From victor@jvknet.com Sun Sep 1 08:38:22 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB211E81FE for ; Sun, 1 Sep 2013 08:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvjpIXLIk8Th for ; Sun, 1 Sep 2013 08:38:18 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id E331111E81F0 for ; Sun, 1 Sep 2013 08:38:17 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so6606416iej.36 for ; Sun, 01 Sep 2013 08:38:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=s38GTFsfp8zeJzcUERgBcV+MOBzxzBnjkRfzf4sSNdo=; b=iG9Cs3RSiZRC+JvMfXQy4tTl4vPIRosNloXqGC5O++9/XN/mYKql22tIEBzgYTXF5m bbKsKCFhSt9httLMDyUqqp6Sj8SGzL4+zd3y4ceLHRvL7/sv8f3hv81mbvDfxdspFfjU sCMphHouQ2wve5SbY+hNA25rHEZkTpFGbwyxrRF+U7ALpQC9FzqWybK1nClSTs6+/6TO hcMtXfywbclIcdGoyKjXuCDSV4wvMyETZKHx2SjbW0uciukaon4labmcgE4kmt9vDP16 8HhQWny4s3TFNgPri9YZOFTUA8ivcPXM1E4CSsBIr+v2gl8ckchk8IlWadYH1+ulsxLl C0wQ== X-Gm-Message-State: ALoCoQnV+ZxA529tweRYGpiYgDfQl9RnY+qum2KnaMcBn7CguBpBG1Mi79E9bX1asWFLxPg2/x1R X-Received: by 10.50.50.210 with SMTP id e18mr9165964igo.9.1378049895396; Sun, 01 Sep 2013 08:38:15 -0700 (PDT) Received: from [192.168.1.45] ([24.114.95.88]) by mx.google.com with ESMTPSA id oq3sm11281473igb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 01 Sep 2013 08:38:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 01 Sep 2013 11:38:04 -0400 From: Victor Kuarsingh To: "Roberta Maglione (robmgl)" , "Alvaro Retana (aretana)" Message-ID: Thread-Topic: [Status] Summary of STATUS BOF and the next steps In-Reply-To: <4FF0BAF2-CA67-422F-8DAB-66704C6A590A@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Adrian Farrel , "status@ietf.org" , "John G. Scudder" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2013 15:38:22 -0000 All, I would also favour "Segment Routing WG" as well. I note this since attempting to come up with an all encompassing acronym will be difficult and Segment Routing is generic enough to associate to multiple functions. Regards, Victor K On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" wrote: >+1 for Segment Routing WG > >Roberta > >Sent from my iPad > >On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >wrote: > >> Segment Routing WG >> >> Sent from my iPhone >> >> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >> wrote: >> >>> The second task, which hopefully should be relatively easy, >>> is to find a better working name for the WG, since it has >>> been put to me a number of times that STATUS is going to >>> be confusing in text and a difficult search term. >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status From mark@townsley.net Sun Sep 1 10:08:13 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A0221E8083 for ; Sun, 1 Sep 2013 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdcD6IHu5H6L for ; Sun, 1 Sep 2013 10:08:08 -0700 (PDT) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3342211E8152 for ; Sun, 1 Sep 2013 10:07:59 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id q16so1863856ead.7 for ; Sun, 01 Sep 2013 10:07:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iaAp5RZ4x3cBs7LmuH5Uh13hr0u/yDZHslFcLyMiTpA=; b=lJKJ6uZ4zda/ONsxd6cPRr5dWEeGynRL7itiIKOLcUKd0tn18v4dky4Y/pJPTkkEmc vY5TmbKzBhHS1JdXoR9G10uMDW3R21CeGMvRJm01NsA9fICUBhri5LJCsVIWGD86hTgB lrb7/+S8DG74huWGJyBRtPcyiuMSFyRgEasGWSkHMNuc4BJS36MtSByz6VD5x/g6Mh3Y AuAS17kMS/gGCQvxhzhqU+yx7qDHE+EKVN2Xh4SSCwBiXdHhyFsJMMDHkyWFjgq9TQ8g mElJvZSiKURn3EaQlcm8+C8GG5qG5BGm2l/UismgBUVr/hskcgghfB60L5PtBEsHDPp0 5riQ== X-Gm-Message-State: ALoCoQlMX7ELiV/b9iqQvKGMKDda4qOJXQT154q7K15py3JfGfi0xGLwVFftdYOekJmUASPC/98X X-Received: by 10.14.176.129 with SMTP id b1mr170460eem.78.1378055278107; Sun, 01 Sep 2013 10:07:58 -0700 (PDT) Received: from ams-townsley-8913.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id bn13sm14760554eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Sep 2013 10:07:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Sun, 1 Sep 2013 19:07:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1283) Cc: "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Sep 2013 17:08:13 -0000 On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: > All, >=20 > I would also favour "Segment Routing WG" as well. >=20 > I note this since attempting to come up with an all encompassing = acronym > will be difficult and Segment Routing is generic enough to associate = to > multiple functions. Then we can just use "segroute" for the short name. WGs do not have to = have acronyms, but they do need to have an 8-char limited short name for = the various automated tools not to break. - Mark >=20 > Regards, >=20 > Victor K >=20 >=20 >=20 > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" > wrote: >=20 >> +1 for Segment Routing WG >>=20 >> Roberta >>=20 >> Sent from my iPad >>=20 >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" = >> wrote: >>=20 >>> Segment Routing WG >>>=20 >>> Sent from my iPhone >>>=20 >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>> wrote: >>>=20 >>>> The second task, which hopefully should be relatively easy, >>>> is to find a better working name for the WG, since it has >>>> been put to me a number of times that STATUS is going to >>>> be confusing in text and a difficult search term. >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From jdrake@juniper.net Tue Sep 3 06:02:15 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8157D21E8134 for ; Tue, 3 Sep 2013 06:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w0vx3-c2gP8 for ; Tue, 3 Sep 2013 06:02:10 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7F21E8141 for ; Tue, 3 Sep 2013 06:02:10 -0700 (PDT) Received: from mail87-va3-R.bigfish.com (10.7.14.225) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 13:02:07 +0000 Received: from mail87-va3 (localhost [127.0.0.1]) by mail87-va3-R.bigfish.com (Postfix) with ESMTP id C53DB140185; Tue, 3 Sep 2013 13:02:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z551biz98dI9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail87-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(51704005)(199002)(189002)(377454003)(13464003)(24454002)(47736001)(76482001)(54356001)(81542001)(19580405001)(83322001)(47976001)(50986001)(56776001)(74876001)(4396001)(15975445006)(54316002)(77096001)(56816003)(49866001)(69226001)(53806001)(81342001)(74316001)(19580395003)(74662001)(74502001)(47446002)(31966008)(83072001)(74706001)(51856001)(46102001)(74366001)(79102001)(76576001)(76796001)(76786001)(81816001)(80976001)(63696002)(65816001)(80022001)(66066001)(81686001)(77982001)(59766001)(33646001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3 (MessageSwitch) id 1378213325451471_8465; Tue, 3 Sep 2013 13:02:05 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.252]) by mail87-va3.bigfish.com (Postfix) with ESMTP id 6796B3A007A; Tue, 3 Sep 2013 13:02:05 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 13:02:05 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 13:02:04 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 13:02:01 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 13:02:01 +0000 From: John E Drake To: Mark Townsley , Victor Kuarsingh Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbKMNMppxiDdAEC+H+M4LHfrLJmv7eKAgAEZNwCAABkbgIAC3wVg Date: Tue, 3 Sep 2013 13:02:01 +0000 Message-ID: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Roberta Maglione \(robmgl\)" , "John G. Scudder" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:02:15 -0000 Hi, What is this 'segment routing' silliness? The correct term is 'source rout= ing'.=20 Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of Mark Townsley > Sent: Sunday, September 01, 2013 10:08 AM > To: Victor Kuarsingh > Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Ret= ana > (aretana); status@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 >=20 > On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >=20 > > All, > > > > I would also favour "Segment Routing WG" as well. > > > > I note this since attempting to come up with an all encompassing > > acronym will be difficult and Segment Routing is generic enough to > > associate to multiple functions. >=20 > Then we can just use "segroute" for the short name. WGs do not have to > have acronyms, but they do need to have an 8-char limited short name for > the various automated tools not to break. >=20 > - Mark >=20 > > > > Regards, > > > > Victor K > > > > > > > > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" > > wrote: > > > >> +1 for Segment Routing WG > >> > >> Roberta > >> > >> Sent from my iPad > >> > >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" > >> > >> wrote: > >> > >>> Segment Routing WG > >>> > >>> Sent from my iPhone > >>> > >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > >>> wrote: > >>> > >>>> The second task, which hopefully should be relatively easy, is to > >>>> find a better working name for the WG, since it has been put to me > >>>> a number of times that STATUS is going to be confusing in text and > >>>> a difficult search term. > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >> _______________________________________________ > >> status mailing list > >> status@ietf.org > >> https://www.ietf.org/mailman/listinfo/status > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 From stephane.litkowski@orange.com Tue Sep 3 06:06:47 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B753121E814E for ; Tue, 3 Sep 2013 06:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kASM8D9hj77m for ; Tue, 3 Sep 2013 06:06:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6CB21E812E for ; Tue, 3 Sep 2013 06:06:41 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 48B1A190201; Tue, 3 Sep 2013 15:06:40 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 25EE6384049; Tue, 3 Sep 2013 15:06:40 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 3 Sep 2013 15:06:39 +0200 From: To: John E Drake , Mark Townsley , Victor Kuarsingh Date: Tue, 3 Sep 2013 15:06:38 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbKMNMppxiDdAEC+H+M4LHfrLJmv7eKAgAEZNwCAABkbgIAC3wVggAAB9kA= Message-ID: <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.3.102415 Cc: "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:06:47 -0000 Hi, "Source routing" is just a subcase of segment routing ... as it is for IP r= outing ... Stephane =20 -----Message d'origine----- De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de= John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); A= drian Farrel; status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps Hi, What is this 'segment routing' silliness? The correct term is 'source rout= ing'.=20 Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 > Behalf Of Mark Townsley > Sent: Sunday, September 01, 2013 10:08 AM > To: Victor Kuarsingh > Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20 > Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 >=20 > On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >=20 > > All, > > > > I would also favour "Segment Routing WG" as well. > > > > I note this since attempting to come up with an all encompassing=20 > > acronym will be difficult and Segment Routing is generic enough to=20 > > associate to multiple functions. >=20 > Then we can just use "segroute" for the short name. WGs do not have to=20 > have acronyms, but they do need to have an 8-char limited short name=20 > for the various automated tools not to break. >=20 > - Mark >=20 > > > > Regards, > > > > Victor K > > > > > > > > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20 > > > > wrote: > > > >> +1 for Segment Routing WG > >> > >> Roberta > >> > >> Sent from my iPad > >> > >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" > >> > >> wrote: > >> > >>> Segment Routing WG > >>> > >>> Sent from my iPhone > >>> > >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > >>> wrote: > >>> > >>>> The second task, which hopefully should be relatively easy, is to=20 > >>>> find a better working name for the WG, since it has been put to=20 > >>>> me a number of times that STATUS is going to be confusing in text=20 > >>>> and a difficult search term. > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >> _______________________________________________ > >> status mailing list > >> status@ietf.org > >> https://www.ietf.org/mailman/listinfo/status > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jdrake@juniper.net Tue Sep 3 06:32:00 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF911E81D7 for ; Tue, 3 Sep 2013 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1akcU+dKfDD for ; Tue, 3 Sep 2013 06:31:55 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8DE11E81D6 for ; Tue, 3 Sep 2013 06:31:55 -0700 (PDT) Received: from mail182-db9-R.bigfish.com (10.174.16.236) by DB9EHSOBE004.bigfish.com (10.174.14.67) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 13:31:53 +0000 Received: from mail182-db9 (localhost [127.0.0.1]) by mail182-db9-R.bigfish.com (Postfix) with ESMTP id E45A312016A; Tue, 3 Sep 2013 13:31:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -72 X-BigFish: VPS-72(z551biz98dI9371Ic89bh936eI542I1432I15caKJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail182-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(55784002)(24454002)(51704005)(13464003)(377424004)(189002)(199002)(59766001)(77982001)(76482001)(54316002)(56776001)(53806001)(54356001)(76576001)(77096001)(56816003)(76796001)(76786001)(74662001)(63696002)(47446002)(74502001)(79102001)(31966008)(47736001)(15975445006)(49866001)(47976001)(50986001)(4396001)(81342001)(81542001)(81816001)(74706001)(74366001)(46102001)(74876001)(81686001)(65816001)(80022001)(69226001)(83072001)(33646001)(66066001)(74316001)(51856001)(80976001)(83322001)(19580405001)(19580395003)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail182-db9 (localhost.localdomain [127.0.0.1]) by mail182-db9 (MessageSwitch) id 1378215110623019_24333; Tue, 3 Sep 2013 13:31:50 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.243]) by mail182-db9.bigfish.com (Postfix) with ESMTP id 921B83C0041; Tue, 3 Sep 2013 13:31:50 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 13:31:49 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 13:31:46 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 13:31:42 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 13:31:42 +0000 From: John E Drake To: "stephane.litkowski@orange.com" , Mark Townsley , Victor Kuarsingh Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbKMNMppxiDdAEC+H+M4LHfrLJmv7eKAgAEZNwCAABkbgIAC3wVggAAB9kCAAAZRQA== Date: Tue, 3 Sep 2013 13:31:41 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:32:01 -0000 Stephane, I don't see anything in the segment routing architecture I-D that justifies= your assertion. Yours Irrespectively, John > -----Original Message----- > From: stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > Sent: Tuesday, September 03, 2013 6:07 AM > To: John E Drake; Mark Townsley; Victor Kuarsingh > Cc: Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); > Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) > Subject: RE: [Status] Summary of STATUS BOF and the next steps >=20 > Hi, >=20 > "Source routing" is just a subcase of segment routing ... as it is for IP= routing > ... >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part = de > John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark Townsley; > Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro > Retana (aretana); Adrian Farrel; status@ietf.org; Stewart Bryant (stbryan= t) > Objet : Re: [Status] Summary of STATUS BOF and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'. >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > > Behalf Of Mark Townsley > > Sent: Sunday, September 01, 2013 10:08 AM > > To: Victor Kuarsingh > > Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro > > Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) > > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > > > > > On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: > > > > > All, > > > > > > I would also favour "Segment Routing WG" as well. > > > > > > I note this since attempting to come up with an all encompassing > > > acronym will be difficult and Segment Routing is generic enough to > > > associate to multiple functions. > > > > Then we can just use "segroute" for the short name. WGs do not have to > > have acronyms, but they do need to have an 8-char limited short name > > for the various automated tools not to break. > > > > - Mark > > > > > > > > Regards, > > > > > > Victor K > > > > > > > > > > > > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" > > > > > > wrote: > > > > > >> +1 for Segment Routing WG > > >> > > >> Roberta > > >> > > >> Sent from my iPad > > >> > > >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" > > >> > > >> wrote: > > >> > > >>> Segment Routing WG > > >>> > > >>> Sent from my iPhone > > >>> > > >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > > >>> wrote: > > >>> > > >>>> The second task, which hopefully should be relatively easy, is to > > >>>> find a better working name for the WG, since it has been put to > > >>>> me a number of times that STATUS is going to be confusing in text > > >>>> and a difficult search term. > > >>> _______________________________________________ > > >>> status mailing list > > >>> status@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/status > > >> _______________________________________________ > > >> status mailing list > > >> status@ietf.org > > >> https://www.ietf.org/mailman/listinfo/status > > > > > > > > > _______________________________________________ > > > status mailing list > > > status@ietf.org > > > https://www.ietf.org/mailman/listinfo/status > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 >=20 From stbryant@cisco.com Tue Sep 3 06:33:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32BD11E81DC for ; Tue, 3 Sep 2013 06:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.623 X-Spam-Level: X-Spam-Status: No, score=-110.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQedIvaBIz1J for ; Tue, 3 Sep 2013 06:33:13 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDE611E81DB for ; Tue, 3 Sep 2013 06:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4485; q=dns/txt; s=iport; t=1378215192; x=1379424792; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dokUJ7uhPpWnwFc3YWdVxyus0Y8YBXlOPRtaC2+8axE=; b=SKc+TjBGJJneAh1bounTG0ZFplEYA4wUylil+dgQ3tEyqoMqoNPo5K/X /Kkk4CCbcXpFePeuzhzGu1j9UTRwGdMquVtvCek+DgJFrp12nHIulHleb ie0TIh939a8N+7NFA9pF0tb7vZjFn/P+f3v8L7KW5gjDtzZ7bHOpzwKsH E=; X-IronPort-AV: E=Sophos;i="4.89,1014,1367971200"; d="scan'208";a="17714599" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 03 Sep 2013 13:33:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r83DX49F015979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 13:33:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r83DX2u4008506; Tue, 3 Sep 2013 14:33:03 +0100 (BST) Message-ID: <5225E50E.3020100@cisco.com> Date: Tue, 03 Sep 2013 14:33:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: stephane.litkowski@orange.com References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 03 Sep 2013 13:33:17 -0000 Stephane That is not correct. A long time ago there was source routed transparent which was a token ring technology. Stewart On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: > Hi, > > "Source routing" is just a subcase of segment routing ... as it is for IP routing ... > > Stephane > > > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de John E Drake > Envoyé : mardi 3 septembre 2013 15:02 > À : Mark Townsley; Victor Kuarsingh > Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) > Objet : Re: [Status] Summary of STATUS BOF and the next steps > > Hi, > > What is this 'segment routing' silliness? The correct term is 'source routing'. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >> >> >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >> >>> All, >>> >>> I would also favour "Segment Routing WG" as well. >>> >>> I note this since attempting to come up with an all encompassing >>> acronym will be difficult and Segment Routing is generic enough to >>> associate to multiple functions. >> Then we can just use "segroute" for the short name. WGs do not have to >> have acronyms, but they do need to have an 8-char limited short name >> for the various automated tools not to break. >> >> - Mark >> >>> Regards, >>> >>> Victor K >>> >>> >>> >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>> >>> wrote: >>> >>>> +1 for Segment Routing WG >>>> >>>> Roberta >>>> >>>> Sent from my iPad >>>> >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>> >>>>> Segment Routing WG >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>> >>>>>> The second task, which hopefully should be relatively easy, is to >>>>>> find a better working name for the WG, since it has been put to >>>>>> me a number of times that STATUS is going to be confusing in text >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jdrake@juniper.net Tue Sep 3 06:32:47 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47C711E81DB for ; Tue, 3 Sep 2013 06:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJWmNxfrFeyd for ; Tue, 3 Sep 2013 06:32:42 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 35BF811E81D6 for ; Tue, 3 Sep 2013 06:32:42 -0700 (PDT) Received: from mail1-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 13:32:41 +0000 Received: from mail1-am1 (localhost [127.0.0.1]) by mail1-am1-R.bigfish.com (Postfix) with ESMTP id 092583C0414; Tue, 3 Sep 2013 13:32:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -72 X-BigFish: VPS-72(z551biz98dI9371Ic89bh936eI542I1432I15caKJzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail1-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377424004)(199002)(189002)(377454003)(55784002)(51704005)(24454002)(74706001)(4396001)(81686001)(74316001)(19580395003)(46102001)(74366001)(69226001)(83322001)(65816001)(66066001)(19580405001)(80976001)(80022001)(51856001)(81816001)(74876001)(33646001)(47736001)(49866001)(81542001)(47976001)(15975445006)(81342001)(50986001)(56776001)(76482001)(53806001)(83072001)(76796001)(77096001)(76786001)(54356001)(76576001)(59766001)(77982001)(74502001)(47446002)(74662001)(79102001)(31966008)(63696002)(56816003)(54316002)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail1-am1 (localhost.localdomain [127.0.0.1]) by mail1-am1 (MessageSwitch) id 1378215158244957_15431; Tue, 3 Sep 2013 13:32:38 +0000 (UTC) Received: from AM1EHSMHS021.bigfish.com (unknown [10.3.201.252]) by mail1-am1.bigfish.com (Postfix) with ESMTP id 36FFAA005A; Tue, 3 Sep 2013 13:32:38 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS021.bigfish.com (10.3.207.150) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 13:32:37 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 13:32:36 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 13:32:33 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 13:32:32 +0000 From: John E Drake To: AshwoodsmithPeter , "stephane.litkowski@orange.com" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbKMNMppxiDdAEC+H+M4LHfrLJmv7eKAgAEZNwCAABkbgIAC3wVggAAB9kCAAAYHgIAAAXAg Date: Tue, 3 Sep 2013 13:32:32 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> In-Reply-To: <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Tue, 03 Sep 2013 06:37:21 -0700 Cc: Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:32:48 -0000 Excellent. Yours Irrespectively, John > -----Original Message----- > From: AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] > Sent: Tuesday, September 03, 2013 6:27 AM > To: stephane.litkowski@orange.com > Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione > (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); > status@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > The term "source routing" has been around for a very long time and is dat= a > path agnostic. Its also the term used in the literature etc so my prefere= nce is > to stick with this existing well known and data path agnostic term. >=20 > Peter >=20 > On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" > wrote: >=20 > > Hi, > > > > "Source routing" is just a subcase of segment routing ... as it is for = IP routing > ... > > > > Stephane > > > > > > -----Message d'origine----- > > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la > > part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark > > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. > > Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; > > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF > > and the next steps > > > > Hi, > > > > What is this 'segment routing' silliness? The correct term is 'source = routing'. > > > > Yours Irrespectively, > > > > John > > > >> -----Original Message----- > >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > >> Behalf Of Mark Townsley > >> Sent: Sunday, September 01, 2013 10:08 AM > >> To: Victor Kuarsingh > >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro > >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) > >> Subject: Re: [Status] Summary of STATUS BOF and the next steps > >> > >> > >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: > >> > >>> All, > >>> > >>> I would also favour "Segment Routing WG" as well. > >>> > >>> I note this since attempting to come up with an all encompassing > >>> acronym will be difficult and Segment Routing is generic enough to > >>> associate to multiple functions. > >> > >> Then we can just use "segroute" for the short name. WGs do not have > >> to have acronyms, but they do need to have an 8-char limited short > >> name for the various automated tools not to break. > >> > >> - Mark > >> > >>> > >>> Regards, > >>> > >>> Victor K > >>> > >>> > >>> > >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" > >>> > >>> wrote: > >>> > >>>> +1 for Segment Routing WG > >>>> > >>>> Roberta > >>>> > >>>> Sent from my iPad > >>>> > >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" > >>>> > >>>> wrote: > >>>> > >>>>> Segment Routing WG > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > >>>>> wrote: > >>>>> > >>>>>> The second task, which hopefully should be relatively easy, is to > >>>>>> find a better working name for the WG, since it has been put to > >>>>>> me a number of times that STATUS is going to be confusing in text > >>>>>> and a difficult search term. > >>>>> _______________________________________________ > >>>>> status mailing list > >>>>> status@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/status > >>>> _______________________________________________ > >>>> status mailing list > >>>> status@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/status > >>> > >>> > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >> > >> _______________________________________________ > >> status mailing list > >> status@ietf.org > >> https://www.ietf.org/mailman/listinfo/status > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > > > > __________________________________________________________ > ____________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status >=20 From Peter.AshwoodSmith@huawei.com Tue Sep 3 06:27:39 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF5021E813A for ; Tue, 3 Sep 2013 06:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EHtN11S83QR for ; Tue, 3 Sep 2013 06:27:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7849521F9C4C for ; Tue, 3 Sep 2013 06:27:26 -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.5-GA FastPath queued) with ESMTP id AWW04056; Tue, 03 Sep 2013 13:27:24 +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.146.0; Tue, 3 Sep 2013 14:27:08 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 14:27:21 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 06:27:15 -0700 From: AshwoodsmithPeter To: "stephane.litkowski@orange.com" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqkw== Date: Tue, 3 Sep 2013 13:27:15 +0000 Message-ID: <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 03 Sep 2013 06:38:21 -0700 Cc: John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:27:40 -0000 The term "source routing" has been around for a very long time and is data = path agnostic. Its also the term used in the literature etc so my preferenc= e is to stick with this existing well known and data path agnostic term. Peter On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > Hi, >=20 > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part = de John E Drake > Envoy=E9 : mardi 3 septembre 2013 15:02 > =C0 : Mark Townsley; Victor Kuarsingh > Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);= Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) > Objet : Re: [Status] Summary of STATUS BOF and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'.=20 >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20 >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >>=20 >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>=20 >>> All, >>>=20 >>> I would also favour "Segment Routing WG" as well. >>>=20 >>> I note this since attempting to come up with an all encompassing=20 >>> acronym will be difficult and Segment Routing is generic enough to=20 >>> associate to multiple functions. >>=20 >> Then we can just use "segroute" for the short name. WGs do not have to=20 >> have acronyms, but they do need to have an 8-char limited short name=20 >> for the various automated tools not to break. >>=20 >> - Mark >>=20 >>>=20 >>> Regards, >>>=20 >>> Victor K >>>=20 >>>=20 >>>=20 >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20 >>> >>> wrote: >>>=20 >>>> +1 for Segment Routing WG >>>>=20 >>>> Roberta >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>>=20 >>>>> Segment Routing WG >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>>=20 >>>>>> The second task, which hopefully should be relatively easy, is to=20 >>>>>> find a better working name for the WG, since it has been put to=20 >>>>>> me a number of times that STATUS is going to be confusing in text=20 >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From Peter.AshwoodSmith@huawei.com Tue Sep 3 06:41:56 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746B011E81D3 for ; Tue, 3 Sep 2013 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNwFeDJaCjYW for ; Tue, 3 Sep 2013 06:41:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1D11E812E for ; Tue, 3 Sep 2013 06:41:49 -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.5-GA FastPath queued) with ESMTP id AUZ97544; Tue, 03 Sep 2013 13:41:48 +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.146.0; Tue, 3 Sep 2013 14:41:16 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 14:41:28 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 06:41:22 -0700 From: AshwoodsmithPeter To: "stbryant@cisco.com" , "stephane.litkowski@orange.com" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwCAAAdgAP//izAg Date: Tue, 3 Sep 2013 13:41:22 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E3692@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <5225E50E.3020100@cisco.com> In-Reply-To: <5225E50E.3020100@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.231] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 03 Sep 2013 06:45:10 -0700 Cc: John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:41:57 -0000 There was a lot of work on source routing mechanisms independent of IP. One= rather cool example was a mechanism for routing through a constellation of= polar orbit satellites. Geodesic I think it was called. There were also a = number of other non IP proprietary source routing protocols deployed too. A= nyway I agree that the term is generic and not tied to IP any more than hop= -by-hop routing is tied to IP. Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Tuesday, September 03, 2013 9:33 AM To: stephane.litkowski@orange.com Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps Stephane That is not correct. A long time ago there was source routed transparent=20 which was a token ring technology. Stewart On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: > Hi, > > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... > > Stephane > =20 > > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part = de John E Drake > Envoy=E9 : mardi 3 septembre 2013 15:02 > =C0 : Mark Townsley; Victor Kuarsingh > Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);= Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) > Objet : Re: [Status] Summary of STATUS BOF and the next steps > > Hi, > > What is this 'segment routing' silliness? The correct term is 'source ro= uting'. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >> >> >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >> >>> All, >>> >>> I would also favour "Segment Routing WG" as well. >>> >>> I note this since attempting to come up with an all encompassing >>> acronym will be difficult and Segment Routing is generic enough to >>> associate to multiple functions. >> Then we can just use "segroute" for the short name. WGs do not have to >> have acronyms, but they do need to have an 8-char limited short name >> for the various automated tools not to break. >> >> - Mark >> >>> Regards, >>> >>> Victor K >>> >>> >>> >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>> >>> wrote: >>> >>>> +1 for Segment Routing WG >>>> >>>> Roberta >>>> >>>> Sent from my iPad >>>> >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>> >>>>> Segment Routing WG >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>> >>>>>> The second task, which hopefully should be relatively easy, is to >>>>>> find a better working name for the WG, since it has been put to >>>>>> me a number of times that STATUS is going to be confusing in text >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > . > --=20 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From Ruediger.Geib@telekom.de Tue Sep 3 06:45:09 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3311E81E6 for ; Tue, 3 Sep 2013 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8lIrtfKApyl for ; Tue, 3 Sep 2013 06:45:04 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 12B1E11E81DD for ; Tue, 3 Sep 2013 06:45:02 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 03 Sep 2013 15:45:00 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 3 Sep 2013 15:45:00 +0200 From: To: Date: Tue, 3 Sep 2013 15:44:58 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6oqjlhlvw1TzoYQAOxFwxTLr4rygAALuVA Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <5225E50E.3020100@cisco.com> In-Reply-To: <5225E50E.3020100@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 03 Sep 2013 07:00:07 -0700 Cc: jdrake@juniper.net, stephane.litkowski@orange.com, mark@townsley.net, victor@jvknet.com, robmgl@cisco.com, jgs@bgp.nu, aretana@cisco.com, adrian@olddog.co.uk, status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:45:10 -0000 Stewart, to name a WG "Source Routing WG" just because it allows a more organised wa= y of exploiting features of an MPLS network, and that limited to paths and = routers where an operator desires to utlise these features doesn't seem to = be a good idea. Segment Routing describes what the company I work for will be using it. We = don't intend to operate a source routed network. It's an enhancement as com= pared to LDP based MPLS. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Tuesday, September 03, 2013 3:33 PM To: stephane.litkowski@orange.com Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps Stephane That is not correct. A long time ago there was source routed transparent which was a token ring technology. Stewart On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: > Hi, > > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... > > Stephane > > > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part = de John E Drake > Envoy=E9 : mardi 3 septembre 2013 15:02 > =C0 : Mark Townsley; Victor Kuarsingh > Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana);= Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) > Objet : Re: [Status] Summary of STATUS BOF and the next steps > > Hi, > > What is this 'segment routing' silliness? The correct term is 'source ro= uting'. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >> >> >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >> >>> All, >>> >>> I would also favour "Segment Routing WG" as well. >>> >>> I note this since attempting to come up with an all encompassing >>> acronym will be difficult and Segment Routing is generic enough to >>> associate to multiple functions. >> Then we can just use "segroute" for the short name. WGs do not have to >> have acronyms, but they do need to have an 8-char limited short name >> for the various automated tools not to break. >> >> - Mark >> >>> Regards, >>> >>> Victor K >>> >>> >>> >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>> >>> wrote: >>> >>>> +1 for Segment Routing WG >>>> >>>> Roberta >>>> >>>> Sent from my iPad >>>> >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>> >>>>> Segment Routing WG >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>> >>>>>> The second task, which hopefully should be relatively easy, is to >>>>>> find a better working name for the WG, since it has been put to >>>>>> me a number of times that STATUS is going to be confusing in text >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From loa@pi.nu Tue Sep 3 06:58:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818611E81F4 for ; Tue, 3 Sep 2013 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nWKJehs1nHp for ; Tue, 3 Sep 2013 06:58:30 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BB11721F9EFE for ; Tue, 3 Sep 2013 06:58:28 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4F18618033E4; Tue, 3 Sep 2013 15:58:27 +0200 (CEST) Message-ID: <5225EB04.5000904@pi.nu> Date: Tue, 03 Sep 2013 15:58:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: AshwoodsmithPeter References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <5225E50E.3020100@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E3692@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E3692@dfweml513-mbb.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 03 Sep 2013 07:00:07 -0700 Cc: "stephane.litkowski@orange.com" , John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:58:35 -0000 All, I wonder - if this is true: In segment routing the source to a (partial) source routing defining which segments (for any value of segment) that should be in the path. Each segment may or may not be establish by source routing or any other routing technology. If this is true - then a discussion on what is and what is not a sub-set of the other will turn out to be extremely non-productive. Also there is both "segment routing" and "source routing" - I could imagine a case where which segment to use is not determined by the source but by any standard routing algorithm. If doing this has any value or not is for the future. /Loa On 2013-09-03 15:41, AshwoodsmithPeter wrote: > There was a lot of work on source routing mechanisms independent of IP. One rather cool example was a mechanism for routing through a constellation of polar orbit satellites. Geodesic I think it was called. There were also a number of other non IP proprietary source routing protocols deployed too. Anyway I agree that the term is generic and not tied to IP any more than hop-by-hop routing is tied to IP. > > Peter > > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, September 03, 2013 9:33 AM > To: stephane.litkowski@orange.com > Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > Stephane > > That is not correct. A long time ago there was source routed transparent > which was a token ring technology. > > Stewart > > On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: >> Hi, >> >> "Source routing" is just a subcase of segment routing ... as it is for IP routing ... >> >> Stephane >> >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de John E Drake >> Envoyé : mardi 3 septembre 2013 15:02 >> À : Mark Townsley; Victor Kuarsingh >> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) >> Objet : Re: [Status] Summary of STATUS BOF and the next steps >> >> Hi, >> >> What is this 'segment routing' silliness? The correct term is 'source routing'. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of Mark Townsley >>> Sent: Sunday, September 01, 2013 10:08 AM >>> To: Victor Kuarsingh >>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>> >>>> All, >>>> >>>> I would also favour "Segment Routing WG" as well. >>>> >>>> I note this since attempting to come up with an all encompassing >>>> acronym will be difficult and Segment Routing is generic enough to >>>> associate to multiple functions. >>> Then we can just use "segroute" for the short name. WGs do not have to >>> have acronyms, but they do need to have an 8-char limited short name >>> for the various automated tools not to break. >>> >>> - Mark >>> >>>> Regards, >>>> >>>> Victor K >>>> >>>> >>>> >>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>> >>>> wrote: >>>> >>>>> +1 for Segment Routing WG >>>>> >>>>> Roberta >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>> >>>>> wrote: >>>>> >>>>>> Segment Routing WG >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>> wrote: >>>>>> >>>>>>> The second task, which hopefully should be relatively easy, is to >>>>>>> find a better working name for the WG, since it has been put to >>>>>>> me a number of times that STATUS is going to be confusing in text >>>>>>> and a difficult search term. >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> . >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jnc@mercury.lcs.mit.edu Tue Sep 3 07:19:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8626321E80B9 for ; Tue, 3 Sep 2013 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RbSs3Kch9nH for ; Tue, 3 Sep 2013 07:19:12 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6F021F9CFB for ; Tue, 3 Sep 2013 07:19:12 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1611C18C1C2; Tue, 3 Sep 2013 10:19:12 -0400 (EDT) To: status@ietf.org Message-Id: <20130903141912.1611C18C1C2@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 10:19:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 14:19:17 -0000 > From: John E Drake > What is this 'segment routing' silliness? The correct term is 'source > routing'. After a quick review of the I-D, I'm not so sure. To me, "source routing" means... the source picks the path (specified either at a high level - 'loose source route' - or at a low level - 'strict source route'). Which is why in Nimrod (RFC-1992) we did not use the term "source route", because it tended to confuse people - newcomers saw that phrase "source route" and applied their existing mental models - and went way wrong. The I-D isn't as clear as I'd like (it seems to jumble together architectural description and engineering detail - in the early sections, at least), but to me, the first question to answer is 'who makes the path selection decisions'. We have 'hop by hop' as a clearly understood term for one end of that spectrum, and 'source routing' (classic version) for another end, but for things in the middle (e.g. use of MPLS paths to carry datagram traffic along an MPLS flow for _part_ of the packet's entire end-end path) we don't really have clear terminology. I tried, but could never come up with a good one: I tried "unitary routing" for Nimrod's model (emphasizing that _one_ entity was in charge of selecting the path, although perhaps in terms of high-level entities, with the path selection process then recursing down to actual hardware, all using the same basic model), but I was never happy with that. I later started using "explicit routing", but I'm not sure that was any better. "Segment routing" might in fact be a pretty good term to describe what this design does (at least, as best I understand it). But I'd suggest to the I-D writers that they focus on 'who makes the path selection decision(s)' first, and only later talk about 'how that decisision is carried out' (be it by a sequence of flow labels, or whatever - those are secondary questions). > From: AshwoodsmithPeter > The term "source routing" has been around for a very long time .. Its > also the term used in the literature etc Which means that it already has a meaning in people's minds - and, worse yet, since it has been used to cover a lot of ground, those meanings may be _different_ for different people. (We really need better taxonomy of how paths are selected - as Saltzer memorably said in RFC-1498, "trying to discuss the issues with too few well-defined [terms] at hand" leads to confusion. There are a lot more options for how paths are selected than just 'hop-by-hop' and 'classic source route' - e.g. the existing MPLS stuff I alluded to above.) Anyway, if the concept in this I-D is in some ways significantly different from 'classic' source routing, use of that term will be confusing, so we should not re-use that term. Noel From bruno.decraene@orange.com Tue Sep 3 07:29:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75A21E8154 for ; Tue, 3 Sep 2013 07:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFgAN0Yj7kWM for ; Tue, 3 Sep 2013 07:29:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 03DDB21E80B9 for ; Tue, 3 Sep 2013 07:29:37 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id DC75D190460; Tue, 3 Sep 2013 16:29:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id B992315803A; Tue, 3 Sep 2013 16:29:35 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 3 Sep 2013 16:29:35 +0200 From: To: "Ruediger.Geib@telekom.de" , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6oqjlhlvw1TzoYQAOxFwxTLr4rygAALuVAAAG7ZPA= Date: Tue, 3 Sep 2013 14:29:35 +0000 Message-ID: <725_1378218575_5225F24F_725_18465_1_53C29892C857584299CBF5D05346208A070591C5@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <5225E50E.3020100@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.3.102415 Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 14:29:41 -0000 +1 Regarding the MPLS dataplane, it's mostly about using the IGP as the (intra= AS) label distribution protocol for both SPT and 1 hop LSP. Then this allo= ws for easier stacking of LSP/segments as any LSR knows all the LSP/segment= s of the AS, which can then be used for different use cases as presented du= ring the BOF. This is not source routing from the source of the IP packet. Regards, Bruno >From: Ruediger.Geib@telekom.de > >Stewart, > >to name a WG "Source Routing WG" just because it allows a more organised w= ay >of exploiting features of an MPLS network, and that limited to paths and >routers where an operator desires to utlise these features doesn't seem to >be a good idea. > >Segment Routing describes what the company I work for will be using it. We >don't intend to operate a source routed network. It's an enhancement as >compared to LDP based MPLS. > >Regards, > >Ruediger > >-----Original Message----- >From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of >Stewart Bryant >Sent: Tuesday, September 03, 2013 3:33 PM >To: stephane.litkowski@orange.com >Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione >(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >status@ietf.org >Subject: Re: [Status] Summary of STATUS BOF and the next steps > >Stephane > >That is not correct. A long time ago there was source routed transparent >which was a token ring technology. > >Stewart > >On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: >> Hi, >> >> "Source routing" is just a subcase of segment routing ... as it is for IP >routing ... >> >> Stephane >> >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part >de John E Drake >> Envoy=E9 : mardi 3 septembre 2013 15:02 >> =C0 : Mark Townsley; Victor Kuarsingh >> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); >Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) >> Objet : Re: [Status] Summary of STATUS BOF and the next steps >> >> Hi, >> >> What is this 'segment routing' silliness? The correct term is 'source >routing'. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of Mark Townsley >>> Sent: Sunday, September 01, 2013 10:08 AM >>> To: Victor Kuarsingh >>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>> >>>> All, >>>> >>>> I would also favour "Segment Routing WG" as well. >>>> >>>> I note this since attempting to come up with an all encompassing >>>> acronym will be difficult and Segment Routing is generic enough to >>>> associate to multiple functions. >>> Then we can just use "segroute" for the short name. WGs do not have to >>> have acronyms, but they do need to have an 8-char limited short name >>> for the various automated tools not to break. >>> >>> - Mark >>> >>>> Regards, >>>> >>>> Victor K >>>> >>>> >>>> >>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>> >>>> wrote: >>>> >>>>> +1 for Segment Routing WG >>>>> >>>>> Roberta >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>> >>>>> wrote: >>>>> >>>>>> Segment Routing WG >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>> wrote: >>>>>> >>>>>>> The second task, which hopefully should be relatively easy, is to >>>>>>> find a better working name for the WG, since it has been put to >>>>>>> me a number of times that STATUS is going to be confusing in text >>>>>>> and a difficult search term. >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> >__________________________________________________________________________= __ >_____________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou >falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en >modified, changed or falsified. >> Thank you. >> >> . >> > > >-- >For corporate legal information go to: > >http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From stephane.litkowski@orange.com Tue Sep 3 07:43:34 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9736A21E80E0 for ; Tue, 3 Sep 2013 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FobORPsEnH5V for ; Tue, 3 Sep 2013 07:43:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3697221E80D8 for ; Tue, 3 Sep 2013 07:43:29 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 982B21B8718; Tue, 3 Sep 2013 16:43:28 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 56B89180049; Tue, 3 Sep 2013 16:43:28 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 3 Sep 2013 16:43:27 +0200 From: To: AshwoodsmithPeter Date: Tue, 3 Sep 2013 16:43:26 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDA= Message-ID: <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.3.102415 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 14:43:34 -0000 =20 There was a misunderstanding in my small comment :) so I will explain more : In segment routing, you have more than basic source routing : segment routi= ng is just associate a segment number to an action and then combine segment= as you want, yes you can do source routing, but you also can do more. In the other hand, I completely agree with your statement that source routi= ng is generic and dataplane agnostic, as segment routing is ... (segment ro= uting is not a new dataplane ...) Now the definition of the WG naming must be inline with the charter that wi= ll be defined ... (draft today) =20 Based on the already existing consensus (at least for MPLS dataplane) broug= ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good= target candidate. So now, do we want to do more in the WG charter than just make progressing = segment routing architecture and uses cases document and ensure coordinatio= n for the standardization of this technology ? =20 Do we want to standardize other technologies in this WG ? I don't think so,= based on Stewart's conclusion email from the BOF :"A new WG focused solely= on SR therefore needs to be create" If the WG charter is limited to source routing, how will we handle the "non= source routing" use cases of segment routing ? In another working group ? = So we will go back to the WG synchronization issue that has been raised for= this technology ... If the WG is focused on SR, let's use a name in relation with SR. Feedback ? Stephane -----Message d'origine----- De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg= l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.or= g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and= the next steps The term "source routing" has been around for a very long time and is data = path agnostic. Its also the term used in the literature etc so my preferenc= e is to stick with this existing well known and data path agnostic term. Peter On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > Hi, >=20 > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la=20 > part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark= =20 > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. > Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org;=20 > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20 > and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'.=20 >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20 >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >>=20 >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>=20 >>> All, >>>=20 >>> I would also favour "Segment Routing WG" as well. >>>=20 >>> I note this since attempting to come up with an all encompassing=20 >>> acronym will be difficult and Segment Routing is generic enough to=20 >>> associate to multiple functions. >>=20 >> Then we can just use "segroute" for the short name. WGs do not have=20 >> to have acronyms, but they do need to have an 8-char limited short=20 >> name for the various automated tools not to break. >>=20 >> - Mark >>=20 >>>=20 >>> Regards, >>>=20 >>> Victor K >>>=20 >>>=20 >>>=20 >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20 >>> >>> wrote: >>>=20 >>>> +1 for Segment Routing WG >>>>=20 >>>> Roberta >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>>=20 >>>>> Segment Routing WG >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>>=20 >>>>>> The second task, which hopefully should be relatively easy, is to=20 >>>>>> find a better working name for the WG, since it has been put to=20 >>>>>> me a number of times that STATUS is going to be confusing in text=20 >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From gregory.mirsky@ericsson.com Tue Sep 3 07:08:43 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE0121E80B6 for ; Tue, 3 Sep 2013 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTq9AkvcQgby for ; Tue, 3 Sep 2013 07:08:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5823F21E812C for ; Tue, 3 Sep 2013 07:08:31 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-50-5225ed5ebf14 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5B.01.03458.E5DE5225; Tue, 3 Sep 2013 16:08:30 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Tue, 3 Sep 2013 10:04:53 -0400 From: Gregory Mirsky To: Loa Andersson , AshwoodsmithPeter Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJjWn+At7PVFUmdqonqRanQiJmwMPCAgAEZOACAABkagIAC3/aAgAABSgCAAAdgAIAAAlQAgAAExwD//76L8A== Date: Tue, 3 Sep 2013 14:04:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6E42F0@eusaamb103.ericsson.se> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <5225E50E.3020100@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E3692@dfweml513-mbb.china.huawei.com> <5225EB04.5000904@pi.nu> In-Reply-To: <5225EB04.5000904@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXRPoG7cW9Ugg+ULNSx+9Nxgtvj7cyuj xZy7zhYb/+9gt/g3dw6zxbQDD5gsFt5tY7JY22Nl8br5IpPFuadzGC2+7n3IanF98WNWBx6P Jd3vmTym/N7I6tFy5C2rx5IlP5k8rjddZff4++wMu8eKzSsZPVqenWTzmDW9jc3j/rSJTAFc UVw2Kak5mWWpRfp2CVwZfzasYCuYbV7R3LWPqYFxhm4XIyeHhICJxIT2VWwQtpjEhXvrgWwu DiGBo4wS/179Y4VwljFK3Hx0jQWkik3ASOLFxh72LkYODhGBIInv6/hAwswCm5kluueJgtjC AnYS96/eZwWxRQTsJc6fvccEYWdJHH3SAjaGRUBF4sfJf4wgNq+Ar8SGwxcYIXatZ5Z4/nYW WAOngKrElT9PwQYxAl33/dQaJohl4hK3nsxngrhaQGLJnvPMELaoxMvH/1ghbGWJ73MesUDU 60ncmDqFDcLWlli28DUzxGJBiZMzn7BMYBSbhWTsLCQts5C0zELSsoCRZRUjR2lxalluupHh JkZgXB+TYHPcwbjgk+UhRmkOFiVx3g16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MM7+ cjVDY8+1HKN5G3S5l1dPfXt0tYeoihCr5qv9q/qfO68Wdv9m2KBqX1Usoe1XYfvE6dfUooQn U/0eyrtznpZfyv1QS1Tt4dwpmlePHveckvd34kup8upDs0XPhb67e2DzXY4mXWVDxUPu18Kr ZoRcTJ14+ddXDQXJM/dSAk+UHrZT4oou91NiKc5INNRiLipOBACF08fTuQIAAA== X-Mailman-Approved-At: Tue, 03 Sep 2013 08:12:31 -0700 Cc: "stephane.litkowski@orange.com" , John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 14:08:43 -0000 Unified Segment Source Routing (USSR)? ;) Regards, Greg -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Loa Andersson Sent: Tuesday, September 03, 2013 6:58 AM To: AshwoodsmithPeter Cc: stephane.litkowski@orange.com; John E Drake; Mark Townsley; Victor Kuar= singh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Re= tana (aretana); status@ietf.org; stbryant@cisco.com Subject: Re: [Status] Summary of STATUS BOF and the next steps All, I wonder - if this is true: In segment routing the source to a (partial) source routing defining which = segments (for any value of segment) that should be in the path. Each segment may or may not be establish by source routing or any other rou= ting technology. If this is true - then a discussion on what is and what is not a sub-set of= the other will turn out to be extremely non-productive. Also there is both "segment routing" and "source routing" - I could imagine= a case where which segment to use is not determined by the source but by a= ny standard routing algorithm. If doing this has any value or not is for th= e future. /Loa On 2013-09-03 15:41, AshwoodsmithPeter wrote: > There was a lot of work on source routing mechanisms independent of IP. O= ne rather cool example was a mechanism for routing through a constellation = of polar orbit satellites. Geodesic I think it was called. There were also = a number of other non IP proprietary source routing protocols deployed too.= Anyway I agree that the term is generic and not tied to IP any more than h= op-by-hop routing is tied to IP. > > Peter > > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 > Behalf Of Stewart Bryant > Sent: Tuesday, September 03, 2013 9:33 AM > To: stephane.litkowski@orange.com > Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione=20 > (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);=20 > status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > Stephane > > That is not correct. A long time ago there was source routed=20 > transparent which was a token ring technology. > > Stewart > > On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: >> Hi, >> >> "Source routing" is just a subcase of segment routing ... as it is for I= P routing ... >> >> Stephane >> >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la=20 >> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark= =20 >> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.=20 >> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org;=20 >> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20 >> and the next steps >> >> Hi, >> >> What is this 'segment routing' silliness? The correct term is 'source r= outing'. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >>> Behalf Of Mark Townsley >>> Sent: Sunday, September 01, 2013 10:08 AM >>> To: Victor Kuarsingh >>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;=20 >>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>> >>>> All, >>>> >>>> I would also favour "Segment Routing WG" as well. >>>> >>>> I note this since attempting to come up with an all encompassing=20 >>>> acronym will be difficult and Segment Routing is generic enough to=20 >>>> associate to multiple functions. >>> Then we can just use "segroute" for the short name. WGs do not have=20 >>> to have acronyms, but they do need to have an 8-char limited short=20 >>> name for the various automated tools not to break. >>> >>> - Mark >>> >>>> Regards, >>>> >>>> Victor K >>>> >>>> >>>> >>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>> >>>> wrote: >>>> >>>>> +1 for Segment Routing WG >>>>> >>>>> Roberta >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>> >>>>> wrote: >>>>> >>>>>> Segment Routing WG >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>> wrote: >>>>>> >>>>>>> The second task, which hopefully should be relatively easy, is=20 >>>>>>> to find a better working name for the WG, since it has been put=20 >>>>>>> to me a number of times that STATUS is going to be confusing in=20 >>>>>>> text and a difficult search term. >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> . >> > > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From stephane.litkowski@orange.com Tue Sep 3 07:42:15 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A18821E80DD for ; Tue, 3 Sep 2013 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osxs1V5vNQoX for ; Tue, 3 Sep 2013 07:42:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43C21E80B9 for ; Tue, 3 Sep 2013 07:42:10 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id E0C57360128; Tue, 3 Sep 2013 16:42:09 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id B2A75C8056; Tue, 3 Sep 2013 16:42:09 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 3 Sep 2013 16:42:09 +0200 From: To: AshwoodsmithPeter Date: Tue, 3 Sep 2013 16:42:08 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQ Message-ID: <10651_1378219329_5225F541_10651_1240_6_EEE55384044474429A926C625D0FCC810962D1E704@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> In-Reply-To: <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 X-Mailman-Approved-At: Tue, 03 Sep 2013 08:12:31 -0700 Cc: John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , "Alvaro Retana \(aretana\)" , Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 14:42:15 -0000 There was a misunderstanding in my small comment :) so I will explain more : In segment routing, you have more than basic source routing : segment routi= ng is just associate a segment number to an action and then combine segment= as you want, yes you can do source routing, but you also can do more. In the other hand, I completely agree with your statement that source routi= ng is generic and dataplane agnostic, as segment routing is ... (segment ro= uting is not a new dataplane ...) Now the definition of the WG naming must be inline with the charter that wi= ll be defined ... (draft today) =20 Based on the already existing consensus (at least for MPLS dataplane) broug= ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good= target candidate. So now, do we want to do more in the WG charter than just make progressing = segment routing architecture and uses cases document and ensure coordinatio= n for the standardization of this technology ? =20 Do we want to standardize other technologies in this WG ? I don't think so,= based on Stewart's conclusion email from the BOF :"A new WG focused solely= on SR therefore needs to be create" If the WG charter is limited to source routing, how will we handle the "non= source routing" use cases of segment routing ? In another working group ? = So we will go back to the WG synchronization issue that has been raised for= this technology ... If the WG is focused on SR, let's use a name in relation with SR. Feedback ? Stephane -----Message d'origine----- De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com]=20 Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg= l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.or= g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps The term "source routing" has been around for a very long time and is data = path agnostic. Its also the term used in the literature etc so my preferenc= e is to stick with this existing well known and data path agnostic term. Peter On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > Hi, >=20 > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la=20 > part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark= =20 > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G.=20 > Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org;=20 > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20 > and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'.=20 >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20 >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >>=20 >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>=20 >>> All, >>>=20 >>> I would also favour "Segment Routing WG" as well. >>>=20 >>> I note this since attempting to come up with an all encompassing=20 >>> acronym will be difficult and Segment Routing is generic enough to=20 >>> associate to multiple functions. >>=20 >> Then we can just use "segroute" for the short name. WGs do not have=20 >> to have acronyms, but they do need to have an 8-char limited short=20 >> name for the various automated tools not to break. >>=20 >> - Mark >>=20 >>>=20 >>> Regards, >>>=20 >>> Victor K >>>=20 >>>=20 >>>=20 >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20 >>> >>> wrote: >>>=20 >>>> +1 for Segment Routing WG >>>>=20 >>>> Roberta >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>>=20 >>>>> Segment Routing WG >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>>=20 >>>>>> The second task, which hopefully should be relatively easy, is to=20 >>>>>> find a better working name for the WG, since it has been put to=20 >>>>>> me a number of times that STATUS is going to be confusing in text=20 >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From Peter.AshwoodSmith@huawei.com Tue Sep 3 08:14:59 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8545511E81F4 for ; Tue, 3 Sep 2013 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3FPsOZnXW8X for ; Tue, 3 Sep 2013 08:14:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB19021E8127 for ; Tue, 3 Sep 2013 08:14:54 -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.5-GA FastPath queued) with ESMTP id AWW13536; Tue, 03 Sep 2013 15:14:39 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 16:13:56 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 16:14:07 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 08:14:02 -0700 From: AshwoodsmithPeter To: "bruno.decraene@orange.com" , "Ruediger.Geib@telekom.de" , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwCAAAdgAIAAA1UAgAAMeID//4wQUA== Date: Tue, 3 Sep 2013 15:14:02 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E3852@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <5225E50E.3020100@cisco.com> <725_1378218575_5225F24F_725_18465_1_53C29892C857584299CBF5D05346208A070591C5@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <725_1378218575_5225F24F_725_18465_1_53C29892C857584299CBF5D05346208A070591C5@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.231] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:14:59 -0000 Roughly speaking we have three well known transit behaviors for packet forw= arding which can be added recursively at various boundaries. Hop-by-hop =3D> out interface =3D F(packet.destination) Label-substitution =3D> out interface =3D F(incoming port, packet.label) Source routing =3D> out interface =3D packet.hop[packet.nexthop++] These terms have all been used independently of the underlying data planes,= eg IP, Ethernet, ATM, MPLS, etc. for nearly 20 years. Segment routing is the use of recursive label-substitution to implement sou= rce routing like behavior because there is no packet.nexthop++ operation in= existing MPLS hardware, so it does not seem agnostic of MPLS which was one= of the stated goals of the charter. Not to say it's not a great thing to do and very useful, but terminology wi= se I don't think it meets the stated agnostic requirement.=20 Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= bruno.decraene@orange.com Sent: Tuesday, September 03, 2013 10:30 AM To: Ruediger.Geib@telekom.de; status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps +1 Regarding the MPLS dataplane, it's mostly about using the IGP as the (intra= AS) label distribution protocol for both SPT and 1 hop LSP. Then this allo= ws for easier stacking of LSP/segments as any LSR knows all the LSP/segment= s of the AS, which can then be used for different use cases as presented du= ring the BOF. This is not source routing from the source of the IP packet. Regards, Bruno >From: Ruediger.Geib@telekom.de > >Stewart, > >to name a WG "Source Routing WG" just because it allows a more organised w= ay >of exploiting features of an MPLS network, and that limited to paths and >routers where an operator desires to utlise these features doesn't seem to >be a good idea. > >Segment Routing describes what the company I work for will be using it. We >don't intend to operate a source routed network. It's an enhancement as >compared to LDP based MPLS. > >Regards, > >Ruediger > >-----Original Message----- >From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf O= f >Stewart Bryant >Sent: Tuesday, September 03, 2013 3:33 PM >To: stephane.litkowski@orange.com >Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione >(robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >status@ietf.org >Subject: Re: [Status] Summary of STATUS BOF and the next steps > >Stephane > >That is not correct. A long time ago there was source routed transparent >which was a token ring technology. > >Stewart > >On 03/09/2013 14:06, stephane.litkowski@orange.com wrote: >> Hi, >> >> "Source routing" is just a subcase of segment routing ... as it is for I= P >routing ... >> >> Stephane >> >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part >de John E Drake >> Envoy=E9 : mardi 3 septembre 2013 15:02 >> =C0 : Mark Townsley; Victor Kuarsingh >> Cc : Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana)= ; >Adrian Farrel; status@ietf.org; Stewart Bryant (stbryant) >> Objet : Re: [Status] Summary of STATUS BOF and the next steps >> >> Hi, >> >> What is this 'segment routing' silliness? The correct term is 'source >routing'. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of Mark Townsley >>> Sent: Sunday, September 01, 2013 10:08 AM >>> To: Victor Kuarsingh >>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>> >>>> All, >>>> >>>> I would also favour "Segment Routing WG" as well. >>>> >>>> I note this since attempting to come up with an all encompassing >>>> acronym will be difficult and Segment Routing is generic enough to >>>> associate to multiple functions. >>> Then we can just use "segroute" for the short name. WGs do not have to >>> have acronyms, but they do need to have an 8-char limited short name >>> for the various automated tools not to break. >>> >>> - Mark >>> >>>> Regards, >>>> >>>> Victor K >>>> >>>> >>>> >>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>> >>>> wrote: >>>> >>>>> +1 for Segment Routing WG >>>>> >>>>> Roberta >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>> >>>>> wrote: >>>>> >>>>>> Segment Routing WG >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>> wrote: >>>>>> >>>>>>> The second task, which hopefully should be relatively easy, is to >>>>>>> find a better working name for the WG, since it has been put to >>>>>>> me a number of times that STATUS is going to be confusing in text >>>>>>> and a difficult search term. >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> >__________________________________________________________________________= __ >_____________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou >falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en >modified, changed or falsified. >> Thank you. >> >> . >> > > >-- >For corporate legal information go to: > >http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From Peter.AshwoodSmith@huawei.com Tue Sep 3 08:22:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1147821E8120 for ; Tue, 3 Sep 2013 08:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7I4DjIG5lR1 for ; Tue, 3 Sep 2013 08:22:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6839921E811E for ; Tue, 3 Sep 2013 08:22:37 -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.5-GA FastPath queued) with ESMTP id AWW14198; Tue, 03 Sep 2013 15:22:36 +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.146.0; Tue, 3 Sep 2013 16:22:11 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 16:22:24 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Tue, 3 Sep 2013 08:22:17 -0700 From: AshwoodsmithPeter To: "stephane.litkowski@orange.com" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAAmx0A== Date: Tue, 3 Sep 2013 15:22:17 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.231] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:22:49 -0000 " If the WG charter is limited to source routing, how will we handle the "n= on source routing" use cases of segment routing ? In another working group = ? So we will go back to the WG synchronization issue that has been raised f= or this technology ..." That's why I suggested SRV2. We are revisiting source routing with new conc= epts. More generic number/action behavior.=20 Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= stephane.litkowski@orange.com Sent: Tuesday, September 03, 2013 10:43 AM To: AshwoodsmithPeter Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps =20 There was a misunderstanding in my small comment :) so I will explain more = : In segment routing, you have more than basic source routing : segment routi= ng is just associate a segment number to an action and then combine segment= as you want, yes you can do source routing, but you also can do more. In the other hand, I completely agree with your statement that source routi= ng is generic and dataplane agnostic, as segment routing is ... (segment ro= uting is not a new dataplane ...) Now the definition of the WG naming must be inline with the charter that wi= ll be defined ... (draft today) =20 Based on the already existing consensus (at least for MPLS dataplane) broug= ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good= target candidate. So now, do we want to do more in the WG charter than just make progressing = segment routing architecture and uses cases document and ensure coordinatio= n for the standardization of this technology ? =20 Do we want to standardize other technologies in this WG ? I don't think so,= based on Stewart's conclusion email from the BOF :"A new WG focused solely= on SR therefore needs to be create" If the WG charter is limited to source routing, how will we handle the "non= source routing" use cases of segment routing ? In another working group ? = So we will go back to the WG synchronization issue that has been raised for= this technology ... If the WG is focused on SR, let's use a name in relation with SR. Feedback ? Stephane -----Message d'origine----- De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg= l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.or= g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and= the next steps The term "source routing" has been around for a very long time and is data = path agnostic. Its also the term used in the literature etc so my preferenc= e is to stick with this existing well known and data path agnostic term. Peter On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > Hi, >=20 > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la=20 > part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark=20 > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. > Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org;=20 > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20 > and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'.=20 >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20 >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >>=20 >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>=20 >>> All, >>>=20 >>> I would also favour "Segment Routing WG" as well. >>>=20 >>> I note this since attempting to come up with an all encompassing=20 >>> acronym will be difficult and Segment Routing is generic enough to=20 >>> associate to multiple functions. >>=20 >> Then we can just use "segroute" for the short name. WGs do not have=20 >> to have acronyms, but they do need to have an 8-char limited short=20 >> name for the various automated tools not to break. >>=20 >> - Mark >>=20 >>>=20 >>> Regards, >>>=20 >>> Victor K >>>=20 >>>=20 >>>=20 >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20 >>> >>> wrote: >>>=20 >>>> +1 for Segment Routing WG >>>>=20 >>>> Roberta >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>>=20 >>>>> Segment Routing WG >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>>=20 >>>>>> The second task, which hopefully should be relatively easy, is to=20 >>>>>> find a better working name for the WG, since it has been put to=20 >>>>>> me a number of times that STATUS is going to be confusing in text=20 >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From loa@pi.nu Tue Sep 3 08:31:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D8321E8143 for ; Tue, 3 Sep 2013 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz2iKBxWfIHK for ; Tue, 3 Sep 2013 08:31:44 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27121F9C3A for ; Tue, 3 Sep 2013 08:31:44 -0700 (PDT) Received: from [192.168.5.60] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C8D1E18033E4 for ; Tue, 3 Sep 2013 17:31:42 +0200 (CEST) Message-ID: <522600E0.8050004@pi.nu> Date: Tue, 03 Sep 2013 17:31:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: status@ietf.org References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:31:49 -0000 Folks, Excuse me if I'm slightly out of the loop, but so far I have not seen a charter proposal, if there is one please point me to it. It seems a bit odd to put the cart (what the wg should do) before the horse (wg name). If we drill down the the charter first the wg name might be easier to figure out. /Loa PS OK I understand that the horse and cart analogy limps a bit :). On 2013-09-03 17:22, AshwoodsmithPeter wrote: > " If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ..." > > That's why I suggested SRV2. We are revisiting source routing with new concepts. More generic number/action behavior. > > Peter > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com > Sent: Tuesday, September 03, 2013 10:43 AM > To: AshwoodsmithPeter > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > > There was a misunderstanding in my small comment :) so I will explain more : > > In segment routing, you have more than basic source routing : segment routing is just associate a segment number to an action and then combine segment as you want, yes you can do source routing, but you also can do more. > > In the other hand, I completely agree with your statement that source routing is generic and dataplane agnostic, as segment routing is ... (segment routing is not a new dataplane ...) > > Now the definition of the WG naming must be inline with the charter that will be defined ... (draft today) > > Based on the already existing consensus (at least for MPLS dataplane) brought up during Berlin STATUS BOF meeting, segment routing sounds to be a good target candidate. > > So now, do we want to do more in the WG charter than just make progressing segment routing architecture and uses cases document and ensure coordination for the standardization of this technology ? > > Do we want to standardize other technologies in this WG ? I don't think so, based on Stewart's conclusion email from the BOF :"A new WG focused solely on SR therefore needs to be create" > > If the WG charter is limited to source routing, how will we handle the "non source routing" use cases of segment routing ? In another working group ? So we will go back to the WG synchronization issue that has been raised for this technology ... > > If the WG is focused on SR, let's use a name in relation with SR. > > Feedback ? > > > Stephane > > > -----Message d'origine----- > De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] > Envoyé : mardi 3 septembre 2013 15:27 > À : LITKOWSKI Stephane DTF/DERX > Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and the next steps > > The term "source routing" has been around for a very long time and is data path agnostic. Its also the term used in the literature etc so my preference is to stick with this existing well known and data path agnostic term. > > Peter > > On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > >> Hi, >> >> "Source routing" is just a subcase of segment routing ... as it is for IP routing ... >> >> Stephane >> >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >> part de John E Drake Envoyé : mardi 3 septembre 2013 15:02 À : Mark >> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF >> and the next steps >> >> Hi, >> >> What is this 'segment routing' silliness? The correct term is 'source routing'. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of Mark Townsley >>> Sent: Sunday, September 01, 2013 10:08 AM >>> To: Victor Kuarsingh >>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>> >>>> All, >>>> >>>> I would also favour "Segment Routing WG" as well. >>>> >>>> I note this since attempting to come up with an all encompassing >>>> acronym will be difficult and Segment Routing is generic enough to >>>> associate to multiple functions. >>> >>> Then we can just use "segroute" for the short name. WGs do not have >>> to have acronyms, but they do need to have an 8-char limited short >>> name for the various automated tools not to break. >>> >>> - Mark >>> >>>> >>>> Regards, >>>> >>>> Victor K >>>> >>>> >>>> >>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>> >>>> wrote: >>>> >>>>> +1 for Segment Routing WG >>>>> >>>>> Roberta >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>> >>>>> wrote: >>>>> >>>>>> Segment Routing WG >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>> wrote: >>>>>> >>>>>>> The second task, which hopefully should be relatively easy, is to >>>>>>> find a better working name for the WG, since it has been put to >>>>>>> me a number of times that STATUS is going to be confusing in text >>>>>>> and a difficult search term. >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stephane.litkowski@orange.com Tue Sep 3 08:33:04 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF3A21F9CCC for ; Tue, 3 Sep 2013 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be9H380U968x for ; Tue, 3 Sep 2013 08:33:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id B6F4521F9AA8 for ; Tue, 3 Sep 2013 08:32:59 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 425F01B8E7E; Tue, 3 Sep 2013 17:32:58 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1EC4B15804E; Tue, 3 Sep 2013 17:32:58 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 3 Sep 2013 17:32:58 +0200 From: To: Loa Andersson , "status@ietf.org" Date: Tue, 3 Sep 2013 17:32:56 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6ouri5sm3TsPO1TH+awCr/7IpSzQAAB6oQ Message-ID: <26855_1378222378_5226012A_26855_2334_1_EEE55384044474429A926C625D0FCC810962D1E78B@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> In-Reply-To: <522600E0.8050004@pi.nu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.3.102415 Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:33:04 -0000 +1 ! =20 -----Message d'origine----- De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de= Loa Andersson Envoy=E9 : mardi 3 septembre 2013 17:32 =C0 : status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the next steps Folks, Excuse me if I'm slightly out of the loop, but so far I have not seen a cha= rter proposal, if there is one please point me to it. It seems a bit odd to put the cart (what the wg should do) before the horse= (wg name). If we drill down the the charter first the wg name might be eas= ier to figure out. /Loa PS OK I understand that the horse and cart analogy limps a bit :). On 2013-09-03 17:22, AshwoodsmithPeter wrote: > " If the WG charter is limited to source routing, how will we handle the = "non source routing" use cases of segment routing ? In another working grou= p ? So we will go back to the WG synchronization issue that has been raised= for this technology ..." > > That's why I suggested SRV2. We are revisiting source routing with new co= ncepts. More generic number/action behavior. > > Peter > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 > Behalf Of stephane.litkowski@orange.com > Sent: Tuesday, September 03, 2013 10:43 AM > To: AshwoodsmithPeter > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > > There was a misunderstanding in my small comment :) so I will explain mor= e : > > In segment routing, you have more than basic source routing : segment rou= ting is just associate a segment number to an action and then combine segme= nt as you want, yes you can do source routing, but you also can do more. > > In the other hand, I completely agree with your statement that source=20 > routing is generic and dataplane agnostic, as segment routing is ...=20 > (segment routing is not a new dataplane ...) > > Now the definition of the WG naming must be inline with the charter=20 > that will be defined ... (draft today) > > Based on the already existing consensus (at least for MPLS dataplane) bro= ught up during Berlin STATUS BOF meeting, segment routing sounds to be a go= od target candidate. > > So now, do we want to do more in the WG charter than just make progressin= g segment routing architecture and uses cases document and ensure coordinat= ion for the standardization of this technology ? > > Do we want to standardize other technologies in this WG ? I don't think s= o, based on Stewart's conclusion email from the BOF :"A new WG focused sole= ly on SR therefore needs to be create" > > If the WG charter is limited to source routing, how will we handle the "n= on source routing" use cases of segment routing ? In another working group = ? So we will go back to the WG synchronization issue that has been raised f= or this technology ... > > If the WG is focused on SR, let's use a name in relation with SR. > > Feedback ? > > > Stephane > > > -----Message d'origine----- > De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] > Envoy=E9 : mardi 3 septembre 2013 15:27 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione=20 > (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana);=20 > status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status]=20 > Summary of STATUS BOF and the next steps > > The term "source routing" has been around for a very long time and is dat= a path agnostic. Its also the term used in the literature etc so my prefere= nce is to stick with this existing well known and data path agnostic term. > > Peter > > On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > >> Hi, >> >> "Source routing" is just a subcase of segment routing ... as it is for I= P routing ... >> >> Stephane >> >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la=20 >> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark= =20 >> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org;=20 >> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20 >> and the next steps >> >> Hi, >> >> What is this 'segment routing' silliness? The correct term is 'source r= outing'. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >>> Behalf Of Mark Townsley >>> Sent: Sunday, September 01, 2013 10:08 AM >>> To: Victor Kuarsingh >>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel;=20 >>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>> >>>> All, >>>> >>>> I would also favour "Segment Routing WG" as well. >>>> >>>> I note this since attempting to come up with an all encompassing=20 >>>> acronym will be difficult and Segment Routing is generic enough to=20 >>>> associate to multiple functions. >>> >>> Then we can just use "segroute" for the short name. WGs do not have=20 >>> to have acronyms, but they do need to have an 8-char limited short=20 >>> name for the various automated tools not to break. >>> >>> - Mark >>> >>>> >>>> Regards, >>>> >>>> Victor K >>>> >>>> >>>> >>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>> >>>> wrote: >>>> >>>>> +1 for Segment Routing WG >>>>> >>>>> Roberta >>>>> >>>>> Sent from my iPad >>>>> >>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>> >>>>> wrote: >>>>> >>>>>> Segment Routing WG >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>> wrote: >>>>>> >>>>>>> The second task, which hopefully should be relatively easy, is=20 >>>>>>> to find a better working name for the WG, since it has been put=20 >>>>>>> to me a number of times that STATUS is going to be confusing in=20 >>>>>>> text and a difficult search term. >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jnc@mercury.lcs.mit.edu Tue Sep 3 08:35:50 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F321E814E for ; Tue, 3 Sep 2013 08:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CroFF6-ORdym for ; Tue, 3 Sep 2013 08:35:41 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 397A221E8176 for ; Tue, 3 Sep 2013 08:35:41 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BD19618C1B8; Tue, 3 Sep 2013 11:35:38 -0400 (EDT) To: status@ietf.org Message-Id: <20130903153538.BD19618C1B8@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 11:35:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:35:51 -0000 > From: AshwoodsmithPeter > We are revisiting source routing with new concepts. The problem is that "source routing" seems, by the time you do the set-or of all the various meanings that people apply to it, to basically mean "not hop-by-hop routing". The problem, therefore, with calling something "source routing" is that it's like me calling myself "Not Peter Ashwood-Smith". The problem is that there are a lot of people whose name is "Not Peter Ashwood-Smith", so it's really a pretty useless name. Similarly, saying that something is "source routing" really tells you very little about it - except that it's not hop-by-hop. So let's find a different, and actually meaningful, name. Noel From aretana@cisco.com Tue Sep 3 09:11:43 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5243321F9E8B for ; Tue, 3 Sep 2013 09:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJhx0Ei0AFWv for ; Tue, 3 Sep 2013 09:11:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C981A21F9E5C for ; Tue, 3 Sep 2013 09:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2078; q=dns/txt; s=iport; t=1378224694; x=1379434294; h=from:to:subject:date:message-id:mime-version; bh=xiNvkvgR3OhcvfCVLixU9uoI3mNiuKuFPR9mYX00SHI=; b=MICDpAyZPS0UrVUpJ5mvOdbb0aas9BeLvWhgpKUeAyBAS36WR9raZPnJ Kdr0iTbso3HCuQqPB2jnDFVtdSyv1+igxUw7z4elZ9V4YyaUuad/X2zle wyCxPn1BfOh/do3jolNkYVU/htYRDOAFAPjC5jnCkAs9umcJmgLwXxkIJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAOcJJlKtJV2a/2dsb2JhbABbgkNEgQbAdYEsFm0HghsLAQSBCwELAR5WJwQbh3qYdKAij0WDVYEAA6lbgyCCKg X-IronPort-AV: E=Sophos;i="4.89,1015,1367971200"; d="scan'208,217";a="255036325" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 03 Sep 2013 16:11:33 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r83GBXT5027813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Sep 2013 16:11:33 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.182]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 11:11:33 -0500 From: "Alvaro Retana (aretana)" To: "status@ietf.org" Thread-Topic: "Too many recipients to the message" Thread-Index: AQHOqMBBJySSdn3tx0KaEJkzLlcKrg== Date: Tue, 3 Sep 2013 16:11:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.211.150] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_" MIME-Version: 1.0 Subject: [Status] "Too many recipients to the message" X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 16:11:43 -0000 --_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We've been getting messages held by mailman because they are sent to "too m= any recipients" (and, I guess, the system thinks they might be spam). I th= ink the queue has now been cleared. The discussion on the "Summary of STATUS BOF.." thread has gathered a lot o= f interest which is why the list of recipients has grown. While the partic= ipation/interest is great, please do everyone a favor and edit the list of = recipients to the min (the person you're replying to and the list). Thanks! Alvaro. Listed as one of the owners of the status list.. --_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

We've been getting messages held by mailman because they are sent to &= quot;too many recipients" (and, I guess, the system thinks they might = be spam).  I think the queue has now been cleared.

The discussion on the "Summary of STATUS BOF.." thread has g= athered a lot of interest which is why the list of recipients has grown. &n= bsp;While the participation/interest is great, please do everyone a favor a= nd edit the list of recipients to the min (the person you're replying to and the list).

Thanks!

Alvaro.
Listed as one of the owners of the status list..
--_000_BBD66FD99311804F80324E8139B3C94E29068EE5xmbalnx15ciscoc_-- From hannes@juniper.net Tue Sep 3 09:31:13 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1585411E81CB for ; Tue, 3 Sep 2013 09:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enFWqLvOqgTc for ; Tue, 3 Sep 2013 09:31:07 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED711E81B7 for ; Tue, 3 Sep 2013 09:31:07 -0700 (PDT) Received: from mail192-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 16:31:06 +0000 Received: from mail192-co1 (localhost [127.0.0.1]) by mail192-co1-R.bigfish.com (Postfix) with ESMTP id A3BAA9800A5; Tue, 3 Sep 2013 16:31:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -70 X-BigFish: VPS-70(z551biz62a3I98dI9371Ic89bh936eI542I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail192-co1: domain of juniper.net designates 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=hannes@juniper.net; helo=BN1PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail192-co1 (localhost.localdomain [127.0.0.1]) by mail192-co1 (MessageSwitch) id 1378225864606395_21192; Tue, 3 Sep 2013 16:31:04 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.226]) by mail192-co1.bigfish.com (Postfix) with ESMTP id 86F3314004B; Tue, 3 Sep 2013 16:31:04 +0000 (UTC) Received: from BN1PRD0512HT001.namprd05.prod.outlook.com (132.245.2.21) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 16:31:03 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.193.34) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 16:30:59 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <522600E0.8050004@pi.nu> Date: Tue, 3 Sep 2013 18:30:56 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 16:31:13 -0000 good point - what about this charter proposal ? --- Stacked Tunnels for Explicit Routing (STER)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A explicit routing domain (ERD) contains a set of routers with the = following characteristics: - They form a connected network - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in = the ERD. It can then send any packet that passes through it through any = path that it has specified. Downstream routers within the ERD forward = the packet as specified by the router at the head-end of the path. The STER working group is chartered for the following ordered list of = work items: - The first goal of the STER WG is to identify use-cases for ERDs.=20 - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements.=20 - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified.=20 Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. --- /hannes On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: > Folks, >=20 > Excuse me if I'm slightly out of the loop, but so far I have not seen = a > charter proposal, if there is one please point me to it. >=20 > It seems a bit odd to put the cart (what the wg should do) before the > horse (wg name). If we drill down the the charter first the wg name > might be easier to figure out. >=20 > /Loa >=20 > PS > OK I understand that the horse and cart analogy limps a bit :). >=20 >=20 >=20 > On 2013-09-03 17:22, AshwoodsmithPeter wrote: >> " If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ..." >>=20 >> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>=20 >> Peter >>=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On = Behalf Of stephane.litkowski@orange.com >> Sent: Tuesday, September 03, 2013 10:43 AM >> To: AshwoodsmithPeter >> Cc: status@ietf.org >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >>=20 >> There was a misunderstanding in my small comment :) so I will explain = more : >>=20 >> In segment routing, you have more than basic source routing : segment = routing is just associate a segment number to an action and then combine = segment as you want, yes you can do source routing, but you also can do = more. >>=20 >> In the other hand, I completely agree with your statement that source = routing is generic and dataplane agnostic, as segment routing is ... = (segment routing is not a new dataplane ...) >>=20 >> Now the definition of the WG naming must be inline with the charter = that will be defined ... (draft today) >>=20 >> Based on the already existing consensus (at least for MPLS dataplane) = brought up during Berlin STATUS BOF meeting, segment routing sounds to = be a good target candidate. >>=20 >> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>=20 >> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>=20 >> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>=20 >> If the WG is focused on SR, let's use a name in relation with SR. >>=20 >> Feedback ? >>=20 >>=20 >> Stephane >>=20 >>=20 >> -----Message d'origine----- >> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >> Envoy=E9 : mardi 3 septembre 2013 15:27 >> =C0 : LITKOWSKI Stephane DTF/DERX >> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione = (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); = status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] Summary = of STATUS BOF and the next steps >>=20 >> The term "source routing" has been around for a very long time and is = data path agnostic. Its also the term used in the literature etc so my = preference is to stick with this existing well known and data path = agnostic term. >>=20 >> Peter >>=20 >> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>=20 >>> Hi, >>>=20 >>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>=20 >>> Stephane >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF >>> and the next steps >>>=20 >>> Hi, >>>=20 >>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>=20 >>> Yours Irrespectively, >>>=20 >>> John >>>=20 >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of Mark Townsley >>>> Sent: Sunday, September 01, 2013 10:08 AM >>>> To: Victor Kuarsingh >>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; = Alvaro >>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>>=20 >>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> I would also favour "Segment Routing WG" as well. >>>>>=20 >>>>> I note this since attempting to come up with an all encompassing >>>>> acronym will be difficult and Segment Routing is generic enough to >>>>> associate to multiple functions. >>>>=20 >>>> Then we can just use "segroute" for the short name. WGs do not have >>>> to have acronyms, but they do need to have an 8-char limited short >>>> name for the various automated tools not to break. >>>>=20 >>>> - Mark >>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Victor K >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>> >>>>> wrote: >>>>>=20 >>>>>> +1 for Segment Routing WG >>>>>>=20 >>>>>> Roberta >>>>>>=20 >>>>>> Sent from my iPad >>>>>>=20 >>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> Segment Routing WG >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> The second task, which hopefully should be relatively easy, is = to >>>>>>>> find a better working name for the WG, since it has been put to >>>>>>>> me a number of times that STATUS is going to be confusing in = text >>>>>>>> and a difficult search term. >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 From mark@townsley.net Tue Sep 3 09:48:12 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C79121E8185 for ; Tue, 3 Sep 2013 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju3M2rosNKVl for ; Tue, 3 Sep 2013 09:48:07 -0700 (PDT) Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E821E817C for ; Tue, 3 Sep 2013 09:48:06 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id n15so3133321ead.30 for ; Tue, 03 Sep 2013 09:47:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=G9i8/qo5xi7Z98Ng/7p6dnkcpln34hf+BZLxYyULjS0=; b=EPIu9AUn3+GCeVR+3+l/M/b3WAj3fo4MeVonCMbIyq1kWgoMUnsVcPzomvBJQt0g4V VN1P12xwdhEGWOtPaF/STZYcFQBYyRUEEVKevjBE6LY5wv61mAG8MAeWffuhEOEcIVMt UsAuW5tTdHzHHOfNo89UIMjltsvtSJG6Utxn6drGPndRGL+VmD74CK4quUNf+Lc2f916 8HeTAbw2FRP4zuuK070FQRAvGwVO1qVQe8T3BwMQ7Xyffs5HdD0DrEfORKygSsxP3qhb aSAfQIRk53X7nZdBzEODr0BMxBKYV/dAuz0/hH+/Q+O8cK0l3/7oPCcH4exigupZfhPQ Z5xw== X-Gm-Message-State: ALoCoQnFLQcv6vYACRf3k0VdiRYNTy6Jj3DV9sHKQV1FTLpOiY+mPzmOnJcBdpixDN29CzrsTPsU X-Received: by 10.14.184.3 with SMTP id r3mr6345533eem.49.1378226869787; Tue, 03 Sep 2013 09:47:49 -0700 (PDT) Received: from ams-townsley-8913.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id f49sm32932097eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 09:47:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Mark Townsley In-Reply-To: <20130903153538.BD19618C1B8@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 18:47:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130903153538.BD19618C1B8@mercury.lcs.mit.edu> To: status@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 16:48:12 -0000 For those who might not be aware, the homenet WG has been actively = working on "source and destination routing" (SADR) techniques to solve = the routing problem facing a multi-router, multi-homed, multi-prefix, = IPv6 home network: A few refs: draft-troan-homenet-sadr draft-baker-ipv6-ospf-dst-src-routing draft-baker-ipv6-isis-dst-src-routing draft-boutier-homenet-source-specific-routing draft-baker-rtgwg-src-dst-routing-use-cases We're working with the ADs on where to advance this, including the = possibility of the rtgwg (hence baker's rtgwg document listed above). = Whatever ends up coming out of homenet, rtgwg, and the WG that is = forming here, we should aim to be very clear what is what.=20 - Mark P.S. Another ref, just for kicks: = http://www.youtube.com/watch?v=3D3Omg1lJ6EQI On Sep 3, 2013, at 5:35 PM, Noel Chiappa wrote: >> From: AshwoodsmithPeter >=20 >> We are revisiting source routing with new concepts.=20 >=20 > The problem is that "source routing" seems, by the time you do the = set-or of > all the various meanings that people apply to it, to basically mean = "not > hop-by-hop routing". >=20 > The problem, therefore, with calling something "source routing" is = that it's > like me calling myself "Not Peter Ashwood-Smith". The problem is that = there > are a lot of people whose name is "Not Peter Ashwood-Smith", so it's = really a > pretty useless name. >=20 > Similarly, saying that something is "source routing" really tells you = very > little about it - except that it's not hop-by-hop. So let's find a = different, > and actually meaningful, name. >=20 > Noel > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From jnc@mercury.lcs.mit.edu Tue Sep 3 09:54:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AED11E81E3 for ; Tue, 3 Sep 2013 09:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGGEFzt3pUXu for ; Tue, 3 Sep 2013 09:54:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7776C11E81F4 for ; Tue, 3 Sep 2013 09:54:24 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EF43C18C12F; Tue, 3 Sep 2013 12:54:18 -0400 (EDT) To: status@ietf.org Message-Id: <20130903165418.EF43C18C12F@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 12:54:18 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 16:54:35 -0000 > From: Hannes Gredler > what about this charter proposal ? It looks like a good start to me, but one thing: > Stacked Tunnels for Explicit Routing (STER) I actually like the name "segment routing". For one, it's a new term, so it doesn't have any existing (overloaded) meaning. For another, I find the 'ST' part of 'STER' a bit misleading because an ERD might not be using a tunnel (as I normally think of it, which involves 'IPvN in IPvN encapsulation' or 'L2 in IPvN encapsulation', or something like that) to specify a path across itself; it might be using an MPLS path, for instance (which I don't consider a tunnel). 'Segment routing' seems to me to capture the essence of what's going on; at certain points along the overall path, an explicit route is picked for the next segment of the overall path; hence, my liking for it. I have no objection to using the term 'explicit routing' along with 'segment', so combinations like 'segment routing with explicit path sections', etc, would all be fine with me too, although I don't have a perfect suggested name to suggest. Noel From jdrake@juniper.net Tue Sep 3 10:02:26 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930A011E8106 for ; Tue, 3 Sep 2013 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mM3Ty27Htxs for ; Tue, 3 Sep 2013 10:02:21 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE111E8109 for ; Tue, 3 Sep 2013 10:02:19 -0700 (PDT) Received: from mail115-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 17:02:18 +0000 Received: from mail115-ch1 (localhost [127.0.0.1]) by mail115-ch1-R.bigfish.com (Postfix) with ESMTP id 660F72000DE; Tue, 3 Sep 2013 17:02:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -73 X-BigFish: VPS-73(z551biz62a3I98dI9371Ic89bh936eI542I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail115-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(55784002)(13464003)(24454002)(51704005)(189002)(199002)(377424004)(377454003)(252514010)(47446002)(74502001)(561944002)(31966008)(76796001)(74662001)(76576001)(76786001)(77982001)(59766001)(79102001)(54356001)(81686001)(33646001)(65816001)(74706001)(66066001)(74876001)(80022001)(77096001)(56816003)(69226001)(19580395003)(74366001)(4396001)(81542001)(74316001)(50986001)(47976001)(51856001)(83072001)(46102001)(63696002)(80976001)(76482001)(54316002)(81816001)(53806001)(56776001)(15975445006)(49866001)(47736001)(81342001)(19580405001)(83322001)(1941001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB254; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail115-ch1 (localhost.localdomain [127.0.0.1]) by mail115-ch1 (MessageSwitch) id 1378227736271597_9689; Tue, 3 Sep 2013 17:02:16 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail115-ch1.bigfish.com (Postfix) with ESMTP id 334F01E0041; Tue, 3 Sep 2013 17:02:16 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 17:02:14 +0000 Received: from BY2PR05MB254.namprd05.prod.outlook.com (10.242.41.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 17:02:13 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB254.namprd05.prod.outlook.com (10.242.41.152) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 17:02:10 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 17:02:10 +0000 From: John E Drake To: Hannes Gredler , Loa Andersson Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqNMppxiDdAEC+H+M4LHfrLJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAAsHgIAAAqQAgAAQiwCAAAWuoA== Date: Tue, 3 Sep 2013 17:02:09 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> In-Reply-To: <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 17:02:26 -0000 Hannes, This is the precisely the terminology that I used in my Berlin presentation= and the charter statement seems fine. Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of Hannes Gredler > Sent: Tuesday, September 03, 2013 9:31 AM > To: Loa Andersson > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > good point - what about this charter proposal ? >=20 > --- >=20 > Stacked Tunnels for Explicit Routing (STER) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > A explicit routing domain (ERD) contains a set of routers with the follow= ing > characteristics: >=20 > - They form a connected network > - They can forward traffic through the shortest paths or paths other than= the > shortest (the latter called explicitly routed paths, or explicit paths) > - They share a common trust model. In this model, any router within the E= RD > can specify an explicit path between itself and any other router in the E= RD. It > can then send any packet that passes through it through any path that it = has > specified. Downstream routers within the ERD forward the packet as > specified by the router at the head-end of the path. >=20 > The STER working group is chartered for the following ordered list of wor= k > items: >=20 > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y > available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls > or new protocols that address gaps that are identified. >=20 > Protocol work may be carried out in this working group or in other workin= g > groups responsible for the protocols, in coordination with this WG, and i= n > agreement with the WG chairs and responsible ADs. However, no protocol > work will be adopted by a working group to address the ERD use-cases unti= l > the requirements document motivating the protocol work has been sent to > the IESG for publication as an RFC. >=20 > --- >=20 > >=20 > /hannes >=20 >=20 > On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >=20 > > Folks, > > > > Excuse me if I'm slightly out of the loop, but so far I have not seen > > a charter proposal, if there is one please point me to it. > > > > It seems a bit odd to put the cart (what the wg should do) before the > > horse (wg name). If we drill down the the charter first the wg name > > might be easier to figure out. > > > > /Loa > > > > PS > > OK I understand that the horse and cart analogy limps a bit :). > > > > > > > > On 2013-09-03 17:22, AshwoodsmithPeter wrote: > >> " If the WG charter is limited to source routing, how will we handle t= he > "non source routing" use cases of segment routing ? In another working > group ? So we will go back to the WG synchronization issue that has been > raised for this technology ..." > >> > >> That's why I suggested SRV2. We are revisiting source routing with new > concepts. More generic number/action behavior. > >> > >> Peter > >> > >> -----Original Message----- > >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > >> Behalf Of stephane.litkowski@orange.com > >> Sent: Tuesday, September 03, 2013 10:43 AM > >> To: AshwoodsmithPeter > >> Cc: status@ietf.org > >> Subject: Re: [Status] Summary of STATUS BOF and the next steps > >> > >> > >> There was a misunderstanding in my small comment :) so I will explain > more : > >> > >> In segment routing, you have more than basic source routing : segment > routing is just associate a segment number to an action and then combine > segment as you want, yes you can do source routing, but you also can do > more. > >> > >> In the other hand, I completely agree with your statement that source > >> routing is generic and dataplane agnostic, as segment routing is ... > >> (segment routing is not a new dataplane ...) > >> > >> Now the definition of the WG naming must be inline with the charter > >> that will be defined ... (draft today) > >> > >> Based on the already existing consensus (at least for MPLS dataplane) > brought up during Berlin STATUS BOF meeting, segment routing sounds to be > a good target candidate. > >> > >> So now, do we want to do more in the WG charter than just make > progressing segment routing architecture and uses cases document and > ensure coordination for the standardization of this technology ? > >> > >> Do we want to standardize other technologies in this WG ? I don't thin= k > so, based on Stewart's conclusion email from the BOF :"A new WG focused > solely on SR therefore needs to be create" > >> > >> If the WG charter is limited to source routing, how will we handle the= "non > source routing" use cases of segment routing ? In another working group ? > So we will go back to the WG synchronization issue that has been raised f= or > this technology ... > >> > >> If the WG is focused on SR, let's use a name in relation with SR. > >> > >> Feedback ? > >> > >> > >> Stephane > >> > >> > >> -----Message d'origine----- > >> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] > >> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane > DTF/DERX > >> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione > >> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); > >> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] > >> Summary of STATUS BOF and the next steps > >> > >> The term "source routing" has been around for a very long time and is > data path agnostic. Its also the term used in the literature etc so my > preference is to stick with this existing well known and data path agnost= ic > term. > >> > >> Peter > >> > >> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" > wrote: > >> > >>> Hi, > >>> > >>> "Source routing" is just a subcase of segment routing ... as it is fo= r IP > routing ... > >>> > >>> Stephane > >>> > >>> > >>> -----Message d'origine----- > >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la > >>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Ma= rk > >>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. > >>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; > >>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF > >>> and the next steps > >>> > >>> Hi, > >>> > >>> What is this 'segment routing' silliness? The correct term is 'sourc= e > routing'. > >>> > >>> Yours Irrespectively, > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > >>>> Behalf Of Mark Townsley > >>>> Sent: Sunday, September 01, 2013 10:08 AM > >>>> To: Victor Kuarsingh > >>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; > >>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) > >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps > >>>> > >>>> > >>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: > >>>> > >>>>> All, > >>>>> > >>>>> I would also favour "Segment Routing WG" as well. > >>>>> > >>>>> I note this since attempting to come up with an all encompassing > >>>>> acronym will be difficult and Segment Routing is generic enough to > >>>>> associate to multiple functions. > >>>> > >>>> Then we can just use "segroute" for the short name. WGs do not have > >>>> to have acronyms, but they do need to have an 8-char limited short > >>>> name for the various automated tools not to break. > >>>> > >>>> - Mark > >>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Victor K > >>>>> > >>>>> > >>>>> > >>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" > >>>>> > >>>>> wrote: > >>>>> > >>>>>> +1 for Segment Routing WG > >>>>>> > >>>>>> Roberta > >>>>>> > >>>>>> Sent from my iPad > >>>>>> > >>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Segment Routing WG > >>>>>>> > >>>>>>> Sent from my iPhone > >>>>>>> > >>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > >>>>>>> wrote: > >>>>>>> > >>>>>>>> The second task, which hopefully should be relatively easy, is > >>>>>>>> to find a better working name for the WG, since it has been put > >>>>>>>> to me a number of times that STATUS is going to be confusing in > >>>>>>>> text and a difficult search term. > >>>>>>> _______________________________________________ > >>>>>>> status mailing list > >>>>>>> status@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/status > >>>>>> _______________________________________________ > >>>>>> status mailing list > >>>>>> status@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/status > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> status mailing list > >>>>> status@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/status > >>>> > >>>> _______________________________________________ > >>>> status mailing list > >>>> status@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/status > >>> > >>> > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >>> > >>> > __________________________________________________________ > __________ > >>> __ ___________________________________________________ > >>> > >>> Ce message et ses pieces jointes peuvent contenir des informations > >>> confidentielles ou privilegiees et ne doivent donc pas etre > >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu > >>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire > ainsi que les pieces jointes. Les messages electroniques etant susceptibl= es > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, > deforme ou falsifie. Merci. > >>> > >>> This message and its attachments may contain confidential or > >>> privileged information that may be protected by law; they should not = be > distributed, used or copied without authorisation. > >>> If you have received this email in error, please notify the sender an= d > delete this message and its attachments. > >>> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >>> Thank you. > >>> > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >> > >> > __________________________________________________________ > ___________ > >> ____________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not b= e > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >> Thank you. > >> > >> _______________________________________________ > >> status mailing list > >> status@ietf.org > >> https://www.ietf.org/mailman/listinfo/status > >> _______________________________________________ > >> status mailing list > >> status@ietf.org > >> https://www.ietf.org/mailman/listinfo/status > >> > > > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > > > >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 From cpignata@cisco.com Tue Sep 3 10:18:06 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131AE21E804B for ; Tue, 3 Sep 2013 10:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhbVXHvVtz+v for ; Tue, 3 Sep 2013 10:18:01 -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 7C26111E80F8 for ; Tue, 3 Sep 2013 10:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3245; q=dns/txt; s=iport; t=1378228681; x=1379438281; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C1UiX8q01VdKsdJ+86Pb1ganwdbpohjCcQpbPIQjXcs=; b=ShJN7hHJ4YDbVI+kCornRwrMuWwx9LVTwUl/i7yIkm9mE2spDTNug3Qz VNcCBUVY7T6h6x1JZvkB7ZbtNhGA4CzPqqP7C4yRa0LqHN3WwuyLWBYiA mHrRaN2dbA1rAptojPOjZKURS/XXl6ktGRKl9cupdTGQYWgjxyk40Vj4e A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOYYJlKtJXG+/2dsb2JhbABbgwc1UcB6gS4WdIIkAQEBAwEBAQFrCxACAQgVAwokJwslAgQOBQgGh24GDKxSjESPRTEHAoMbgQADkCOBLpgKgyCCKg X-IronPort-AV: E=Sophos;i="4.89,1015,1367971200"; d="asc'?scan'208";a="255042997" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 03 Sep 2013 17:18:01 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r83HI0AP005499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 17:18:00 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.15]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 12:18:00 -0500 From: "Carlos Pignataro (cpignata)" To: Mark Townsley Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqLs9HivemM8DHkmVsz4P2sv2M5m0jP8AgAAIcAA= Date: Tue, 3 Sep 2013 17:18:00 +0000 Message-ID: <95067C434CE250468B77282634C96ED325E8ECA6@xmb-aln-x02.cisco.com> References: <20130903153538.BD19618C1B8@mercury.lcs.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.54] Content-Type: multipart/signed; boundary="Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 17:18:06 -0000 --Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is another datapoint against using "source routing" -- the term is = overloaded with multiple meanings and history including "providing = routing information at the source", use of SRR options, and "making a = routing decision based on a source address". "Segment Routing" is simple and captures the essence of the work = (including non explicit -- meaning IGP selected -- paths). Thanks, -- Carlos. On Sep 3, 2013, at 12:47 PM, Mark Townsley wrote: >=20 > For those who might not be aware, the homenet WG has been actively = working on "source and destination routing" (SADR) techniques to solve = the routing problem facing a multi-router, multi-homed, multi-prefix, = IPv6 home network: >=20 > A few refs: >=20 > draft-troan-homenet-sadr > draft-baker-ipv6-ospf-dst-src-routing > draft-baker-ipv6-isis-dst-src-routing > draft-boutier-homenet-source-specific-routing > draft-baker-rtgwg-src-dst-routing-use-cases >=20 > We're working with the ADs on where to advance this, including the = possibility of the rtgwg (hence baker's rtgwg document listed above). = Whatever ends up coming out of homenet, rtgwg, and the WG that is = forming here, we should aim to be very clear what is what.=20 >=20 > - Mark >=20 > P.S. Another ref, just for kicks: = http://www.youtube.com/watch?v=3D3Omg1lJ6EQI >=20 >=20 > On Sep 3, 2013, at 5:35 PM, Noel Chiappa wrote: >=20 >>> From: AshwoodsmithPeter >>=20 >>> We are revisiting source routing with new concepts.=20 >>=20 >> The problem is that "source routing" seems, by the time you do the = set-or of >> all the various meanings that people apply to it, to basically mean = "not >> hop-by-hop routing". >>=20 >> The problem, therefore, with calling something "source routing" is = that it's >> like me calling myself "Not Peter Ashwood-Smith". The problem is that = there >> are a lot of people whose name is "Not Peter Ashwood-Smith", so it's = really a >> pretty useless name. >>=20 >> Similarly, saying that something is "source routing" really tells you = very >> little about it - except that it's not hop-by-hop. So let's find a = different, >> and actually meaningful, name. >>=20 >> Noel >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status --Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlImGcgACgkQtfDPGTp3USwDqQCfWAW/vytxvY+SWnwm+2rmnvRw I1IAn2Pcbf+XsbJJpBaD+60Fepge0CBE =+7wZ -----END PGP SIGNATURE----- --Apple-Mail=_13E9F7E0-CD4F-4BC4-96E6-76F6925B88B6-- From jdrake@juniper.net Tue Sep 3 11:10:57 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E3F11E812B for ; Tue, 3 Sep 2013 11:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVbsU4s1rDmr for ; Tue, 3 Sep 2013 11:10:51 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0870411E80FC for ; Tue, 3 Sep 2013 11:10:50 -0700 (PDT) Received: from mail178-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 18:10:49 +0000 Received: from mail178-db8 (localhost [127.0.0.1]) by mail178-db8-R.bigfish.com (Postfix) with ESMTP id 7776134008B; Tue, 3 Sep 2013 18:10:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(z551biz9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail178-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(377454003)(51704005)(81542001)(81816001)(4396001)(81342001)(81686001)(74876001)(74706001)(46102001)(74366001)(50986001)(47736001)(47976001)(15975445006)(49866001)(65816001)(80976001)(74316001)(51856001)(19580395003)(83322001)(19580405001)(80022001)(33646001)(66066001)(69226001)(561944002)(83072001)(76482001)(54316002)(77096001)(56816003)(54356001)(56776001)(53806001)(76576001)(59766001)(77982001)(74662001)(76786001)(76796001)(31966008)(63696002)(79102001)(47446002)(74502001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail178-db8 (localhost.localdomain [127.0.0.1]) by mail178-db8 (MessageSwitch) id 13782318487197_7399; Tue, 3 Sep 2013 18:10:48 +0000 (UTC) Received: from DB8EHSMHS025.bigfish.com (unknown [10.174.8.244]) by mail178-db8.bigfish.com (Postfix) with ESMTP id F1BE15C0041; Tue, 3 Sep 2013 18:10:47 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS025.bigfish.com (10.174.4.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 18:10:47 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 18:10:46 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 18:10:43 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 18:10:43 +0000 From: John E Drake To: Noel Chiappa , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqMY6NMppxiDdAEC+H+M4LHfrLJm0TqOQ Date: Tue, 3 Sep 2013 18:10:43 +0000 Message-ID: <7cde91101ecb49d98ad0155d4525e286@BY2PR05MB142.namprd05.prod.outlook.com> References: <20130903165418.EF43C18C12F@mercury.lcs.mit.edu> In-Reply-To: <20130903165418.EF43C18C12F@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 18:10:57 -0000 Noel, Comments inline. Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of Noel Chiappa > Sent: Tuesday, September 03, 2013 9:54 AM > To: status@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > > From: Hannes Gredler >=20 > > what about this charter proposal ? >=20 > It looks like a good start to me, but one thing: >=20 > > Stacked Tunnels for Explicit Routing (STER) >=20 > I actually like the name "segment routing". For one, it's a new term, so = it > doesn't have any existing (overloaded) meaning. [JD] Inventing a new term to describe an existing phenomenon is not necess= arily a good idea.=20 >=20 > For another, I find the 'ST' part of 'STER' a bit misleading because an E= RD > might not be using a tunnel (as I normally think of it, which involves 'I= PvN in > IPvN encapsulation' or 'L2 in IPvN encapsulation', or something like that= ) to > specify a path across itself; it might be using an MPLS path, for instanc= e > (which I don't consider a tunnel). [JD] From RFC3031: 3.27. Tunnels and Hierarchy Sometimes a router Ru takes explicit action to cause a particular packet to be delivered to another router Rd, even though Ru and Rd are not consecutive routers on the Hop-by-hop path for that packet, and Rd is not the packet's ultimate destination. For example, this may be done by encapsulating the packet inside a network layer packet whose destination address is the address of Rd itself. This creates a "tunnel" from Ru to Rd. We refer to any packet so handled as a "Tunneled Packet". 3.27.2. Explicitly Routed Tunnel If a Tunneled Packet travels from Ru to Rd over a path other than the Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. For example, we might send a packet through an Explicitly Routed Tunnel by encapsulating it in a packet which is source routed. >=20 > 'Segment routing' seems to me to capture the essence of what's going on; = at > certain points along the overall path, an explicit route is picked for th= e next > segment of the overall path; hence, my liking for it. [JD] It must be a matter of taste as I find 'segment routing' to be startl= ingly non-evocative.=20 >=20 > I have no objection to using the term 'explicit routing' along with 'segm= ent', > so combinations like 'segment routing with explicit path sections', etc, = would > all be fine with me too, although I don't have a perfect suggested name t= o > suggest. >=20 > Noel > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 From jnc@mercury.lcs.mit.edu Tue Sep 3 11:39:42 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BE311E8126 for ; Tue, 3 Sep 2013 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAQM+q6HosQs for ; Tue, 3 Sep 2013 11:39:38 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 44F4811E812B for ; Tue, 3 Sep 2013 11:39:38 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 73D5618C194; Tue, 3 Sep 2013 14:39:32 -0400 (EDT) To: status@ietf.org Message-Id: <20130903183932.73D5618C194@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 14:39:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 18:39:43 -0000 > From: John E Drake > Inventing a new term to describe an existing phenomenon is not > necessarily a good idea. The only two possible existing terms are "source routing" and "explicit routing", and both of them cover a lot more ground then the specific design here. Did I miss another alternative? > From RFC3031 Just because one can find one document which supports a particular reading, that doesn't necessarily mean much, if there are other documents which support other readings. E.g.: Tunneling typically contrasts with a layered protocol model ... The delivery protocol usually ... operates at a higher level in the model than does the payload protocol http://en.wikipedia.org/wiki/Tunneling_protocol (from the first entry in a quick Google search). Noel From yakov@juniper.net Tue Sep 3 11:46:25 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5468821F9A13 for ; Tue, 3 Sep 2013 11:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGJ6+3Z8EP7t for ; Tue, 3 Sep 2013 11:46:20 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id E559E21F994A for ; Tue, 3 Sep 2013 11:46:19 -0700 (PDT) Received: from mail134-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE037.bigfish.com (10.174.4.100) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 18:46:19 +0000 Received: from mail134-db8 (localhost [127.0.0.1]) by mail134-db8-R.bigfish.com (Postfix) with ESMTP id BE738A00D3; Tue, 3 Sep 2013 18:46:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(z551biz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h17326ah1de097h186068h8275dhz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail134-db8: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail134-db8 (localhost.localdomain [127.0.0.1]) by mail134-db8 (MessageSwitch) id 1378233976825991_6859; Tue, 3 Sep 2013 18:46:16 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.243]) by mail134-db8.bigfish.com (Postfix) with ESMTP id C2E89480056; Tue, 3 Sep 2013 18:46:16 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.52) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 18:46:13 +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; Tue, 3 Sep 2013 11:46:11 -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 r83IkAL84969; Tue, 3 Sep 2013 11:46:10 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201309031846.r83IkAL84969@magenta.juniper.net> To: Noel Chiappa In-Reply-To: <20130903183932.73D5618C194@mercury.lcs.mit.edu> References: <20130903183932.73D5618C194@mercury.lcs.mit.edu> X-MH-In-Reply-To: Noel Chiappa message dated "Tue, 03 Sep 2013 14:39:32 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95646.1378233969.1@juniper.net> Date: Tue, 3 Sep 2013 11:46:10 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 18:46:25 -0000 Noel, > > From: John E Drake > > > Inventing a new term to describe an existing phenomenon is not > > necessarily a good idea. > > The only two possible existing terms are "source routing" and "explicit > routing", and both of them cover a lot more ground then the specific design > here. Did I miss another alternative? > > > > From RFC3031 > > Just because one can find one document which supports a particular reading, > that doesn't necessarily mean much, if there are other documents which support > other readings. E.g.: > > Tunneling typically contrasts with a layered protocol model ... The > delivery protocol usually ... operates at a higher level in the model than > does the payload protocol > > http://en.wikipedia.org/wiki/Tunneling_protocol > > (from the first entry in a quick Google search). rfc3031 is a product of IETF. http://en.wikipedia.org/wiki/Tunneling_protocol is not. In the context of IETF work, reading supported by IETF documents (RFCs) takes precedence over reading supported by other non-IETF documents. Yakov. From adrian@olddog.co.uk Tue Sep 3 13:59:31 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5679D21E80C3 for ; Tue, 3 Sep 2013 13:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVq8MI5OWs8c for ; Tue, 3 Sep 2013 13:59:00 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0521E80AC for ; Tue, 3 Sep 2013 13:58:53 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r83Kwpww029002; Tue, 3 Sep 2013 21:58:51 +0100 Received: from 950129200 ([203.9.153.2]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r83Kwltc028957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Sep 2013 21:58:50 +0100 From: "Adrian Farrel" To: "'Noel Chiappa'" , References: <20130903183932.73D5618C194@mercury.lcs.mit.edu> In-Reply-To: <20130903183932.73D5618C194@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 21:58:49 +0100 Message-ID: <027901cea8e8$65dca0c0$3195e240$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGkuIxGgd+53WvNKp86LM+YYjpqX5oIXcZg Content-Language: en-gb Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 20:59:32 -0000 Hi Noel, Far be it from me to criticise the wisdom of wikipedia, but... > Tunneling typically contrasts with a layered protocol model ... The > delivery protocol usually ... operates at a higher level in the model than > does the payload protocol "operates at higher level" might be an architectural rather than a technological definition. Whatever! I consider IP-in-IP to be tunneling. Looks like IP is probably at the same level as IP. I think that pseudowires are tunneling. Looks like IP/L2TP/MPLS are probably at a higher layer than Ethernet or TDM. I think MPLS-in-MPLS is tunneling, and MPLS is at the same level as MPLS. So, maybe, next time you are updating this wikipedia entry, s/operates at a higher level/operates at the same or a higher level/ Cheers, Adrian From adrian@olddog.co.uk Tue Sep 3 14:13:52 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2ED11E8126 for ; Tue, 3 Sep 2013 14:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGyX88+4X3YA for ; Tue, 3 Sep 2013 14:13:41 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 2576111E80D9 for ; Tue, 3 Sep 2013 14:13:40 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r83LDdfR030360; Tue, 3 Sep 2013 22:13:39 +0100 Received: from 950129200 ([203.9.153.2]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r83LDZWa030340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Sep 2013 22:13:38 +0100 From: "Adrian Farrel" To: "'Mark Townsley'" , References: <20130903153538.BD19618C1B8@mercury.lcs.mit.edu> In-Reply-To: Date: Tue, 3 Sep 2013 22:13:36 +0100 Message-ID: <028501cea8ea$76ec62e0$64c528a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJUgxrd5tUvDV9iNoqSlpnc3PWJWgKIV2q0mJSIwFA= Content-Language: en-gb Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:13:52 -0000 Hi Mark, The term "source routing" in the homenet context appears to apply to the concept of considering the source address at the time of making a routing decision, rather than the imposition of a route by the source node. Thus, what homenet is doing is a form of policy-based routing (where the policy applies to the source address). It may be the case that the homenet problem space overlaps somewhat with the STATUS work, but it looks like STATUS is considering a wider set of problems and networks with larger diameters. [snip] > We're working with the ADs on where to advance this, including the possibility of > the rtgwg (hence baker's rtgwg document listed above). Whatever ends up > coming out of homenet, rtgwg, and the WG that is forming here, we should aim > to be very clear what is what. I haven't been involved in that discussion (yet), but I note that the homenet charter says... If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. But you're right. We need to be clear on terminology and division of labor. Thanks for raising this. Adrian From jdrake@juniper.net Tue Sep 3 14:36:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC121F9E8B for ; Tue, 3 Sep 2013 14:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.912 X-Spam-Level: X-Spam-Status: No, score=-4.912 tagged_above=-999 required=5 tests=[AWL=1.688, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyJybZiXOBml for ; Tue, 3 Sep 2013 14:36:46 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE521F9994 for ; Tue, 3 Sep 2013 14:36:46 -0700 (PDT) Received: from mail29-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 21:36:44 +0000 Received: from mail29-co9 (localhost [127.0.0.1]) by mail29-co9-R.bigfish.com (Postfix) with ESMTP id 804F51A0108; Tue, 3 Sep 2013 21:36:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(z551biz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail29-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51704005)(13464003)(189002)(199002)(76576001)(77982001)(59766001)(83072001)(76796001)(53806001)(76786001)(77096001)(54356001)(54316002)(63696002)(56816003)(47446002)(74502001)(31966008)(74662001)(79102001)(76482001)(15202345003)(74706001)(74316001)(81686001)(46102001)(74366001)(19580395003)(4396001)(49866001)(81542001)(74876001)(33646001)(47736001)(56776001)(47976001)(50986001)(81342001)(15975445006)(81816001)(69226001)(83322001)(80976001)(19580405001)(80022001)(51856001)(65816001)(66066001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail29-co9 (localhost.localdomain [127.0.0.1]) by mail29-co9 (MessageSwitch) id 1378244202796402_18659; Tue, 3 Sep 2013 21:36:42 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.227]) by mail29-co9.bigfish.com (Postfix) with ESMTP id B4374320057; Tue, 3 Sep 2013 21:36:42 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 21:36:42 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 21:36:39 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 21:36:35 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 21:36:35 +0000 From: John E Drake To: Noel Chiappa , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqNTuA+YRCbCtGUqYSTFlBeyH3Zm0gFmw Date: Tue, 3 Sep 2013 21:36:34 +0000 Message-ID: References: <20130903183932.73D5618C194@mercury.lcs.mit.edu> In-Reply-To: <20130903183932.73D5618C194@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 09583628E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 21:36:51 -0000 Yours Irrespectively, John > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Tuesday, September 03, 2013 11:40 AM > To: status@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [Status] Summary of STATUS BOF and the next steps >=20 > > From: John E Drake >=20 > > Inventing a new term to describe an existing phenomenon is not > > necessarily a good idea. >=20 > The only two possible existing terms are "source routing" and "explicit > routing", and both of them cover a lot more ground then the specific desi= gn > here. Did I miss another alternative? [JD] I'm happy with either source routing or explicit routing. If you ins= ist upon a new term, why not 'directed forwarding|routing'.=20 >=20 >=20 > > From RFC3031 >=20 > Just because one can find one document which supports a particular readin= g, > that doesn't necessarily mean much, [JD] You were making incorrect statements about MPLS, so for some odd reas= on I thought it appropriate to reference the MPLS architecture RFC.=20 > if there are other documents which > support other readings. E.g.: >=20 > Tunneling typically contrasts with a layered protocol model ... The > delivery protocol usually ... operates at a higher level in the model t= han > does the payload protocol >=20 > http://en.wikipedia.org/wiki/Tunneling_protocol >=20 > (from the first entry in a quick Google search). [JD] Perhaps you would consider re-writing this?=20 >=20 > Noel >=20 From jnc@mercury.lcs.mit.edu Tue Sep 3 18:08:33 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047EF21E80F2 for ; Tue, 3 Sep 2013 18:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAV0eBdHcjbm for ; Tue, 3 Sep 2013 18:08:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76D21F9A27 for ; Tue, 3 Sep 2013 18:08:27 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 24CAE18C0E9; Tue, 3 Sep 2013 21:08:24 -0400 (EDT) To: status@ietf.org Message-Id: <20130904010824.24CAE18C0E9@mercury.lcs.mit.edu> Date: Tue, 3 Sep 2013 21:08:24 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 01:08:33 -0000 > From: John E Drake > I'm happy with either source routing or explicit routing. If you insist > upon a new term, why not 'directed forwarding|routing'. Now I'm somewhat confused, because you aren't stuck on 'source routing' or 'explicit routing', but... 'segment routing' is a no-go - apparently because you find it "to be startlingly non-evocative" - you didn't, AFAICR, put forward any other reason it's unacceptable? Look, I am not at all invested in 'segment routing'. If someone comes up with a good alternative, that's fine with me. > You were making incorrect statements about MPLS No. What I said, exactly, was "an MPLS path, for instance (which I don't consider a tunnel)". The key phrase there being "I don't consider" - i.e. it's my opinion. > From: Yakov Rekhter > rfc3031 is a product of IETF. > ... > In the context of IETF work, reading supported by IETF documents (RFCs) > takes precedence over reading supported by other non-IETF documents. The world of computers/networking is larger than the IETF. If an IETF document re-defined "packet" or "datagram", would that be definitive? (Heck, RFC-1753/RFC-1992 _did_ re-define 'datagram', but I don't go around demanding that people always use that definition!) Anyway, there are other IETF documents that do use the 'layer 2...N wrapped inside layer N' definition of "tunnel" - see RFC-1241, RFC-1853, etc (and that's 5 minutes of my life I'll never get back). > From: "Adrian Farrel" > next time you are updating this wikipedia entry I have _never_ worked on that entry, and have no intention of ever so doing. And this whole argument about tunnels is almost as stupid as much of the flaming on the IETF main list. I feel like I've fallen into an episode of Monty Python. (For people who don't get the reference, see this: https://en.wikipedia.org/wiki/The_Argument_Sketch which will explain it.) Noel From jdrake@juniper.net Tue Sep 3 18:30:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61A21E80E3 for ; Tue, 3 Sep 2013 18:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEpVvdzXr86l for ; Tue, 3 Sep 2013 18:30:13 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1091E21E80F2 for ; Tue, 3 Sep 2013 18:30:03 -0700 (PDT) Received: from mail60-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 01:30:00 +0000 Received: from mail60-db8 (localhost [127.0.0.1]) by mail60-db8-R.bigfish.com (Postfix) with ESMTP id C65DD300326; Wed, 4 Sep 2013 01:30:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(z551biz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail60-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(377454003)(13464003)(76482001)(47736001)(81542001)(19580405001)(83322001)(47976001)(50986001)(74876001)(4396001)(56776001)(56816003)(77096001)(69226001)(54316002)(49866001)(54356001)(81342001)(53806001)(74316001)(74662001)(47446002)(19580395003)(74502001)(31966008)(83072001)(74706001)(51856001)(46102001)(74366001)(76576001)(79102001)(76796001)(80976001)(81816001)(63696002)(76786001)(80022001)(66066001)(81686001)(77982001)(65816001)(33646001)(59766001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail60-db8 (localhost.localdomain [127.0.0.1]) by mail60-db8 (MessageSwitch) id 1378258198439404_17005; Wed, 4 Sep 2013 01:29:58 +0000 (UTC) Received: from DB8EHSMHS012.bigfish.com (unknown [10.174.8.235]) by mail60-db8.bigfish.com (Postfix) with ESMTP id 5B045B80041; Wed, 4 Sep 2013 01:29:58 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS012.bigfish.com (10.174.4.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 01:29:58 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 01:29:58 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 01:29:55 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 01:29:55 +0000 From: John E Drake To: Noel Chiappa , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqQtAA+YRCbCtGUqYSTFlBeyH3Zm0yPxA Date: Wed, 4 Sep 2013 01:29:54 +0000 Message-ID: <3b9b0e2767774799af70099fa7278470@BY2PR05MB142.namprd05.prod.outlook.com> References: <20130904010824.24CAE18C0E9@mercury.lcs.mit.edu> In-Reply-To: <20130904010824.24CAE18C0E9@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 095972DF2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 01:30:24 -0000 Noel, Snipped, comments inline. Yours Irrespectively, John > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Tuesday, September 03, 2013 6:08 PM > To: status@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [Status] Summary of STATUS BOF and the next steps >=20 > > From: John E Drake >=20 > > I'm happy with either source routing or explicit routing. If you in= sist > > upon a new term, why not 'directed forwarding|routing'. >=20 > Now I'm somewhat confused, because you aren't stuck on 'source routing' o= r > 'explicit routing', but... 'segment routing' is a no-go - apparently beca= use you > find it "to be startlingly non-evocative" - you didn't, AFAICR, put forwa= rd any > other reason it's unacceptable? [JD] If a term has only passing familiarity with what it is describing, it= is effectively useless. >=20 > Look, I am not at all invested in 'segment routing'. If someone comes up = with > a good alternative, that's fine with me. >=20 > > You were making incorrect statements about MPLS >=20 > No. What I said, exactly, was "an MPLS path, for instance (which I don't > consider a tunnel)". The key phrase there being "I don't consider" - i.e. > it's my opinion. [JD] Right. I was simply pointing out that your opinion is wrong. From mach.chen@huawei.com Tue Sep 3 18:56:20 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812AA21E812F for ; Tue, 3 Sep 2013 18:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX5Llc4uMFNl for ; Tue, 3 Sep 2013 18:56:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1865021E8123 for ; Tue, 3 Sep 2013 18:56:11 -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.5-GA FastPath queued) with ESMTP id AVA34118; Wed, 04 Sep 2013 01:56:11 +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.146.0; Wed, 4 Sep 2013 02:55:39 +0100 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 02:55:52 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.175]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.007; Wed, 4 Sep 2013 09:55:45 +0800 From: Mach Chen To: John E Drake , Mark Townsley , Victor Kuarsingh Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJpwNqdHEx+e0+Ke3Awtr4OpJmvZ8aAgAEZNwCAABkbgIAC3/WAgAFdseA= Date: Wed, 4 Sep 2013 01:55:43 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 01:56:20 -0000 I also prefer to "source routing", it's well-know and direct. Best regards, Mach > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of > John E Drake > Sent: Tuesday, September 03, 2013 9:02 PM > To: Mark Townsley; Victor Kuarsingh > Cc: Roberta Maglione (robmgl); John G. Scudder; Alvaro Retana (aretana); = Adrian > Farrel; status@ietf.org; Stewart Bryant (stbryant) > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'. >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behal= f > > Of Mark Townsley > > Sent: Sunday, September 01, 2013 10:08 AM > > To: Victor Kuarsingh > > Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro R= etana > > (aretana); status@ietf.org; Stewart Bryant (stbryant) > > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > > > > > On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: > > > > > All, > > > > > > I would also favour "Segment Routing WG" as well. > > > > > > I note this since attempting to come up with an all encompassing > > > acronym will be difficult and Segment Routing is generic enough to > > > associate to multiple functions. > > > > Then we can just use "segroute" for the short name. WGs do not have to > > have acronyms, but they do need to have an 8-char limited short name fo= r > > the various automated tools not to break. > > > > - Mark > > > > > > > > Regards, > > > > > > Victor K > > > > > > > > > > > > On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" > > > wrote: > > > > > >> +1 for Segment Routing WG > > >> > > >> Roberta > > >> > > >> Sent from my iPad > > >> > > >> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" > > >> > > >> wrote: > > >> > > >>> Segment Routing WG > > >>> > > >>> Sent from my iPhone > > >>> > > >>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" > > >>> wrote: > > >>> > > >>>> The second task, which hopefully should be relatively easy, is to > > >>>> find a better working name for the WG, since it has been put to me > > >>>> a number of times that STATUS is going to be confusing in text and > > >>>> a difficult search term. > > >>> _______________________________________________ > > >>> status mailing list > > >>> status@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/status > > >> _______________________________________________ > > >> status mailing list > > >> status@ietf.org > > >> https://www.ietf.org/mailman/listinfo/status > > > > > > > > > _______________________________________________ > > > status mailing list > > > status@ietf.org > > > https://www.ietf.org/mailman/listinfo/status > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From stephane.litkowski@orange.com Wed Sep 4 00:22:04 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31CA21F9A99 for ; Wed, 4 Sep 2013 00:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bl8qCkTVDTV for ; Wed, 4 Sep 2013 00:21:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2121F9A98 for ; Wed, 4 Sep 2013 00:21:58 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id AFCEB3B41DD; Wed, 4 Sep 2013 09:21:53 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 95BE518003E; Wed, 4 Sep 2013 09:21:53 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 4 Sep 2013 09:21:53 +0200 From: To: AshwoodsmithPeter Date: Wed, 4 Sep 2013 09:21:52 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAAmx0IABDQmA Message-ID: <27969_1378279313_5226DF91_27969_15991_1_EEE55384044474429A926C625D0FCC810962D1E8B8@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.4.62420 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 07:22:04 -0000 >We are revisiting source routing with new concepts. More generic number/a= ction behavior. [SLI] Agree ! So I would be more in favor of a new term to prevent confusio= n with a very well known concept today. -----Message d'origine----- De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com]=20 Envoy=E9 : mardi 3 septembre 2013 17:22 =C0 : LITKOWSKI Stephane DTF/DERX Cc : status@ietf.org Objet : RE: [Status] Summary of STATUS BOF and the next steps " If the WG charter is limited to source routing, how will we handle the "n= on source routing" use cases of segment routing ? In another working group = ? So we will go back to the WG synchronization issue that has been raised f= or this technology ..." That's why I suggested SRV2. We are revisiting source routing with new conc= epts. More generic number/action behavior.=20 Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= stephane.litkowski@orange.com Sent: Tuesday, September 03, 2013 10:43 AM To: AshwoodsmithPeter Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps =20 There was a misunderstanding in my small comment :) so I will explain more : In segment routing, you have more than basic source routing : segment routi= ng is just associate a segment number to an action and then combine segment= as you want, yes you can do source routing, but you also can do more. In the other hand, I completely agree with your statement that source routi= ng is generic and dataplane agnostic, as segment routing is ... (segment ro= uting is not a new dataplane ...) Now the definition of the WG naming must be inline with the charter that wi= ll be defined ... (draft today) =20 Based on the already existing consensus (at least for MPLS dataplane) broug= ht up during Berlin STATUS BOF meeting, segment routing sounds to be a good= target candidate. So now, do we want to do more in the WG charter than just make progressing = segment routing architecture and uses cases document and ensure coordinatio= n for the standardization of this technology ? =20 Do we want to standardize other technologies in this WG ? I don't think so,= based on Stewart's conclusion email from the BOF :"A new WG focused solely= on SR therefore needs to be create" If the WG charter is limited to source routing, how will we handle the "non= source routing" use cases of segment routing ? In another working group ? = So we will go back to the WG synchronization issue that has been raised for= this technology ... If the WG is focused on SR, let's use a name in relation with SR. Feedback ? Stephane -----Message d'origine----- De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg= l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.or= g; Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF and= the next steps The term "source routing" has been around for a very long time and is data = path agnostic. Its also the term used in the literature etc so my preferenc= e is to stick with this existing well known and data path agnostic term. Peter On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: > Hi, >=20 > "Source routing" is just a subcase of segment routing ... as it is for IP= routing ... >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la=20 > part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark= =20 > Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. > Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org;=20 > Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF=20 > and the next steps >=20 > Hi, >=20 > What is this 'segment routing' silliness? The correct term is 'source ro= uting'.=20 >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 >> Behalf Of Mark Townsley >> Sent: Sunday, September 01, 2013 10:08 AM >> To: Victor Kuarsingh >> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro=20 >> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >>=20 >> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>=20 >>> All, >>>=20 >>> I would also favour "Segment Routing WG" as well. >>>=20 >>> I note this since attempting to come up with an all encompassing=20 >>> acronym will be difficult and Segment Routing is generic enough to=20 >>> associate to multiple functions. >>=20 >> Then we can just use "segroute" for the short name. WGs do not have=20 >> to have acronyms, but they do need to have an 8-char limited short=20 >> name for the various automated tools not to break. >>=20 >> - Mark >>=20 >>>=20 >>> Regards, >>>=20 >>> Victor K >>>=20 >>>=20 >>>=20 >>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)"=20 >>> >>> wrote: >>>=20 >>>> +1 for Segment Routing WG >>>>=20 >>>> Roberta >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>> >>>> wrote: >>>>=20 >>>>> Segment Routing WG >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>> wrote: >>>>>=20 >>>>>> The second task, which hopefully should be relatively easy, is to=20 >>>>>> find a better working name for the WG, since it has been put to=20 >>>>>> me a number of times that STATUS is going to be confusing in text=20 >>>>>> and a difficult search term. >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From stephane.litkowski@orange.com Wed Sep 4 01:02:54 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CC011E818B for ; Wed, 4 Sep 2013 01:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WHZbX5-9WmF for ; Wed, 4 Sep 2013 01:02:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id BAD0811E80E3 for ; Wed, 4 Sep 2013 01:02:49 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 2A2083B543A; Wed, 4 Sep 2013 10:02:47 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 119D118003E; Wed, 4 Sep 2013 10:02:47 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 4 Sep 2013 10:02:47 +0200 From: To: Hannes Gredler Date: Wed, 4 Sep 2013 10:02:45 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6owwTTFv/vcw2mTVaNxErNDk0WvwAfIBOA Message-ID: <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> In-Reply-To: <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.4.73317 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 08:02:54 -0000 Hannes, In case, we are using only directed forwarding (adjacency segment), could w= e still talk about tunneling ? (it's a very very small tunnel) Moreover talking about "stacking" is really dataplane agnostic (MPLS) ... In the proposed segment routing architectural concepts, segments are at the= same "level" and pointer moves on the segment list, then the MPLS instanti= ation is performing this using stacking ... IMHO, if we use "Stacked Tunnels", we already talk about a chosen solution = and it's closing the door to something else ... Finally, about the "routing" word, routing is essentially a "forward" actio= n which may limit the scope of what we can do by using a segment list. Acti= ons associated with a segment could be something else than forwarding. Do we want in the charter to limit the scope to routing actions ? I have no solution today to propose for the naming, but I completely agree = with Loa, to first focus on working on the charter, and define a clear scop= e of the work and then the name will be easier to find. Regarding your charter proposal : -------- - They form a connected network [SLI] InterAS case must be included, but the WG can go step by step= and first release intraAS, and then doing interAS (in relation with IDR ??= ). - They can forward traffic through the shortest paths or paths other than t= he shortest (the latter called explicitly routed paths, or explicit paths) [SLI] There is something else between SPT and Explicit path, you ca= n define other algorithms than SPT to define a path, and it's not explicit = path. Moreover I come back to my comment, on do we want to limit the scope = to routing ? I would say no. - They share a common trust model. In this model, any router within the ERD= can specify an explicit path between itself and any other router in the ER= D. It can then send any packet that passes through it through any path that= it has specified. [SLI] Security considerations may have to be addressed in the chart= er , especially for the interAS case (trust yes, but not sure access to eve= rything may not be good) Downstream routers within the ERD forward the packet as specified by the ro= uter at the head-end of the path. [SLI] Yes, but any router in the middle may be able to change the end to en= d explicit path. - The first goal of the STER WG is to identify use-cases for ERDs. - Having identified use-cases, the WG will identify gaps between currently = available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols= or new protocols that address gaps that are identified. [SLI] Agree, I would add : - defining the architecture framework - analysing the security considerisations --------- Here would be my proposal to extend yours : A domain contains a set of routers with the following= characteristics: - They form a connected network - They can forward traffic through any path within the network using shorte= st path, non shortest path or explicit path - They may provide other types of services than forwarding and they can enf= orce service actions in the path. - They share a common trust model. In this model, any router within the dom= ain can specify a path between itself and any other router in the domain. I= t may then send any packet that passes through it through any path that it = has specified and that is conform to the security rules. Downstream routers= within the ERD forward the packet as specified by the router at the head-e= nd of the path. The working group is chartered for the following ordered list of wor= k items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the se= curity considerations. The architecture framework and security consideratio= ns must address the relations between domains (interdomain). - Having identified use-cases, architecture and security, the WG will ident= ify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols= or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Protocol work may be carried out in this working group or in other working = groups responsible for the protocols, in coordination with this WG, and in = agreement with the WG chairs and responsible ADs. However, no protocol work= will be adopted by a working group to address the ERD use-cases until the = requirements document motivating the protocol work has been sent to the IES= G for publication as an RFC. -----Message d'origine----- De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de= Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the next steps good point - what about this charter proposal ? --- Stacked Tunnels for Explicit Routing (STER) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D A explicit routing domain (ERD) contains a set of routers with the followin= g characteristics: - They form a connected network - They can forward traffic through the shortest paths or paths other than t= he shortest (the latter called explicitly routed paths, or explicit paths) - They share a common trust model. In this model, any router within the ERD= can specify an explicit path between itself and any other router in the ER= D. It can then send any packet that passes through it through any path that= it has specified. Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. The STER working group is chartered for the following ordered list of work = items: - The first goal of the STER WG is to identify use-cases for ERDs. - Having identified use-cases, the WG will identify gaps between currently = available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols= or new protocols that address gaps that are identified. Protocol work may be carried out in this working group or in other working = groups responsible for the protocols, in coordination with this WG, and in = agreement with the WG chairs and responsible ADs. However, no protocol work= will be adopted by a working group to address the ERD use-cases until the = requirements document motivating the protocol work has been sent to the IES= G for publication as an RFC. --- /hannes On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: > Folks, > > Excuse me if I'm slightly out of the loop, but so far I have not seen > a charter proposal, if there is one please point me to it. > > It seems a bit odd to put the cart (what the wg should do) before the > horse (wg name). If we drill down the the charter first the wg name > might be easier to figure out. > > /Loa > > PS > OK I understand that the horse and cart analogy limps a bit :). > > > > On 2013-09-03 17:22, AshwoodsmithPeter wrote: >> " If the WG charter is limited to source routing, how will we handle the= "non source routing" use cases of segment routing ? In another working gro= up ? So we will go back to the WG synchronization issue that has been raise= d for this technology ..." >> >> That's why I suggested SRV2. We are revisiting source routing with new c= oncepts. More generic number/action behavior. >> >> Peter >> >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of stephane.litkowski@orange.com >> Sent: Tuesday, September 03, 2013 10:43 AM >> To: AshwoodsmithPeter >> Cc: status@ietf.org >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >> >> >> There was a misunderstanding in my small comment :) so I will explain mo= re : >> >> In segment routing, you have more than basic source routing : segment ro= uting is just associate a segment number to an action and then combine segm= ent as you want, yes you can do source routing, but you also can do more. >> >> In the other hand, I completely agree with your statement that source >> routing is generic and dataplane agnostic, as segment routing is ... >> (segment routing is not a new dataplane ...) >> >> Now the definition of the WG naming must be inline with the charter >> that will be defined ... (draft today) >> >> Based on the already existing consensus (at least for MPLS dataplane) br= ought up during Berlin STATUS BOF meeting, segment routing sounds to be a g= ood target candidate. >> >> So now, do we want to do more in the WG charter than just make progressi= ng segment routing architecture and uses cases document and ensure coordina= tion for the standardization of this technology ? >> >> Do we want to standardize other technologies in this WG ? I don't think = so, based on Stewart's conclusion email from the BOF :"A new WG focused sol= ely on SR therefore needs to be create" >> >> If the WG charter is limited to source routing, how will we handle the "= non source routing" use cases of segment routing ? In another working group= ? So we will go back to the WG synchronization issue that has been raised = for this technology ... >> >> If the WG is focused on SR, let's use a name in relation with SR. >> >> Feedback ? >> >> >> Stephane >> >> >> -----Message d'origine----- >> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane DTF/DERX >> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione >> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >> Summary of STATUS BOF and the next steps >> >> The term "source routing" has been around for a very long time and is da= ta path agnostic. Its also the term used in the literature etc so my prefer= ence is to stick with this existing well known and data path agnostic term. >> >> Peter >> >> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >> >>> Hi, >>> >>> "Source routing" is just a subcase of segment routing ... as it is for = IP routing ... >>> >>> Stephane >>> >>> >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark >>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS BOF >>> and the next steps >>> >>> Hi, >>> >>> What is this 'segment routing' silliness? The correct term is 'source = routing'. >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of Mark Townsley >>>> Sent: Sunday, September 01, 2013 10:08 AM >>>> To: Victor Kuarsingh >>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>> >>>> >>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>> >>>>> All, >>>>> >>>>> I would also favour "Segment Routing WG" as well. >>>>> >>>>> I note this since attempting to come up with an all encompassing >>>>> acronym will be difficult and Segment Routing is generic enough to >>>>> associate to multiple functions. >>>> >>>> Then we can just use "segroute" for the short name. WGs do not have >>>> to have acronyms, but they do need to have an 8-char limited short >>>> name for the various automated tools not to break. >>>> >>>> - Mark >>>> >>>>> >>>>> Regards, >>>>> >>>>> Victor K >>>>> >>>>> >>>>> >>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>> >>>>> wrote: >>>>> >>>>>> +1 for Segment Routing WG >>>>>> >>>>>> Roberta >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Segment Routing WG >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>> wrote: >>>>>>> >>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>> to find a better working name for the WG, since it has been put >>>>>>>> to me a number of times that STATUS is going to be confusing in >>>>>>>> text and a difficult search term. >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >>> ____________________________________________________________________ >>> __ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From stbryant@cisco.com Wed Sep 4 03:25:20 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97D11E812A for ; Wed, 4 Sep 2013 03:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.621 X-Spam-Level: X-Spam-Status: No, score=-110.621 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mWaEICdlveC for ; Wed, 4 Sep 2013 03:25:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4D80B11E81A6 for ; Wed, 4 Sep 2013 03:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9330; q=dns/txt; s=iport; t=1378290305; x=1379499905; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=M9YE9s8AH6WW8zGO5mkl8PVYgJnU8A3e5iinz5T58eo=; b=OnjWdO0lxrAdbvE60I1UplA/urdkWHM3/9xRu3M4pWGXGcRxR634SGiu fYBgtgmcHAGsMSK7aRDLaL2Iq2nQqjd+W7/L+GyhPSrs+Yf8syVYXEiMA /YcdhGq+enz+tXOoZ7faI2CGDpNzKIie3tH31LMD6/ZGCRRpVa6V/cQy/ c=; X-IronPort-AV: E=Sophos;i="4.89,1020,1367971200"; d="scan'208,217";a="86390389" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 04 Sep 2013 10:24:56 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r84AOsXH010196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Sep 2013 10:24:55 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r84AOqML009323; Wed, 4 Sep 2013 11:24:53 +0100 (BST) Message-ID: <52270A74.7010707@cisco.com> Date: Wed, 04 Sep 2013 11:24:52 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mach Chen References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010802000607090309080402" Cc: John E Drake , Mark Townsley , Victor Kuarsingh , "Roberta Maglione \(robmgl\)" , "John G. Scudder" , Adrian Farrel , "Alvaro Retana \(aretana\)" , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 04 Sep 2013 10:25:20 -0000 This is a multi-part message in MIME format. --------------010802000607090309080402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart --------------010802000607090309080402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including 
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups, 
    respectively).

- Stewart

--------------010802000607090309080402-- From ghanwani@gmail.com Wed Sep 4 06:26:09 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCBB21E80B8 for ; Wed, 4 Sep 2013 06:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZiYHKsIdyIw for ; Wed, 4 Sep 2013 06:26:08 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D0E2B11E81B5 for ; Wed, 4 Sep 2013 06:26:07 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id q55so279475wes.36 for ; Wed, 04 Sep 2013 06:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=S/BLB3CJwBINbTATB3OUfL8rjzlMzWWdRKb5fgQewUQ=; b=g6BRaD9VUjj8eoDDC2zg8csS2/nzguXxN0XZRZudVNnAxCnimSe/Md+PUHXLgdSyDb D+hjFi2B4vjhd8bIZu5gWscuqS8oOeN46dOmZp1qoLzoU3tyRyULztryZMhhKSXHv+Vh kM4lvguO2ZGFFVrHUFXcBimBlW2lwJ40oof175YzNQzgZfgjEIdgD923K2GXKjjzQMR9 TYtWdPNXgNEHbMOqjVUFroVLjEpHlKPmV1UpGLogj/oP7P2MKMBPrk916qtsP49MFInb lYON4FmQgrVUOF/HwvhpoLHCDHU9q1APP4UbGTEfZ5U+JKlfBJdaGFBsnS8nr10mC2xu 5anA== MIME-Version: 1.0 X-Received: by 10.180.160.203 with SMTP id xm11mr2074627wib.17.1378301166974; Wed, 04 Sep 2013 06:26:06 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Wed, 4 Sep 2013 06:26:06 -0700 (PDT) Date: Wed, 4 Sep 2013 06:26:06 -0700 X-Google-Sender-Auth: JVMVIYpqpaeXoGoUkRD5eqzEYs0 Message-ID: From: Anoop Ghanwani To: "status@ietf.org" Content-Type: multipart/alternative; boundary=047d7b66f907737ad104e58ebfa5 Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 13:26:09 -0000 --047d7b66f907737ad104e58ebfa5 Content-Type: text/plain; charset=ISO-8859-1 Some folks use BGP to perform the function of an IGP. It looks like the proposed charter would exclude them from taking advantage of this technology. It might be worthwhile adding BGP to that list of protocols to be enhanced for this. With respect to the text about working with existing data paths -- I wonder if there is some way to capture that it might not work with all existing implementations. For example, the number of labels required to be pushed at the ingress device may prevent some existing implementations from taking advantage of this technology, depending on the size of the topology. Anoop On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant wrote: > > May I suggest that we use the name "SR" and worry > about what it binds to later. > > The higher priority item is the charter text. Does > anyone have any comments on the text proposed > so far, or the text in the BOF proposal: > > > The Stacked Tunnels for Source Routing (STATUS) Working Group > is chartered to develop a framework and use cases for source-routed > flows in packet switched networks. > > IP previously had a source-based routing mechanism made > available through an IP Option. This mechanism has, however, > not been widely used and has a number of issues that make its > use inadvisable, and other mechanisms (such as RFC 1940) > do not appear to have been implemented at all. > > The ability of a router to influence or control the forwarding > path of an individual packet or all the packets of a given > Forwarding Equivalence Class (FEC) is a desirable feature > for a number of reasons including Label Switched Path stitching, > egress protection, explicit routing, egress ASBR link selection, > and backup (bypass tunnels, Remote Loop-Free Alternates) > routing. This can be achieved by facilitating source-initiated > selection of routes to complement the route selection > provided by existing routing protocols for both inter- domain > and intra-domain routes. > > Historically, distribution of MPLS label binding information > was done by relying on label distribution protocols > such as LDP and RSVP-TE. > > The use cases documented by the working group will > indicate the network function that is being facilitated > and indicate which packet data plane is to be used. > > The framework developed by the working group will > consider forwarding of IPv4, IPv6, and MPLS using the > existing unicast data planes. Multicast forwarding will > be for future study and the choice of data planes will > be limited to those for which use cases exist. A key > objective of the work will be to ensure that source- > routed packets can be handled seamlessly by existing > deployed equipment. A major objective will be that the > new function does not modify existing data plane behavior > or architectures, and that it can be enabled through only > control and management plane software upgrades at > deployed devices. > > Once the working group has established a framework > and there is demonstrable consensus for use cases, > the working group will move forward to specify protocol > solutions for installing forwarding information through > the use of the IGPs (OSPF and IS-IS), or through the > management plane. In the course of developing protocol > extensions, the working group will work closely with > other IETF working groups responsible for the protocols > being modified (such as OSPF, ISIS, and I2RS). > > The working group is chartered for the following work items: > > A framework for the use of the existing MPLS data plane to > support tunnel-based unicast source routing. > > Develop use cases for tunnel-based unicast source routing > that demonstrate the need and support for solutions. Care > should be taken to avoid clustering use cases that might seem > to imply support for multiple use cases when only some of the > cluster actually have wide-scale support. > > Develop ISIS and OSPF protocol extensions necessary for > distribution of MPLS forwarding information. > > The working group will consider management (including > configuration, reporting, diagnostics, and OAM) and security > implications of its work and document them in separate > documents as appropriate. > > The working group is not chartered to make any changes to > the MPLS or IPv6 data planes. Any proposed changes to the > data planes are to be specified in the working groups responsible > for the data planes (that is, the MPLS and 6MAN working groups, > respectively). > > - Stewart > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > --047d7b66f907737ad104e58ebfa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some folks use BGP to perform the function of an IGP. =A0I= t looks like the proposed charter would exclude them from taking advantage = of this technology. =A0It might be worthwhile adding BGP to that list of pr= otocols to be enhanced for this.

With respect to the text about working with existing data pa= ths -- I wonder if there is some way to capture that it might not work with= all existing implementations. =A0For example, the number of labels require= d to be pushed at the ingress device may prevent some existing implementati= ons from taking advantage of this technology, depending on the size of the = topology.

Anoop


On Wed, S= ep 4, 2013 at 3:24 AM, Stewart Bryant <stbryant@cisco.com> = wrote:
=20 =20 =20

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

=20
The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

=A0=A0=A0 The working group is chartered for the following work items:<= br>
=A0=A0=A0 A framework for the use of the existing MPLS data plane to =A0=A0=A0 support tunnel-based unicast source routing.

=A0=A0=A0 Develop use cases for tunnel-based unicast source routing =A0=A0=A0 that demonstrate the need and support for solutions. Care =A0=A0=A0 should be taken to avoid clustering use cases that might seem=
=A0 =A0 to imply support for multiple use cases when only some of the <= br> =A0=A0=A0 cluster actually have wide-scale support.

=A0=A0=A0 Develop ISIS and OSPF protocol extensions necessary for
=A0=A0 distribution of MPLS forwarding information.

=A0=A0=A0 The working group will consider management (including=A0
=A0=A0=A0 configuration, reporting, diagnostics, and OAM) and security =
=A0=A0=A0 implications of its work and document them in separate
=A0=A0=A0 documents as appropriate.

=A0=A0=A0 The working group is not chartered to make any changes to =A0=A0=A0 the MPLS or IPv6 data planes. Any proposed changes to the =A0=A0=A0 data planes are to be specified in the working groups responsible
=A0=A0=A0 for the data planes (that is, the MPLS and 6MAN working group= s,=A0
=A0=A0=A0 respectively).

- Stewart


_________________________________________= ______
status mailing list
status@ietf.org = https://www.ietf.org/mailman/listinfo/status



--047d7b66f907737ad104e58ebfa5-- From stephane.litkowski@orange.com Wed Sep 4 07:00:46 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A351C11E81B5 for ; Wed, 4 Sep 2013 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00O5Py+m2Oxn for ; Wed, 4 Sep 2013 07:00:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id C4BE621E80C2 for ; Wed, 4 Sep 2013 07:00:41 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id AEF0D1911B1; Wed, 4 Sep 2013 16:00:36 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 90B4F3840D0; Wed, 4 Sep 2013 16:00:36 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 4 Sep 2013 16:00:35 +0200 From: To: Anoop Ghanwani , "status@ietf.org" Date: Wed, 4 Sep 2013 16:00:35 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6pclOGdx36NzIbRiiH6Ctt1EO4iQABGbog Message-ID: <18365_1378303236_52273D04_18365_16913_1_EEE55384044474429A926C625D0FCC810963161D72@PUEXCB2F.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.4.120616 Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 14:00:46 -0000 --_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some folks use BGP to perform the function of an IGP. It looks like the pr= oposed charter would exclude them from taking advantage of this technology.= It might be worthwhile adding BGP to that list of protocols to be enhance= d for this. [SLI] The charter must not mention any protocol. In the charter, first we m= ust do an analysis, then see which protocols must be fixed and how. But the= charter must not define the solution :) ________________________________ De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de= Anoop Ghanwani Envoy=E9 : mercredi 4 septembre 2013 15:26 =C0 : status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the next steps Some folks use BGP to perform the function of an IGP. It looks like the pr= oposed charter would exclude them from taking advantage of this technology.= It might be worthwhile adding BGP to that list of protocols to be enhance= d for this. With respect to the text about working with existing data paths -- I wonder= if there is some way to capture that it might not work with all existing i= mplementations. For example, the number of labels required to be pushed at= the ingress device may prevent some existing implementations from taking a= dvantage of this technology, depending on the size of the topology. Anoop On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant > wrote: May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Some folks use BGP to perform the function of a= n IGP.=20  It looks like the proposed charter would exclude them from taking=20 advantage of this technology.  It might be worthwhile adding BGP to th= at=20 list of protocols to be enhanced for this.
 
[SLI] The charter must not mention any protocol. In the charter, f= irst we=20 must do an analysis, then see which protocols must be fixed and how. But th= e=20 charter must not define the solution :)
 
 
 

De : status-bounces@ietf.org=20 [mailto:status-bounces@ietf.org] De la part de Anoop=20 Ghanwani
Envoy=E9 : mercredi 4 septembre 2013=20 15:26
=C0 : status@ietf.org
Objet : Re: [St= atus]=20 Summary of STATUS BOF and the next steps

Some folks use BGP to perform the function of an IGP. &nbs= p;It=20 looks like the proposed charter would exclude them from taking advantage = of=20 this technology.  It might be worthwhile adding BGP to that list of= =20 protocols to be enhanced for this.

With respect to the text about working with existing data paths -- I= =20 wonder if there is some way to capture that it might not work with all=20 existing implementations.  For example, the number of labels require= d to=20 be pushed at the ingress device may prevent some existing implementations= from=20 taking advantage of this technology, depending on the size of the=20 topology.

Anoop


On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <stbryant@cisco.com> wrote:

May I suggest that we use= the name=20 "SR" and worry
about what it binds to later.

The higher prior= ity=20 item is the charter text. Does
anyone have any comments on the text= =20 proposed
so far, or the text in the BOF proposal:


The Sta= cked=20 Tunnels for Source Routing (STATUS) Working Group
is chartered to= =20 develop a framework and use cases for source-routed
flows in packet= =20 switched networks.

IP previously had a source-based routing mech= anism=20 made
available through an IP Option. This mechanism has, however,= =20
not been widely used and has a number of issues that make its
u= se=20 inadvisable, and other mechanisms (such as RFC 1940)
do not appear = to=20 have been implemented at all.

The ability of a router to influen= ce or=20 control the forwarding
path of an individual packet or all the pack= ets=20 of a given
Forwarding Equivalence Class (FEC) is a desirable featur= e=20
for a number of reasons including Label Switched Path stitching,=20
egress protection, explicit routing, egress ASBR link selection, and=20 backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This = can=20 be achieved by facilitating source-initiated
selection of routes to= =20 complement the route selection
provided by existing routing protoco= ls=20 for both inter- domain
and intra-domain routes.

Historically= ,=20 distribution of MPLS label binding information
was done by relying = on=20 label distribution protocols
such as LDP and RSVP-TE.

The us= e=20 cases documented by the working group will
indicate the network fun= ction=20 that is being facilitated
and indicate which packet data plane is t= o be=20 used.

The framework developed by the working group will
cons= ider=20 forwarding of IPv4, IPv6, and MPLS using the
existing unicast data= =20 planes. Multicast forwarding will
be for future study and the choic= e of=20 data planes will
be limited to those for which use cases exist. A k= ey=20
objective of the work will be to ensure that source-
routed pack= ets=20 can be handled seamlessly by existing
deployed equipment. A major= =20 objective will be that the
new function does not modify existing da= ta=20 plane behavior
or architectures, and that it can be enabled through= only=20
control and management plane software upgrades at
deployed=20 devices.

Once the working group has established a framework
= and=20 there is demonstrable consensus for use cases,
the working group wi= ll=20 move forward to specify protocol
solutions for installing forwardin= g=20 information through
the use of the IGPs (OSPF and IS-IS), or throug= h the=20
management plane. In the course of developing protocol
extensio= ns,=20 the working group will work closely with
other IETF working groups= =20 responsible for the protocols
being modified (such as OSPF, ISIS, a= nd=20 I2RS).

    The working group is chartered for the= =20 following work items:

    A framework for the use= of=20 the existing MPLS data plane to
    support tunnel-b= ased=20 unicast source routing.

    Develop use cases fo= r=20 tunnel-based unicast source routing
    that demonst= rate=20 the need and support for solutions. Care
    should = be=20 taken to avoid clustering use cases that might seem
    to= =20 imply support for multiple use cases when only some of the=20
    cluster actually have wide-scale support.=20

    Develop ISIS and OSPF protocol extensions=20 necessary for
   distribution of MPLS forwarding informat= ion.=20

    The working group will consider management= =20 (including 
    configuration, reporting,=20 diagnostics, and OAM) and security
    implications = of=20 its work and document them in separate
    documents= as=20 appropriate.

    The working group is not charte= red=20 to make any changes to
    the MPLS or IPv6 data pla= nes.=20 Any proposed changes to the
    data planes are to b= e=20 specified in the working groups responsible
    for = the=20 data planes (that is, the MPLS and 6MAN working groups, =20
    respectively).
-=20 Stewart


_______________________________________________
stat= us=20 mailing list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status


__________________________________________________________________________= _______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810963161D72PUEXCB2Fnante_-- From Peter.AshwoodSmith@huawei.com Wed Sep 4 07:01:57 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B5321E80D1 for ; Wed, 4 Sep 2013 07:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.545 X-Spam-Level: X-Spam-Status: No, score=-5.545 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sJ4JosL9UiD for ; Wed, 4 Sep 2013 07:01:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7721E80D0 for ; Wed, 4 Sep 2013 07:01:50 -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.5-GA FastPath queued) with ESMTP id AWX04536; Wed, 04 Sep 2013 14:01:43 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 15:00:53 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 15:01:08 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 07:01:05 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgADYLICAAI5BAP//xVKw Date: Wed, 4 Sep 2013 14:01:03 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> In-Reply-To: <52270A74.7010707@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.231] Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 14:01:57 -0000 --_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like us to have the door open to changes in the data plane in the f= uture. The text as written pretty much closes that door. Naturally it makes sense to focus on what current hardware can do, but we n= eed to be forward looking and to make recommendations on what changes would= be useful in the future. Peter From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Wednesday, September 04, 2013 6:25 AM To: Mach Chen Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart --_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like us to have t= he door open to changes in the data plane in the future.

 <= /p>

The text as written prett= y much closes that door.

 <= /p>

Naturally it makes sense = to focus on what current hardware can do, but we need to be forward looking= and to make recommendations on what changes would be useful in the future.

 <= /p>

Peter

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@ie= tf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione = (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@i= etf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327dfweml513mbbchi_-- From mark@townsley.net Wed Sep 4 07:18:25 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6219721F9A19 for ; Wed, 4 Sep 2013 07:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7AETq+Y48N2 for ; Wed, 4 Sep 2013 07:18:20 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id F27E421F93D4 for ; Wed, 4 Sep 2013 07:18:19 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id l10so217757eei.21 for ; Wed, 04 Sep 2013 07:18:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=70oDxmThz80cEytqsG82JW4JqxEGTmaJLySUfk38XnQ=; b=E0J2Mk4NQnEI65bE0fpJqbxfeGlMJMn3O5UT1OoRdqNqM6/2Z/rmZ6U1h7PTohHfMg e956O8D032dI6t1IMnJoVnmX1lSKSRlcqmDyz0N3jY+gnFj6XwSOTZ6N0o/EXZ1amMD+ Fbz0xUl7ZepH3dtwACHpzjLvINgQf0uT1HzcVF1YbdeXDFjey2KbDclKUMqnVpBsX+PE 5WnJKnkR+GrGv7oz47GweNV/oYZASmtfQlsvabsrj2ua6JipVEXflx8RM1warcACBN2e gvSmBxTJ1nIagxObec88LxdMlATy4w2beOwrJJtPHH3jnRx9c/U9JjlEPxmaC43sBlUb Rq5g== X-Gm-Message-State: ALoCoQmfCBunyHNjhTZLSJAj6cMIcPH1XydmFsDlbIZqV163jJnUk1gM4WFBqysindJD62VoAJ44 X-Received: by 10.14.45.70 with SMTP id o46mr5169331eeb.19.1378304297619; Wed, 04 Sep 2013 07:18:17 -0700 (PDT) Received: from ams-townsley-8913.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id k7sm40368422eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Sep 2013 07:18:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401" From: Mark Townsley In-Reply-To: Date: Wed, 4 Sep 2013 16:18:11 +0200 Message-Id: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> References: To: Anoop Ghanwani X-Mailer: Apple Mail (2.1283) Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 14:18:25 -0000 --Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote: > Some folks use BGP to perform the function of an IGP. It looks like = the proposed charter would exclude them from taking advantage of this = technology. It might be worthwhile adding BGP to that list of protocols = to be enhanced for this. I agree that the statement "Develop ISIS and OSPF protocol extensions = necessary for distribution of MPLS forwarding information." needs work, = for two reasons. First, the extensions may not be strictly MPLS if the = goal is to make this work for MPLS and IPv6. Second, I think it would be = better for the ISIS and OSPF WGs to advance their own protocol = extensions, rather than including that within the charter of SR as a = deliverable. BGP, or any other routing protocol, could then adopt SR = based on its own level of interest in that WG to do so. Would that = suffice? - Mark > With respect to the text about working with existing data paths -- I = wonder if there is some way to capture that it might not work with all = existing implementations. For example, the number of labels required to = be pushed at the ingress device may prevent some existing = implementations from taking advantage of this technology, depending on = the size of the topology. >=20 > Anoop >=20 >=20 > On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant = wrote: >=20 > May I suggest that we use the name "SR" and worry > about what it binds to later. >=20 > The higher priority item is the charter text. Does > anyone have any comments on the text proposed > so far, or the text in the BOF proposal: >=20 >=20 > The Stacked Tunnels for Source Routing (STATUS) Working Group=20 > is chartered to develop a framework and use cases for source-routed=20 > flows in packet switched networks. >=20 > IP previously had a source-based routing mechanism made=20 > available through an IP Option. This mechanism has, however,=20 > not been widely used and has a number of issues that make its=20 > use inadvisable, and other mechanisms (such as RFC 1940)=20 > do not appear to have been implemented at all. >=20 > The ability of a router to influence or control the forwarding=20 > path of an individual packet or all the packets of a given=20 > Forwarding Equivalence Class (FEC) is a desirable feature=20 > for a number of reasons including Label Switched Path stitching,=20 > egress protection, explicit routing, egress ASBR link selection,=20 > and backup (bypass tunnels, Remote Loop-Free Alternates)=20 > routing. This can be achieved by facilitating source-initiated=20 > selection of routes to complement the route selection=20 > provided by existing routing protocols for both inter- domain=20 > and intra-domain routes. >=20 > Historically, distribution of MPLS label binding information=20 > was done by relying on label distribution protocols=20 > such as LDP and RSVP-TE. >=20 > The use cases documented by the working group will=20 > indicate the network function that is being facilitated=20 > and indicate which packet data plane is to be used. >=20 > The framework developed by the working group will=20 > consider forwarding of IPv4, IPv6, and MPLS using the=20 > existing unicast data planes. Multicast forwarding will=20 > be for future study and the choice of data planes will=20 > be limited to those for which use cases exist. A key=20 > objective of the work will be to ensure that source- > routed packets can be handled seamlessly by existing=20 > deployed equipment. A major objective will be that the=20 > new function does not modify existing data plane behavior=20 > or architectures, and that it can be enabled through only=20 > control and management plane software upgrades at=20 > deployed devices. >=20 > Once the working group has established a framework=20 > and there is demonstrable consensus for use cases,=20 > the working group will move forward to specify protocol=20 > solutions for installing forwarding information through=20 > the use of the IGPs (OSPF and IS-IS), or through the=20 > management plane. In the course of developing protocol=20 > extensions, the working group will work closely with=20 > other IETF working groups responsible for the protocols=20 > being modified (such as OSPF, ISIS, and I2RS). >=20 > The working group is chartered for the following work items: >=20 > A framework for the use of the existing MPLS data plane to=20 > support tunnel-based unicast source routing.=20 >=20 > Develop use cases for tunnel-based unicast source routing=20 > that demonstrate the need and support for solutions. Care=20 > should be taken to avoid clustering use cases that might seem > to imply support for multiple use cases when only some of the=20 > cluster actually have wide-scale support.=20 >=20 > Develop ISIS and OSPF protocol extensions necessary for=20 > distribution of MPLS forwarding information.=20 >=20 > The working group will consider management (including =20 > configuration, reporting, diagnostics, and OAM) and security=20 > implications of its work and document them in separate=20 > documents as appropriate.=20 >=20 > The working group is not chartered to make any changes to=20 > the MPLS or IPv6 data planes. Any proposed changes to the=20 > data planes are to be specified in the working groups responsible=20= > for the data planes (that is, the MPLS and 6MAN working groups, =20= > respectively). >=20 > - Stewart >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status --Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Some folks use BGP to perform the = function of an IGP.  It looks like the proposed charter would = exclude them from taking advantage of this technology.  It might be = worthwhile adding BGP to that list of protocols to be enhanced for = this.

I agree that the = statement "Develop ISIS and OSPF protocol extensions necessary for = distribution of MPLS forwarding information." needs work, for two = reasons. First, the extensions may not be strictly MPLS if the goal is = to make this work for MPLS and IPv6. Second, I think it would be = better for the ISIS and OSPF WGs to advance their own protocol = extensions, rather than including that within the charter of SR as a = deliverable. BGP, or any other routing protocol, could then adopt SR = based on its own level of interest in that WG to do so. Would that = suffice?

- Mark

With respect to the = text about working with existing data paths -- I wonder if there is some = way to capture that it might not work with all existing implementations. =  For example, the number of labels required to be pushed at the = ingress device may prevent some existing implementations from taking = advantage of this technology, depending on the size of the = topology.

Anoop


On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant <stbryant@cisco.com> wrote:
=20 =20 =20

May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:

=20
The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching, =
egress protection, explicit routing, egress ASBR link selection, =
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following = work items:

    A framework for the use of the existing MPLS data = plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source = routing
    that demonstrate the need and support for = solutions. Care
    should be taken to avoid clustering use cases = that might seem
    to imply support for multiple use cases when only some = of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions = necessary for
   distribution of MPLS forwarding information.

    The working group will consider management = (including 
    configuration, reporting, diagnostics, and OAM) = and security
    implications of its work and document them in = separate
    documents as appropriate.

    The working group is not chartered to make any = changes to
    the MPLS or IPv6 data planes. Any proposed = changes to the
    data planes are to be specified in the working = groups responsible
    for the data planes (that is, the MPLS and 6MAN = working groups, 
    respectively).

- Stewart


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



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

= --Apple-Mail=_08A703D3-6D68-4939-AB7B-DD66A9A99401-- From Ruediger.Geib@telekom.de Wed Sep 4 07:21:26 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CAA21F9A19 for ; Wed, 4 Sep 2013 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq++rZnXBDGK for ; Wed, 4 Sep 2013 07:21:21 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 3139011E81C8 for ; Wed, 4 Sep 2013 07:21:20 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 04 Sep 2013 16:21:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Wed, 4 Sep 2013 16:21:14 +0200 From: To: Date: Wed, 4 Sep 2013 16:21:13 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgADYLICAAI5BAP//xVKwgAAGaLA= Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_" MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 14:21:26 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter, no objection, if you address phase 2 of SR. So whatever is done in phase 1,= it should not exclude future changes to the data plane. SR Phase 1, which = is chartered now, should exclude changes to the existing data plane. Let's = stay focused. Regards, Ruediger ________________________________ From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= AshwoodsmithPeter Sent: Wednesday, September 04, 2013 4:01 PM To: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps I would like us to have the door open to changes in the data plane in the f= uture. The text as written pretty much closes that door. Naturally it makes sense to focus on what current hardware can do, but we n= eed to be forward looking and to make recommendations on what changes would= be useful in the future. Peter From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Wednesday, September 04, 2013 6:25 AM To: Mach Chen Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart --_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Peter,
 
no objection, if you address phase 2 of SR.= So=20 whatever is done in phase 1, it should not exclude future changes to the da= ta=20 plane. SR Phase 1, which is chartered now, should exclude changes to the=20 existing data plane. Let's stay focused.
 
Regards,
 
Ruediger

From: status-bounces@ietf.org=20 [mailto:status-bounces@ietf.org] On Behalf Of=20 AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 4:01=20 PM
To: status@ietf.org
Subject: Re: [Status] Summary of= =20 STATUS BOF and the next steps

I=20 would like us to have the door open to changes in the data plane in the= =20 future.

 

The=20 text as written pretty much closes that door.

 

Naturally=20 it makes sense to focus on what current hardware can do, but we need to be= =20 forward looking and to make recommendations on what changes would be useful= in=20 the future.

 

Peter

 

From:=20 status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of=20 Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25=20 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victo= r=20 Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvar= o=20 Retana (aretana); status@ietf.org
Subject: Re: [Status] Summary o= f=20 STATUS BOF and the next steps

 


May I suggest that w= e use the=20 name "SR" and worry
about what it binds to later.

The higher prio= rity=20 item is the charter text. Does
anyone have any comments on the text=20 proposed
so far, or the text in the BOF proposal:


The Stacked= =20 Tunnels for Source Routing (STATUS) Working Group
is chartered to devel= op a=20 framework and use cases for source-routed
flows in packet switched=20 networks.

IP previously had a source-based routing mechanism made=20
available through an IP Option. This mechanism has, however,
not be= en=20 widely used and has a number of issues that make its
use inadvisable, a= nd=20 other mechanisms (such as RFC 1940)
do not appear to have been implemen= ted=20 at all.

The ability of a router to influence or control the forwardi= ng=20
path of an individual packet or all the packets of a given
Forwardi= ng=20 Equivalence Class (FEC) is a desirable feature
for a number of reasons= =20 including Label Switched Path stitching,
egress protection, explicit=20 routing, egress ASBR link selection,
and backup (bypass tunnels, Remote= =20 Loop-Free Alternates)
routing. This can be achieved by facilitating=20 source-initiated
selection of routes to complement the route selection= =20
provided by existing routing protocols for both inter- domain
and=20 intra-domain routes.

Historically, distribution of MPLS label bindin= g=20 information
was done by relying on label distribution protocols
suc= h as=20 LDP and RSVP-TE.

The use cases documented by the working group will= =20
indicate the network function that is being facilitated
and indicat= e=20 which packet data plane is to be used.

The framework developed by th= e=20 working group will
consider forwarding of IPv4, IPv6, and MPLS using th= e=20
existing unicast data planes. Multicast forwarding will
be for futu= re=20 study and the choice of data planes will
be limited to those for which = use=20 cases exist. A key
objective of the work will be to ensure that=20 source-
routed packets can be handled seamlessly by existing
deploye= d=20 equipment. A major objective will be that the
new function does not mod= ify=20 existing data plane behavior
or architectures, and that it can be enabl= ed=20 through only
control and management plane software upgrades at
depl= oyed=20 devices.

Once the working group has established a framework
and = there=20 is demonstrable consensus for use cases,
the working group will move fo= rward=20 to specify protocol
solutions for installing forwarding information thr= ough=20
the use of the IGPs (OSPF and IS-IS), or through the
management pla= ne.=20 In the course of developing protocol
extensions, the working group will= work=20 closely with
other IETF working groups responsible for the protocols=20
being modified (such as OSPF, ISIS, and I2RS).

   = ; The=20 working group is chartered for the following work=20 items:

    A framework for the use of the existing MP= LS=20 data plane to
    support tunnel-based unicast source=20 routing.

    Develop use cases for tunnel-based unic= ast=20 source routing
    that demonstrate the need and support= for=20 solutions. Care
    should be taken to avoid clustering = use=20 cases that might seem
    to imply support for multiple use ca= ses=20 when only some of the
    cluster actually have wide-sca= le=20 support.

    Develop ISIS and OSPF protocol extensio= ns=20 necessary for
   distribution of MPLS forwarding information.= =20

    The working group will consider management=20 (including 
    configuration, reporting, diagnosti= cs,=20 and OAM) and security
    implications of its work and=20 document them in separate
    documents as appropriate.= =20

    The working group is not chartered to make any=20 changes to
    the MPLS or IPv6 data planes. Any propose= d=20 changes to the
    data planes are to be specified in th= e=20 working groups responsible
    for the data planes (that= is,=20 the MPLS and 6MAN working groups, 
   =20 respectively).

- Stewart

--_000_CA7A7C64CC4ADB458B74477EA99DF6F501F563C27EHE111643EMEA1_-- From jdrake@juniper.net Wed Sep 4 07:26:44 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D047011E812E for ; Wed, 4 Sep 2013 07:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ2W2mzIqCf0 for ; Wed, 4 Sep 2013 07:26:38 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5710B21F9DF3 for ; Wed, 4 Sep 2013 07:26:38 -0700 (PDT) Received: from mail109-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Sep 2013 14:26:37 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id 987BD3800CE; Wed, 4 Sep 2013 14:26:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(z551biz9371Ic85fhec9Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail109-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(37854004)(189002)(199002)(77982001)(59766001)(54316002)(76482001)(53806001)(54356001)(56776001)(76576001)(56816003)(77096001)(76796001)(74662001)(76786001)(47446002)(79102001)(74502001)(63696002)(31966008)(16236675002)(15202345003)(15975445006)(47736001)(47976001)(49866001)(50986001)(4396001)(81342001)(81542001)(81816001)(74706001)(46102001)(74366001)(81686001)(80022001)(74876001)(65816001)(19300405004)(69226001)(83072001)(561944002)(66066001)(33646001)(74316001)(51856001)(80976001)(83322001)(19580405001)(19580395003)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.36; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1378304795115746_19333; Wed, 4 Sep 2013 14:26:35 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id 0F3CC300041; Wed, 4 Sep 2013 14:26:35 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Sep 2013 14:26:34 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 4 Sep 2013 14:26:31 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 4 Sep 2013 14:26:29 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Wed, 4 Sep 2013 14:26:28 +0000 From: John E Drake To: AshwoodsmithPeter , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbKMNMppxiDdAEC+H+M4LHfrLJmv7eKAgAEZNwCAABkbgIAC3wVggADZHICAAI5BAIAAPGeAgAAGm7A= Date: Wed, 4 Sep 2013 14:26:28 +0000 Message-ID: <6831c7c2579c42bfb63573e464cf66cc@BY2PR05MB142.namprd05.prod.outlook.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.36] x-forefront-prvs: 095972DF2F Content-Type: multipart/alternative; boundary="_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 14:26:44 -0000 --_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter, The group's charter can always be amended in the future, but I don't think = it's good to declare open season on the MPLS data plane initially. Yours Irrespectively, John From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= AshwoodsmithPeter Sent: Wednesday, September 04, 2013 7:01 AM To: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps I would like us to have the door open to changes in the data plane in the f= uture. The text as written pretty much closes that door. Naturally it makes sense to focus on what current hardware can do, but we n= eed to be forward looking and to make recommendations on what changes would= be useful in the future. Peter From: status-bounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, September 04, 2013 6:25 AM To: Mach Chen Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org= Subject: Re: [Status] Summary of STATUS BOF and the next steps May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart --_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter,<= /p>

 <= /p>

The group’s charter= can always be amended in the future, but I don’t think it’s go= od to declare open season on the MPLS data plane initially.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@= ietf.org] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 

I would like us to have t= he door open to changes in the data plane in the future.

 <= /p>

The text as written prett= y much closes that door.

 <= /p>

Naturally it makes sense = to focus on what current hardware can do, but we need to be forward looking= and to make recommendations on what changes would be useful in the future.

 <= /p>

Peter

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione = (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart

--_000_6831c7c2579c42bfb63573e464cf66ccBY2PR05MB142namprd05pro_-- From ghanwani@gmail.com Wed Sep 4 07:40:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B540721E80B7 for ; Wed, 4 Sep 2013 07:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvmpfiAJOim3 for ; Wed, 4 Sep 2013 07:40:44 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id F039321E809E for ; Wed, 4 Sep 2013 07:40:41 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id l18so428652wgh.4 for ; Wed, 04 Sep 2013 07:40:41 -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=Znnze/gkHnIbxnYXOdXkNJ/7kLnOF4W/xOkkfHUIjAA=; b=EsFH7IO2LH92oC5YT+eKotbF3pOPsKgWExH8pNV2Q9w+o0JAOkdUuEFErHr4yzbv8X wHSTBc8G0vFDAD3N6wv5Xxp6s0qnqRkN2nXW6uHhRKGhOUuUafZvihpVJaCGIc9pphyR RTzrdT+Kd0Tb5+cCVhft6MNjv7nTLfSDcMLgrowuuepPbKEUpj/686WvwfP0o77O/5A+ xR03G1xHG2nzAWry+kmBJ6hamtzSD+4vVdQugjjH887OGvF8xtJwHJa4L6ExdVTp6Aco cDe0k0xIpnZHSqXecfUW3BjjGQGzb9N5yT2/wzKOH321AQFkJUUDbobjPxYL0ran9/ix KTQw== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr2397333wic.60.1378305641127; Wed, 04 Sep 2013 07:40:41 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Wed, 4 Sep 2013 07:40:40 -0700 (PDT) In-Reply-To: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> Date: Wed, 4 Sep 2013 07:40:40 -0700 X-Google-Sender-Auth: Ff8BbujVZoOxiQFn5Q1ugrnRpXg Message-ID: From: Anoop Ghanwani To: Mark Townsley Content-Type: multipart/alternative; boundary=001a11c227ee21a7a204e58fca05 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 14:40:49 -0000 --001a11c227ee21a7a204e58fca05 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 4, 2013 at 7:18 AM, Mark Townsley wrote: > > On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote: > > Some folks use BGP to perform the function of an IGP. It looks like the > proposed charter would exclude them from taking advantage of this > technology. It might be worthwhile adding BGP to that list of protocols to > be enhanced for this. > > > I agree that the statement "Develop ISIS and OSPF protocol extensions > necessary for distribution of MPLS forwarding information." needs work, for > two reasons. First, the extensions may not be strictly MPLS if the goal is > to make this work for MPLS and IPv6. Second, I think it would be better for > the ISIS and OSPF WGs to advance their own protocol extensions, rather than > including that within the charter of SR as a deliverable. BGP, or any other > routing protocol, could then adopt SR based on its own level of interest in > that WG to do so. Would that suffice? > Yes, I think that would be reasonable. Anoop --001a11c227ee21a7a204e58fca05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 4, 2013 at 7:18 AM, Mark Townsley <= ;mark@townsley.net> wrote:

On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote:
Some folks use BGP to perfor= m the function of an IGP. =A0It looks like the proposed charter would exclu= de them from taking advantage of this technology. =A0It might be worthwhile= adding BGP to that list of protocols to be enhanced for this.

I agree that the statement &qu= ot;Develop ISIS and OSPF protocol extensions necessary for distribution of = MPLS forwarding information." needs work, for two reasons. First, the = extensions may not be strictly MPLS if the goal is to make this work for MP= LS and IPv6. Second, I think it would=A0be better for the ISIS and OSPF WGs= to advance their own protocol extensions, rather than including that withi= n the charter of SR as a deliverable. BGP, or any other routing protocol, c= ould then adopt SR based on its own level of interest in that WG to do so. = Would that suffice?

Yes, I think that would be rea= sonable.

Anoop=A0
--001a11c227ee21a7a204e58fca05-- From rjs@rob.sh Wed Sep 4 11:57:27 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1DC11E812E for ; Wed, 4 Sep 2013 11:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.464 X-Spam-Level: X-Spam-Status: No, score=0.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcgZtLYI9-LC for ; Wed, 4 Sep 2013 11:57:26 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id A4D5711E810B for ; Wed, 4 Sep 2013 11:57:25 -0700 (PDT) Received: from [212.183.132.59] (helo=[10.229.17.183]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VHIFk-00004t-2J; Wed, 04 Sep 2013 19:56:32 +0100 References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> <6831c7c2579c42bfb63573e464cf66cc@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <6831c7c2579c42bfb63573e464cf66cc@BY2PR05MB142.namprd05.prod.outlook.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD Message-Id: <0D84FF8C-2A4A-4B04-A21B-D82B54CBC216@rob.sh> X-Mailer: iPhone Mail (10B329) From: Rob Shakir Date: Wed, 4 Sep 2013 19:56:37 +0100 To: John E Drake Cc: "status@ietf.org" , AshwoodsmithPeter Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 18:57:27 -0000 --Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Right. Day 1 we need this to work with things that are deployable in real an= d existing networks, but I think this should not stop us defining the charte= r to write a data plane agnostic architecture, which can then have documents= describing how it is implemented in each data plane we want to use.=20 This way we can define the features that we need - or at least desirable - a= nd then work out how they are realised (some existing data planes may not be= able to support all desirable features - an example is retaining the full p= ath at all hops). It also reduces duplication across the data plane instance= specs.=20 =46rom my perspective this means the charter must include an architecture de= liverable plus one defining the MPLS data plane. Based on the assessment of t= he BoF it should also include one for lPv6. This would not preclude future d= ata planes from being added to the charter and reusing all the output of the= WG sometime down the line.=20 r.=20 Sent from my iPhone On 4 Sep 2013, at 15:26, John E Drake wrote: > Peter, > =20 > The group=E2=80=99s charter can always be amended in the future, but I don= =E2=80=99t think it=E2=80=99s good to declare open season on the MPLS data p= lane initially. > =20 > Yours Irrespectively, > =20 > John > =20 > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf O= f AshwoodsmithPeter > Sent: Wednesday, September 04, 2013 7:01 AM > To: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > =20 > I would like us to have the door open to changes in the data plane in the f= uture. > =20 > The text as written pretty much closes that door. > =20 > Naturally it makes sense to focus on what current hardware can do, but we n= eed to be forward looking and to make recommendations on what changes would b= e useful in the future. > =20 > Peter > =20 > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf O= f Stewart Bryant > Sent: Wednesday, September 04, 2013 6:25 AM > To: Mach Chen > Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmg= l); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org= > Subject: Re: [Status] Summary of STATUS BOF and the next steps > =20 >=20 > May I suggest that we use the name "SR" and worry > about what it binds to later. >=20 > The higher priority item is the charter text. Does > anyone have any comments on the text proposed > so far, or the text in the BOF proposal: >=20 >=20 > The Stacked Tunnels for Source Routing (STATUS) Working Group=20 > is chartered to develop a framework and use cases for source-routed=20 > flows in packet switched networks. >=20 > IP previously had a source-based routing mechanism made=20 > available through an IP Option. This mechanism has, however,=20 > not been widely used and has a number of issues that make its=20 > use inadvisable, and other mechanisms (such as RFC 1940)=20 > do not appear to have been implemented at all. >=20 > The ability of a router to influence or control the forwarding=20 > path of an individual packet or all the packets of a given=20 > Forwarding Equivalence Class (FEC) is a desirable feature=20 > for a number of reasons including Label Switched Path stitching,=20 > egress protection, explicit routing, egress ASBR link selection,=20 > and backup (bypass tunnels, Remote Loop-Free Alternates)=20 > routing. This can be achieved by facilitating source-initiated=20 > selection of routes to complement the route selection=20 > provided by existing routing protocols for both inter- domain=20 > and intra-domain routes. >=20 > Historically, distribution of MPLS label binding information=20 > was done by relying on label distribution protocols=20 > such as LDP and RSVP-TE. >=20 > The use cases documented by the working group will=20 > indicate the network function that is being facilitated=20 > and indicate which packet data plane is to be used. >=20 > The framework developed by the working group will=20 > consider forwarding of IPv4, IPv6, and MPLS using the=20 > existing unicast data planes. Multicast forwarding will=20 > be for future study and the choice of data planes will=20 > be limited to those for which use cases exist. A key=20 > objective of the work will be to ensure that source- > routed packets can be handled seamlessly by existing=20 > deployed equipment. A major objective will be that the=20 > new function does not modify existing data plane behavior=20 > or architectures, and that it can be enabled through only=20 > control and management plane software upgrades at=20 > deployed devices. >=20 > Once the working group has established a framework=20 > and there is demonstrable consensus for use cases,=20 > the working group will move forward to specify protocol=20 > solutions for installing forwarding information through=20 > the use of the IGPs (OSPF and IS-IS), or through the=20 > management plane. In the course of developing protocol=20 > extensions, the working group will work closely with=20 > other IETF working groups responsible for the protocols=20 > being modified (such as OSPF, ISIS, and I2RS). >=20 > The working group is chartered for the following work items: >=20 > A framework for the use of the existing MPLS data plane to=20 > support tunnel-based unicast source routing.=20 >=20 > Develop use cases for tunnel-based unicast source routing=20 > that demonstrate the need and support for solutions. Care=20 > should be taken to avoid clustering use cases that might seem > to imply support for multiple use cases when only some of the=20 > cluster actually have wide-scale support.=20 >=20 > Develop ISIS and OSPF protocol extensions necessary for=20 > distribution of MPLS forwarding information.=20 >=20 > The working group will consider management (including =20 > configuration, reporting, diagnostics, and OAM) and security=20 > implications of its work and document them in separate=20 > documents as appropriate.=20 >=20 > The working group is not chartered to make any changes to=20 > the MPLS or IPv6 data planes. Any proposed changes to the=20 > data planes are to be specified in the working groups responsible=20 > for the data planes (that is, the MPLS and 6MAN working groups, =20 > respectively). >=20 > - Stewart >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status --Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Right. Day 1 we nee= d this to work with things that are deployable in real and existing networks= , but I think this should not stop us defining the charter to write a data p= lane agnostic architecture, which can then have documents describing how it i= s implemented in each data plane we want to use. 

This way we can define the feat= ures that we need - or at least desirable - and then work out how they are r= ealised (some existing data planes may not be able to support all desirable f= eatures - an example is retaining the full path at all hops). It also reduce= s duplication across the data plane instance specs. 
<= span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(255, 25= 5, 255, 0);">
=46rom my perspective this m= eans the charter must include an architecture deliverable plus one defining t= he MPLS data plane. Based on the assessment of the BoF it should also includ= e one for lPv6. This would not preclude future data planes from being added t= o the charter and reusing all the output of the WG sometime down the line.&n= bsp;

r. 

Sent from my iPhone
=

Peter,

 

The group=E2=80=99s charter= can always be amended in the future, but I don=E2=80=99t think it=E2=80=99s= good to declare open season on the MPLS data plane initially.

 

Yours Irrespectively,<= /o:p>

 

John

 

From: status-b= ounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps

 

I would like us to have the= door open to changes in the data plane in the future.

 

The text as written pretty m= uch closes that door.

 

Naturally it makes sense to= focus on what current hardware can do, but we need to be forward looking an= d to make recommendations on what changes would be useful in the future.

 

Peter

=

 

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (= robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps

 


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work ite= ms:

    A framework for the use of the existing MPLS data plane t= o
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing=
    that demonstrate the need and support for solutions. Care=
    should be taken to avoid clustering use cases that might s= eem
    to imply support for multiple use cases when only some of the <= br>     cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for <= br>    distribution of MPLS forwarding information.

    The working group will consider management (including&nbs= p;
    configuration, reporting, diagnostics, and OAM) and secur= ity
    implications of its work and document them in separate     documents as appropriate.

    The working group is not chartered to make any changes to=
    the MPLS or IPv6 data planes. Any proposed changes to the=
    data planes are to be specified in the working groups res= ponsible
    for the data planes (that is, the MPLS and 6MAN working g= roups, 
    respectively).

- Stewart

_______________________________________________
status mailing list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status
= --Apple-Mail-166B02E9-174A-413E-A62C-7A0E832E66CD-- From Peter.AshwoodSmith@huawei.com Wed Sep 4 12:06:08 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D25811E81D5 for ; Wed, 4 Sep 2013 12:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEHZ8haCYQCd for ; Wed, 4 Sep 2013 12:06:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4274D11E812E for ; Wed, 4 Sep 2013 12:06:03 -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.5-GA FastPath queued) with ESMTP id AVB13286; Wed, 04 Sep 2013 19:06:02 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 20:05:43 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 20:06:00 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 12:05:54 -0700 From: AshwoodsmithPeter To: Rob Shakir , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgADYLICAAI5BAP//xVKwgAB+LwCAAEt6gP//jUAk Date: Wed, 4 Sep 2013 19:05:53 +0000 Message-ID: <746508F1-7E89-4C4B-9A11-9233C6985E3E@huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5327@dfweml513-mbb.china.huawei.com> <6831c7c2579c42bfb63573e464cf66cc@BY2PR05MB142.namprd05.prod.outlook.com>, <0D84FF8C-2A4A-4B04-A21B-D82B54CBC216@rob.sh> In-Reply-To: <0D84FF8C-2A4A-4B04-A21B-D82B54CBC216@rob.sh> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 19:06:08 -0000 --_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable strongly concur. Peter On Sep 4, 2013, at 2:57 PM, "Rob Shakir" > wr= ote: Right. Day 1 we need this to work with things that are deployable in real a= nd existing networks, but I think this should not stop us defining the char= ter to write a data plane agnostic architecture, which can then have docume= nts describing how it is implemented in each data plane we want to use. This way we can define the features that we need - or at least desirable - = and then work out how they are realised (some existing data planes may not = be able to support all desirable features - an example is retaining the ful= l path at all hops). It also reduces duplication across the data plane inst= ance specs. >From my perspective this means the charter must include an architecture del= iverable plus one defining the MPLS data plane. Based on the assessment of = the BoF it should also include one for lPv6. This would not preclude future= data planes from being added to the charter and reusing all the output of = the WG sometime down the line. r. Sent from my iPhone On 4 Sep 2013, at 15:26, John E Drake > wrote: Peter, The group=92s charter can always be amended in the future, but I don=92t th= ink it=92s good to declare open season on the MPLS data plane initially. Yours Irrespectively, John From: status-bounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of AshwoodsmithPeter Sent: Wednesday, September 04, 2013 7:01 AM To: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps I would like us to have the door open to changes in the data plane in the f= uture. The text as written pretty much closes that door. Naturally it makes sense to focus on what current hardware can do, but we n= eed to be forward looking and to make recommendations on what changes would= be useful in the future. Peter From: status-bounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, September 04, 2013 6:25 AM To: Mach Chen Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org= Subject: Re: [Status] Summary of STATUS BOF and the next steps May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status --_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
strongly concur.

Peter

On Sep 4, 2013, at 2:57 PM, "Rob Shakir" <rjs@rob.sh> wrote:

Right. Day 1 we need this to work with things that are = deployable in real and existing networks, but I think this should not stop = us defining the charter to write a data plane agnostic architecture, which can then have documents describing= how it is implemented in each data plane we want to use. 

This way we can define the features that we need - or a= t least desirable - and then work out how they are realised (some existing = data planes may not be able to support all desirable features - an example is retaining the full path at all hops= ). It also reduces duplication across the data plane instance specs. <= /span>

From my perspective this means the charter must include= an architecture deliverable plus one defining the MPLS data plane. Based o= n the assessment of the BoF it should also include one for lPv6. This would not preclude future data planes from= being added to the charter and reusing all the output of the WG sometime d= own the line. 

r. 

Sent from my iPhone<= /div>

On 4 Sep 2013, at 15:26, John E Drake <jdrake@juniper.net> wrote:

Peter,<= /p>

 <= /p>

The group=92s charter can= always be amended in the future, but I don=92t think it=92s good to declar= e open season on the MPLS data plane initially.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 

I would like us to have t= he door open to changes in the data plane in the future.

 <= /p>

The text as written prett= y much closes that door.

 <= /p>

Naturally it makes sense = to focus on what current hardware can do, but we need to be forward looking= and to make recommendations on what changes would be useful in the future.

 <= /p>

Peter

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione = (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart

_______________________________________________
status mailing list
status@ietf.org
https://www.= ietf.org/mailman/listinfo/status
--_000_746508F17E894C4B9A119233C6985E3Ehuaweicom_-- From swallow@cisco.com Wed Sep 4 14:38:58 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CC711E811E for ; Wed, 4 Sep 2013 14:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.765 X-Spam-Level: X-Spam-Status: No, score=-109.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11Vre8FFHsYf for ; Wed, 4 Sep 2013 14:38:53 -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 6133411E8100 for ; Wed, 4 Sep 2013 14:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22753; q=dns/txt; s=iport; t=1378330733; x=1379540333; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=b7ArRn4QWMjTalmDoDUVarsEcElQ8NP3w8ALxVb8GqM=; b=Ka5UyJzO2TIsCr3F9Z4qkbpxMcHvySNNNYM0bPIhNG+XI0vqMrOBPnxS EMoe/sf/8PlIWp4/tYqef+usucDv5XoqoKgP/Fop0mCjlaIRHjLt4QGcV MWLMJmJWzbRGiIppz1Nyj8B/uYxuzCOenzrN2jXGGQYlAcWgpRFOg0CWy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FACmnJ1KtJXG8/2dsb2JhbABagkNENVHBRIEoFnSCJAEBAQQBAQEqQQsSAQgRAQIBAQELHS4LFAMGCAIEAQ0FCBOHZwy6MQSODhMTew0TDQQGAQKDG4EAA6lbgyCBaAIeIg X-IronPort-AV: E=Sophos;i="4.90,1023,1371081600"; d="scan'208,217";a="252677801" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2013 21:38:51 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r84LcpNI005197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Sep 2013 21:38:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 4 Sep 2013 16:38:51 -0500 From: "George Swallow (swallow)" To: AshwoodsmithPeter , Rob Shakir , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJubBvTp7+4EUeVKd4J6oT3vpmwQbOAgAEZOACAABkbgIAC3/WAgADYLICAAI5BAIAAPGaAgAAHGgCAAEt7gIAAApeA///nrIA= Date: Wed, 4 Sep 2013 21:38:51 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB140E703F@xmb-rcd-x10.cisco.com> In-Reply-To: <746508F1-7E89-4C4B-9A11-9233C6985E3E@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.98.56.164] Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "George Swallow \(swallow\)" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 21:38:58 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I actually don't think it is possible to write a dataplane agnostic archite= cture. We can write an architecture document that is 90% dataplane indepe= ndent and then has some dataplane dependencies. E.g. having the full SR pa= th available at each hop vs the remainder. George From: AshwoodsmithPeter > Date: Wednesday, September 4, 2013 3:05 PM To: Rob Shakir >, "status@ietf.org" > Subject: Re: [Status] Summary of STATUS BOF and the next steps strongly concur. Peter On Sep 4, 2013, at 2:57 PM, "Rob Shakir" > wr= ote: Right. Day 1 we need this to work with things that are deployable in real a= nd existing networks, but I think this should not stop us defining the char= ter to write a data plane agnostic architecture, which can then have docume= nts describing how it is implemented in each data plane we want to use. This way we can define the features that we need - or at least desirable - = and then work out how they are realised (some existing data planes may not = be able to support all desirable features - an example is retaining the ful= l path at all hops). It also reduces duplication across the data plane inst= ance specs. >From my perspective this means the charter must include an architecture del= iverable plus one defining the MPLS data plane. Based on the assessment of = the BoF it should also include one for lPv6. This would not preclude future= data planes from being added to the charter and reusing all the output of = the WG sometime down the line. r. Sent from my iPhone On 4 Sep 2013, at 15:26, John E Drake > wrote: Peter, The group=92s charter can always be amended in the future, but I don=92t th= ink it=92s good to declare open season on the MPLS data plane initially. Yours Irrespectively, John From:status-bounces@ietf.org [mailto:status= -bounces@ietf.org] On Behalf Of AshwoodsmithPeter Sent: Wednesday, September 04, 2013 7:01 AM To: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps I would like us to have the door open to changes in the data plane in the f= uture. The text as written pretty much closes that door. Naturally it makes sense to focus on what current hardware can do, but we n= eed to be forward looking and to make recommendations on what changes would= be useful in the future. Peter From:status-bounces@ietf.org [mailto:status= -bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, September 04, 2013 6:25 AM To: Mach Chen Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl= ); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org= Subject: Re: [Status] Summary of STATUS BOF and the next steps May I suggest that we use the name "SR" and worry about what it binds to later. The higher priority item is the charter text. Does anyone have any comments on the text proposed so far, or the text in the BOF proposal: The Stacked Tunnels for Source Routing (STATUS) Working Group is chartered to develop a framework and use cases for source-routed flows in packet switched networks. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. The use cases documented by the working group will indicate the network function that is being facilitated and indicate which packet data plane is to be used. The framework developed by the working group will consider forwarding of IPv4, IPv6, and MPLS using the existing unicast data planes. Multicast forwarding will be for future study and the choice of data planes will be limited to those for which use cases exist. A key objective of the work will be to ensure that source- routed packets can be handled seamlessly by existing deployed equipment. A major objective will be that the new function does not modify existing data plane behavior or architectures, and that it can be enabled through only control and management plane software upgrades at deployed devices. Once the working group has established a framework and there is demonstrable consensus for use cases, the working group will move forward to specify protocol solutions for installing forwarding information through the use of the IGPs (OSPF and IS-IS), or through the management plane. In the course of developing protocol extensions, the working group will work closely with other IETF working groups responsible for the protocols being modified (such as OSPF, ISIS, and I2RS). The working group is chartered for the following work items: A framework for the use of the existing MPLS data plane to support tunnel-based unicast source routing. Develop use cases for tunnel-based unicast source routing that demonstrate the need and support for solutions. Care should be taken to avoid clustering use cases that might seem to imply support for multiple use cases when only some of the cluster actually have wide-scale support. Develop ISIS and OSPF protocol extensions necessary for distribution of MPLS forwarding information. The working group will consider management (including configuration, reporting, diagnostics, and OAM) and security implications of its work and document them in separate documents as appropriate. The working group is not chartered to make any changes to the MPLS or IPv6 data planes. Any proposed changes to the data planes are to be specified in the working groups responsible for the data planes (that is, the MPLS and 6MAN working groups, respectively). - Stewart _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status --_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I actually don't think it is possible to write a dataplane agnostic ar= chitecture.   We can write an architecture document that is 90% datapl= ane independent and then has some dataplane dependencies.  E.g. having= the full SR path available at each hop vs the remainder.

George

From: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com= >
Date: Wednesday, September 4, 2013 = 3:05 PM
To: Rob Shakir <rjs@rob.sh>, "= status@ietf.org" <status@iet= f.org>
Subject: Re: [Status] Summary of ST= ATUS BOF and the next steps

strongly concur.

Peter

On Sep 4, 2013, at 2:57 PM, "Rob Shakir" <rjs@rob.sh> wrote:

Right. Day 1 we need this to work with things that are = deployable in real and existing networks, but I think this should not stop = us defining the charter to write a data plane agnostic architecture, which can then have documents describing= how it is implemented in each data plane we want to use. 

This way we can define the features that we need - or a= t least desirable - and then work out how they are realised (some existing = data planes may not be able to support all desirable features - an example is retaining the full path at all hops= ). It also reduces duplication across the data plane instance specs. <= /span>

From my perspective this means the charter must include= an architecture deliverable plus one defining the MPLS data plane. Based o= n the assessment of the BoF it should also include one for lPv6. This would not preclude future data planes from= being added to the charter and reusing all the output of the WG sometime d= own the line. 

r. 

Sent from my iPhone<= /div>

On 4 Sep 2013, at 15:26, John E Drake <jdrake@juniper.net> wrote:

Peter,

 

The group=92s charter can always b= e amended in the future, but I don=92t think it=92s good to declare open se= ason on the MPLS data plane initially.

 

Yours Irrespectively,

 

John

 

From:status-bounces@ietf.org [mailto:status-bounces@ietf.org= ] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, September 04, 2013 7:01 AM
To: status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 

I would like us to have the door o= pen to changes in the data plane in the future.

 

The text as written pretty much cl= oses that door.

 

Naturally it makes sense to focus = on what current hardware can do, but we need to be forward looking and to m= ake recommendations on what changes would be useful in the future.

 

Peter

 

From:status-bounces@ietf.org [mailto:status-bounces@ietf.org= ] On Behalf Of Stewart Bryant
Sent: Wednesday, September 04, 2013 6:25 AM
To: Mach Chen
Cc: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione = (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org
Subject: Re: [Status] Summary of STATUS BOF and the next steps<= /o:p>

 


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart

_______________________________________________
status mailing list
status@ietf.org
https://www.= ietf.org/mailman/listinfo/status
 --_000_2FE467D3673DCE409A84D67EC2F607BB140E703Fxmbrcdx10ciscoc_-- From hannes@juniper.net Wed Sep 4 20:54:45 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0A11E815E for ; Wed, 4 Sep 2013 20:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lukwhPJ4tDiz for ; Wed, 4 Sep 2013 20:54:40 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6348011E80FA for ; Wed, 4 Sep 2013 20:54:39 -0700 (PDT) Received: from mail7-db9-R.bigfish.com (10.174.16.227) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 03:54:38 +0000 Received: from mail7-db9 (localhost [127.0.0.1]) by mail7-db9-R.bigfish.com (Postfix) with ESMTP id 44FC69000FE; Thu, 5 Sep 2013 03:54:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -70 X-BigFish: VPS-70(z551biz62a3I98dI9371Ic89bh936eI542I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail7-db9: domain of juniper.net designates 157.56.238.5 as permitted sender) client-ip=157.56.238.5; envelope-from=hannes@juniper.net; helo=BY2PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail7-db9 (localhost.localdomain [127.0.0.1]) by mail7-db9 (MessageSwitch) id 137835327573145_17072; Thu, 5 Sep 2013 03:54:35 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.251]) by mail7-db9.bigfish.com (Postfix) with ESMTP id 05E85A00041; Thu, 5 Sep 2013 03:54:35 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 03:54:34 +0000 Received: from mrepeti-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.243.34) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 03:54:31 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> Date: Thu, 5 Sep 2013 05:54:26 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 03:54:45 -0000 hi stephane, see comments inline prefixed by HG> On Sep 4, 2013, at 10:02 AM, = wrote: > case, we are using only directed forwarding (adjacency segment), = could we still talk about tunneling ? (it's a very very small tunnel) > Moreover talking about "stacking" is really dataplane agnostic (MPLS) = =85 HG> one-hop tunnels are ok; > In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking =85 the "moving pointer" is a requirement without an actual use case - do you know how this would be used ? - i don't > IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else =85 HG> closing door to things we have no (known) requirements for is ok; being anything to anybody is not helpful - the more concise the charter the better; > Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment = list. Actions associated with a segment could be something else than = forwarding. > Do we want in the charter to limit the scope to routing actions ? >=20 HG> as per the published use-case drafts all i have seen are use-cases = related to "forwarding". as far as i am concerned i am good limiting the scope to "routing actions". > I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. HG> good :-) > Regarding your charter proposal : >=20 > -------- >=20 > - They form a connected network > [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). HG> did i preclude inter-AS in any way ? > - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) > [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. HG> if you have a case for non-routing, please make it; - IIRC in our = past 6 months of conversation around IGP label advertisement / SR we haven't discussed = any non-routing use-case. > - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. > [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) HG> ok. > Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. > [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. HG> is there any application outside FRR for changing an explicit path ? > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >=20 > [SLI] Agree, I would add : > - defining the architecture framework > - analysing the security considerations HG> ok; >=20 >=20 > Here would be my proposal to extend yours : >=20 > A domain contains a set of routers with the = following characteristics: >=20 > - They form a connected network > - They can forward traffic through any path within the network using = shortest path, non shortest path or explicit path > - They may provide other types of services than forwarding and they = can enforce service actions in the path. > - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >=20 > The working group is chartered for the following ordered list = of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case = requirements. > - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la = part de Hannes Gredler > Envoy=E9 : mardi 3 septembre 2013 18:31 > =C0 : Loa Andersson > Cc : status@ietf.org > Objet : Re: [Status] Summary of STATUS BOF and the next steps >=20 > good point - what about this charter proposal ? >=20 > --- >=20 > Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >=20 > - They form a connected network > - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) > - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >=20 > The STER working group is chartered for the following ordered list of = work items: >=20 > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >=20 > --- >=20 > >=20 > /hannes >=20 >=20 > On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >=20 >> Folks, >>=20 >> Excuse me if I'm slightly out of the loop, but so far I have not seen >> a charter proposal, if there is one please point me to it. >>=20 >> It seems a bit odd to put the cart (what the wg should do) before the >> horse (wg name). If we drill down the the charter first the wg name >> might be easier to figure out. >>=20 >> /Loa >>=20 >> PS >> OK I understand that the horse and cart analogy limps a bit :). >>=20 >>=20 >>=20 >> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>> " If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ..." >>>=20 >>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>=20 >>> Peter >>>=20 >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of stephane.litkowski@orange.com >>> Sent: Tuesday, September 03, 2013 10:43 AM >>> To: AshwoodsmithPeter >>> Cc: status@ietf.org >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>=20 >>>=20 >>> There was a misunderstanding in my small comment :) so I will = explain more : >>>=20 >>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>=20 >>> In the other hand, I completely agree with your statement that = source >>> routing is generic and dataplane agnostic, as segment routing is ... >>> (segment routing is not a new dataplane ...) >>>=20 >>> Now the definition of the WG naming must be inline with the charter >>> that will be defined ... (draft today) >>>=20 >>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>=20 >>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>=20 >>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>=20 >>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>=20 >>> If the WG is focused on SR, let's use a name in relation with SR. >>>=20 >>> Feedback ? >>>=20 >>>=20 >>> Stephane >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane = DTF/DERX >>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione >>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>> Summary of STATUS BOF and the next steps >>>=20 >>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>=20 >>> Peter >>>=20 >>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS = BOF >>>> and the next steps >>>>=20 >>>> Hi, >>>>=20 >>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>=20 >>>> Yours Irrespectively, >>>>=20 >>>> John >>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of Mark Townsley >>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>> To: Victor Kuarsingh >>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>>=20 >>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> I would also favour "Segment Routing WG" as well. >>>>>>=20 >>>>>> I note this since attempting to come up with an all encompassing >>>>>> acronym will be difficult and Segment Routing is generic enough = to >>>>>> associate to multiple functions. >>>>>=20 >>>>> Then we can just use "segroute" for the short name. WGs do not = have >>>>> to have acronyms, but they do need to have an 8-char limited short >>>>> name for the various automated tools not to break. >>>>>=20 >>>>> - Mark >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Victor K >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> +1 for Segment Routing WG >>>>>>>=20 >>>>>>> Roberta >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Segment Routing WG >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>> to find a better working name for the WG, since it has been = put >>>>>>>>> to me a number of times that STATUS is going to be confusing = in >>>>>>>>> text and a difficult search term. >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = ____________________________________________________________________ >>>> __ ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> = _____________________________________________________________________ >>> ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 >=20 >=20 From hannes@juniper.net Wed Sep 4 21:06:03 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8182421E8053 for ; Wed, 4 Sep 2013 21:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.604 X-Spam-Level: X-Spam-Status: No, score=-3.604 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1UtuVB2ZKeH for ; Wed, 4 Sep 2013 21:05:58 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3194B11E8152 for ; Wed, 4 Sep 2013 21:05:58 -0700 (PDT) Received: from mail11-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE030.bigfish.com (10.236.130.93) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 04:05:57 +0000 Received: from mail11-co9 (localhost [127.0.0.1]) by mail11-co9-R.bigfish.com (Postfix) with ESMTP id 886204200A9; Thu, 5 Sep 2013 04:05:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(z551biz98dI9371Iec9I1432I1521Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail11-co9: domain of juniper.net designates 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=hannes@juniper.net; helo=BN1PRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail11-co9 (localhost.localdomain [127.0.0.1]) by mail11-co9 (MessageSwitch) id 137835395579338_21621; Thu, 5 Sep 2013 04:05:55 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.232]) by mail11-co9.bigfish.com (Postfix) with ESMTP id 0E76F30004F; Thu, 5 Sep 2013 04:05:55 +0000 (UTC) Received: from BN1PRD0512HT003.namprd05.prod.outlook.com (132.245.2.21) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 04:05:54 +0000 Received: from mrepeti-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.193.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 04:05:53 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> Date: Thu, 5 Sep 2013 06:05:49 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALUMNI.DUKE.EDU$RO%1$TLS%0$FQDN%$TlsDn% Cc: Anoop Ghanwani , status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 04:06:03 -0000 On Sep 4, 2013, at 4:18 PM, Mark Townsley wrote: >=20 > On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote: >=20 >> Some folks use BGP to perform the function of an IGP. It looks like = the proposed charter would exclude them from taking advantage of this = technology. It might be worthwhile adding BGP to that list of protocols = to be enhanced for this. >=20 > I agree that the statement "Develop ISIS and OSPF protocol extensions = necessary for distribution of MPLS forwarding information." needs work, = for two reasons. First, the extensions may not be strictly MPLS if the = goal is to make this work for MPLS and IPv6. Second, I think it would be = better for the ISIS and OSPF WGs to advance their own protocol = extensions, rather than including that within the charter of SR as a = deliverable. BGP, or any other routing protocol, could then adopt SR = based on its own level of interest in that WG to do so. Would that = suffice? actually not. the whole point of forming a new WG is that folks do not sneak-in "*-routing" ideas in the respective protocol groups where people may not be paying attention. back to the original argument: since what we are extending are link-state protocols and there is an incarnation of BGP to carry link-state graphs its perfectly legitimate to add BGP to the list of to be worked on protocols. >> With respect to the text about working with existing data paths -- I = wonder if there is some way to capture that it might not work with all = existing implementations. For example, the number of labels required to = be pushed at the ingress device may prevent some existing = implementations from taking advantage of this technology, depending on = the size of the topology. >>=20 >> Anoop >>=20 >>=20 >> On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant = wrote: >>=20 >> May I suggest that we use the name "SR" and worry >> about what it binds to later. >>=20 >> The higher priority item is the charter text. Does >> anyone have any comments on the text proposed >> so far, or the text in the BOF proposal: >>=20 >>=20 >> The Stacked Tunnels for Source Routing (STATUS) Working Group=20 >> is chartered to develop a framework and use cases for source-routed=20= >> flows in packet switched networks. >>=20 >> IP previously had a source-based routing mechanism made=20 >> available through an IP Option. This mechanism has, however,=20 >> not been widely used and has a number of issues that make its=20 >> use inadvisable, and other mechanisms (such as RFC 1940)=20 >> do not appear to have been implemented at all. >>=20 >> The ability of a router to influence or control the forwarding=20 >> path of an individual packet or all the packets of a given=20 >> Forwarding Equivalence Class (FEC) is a desirable feature=20 >> for a number of reasons including Label Switched Path stitching,=20 >> egress protection, explicit routing, egress ASBR link selection,=20 >> and backup (bypass tunnels, Remote Loop-Free Alternates)=20 >> routing. This can be achieved by facilitating source-initiated=20 >> selection of routes to complement the route selection=20 >> provided by existing routing protocols for both inter- domain=20 >> and intra-domain routes. >>=20 >> Historically, distribution of MPLS label binding information=20 >> was done by relying on label distribution protocols=20 >> such as LDP and RSVP-TE. >>=20 >> The use cases documented by the working group will=20 >> indicate the network function that is being facilitated=20 >> and indicate which packet data plane is to be used. >>=20 >> The framework developed by the working group will=20 >> consider forwarding of IPv4, IPv6, and MPLS using the=20 >> existing unicast data planes. Multicast forwarding will=20 >> be for future study and the choice of data planes will=20 >> be limited to those for which use cases exist. A key=20 >> objective of the work will be to ensure that source- >> routed packets can be handled seamlessly by existing=20 >> deployed equipment. A major objective will be that the=20 >> new function does not modify existing data plane behavior=20 >> or architectures, and that it can be enabled through only=20 >> control and management plane software upgrades at=20 >> deployed devices. >>=20 >> Once the working group has established a framework=20 >> and there is demonstrable consensus for use cases,=20 >> the working group will move forward to specify protocol=20 >> solutions for installing forwarding information through=20 >> the use of the IGPs (OSPF and IS-IS), or through the=20 >> management plane. In the course of developing protocol=20 >> extensions, the working group will work closely with=20 >> other IETF working groups responsible for the protocols=20 >> being modified (such as OSPF, ISIS, and I2RS). >>=20 >> The working group is chartered for the following work items: >>=20 >> A framework for the use of the existing MPLS data plane to=20 >> support tunnel-based unicast source routing.=20 >>=20 >> Develop use cases for tunnel-based unicast source routing=20 >> that demonstrate the need and support for solutions. Care=20 >> should be taken to avoid clustering use cases that might seem >> to imply support for multiple use cases when only some of the=20 >> cluster actually have wide-scale support.=20 >>=20 >> Develop ISIS and OSPF protocol extensions necessary for=20 >> distribution of MPLS forwarding information.=20 >>=20 >> The working group will consider management (including =20 >> configuration, reporting, diagnostics, and OAM) and security=20 >> implications of its work and document them in separate=20 >> documents as appropriate.=20 >>=20 >> The working group is not chartered to make any changes to=20 >> the MPLS or IPv6 data planes. Any proposed changes to the=20 >> data planes are to be specified in the working groups responsible=20= >> for the data planes (that is, the MPLS and 6MAN working groups, =20= >> respectively). >>=20 >> - Stewart >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From jeff.tantsura@ericsson.com Wed Sep 4 21:26:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF811E8257 for ; Wed, 4 Sep 2013 21:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncmSUPoJF4Cy for ; Wed, 4 Sep 2013 21:26:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED9E11E824A for ; Wed, 4 Sep 2013 21:26:11 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-d2-522807e1b945 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 19.59.03458.1E708225; Thu, 5 Sep 2013 06:26:10 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Thu, 5 Sep 2013 00:26:09 -0400 From: Jeff Tantsura To: Hannes Gredler Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqXJPZFhQM2M54UyFMKsHBVlnq5m141WAgADnPYD//8KgbQ== Date: Thu, 5 Sep 2013 04:26:09 +0000 Message-ID: <20119EBF-C513-4211-8A4D-BE0341A65DEC@ericsson.com> References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXRPoO4jdo0gg6NnmS32Hnez6L/3hM1i 2oEHTBavmy8yObB4bDmZ7rFkyU8mj+tNV9k97k+byBTAEsVlk5Kak1mWWqRvl8CVcf/ILuaC PvOKBze1Ghg/63QxcnBICJhIzJyk1sXICWSKSVy4t56ti5GLQ0jgKKPEz54DLBDOMkaJdbcb 2UCq2AQMJP5/O84CYosIqEssnHSXGcRmFiiRuLR0PhOILSxgJ9Hz5RITRI29xPmz96BsJ4n3 5/YxgtgsAioSP1pegPXyAtUc+fmLFWLZTkaJXdP2gBVxAiWmXVjMDmIzAp33/dQaJohl4hK3 nkAskxAQkFiy5zwzhC0q8fLxP1aIGh2JBbs/sUHY2hLLFr6GWiYocXLmE5YJjKKzkIyahaRl FpKWWUhaFjCyrGLkKC1OLctNNzLcxAiMmGMSbI47GBd8sjzEKM3BoiTOu0HvTKCQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRgWj6kbj9aoTC35KzVq08lz1pNLXnvGKJyb6X9gdovx3006D C9fZ357YznOeqf9rZcWcX6qbGL/XlcpIuGmul0z81BJXlqCvtPKoHatO6+vnxsrdV7gvL6wW bPmS+3TrwrQX2rHmsQ9ZK+XE55cqn1v16sGUCFuHeC7DV5t59E+Ka5cy5BZ/VWIpzkg01GIu Kk4EAN1BmCpmAgAA Cc: Anoop Ghanwani , Mark Townsley , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 04:26:17 -0000 Agree with Hannes, BGP is a valid protocol to work on? Regards, Jeff On Sep 4, 2013, at 21:06, "Hannes Gredler" wrote: >=20 > On Sep 4, 2013, at 4:18 PM, Mark Townsley wrote: >=20 >>=20 >> On Sep 4, 2013, at 3:26 PM, Anoop Ghanwani wrote: >>=20 >>> Some folks use BGP to perform the function of an IGP. It looks like th= e proposed charter would exclude them from taking advantage of this technol= ogy. It might be worthwhile adding BGP to that list of protocols to be enh= anced for this. >>=20 >> I agree that the statement "Develop ISIS and OSPF protocol extensions ne= cessary for distribution of MPLS forwarding information." needs work, for t= wo reasons. First, the extensions may not be strictly MPLS if the goal is t= o make this work for MPLS and IPv6. Second, I think it would be better for = the ISIS and OSPF WGs to advance their own protocol extensions, rather than= including that within the charter of SR as a deliverable. BGP, or any othe= r routing protocol, could then adopt SR based on its own level of interest = in that WG to do so. Would that suffice? >=20 > actually not. the whole point of forming a new WG is that > folks do not sneak-in "*-routing" ideas in the respective > protocol groups where people may not be paying attention. >=20 > back to the original argument: since what we are extending > are link-state protocols and there is an incarnation of BGP > to carry link-state graphs its perfectly legitimate to > add BGP to the list of to be worked on protocols. >=20 >>> With respect to the text about working with existing data paths -- I wo= nder if there is some way to capture that it might not work with all existi= ng implementations. For example, the number of labels required to be pushe= d at the ingress device may prevent some existing implementations from taki= ng advantage of this technology, depending on the size of the topology. >>>=20 >>> Anoop >>>=20 >>>=20 >>> On Wed, Sep 4, 2013 at 3:24 AM, Stewart Bryant wro= te: >>>=20 >>> May I suggest that we use the name "SR" and worry >>> about what it binds to later. >>>=20 >>> The higher priority item is the charter text. Does >>> anyone have any comments on the text proposed >>> so far, or the text in the BOF proposal: >>>=20 >>>=20 >>> The Stacked Tunnels for Source Routing (STATUS) Working Group=20 >>> is chartered to develop a framework and use cases for source-routed=20 >>> flows in packet switched networks. >>>=20 >>> IP previously had a source-based routing mechanism made=20 >>> available through an IP Option. This mechanism has, however,=20 >>> not been widely used and has a number of issues that make its=20 >>> use inadvisable, and other mechanisms (such as RFC 1940)=20 >>> do not appear to have been implemented at all. >>>=20 >>> The ability of a router to influence or control the forwarding=20 >>> path of an individual packet or all the packets of a given=20 >>> Forwarding Equivalence Class (FEC) is a desirable feature=20 >>> for a number of reasons including Label Switched Path stitching,=20 >>> egress protection, explicit routing, egress ASBR link selection,=20 >>> and backup (bypass tunnels, Remote Loop-Free Alternates)=20 >>> routing. This can be achieved by facilitating source-initiated=20 >>> selection of routes to complement the route selection=20 >>> provided by existing routing protocols for both inter- domain=20 >>> and intra-domain routes. >>>=20 >>> Historically, distribution of MPLS label binding information=20 >>> was done by relying on label distribution protocols=20 >>> such as LDP and RSVP-TE. >>>=20 >>> The use cases documented by the working group will=20 >>> indicate the network function that is being facilitated=20 >>> and indicate which packet data plane is to be used. >>>=20 >>> The framework developed by the working group will=20 >>> consider forwarding of IPv4, IPv6, and MPLS using the=20 >>> existing unicast data planes. Multicast forwarding will=20 >>> be for future study and the choice of data planes will=20 >>> be limited to those for which use cases exist. A key=20 >>> objective of the work will be to ensure that source- >>> routed packets can be handled seamlessly by existing=20 >>> deployed equipment. A major objective will be that the=20 >>> new function does not modify existing data plane behavior=20 >>> or architectures, and that it can be enabled through only=20 >>> control and management plane software upgrades at=20 >>> deployed devices. >>>=20 >>> Once the working group has established a framework=20 >>> and there is demonstrable consensus for use cases,=20 >>> the working group will move forward to specify protocol=20 >>> solutions for installing forwarding information through=20 >>> the use of the IGPs (OSPF and IS-IS), or through the=20 >>> management plane. In the course of developing protocol=20 >>> extensions, the working group will work closely with=20 >>> other IETF working groups responsible for the protocols=20 >>> being modified (such as OSPF, ISIS, and I2RS). >>>=20 >>> The working group is chartered for the following work items: >>>=20 >>> A framework for the use of the existing MPLS data plane to=20 >>> support tunnel-based unicast source routing.=20 >>>=20 >>> Develop use cases for tunnel-based unicast source routing=20 >>> that demonstrate the need and support for solutions. Care=20 >>> should be taken to avoid clustering use cases that might seem >>> to imply support for multiple use cases when only some of the=20 >>> cluster actually have wide-scale support.=20 >>>=20 >>> Develop ISIS and OSPF protocol extensions necessary for=20 >>> distribution of MPLS forwarding information.=20 >>>=20 >>> The working group will consider management (including =20 >>> configuration, reporting, diagnostics, and OAM) and security=20 >>> implications of its work and document them in separate=20 >>> documents as appropriate.=20 >>>=20 >>> The working group is not chartered to make any changes to=20 >>> the MPLS or IPv6 data planes. Any proposed changes to the=20 >>> data planes are to be specified in the working groups responsible=20 >>> for the data planes (that is, the MPLS and 6MAN working groups, =20 >>> respectively). >>>=20 >>> - Stewart >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From saku@ytti.fi Wed Sep 4 21:52:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6BC21F9A31 for ; Wed, 4 Sep 2013 21:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rEDQW0qkWR3 for ; Wed, 4 Sep 2013 21:52:44 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABA21F9A2A for ; Wed, 4 Sep 2013 21:52:42 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id x18so1219862lbi.17 for ; Wed, 04 Sep 2013 21:52:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=gbAXzMzwKLM2aV1UIzysa6gwIKGYtFJgzrnFzOeY6K4=; b=VzAvLfC3s6pXQHpJoYaeS0Kva9lnXrLYDAjhTG7nA3lDUeiNGSewW8YaxQezTI0rO0 V29FRDIz1c6qCODJjF8t4f7z/DM2CCeeLhR8mIoIDXm6I+uUrik6zqek+VhoPnQclIyZ S2kuUFoi543uH/sraxHK6NZMihzl/6m07z5xvqE/aHqVN7IFA0b4bKTAT5VkI43awwhX g6SVKJ5SSXkeAlaxb4lHeTZkKHe7pWtLZi/hVGun2lYdFjsK2GkLe7Ft9w+VkMcMjzOW lj7bVHVOBwxFR+9JtJrLqttwdDNcX0HQIcZp8krAtV2wUmIiEcZ76l5WtUBjA7jBJpT0 7Cjw== X-Gm-Message-State: ALoCoQlicHaYvlrDvoRBS3cuLOqtXQCUAsnoiKbKGTcbCNRDGE4rjZ2O3NLrtKy6Z+DXKZi7Awqi X-Received: by 10.112.168.170 with SMTP id zx10mr5463062lbb.0.1378356761165; Wed, 04 Sep 2013 21:52:41 -0700 (PDT) Received: from pob.ytti.fi (up.ip.fi. [2001:6e8:288::d]) by mx.google.com with ESMTPSA id u18sm11980936lbp.4.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 04 Sep 2013 21:52:39 -0700 (PDT) Date: Thu, 5 Sep 2013 07:52:37 +0300 From: Saku Ytti To: status@ietf.org Message-ID: <20130905045237.GA1186@pob.ytti.fi> References: <746508F1-7E89-4C4B-9A11-9233C6985E3E@huawei.com> <2FE467D3673DCE409A84D67EC2F607BB140E703F@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB140E703F@xmb-rcd-x10.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 04:52:49 -0000 On (2013-09-04 21:38 +0000), George Swallow (swallow) wrote: > I actually don't think it is possible to write a dataplane agnostic architecture. We can write an architecture document that is 90% dataplane independent and then has some dataplane dependencies. E.g. having the full SR path available at each hop vs the remainder. Architecture can provide command 'next segment', without explicitly mandating previous segments to be deleted or kept. Compatible implementation/wire-format then has some freedom in its implementation. -- ++ytti From stephane.litkowski@orange.com Thu Sep 5 01:00:50 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB18011E8120 for ; Thu, 5 Sep 2013 01:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbSIEoVFLmGK for ; Thu, 5 Sep 2013 01:00:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7F011E8184 for ; Thu, 5 Sep 2013 01:00:36 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AE0E918C863; Thu, 5 Sep 2013 10:00:35 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8B30F35C079; Thu, 5 Sep 2013 10:00:35 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 5 Sep 2013 10:00:35 +0200 From: To: Hannes Gredler Date: Thu, 5 Sep 2013 10:00:34 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6p66hKW6eUIkcFQRiMdgz+ge8gNwAIMpDw Message-ID: <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.5.50915 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 08:00:50 -0000 Hannes, > In the proposed segment routing architectural concepts, segments are > at the same "level" and pointer moves on the segment list, then the > MPLS instantiation is performing this using stacking ... [HG] the "moving pointer" is a requirement without an actual use case - do = you know how this would be used ? - i don't [SLI] Interrest is to keep tracking where the packet is coming from. I'm no= t saying that this is a good the solution or not ... working group should d= ecide ... but enforcing "stacking" is the charter may close door to some ot= her solutions. > Finally, about the "routing" word, routing is essentially a "forward" act= ion which may limit the scope of what we can do by using a segment list. Ac= tions associated with a segment could be something else than forwarding. > Do we want in the charter to limit the scope to routing actions ? > HG> as per the published use-case drafts all i have seen are use-cases HG> related to "forwarding". as far as i am concerned i am good limiting the scope to "rou= ting actions". [SLI] We had to start with something simple, that's why the current use cas= es are related only to forwarding. But it's not a reason to limit the chart= er to this ... > - They form a connected network > [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). HG> did i preclude inter-AS in any way ? [SLI] It was not clear to me what did you put behind "connected network" > - They can forward traffic through the shortest paths or paths other than= the shortest (the latter called explicitly routed paths, or explicit paths) > [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. HG> if you have a case for non-routing, please make it; - IIRC in our HG> past 6 months of conversation around IGP label advertisement / SR we haven't discussed any = non-routing use-case. [SLI] Non routing use case are more future ... routing is the basic infras= tructure on top of which you can add some stuffs. Stephane -----Message d'origine----- De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : jeudi 5 septembre 2013 05:54 =C0 : LITKOWSKI Stephane DTF/DERX Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the next steps hi stephane, see comments inline prefixed by HG> On Sep 4, 2013, at 10:02 AM, wrote: > case, we are using only directed forwarding (adjacency segment), > could we still talk about tunneling ? (it's a very very small tunnel) > Moreover talking about "stacking" is really dataplane agnostic (MPLS) > ... HG> one-hop tunnels are ok; > In the proposed segment routing architectural concepts, segments are > at the same "level" and pointer moves on the segment list, then the > MPLS instantiation is performing this using stacking ... the "moving pointer" is a requirement without an actual use case - do you k= now how this would be used ? - i don't > IMHO, if we use "Stacked Tunnels", we already talk about a chosen > solution and it's closing the door to something else ... HG> closing door to things we have no (known) requirements for is ok; being anything to anybody is not helpful - the more concise the charter the= better; > Finally, about the "routing" word, routing is essentially a "forward" act= ion which may limit the scope of what we can do by using a segment list. Ac= tions associated with a segment could be something else than forwarding. > Do we want in the charter to limit the scope to routing actions ? > HG> as per the published use-case drafts all i have seen are use-cases HG> related to "forwarding". as far as i am concerned i am good limiting the scope to "rou= ting actions". > I have no solution today to propose for the naming, but I completely agre= e with Loa, to first focus on working on the charter, and define a clear sc= ope of the work and then the name will be easier to find. HG> good :-) > Regarding your charter proposal : > > -------- > > - They form a connected network > [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). HG> did i preclude inter-AS in any way ? > - They can forward traffic through the shortest paths or paths other than= the shortest (the latter called explicitly routed paths, or explicit paths) > [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. HG> if you have a case for non-routing, please make it; - IIRC in our HG> past 6 months of conversation around IGP label advertisement / SR we haven't discussed any = non-routing use-case. > - They share a common trust model. In this model, any router within the E= RD can specify an explicit path between itself and any other router in the = ERD. It can then send any packet that passes through it through any path th= at it has specified. > [SLI] Security considerations may have to be addressed in the > charter , especially for the interAS case (trust yes, but not sure > access to everything may not be good) HG> ok. > Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. > [SLI] Yes, but any router in the middle may be able to change the end to = end explicit path. HG> is there any application outside FRR for changing an explicit path ? > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > > [SLI] Agree, I would add : > - defining the architecture framework > - analysing the security considerations HG> ok; > > > Here would be my proposal to extend yours : > > A domain contains a set of routers with the followi= ng characteristics: > > - They form a connected network > - They can forward traffic through any path within the network using > shortest path, non shortest path or explicit path > - They may provide other types of services than forwarding and they can e= nforce service actions in the path. > - They share a common trust model. In this model, any router within the d= omain can specify a path between itself and any other router in the domain.= It may then send any packet that passes through it through any path that i= t has specified and that is conform to the security rules. Downstream route= rs within the ERD forward the packet as specified by the router at the head= -end of the path. > > The working group is chartered for the following ordered list of w= ork items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with the = security considerations. The architecture framework and security considerat= ions must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will ide= ntify gaps between currently available technologies and use-case requiremen= ts. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. However, no protocol wo= rk will be adopted by a working group to address the ERD use-cases until th= e requirements document motivating the protocol work has been sent to the I= ESG for publication as an RFC. > > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la > part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa > Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS > BOF and the next steps > > good point - what about this charter proposal ? > > --- > > Stacked Tunnels for Explicit Routing (STER) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A explicit routing domain (ERD) contains a set of routers with the follow= ing characteristics: > > - They form a connected network > - They can forward traffic through the shortest paths or paths other > than the shortest (the latter called explicitly routed paths, or > explicit paths) > - They share a common trust model. In this model, any router within the E= RD can specify an explicit path between itself and any other router in the = ERD. It can then send any packet that passes through it through any path th= at it has specified. Downstream routers within the ERD forward the packet a= s specified by the router at the head-end of the path. > > The STER working group is chartered for the following ordered list of wor= k items: > > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. However, no protocol wo= rk will be adopted by a working group to address the ERD use-cases until th= e requirements document motivating the protocol work has been sent to the I= ESG for publication as an RFC. > > --- > > > > /hannes > > > On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: > >> Folks, >> >> Excuse me if I'm slightly out of the loop, but so far I have not seen >> a charter proposal, if there is one please point me to it. >> >> It seems a bit odd to put the cart (what the wg should do) before the >> horse (wg name). If we drill down the the charter first the wg name >> might be easier to figure out. >> >> /Loa >> >> PS >> OK I understand that the horse and cart analogy limps a bit :). >> >> >> >> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>> " If the WG charter is limited to source routing, how will we handle th= e "non source routing" use cases of segment routing ? In another working gr= oup ? So we will go back to the WG synchronization issue that has been rais= ed for this technology ..." >>> >>> That's why I suggested SRV2. We are revisiting source routing with new = concepts. More generic number/action behavior. >>> >>> Peter >>> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of stephane.litkowski@orange.com >>> Sent: Tuesday, September 03, 2013 10:43 AM >>> To: AshwoodsmithPeter >>> Cc: status@ietf.org >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> There was a misunderstanding in my small comment :) so I will explain m= ore : >>> >>> In segment routing, you have more than basic source routing : segment r= outing is just associate a segment number to an action and then combine seg= ment as you want, yes you can do source routing, but you also can do more. >>> >>> In the other hand, I completely agree with your statement that >>> source routing is generic and dataplane agnostic, as segment routing is= ... >>> (segment routing is not a new dataplane ...) >>> >>> Now the definition of the WG naming must be inline with the charter >>> that will be defined ... (draft today) >>> >>> Based on the already existing consensus (at least for MPLS dataplane) b= rought up during Berlin STATUS BOF meeting, segment routing sounds to be a = good target candidate. >>> >>> So now, do we want to do more in the WG charter than just make progress= ing segment routing architecture and uses cases document and ensure coordin= ation for the standardization of this technology ? >>> >>> Do we want to standardize other technologies in this WG ? I don't think= so, based on Stewart's conclusion email from the BOF :"A new WG focused so= lely on SR therefore needs to be create" >>> >>> If the WG charter is limited to source routing, how will we handle the = "non source routing" use cases of segment routing ? In another working grou= p ? So we will go back to the WG synchronization issue that has been raised= for this technology ... >>> >>> If the WG is focused on SR, let's use a name in relation with SR. >>> >>> Feedback ? >>> >>> >>> Stephane >>> >>> >>> -----Message d'origine----- >>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>> [Status] Summary of STATUS BOF and the next steps >>> >>> The term "source routing" has been around for a very long time and is d= ata path agnostic. Its also the term used in the literature etc so my prefe= rence is to stick with this existing well known and data path agnostic term. >>> >>> Peter >>> >>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>> >>>> Hi, >>>> >>>> "Source routing" is just a subcase of segment routing ... as it is for= IP routing ... >>>> >>>> Stephane >>>> >>>> >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark >>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>> BOF and the next steps >>>> >>>> Hi, >>>> >>>> What is this 'segment routing' silliness? The correct term is 'source= routing'. >>>> >>>> Yours Irrespectively, >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of Mark Townsley >>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>> To: Victor Kuarsingh >>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>> (stbryant) >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> >>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I would also favour "Segment Routing WG" as well. >>>>>> >>>>>> I note this since attempting to come up with an all encompassing >>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>> to associate to multiple functions. >>>>> >>>>> Then we can just use "segroute" for the short name. WGs do not >>>>> have to have acronyms, but they do need to have an 8-char limited >>>>> short name for the various automated tools not to break. >>>>> >>>>> - Mark >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Victor K >>>>>> >>>>>> >>>>>> >>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> +1 for Segment Routing WG >>>>>>> >>>>>>> Roberta >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Segment Routing WG >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>> confusing in text and a difficult search term. >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> ___________________________________________________________________ >>>> _ __ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> ____________________________________________________________________ >>> _ ____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From sprevidi@cisco.com Thu Sep 5 01:18:59 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC5E21F9E5C for ; Thu, 5 Sep 2013 01:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.02 X-Spam-Level: X-Spam-Status: No, score=-107.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FS9mx9BhgF9 for ; Thu, 5 Sep 2013 01:18:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6A721F9F0A for ; Thu, 5 Sep 2013 01:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24678; q=dns/txt; s=iport; t=1378369129; x=1379578729; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AybVsHBacvJlZDGPeuGhY++yMp3wCIePiuwlDKzP5cc=; b=eeN59+AI2hT0ueq9IrT6S4/OQB7MxS37/baER99m9Is2Gl3X0p2r6hRB +pFITQG2N5mqUjHPBwNDcTpG0CgFjhIZOMqOBuB1WWbLWcNzM2f42tuhT Jw2AM8VDjocFejmwmzpFiUFIOCRNoekdteRAv5oTUCOdd9Hu3xY0Z48ag Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAM09KFKtJV2c/2dsb2JhbABRCoMHNVHBRoEmFnSCJAEBAQMBAQEBF00EAwQTAgICAQgRAQMBAQEKHQcbDAsUAwYIAgQBEggTh2EGDLouBASOEwYEAYELAiwMBoMXgQADiH2gXoMggWgBCBci X-IronPort-AV: E=Sophos;i="4.90,845,1371081600"; d="scan'208";a="255677322" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 05 Sep 2013 08:18:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r858IlHn002695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 08:18:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 03:18:47 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler , Stephane Litkowski , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqn9BmNg4ov0KfP72YYuk0EpmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAF7ZgIAAAqQAgAAQigCAAQRZgIABTPQAgABExQCAAAUUgA== Date: Thu, 5 Sep 2013 08:18:46 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.82.254] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1C1C786AB205F148A0D97FA017CC535C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 08:18:59 -0000 Hannes, Stephane, On Sep 5, 2013, at 10:00 AM, Hannes and Stephane wrote: >=20 > Hannes, >=20 >=20 >> In the proposed segment routing architectural concepts, segments are >> at the same "level" and pointer moves on the segment list, then the >> MPLS instantiation is performing this using stacking ... >=20 > [HG] the "moving pointer" is a requirement without an actual use case - d= o you know how this would be used ? - i don't >=20 > [SLI] Interrest is to keep tracking where the packet is coming from. I'm = not saying that this is a good the solution or not ... working group should= decide ... but enforcing "stacking" is the charter may close door to some = other solutions. absolutely agree. Data-plane agnostic means there may be differences in the way data-planes instantiate a function. If one data-plane stacks, the other may point. Nothing wrong with=20 this. >> Finally, about the "routing" word, routing is essentially a "forward" ac= tion which may limit the scope of what we can do by using a segment list. A= ctions associated with a segment could be something else than forwarding. >> Do we want in the charter to limit the scope to routing actions ? >>=20 >=20 > HG> as per the published use-case drafts all i have seen are use-cases > HG> related to > "forwarding". as far as i am concerned i am good limiting the scope to "r= outing actions". not me. There are use cases, (still to document but pretty real) that are not routing based. Service Chaining is one. > [SLI] We had to start with something simple, that's why the current use c= ases are related only to forwarding. But it's not a reason to limit the cha= rter to this ... absolutely agree. >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >=20 > HG> did i preclude inter-AS in any way ? >=20 > [SLI] It was not clear to me what did you put behind "connected network" >=20 >=20 >> - They can forward traffic through the shortest paths or paths other tha= n the shortest (the latter called explicitly routed paths, or explicit path= s) >> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >=20 > HG> if you have a case for non-routing, please make it; - IIRC in our > HG> past 6 months of > conversation around IGP label advertisement / SR we haven't discussed any= non-routing use-case. Service chaining is one of them. Thanks. s. > [SLI] Non routing use case are more future ... routing is the basic infr= astructure on top of which you can add some stuffs. >=20 >=20 > Stephane >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : Hannes Gredler [mailto:hannes@juniper.net] > Envoy=E9 : jeudi 5 septembre 2013 05:54 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : status@ietf.org > Objet : Re: [Status] Summary of STATUS BOF and the next steps >=20 > hi stephane, >=20 > see comments inline prefixed by HG> >=20 > On Sep 4, 2013, at 10:02 AM, wrote: >> case, we are using only directed forwarding (adjacency segment), >> could we still talk about tunneling ? (it's a very very small tunnel) >> Moreover talking about "stacking" is really dataplane agnostic (MPLS) >> ... >=20 > HG> one-hop tunnels are ok; >=20 >> In the proposed segment routing architectural concepts, segments are >> at the same "level" and pointer moves on the segment list, then the >> MPLS instantiation is performing this using stacking ... >=20 > the "moving pointer" is a requirement without an actual use case - do you= know how this would be used ? - i don't >=20 >> IMHO, if we use "Stacked Tunnels", we already talk about a chosen >> solution and it's closing the door to something else ... >=20 > HG> closing door to things we have no (known) requirements for is ok; > being anything to anybody is not helpful - the more concise the charter t= he better; >=20 >> Finally, about the "routing" word, routing is essentially a "forward" ac= tion which may limit the scope of what we can do by using a segment list. A= ctions associated with a segment could be something else than forwarding. >> Do we want in the charter to limit the scope to routing actions ? >>=20 >=20 > HG> as per the published use-case drafts all i have seen are use-cases > HG> related to > "forwarding". as far as i am concerned i am good limiting the scope to "r= outing actions". >=20 >> I have no solution today to propose for the naming, but I completely agr= ee with Loa, to first focus on working on the charter, and define a clear s= cope of the work and then the name will be easier to find. >=20 > HG> good :-) >=20 >> Regarding your charter proposal : >>=20 >> -------- >>=20 >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >=20 > HG> did i preclude inter-AS in any way ? >=20 >> - They can forward traffic through the shortest paths or paths other tha= n the shortest (the latter called explicitly routed paths, or explicit path= s) >> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >=20 > HG> if you have a case for non-routing, please make it; - IIRC in our > HG> past 6 months of > conversation around IGP label advertisement / SR we haven't discussed any= non-routing use-case. >=20 >> - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in the= ERD. It can then send any packet that passes through it through any path t= hat it has specified. >> [SLI] Security considerations may have to be addressed in the >> charter , especially for the interAS case (trust yes, but not sure >> access to everything may not be good) >=20 > HG> ok. >=20 >> Downstream routers within the ERD forward the packet as specified by the= router at the head-end of the path. >> [SLI] Yes, but any router in the middle may be able to change the end to= end explicit path. >=20 > HG> is there any application outside FRR for changing an explicit path ? >=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between current= ly available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >>=20 >> [SLI] Agree, I would add : >> - defining the architecture framework >> - analysing the security considerations >=20 > HG> ok; >=20 >>=20 >>=20 >> Here would be my proposal to extend yours : >>=20 >> A domain contains a set of routers with the follow= ing characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, non shortest path or explicit path >> - They may provide other types of services than forwarding and they can = enforce service actions in the path. >> - They share a common trust model. In this model, any router within the = domain can specify a path between itself and any other router in the domain= . It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream rout= ers within the ERD forward the packet as specified by the router at the hea= d-end of the path. >>=20 >> The working group is chartered for the following ordered list of = work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with the= security considerations. The architecture framework and security considera= tions must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will id= entify gaps between currently available technologies and use-case requireme= nts. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. However, no protocol w= ork will be adopted by a working group to address the ERD use-cases until t= he requirements document motivating the protocol work has been sent to the = IESG for publication as an RFC. >>=20 >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa >> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >> BOF and the next steps >>=20 >> good point - what about this charter proposal ? >>=20 >> --- >>=20 >> Stacked Tunnels for Explicit Routing (STER) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> A explicit routing domain (ERD) contains a set of routers with the follo= wing characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through the shortest paths or paths other >> than the shortest (the latter called explicitly routed paths, or >> explicit paths) >> - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in the= ERD. It can then send any packet that passes through it through any path t= hat it has specified. Downstream routers within the ERD forward the packet = as specified by the router at the head-end of the path. >>=20 >> The STER working group is chartered for the following ordered list of wo= rk items: >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between current= ly available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >>=20 >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. However, no protocol w= ork will be adopted by a working group to address the ERD use-cases until t= he requirements document motivating the protocol work has been sent to the = IESG for publication as an RFC. >>=20 >> --- >>=20 >> >>=20 >> /hannes >>=20 >>=20 >> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>=20 >>> Folks, >>>=20 >>> Excuse me if I'm slightly out of the loop, but so far I have not seen >>> a charter proposal, if there is one please point me to it. >>>=20 >>> It seems a bit odd to put the cart (what the wg should do) before the >>> horse (wg name). If we drill down the the charter first the wg name >>> might be easier to figure out. >>>=20 >>> /Loa >>>=20 >>> PS >>> OK I understand that the horse and cart analogy limps a bit :). >>>=20 >>>=20 >>>=20 >>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>> " If the WG charter is limited to source routing, how will we handle t= he "non source routing" use cases of segment routing ? In another working g= roup ? So we will go back to the WG synchronization issue that has been rai= sed for this technology ..." >>>>=20 >>>> That's why I suggested SRV2. We are revisiting source routing with new= concepts. More generic number/action behavior. >>>>=20 >>>> Peter >>>>=20 >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of stephane.litkowski@orange.com >>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>> To: AshwoodsmithPeter >>>> Cc: status@ietf.org >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>>=20 >>>> There was a misunderstanding in my small comment :) so I will explain = more : >>>>=20 >>>> In segment routing, you have more than basic source routing : segment = routing is just associate a segment number to an action and then combine se= gment as you want, yes you can do source routing, but you also can do more. >>>>=20 >>>> In the other hand, I completely agree with your statement that >>>> source routing is generic and dataplane agnostic, as segment routing i= s ... >>>> (segment routing is not a new dataplane ...) >>>>=20 >>>> Now the definition of the WG naming must be inline with the charter >>>> that will be defined ... (draft today) >>>>=20 >>>> Based on the already existing consensus (at least for MPLS dataplane) = brought up during Berlin STATUS BOF meeting, segment routing sounds to be a= good target candidate. >>>>=20 >>>> So now, do we want to do more in the WG charter than just make progres= sing segment routing architecture and uses cases document and ensure coordi= nation for the standardization of this technology ? >>>>=20 >>>> Do we want to standardize other technologies in this WG ? I don't thin= k so, based on Stewart's conclusion email from the BOF :"A new WG focused s= olely on SR therefore needs to be create" >>>>=20 >>>> If the WG charter is limited to source routing, how will we handle the= "non source routing" use cases of segment routing ? In another working gro= up ? So we will go back to the WG synchronization issue that has been raise= d for this technology ... >>>>=20 >>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>=20 >>>> Feedback ? >>>>=20 >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>> [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>> The term "source routing" has been around for a very long time and is = data path agnostic. Its also the term used in the literature etc so my pref= erence is to stick with this existing well known and data path agnostic ter= m. >>>>=20 >>>> Peter >>>>=20 >>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> "Source routing" is just a subcase of segment routing ... as it is fo= r IP routing ... >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Ma= rk >>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>> BOF and the next steps >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> What is this 'segment routing' silliness? The correct term is 'sourc= e routing'. >>>>>=20 >>>>> Yours Irrespectively, >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of Mark Townsley >>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>> To: Victor Kuarsingh >>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>> (stbryant) >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>=20 >>>>>>> I note this since attempting to come up with an all encompassing >>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>> to associate to multiple functions. >>>>>>=20 >>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>> short name for the various automated tools not to break. >>>>>>=20 >>>>>> - Mark >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Victor K >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> +1 for Segment Routing WG >>>>>>>>=20 >>>>>>>> Roberta >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> ___________________________________________________________________ >>>>> _ __ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> ____________________________________________________________________ >>>> _ ____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >=20 >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From hannes@juniper.net Thu Sep 5 01:51:08 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42121E80DF for ; Thu, 5 Sep 2013 01:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-3.042, BAYES_00=-2.599, FRT_INTEREST=3.579, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B76wfBhc+cgR for ; Thu, 5 Sep 2013 01:51:02 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 010BC11E80E2 for ; Thu, 5 Sep 2013 01:51:00 -0700 (PDT) Received: from mail84-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE035.bigfish.com (10.174.14.98) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 08:51:00 +0000 Received: from mail84-db9 (localhost [127.0.0.1]) by mail84-db9-R.bigfish.com (Postfix) with ESMTP id E79F8E02A5; Thu, 5 Sep 2013 08:50:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -73 X-BigFish: VPS-73(z551biz62a3I98dI9371Ic89bh936eI15bfK542I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail84-db9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail84-db9 (localhost.localdomain [127.0.0.1]) by mail84-db9 (MessageSwitch) id 1378371057266990_25074; Thu, 5 Sep 2013 08:50:57 +0000 (UTC) Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.241]) by mail84-db9.bigfish.com (Postfix) with ESMTP id 3273F32004D; Thu, 5 Sep 2013 08:50:57 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 08:50:57 +0000 Received: from [172.26.200.176] (193.110.54.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 08:50:53 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: Date: Thu, 5 Sep 2013 10:50:49 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <05E8CD61-9B05-4463-ADD6-4D7240B142FA@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> To: "Stefano Previdi (sprevidi)" X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephane Litkowski , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 08:51:08 -0000 hi stefano, please see comments inline; On Sep 5, 2013, at 10:18 AM, Stefano Previdi (sprevidi) wrote: > Hannes, Stephane, >=20 >=20 > On Sep 5, 2013, at 10:00 AM, Hannes and Stephane wrote: >>=20 >> Hannes, >>=20 >>=20 >>> In the proposed segment routing architectural concepts, segments are >>> at the same "level" and pointer moves on the segment list, then the >>> MPLS instantiation is performing this using stacking ... >>=20 >> [HG] the "moving pointer" is a requirement without an actual use case = - do you know how this would be used ? - i don't >>=20 >> [SLI] Interrest is to keep tracking where the packet is coming from. = I'm not saying that this is a good the solution or not ... working group = should decide ... but enforcing "stacking" is the charter may close door = to some other solutions. >=20 >=20 > absolutely agree. Data-plane agnostic means there may be differences > in the way data-planes instantiate a function. >=20 > If one data-plane stacks, the other may point. Nothing wrong with=20 > this. >=20 >=20 >>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>> Do we want in the charter to limit the scope to routing actions ? >>>=20 >>=20 >> HG> as per the published use-case drafts all i have seen are = use-cases >> HG> related to >> "forwarding". as far as i am concerned i am good limiting the scope = to "routing actions". >=20 >=20 > not me. There are use cases, (still to document but pretty real) that > are not routing based. Service Chaining is one. HG> the use cases becomes "real" once they see the light of day = (=3Dpublication) in the meantime they'll remain "fictional". for network service chaining it is my understanding that there is a = dedicated BOF/WG. i fail to see why we would need to do it here. - quite contrary it = may be one of those things that http://tools.ietf.org/html/rfc1925 section 2 point (5) warns us = about. >> [SLI] We had to start with something simple, that's why the current = use cases are related only to forwarding. But it's not a reason to limit = the charter to this ... >=20 >=20 > absolutely agree. HG> good so lets keep it out for now, and change charter later as = requirements become more clear; >=20 >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>=20 >> HG> did i preclude inter-AS in any way ? >>=20 >> [SLI] It was not clear to me what did you put behind "connected = network" >>=20 >>=20 >>> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >>> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>=20 >> HG> if you have a case for non-routing, please make it; - IIRC in our >> HG> past 6 months of >> conversation around IGP label advertisement / SR we haven't discussed = any non-routing use-case. >=20 >=20 > Service chaining is one of them. >=20 > Thanks. >=20 > s. >=20 >=20 >=20 >> [SLI] Non routing use case are more future ... routing is the basic = infrastructure on top of which you can add some stuffs. >>=20 >>=20 >> Stephane >>=20 >>=20 >>=20 >>=20 >> -----Message d'origine----- >> De : Hannes Gredler [mailto:hannes@juniper.net] >> Envoy=E9 : jeudi 5 septembre 2013 05:54 >> =C0 : LITKOWSKI Stephane DTF/DERX >> Cc : status@ietf.org >> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>=20 >> hi stephane, >>=20 >> see comments inline prefixed by HG> >>=20 >> On Sep 4, 2013, at 10:02 AM, = wrote: >>> case, we are using only directed forwarding (adjacency segment), >>> could we still talk about tunneling ? (it's a very very small = tunnel) >>> Moreover talking about "stacking" is really dataplane agnostic = (MPLS) >>> ... >>=20 >> HG> one-hop tunnels are ok; >>=20 >>> In the proposed segment routing architectural concepts, segments are >>> at the same "level" and pointer moves on the segment list, then the >>> MPLS instantiation is performing this using stacking ... >>=20 >> the "moving pointer" is a requirement without an actual use case - do = you know how this would be used ? - i don't >>=20 >>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen >>> solution and it's closing the door to something else ... >>=20 >> HG> closing door to things we have no (known) requirements for is ok; >> being anything to anybody is not helpful - the more concise the = charter the better; >>=20 >>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>> Do we want in the charter to limit the scope to routing actions ? >>>=20 >>=20 >> HG> as per the published use-case drafts all i have seen are = use-cases >> HG> related to >> "forwarding". as far as i am concerned i am good limiting the scope = to "routing actions". >>=20 >>> I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>=20 >> HG> good :-) >>=20 >>> Regarding your charter proposal : >>>=20 >>> -------- >>>=20 >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>=20 >> HG> did i preclude inter-AS in any way ? >>=20 >>> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >>> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>=20 >> HG> if you have a case for non-routing, please make it; - IIRC in our >> HG> past 6 months of >> conversation around IGP label advertisement / SR we haven't discussed = any non-routing use-case. >>=20 >>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >>> [SLI] Security considerations may have to be addressed in the >>> charter , especially for the interAS case (trust yes, but not sure >>> access to everything may not be good) >>=20 >> HG> ok. >>=20 >>> Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. >>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>=20 >> HG> is there any application outside FRR for changing an explicit = path ? >>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>=20 >>> [SLI] Agree, I would add : >>> - defining the architecture framework >>> - analysing the security considerations >>=20 >> HG> ok; >>=20 >>>=20 >>>=20 >>> Here would be my proposal to extend yours : >>>=20 >>> A domain contains a set of routers with the = following characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through any path within the network using >>> shortest path, non shortest path or explicit path >>> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >>> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>>=20 >>> The working group is chartered for the following ordered list = of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). >>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>=20 >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : = Loa >>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of = STATUS >>> BOF and the next steps >>>=20 >>> good point - what about this charter proposal ? >>>=20 >>> --- >>>=20 >>> Stacked Tunnels for Explicit Routing (STER) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through the shortest paths or paths other >>> than the shortest (the latter called explicitly routed paths, or >>> explicit paths) >>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>>=20 >>> The STER working group is chartered for the following ordered list = of work items: >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>=20 >>> --- >>>=20 >>> >>>=20 >>> /hannes >>>=20 >>>=20 >>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>> a charter proposal, if there is one please point me to it. >>>>=20 >>>> It seems a bit odd to put the cart (what the wg should do) before = the >>>> horse (wg name). If we drill down the the charter first the wg name >>>> might be easier to figure out. >>>>=20 >>>> /Loa >>>>=20 >>>> PS >>>> OK I understand that the horse and cart analogy limps a bit :). >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>=20 >>>>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of stephane.litkowski@orange.com >>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>> To: AshwoodsmithPeter >>>>> Cc: status@ietf.org >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>>=20 >>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>=20 >>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>=20 >>>>> In the other hand, I completely agree with your statement that >>>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>>> (segment routing is not a new dataplane ...) >>>>>=20 >>>>> Now the definition of the WG naming must be inline with the = charter >>>>> that will be defined ... (draft today) >>>>>=20 >>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>=20 >>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>=20 >>>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>>=20 >>>>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>>>=20 >>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>=20 >>>>> Feedback ? >>>>>=20 >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; = Roberta >>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>> [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : Mark >>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>> BOF and the next steps >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>=20 >>>>>> Yours Irrespectively, >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>> Behalf Of Mark Townsley >>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>> To: Victor Kuarsingh >>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>> (stbryant) >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>=20 >>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>>> to associate to multiple functions. >>>>>>>=20 >>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>> have to have acronyms, but they do need to have an 8-char = limited >>>>>>> short name for the various automated tools not to break. >>>>>>>=20 >>>>>>> - Mark >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Victor K >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> +1 for Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Roberta >>>>>>>>>=20 >>>>>>>>> Sent from my iPad >>>>>>>>>=20 >>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> = ___________________________________________________________________ >>>>>> _ __ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = ____________________________________________________________________ >>>>> _ ____________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 >=20 From rjs@rob.sh Thu Sep 5 02:23:14 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFD721F99C3 for ; Thu, 5 Sep 2013 02:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnZu4r6ijRnD for ; Thu, 5 Sep 2013 02:23:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 6491921F99BE for ; Thu, 5 Sep 2013 02:23:13 -0700 (PDT) Received: from [109.144.231.67] (helo=[10.96.1.29]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VHVla-0005k0-Va; Thu, 05 Sep 2013 10:22:18 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB140E703F@xmb-rcd-x10.cisco.com> Date: Thu, 5 Sep 2013 10:23:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <394C8B14-6B9A-40C7-8D35-BBC80CDB4315@rob.sh> References: <2FE467D3673DCE409A84D67EC2F607BB140E703F@xmb-rcd-x10.cisco.com> To: "George Swallow (swallow)" X-Mailer: Apple Mail (2.1508) Cc: "status@ietf.org" , AshwoodsmithPeter Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 09:23:14 -0000 On 4 Sep 2013, at 22:38, "George Swallow (swallow)" = wrote: > I actually don't think it is possible to write a dataplane agnostic = architecture. We can write an architecture document that is 90% = dataplane independent and then has some dataplane dependencies. E.g. = having the full SR path available at each hop vs the remainder. You're right, maybe "agnostic" is an overstatement, but it at least = needs to be data plane independent as you say (such that the = architecture does not link to a specific data plane, but can be re-used = across them). The way that we develop the architecture should of course = take into account what the capabilities are of the data planes that we = envisage deploying SR on. r.= From xuxiaohu@huawei.com Thu Sep 5 03:17:28 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8EA21E8100 for ; Thu, 5 Sep 2013 03:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJgWNOXojEnB for ; Thu, 5 Sep 2013 03:17:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9B11E8184 for ; Thu, 5 Sep 2013 03:17:07 -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.5-GA FastPath queued) with ESMTP id AWX80300; Thu, 05 Sep 2013 10:17:03 +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.146.0; Thu, 5 Sep 2013 11:16:18 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 11:16:35 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Thu, 5 Sep 2013 18:16:30 +0800 From: Xuxiaohu To: "stbryant@cisco.com" , "status@ietf.org" Thread-Topic: A possible way to make IP fans happy//re: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbKMNMppxiDdAEC+H+M4LHfrLJmv7eKAgAEZNwCAABkbgIAC3wVggABS/4CAAI5CAIAB+xQQ Date: Thu, 5 Sep 2013 10:16:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966@NKGEML512-MBS.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> In-Reply-To: <52270A74.7010707@cisco.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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:17:28 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpBY2NvcmRpbmcgdG8gdGhlIEJvRiBzZXNzaW9uIGF0IElFVEY4NywgaXQgc2Vl bXMgdGhhdCB0aGVyZSBhcmUgYSBjZXJ0YWluIG51bWJlciBvZiBwZW9wbGUgd2hvIHdhbnQgdG8g c2VlIGFuIElQdjYtYmFzZWQsIHJhdGhlciB0aGFuIE1QTFMtYmFzZWQgc291cmNlIHJvdXRpbmcg bWVjaGFuaXNtLiBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IG1hbnkgcGVvcGxlIGFyZSBoZXNpdGF0 ZSB0byBtYWtlIGFueSBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5nIE1QTFMgYW5kIElQIGRhdGEgcGxh bmVzLg0KDQpJIHdvbmRlciB3aGV0aGVyIHRoZSBmb2xsb3dpbmcgbG93LWNvc3QgYXBwcm9hY2gg Y2FuIG1ha2UgdGhvc2UgSVAgZmFucyBoYXBweTogdGhlIHByZWRlZmluZWQgbmV4dC1ob3BzIHRo YXQgdGhlIGV4cGxpY2l0IHNvdXJjZSBwYXRoIG11c3QgdHJhdmVyc2UgYXJlIHN0aWxsIGV4cHJl c3NlZCBieSB0aGUgTVBMUyBsYWJlbCBzdGFjayBpbiB0aGUgZGF0YSBwYWNrZXRzLCBidXQgdGhl IGFkamFjZW50IG5leHQtaG9wcyBhcmUgY29ubmVjdGVkIHZpYSBwdXJlIElQIG5ldHdvcmtzLCBy YXRoZXIgdGhhbiBNUExTIG5ldHdvcmtzLiAgRm9yIGV4YW1wbGUsIGlmIExTUiBBIHdhbnRzIHRv IHNlbmQgYSBNUExTIFZQTiBwYWNrZXQgZm9yIExTUiBaIGFsb25nIGFuIGV4cGxpY2l0IHBhdGgg e0IsIEMsIFp9LCBpdCB3b3VsZCBwdXNoIHRoZSBub2RlIHNlZ21lbnQgbGFiZWwgZm9yIFogYW5k IHRoZW4gdGhlIG5vZGUgc2VnbWVudCBsYWJlbCBmb3IgQyBpbnRvIHRoZSBleGlzdGluZyBNUExT IGxhYmVsIHN0YWNrLCBhbmQgdGhlbiB0cmFuc3BvcnQgc3VjaCBNUExTIHBhY2tldCBvdmVyIGFu IElQIHR1bm5lbCB0b3dhcmRzIEIuIFVwb24gcmVjZWl2aW5nIHN1Y2ggTVBMUyBwYWNrZXQgb3Zl ciB0aGUgSVAgdHVubmVsLCBCIHdvdWxkIGxvb2sgdXAgdGhlIGNvcnJlc3BvbmRpbmcgTVBMUyBm b3J3YXJkaW5nIHRhYmxlIGVudHJ5IGZvciB0aGUgdG9wbW9zdCBsYWJlbCAoaS5lLiwgdGhlIG5v ZGUgc2VnbWVudCBsYWJlbCBmb3IgQykgYW5kIGZpbmQgdGhlIG91dCBpbnRlcmZhY2UgZm9yIHRo aXMgcGFja2V0IGlzIGFuIElQIHR1bm5lbCBpbnRlcmZhY2Ugd2l0aCB0dW5uZWwgZGVzdGluYXRp b24gb2YgQywgdGhlcmVmb3JlIGl0IHdvdWxkIHBvcCB0aGUgdG9wbW9zdCBsYWJlbCAoaWYgdGhl IG91dCBsYWJlbCBvZiB0aGF0IE1QTFMgZm9yd2FyZGluZyBlbnRyeSBpcyBudWxsKSBhbmQgdGhl biB0cmFuc3BvcnQgdGhlIE1QTFMgcGFja2V0IG92ZXIgYW4gSVAgdHVubmVsIHRvd2FyZHMgQy4g IE9uY2UgQyByZWNlaXZlcyBzdWNoIE1QTFMgcGFja2V0IG92ZXIgdGhlIElQIHR1bm5lbCwgQyB3 b3VsZCBsb29rIHVwIHRoZSBjb3JyZXNwb25kaW5nIE1QTFMgZm9yd2FyZGluZyBlbnRyeSBmb3Ig dGhlIGN1cnJlbnQgdG9wbW9zdCBsYWJlbCAoaS5lLiwgdGhlIG5vZGUgc2VnbWVudCBsYWJlbCBm b3IgWikgLCBhbmQgdGhlbiBmb3J3YXJkIHRoaXMgTVBMUyBwYWNrZXQgb3ZlciBhbiBJUCB0dW5u ZWwgdG93YXJkcyBaIGxpa2Ugd2hhdCBCIGhhcyBkb25lLg0KDQpUaGUgYWJvdmUgYXBwcm9hY2gg aGFzIGF0IGxlYXN0IHRoZSBmb2xsb3dpbmcgYmVuZWZpdHM6DQoNCg0KMSkgICAgTm8gY2hhbmdl IHRvIHRoZSBleGlzdGluZyBNUExTIGFuZCBJUCBkYXRhIHBsYW5lLg0KDQoyKSAgICBObyByZXF1 aXJlbWVudCBmb3IgdGhlIE1QTFMgZm9yd2FyZGluZyBjYXBhYmlsaXR5IG9uIGFsbCByb3V0ZXJz PT4gb25seSB0aG9zZSBleHBsaWNpdCBob3BzIG5lZWQgdGhlIE1QTFMgZm9yd2FyZGluZyBjYXBh YmlsaXR5Lg0KDQozKSAgICBObyByZXF1aXJlbWVudCBmb3Igc29mdHdhcmUgdXBncmFkZSBvbiBh bGwgcm91dGVycz0+IG9ubHkgdGhvc2UgZXhwbGljaXQgaG9wcyBuZWVkIHN1Y2ggc29mdHdhcmUg dXBncmFkZS4NCg0KNCkgICAgTGVzcyBNVFUgY29sbGlzaW9uIHJpc2sgZHVlIHRvIHRoZSB1c2Fn ZSBvZiAyMC1iaXQgbG9uZyBNUExTIGxhYmVscywgcmF0aGVyIHRoYW4gMTI4LWJpdCBsb25nIElQ djYgYWRkcmVzc2VzIGZvciBpbmRpY2F0aW5nIHRoZSBwcmVkZWZpbmVkIG5leHQtaG9wcyBvZiBh IGdpdmVuIGV4cGxpY2l0IHNvdXJjZSBwYXRoLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K t6K8/sjLOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFN0ZXdhcnQgQnJ5YW50DQq3osvNyrG85DogMjAxM8TqOdTCNMjVIDE4OjI1 DQrK1bz+yMs6IE1hY2ggQ2hlbg0Ks63LzTogSm9obiBFIERyYWtlOyBNYXJrIFRvd25zbGV5OyBW aWN0b3IgS3VhcnNpbmdoOyBSb2JlcnRhIE1hZ2xpb25lIChyb2JtZ2wpOyBKb2huIEcuIFNjdWRk ZXI7IEFkcmlhbiBGYXJyZWw7IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBzdGF0dXNAaWV0Zi5v cmcNCtb3zOI6IFJlOiBbU3RhdHVzXSBTdW1tYXJ5IG9mIFNUQVRVUyBCT0YgYW5kIHRoZSBuZXh0 IHN0ZXBzDQoNCg0KTWF5IEkgc3VnZ2VzdCB0aGF0IHdlIHVzZSB0aGUgbmFtZSAiU1IiIGFuZCB3 b3JyeQ0KYWJvdXQgd2hhdCBpdCBiaW5kcyB0byBsYXRlci4NCg0KVGhlIGhpZ2hlciBwcmlvcml0 eSBpdGVtIGlzIHRoZSBjaGFydGVyIHRleHQuIERvZXMNCmFueW9uZSBoYXZlIGFueSBjb21tZW50 cyBvbiB0aGUgdGV4dCBwcm9wb3NlZA0Kc28gZmFyLCBvciB0aGUgdGV4dCBpbiB0aGUgQk9GIHBy b3Bvc2FsOg0KDQoNClRoZSBTdGFja2VkIFR1bm5lbHMgZm9yIFNvdXJjZSBSb3V0aW5nIChTVEFU VVMpIFdvcmtpbmcgR3JvdXANCmlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZnJhbWV3b3JrIGFu ZCB1c2UgY2FzZXMgZm9yIHNvdXJjZS1yb3V0ZWQNCmZsb3dzIGluIHBhY2tldCBzd2l0Y2hlZCBu ZXR3b3Jrcy4NCg0KSVAgcHJldmlvdXNseSBoYWQgYSBzb3VyY2UtYmFzZWQgcm91dGluZyBtZWNo YW5pc20gbWFkZQ0KYXZhaWxhYmxlIHRocm91Z2ggYW4gSVAgT3B0aW9uLiBUaGlzIG1lY2hhbmlz bSBoYXMsIGhvd2V2ZXIsDQpub3QgYmVlbiB3aWRlbHkgdXNlZCBhbmQgaGFzIGEgbnVtYmVyIG9m IGlzc3VlcyB0aGF0IG1ha2UgaXRzDQp1c2UgaW5hZHZpc2FibGUsIGFuZCBvdGhlciBtZWNoYW5p c21zIChzdWNoIGFzIFJGQyAxOTQwKQ0KZG8gbm90IGFwcGVhciB0byBoYXZlIGJlZW4gaW1wbGVt ZW50ZWQgYXQgYWxsLg0KDQpUaGUgYWJpbGl0eSBvZiBhIHJvdXRlciB0byBpbmZsdWVuY2Ugb3Ig Y29udHJvbCB0aGUgZm9yd2FyZGluZw0KcGF0aCBvZiBhbiBpbmRpdmlkdWFsIHBhY2tldCBvciBh bGwgdGhlIHBhY2tldHMgb2YgYSBnaXZlbg0KRm9yd2FyZGluZyBFcXVpdmFsZW5jZSBDbGFzcyAo RkVDKSBpcyBhIGRlc2lyYWJsZSBmZWF0dXJlDQpmb3IgYSBudW1iZXIgb2YgcmVhc29ucyBpbmNs dWRpbmcgTGFiZWwgU3dpdGNoZWQgUGF0aCBzdGl0Y2hpbmcsDQplZ3Jlc3MgcHJvdGVjdGlvbiwg ZXhwbGljaXQgcm91dGluZywgZWdyZXNzIEFTQlIgbGluayBzZWxlY3Rpb24sDQphbmQgYmFja3Vw IChieXBhc3MgdHVubmVscywgUmVtb3RlIExvb3AtRnJlZSBBbHRlcm5hdGVzKQ0Kcm91dGluZy4g VGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgZmFjaWxpdGF0aW5nIHNvdXJjZS1pbml0aWF0ZWQNCnNl bGVjdGlvbiBvZiByb3V0ZXMgdG8gY29tcGxlbWVudCB0aGUgcm91dGUgc2VsZWN0aW9uDQpwcm92 aWRlZCBieSBleGlzdGluZyByb3V0aW5nIHByb3RvY29scyBmb3IgYm90aCBpbnRlci0gZG9tYWlu DQphbmQgaW50cmEtZG9tYWluIHJvdXRlcy4NCg0KSGlzdG9yaWNhbGx5LCBkaXN0cmlidXRpb24g b2YgTVBMUyBsYWJlbCBiaW5kaW5nIGluZm9ybWF0aW9uDQp3YXMgZG9uZSBieSByZWx5aW5nIG9u IGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2NvbHMNCnN1Y2ggYXMgTERQIGFuZCBSU1ZQLVRFLg0K DQpUaGUgdXNlIGNhc2VzIGRvY3VtZW50ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbA0KaW5k aWNhdGUgdGhlIG5ldHdvcmsgZnVuY3Rpb24gdGhhdCBpcyBiZWluZyBmYWNpbGl0YXRlZA0KYW5k IGluZGljYXRlIHdoaWNoIHBhY2tldCBkYXRhIHBsYW5lIGlzIHRvIGJlIHVzZWQuDQoNClRoZSBm cmFtZXdvcmsgZGV2ZWxvcGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwNCmNvbnNpZGVyIGZv cndhcmRpbmcgb2YgSVB2NCwgSVB2NiwgYW5kIE1QTFMgdXNpbmcgdGhlDQpleGlzdGluZyB1bmlj YXN0IGRhdGEgcGxhbmVzLiBNdWx0aWNhc3QgZm9yd2FyZGluZyB3aWxsDQpiZSBmb3IgZnV0dXJl IHN0dWR5IGFuZCB0aGUgY2hvaWNlIG9mIGRhdGEgcGxhbmVzIHdpbGwNCmJlIGxpbWl0ZWQgdG8g dGhvc2UgZm9yIHdoaWNoIHVzZSBjYXNlcyBleGlzdC4gQSBrZXkNCm9iamVjdGl2ZSBvZiB0aGUg d29yayB3aWxsIGJlIHRvIGVuc3VyZSB0aGF0IHNvdXJjZS0NCnJvdXRlZCBwYWNrZXRzIGNhbiBi ZSBoYW5kbGVkIHNlYW1sZXNzbHkgYnkgZXhpc3RpbmcNCmRlcGxveWVkIGVxdWlwbWVudC4gQSBt YWpvciBvYmplY3RpdmUgd2lsbCBiZSB0aGF0IHRoZQ0KbmV3IGZ1bmN0aW9uIGRvZXMgbm90IG1v ZGlmeSBleGlzdGluZyBkYXRhIHBsYW5lIGJlaGF2aW9yDQpvciBhcmNoaXRlY3R1cmVzLCBhbmQg dGhhdCBpdCBjYW4gYmUgZW5hYmxlZCB0aHJvdWdoIG9ubHkNCmNvbnRyb2wgYW5kIG1hbmFnZW1l bnQgcGxhbmUgc29mdHdhcmUgdXBncmFkZXMgYXQNCmRlcGxveWVkIGRldmljZXMuDQoNCk9uY2Ug dGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGVzdGFibGlzaGVkIGEgZnJhbWV3b3JrDQphbmQgdGhlcmUg aXMgZGVtb25zdHJhYmxlIGNvbnNlbnN1cyBmb3IgdXNlIGNhc2VzLA0KdGhlIHdvcmtpbmcgZ3Jv dXAgd2lsbCBtb3ZlIGZvcndhcmQgdG8gc3BlY2lmeSBwcm90b2NvbA0Kc29sdXRpb25zIGZvciBp bnN0YWxsaW5nIGZvcndhcmRpbmcgaW5mb3JtYXRpb24gdGhyb3VnaA0KdGhlIHVzZSBvZiB0aGUg SUdQcyAoT1NQRiBhbmQgSVMtSVMpLCBvciB0aHJvdWdoIHRoZQ0KbWFuYWdlbWVudCBwbGFuZS4g SW4gdGhlIGNvdXJzZSBvZiBkZXZlbG9waW5nIHByb3RvY29sDQpleHRlbnNpb25zLCB0aGUgd29y a2luZyBncm91cCB3aWxsIHdvcmsgY2xvc2VseSB3aXRoDQpvdGhlciBJRVRGIHdvcmtpbmcgZ3Jv dXBzIHJlc3BvbnNpYmxlIGZvciB0aGUgcHJvdG9jb2xzDQpiZWluZyBtb2RpZmllZCAoc3VjaCBh cyBPU1BGLCBJU0lTLCBhbmQgSTJSUykuDQoNCiAgICBUaGUgd29ya2luZyBncm91cCBpcyBjaGFy dGVyZWQgZm9yIHRoZSBmb2xsb3dpbmcgd29yayBpdGVtczoNCg0KICAgIEEgZnJhbWV3b3JrIGZv ciB0aGUgdXNlIG9mIHRoZSBleGlzdGluZyBNUExTIGRhdGEgcGxhbmUgdG8NCiAgICBzdXBwb3J0 IHR1bm5lbC1iYXNlZCB1bmljYXN0IHNvdXJjZSByb3V0aW5nLg0KDQogICAgRGV2ZWxvcCB1c2Ug Y2FzZXMgZm9yIHR1bm5lbC1iYXNlZCB1bmljYXN0IHNvdXJjZSByb3V0aW5nDQogICAgdGhhdCBk ZW1vbnN0cmF0ZSB0aGUgbmVlZCBhbmQgc3VwcG9ydCBmb3Igc29sdXRpb25zLiBDYXJlDQogICAg c2hvdWxkIGJlIHRha2VuIHRvIGF2b2lkIGNsdXN0ZXJpbmcgdXNlIGNhc2VzIHRoYXQgbWlnaHQg c2VlbQ0KICAgIHRvIGltcGx5IHN1cHBvcnQgZm9yIG11bHRpcGxlIHVzZSBjYXNlcyB3aGVuIG9u bHkgc29tZSBvZiB0aGUNCiAgICBjbHVzdGVyIGFjdHVhbGx5IGhhdmUgd2lkZS1zY2FsZSBzdXBw b3J0Lg0KDQogICAgRGV2ZWxvcCBJU0lTIGFuZCBPU1BGIHByb3RvY29sIGV4dGVuc2lvbnMgbmVj ZXNzYXJ5IGZvcg0KICAgZGlzdHJpYnV0aW9uIG9mIE1QTFMgZm9yd2FyZGluZyBpbmZvcm1hdGlv bi4NCg0KICAgIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgbWFuYWdlbWVudCAoaW5j bHVkaW5nDQogICAgY29uZmlndXJhdGlvbiwgcmVwb3J0aW5nLCBkaWFnbm9zdGljcywgYW5kIE9B TSkgYW5kIHNlY3VyaXR5DQogICAgaW1wbGljYXRpb25zIG9mIGl0cyB3b3JrIGFuZCBkb2N1bWVu dCB0aGVtIGluIHNlcGFyYXRlDQogICAgZG9jdW1lbnRzIGFzIGFwcHJvcHJpYXRlLg0KDQogICAg VGhlIHdvcmtpbmcgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBtYWtlIGFueSBjaGFuZ2VzIHRv DQogICAgdGhlIE1QTFMgb3IgSVB2NiBkYXRhIHBsYW5lcy4gQW55IHByb3Bvc2VkIGNoYW5nZXMg dG8gdGhlDQogICAgZGF0YSBwbGFuZXMgYXJlIHRvIGJlIHNwZWNpZmllZCBpbiB0aGUgd29ya2lu ZyBncm91cHMgcmVzcG9uc2libGUNCiAgICBmb3IgdGhlIGRhdGEgcGxhbmVzICh0aGF0IGlzLCB0 aGUgTVBMUyBhbmQgNk1BTiB3b3JraW5nIGdyb3VwcywNCiAgICByZXNwZWN0aXZlbHkpLg0KDQot IFN0ZXdhcnQNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

According = to the BoF session at IETF87, it seems that there are a certain number of p= eople who want to see an IPv6-based, rather than MPLS-based source routing mechanism. However, it seems that many people are hesitate = to make any change to the existing MPLS and IP data planes.

 = ;

I wonder w= hether the following low-cost approach can make those IP fans happy: the pr= edefined next-hops that the explicit source path must traverse are still expressed by the MPLS label stack in the data packets, but the a= djacent next-hops are connected via pure IP networks, rather than MPLS netw= orks.  For example, if LSR A wants to send a MPLS VPN packet for LSR Z= along an explicit path {B, C, Z}, it would push the node segment label for Z and then the node segment label fo= r C into the existing MPLS label stack, and then transport such MPLS packet= over an IP tunnel towards B. Upon receiving such MPLS packet over the IP t= unnel, B would look up the corresponding MPLS forwarding table entry for the topmost label (i.e., the node segment = label for C) and find the out interface for this packet is an IP tunnel int= erface with tunnel destination of C, therefore it would pop the topmost lab= el (if the out label of that MPLS forwarding entry is null) and then transport the MPLS packet over an IP tu= nnel towards C.  Once C receives such MPLS packet over the IP tunnel, = C would look up the corresponding MPLS forwarding entry for the current top= most label (i.e., the node segment label for Z) , and then forward this MPLS packet over an IP tunnel towards Z lik= e what B has done.

 = ;

The above = approach has at least the following benefits:

 = ;

1)    No= change to the existing MPLS and IP data plane.

2)    No= requirement for the MPLS forwarding capability on all routers=3D> only = those explicit hops need the MPLS forwarding capability.<= /p>

3)    No= requirement for software upgrade on all routers=3D> only those explicit= hops need such software upgrade.

4)    Le= ss MTU collision risk due to the usage of 20-bit long MPLS labels, rather t= han 128-bit long IPv6 addresses for indicating the predefined next-hops of a given explicit source path.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB:= status-bounces@ietf.org [mailto:status-bounces= @ietf.org] =B4=FA=B1=ED Stewart Bryant
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2013=C4=EA9=D4=C24=C8=D5 18:25
=CA=D5=BC=FE=C8=CB: Mach Chen
=B3=AD=CB=CD: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl);= John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org =D6=F7=CC=E2: Re: [Status] Summary of STATUS BOF and the next steps

 

=
May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966NKGEML512MBSchi_-- From ghanwani@gmail.com Thu Sep 5 03:42:27 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F2E21E80AE for ; Thu, 5 Sep 2013 03:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-1.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ia5r-a+G-7L for ; Thu, 5 Sep 2013 03:42:26 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BAE3011E8186 for ; Thu, 5 Sep 2013 03:42:24 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q59so1546656wes.20 for ; Thu, 05 Sep 2013 03:42:24 -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=E/JKzHjn9Bg+ErjR8ebhrxJRv+6JyUvPSmVkNH+BqFo=; b=wtTdZrANuTkOi9Ua22sScaIyzRKWDycGSeWThL7UCjkEBgl1IQJYCv3zb+uLsmewwu ogCZkmcD/IoUjp8b8k3jex7HsB4z+2VtdWf1DsCBE6+CCzVH1/VTOjCiRp+DXbLl61XZ JidSLuLSLVraX4WKBHcHAgbMabk85azRM23oI6fTDoy3xbEP07WNA+Hzd1T18+ve39Wi a4NBNA9gVaFCGTAXArUd4HXtFGWeqoE9elbRLYcCBOayqq57YoWbopyEaFPS8N0VoHCa Ji7XJ0/Yx5QzWrgln+9OUR6x/JJke5gUyA2EtVKNJ8VNpWYo8VC3CR7vtVdtmz3KIa0Q sIGw== MIME-Version: 1.0 X-Received: by 10.194.122.129 with SMTP id ls1mr6225988wjb.37.1378377743897; Thu, 05 Sep 2013 03:42:23 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.217.54.6 with HTTP; Thu, 5 Sep 2013 03:42:23 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966@NKGEML512-MBS.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966@NKGEML512-MBS.china.huawei.com> Date: Thu, 5 Sep 2013 03:42:23 -0700 X-Google-Sender-Auth: hq2cMPp2Yosd5FiEHu1XYxasaXs Message-ID: From: Anoop Ghanwani To: Xuxiaohu Content-Type: multipart/alternative; boundary=089e012299c8ca9ac304e5a0938a Cc: "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:42:27 -0000 --089e012299c8ca9ac304e5a0938a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Is this any different than MPLS over GRE, where GRE is used to get over non-MPLS-aware parts of a network? Anoop On Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu wrote: > Hi all,**** > > ** ** > > According to the BoF session at IETF87, it seems that there are a certain > number of people who want to see an IPv6-based, rather than MPLS-based > source routing mechanism. However, it seems that many people are hesitate > to make any change to the existing MPLS and IP data planes.**** > > ** ** > > I wonder whether the following low-cost approach can make those IP fans > happy: the predefined next-hops that the explicit source path must traver= se > are still expressed by the MPLS label stack in the data packets, but the > adjacent next-hops are connected via pure IP networks, rather than MPLS > networks. For example, if LSR A wants to send a MPLS VPN packet for LSR = Z > along an explicit path {B, C, Z}, it would push the node segment label fo= r > Z and then the node segment label for C into the existing MPLS label stac= k, > and then transport such MPLS packet over an IP tunnel towards B. Upon > receiving such MPLS packet over the IP tunnel, B would look up the > corresponding MPLS forwarding table entry for the topmost label (i.e., th= e > node segment label for C) and find the out interface for this packet is a= n > IP tunnel interface with tunnel destination of C, therefore it would pop > the topmost label (if the out label of that MPLS forwarding entry is null= ) > and then transport the MPLS packet over an IP tunnel towards C. Once C > receives such MPLS packet over the IP tunnel, C would look up the > corresponding MPLS forwarding entry for the current topmost label (i.e., > the node segment label for Z) , and then forward this MPLS packet over an > IP tunnel towards Z like what B has done.**** > > ** ** > > The above approach has at least the following benefits:**** > > ** ** > > **1) **No change to the existing MPLS and IP data plane.**** > > **2) **No requirement for the MPLS forwarding capability on all > routers=3D> only those explicit hops need the MPLS forwarding capability.= *** > * > > **3) **No requirement for software upgrade on all routers=3D> only tho= se > explicit hops need such software upgrade.**** > > **4) **Less MTU collision risk due to the usage of 20-bit long MPLS > labels, rather than 128-bit long IPv6 addresses for indicating the > predefined next-hops of a given explicit source path.**** > > ** ** > > Best regards,**** > > Xiaohu**** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* status-bounces@ietf.org [mailto:status-bounces@ietf= .org] *=B4=FA=B1=ED *Stewart > Bryant > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2013=C4=EA9=D4=C24=C8=D5 18:25 > *=CA=D5=BC=FE=C8=CB:* Mach Chen > *=B3=AD=CB=CD:* John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Ma= glione > (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); > status@ietf.org > *=D6=F7=CC=E2:* Re: [Status] Summary of STATUS BOF and the next steps**** > > ** ** > > > May I suggest that we use the name "SR" and worry > about what it binds to later. > > The higher priority item is the charter text. Does > anyone have any comments on the text proposed > so far, or the text in the BOF proposal: > > > The Stacked Tunnels for Source Routing (STATUS) Working Group > is chartered to develop a framework and use cases for source-routed > flows in packet switched networks. > > IP previously had a source-based routing mechanism made > available through an IP Option. This mechanism has, however, > not been widely used and has a number of issues that make its > use inadvisable, and other mechanisms (such as RFC 1940) > do not appear to have been implemented at all. > > The ability of a router to influence or control the forwarding > path of an individual packet or all the packets of a given > Forwarding Equivalence Class (FEC) is a desirable feature > for a number of reasons including Label Switched Path stitching, > egress protection, explicit routing, egress ASBR link selection, > and backup (bypass tunnels, Remote Loop-Free Alternates) > routing. This can be achieved by facilitating source-initiated > selection of routes to complement the route selection > provided by existing routing protocols for both inter- domain > and intra-domain routes. > > Historically, distribution of MPLS label binding information > was done by relying on label distribution protocols > such as LDP and RSVP-TE. > > The use cases documented by the working group will > indicate the network function that is being facilitated > and indicate which packet data plane is to be used. > > The framework developed by the working group will > consider forwarding of IPv4, IPv6, and MPLS using the > existing unicast data planes. Multicast forwarding will > be for future study and the choice of data planes will > be limited to those for which use cases exist. A key > objective of the work will be to ensure that source- > routed packets can be handled seamlessly by existing > deployed equipment. A major objective will be that the > new function does not modify existing data plane behavior > or architectures, and that it can be enabled through only > control and management plane software upgrades at > deployed devices. > > Once the working group has established a framework > and there is demonstrable consensus for use cases, > the working group will move forward to specify protocol > solutions for installing forwarding information through > the use of the IGPs (OSPF and IS-IS), or through the > management plane. In the course of developing protocol > extensions, the working group will work closely with > other IETF working groups responsible for the protocols > being modified (such as OSPF, ISIS, and I2RS). > > The working group is chartered for the following work items: > > A framework for the use of the existing MPLS data plane to > support tunnel-based unicast source routing. > > Develop use cases for tunnel-based unicast source routing > that demonstrate the need and support for solutions. Care > should be taken to avoid clustering use cases that might seem > to imply support for multiple use cases when only some of the > cluster actually have wide-scale support. > > Develop ISIS and OSPF protocol extensions necessary for > distribution of MPLS forwarding information. > > The working group will consider management (including > configuration, reporting, diagnostics, and OAM) and security > implications of its work and document them in separate > documents as appropriate. > > The working group is not chartered to make any changes to > the MPLS or IPv6 data planes. Any proposed changes to the > data planes are to be specified in the working groups responsible > for the data planes (that is, the MPLS and 6MAN working groups, > respectively). > > - Stewart**** > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > --089e012299c8ca9ac304e5a0938a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Is this any different than MPLS over GRE, where GRE is use= d to get over non-MPLS-aware parts of a network?

Anoop


On = Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi all,=

&nb= sp;

According = to the BoF session at IETF87, it seems that there are a certain number of p= eople who want to see an IPv6-based, rather than MPLS-based source routing mechanism. However, it seems that many people are hesitate = to make any change to the existing MPLS and IP data planes.

&nb= sp;

I wonder w= hether the following low-cost approach can make those IP fans happy: the pr= edefined next-hops that the explicit source path must traverse are still expressed by the MPLS label stack in the data packets, but the a= djacent next-hops are connected via pure IP networks, rather than MPLS netw= orks.  For example, if LSR A wants to send a MPLS VPN packet for LSR Z= along an explicit path {B, C, Z}, it would push the node segment label for Z and then the node segment label fo= r C into the existing MPLS label stack, and then transport such MPLS packet= over an IP tunnel towards B. Upon receiving such MPLS packet over the IP t= unnel, B would look up the corresponding MPLS forwarding table entry for the topmost label (i.e., the node segment = label for C) and find the out interface for this packet is an IP tunnel int= erface with tunnel destination of C, therefore it would pop the topmost lab= el (if the out label of that MPLS forwarding entry is null) and then transport the MPLS packet over an IP tu= nnel towards C.  Once C receives such MPLS packet over the IP tunnel, = C would look up the corresponding MPLS forwarding entry for the current top= most label (i.e., the node segment label for Z) , and then forward this MPLS packet over an IP tunnel towards Z lik= e what B has done.

&nb= sp;

The above = approach has at least the following benefits:

&nb= sp;

1)    No ch= ange to the existing MPLS and IP data plane.

2)    No re= quirement for the MPLS forwarding capability on all routers=3D> only tho= se explicit hops need the MPLS forwarding capability.<= /p>

3)    No re= quirement for software upgrade on all routers=3D> only those explicit ho= ps need such software upgrade.

4)    Less = MTU collision risk due to the usage of 20-bit long MPLS labels, rather than= 128-bit long IPv6 addresses for indicating the predefined next-hops of a given explicit source path.

&nb= sp;

Best regar= ds,

Xiaohu<= /u>

&nb= sp;

=B7=A2=BC=FE=C8=CB:= status-bounces@ietf.org [mailto:status-bounces@ietf.org] =B4=FA=B1=ED Stewart Bryant
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2013=C4=EA9=D4=C24=C8=D5 18:25
=CA=D5=BC=FE=C8=CB: Mach Chen
=B3=AD=CB=CD: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl);= John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org
=D6=F7=CC=E2: Re: [Status] Summary of STATUS BOF and the next steps

 

=
May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart


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


--089e012299c8ca9ac304e5a0938a-- From sprevidi@cisco.com Thu Sep 5 06:32:56 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D724611E81A0 for ; Thu, 5 Sep 2013 06:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.02 X-Spam-Level: X-Spam-Status: No, score=-107.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2uAn+2YM3qF for ; Thu, 5 Sep 2013 06:32:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7BA11E819E for ; Thu, 5 Sep 2013 06:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26639; q=dns/txt; s=iport; t=1378387971; x=1379597571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6pN4sJ9fI+qxyL2dLYcUD8BaFqNSzVn8gsw9HKS/RnI=; b=TL9dBv18jjJOiXSHsDjd/V2pn7C78HFQrGNrnyqvXL9Hz0KDgyt51xZb eMjhgaWKPu1RpvzsDHlrJB+flg5L0ryfKEtZ01yajrcVj9SKsmmvJL+PF mlTfWdpYnHucFfwWRUihnLtvuj0/47hsQUZSzq9RbPoQQysF5gmdg1UpE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAOCHKFKtJXHB/2dsb2JhbABRCoMHNVHBSIEoFnSCJAEBAQMBAQEBF00EAwQHBQcCAgIBCBEBAwEBAQodBxsMCxQDBggCBA4FCBOHYQYMuhEEjhMGBAGBCwIsBQcGgxeBAAOIfZAnkDeDIIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208";a="255781707" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 05 Sep 2013 13:32:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r85DWahT006036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 13:32:36 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.02.0318.004; Thu, 5 Sep 2013 08:32:36 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqn9BmNg4ov0KfP72YYuk0EpmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAF7ZgIAAAqQAgAAQigCAAQRZgIABTPQAgABExQCAAAUUgIAACPaAgABOuAA= Date: Thu, 5 Sep 2013 13:32:35 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> <05E8CD61-9B05-4463-ADD6-4D7240B142FA@juniper.net> In-Reply-To: <05E8CD61-9B05-4463-ADD6-4D7240B142FA@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.64] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4688AA7674522245890783E171C492F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stephane Litkowski , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:32:57 -0000 On Sep 5, 2013, at 10:50 AM, Hannes Gredler wrote: > hi stefano, >=20 > please see comments inline; >=20 > On Sep 5, 2013, at 10:18 AM, Stefano Previdi (sprevidi) wrote: >=20 >> Hannes, Stephane, >>=20 >>=20 >> On Sep 5, 2013, at 10:00 AM, Hannes and Stephane wrote: >>>=20 >>> Hannes, >>>=20 >>>=20 >>>> In the proposed segment routing architectural concepts, segments are >>>> at the same "level" and pointer moves on the segment list, then the >>>> MPLS instantiation is performing this using stacking ... >>>=20 >>> [HG] the "moving pointer" is a requirement without an actual use case -= do you know how this would be used ? - i don't >>>=20 >>> [SLI] Interrest is to keep tracking where the packet is coming from. I'= m not saying that this is a good the solution or not ... working group shou= ld decide ... but enforcing "stacking" is the charter may close door to som= e other solutions. >>=20 >>=20 >> absolutely agree. Data-plane agnostic means there may be differences >> in the way data-planes instantiate a function. >>=20 >> If one data-plane stacks, the other may point. Nothing wrong with=20 >> this. >>=20 >>=20 >>>> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment list.= Actions associated with a segment could be something else than forwarding. >>>> Do we want in the charter to limit the scope to routing actions ? >>>>=20 >>>=20 >>> HG> as per the published use-case drafts all i have seen are use-cases >>> HG> related to >>> "forwarding". as far as i am concerned i am good limiting the scope to = "routing actions". >>=20 >>=20 >> not me. There are use cases, (still to document but pretty real) that >> are not routing based. Service Chaining is one. >=20 > HG> the use cases becomes "real" once they see the light of day (=3Dpubli= cation) I'm producing a charter proposal that includes use-cases document=20 publication. > in the meantime they'll remain "fictional". > for network service chaining it is my understanding that there is a de= dicated BOF/WG. > i fail to see why we would need to do it here. - quite contrary it may= be one of those things > that http://tools.ietf.org/html/rfc1925 section 2 point (5) warns us a= bout. >=20 >>> [SLI] We had to start with something simple, that's why the current use= cases are related only to forwarding. But it's not a reason to limit the c= harter to this ... >>=20 >>=20 >> absolutely agree. >=20 > HG> good so lets keep it out for now, and change charter later as require= ments become more clear; I don't think we want to keep it out. s. >=20 >>=20 >>>> - They form a connected network >>>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>=20 >>> HG> did i preclude inter-AS in any way ? >>>=20 >>> [SLI] It was not clear to me what did you put behind "connected network= " >>>=20 >>>=20 >>>> - They can forward traffic through the shortest paths or paths other t= han the shortest (the latter called explicitly routed paths, or explicit pa= ths) >>>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>>=20 >>> HG> if you have a case for non-routing, please make it; - IIRC in our >>> HG> past 6 months of >>> conversation around IGP label advertisement / SR we haven't discussed a= ny non-routing use-case. >>=20 >>=20 >> Service chaining is one of them. >>=20 >> Thanks. >>=20 >> s. >>=20 >>=20 >>=20 >>> [SLI] Non routing use case are more future ... routing is the basic in= frastructure on top of which you can add some stuffs. >>>=20 >>>=20 >>> Stephane >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : Hannes Gredler [mailto:hannes@juniper.net] >>> Envoy=E9 : jeudi 5 septembre 2013 05:54 >>> =C0 : LITKOWSKI Stephane DTF/DERX >>> Cc : status@ietf.org >>> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>>=20 >>> hi stephane, >>>=20 >>> see comments inline prefixed by HG> >>>=20 >>> On Sep 4, 2013, at 10:02 AM, wrote: >>>> case, we are using only directed forwarding (adjacency segment), >>>> could we still talk about tunneling ? (it's a very very small tunnel) >>>> Moreover talking about "stacking" is really dataplane agnostic (MPLS) >>>> ... >>>=20 >>> HG> one-hop tunnels are ok; >>>=20 >>>> In the proposed segment routing architectural concepts, segments are >>>> at the same "level" and pointer moves on the segment list, then the >>>> MPLS instantiation is performing this using stacking ... >>>=20 >>> the "moving pointer" is a requirement without an actual use case - do y= ou know how this would be used ? - i don't >>>=20 >>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen >>>> solution and it's closing the door to something else ... >>>=20 >>> HG> closing door to things we have no (known) requirements for is ok; >>> being anything to anybody is not helpful - the more concise the charter= the better; >>>=20 >>>> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment list.= Actions associated with a segment could be something else than forwarding. >>>> Do we want in the charter to limit the scope to routing actions ? >>>>=20 >>>=20 >>> HG> as per the published use-case drafts all i have seen are use-cases >>> HG> related to >>> "forwarding". as far as i am concerned i am good limiting the scope to = "routing actions". >>>=20 >>>> I have no solution today to propose for the naming, but I completely a= gree with Loa, to first focus on working on the charter, and define a clear= scope of the work and then the name will be easier to find. >>>=20 >>> HG> good :-) >>>=20 >>>> Regarding your charter proposal : >>>>=20 >>>> -------- >>>>=20 >>>> - They form a connected network >>>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>=20 >>> HG> did i preclude inter-AS in any way ? >>>=20 >>>> - They can forward traffic through the shortest paths or paths other t= han the shortest (the latter called explicitly routed paths, or explicit pa= ths) >>>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>>=20 >>> HG> if you have a case for non-routing, please make it; - IIRC in our >>> HG> past 6 months of >>> conversation around IGP label advertisement / SR we haven't discussed a= ny non-routing use-case. >>>=20 >>>> - They share a common trust model. In this model, any router within th= e ERD can specify an explicit path between itself and any other router in t= he ERD. It can then send any packet that passes through it through any path= that it has specified. >>>> [SLI] Security considerations may have to be addressed in the >>>> charter , especially for the interAS case (trust yes, but not sure >>>> access to everything may not be good) >>>=20 >>> HG> ok. >>>=20 >>>> Downstream routers within the ERD forward the packet as specified by t= he router at the head-end of the path. >>>> [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >>>=20 >>> HG> is there any application outside FRR for changing an explicit path = ? >>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between curre= ntly available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>>=20 >>>> [SLI] Agree, I would add : >>>> - defining the architecture framework >>>> - analysing the security considerations >>>=20 >>> HG> ok; >>>=20 >>>>=20 >>>>=20 >>>> Here would be my proposal to extend yours : >>>>=20 >>>> A domain contains a set of routers with the foll= owing characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through any path within the network using >>>> shortest path, non shortest path or explicit path >>>> - They may provide other types of services than forwarding and they ca= n enforce service actions in the path. >>>> - They share a common trust model. In this model, any router within th= e domain can specify a path between itself and any other router in the doma= in. It may then send any packet that passes through it through any path tha= t it has specified and that is conform to the security rules. Downstream ro= uters within the ERD forward the packet as specified by the router at the h= ead-end of the path. >>>>=20 >>>> The working group is chartered for the following ordered list o= f work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated with t= he security considerations. The architecture framework and security conside= rations must address the relations between domains (interdomain). >>>> - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case require= ments. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding definition. >>>>=20 >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols, in coordination with this WG, an= d in agreement with the WG chairs and responsible ADs. However, no protocol= work will be adopted by a working group to address the ERD use-cases until= the requirements document motivating the protocol work has been sent to th= e IESG for publication as an RFC. >>>>=20 >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : L= oa >>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >>>> BOF and the next steps >>>>=20 >>>> good point - what about this charter proposal ? >>>>=20 >>>> --- >>>>=20 >>>> Stacked Tunnels for Explicit Routing (STER) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> A explicit routing domain (ERD) contains a set of routers with the fol= lowing characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through the shortest paths or paths other >>>> than the shortest (the latter called explicitly routed paths, or >>>> explicit paths) >>>> - They share a common trust model. In this model, any router within th= e ERD can specify an explicit path between itself and any other router in t= he ERD. It can then send any packet that passes through it through any path= that it has specified. Downstream routers within the ERD forward the packe= t as specified by the router at the head-end of the path. >>>>=20 >>>> The STER working group is chartered for the following ordered list of = work items: >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between curre= ntly available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>>=20 >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols, in coordination with this WG, an= d in agreement with the WG chairs and responsible ADs. However, no protocol= work will be adopted by a working group to address the ERD use-cases until= the requirements document motivating the protocol work has been sent to th= e IESG for publication as an RFC. >>>>=20 >>>> --- >>>>=20 >>>> >>>>=20 >>>> /hannes >>>>=20 >>>>=20 >>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> Excuse me if I'm slightly out of the loop, but so far I have not seen >>>>> a charter proposal, if there is one please point me to it. >>>>>=20 >>>>> It seems a bit odd to put the cart (what the wg should do) before the >>>>> horse (wg name). If we drill down the the charter first the wg name >>>>> might be easier to figure out. >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> PS >>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>> " If the WG charter is limited to source routing, how will we handle= the "non source routing" use cases of segment routing ? In another working= group ? So we will go back to the WG synchronization issue that has been r= aised for this technology ..." >>>>>>=20 >>>>>> That's why I suggested SRV2. We are revisiting source routing with n= ew concepts. More generic number/action behavior. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of stephane.litkowski@orange.com >>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>> To: AshwoodsmithPeter >>>>>> Cc: status@ietf.org >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> There was a misunderstanding in my small comment :) so I will explai= n more : >>>>>>=20 >>>>>> In segment routing, you have more than basic source routing : segmen= t routing is just associate a segment number to an action and then combine = segment as you want, yes you can do source routing, but you also can do mor= e. >>>>>>=20 >>>>>> In the other hand, I completely agree with your statement that >>>>>> source routing is generic and dataplane agnostic, as segment routing= is ... >>>>>> (segment routing is not a new dataplane ...) >>>>>>=20 >>>>>> Now the definition of the WG naming must be inline with the charter >>>>>> that will be defined ... (draft today) >>>>>>=20 >>>>>> Based on the already existing consensus (at least for MPLS dataplane= ) brought up during Berlin STATUS BOF meeting, segment routing sounds to be= a good target candidate. >>>>>>=20 >>>>>> So now, do we want to do more in the WG charter than just make progr= essing segment routing architecture and uses cases document and ensure coor= dination for the standardization of this technology ? >>>>>>=20 >>>>>> Do we want to standardize other technologies in this WG ? I don't th= ink so, based on Stewart's conclusion email from the BOF :"A new WG focused= solely on SR therefore needs to be create" >>>>>>=20 >>>>>> If the WG charter is limited to source routing, how will we handle t= he "non source routing" use cases of segment routing ? In another working g= roup ? So we will go back to the WG synchronization issue that has been rai= sed for this technology ... >>>>>>=20 >>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>>=20 >>>>>> Feedback ? >>>>>>=20 >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>> The term "source routing" has been around for a very long time and i= s data path agnostic. Its also the term used in the literature etc so my pr= eference is to stick with this existing well known and data path agnostic t= erm. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>>> BOF and the next steps >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> What is this 'segment routing' silliness? The correct term is 'sou= rce routing'. >>>>>>>=20 >>>>>>> Yours Irrespectively, >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>>>> Behalf Of Mark Townsley >>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>> To: Victor Kuarsingh >>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>> (stbryant) >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>=20 >>>>>>>>> All, >>>>>>>>>=20 >>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>=20 >>>>>>>>> I note this since attempting to come up with an all encompassing >>>>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>>>> to associate to multiple functions. >>>>>>>>=20 >>>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>>>> short name for the various automated tools not to break. >>>>>>>>=20 >>>>>>>> - Mark >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Victor K >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Roberta >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPad >>>>>>>>>>=20 >>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Segment Routing WG >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>=20 >>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> ___________________________________________________________________ >>>>>>> _ __ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de= truire ainsi que les pieces jointes. Les messages electroniques etant susce= ptibles d'alteration, Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should no= t be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> ____________________________________________________________________ >>>>>> _ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> ______________________________________________________________________ >>>> ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________________________________= __________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >>=20 >=20 >=20 From Peter.AshwoodSmith@huawei.com Thu Sep 5 06:40:20 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2021F9FF1 for ; Thu, 5 Sep 2013 06:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.453 X-Spam-Level: X-Spam-Status: No, score=-4.453 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NdxhAGhICMd for ; Thu, 5 Sep 2013 06:40:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9650011E8199 for ; Thu, 5 Sep 2013 06:40:11 -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.5-GA FastPath queued) with ESMTP id AVB87259; Thu, 05 Sep 2013 13:40:09 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 14:39:44 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 14:40:01 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 06:39:55 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAAmx0IAAeVMAgAAQigCAAQRZgIABTPQAgABExQD//+DbgA== Date: Thu, 5 Sep 2013 13:39:54 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5EA2@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:40:20 -0000 [HG] the "moving pointer" is a requirement without an actual use case - do = you know how this would be used ? - i don't [SLI] Interrest is to keep tracking where the packet is coming from. I'm no= t saying that this is a good the solution or not ... working group should d= ecide ... but enforcing "stacking" is the charter may close door to some ot= her solutions. There are a number of interesting uses when the history of the packet's fli= ght is available. - tandem fast reroute mechanisms can use previous hops as context to sprea= d traffic to different alternate next hops. - one can create 1:1 end to end protected paths with reverse path fate sha= ring for the probes, no need to install state at both ends. - greatly simplified debugging of network. - easier to build network flow information by simply inspecting traffic fl= owing through small number of representative network cuts. - reverse path checks can be used for authentication. - potentially halves the amount of work an central (SDN or Forces) control= ler must do (assuming symmetry is desired). Admittedly these are longer term uses, but for these reasons and others I h= ope that we do not close the door to keeping track of the history of the pa= cket's flight.=20 Cheers, Peter From Peter.AshwoodSmith@huawei.com Thu Sep 5 06:51:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57E011E8199 for ; Thu, 5 Sep 2013 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl9JkvggwMmR for ; Thu, 5 Sep 2013 06:51:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC5F411E816F for ; Thu, 5 Sep 2013 06:51:34 -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.5-GA FastPath queued) with ESMTP id AVB88325; Thu, 05 Sep 2013 13:51:34 +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.146.0; Thu, 5 Sep 2013 14:51:15 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Sep 2013 14:51:32 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.219]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 06:51:27 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqW4bqF79TsU221KTjikhKjJmwYzuAgAEZNwCAABkbgIAC3/WAgADYLICAAI5BAP//xVKwgAB+LwCAAEt6gP//jUAkgACgFICAAMTKgP//1GFg Date: Thu, 5 Sep 2013 13:51:26 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5EDF@dfweml513-mbb.china.huawei.com> References: <2FE467D3673DCE409A84D67EC2F607BB140E703F@xmb-rcd-x10.cisco.com> <394C8B14-6B9A-40C7-8D35-BBC80CDB4315@rob.sh> In-Reply-To: <394C8B14-6B9A-40C7-8D35-BBC80CDB4315@rob.sh> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:51:42 -0000 George, the existing architecture document does a pretty good job IMHO. Not= perfect of course, but they lay out the properties that are desirable and = then map them to IP and MPLS. I hope we can keep that approach in the WG.=20 Peter -----Original Message----- From: Rob Shakir [mailto:rjs@rob.sh]=20 Sent: Thursday, September 05, 2013 5:23 AM To: George Swallow (swallow) Cc: AshwoodsmithPeter; status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps On 4 Sep 2013, at 22:38, "George Swallow (swallow)" wro= te: > I actually don't think it is possible to write a dataplane agnostic archi= tecture. We can write an architecture document that is 90% dataplane inde= pendent and then has some dataplane dependencies. E.g. having the full SR = path available at each hop vs the remainder. You're right, maybe "agnostic" is an overstatement, but it at least needs t= o be data plane independent as you say (such that the architecture does not= link to a specific data plane, but can be re-used across them). The way th= at we develop the architecture should of course take into account what the = capabilities are of the data planes that we envisage deploying SR on. r. From jdrake@juniper.net Thu Sep 5 10:57:09 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2104111E81C1 for ; Thu, 5 Sep 2013 10:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-1.668, BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcM65oOYxGlj for ; Thu, 5 Sep 2013 10:57:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 07D0021E80FD for ; Thu, 5 Sep 2013 10:57:01 -0700 (PDT) Received: from mail181-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 17:56:58 +0000 Received: from mail181-ch1 (localhost [127.0.0.1]) by mail181-ch1-R.bigfish.com (Postfix) with ESMTP id 1E7562202D0; Thu, 5 Sep 2013 17:56:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(z551biz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail181-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(377454003)(13464003)(54316002)(74706001)(59766001)(77982001)(53806001)(56776001)(33646001)(81816001)(81542001)(69226001)(54356001)(74876001)(65816001)(80022001)(15975445006)(77096001)(56816003)(66066001)(51856001)(74316001)(83072001)(19580395003)(63696002)(19580405001)(83322001)(76786001)(76796001)(74662001)(47446002)(31966008)(74502001)(76576001)(80976001)(4396001)(47736001)(79102001)(74366001)(76482001)(81342001)(50986001)(49866001)(47976001)(81686001)(46102001)(24736002)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail181-ch1 (localhost.localdomain [127.0.0.1]) by mail181-ch1 (MessageSwitch) id 1378403765799014_21876; Thu, 5 Sep 2013 17:56:05 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail181-ch1.bigfish.com (Postfix) with ESMTP id BF1D926004D; Thu, 5 Sep 2013 17:56:05 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 17:55:57 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 17:55:54 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 5 Sep 2013 17:55:52 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.40]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.207]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 17:55:52 +0000 From: John E Drake To: AshwoodsmithPeter , "status@ietf.org" Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOpbJqNMppxiDdAEC+H+M4LHfrLJmwYzuAgAEZNwCAABkbgIAC3/WAgAABSwD//5Bqk4AADYzQgAAHkDCAAAsHgIAAAqQAgAAQiwCAAQRYgIABTPQAgABExQCAAF7PAIAAQg+w Date: Thu, 5 Sep 2013 17:55:51 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <17587_1378368035_52283A23_17587_2474_1_EEE55384044474429A926C625D0FCC810963161FB4@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5EA2@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2098E5EA2@dfweml513-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 096029FF66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 17:57:09 -0000 Peter, Comments inline. Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of AshwoodsmithPeter > Sent: Thursday, September 05, 2013 6:40 AM > To: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > [HG] the "moving pointer" is a requirement without an actual use case - d= o > you know how this would be used ? - i don't >=20 > [SLI] Interrest is to keep tracking where the packet is coming from. I'm = not > saying that this is a good the solution or not ... working group should d= ecide > ... but enforcing "stacking" is the charter may close door to some other > solutions. >=20 > There are a number of interesting uses when the history of the packet's > flight is available. >=20 > - tandem fast reroute mechanisms can use previous hops as context to > spread traffic to different alternate next hops. [JD] This information is useless. Regardless of the paths that packets to= ok to reach a given transit node, that node is presented with a composite s= et of traffic flows for each egress node. It will need to spread the packe= ts of these flows across its ECMP paths to that egress node by replacing th= e explicit route in each packet with an explicit route specifying one of th= ese ECMP paths, subject to the requirement that all packets of a given flow= follow the same path. Also, this is strictly a transient case which stops being of interest once = the ingress nodes receive the IGP update from the transit node that indicat= ing the link in question has failed, because at this point the ingress node= s will compute new explicit routes that don't use the failed link. =20 > - one can create 1:1 end to end protected paths with reverse path fate > sharing for the probes, no need to install state at both ends. [JD] Without installing state, how will an egress node know which packets = from a given ingress node are following disjoint paths through the network?= I.e., there will be a multiplicity of disjoint path pairs that a given in= gress node is using to send packets to that egress node.=20 > - greatly simplified debugging of network. [JD] If a packet is misdirected by a transit node, then that transit node = is obviously not processing the explicit route correctly. Therefore, what = is the utility of having the complete explicit route computed by the ingres= s node in such a misdirected packet, since it is clearly not being followed= ? I think it would be far more effective to dynamically accumulate a given pa= cket's path through the network. =20 > - easier to build network flow information by simply inspecting traffic = flowing > through small number of representative network cuts. =20 [JD] In a real network with a large number of ECMP paths between ingress/e= gress node pairs, what leads you to assume that querying a small number of = transit nodes will give one any idea of how the traffic is flowing through = one's network? Why isn't simply querying the ingress nodes both simpler an= d more effective? =20 Also, this is obviously useless if a central controller is being used. > - reverse path checks can be used for authentication. [JD] Reverse path checks are done at the ingress to a network not at the e= gress. =20 > - potentially halves the amount of work an central (SDN or Forces) contr= oller > must do (assuming symmetry is desired). [JD] The phrase 'false economy' springs to mind.=20 >=20 > Admittedly these are longer term uses, but for these reasons and others I > hope that we do not close the door to keeping track of the history of the > packet's flight. >=20 > Cheers, >=20 > Peter >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 From rraszuk@gmail.com Thu Sep 5 12:01:03 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3721E8184 for ; Thu, 5 Sep 2013 12:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74EwntvLlUfN for ; Thu, 5 Sep 2013 12:01:02 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7761821E817D for ; Thu, 5 Sep 2013 12:00:56 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so2838550oag.30 for ; Thu, 05 Sep 2013 12:00:55 -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=SNq1k7TCbxwJB0RJXQR3BJGTOvzcOEjnAWBVQqnpdBk=; b=drQjoPgGbR+7MUsTSpozTwEsEzt3y0VuGJILL2WWjeGrvGfWtdvpqdfyI0GGub5AzS TvgBuNo5lqH+pMZdyy+Q7bYztvLHm+oBNqjnSrPwTCieKWJYgf4InCDmjatIh3O7uEMQ Jg5kJgwjphdCFvdhrZKuRMtI3Z9DV2rfX+9d2+j1GMfDC9ZfFXbvPfWDc+Np+4g7I4rb 8dUV3Cs9Jg8QuZNISSnNAIRxBAnPielCaDpIczyCfQLGuvYcEwPpcrv+m5ZAWp9BzGzQ 4fhNSu3LasVD17warhe5tf+e4a9YhKUHxv9enu2IMz5uYsyYa+U9+3ObJmu04ugYOm4J EO6A== MIME-Version: 1.0 X-Received: by 10.182.143.103 with SMTP id sd7mr7495224obb.70.1378407655656; Thu, 05 Sep 2013 12:00:55 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.182.39.227 with HTTP; Thu, 5 Sep 2013 12:00:54 -0700 (PDT) In-Reply-To: References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> Date: Thu, 5 Sep 2013 21:00:54 +0200 X-Google-Sender-Auth: M4k0zn4glx6mBqbbDifJw8x8y6U Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: text/plain; charset=ISO-8859-1 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:01:03 -0000 > actually not. the whole point of forming a new WG is that > folks do not sneak-in "*-routing" ideas in the respective > protocol groups where people may not be paying attention. Thx for making the objective of this new WG finally very clear ;) In fact I would recommend we frame the above and make it as a charter. That way the new soon to be formed WG will be serving as *routing area preview/policy working group* preventing anyone to be able to "sneak-in" any protocol extension to respective routing protocols WGs without making sure such extensions are politically correct and approved by unanimity voting of anyone subscribed to the list. Cheers, R. PS. It's amazing to see this WG being formed considering a vast majority of people attending the quote "non working group forming BOF" in Berlin indicated no support for such new working group and segment routing architecture to be discussed in current rtwg. From aretana@cisco.com Thu Sep 5 12:31:15 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8CC11E81C6 for ; Thu, 5 Sep 2013 12:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKI4VH3NSucX for ; Thu, 5 Sep 2013 12:31:08 -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 0B22511E80EE for ; Thu, 5 Sep 2013 12:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=953; q=dns/txt; s=iport; t=1378409464; x=1379619064; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YbjZunUCR3Apznpjf2p4pdd0qJDP1G+8Y0tTx5nPrgM=; b=AQ0VRrEAFUTjOD8E9nGuzrrD0hQinqWgJHB+/K09Qpu/x+NdiqLkv576 uunrVZ+rFFvP9Ecif/z/Tp9ylhAqR1yye708OF1Xqnxd+d41rBsjAIcvh 12oViHMmGwH0NQZqrJOk5/jt2a5/DHwRzfZxADuK7UA5SRy7aq7RySjI1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAIrbKFKtJXHB/2dsb2JhbABbgweBBoJjvmiBKxZ0giYBBDo/EgEIIhRCJQIEDgUIh3q6Po8vMQeDHYEAA6lbgyCCKg X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256112466" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 05 Sep 2013 19:31:03 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r85JV3CL026172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 19:31:03 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.182]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 14:31:03 -0500 From: "Alvaro Retana (aretana)" To: Robert Raszuk Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqXJP8kslgYCLCUGB6LpPx3C/Kpm19BiAgADnPYCAAPoVAP//tJoA Date: Thu, 5 Sep 2013 19:31:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.21] Content-Type: text/plain; charset="us-ascii" Content-ID: <05AF5170F8640B4EBC67431C6D582156@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:31:15 -0000 On 9/5/13 2:00 PM, "Robert Raszuk" wrote: >>actually not. the whole point of forming a new WG is that >>folks do not sneak-in "*-routing" ideas in the respective >>protocol groups where people may not be paying attention. > >Thx for making the objective of this new WG finally very clear ;) > >In fact I would recommend we frame the above and make it as a charter. > >That way the new soon to be formed WG will be serving as *routing area >preview/policy working group* preventing anyone to be able to >"sneak-in" any protocol extension to respective routing protocols WGs >without making sure such extensions are politically correct and >approved by unanimity voting of anyone subscribed to the list. Robert: Hi! I assume you mean "preview/policy WG" for the technology in the charter (segment routing, or however you want to call it), and not for the whole routing area, right? ;-) Thanks! Alvaro. From rraszuk@gmail.com Thu Sep 5 12:49:05 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2CD21F9E6B for ; Thu, 5 Sep 2013 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjnubGSxja+A for ; Thu, 5 Sep 2013 12:49:05 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id AA92921F9E46 for ; Thu, 5 Sep 2013 12:49:04 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so2524553obc.13 for ; Thu, 05 Sep 2013 12:49:04 -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=cM4GVNK0GHWMhIWvFmxFMtDyIR0GGkNoWGSyTvI2kNo=; b=PuPkkUencywE6rsy36C5lylSop/zYR2GEtVpt/NngL+4njQsEP4STykwLWz2gJvl7T 48hEK3zzekXJVA9UPEfjdw3NcTKgpiFtt9OV63rgNmA9hiDidRz+Cthot51OU1NQy0ah CDEKymXU+EfTJnFNI1iW7uUfP7omzkRjIoCMtvNiTX1uOJrSK+0PakR1va+7KSyBdCP4 RzG/tezwdzoqgT+lepCgCkEjazaMs9JRsgI6n9ySSgBmTfGSEnw3er7/RFJzO7vFn2oC yCVPMKXm5fESmxBI4ZXchcWcr1vfQAVJ1fiJSRxDqc4UDjlOuDfQ7qLSbYzmjkuZRoKT lw8Q== MIME-Version: 1.0 X-Received: by 10.60.134.196 with SMTP id pm4mr2638281oeb.60.1378410544175; Thu, 05 Sep 2013 12:49:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.182.39.227 with HTTP; Thu, 5 Sep 2013 12:49:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Sep 2013 21:49:03 +0200 X-Google-Sender-Auth: nG0IkXsNp92iHjBIKuXhJI12Alc Message-ID: From: Robert Raszuk To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 19:49:05 -0000 Why not whole routing area if: "the whole point of forming a new WG is that folks do not sneak-in "*-routing" ideas in the respective protocol groups where people may not be paying attention." Let's set it up once and be done. Cheers, R. On Thu, Sep 5, 2013 at 9:31 PM, Alvaro Retana (aretana) wrote: > On 9/5/13 2:00 PM, "Robert Raszuk" wrote: > >>>actually not. the whole point of forming a new WG is that >>>folks do not sneak-in "*-routing" ideas in the respective >>>protocol groups where people may not be paying attention. >> >>Thx for making the objective of this new WG finally very clear ;) >> >>In fact I would recommend we frame the above and make it as a charter. >> >>That way the new soon to be formed WG will be serving as *routing area >>preview/policy working group* preventing anyone to be able to >>"sneak-in" any protocol extension to respective routing protocols WGs >>without making sure such extensions are politically correct and >>approved by unanimity voting of anyone subscribed to the list. > > Robert: > > Hi! > > I assume you mean "preview/policy WG" for the technology in the charter > (segment routing, or however you want to call it), and not for the whole > routing area, right? ;-) > > Thanks! > > Alvaro. > From hannes@juniper.net Thu Sep 5 14:17:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B124D11E81D7 for ; Thu, 5 Sep 2013 14:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt4rY3yZjpdU for ; Thu, 5 Sep 2013 14:17:24 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id ABE2611E8106 for ; Thu, 5 Sep 2013 14:17:23 -0700 (PDT) Received: from mail203-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 21:17:22 +0000 Received: from mail203-ch1 (localhost [127.0.0.1]) by mail203-ch1-R.bigfish.com (Postfix) with ESMTP id 61FD2180136; Thu, 5 Sep 2013 21:17:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(z551biz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail203-ch1: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail203-ch1 (localhost.localdomain [127.0.0.1]) by mail203-ch1 (MessageSwitch) id 1378415841144628_6447; Thu, 5 Sep 2013 21:17:21 +0000 (UTC) Received: from CH1EHSMHS009.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail203-ch1.bigfish.com (Postfix) with ESMTP id 1D6AC40084; Thu, 5 Sep 2013 21:17:21 +0000 (UTC) Received: from BL2PRD0512HT003.namprd05.prod.outlook.com (157.56.242.197) by CH1EHSMHS009.bigfish.com (10.43.70.9) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 21:17:20 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 21:17:20 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: Date: Thu, 5 Sep 2013 23:17:15 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net> References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:17:41 -0000 robert, given that current RTGWG chairs have already declined to work on architectural work on stacking labels do you have a suggestion where else this work should get done ? - CCAMP or perhaps MPLS (sic!) ? if not would you then consider for a moment the alternative and the = implications if architectural work involving more than one target protocol would get = done at the respective protocol-WGs ? i'd predict a whole lot of hush-hush protocol extensions, some even without requirements, some without = use-cases leaving a mess of incompatible protocols, leading in turn to = multi-annual protocol wars where at the end everybody has to support all protocols. have seen this movie several times before and as far as i am concerned i do not want this, nor my customers - - they are interested in shipping, interoperable code. shortcutting the process aka "awww we do not all of this" an inspiring unwarranted fear of "the protocol-policy wants to control = us" does not help to achieve the above. /hannes On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote: >> actually not. the whole point of forming a new WG is that >> folks do not sneak-in "*-routing" ideas in the respective >> protocol groups where people may not be paying attention. >=20 > Thx for making the objective of this new WG finally very clear ;) >=20 > In fact I would recommend we frame the above and make it as a charter. >=20 > That way the new soon to be formed WG will be serving as *routing area > preview/policy working group* preventing anyone to be able to > "sneak-in" any protocol extension to respective routing protocols WGs > without making sure such extensions are politically correct and > approved by unanimity voting of anyone subscribed to the list. >=20 > Cheers, > R. >=20 > PS. It's amazing to see this WG being formed considering a vast > majority of people attending the quote "non working group forming BOF" > in Berlin indicated no support for such new working group and segment > routing architecture to be discussed in current rtwg. >=20 >=20 From rraszuk@gmail.com Thu Sep 5 14:43:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55421F8C40 for ; Thu, 5 Sep 2013 14:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEfMAUvV6eEG for ; Thu, 5 Sep 2013 14:43:23 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE621F8424 for ; Thu, 5 Sep 2013 14:43:23 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so2681916obc.34 for ; Thu, 05 Sep 2013 14:43:13 -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=00T6QHcI1x1gdSP++JjtU7JHb1QsgNjcV8YS1oge4cE=; b=hAUCtdQu106dNgN1XvSrk/i1lO1PIQ+CBZzC/faW+Y6X5PqVtK3ASxk8hKBCyWKuXl 2xVv/znAy23vSJ+2ItOoSzx7Vagz/rAtlNysKVEkH6quuBp1hTlBh3d+RdPhVhNEBoTq hMfXQesgcfYVi5P8EzW3LDt4oZ9ZB6S3t/3H6D34lNvs0UyCYqrG9JTz/5N0wEMss3MR 59YrNtTA2m0smNWBs6FootlXE73nyw1OxAZ+X706guT4r2dkQs8jwR4IgLzLzSOF/ERE JiU6Z6ozGrp32eH6WtvNCS8yVyFok28BiTwgucBBTeNwdQliVRTSNRyKUj8B5aR03E47 Pnbg== MIME-Version: 1.0 X-Received: by 10.60.39.169 with SMTP id q9mr1984611oek.79.1378417392324; Thu, 05 Sep 2013 14:43:12 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.182.39.227 with HTTP; Thu, 5 Sep 2013 14:43:12 -0700 (PDT) In-Reply-To: <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net> References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net> Date: Thu, 5 Sep 2013 23:43:12 +0200 X-Google-Sender-Auth: qQEhvjMRTOspSCylWFlQj5djVRI Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: text/plain; charset=ISO-8859-1 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:43:24 -0000 Hi Hannes, So you are saying that Alvaro declined to work on this in RTGWG where there is only 7 pretty stable active WG documents yet is keen on working on it in separate WG ? As far as I recall if chairs decline to work on what IETF community considers to be useful, chairs get replaced rather then new WGs get formed. Moreover I do not see any need for any "architectural work on stacking labels" .. as far as I recall stacking labels has been day one property of MPLS. Label POP - say without PHP - has also been pretty well known MPLS day one feature. Ooops there is no swap - does this grant new architecture ? Is this hypothetical WG also going to get involved in source routing work going on in homenet ? If not why not ? For the topic of movie being replayed I have pretty good history of similar past strategies where to block the substantial work various artificial requirements are being placed (say multicast, security, hold any progress of protocol extensions till architecture becomes normative document etc ...). I can bet that when let's say MPLS based segment routing data plane is complete the argument why to do this again in IPv6 will be brought up. Will that strategy help all customers ... clearly no. Cheers, R. >On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler wrote: > robert, > > given that current RTGWG chairs have already declined to work on > architectural work on stacking labels do you have a suggestion where > else this work should get done ? - CCAMP or perhaps MPLS (sic!) ? > > if not would you then consider for a moment the alternative and the implications > if architectural work involving more than one target protocol would get done > at the respective protocol-WGs ? i'd predict a whole lot of hush-hush > protocol extensions, some even without requirements, some without use-cases > leaving a mess of incompatible protocols, leading in turn to multi-annual protocol > wars where at the end everybody has to support all protocols. > have seen this movie several times before and > as far as i am concerned i do not want this, nor my customers - > - they are interested in shipping, interoperable code. > > shortcutting the process aka "awww we do not all of this" > an inspiring unwarranted fear of "the protocol-policy wants to control us" > does not help to achieve the above. > > /hannes > > On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote: > >>> actually not. the whole point of forming a new WG is that >>> folks do not sneak-in "*-routing" ideas in the respective >>> protocol groups where people may not be paying attention. >> >> Thx for making the objective of this new WG finally very clear ;) >> >> In fact I would recommend we frame the above and make it as a charter. >> >> That way the new soon to be formed WG will be serving as *routing area >> preview/policy working group* preventing anyone to be able to >> "sneak-in" any protocol extension to respective routing protocols WGs >> without making sure such extensions are politically correct and >> approved by unanimity voting of anyone subscribed to the list. >> >> Cheers, >> R. >> >> PS. It's amazing to see this WG being formed considering a vast >> majority of people attending the quote "non working group forming BOF" >> in Berlin indicated no support for such new working group and segment >> routing architecture to be discussed in current rtwg. >> >> > > From stbryant@cisco.com Thu Sep 5 14:50:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1632111E810F for ; Thu, 5 Sep 2013 14:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYa92BbBAeR5 for ; Thu, 5 Sep 2013 14:50:30 -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 25E4921E80CC for ; Thu, 5 Sep 2013 14:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1592; q=dns/txt; s=iport; t=1378417830; x=1379627430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wBSfKWwwa3BUFlcOKeIFEXH4oUKMTZohBGii0QYZLsY=; b=lc//0SEtvQwrWnooU9n0vz6WrjkND24dRY6xjRCqJAHmm0G9fFFVeqbA bRxSps+xFXjRycvIgyDCwAbjw0RPr4cxLFXRxR/TSOBymUKPp1AarQzbk mtr/Z4LudE+6QDOEz4DWGMOKgndRGX4wuiuMEJiplD+yjQMN+4KsRpDMq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACD8KFKtJXG//2dsb2JhbABbgwc1wh2BKxZ0giQBAQEDAQEBATc0CxACAQgSJBAnCxcOAgQOBYd8Bgy6MgSOF4EWMweDHYEAA5d1kWaDIIFx X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256176202" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 05 Sep 2013 21:50:29 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r85LoT0c022555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 21:50:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.145]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 16:50:29 -0500 From: "Stewart Bryant (stbryant)" To: Robert Raszuk Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqmpZSMEZEzGhbEejhjlVzriutJm3rwp5 Date: Thu, 5 Sep 2013 21:50:28 +0000 Message-ID: <4F8CA45B-9FAA-447A-AB05-317EF22BA4CE@cisco.com> References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:50:35 -0000 Robert, please read my summary email that started this thread. Given 7 WGs that need to contribute (before we even consider OAM and Manage= ment, or the inevitable feature creep ) and the work potentially spanning t= wo IETF areas, there needs to be some group that can see the whole picture,= and act a as a focus to ensure a consistent design. Stewart Sent from my iPad On 5 Sep 2013, at 20:01, "Robert Raszuk" wrote: >> actually not. the whole point of forming a new WG is that >> folks do not sneak-in "*-routing" ideas in the respective >> protocol groups where people may not be paying attention. >=20 > Thx for making the objective of this new WG finally very clear ;) >=20 > In fact I would recommend we frame the above and make it as a charter. >=20 > That way the new soon to be formed WG will be serving as *routing area > preview/policy working group* preventing anyone to be able to > "sneak-in" any protocol extension to respective routing protocols WGs > without making sure such extensions are politically correct and > approved by unanimity voting of anyone subscribed to the list. >=20 > Cheers, > R. >=20 > PS. It's amazing to see this WG being formed considering a vast > majority of people attending the quote "non working group forming BOF" > in Berlin indicated no support for such new working group and segment > routing architecture to be discussed in current rtwg. > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From aretana@cisco.com Thu Sep 5 14:57:39 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00EE21E814D for ; Thu, 5 Sep 2013 14:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-pCdx7tcY+U for ; Thu, 5 Sep 2013 14:57:33 -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 E6B0921E8137 for ; Thu, 5 Sep 2013 14:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=514; q=dns/txt; s=iport; t=1378418253; x=1379627853; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qRpOU8jK52BwrvHU4tbGAi8T5F23HKFlUL6MspFUWts=; b=b+43Y1ni4HtsCx/KG5Yc0E21HF4DEv8+gFQQEKzGydT0BXPRW6J2u7yd jpHxzGxKFnmyXCoP6G1Rle2EU+aBrBLz21VAwR056ib/SVcWimTrnXbsL LUuYEuX0ezpsS5eCRO9UH6ggYxZqv8R9SwpCVNb1iWkYLnVh1BWzGgr7Q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJL9KFKtJV2Y/2dsb2JhbABbgweBBoJjvmmBKxZ0giYBBDo/EgEIIhRCJQIEDgUIh3q6RI8vMQeDHYEAA6lbgyCCKg X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256198635" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 05 Sep 2013 21:57:32 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r85LvWSf012727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 21:57:32 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 16:57:32 -0500 From: "Alvaro Retana (aretana)" To: Hannes Gredler Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqXJP8kslgYCLCUGB6LpPx3C/Kpm19BiAgADnPYCAAPoVAIAAJhmA//+3ZgA= Date: Thu, 5 Sep 2013 21:57:31 +0000 Message-ID: In-Reply-To: <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.208] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:57:39 -0000 On 9/5/13 4:17 PM, "Hannes Gredler" wrote: Hannes: >given that current RTGWG chairs have already declined to work on >architectural work on stacking labels Just to clarify: the decision was made by the IESG/ADs to hold the BOF and then the resulting train of events. The work that is chartered in rtgwg (or any other WG for that matter) is not a decision made by the chairs, but it is a result of WG consensus and (if needed) rechartering approved by the IESG/Ads. Alvaro. From stbryant@cisco.com Thu Sep 5 15:10:04 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FA921F9FF2 for ; Thu, 5 Sep 2013 15:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.392 X-Spam-Level: X-Spam-Status: No, score=-110.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF2igQwlZQ1E for ; Thu, 5 Sep 2013 15:09:59 -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 76CAF21E8155 for ; Thu, 5 Sep 2013 15:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4662; q=dns/txt; s=iport; t=1378418999; x=1379628599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZrkNf7VDuaq1NeUE4TlO6/53w3ZyeURFXkumDiiarv0=; b=TegHh7NZiYU6gRdAETXbpdthpbQG1TZbOjqjUaNYiOX2vBJbbyo+fZVq K3FAU7NJtn6SQUpgM2F29rmdNCXiUbAs1vgJy/E2vD7/tCypZgH7LhGKT LE6k3zVT0Eo+MWhEGVXgdzpemsPpllhg4tv4fy9eW1BRvCtl4R+5IB2FY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJQAKVKtJV2a/2dsb2JhbABbgwc1wh6BKxZ0giQBAQEDAQEBATc0CwULAgEIEgYeECcLFw4CBA4FFIdoBgy6YgSPLTMHgx2BAAOXdZFmgyA X-IronPort-AV: E=Sophos;i="4.90,849,1371081600"; d="scan'208";a="256178913" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 05 Sep 2013 22:09:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r85M9wn6022194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 22:09:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.145]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 17:09:58 -0500 From: "Stewart Bryant (stbryant)" To: Robert Raszuk Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqmpZSMEZEzGhbEejhjlVzriutJm3+ZOAgAAHQAD//7Op5w== Date: Thu, 5 Sep 2013 22:09:57 +0000 Message-ID: References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:10:04 -0000 Robert, You should set aside the the name of the WG, and whether it is a new WG or = and existing one, and consider the charter. WGs are constrained to only work on items specified in their charter, so wh= ether we spin up a new WG, or put the work in an existing WG, we need a pre= cise definition of the work, from dataplane(s), through control planes, OAM= , management etc, since all of these will be impacted to some degree, small= or large, by the need to provide the consistent collection of protocol upd= ates that will provide the SR functionality.=20 So for the moment, can we focus on the a definition of the objective of the= work, and an estimate of the work needed to produce a consistent design, i= .e. focus on the charter. Stewart Sent from my iPad On 5 Sep 2013, at 22:43, "Robert Raszuk" wrote: > Hi Hannes, >=20 > So you are saying that Alvaro declined to work on this in RTGWG where > there is only 7 pretty stable active WG documents yet is keen on > working on it in separate WG ? >=20 > As far as I recall if chairs decline to work on what IETF community > considers to be useful, chairs get replaced rather then new WGs get > formed. >=20 > Moreover I do not see any need for any "architectural work on stacking > labels" .. as far as I recall stacking labels has been day one > property of MPLS. Label POP - say without PHP - has also been pretty > well known MPLS day one feature. Ooops there is no swap - does this > grant new architecture ? >=20 > Is this hypothetical WG also going to get involved in source routing > work going on in homenet ? If not why not ? >=20 > For the topic of movie being replayed I have pretty good history of > similar past strategies where to block the substantial work various > artificial requirements are being placed (say multicast, security, > hold any progress of protocol extensions till architecture becomes > normative document etc ...). >=20 > I can bet that when let's say MPLS based segment routing data plane is > complete the argument why to do this again in IPv6 will be brought up. > Will that strategy help all customers ... clearly no. >=20 > Cheers, > R. >=20 >=20 >> On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler wro= te: >> robert, >>=20 >> given that current RTGWG chairs have already declined to work on >> architectural work on stacking labels do you have a suggestion where >> else this work should get done ? - CCAMP or perhaps MPLS (sic!) ? >>=20 >> if not would you then consider for a moment the alternative and the impl= ications >> if architectural work involving more than one target protocol would get = done >> at the respective protocol-WGs ? i'd predict a whole lot of hush-hush >> protocol extensions, some even without requirements, some without use-ca= ses >> leaving a mess of incompatible protocols, leading in turn to multi-annua= l protocol >> wars where at the end everybody has to support all protocols. >> have seen this movie several times before and >> as far as i am concerned i do not want this, nor my customers - >> - they are interested in shipping, interoperable code. >>=20 >> shortcutting the process aka "awww we do not all of this" >> an inspiring unwarranted fear of "the protocol-policy wants to control u= s" >> does not help to achieve the above. >>=20 >> /hannes >>=20 >> On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote: >>=20 >>>> actually not. the whole point of forming a new WG is that >>>> folks do not sneak-in "*-routing" ideas in the respective >>>> protocol groups where people may not be paying attention. >>>=20 >>> Thx for making the objective of this new WG finally very clear ;) >>>=20 >>> In fact I would recommend we frame the above and make it as a charter. >>>=20 >>> That way the new soon to be formed WG will be serving as *routing area >>> preview/policy working group* preventing anyone to be able to >>> "sneak-in" any protocol extension to respective routing protocols WGs >>> without making sure such extensions are politically correct and >>> approved by unanimity voting of anyone subscribed to the list. >>>=20 >>> Cheers, >>> R. >>>=20 >>> PS. It's amazing to see this WG being formed considering a vast >>> majority of people attending the quote "non working group forming BOF" >>> in Berlin indicated no support for such new working group and segment >>> routing architecture to be discussed in current rtwg. > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From hannes@juniper.net Thu Sep 5 15:16:29 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA3D21E816D for ; Thu, 5 Sep 2013 15:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.844 X-Spam-Level: X-Spam-Status: No, score=-4.844 tagged_above=-999 required=5 tests=[AWL=1.755, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A-pl24PEab5 for ; Thu, 5 Sep 2013 15:16:23 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB8C21E816A for ; Thu, 5 Sep 2013 15:16:23 -0700 (PDT) Received: from mail159-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 22:16:22 +0000 Received: from mail159-co9 (localhost [127.0.0.1]) by mail159-co9-R.bigfish.com (Postfix) with ESMTP id B0F4C260045; Thu, 5 Sep 2013 22:16:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(z551biz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1de097hz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail159-co9: domain of juniper.net designates 157.56.238.5 as permitted sender) client-ip=157.56.238.5; envelope-from=hannes@juniper.net; helo=BY2PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail159-co9 (localhost.localdomain [127.0.0.1]) by mail159-co9 (MessageSwitch) id 1378419381302440_18245; Thu, 5 Sep 2013 22:16:21 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.228]) by mail159-co9.bigfish.com (Postfix) with ESMTP id 3C72A24004D; Thu, 5 Sep 2013 22:16:21 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 22:16:21 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.243.34) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 22:16:18 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Fri, 6 Sep 2013 00:16:07 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <336266A2-18BA-45DE-9514-0DA0EBA74AF6@juniper.net> References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:16:29 -0000 robert, On Sep 5, 2013, at 11:43 PM, Robert Raszuk wrote: > [ =85 ] > For the topic of movie being replayed I have pretty good history of > similar past strategies where to block the substantial work various > artificial requirements are being placed (say multicast, security, > hold any progress of protocol extensions till architecture becomes > normative document etc ...). >=20 > I can bet that when let's say MPLS based segment routing data plane is > complete the argument why to do this again in IPv6 will be brought up. > Will that strategy help all customers ... clearly no. and even if you dislike it - its a valid question - all i am asking is that we have to document the use-cases for each data = plane (especially for new ones) seperatetly prior to change of protocols. i need really a bit more more substance rather than "aww this could be interesting for service chaining =85." before commencing expensive ASIC rework for introducing data plane #4 on the global internet. i am sorry that the "reqs-before-protocol-work" diligence and asking questions "if the same thing can get achieved using existing technology" is being perceived as slow down tactics - its not; its prudent work, nothing else. /hannes >> On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler = wrote: >> robert, >>=20 >> given that current RTGWG chairs have already declined to work on >> architectural work on stacking labels do you have a suggestion where >> else this work should get done ? - CCAMP or perhaps MPLS (sic!) ? >>=20 >> if not would you then consider for a moment the alternative and the = implications >> if architectural work involving more than one target protocol would = get done >> at the respective protocol-WGs ? i'd predict a whole lot of hush-hush >> protocol extensions, some even without requirements, some without = use-cases >> leaving a mess of incompatible protocols, leading in turn to = multi-annual protocol >> wars where at the end everybody has to support all protocols. >> have seen this movie several times before and >> as far as i am concerned i do not want this, nor my customers - >> - they are interested in shipping, interoperable code. >>=20 >> shortcutting the process aka "awww we do not all of this" >> an inspiring unwarranted fear of "the protocol-policy wants to = control us" >> does not help to achieve the above. >>=20 >> /hannes >>=20 >> On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote: >>=20 >>>> actually not. the whole point of forming a new WG is that >>>> folks do not sneak-in "*-routing" ideas in the respective >>>> protocol groups where people may not be paying attention. >>>=20 >>> Thx for making the objective of this new WG finally very clear ;) >>>=20 >>> In fact I would recommend we frame the above and make it as a = charter. >>>=20 >>> That way the new soon to be formed WG will be serving as *routing = area >>> preview/policy working group* preventing anyone to be able to >>> "sneak-in" any protocol extension to respective routing protocols = WGs >>> without making sure such extensions are politically correct and >>> approved by unanimity voting of anyone subscribed to the list. >>>=20 >>> Cheers, >>> R. >>>=20 >>> PS. It's amazing to see this WG being formed considering a vast >>> majority of people attending the quote "non working group forming = BOF" >>> in Berlin indicated no support for such new working group and = segment >>> routing architecture to be discussed in current rtwg. >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From akatlas@gmail.com Thu Sep 5 17:04:08 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ED011E8205 for ; Thu, 5 Sep 2013 17:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpZTupbq1-gn for ; Thu, 5 Sep 2013 17:04:07 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 754E211E81FE for ; Thu, 5 Sep 2013 17:04:07 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id s9so5238957iec.21 for ; Thu, 05 Sep 2013 17:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YUDkbDS6tPL/rOkhNYEYKplci6UjxK08KXhTBXFlx6U=; b=gDXsoe5jGFN4ayRxWJdbMiTNjvzqBQZ+en6As8dxf3004KLDgY+ui/NCseHcgxyajG MdupTbYLHgU0AinzH5vwG//JayQqUelNuFKrTmiV0c5cMD1eNLTQibymkkrkKvEPBKKv R4UXqaktKs8aiJ8M+3U+u+/05uXeihBtFDsb209UBzOe68imOa+wQRb659u7GDRzEr9N 0J63CH8xmN5JONQ6jeALbDN7HP9CAGPSCOa8Yt+fQBV6g82EoXPy3Aq0k4We2fso/nw5 OS3u2G/6Cdp1BKxGMyVoy9yjiqW3A2+Fgd/LvEWtPHdDSTiqDU8Gr6GWtgcajM/MpOjT zOMg== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr8058188igb.36.1378425846100; Thu, 05 Sep 2013 17:04:06 -0700 (PDT) Received: by 10.64.76.106 with HTTP; Thu, 5 Sep 2013 17:04:05 -0700 (PDT) In-Reply-To: References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> <70C92A2C-A6BD-4904-93B6-9215C8BBEE2F@juniper.net> Date: Thu, 5 Sep 2013 20:04:05 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7b10cf0de7fa9904e5abc634 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 00:04:08 -0000 --047d7b10cf0de7fa9904e5abc634 Content-Type: text/plain; charset=ISO-8859-1 Robert, If you look at the charter for RTGWG, it is chartered to work on hop-by-hop fast-reroute and "The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not yet rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and it is either not ready for a BOF or a single BOF would not provide the time to ensure a mature proposal. The RTGWG will serve as the forum for developing these types of proposals." The size of the work for STATUS would take over a significant part of the WG and hinder it from serving its current purposes. I think that the work doesn't fall in the parameters currently expressed in the charter. When a casual glance reveals at least 8+ drafts to be coordinated among many working groups, it is naive to assume that is the extend of the work involved. Obviously, the WG chairs serve at the pleasure of the ADs and work on the charter specified by the IESG. RTGWG is not busy with a large number of WG drafts, but we nonetheless keep occupied. Feel free to come by sometime and see :-) Alia On Thu, Sep 5, 2013 at 5:43 PM, Robert Raszuk wrote: > Hi Hannes, > > So you are saying that Alvaro declined to work on this in RTGWG where > there is only 7 pretty stable active WG documents yet is keen on > working on it in separate WG ? > > As far as I recall if chairs decline to work on what IETF community > considers to be useful, chairs get replaced rather then new WGs get > formed. > > Moreover I do not see any need for any "architectural work on stacking > labels" .. as far as I recall stacking labels has been day one > property of MPLS. Label POP - say without PHP - has also been pretty > well known MPLS day one feature. Ooops there is no swap - does this > grant new architecture ? > > Is this hypothetical WG also going to get involved in source routing > work going on in homenet ? If not why not ? > > For the topic of movie being replayed I have pretty good history of > similar past strategies where to block the substantial work various > artificial requirements are being placed (say multicast, security, > hold any progress of protocol extensions till architecture becomes > normative document etc ...). > > I can bet that when let's say MPLS based segment routing data plane is > complete the argument why to do this again in IPv6 will be brought up. > Will that strategy help all customers ... clearly no. > > Cheers, > R. > > > >On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler > wrote: > > robert, > > > > given that current RTGWG chairs have already declined to work on > > architectural work on stacking labels do you have a suggestion where > > else this work should get done ? - CCAMP or perhaps MPLS (sic!) ? > > > > if not would you then consider for a moment the alternative and the > implications > > if architectural work involving more than one target protocol would get > done > > at the respective protocol-WGs ? i'd predict a whole lot of hush-hush > > protocol extensions, some even without requirements, some without > use-cases > > leaving a mess of incompatible protocols, leading in turn to > multi-annual protocol > > wars where at the end everybody has to support all protocols. > > have seen this movie several times before and > > as far as i am concerned i do not want this, nor my customers - > > - they are interested in shipping, interoperable code. > > > > shortcutting the process aka "awww we do not all of this" > > an inspiring unwarranted fear of "the protocol-policy wants to control > us" > > does not help to achieve the above. > > > > /hannes > > > > On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote: > > > >>> actually not. the whole point of forming a new WG is that > >>> folks do not sneak-in "*-routing" ideas in the respective > >>> protocol groups where people may not be paying attention. > >> > >> Thx for making the objective of this new WG finally very clear ;) > >> > >> In fact I would recommend we frame the above and make it as a charter. > >> > >> That way the new soon to be formed WG will be serving as *routing area > >> preview/policy working group* preventing anyone to be able to > >> "sneak-in" any protocol extension to respective routing protocols WGs > >> without making sure such extensions are politically correct and > >> approved by unanimity voting of anyone subscribed to the list. > >> > >> Cheers, > >> R. > >> > >> PS. It's amazing to see this WG being formed considering a vast > >> majority of people attending the quote "non working group forming BOF" > >> in Berlin indicated no support for such new working group and segment > >> routing architecture to be discussed in current rtwg. > >> > >> > > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --047d7b10cf0de7fa9904e5abc634 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Robert,
If you look= at the charter for RTGWG, it is chartered to work on hop-by-hop fast-rerou= te and
"The Routing area receives occasional proposals for the develop= ment and=A0publication of RFCs deal= ing with routing topics, but for which the=A0required work does not yet rise to the level where a new working = group is=A0justified, yet the topic= does not fit with an existing working group,=A0and it is either not ready for a BOF or a single BOF would not= =A0provide the time to ensure a mat= ure proposal. The RTGWG will serve as=A0the forum for developing these types of proposals."=

The size of the work for STATUS would take over a sign= ificant part of the WG and hinder it from serving its current purposes. =A0= I think that the work doesn't fall in the parameters currently expresse= d in the charter. =A0When a casual glance reveals at least 8+ drafts to be = coordinated among many working groups, it is naive to assume that is the ex= tend of the work involved.

Obviously, the WG chairs serve at the pleasure of the ADs and work on the = charter specified by the IESG.

RTGWG is not busy with a large number of WG drafts, but we nonet= heless keep occupied. =A0Feel free to come by sometime and see :-)=A0

Alia


On Thu, Sep 5, 2013 at 5:43 PM, Robert R= aszuk <robert@raszuk.net> wrote:
Hi Hannes,

So you are saying that Alvaro declined to work on this in RTGWG where
there is only 7 pretty stable active WG documents yet is keen on
working on it in separate WG ?

As far as I recall if chairs decline to work on what IETF community
considers to be useful, chairs get replaced rather then new WGs get
formed.

Moreover I do not see any need for any "architectural work on stacking=
labels" .. as far as I recall stacking labels has been day one
property of MPLS. Label POP - say without PHP - has also been pretty
well known MPLS day one feature. Ooops there is no swap - does this
grant new architecture ?

Is this hypothetical WG also going to get involved in source routing
work going on in homenet ? If not why not ?

For the topic of movie being replayed I have pretty good history of
similar past strategies where to block the substantial work various
artificial requirements are being placed (say multicast, security,
hold any progress of protocol extensions till architecture becomes
normative document etc ...).

I can bet that when let's say MPLS based segment routing data plane is<= br> complete the argument why to do this again in IPv6 will be brought up.
Will that strategy help all customers ... clearly no.

Cheers,
R.


>On Thu, Sep 5, 2013 at 11:17 PM, Hannes Gredler <hannes@juniper.net> wrote:
> robert,
>
> given that current RTGWG chairs have already declined to work on
> architectural work on stacking labels do you have a suggestion where > else this work should get done ? - CCAMP or perhaps MPLS (sic!) ?
>
> if not would you then consider for a moment the alternative and the im= plications
> if architectural work involving more than one target protocol would ge= t done
> at the respective protocol-WGs ? i'd predict a whole lot of hush-h= ush
> protocol extensions, some even without requirements, some without use-= cases
> leaving a mess of incompatible protocols, leading in turn to multi-ann= ual protocol
> wars where at the end everybody has to support all protocols.
> have seen this movie several times before and
> as far as i am concerned i do not want this, nor my customers -
> - they are interested in shipping, interoperable code.
>
> shortcutting the process aka "awww we do not all of this" > an inspiring unwarranted fear of "the protocol-policy wants to co= ntrol us"
> does not help to achieve the above.
>
> /hannes
>
> On Sep 5, 2013, at 9:00 PM, Robert Raszuk wrote:
>
>>> actually not. the whole point of forming a new WG is that
>>> folks do not sneak-in "*-routing" ideas in the respe= ctive
>>> protocol groups where people may not be paying attention.
>>
>> Thx for making the objective of this new WG finally very clear ;)<= br> >>
>> In fact I would recommend we frame the above and make it as a char= ter.
>>
>> That way the new soon to be formed WG will be serving as *routing = area
>> preview/policy working group* preventing anyone to be able to
>> "sneak-in" any protocol extension to respective routing = protocols WGs
>> without making sure such extensions are politically correct and >> approved by unanimity voting of anyone subscribed to the list.
>>
>> Cheers,
>> R.
>>
>> PS. It's amazing to see this WG being formed considering a vas= t
>> majority of people attending the quote "non working group for= ming BOF"
>> in Berlin indicated no support for such new working group and segm= ent
>> routing architecture to be discussed in current rtwg.
>>
>>
>
>
_______________________________________________
status mailing list
status@ietf.org
= https://www.ietf.org/mailman/listinfo/status

--047d7b10cf0de7fa9904e5abc634-- From xuxiaohu@huawei.com Thu Sep 5 20:22:16 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E51A11E8230 for ; Thu, 5 Sep 2013 20:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dvLtBpXylrD for ; Thu, 5 Sep 2013 20:22:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC86B11E8222 for ; Thu, 5 Sep 2013 20:22:10 -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.5-GA FastPath queued) with ESMTP id AWY42468; Fri, 06 Sep 2013 03:22:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 04:21:41 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Sep 2013 04:22:00 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.199]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Fri, 6 Sep 2013 11:21:55 +0800 From: Xuxiaohu To: Anoop Ghanwani Thread-Topic: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps Thread-Index: AQHOqiSi/b4SMujOaECMfwfhKEZkXZm4ACRg Date: Fri, 6 Sep 2013 03:21:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBC@NKGEML512-MBS.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <52270A74.7010707@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202966@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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 03:22:17 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQW5vb3AsDQoNCkl0IGV4YWN0bHkgdXNlcyB0aGUgTVBMUy1pbi1HUkUgb3Igb3RoZXIgSVAt YmFzZWQgZW5jYXBzdWxhdGlvbnMgZm9yIE1QTFMuDQoNCkFueXdheSwgdW5sZXNzIGl0IGlzIG1h bmRhdG9yeSB0byBjb250YWluIGEgbGlzdCBvZiBJUHY2IGFkZHJlc3NlcyBpbiB0aGUgSVB2NiBk YXRhIHBhY2tldCBmb3IgaW5kaWNhdGluZyB0aGUgcHJlZGVmaW5lZCBuZXh0LWhvcHMgb2YgYSBn aXZlbiBleHBsaWNpdCBzb3VyY2UgcGF0aCwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHVzZSBhIGxp c3Qgb2YgU0hPUlRFUiBJRHMvbGFiZWxzIGluc3RlYWQgb2YgdGhlIDEyOC1iaXQgbG9uZyBJUHY2 IGFkZHJlc3NlcyB0byBpbmRpY2F0ZSB0aG9zZSBwcmVkZWZpbmVkIG5leHQtaG9wcy4gSU1ITywg dGhlIGV4aXN0aW5nIE1QTFMgbGFiZWwgc3RhY2sgbWVjaGFuaXNtIGhhcHBlbnMgdG8gYmUgYW4g aWRlYWwgY2FuZGlkYXRlIGZvciB0aGlzLiBQZW9wbGUgd2hvIHdhbnQgdG8gdXNlIHN1Y2ggbWVj aGFuaXNtIGRvbqGvdCBuZWVkIHRvIGtub3cgYW55IG90aGVyIGFwcGxpY2F0aW9ucyBvZiBNUExT LiBUaGUgb25seSB0aGluZyB0aGF0IHRoZXkgbmVlZCB0byBrbm93IGlzIHRoYXQgc2hvcnQgKE1Q TFMpIGxhYmVscywgaW5zdGVhZCBvZiBJUHY2IGFkZHJlc3NlcyBhcmUgdXNlZCBpbiB0aGUgSVB2 NiBkYXRhIHBhY2tldCB0byBpbmRpY2F0ZSB0aGUgcHJlZGVmaW5lZCBuZXh0LWhvcHMuIFRoZXJl Zm9yZSwgaXQgc2VlbXMgdGhhdCB0aGVyZSBpcyBubyBzdHJvbmcgdGVjaG5pY2FsIG1vdGl2YXRp b24gdG8gcmVpbnZlbnQgdGhlIHdoZWVsIGZvciB0aGUgSVB2NiBkYXRhIHBsYW5lLg0KDQpCZXN0 IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOiBnaGFud2FuaUBnbWFpbC5jb20gW21haWx0bzpn aGFud2FuaUBnbWFpbC5jb21dILT6se0gQW5vb3AgR2hhbndhbmkNCreiy83KsbzkOiAyMDEzxOo5 1MI1yNUgMTg6NDINCsrVvP7IyzogWHV4aWFvaHUNCrOty806IHN0YnJ5YW50QGNpc2NvLmNvbTsg c3RhdHVzQGlldGYub3JnDQrW98ziOiBSZTogW1N0YXR1c10gQSBwb3NzaWJsZSB3YXkgdG8gbWFr ZSBJUCBmYW5zIGhhcHB5Ly9yZTogU3VtbWFyeSBvZiBTVEFUVVMgQk9GIGFuZCB0aGUgbmV4dCBz dGVwcw0KDQpJcyB0aGlzIGFueSBkaWZmZXJlbnQgdGhhbiBNUExTIG92ZXIgR1JFLCB3aGVyZSBH UkUgaXMgdXNlZCB0byBnZXQgb3ZlciBub24tTVBMUy1hd2FyZSBwYXJ0cyBvZiBhIG5ldHdvcms/ DQoNCkFub29wDQoNCk9uIFRodSwgU2VwIDUsIDIwMTMgYXQgMzoxNiBBTSwgWHV4aWFvaHUgPHh1 eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCkhp IGFsbCwNCg0KQWNjb3JkaW5nIHRvIHRoZSBCb0Ygc2Vzc2lvbiBhdCBJRVRGODcsIGl0IHNlZW1z IHRoYXQgdGhlcmUgYXJlIGEgY2VydGFpbiBudW1iZXIgb2YgcGVvcGxlIHdobyB3YW50IHRvIHNl ZSBhbiBJUHY2LWJhc2VkLCByYXRoZXIgdGhhbiBNUExTLWJhc2VkIHNvdXJjZSByb3V0aW5nIG1l Y2hhbmlzbS4gSG93ZXZlciwgaXQgc2VlbXMgdGhhdCBtYW55IHBlb3BsZSBhcmUgaGVzaXRhdGUg dG8gbWFrZSBhbnkgY2hhbmdlIHRvIHRoZSBleGlzdGluZyBNUExTIGFuZCBJUCBkYXRhIHBsYW5l cy4NCg0KSSB3b25kZXIgd2hldGhlciB0aGUgZm9sbG93aW5nIGxvdy1jb3N0IGFwcHJvYWNoIGNh biBtYWtlIHRob3NlIElQIGZhbnMgaGFwcHk6IHRoZSBwcmVkZWZpbmVkIG5leHQtaG9wcyB0aGF0 IHRoZSBleHBsaWNpdCBzb3VyY2UgcGF0aCBtdXN0IHRyYXZlcnNlIGFyZSBzdGlsbCBleHByZXNz ZWQgYnkgdGhlIE1QTFMgbGFiZWwgc3RhY2sgaW4gdGhlIGRhdGEgcGFja2V0cywgYnV0IHRoZSBh ZGphY2VudCBuZXh0LWhvcHMgYXJlIGNvbm5lY3RlZCB2aWEgcHVyZSBJUCBuZXR3b3JrcywgcmF0 aGVyIHRoYW4gTVBMUyBuZXR3b3Jrcy4gIEZvciBleGFtcGxlLCBpZiBMU1IgQSB3YW50cyB0byBz ZW5kIGEgTVBMUyBWUE4gcGFja2V0IGZvciBMU1IgWiBhbG9uZyBhbiBleHBsaWNpdCBwYXRoIHtC LCBDLCBafSwgaXQgd291bGQgcHVzaCB0aGUgbm9kZSBzZWdtZW50IGxhYmVsIGZvciBaIGFuZCB0 aGVuIHRoZSBub2RlIHNlZ21lbnQgbGFiZWwgZm9yIEMgaW50byB0aGUgZXhpc3RpbmcgTVBMUyBs YWJlbCBzdGFjaywgYW5kIHRoZW4gdHJhbnNwb3J0IHN1Y2ggTVBMUyBwYWNrZXQgb3ZlciBhbiBJ UCB0dW5uZWwgdG93YXJkcyBCLiBVcG9uIHJlY2VpdmluZyBzdWNoIE1QTFMgcGFja2V0IG92ZXIg dGhlIElQIHR1bm5lbCwgQiB3b3VsZCBsb29rIHVwIHRoZSBjb3JyZXNwb25kaW5nIE1QTFMgZm9y d2FyZGluZyB0YWJsZSBlbnRyeSBmb3IgdGhlIHRvcG1vc3QgbGFiZWwgKGkuZS4sIHRoZSBub2Rl IHNlZ21lbnQgbGFiZWwgZm9yIEMpIGFuZCBmaW5kIHRoZSBvdXQgaW50ZXJmYWNlIGZvciB0aGlz IHBhY2tldCBpcyBhbiBJUCB0dW5uZWwgaW50ZXJmYWNlIHdpdGggdHVubmVsIGRlc3RpbmF0aW9u IG9mIEMsIHRoZXJlZm9yZSBpdCB3b3VsZCBwb3AgdGhlIHRvcG1vc3QgbGFiZWwgKGlmIHRoZSBv dXQgbGFiZWwgb2YgdGhhdCBNUExTIGZvcndhcmRpbmcgZW50cnkgaXMgbnVsbCkgYW5kIHRoZW4g dHJhbnNwb3J0IHRoZSBNUExTIHBhY2tldCBvdmVyIGFuIElQIHR1bm5lbCB0b3dhcmRzIEMuICBP bmNlIEMgcmVjZWl2ZXMgc3VjaCBNUExTIHBhY2tldCBvdmVyIHRoZSBJUCB0dW5uZWwsIEMgd291 bGQgbG9vayB1cCB0aGUgY29ycmVzcG9uZGluZyBNUExTIGZvcndhcmRpbmcgZW50cnkgZm9yIHRo ZSBjdXJyZW50IHRvcG1vc3QgbGFiZWwgKGkuZS4sIHRoZSBub2RlIHNlZ21lbnQgbGFiZWwgZm9y IFopICwgYW5kIHRoZW4gZm9yd2FyZCB0aGlzIE1QTFMgcGFja2V0IG92ZXIgYW4gSVAgdHVubmVs IHRvd2FyZHMgWiBsaWtlIHdoYXQgQiBoYXMgZG9uZS4NCg0KVGhlIGFib3ZlIGFwcHJvYWNoIGhh cyBhdCBsZWFzdCB0aGUgZm9sbG93aW5nIGJlbmVmaXRzOg0KDQoNCjEpICAgIE5vIGNoYW5nZSB0 byB0aGUgZXhpc3RpbmcgTVBMUyBhbmQgSVAgZGF0YSBwbGFuZS4NCg0KMikgICAgTm8gcmVxdWly ZW1lbnQgZm9yIHRoZSBNUExTIGZvcndhcmRpbmcgY2FwYWJpbGl0eSBvbiBhbGwgcm91dGVycz0+ IG9ubHkgdGhvc2UgZXhwbGljaXQgaG9wcyBuZWVkIHRoZSBNUExTIGZvcndhcmRpbmcgY2FwYWJp bGl0eS4NCg0KMykgICAgTm8gcmVxdWlyZW1lbnQgZm9yIHNvZnR3YXJlIHVwZ3JhZGUgb24gYWxs IHJvdXRlcnM9PiBvbmx5IHRob3NlIGV4cGxpY2l0IGhvcHMgbmVlZCBzdWNoIHNvZnR3YXJlIHVw Z3JhZGUuDQoNCjQpICAgIExlc3MgTVRVIGNvbGxpc2lvbiByaXNrIGR1ZSB0byB0aGUgdXNhZ2Ug b2YgMjAtYml0IGxvbmcgTVBMUyBsYWJlbHMsIHJhdGhlciB0aGFuIDEyOC1iaXQgbG9uZyBJUHY2 IGFkZHJlc3NlcyBmb3IgaW5kaWNhdGluZyB0aGUgcHJlZGVmaW5lZCBuZXh0LWhvcHMgb2YgYSBn aXZlbiBleHBsaWNpdCBzb3VyY2UgcGF0aC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCrei vP7Iyzogc3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzdGF0dXMtYm91bmNl c0BpZXRmLm9yZz5dILT6se0gU3Rld2FydCBCcnlhbnQNCreiy83KsbzkOiAyMDEzxOo51MI0yNUg MTg6MjUNCsrVvP7IyzogTWFjaCBDaGVuDQqzrcvNOiBKb2huIEUgRHJha2U7IE1hcmsgVG93bnNs ZXk7IFZpY3RvciBLdWFyc2luZ2g7IFJvYmVydGEgTWFnbGlvbmUgKHJvYm1nbCk7IEpvaG4gRy4g U2N1ZGRlcjsgQWRyaWFuIEZhcnJlbDsgQWx2YXJvIFJldGFuYSAoYXJldGFuYSk7IHN0YXR1c0Bp ZXRmLm9yZzxtYWlsdG86c3RhdHVzQGlldGYub3JnPg0K1vfM4jogUmU6IFtTdGF0dXNdIFN1bW1h cnkgb2YgU1RBVFVTIEJPRiBhbmQgdGhlIG5leHQgc3RlcHMNCg0KDQpNYXkgSSBzdWdnZXN0IHRo YXQgd2UgdXNlIHRoZSBuYW1lICJTUiIgYW5kIHdvcnJ5DQphYm91dCB3aGF0IGl0IGJpbmRzIHRv IGxhdGVyLg0KDQpUaGUgaGlnaGVyIHByaW9yaXR5IGl0ZW0gaXMgdGhlIGNoYXJ0ZXIgdGV4dC4g RG9lcw0KYW55b25lIGhhdmUgYW55IGNvbW1lbnRzIG9uIHRoZSB0ZXh0IHByb3Bvc2VkDQpzbyBm YXIsIG9yIHRoZSB0ZXh0IGluIHRoZSBCT0YgcHJvcG9zYWw6DQoNCg0KVGhlIFN0YWNrZWQgVHVu bmVscyBmb3IgU291cmNlIFJvdXRpbmcgKFNUQVRVUykgV29ya2luZyBHcm91cA0KaXMgY2hhcnRl cmVkIHRvIGRldmVsb3AgYSBmcmFtZXdvcmsgYW5kIHVzZSBjYXNlcyBmb3Igc291cmNlLXJvdXRl ZA0KZmxvd3MgaW4gcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtzLg0KDQpJUCBwcmV2aW91c2x5IGhh ZCBhIHNvdXJjZS1iYXNlZCByb3V0aW5nIG1lY2hhbmlzbSBtYWRlDQphdmFpbGFibGUgdGhyb3Vn aCBhbiBJUCBPcHRpb24uIFRoaXMgbWVjaGFuaXNtIGhhcywgaG93ZXZlciwNCm5vdCBiZWVuIHdp ZGVseSB1c2VkIGFuZCBoYXMgYSBudW1iZXIgb2YgaXNzdWVzIHRoYXQgbWFrZSBpdHMNCnVzZSBp bmFkdmlzYWJsZSwgYW5kIG90aGVyIG1lY2hhbmlzbXMgKHN1Y2ggYXMgUkZDIDE5NDApDQpkbyBu b3QgYXBwZWFyIHRvIGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBhdCBhbGwuDQoNClRoZSBhYmlsaXR5 IG9mIGEgcm91dGVyIHRvIGluZmx1ZW5jZSBvciBjb250cm9sIHRoZSBmb3J3YXJkaW5nDQpwYXRo IG9mIGFuIGluZGl2aWR1YWwgcGFja2V0IG9yIGFsbCB0aGUgcGFja2V0cyBvZiBhIGdpdmVuDQpG b3J3YXJkaW5nIEVxdWl2YWxlbmNlIENsYXNzIChGRUMpIGlzIGEgZGVzaXJhYmxlIGZlYXR1cmUN CmZvciBhIG51bWJlciBvZiByZWFzb25zIGluY2x1ZGluZyBMYWJlbCBTd2l0Y2hlZCBQYXRoIHN0 aXRjaGluZywNCmVncmVzcyBwcm90ZWN0aW9uLCBleHBsaWNpdCByb3V0aW5nLCBlZ3Jlc3MgQVNC UiBsaW5rIHNlbGVjdGlvbiwNCmFuZCBiYWNrdXAgKGJ5cGFzcyB0dW5uZWxzLCBSZW1vdGUgTG9v cC1GcmVlIEFsdGVybmF0ZXMpDQpyb3V0aW5nLiBUaGlzIGNhbiBiZSBhY2hpZXZlZCBieSBmYWNp bGl0YXRpbmcgc291cmNlLWluaXRpYXRlZA0Kc2VsZWN0aW9uIG9mIHJvdXRlcyB0byBjb21wbGVt ZW50IHRoZSByb3V0ZSBzZWxlY3Rpb24NCnByb3ZpZGVkIGJ5IGV4aXN0aW5nIHJvdXRpbmcgcHJv dG9jb2xzIGZvciBib3RoIGludGVyLSBkb21haW4NCmFuZCBpbnRyYS1kb21haW4gcm91dGVzLg0K DQpIaXN0b3JpY2FsbHksIGRpc3RyaWJ1dGlvbiBvZiBNUExTIGxhYmVsIGJpbmRpbmcgaW5mb3Jt YXRpb24NCndhcyBkb25lIGJ5IHJlbHlpbmcgb24gbGFiZWwgZGlzdHJpYnV0aW9uIHByb3RvY29s cw0Kc3VjaCBhcyBMRFAgYW5kIFJTVlAtVEUuDQoNClRoZSB1c2UgY2FzZXMgZG9jdW1lbnRlZCBi eSB0aGUgd29ya2luZyBncm91cCB3aWxsDQppbmRpY2F0ZSB0aGUgbmV0d29yayBmdW5jdGlvbiB0 aGF0IGlzIGJlaW5nIGZhY2lsaXRhdGVkDQphbmQgaW5kaWNhdGUgd2hpY2ggcGFja2V0IGRhdGEg cGxhbmUgaXMgdG8gYmUgdXNlZC4NCg0KVGhlIGZyYW1ld29yayBkZXZlbG9wZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAgd2lsbA0KY29uc2lkZXIgZm9yd2FyZGluZyBvZiBJUHY0LCBJUHY2LCBhbmQg TVBMUyB1c2luZyB0aGUNCmV4aXN0aW5nIHVuaWNhc3QgZGF0YSBwbGFuZXMuIE11bHRpY2FzdCBm b3J3YXJkaW5nIHdpbGwNCmJlIGZvciBmdXR1cmUgc3R1ZHkgYW5kIHRoZSBjaG9pY2Ugb2YgZGF0 YSBwbGFuZXMgd2lsbA0KYmUgbGltaXRlZCB0byB0aG9zZSBmb3Igd2hpY2ggdXNlIGNhc2VzIGV4 aXN0LiBBIGtleQ0Kb2JqZWN0aXZlIG9mIHRoZSB3b3JrIHdpbGwgYmUgdG8gZW5zdXJlIHRoYXQg c291cmNlLQ0Kcm91dGVkIHBhY2tldHMgY2FuIGJlIGhhbmRsZWQgc2VhbWxlc3NseSBieSBleGlz dGluZw0KZGVwbG95ZWQgZXF1aXBtZW50LiBBIG1ham9yIG9iamVjdGl2ZSB3aWxsIGJlIHRoYXQg dGhlDQpuZXcgZnVuY3Rpb24gZG9lcyBub3QgbW9kaWZ5IGV4aXN0aW5nIGRhdGEgcGxhbmUgYmVo YXZpb3INCm9yIGFyY2hpdGVjdHVyZXMsIGFuZCB0aGF0IGl0IGNhbiBiZSBlbmFibGVkIHRocm91 Z2ggb25seQ0KY29udHJvbCBhbmQgbWFuYWdlbWVudCBwbGFuZSBzb2Z0d2FyZSB1cGdyYWRlcyBh dA0KZGVwbG95ZWQgZGV2aWNlcy4NCg0KT25jZSB0aGUgd29ya2luZyBncm91cCBoYXMgZXN0YWJs aXNoZWQgYSBmcmFtZXdvcmsNCmFuZCB0aGVyZSBpcyBkZW1vbnN0cmFibGUgY29uc2Vuc3VzIGZv ciB1c2UgY2FzZXMsDQp0aGUgd29ya2luZyBncm91cCB3aWxsIG1vdmUgZm9yd2FyZCB0byBzcGVj aWZ5IHByb3RvY29sDQpzb2x1dGlvbnMgZm9yIGluc3RhbGxpbmcgZm9yd2FyZGluZyBpbmZvcm1h dGlvbiB0aHJvdWdoDQp0aGUgdXNlIG9mIHRoZSBJR1BzIChPU1BGIGFuZCBJUy1JUyksIG9yIHRo cm91Z2ggdGhlDQptYW5hZ2VtZW50IHBsYW5lLiBJbiB0aGUgY291cnNlIG9mIGRldmVsb3Bpbmcg cHJvdG9jb2wNCmV4dGVuc2lvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgd29yayBjbG9zZWx5 IHdpdGgNCm90aGVyIElFVEYgd29ya2luZyBncm91cHMgcmVzcG9uc2libGUgZm9yIHRoZSBwcm90 b2NvbHMNCmJlaW5nIG1vZGlmaWVkIChzdWNoIGFzIE9TUEYsIElTSVMsIGFuZCBJMlJTKS4NCg0K ICAgIFRoZSB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCBmb3IgdGhlIGZvbGxvd2luZyB3b3Jr IGl0ZW1zOg0KDQogICAgQSBmcmFtZXdvcmsgZm9yIHRoZSB1c2Ugb2YgdGhlIGV4aXN0aW5nIE1Q TFMgZGF0YSBwbGFuZSB0bw0KICAgIHN1cHBvcnQgdHVubmVsLWJhc2VkIHVuaWNhc3Qgc291cmNl IHJvdXRpbmcuDQoNCiAgICBEZXZlbG9wIHVzZSBjYXNlcyBmb3IgdHVubmVsLWJhc2VkIHVuaWNh c3Qgc291cmNlIHJvdXRpbmcNCiAgICB0aGF0IGRlbW9uc3RyYXRlIHRoZSBuZWVkIGFuZCBzdXBw b3J0IGZvciBzb2x1dGlvbnMuIENhcmUNCiAgICBzaG91bGQgYmUgdGFrZW4gdG8gYXZvaWQgY2x1 c3RlcmluZyB1c2UgY2FzZXMgdGhhdCBtaWdodCBzZWVtDQogICAgdG8gaW1wbHkgc3VwcG9ydCBm b3IgbXVsdGlwbGUgdXNlIGNhc2VzIHdoZW4gb25seSBzb21lIG9mIHRoZQ0KICAgIGNsdXN0ZXIg YWN0dWFsbHkgaGF2ZSB3aWRlLXNjYWxlIHN1cHBvcnQuDQoNCiAgICBEZXZlbG9wIElTSVMgYW5k IE9TUEYgcHJvdG9jb2wgZXh0ZW5zaW9ucyBuZWNlc3NhcnkgZm9yDQogICBkaXN0cmlidXRpb24g b2YgTVBMUyBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLg0KDQogICAgVGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBjb25zaWRlciBtYW5hZ2VtZW50IChpbmNsdWRpbmcNCiAgICBjb25maWd1cmF0aW9uLCBy ZXBvcnRpbmcsIGRpYWdub3N0aWNzLCBhbmQgT0FNKSBhbmQgc2VjdXJpdHkNCiAgICBpbXBsaWNh dGlvbnMgb2YgaXRzIHdvcmsgYW5kIGRvY3VtZW50IHRoZW0gaW4gc2VwYXJhdGUNCiAgICBkb2N1 bWVudHMgYXMgYXBwcm9wcmlhdGUuDQoNCiAgICBUaGUgd29ya2luZyBncm91cCBpcyBub3QgY2hh cnRlcmVkIHRvIG1ha2UgYW55IGNoYW5nZXMgdG8NCiAgICB0aGUgTVBMUyBvciBJUHY2IGRhdGEg cGxhbmVzLiBBbnkgcHJvcG9zZWQgY2hhbmdlcyB0byB0aGUNCiAgICBkYXRhIHBsYW5lcyBhcmUg dG8gYmUgc3BlY2lmaWVkIGluIHRoZSB3b3JraW5nIGdyb3VwcyByZXNwb25zaWJsZQ0KICAgIGZv ciB0aGUgZGF0YSBwbGFuZXMgKHRoYXQgaXMsIHRoZSBNUExTIGFuZCA2TUFOIHdvcmtpbmcgZ3Jv dXBzLA0KICAgIHJlc3BlY3RpdmVseSkuDQoNCi0gU3Rld2FydA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RhdHVzIG1haWxpbmcgbGlzdA0Kc3Rh dHVzQGlldGYub3JnPG1haWx0bzpzdGF0dXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Anoop,<= o:p>

 = ;

It exactly= uses the MPLS-in-GRE or other IP-based encapsulations for MPLS. 

 = ;

Anyway, u<= /span>nless it is mandatory to contain a list of IPv6 addresses in the IPv6= data packet for indicating the predefined next-hops of a given explicit so= urce path, it would be better to use a list of SHORTER IDs/labels instead of the 128-bit long IPv6 addresses to indicate those predefined ne= xt-hops. IMHO, the existing MPLS label stack mechanism happens to be an ide= al candidate for this. People who want to use such mechanism don=A1=AFt nee= d to know any other applications of MPLS. The only thing that they need to know is that short (MPLS) labels, instead= of IPv6 addresses are used in the IPv6 data packet to indicate the predefi= ned next-hops. Therefore, it seems that there is no strong technical motiva= tion to reinvent the wheel for the IPv6 data plane.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: ghanwani@gmail.com [mailto:ghanwani@gmail.com] =B4=FA=B1=ED Anoop Ghanwani
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA9=D4=C25=C8=D5 18= :42
=CA=D5=BC=FE=C8=CB: Xuxiaohu
=B3=AD=CB=CD: stbryant@cisco.com; status@ietf.org
=D6=F7=CC=E2: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS = BOF and the next steps

 

Is this any different than MPLS= over GRE, where GRE is used to get over non-MPLS-aware parts of a network?=

 

Anoop

=  

On Thu, Sep 5, 2013 at 3:16 AM,= Xuxiaohu <xuxi= aohu@huawei.com> wrote:

Hi all,

 

According to the BoF ses= sion at IETF87, it seems that there are a certain number of people who want to see an IPv6-based, rather than MPLS-based source routin= g mechanism. However, it seems that many people are hesitate to make any ch= ange to the existing MPLS and IP data planes.

 

I wonder whether the fol= lowing low-cost approach can make those IP fans happy: the predefined next-hops that the explicit source path must traverse are still expressed = by the MPLS label stack in the data packets, but the adjacent next-hops are= connected via pure IP networks, rather than MPLS networks.  For examp= le, if LSR A wants to send a MPLS VPN packet for LSR Z along an explicit path {B, C, Z}, it would push the node = segment label for Z and then the node segment label for C into the existing= MPLS label stack, and then transport such MPLS packet over an IP tunnel to= wards B. Upon receiving such MPLS packet over the IP tunnel, B would look up the corresponding MPLS forwardi= ng table entry for the topmost label (i.e., the node segment label for C) a= nd find the out interface for this packet is an IP tunnel interface with tu= nnel destination of C, therefore it would pop the topmost label (if the out label of that MPLS forwarding e= ntry is null) and then transport the MPLS packet over an IP tunnel towards = C.  Once C receives such MPLS packet over the IP tunnel, C would look = up the corresponding MPLS forwarding entry for the current topmost label (i.e., the node segment label for Z) ,= and then forward this MPLS packet over an IP tunnel towards Z like what B = has done.

 

The above approach has a= t least the following benefits:

 

1= )    No change to the existing = MPLS and IP data plane.

2= )    No requirement for the MPL= S forwarding capability on all routers=3D> only those explicit hops need= the MPLS forwarding capability.

3= )    No requirement for softwar= e upgrade on all routers=3D> only those explicit hops need such software= upgrade.

4= )    Less MTU collision risk du= e to the usage of 20-bit long MPLS labels, rather than 128-bit long IPv6 ad= dresses for indicating the predefined next-hops of a given explicit source path.

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8=CB: status-bounces= @ietf.org [mailto:status-bounces@ietf.org] =B4=FA=B1=ED Stewart Bryant
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA9=D4=C24=C8=D5 18= :25
=CA=D5=BC=FE=C8=CB: Mach Chen
=B3=AD=CB=CD: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl);= John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); status@ietf.org =D6=F7=CC=E2: Re: [Status] Summary of STATUS BOF and the next steps

 


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work it= ems:

    A framework for the use of the existing MPLS data plane = to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routin= g
    that demonstrate the need and support for solutions. Car= e
    should be taken to avoid clustering use cases that might= seem
    to imply support for multiple use cases when only some of the=
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for =
   distribution of MPLS forwarding information.

    The working group will consider management (including&nb= sp;
    configuration, reporting, diagnostics, and OAM) and secu= rity
    implications of its work and document them in separate <= br>     documents as appropriate.

    The working group is not chartered to make any changes t= o
    the MPLS or IPv6 data planes. Any proposed changes to th= e
    data planes are to be specified in the working groups re= sponsible
    for the data planes (that is, the MPLS and 6MAN working = groups, 
    respectively).

- Stewart

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

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08202DBCNKGEML512MBSchi_-- From sprevidi@cisco.com Thu Sep 5 23:48:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB28621E81C4 for ; Thu, 5 Sep 2013 23:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.809 X-Spam-Level: X-Spam-Status: No, score=-108.809 tagged_above=-999 required=5 tests=[AWL=1.790, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFS90Ggps2LN for ; Thu, 5 Sep 2013 23:48:18 -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 56F2D21E80A6 for ; Thu, 5 Sep 2013 23:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2459; q=dns/txt; s=iport; t=1378450098; x=1379659698; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wF9kHypmyuOrobGfNWtPiFwMY1cjHnUkpwMe2CKwh3g=; b=WBAmpithvCU+NHqRT5jfwHGH8o94tSX6dU7fEr/S1KJV8k/gtQSr8eU9 j2nf1KN6OoY9t1ZBYqIzXgQ8cfEuUGrbWA9MIc3ItdQ1ehTJk+n2Ws7sT ZBxsIgW29djd0/Xpu/y5yMpdW9+gUdSYqBZWPsIwzMMqozhq2gOEqbtNF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEFAG96KVKtJV2c/2dsb2JhbABbgweBBsFWgSIWbQeCJgEEOj8SARoQFEIXEAQODYd6uxmPQTGDJIEAA6lbgyCCKg X-IronPort-AV: E=Sophos;i="4.90,852,1371081600"; d="scan'208";a="253344648" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 06 Sep 2013 06:48:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r866iCFx005630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Sep 2013 06:44:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 6 Sep 2013 01:48:17 -0500 From: "Stefano Previdi (sprevidi)" To: "status@ietf.org" Thread-Topic: Proposed Charter Thread-Index: AQHOqs0Qohy0k4/BVkG4wal+W7vNDQ== Date: Fri, 6 Sep 2013 06:48:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.162.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <8BB1AAA4CA1CBA4B9C049F8C2E3B25C0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Clarence Filsfils \(cfilsfil\)" Subject: [Status] Proposed Charter X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 06:48:24 -0000 All, here follows a proposal for the charter. Thanks. s. ------------------------------------------------------------------- Name: SEGROUTE (or SR, or whatever else) Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance=20 data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.=20 have triggered work on the definition of new architecture and protocol=20 extensions allowing to combine well known shortest path based routing=20 paradigms with source/explicit routing methods. Some of these=20 extensions have been implemented already. Objective --------- Define an architecture where a node can steer a packet through a=20 controlled set of instructions, called segments while maintaining=20 per-explicit path state only at the ingress node. The instruction associated to a segment can be derived based on arbitrary mechanisms which may include: . Shortest path routing or explicit/source routing paradigms . Intra and inter domain path computation . Network or application layer . Network virtualization . Centralized or distributed path computation . Unicast or Multicast schemes . Others. The SEGROUTE architecture will support: . Tunnel and non-tunnel based paradigms . Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane=20 should be independent (agnostic) to the data-planes. The WG will work on the definition of the architecture and protocol=20 extensions. No new protocol specification is expected within this WG.=20 No MPLS data-plane changes are expected either. Instead the standardization work should consist in extensions in well=20 established protocols (ISIS, OSPF, BGP, PCEP, ...). It is expected that the SEGROUTE WG will help in the orchestration=20 of protocol extensions specification with the existing IETF Working=20 Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). =20 Documents --------- The WG will produce the following documents: . Problem Statement . Requirements . Use Cases . Architecture=20 . Interoperability Report The protocol extensions and data-plane instantiations will be handled=20 in their respective WGs. From Ruediger.Geib@telekom.de Thu Sep 5 23:51:30 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83B311E8281 for ; Thu, 5 Sep 2013 23:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+RRydmPTu+j for ; Thu, 5 Sep 2013 23:51:26 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0E011E8174 for ; Thu, 5 Sep 2013 23:51:25 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 06 Sep 2013 08:51:23 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 6 Sep 2013 08:51:23 +0200 From: To: Date: Fri, 6 Sep 2013 08:51:21 +0200 Thread-Topic: Proposed Charter Thread-Index: AQHOqs0Qohy0k4/BVkG4wal+W7vNDZm4RT+w Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org, cfilsfil@cisco.com Subject: Re: [Status] Proposed Charter X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 06:51:31 -0000 Hi Stefano, thanks and ok. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stefano Previdi (sprevidi) Sent: Friday, September 06, 2013 8:48 AM To: status@ietf.org Cc: Clarence Filsfils (cfilsfil) Subject: [Status] Proposed Charter All, here follows a proposal for the charter. Thanks. s. ------------------------------------------------------------------- Name: SEGROUTE (or SR, or whatever else) Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol extensions allowing to combine well known shortest path based routing paradigms with source/explicit routing methods. Some of these extensions have been implemented already. Objective --------- Define an architecture where a node can steer a packet through a controlled set of instructions, called segments while maintaining per-explicit path state only at the ingress node. The instruction associated to a segment can be derived based on arbitrary mechanisms which may include: . Shortest path routing or explicit/source routing paradigms . Intra and inter domain path computation . Network or application layer . Network virtualization . Centralized or distributed path computation . Unicast or Multicast schemes . Others. The SEGROUTE architecture will support: . Tunnel and non-tunnel based paradigms . Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane should be independent (agnostic) to the data-planes. The WG will work on the definition of the architecture and protocol extensions. No new protocol specification is expected within this WG. No MPLS data-plane changes are expected either. Instead the standardization work should consist in extensions in well established protocols (ISIS, OSPF, BGP, PCEP, ...). It is expected that the SEGROUTE WG will help in the orchestration of protocol extensions specification with the existing IETF Working Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). Documents --------- The WG will produce the following documents: . Problem Statement . Requirements . Use Cases . Architecture . Interoperability Report The protocol extensions and data-plane instantiations will be handled in their respective WGs. _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From Ruediger.Geib@telekom.de Fri Sep 6 00:09:54 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4846411E8282 for ; Fri, 6 Sep 2013 00:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=1.213, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdPd8IfZev6O for ; Fri, 6 Sep 2013 00:09:50 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id CC91811E8170 for ; Fri, 6 Sep 2013 00:09:49 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 06 Sep 2013 09:09:47 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 6 Sep 2013 09:09:47 +0200 From: To: Date: Fri, 6 Sep 2013 09:09:45 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: AQHOqmpZSMEZEzGhbEejhjlVzriutJm3rwp5gACarbA= Message-ID: References: <9D2D4D14-BA5C-4FD1-AE51-598677DE64D5@townsley.net> , <4F8CA45B-9FAA-447A-AB05-317EF22BA4CE@cisco.com> In-Reply-To: <4F8CA45B-9FAA-447A-AB05-317EF22BA4CE@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 07:09:54 -0000 Stewart, OAM work will start initially, I hope. As I mentioned, there's a prototype = applying SR technology (without the extensions required by any of the 7 WGs= of course). Still, experience collected there allows work on OAM requireme= nts and features. I'm exchanging mails with some interested colleagues already. We'd be happy= to continue the OAM discussion on a public list. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant (stbryant) Sent: Thursday, September 05, 2013 11:50 PM To: Robert Raszuk Cc: Hannes Gredler; status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps Robert, please read my summary email that started this thread. Given 7 WGs that need to contribute (before we even consider OAM and Manage= ment, or the inevitable feature creep ) and the work potentially spanning t= wo IETF areas, there needs to be some group that can see the whole picture,= and act a as a focus to ensure a consistent design. Stewart Sent from my iPad On 5 Sep 2013, at 20:01, "Robert Raszuk" wrote: >> actually not. the whole point of forming a new WG is that >> folks do not sneak-in "*-routing" ideas in the respective >> protocol groups where people may not be paying attention. > > Thx for making the objective of this new WG finally very clear ;) > > In fact I would recommend we frame the above and make it as a charter. > > That way the new soon to be formed WG will be serving as *routing area > preview/policy working group* preventing anyone to be able to > "sneak-in" any protocol extension to respective routing protocols WGs > without making sure such extensions are politically correct and > approved by unanimity voting of anyone subscribed to the list. > > Cheers, > R. > > PS. It's amazing to see this WG being formed considering a vast > majority of people attending the quote "non working group forming BOF" > in Berlin indicated no support for such new working group and segment > routing architecture to be discussed in current rtwg. > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From stephane.litkowski@orange.com Fri Sep 6 02:00:40 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88FA21F8578 for ; Fri, 6 Sep 2013 02:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG9qu9HyNxVf for ; Fri, 6 Sep 2013 02:00:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7621611E811D for ; Fri, 6 Sep 2013 02:00:36 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id BD0023B5ACD; Fri, 6 Sep 2013 11:00:29 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id A10DA18004B; Fri, 6 Sep 2013 11:00:29 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 6 Sep 2013 11:00:27 +0200 From: To: "Stefano Previdi (sprevidi)" , "status@ietf.org" Date: Fri, 6 Sep 2013 11:00:26 +0200 Thread-Topic: Proposed Charter Thread-Index: AQHOqs0Qohy0k4/BVkG4wal+W7vNDZm4aUYQ Message-ID: <5923_1378458029_522999AD_5923_180_1_EEE55384044474429A926C625D0FCC81096316258E@PUEXCB2F.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "Clarence Filsfils \(cfilsfil\)" Subject: Re: [Status] Proposed Charter X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 09:00:41 -0000 Agree on this charter proposal, just need to add security aspects. =20 -----Message d'origine----- De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de= Stefano Previdi (sprevidi) Envoy=E9 : vendredi 6 septembre 2013 08:48 =C0 : status@ietf.org Cc : Clarence Filsfils (cfilsfil) Objet : [Status] Proposed Charter All, here follows a proposal for the charter. Thanks. s. ------------------------------------------------------------------- Name: SEGROUTE (or SR, or whatever else) Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc.=20 have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a controlled= set of instructions, called segments while maintaining per-explicit path s= tate only at the ingress node. The instruction associated to a segment can be derived based on arbitrary m= echanisms which may include: . Shortest path routing or explicit/source routing paradigms . Intra and in= ter domain path computation . Network or application layer . Network virtua= lization . Centralized or distributed path computation . Unicast or Multica= st schemes . Others. The SEGROUTE architecture will support: . Tunnel and non-tunnel based paradigms . Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane should be independent (agnostic) to the data-planes. The WG will work on the definition of the architecture and protocol extensi= ons. No new protocol specification is expected within this WG.=20 No MPLS data-plane changes are expected either. Instead the standardization work should consist in extensions in well estab= lished protocols (ISIS, OSPF, BGP, PCEP, ...). It is expected that the SEGROUTE WG will help in the orchestration of proto= col extensions specification with the existing IETF Working Groups (ISIS, O= SPF, IDR, PCE, 6MAN, MPLS, ...). =20 Documents --------- The WG will produce the following documents: . Problem Statement . Requirements . Use Cases . Architecture . Interoperability Report The protocol extensions and data-plane instantiations will be handled in th= eir respective WGs. _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From hannes@juniper.net Fri Sep 6 09:27:53 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D797E21E8063 for ; Fri, 6 Sep 2013 09:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3066a3n-cDKm for ; Fri, 6 Sep 2013 09:27:45 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id E5F3611E817F for ; Fri, 6 Sep 2013 09:27:44 -0700 (PDT) Received: from mail83-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE033.bigfish.com (10.174.4.96) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Sep 2013 16:27:43 +0000 Received: from mail83-db8 (localhost [127.0.0.1]) by mail83-db8-R.bigfish.com (Postfix) with ESMTP id BA03A54020E; Fri, 6 Sep 2013 16:27:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -70 X-BigFish: VPS-70(z551biz62a3I98dI9371Ic89bh936eI542I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail83-db8: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail83-db8 (localhost.localdomain [127.0.0.1]) by mail83-db8 (MessageSwitch) id 1378484855904099_15321; Fri, 6 Sep 2013 16:27:35 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.251]) by mail83-db8.bigfish.com (Postfix) with ESMTP id BC318CC004A; Fri, 6 Sep 2013 16:27:35 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Sep 2013 16:27:35 +0000 Received: from tlennard-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.353.4; Fri, 6 Sep 2013 16:27:33 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> Date: Fri, 6 Sep 2013 18:27:29 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:27:53 -0000 hi stephane, here is a revised draft charter as per your comments. --- domain contains a set of routers with the following characteristics: - They form a connected network - They can forward traffic through any path within the network using shortest path, or any other (e.g., an explicit) path - They share a common trust model. In this model, any router within the domain can specify a path between itself and any other router in the domain. It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the = domain forward the packet as specified by the router at the head-end of the path. The working group is chartered for the following ordered list of work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between domains = (interdomain). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Protocol work may be carried out in this working group or in other working groups responsible for the protocols, in coordination with this WG, and in agreement with the WG chairs and responsible ADs. However, no protocol work will be adopted by a working group to address the identified use-cases until the requirements document motivating the protocol work has been sent to the IESG for publication as an RFC. --- /hannes On Sep 4, 2013, at 10:02 AM, = wrote: > Hannes, >=20 > In case, we are using only directed forwarding (adjacency segment), = could we still talk about tunneling ? (it's a very very small tunnel) > Moreover talking about "stacking" is really dataplane agnostic (MPLS) = ... >=20 > In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >=20 > IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >=20 > Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment = list. Actions associated with a segment could be something else than = forwarding. >=20 > Do we want in the charter to limit the scope to routing actions ? >=20 > I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >=20 > Regarding your charter proposal : >=20 > -------- >=20 > - They form a connected network > [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >=20 > - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) > [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >=20 > - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. > [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) >=20 > Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. > [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >=20 >=20 >=20 > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >=20 > [SLI] Agree, I would add : > - defining the architecture framework > - analysing the security considerisations >=20 >=20 > --------- >=20 >=20 > Here would be my proposal to extend yours : >=20 > A domain contains a set of routers with the = following characteristics: >=20 > - They form a connected network > - They can forward traffic through any path within the network using = shortest path, non shortest path or explicit path > - They may provide other types of services than forwarding and they = can enforce service actions in the path. > - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >=20 > The working group is chartered for the following ordered list = of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case = requirements. > - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >=20 > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la = part de Hannes Gredler > Envoy=E9 : mardi 3 septembre 2013 18:31 > =C0 : Loa Andersson > Cc : status@ietf.org > Objet : Re: [Status] Summary of STATUS BOF and the next steps >=20 > good point - what about this charter proposal ? >=20 > --- >=20 > Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >=20 > - They form a connected network > - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) > - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >=20 > The STER working group is chartered for the following ordered list of = work items: >=20 > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >=20 > --- >=20 > >=20 > /hannes >=20 >=20 > On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >=20 >> Folks, >>=20 >> Excuse me if I'm slightly out of the loop, but so far I have not seen >> a charter proposal, if there is one please point me to it. >>=20 >> It seems a bit odd to put the cart (what the wg should do) before the >> horse (wg name). If we drill down the the charter first the wg name >> might be easier to figure out. >>=20 >> /Loa >>=20 >> PS >> OK I understand that the horse and cart analogy limps a bit :). >>=20 >>=20 >>=20 >> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>> " If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ..." >>>=20 >>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>=20 >>> Peter >>>=20 >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of stephane.litkowski@orange.com >>> Sent: Tuesday, September 03, 2013 10:43 AM >>> To: AshwoodsmithPeter >>> Cc: status@ietf.org >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>=20 >>>=20 >>> There was a misunderstanding in my small comment :) so I will = explain more : >>>=20 >>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>=20 >>> In the other hand, I completely agree with your statement that = source >>> routing is generic and dataplane agnostic, as segment routing is ... >>> (segment routing is not a new dataplane ...) >>>=20 >>> Now the definition of the WG naming must be inline with the charter >>> that will be defined ... (draft today) >>>=20 >>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>=20 >>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>=20 >>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>=20 >>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>=20 >>> If the WG is focused on SR, let's use a name in relation with SR. >>>=20 >>> Feedback ? >>>=20 >>>=20 >>> Stephane >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane = DTF/DERX >>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione >>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>> Summary of STATUS BOF and the next steps >>>=20 >>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>=20 >>> Peter >>>=20 >>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS = BOF >>>> and the next steps >>>>=20 >>>> Hi, >>>>=20 >>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>=20 >>>> Yours Irrespectively, >>>>=20 >>>> John >>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of Mark Townsley >>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>> To: Victor Kuarsingh >>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>>=20 >>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> I would also favour "Segment Routing WG" as well. >>>>>>=20 >>>>>> I note this since attempting to come up with an all encompassing >>>>>> acronym will be difficult and Segment Routing is generic enough = to >>>>>> associate to multiple functions. >>>>>=20 >>>>> Then we can just use "segroute" for the short name. WGs do not = have >>>>> to have acronyms, but they do need to have an 8-char limited short >>>>> name for the various automated tools not to break. >>>>>=20 >>>>> - Mark >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Victor K >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> +1 for Segment Routing WG >>>>>>>=20 >>>>>>> Roberta >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Segment Routing WG >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>> to find a better working name for the WG, since it has been = put >>>>>>>>> to me a number of times that STATUS is going to be confusing = in >>>>>>>>> text and a difficult search term. >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = ____________________________________________________________________ >>>> __ ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> = _____________________________________________________________________ >>> ____________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 >=20 >=20 From rraszuk@gmail.com Fri Sep 6 09:52:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC5711E82B1 for ; Fri, 6 Sep 2013 09:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTyG3-UkpkDa for ; Fri, 6 Sep 2013 09:52:41 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7A411E81A7 for ; Fri, 6 Sep 2013 09:52:40 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z5so3096342lbh.37 for ; Fri, 06 Sep 2013 09:52:39 -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=rUUc+dW6sy7A0fOQ1biG8cROPlQKv2SWgStxf/FC7W4=; b=pMCmdnpxjN0rKo9in6xQJIlBGGrXd79jsvTgERKoq2mSvimGFUt+UV9XMvvezJ6byV LwG2e+WAQrQF3kh3KzTD1bgdM3cjcEp310x4mBAgrkw05rAotl9I92LSpob2YPUPo+Jt h+2KBrp5BFNaaC4oP2pSw4tgQ59Vi6qcNvWIN4GendD7ylLf16+S2NVT6XaxMtjoobq6 W2THJAsLZaZRS/EOFbcZOPE4EX24s/89CCNQFUUmmjOcEYXOByMBebp9Mq2QrPkBT/5Z 7jwqSLqkJSEZFaPEq7w9ph7KRpyi+n46XQ2tbFF9cMV+Czzi07K7bdDVpbLv2Wpnfdre 8XhQ== MIME-Version: 1.0 X-Received: by 10.152.37.103 with SMTP id x7mr2984049laj.28.1378486359544; Fri, 06 Sep 2013 09:52:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.37.135 with HTTP; Fri, 6 Sep 2013 09:52:39 -0700 (PDT) In-Reply-To: <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> Date: Fri, 6 Sep 2013 18:52:39 +0200 X-Google-Sender-Auth: WxIOIIYqzds_H6i78cKW1eMQyIk Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: text/plain; charset=ISO-8859-1 Cc: stephane.litkowski@orange.com, "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:52:41 -0000 Hi, > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. So this effectively says that if there is a way in today's protocols to accomplish use-cases - no matter how operationally and deployment difficult this turns out to be in practice - there would be no gaps - hence no hope for the operators to see any new protocol extensions work to proceed. I find those two sentences quoted above not acceptable. Of course let's also observe that there is going to be clearly difficulty - which we have already seen at the "BOF" - to evaluate proposed use-cases and consider them as valid or not valid. Who will be the judge and the jury - chairs ? ADs ? IESG ? Rough consensus ? For the record .. I support charter sent to the list by Stefano Previdi. Best, R. From Ruediger.Geib@telekom.de Sun Sep 8 23:53:20 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685A721E8146 for ; Sun, 8 Sep 2013 23:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoHZdp5ZtyYE for ; Sun, 8 Sep 2013 23:53:09 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id AA5CD21E8144 for ; Sun, 8 Sep 2013 23:53:05 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 09 Sep 2013 08:53:03 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 Sep 2013 08:53:01 +0200 From: To: Date: Mon, 9 Sep 2013 08:53:00 +0200 Thread-Topic: Proposed Charter Thread-Index: AQHOqs0Qohy0k4/BVkG4wal+W7vNDZm8/KTA Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Proposed Charter X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:53:20 -0000 Stefano, I support the draft agenda as suggested below. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: status-bounces@ietf.org [mailto:status-bounces@ietf.org] Im Auftrag vo= n Stefano Previdi (sprevidi) Gesendet: Freitag, 6. September 2013 08:48 An: status@ietf.org Cc: Clarence Filsfils (cfilsfil) Betreff: [Status] Proposed Charter All, here follows a proposal for the charter. Thanks. s. ------------------------------------------------------------------- Name: SEGROUTE (or SR, or whatever else) Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a controlled= set of instructions, called segments while maintaining per-explicit path s= tate only at the ingress node. The instruction associated to a segment can be derived based on arbitrary m= echanisms which may include: . Shortest path routing or explicit/source routing paradigms . Intra and in= ter domain path computation . Network or application layer . Network virtua= lization . Centralized or distributed path computation . Unicast or Multica= st schemes . Others. The SEGROUTE architecture will support: . Tunnel and non-tunnel based paradigms . Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane should be independent (agnostic) to the data-planes. The WG will work on the definition of the architecture and protocol extensi= ons. No new protocol specification is expected within this WG. No MPLS data-plane changes are expected either. Instead the standardization work should consist in extensions in well estab= lished protocols (ISIS, OSPF, BGP, PCEP, ...). It is expected that the SEGROUTE WG will help in the orchestration of proto= col extensions specification with the existing IETF Working Groups (ISIS, O= SPF, IDR, PCE, 6MAN, MPLS, ...). Documents --------- The WG will produce the following documents: . Problem Statement . Requirements . Use Cases . Architecture . Interoperability Report The protocol extensions and data-plane instantiations will be handled in th= eir respective WGs. _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From jeff.tantsura@ericsson.com Sun Sep 8 23:56:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDD21F9DFC for ; Sun, 8 Sep 2013 23:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhsqwLwfT3Th for ; Sun, 8 Sep 2013 23:56:36 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7461C21E8144 for ; Sun, 8 Sep 2013 23:56:36 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-0e-522d71202b0d Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 95.6E.09414.0217D225; Mon, 9 Sep 2013 08:56:33 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 9 Sep 2013 02:56:32 -0400 From: Jeff Tantsura To: "sprevidi@cisco.com" Thread-Topic: [Status] Proposed Charter Thread-Index: AQHOqs0Qohy0k4/BVkG4wal+W7vNDZm8/KTA///O4QA= Date: Mon, 9 Sep 2013 06:56:32 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483991A2F9@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <50B576F78A17DB4CB2A6A542713A6FCA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPn65ioW6Qwa7NLBbrdz9isnjdfJHJ gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYf7OFtWCqeMWXVU+YGhg3CncxcnJICJhI /NmzlhnCFpO4cG89G4gtJHCUUeLcDKMuRi4gexmjxIFTZ9hBEmwCBhL/vx1nAbFFBHQl/k3u AGtmFlCXWNjaxARiCwuoSVzc188IUaMuceD3DVYI20riwPTdYHEWARWJZ+0nwHp5Bbwlzs1a DbaYUyBaYunNv2C7GIEO+n5qDRPEfHGJW0/mM0EcKiCxZM95qKNFJV4+/gc2X1RAT6LtGMSd EgLKEkue7GeB6NWTuDF1ChuEbS1x4coJqJu1JZYtfA11g6DEyZlPWCYwis9Csm4WkvZZSNpn IWmfhaR9ASPrKkaO0uLUstx0I4NNjMCoOibBpruDcc9Ly0OM0hwsSuK8q/TOBAoJpCeWpGan phakFsUXleakFh9iZOLglGpgnDBJkNdjXp597NM1lectMnRytObeLBSpVIruvaZQ+O2e4uGt iro3XsSlzWdx6RP32Kf984jz79SXn3nWtdT8cPe6bCHzzcNXeaqgyxbe33/aa7+uZFe3i+nf c+7Wvr+28xd8/3f+0rd3747nnF5WPrUt8MUv26klb6bNdzlYKn5on8H1mefrbiqxFGckGmox FxUnAgBnKrKdeAIAAA== Cc: "status@ietf.org" Subject: Re: [Status] Proposed Charter X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:56:49 -0000 Hi, Support, looks rather reasonable. Cheers, Jeff >-----Urspr=FCngliche Nachricht----- >Von: status-bounces@ietf.org [mailto:status-bounces@ietf.org] Im Auftrag >von Stefano Previdi (sprevidi) >Gesendet: Freitag, 6. September 2013 08:48 >An: status@ietf.org >Cc: Clarence Filsfils (cfilsfil) >Betreff: [Status] Proposed Charter > >All, > >here follows a proposal for the charter. > >Thanks. >s. > > >------------------------------------------------------------------- >Name: SEGROUTE (or SR, or whatever else) >Charter: > >Introduction >------------ >The following use cases: >. Path computation based on awareness of utilization or performance > data, within both centralized and distributed environments, . >Multi-topology (dual planes, disjoint trees), . Simplification and >reduction of signaling components (scaling), . Combined application and >network layer path specification, . Full coverage LFA-FRR, . Topology >Aware OAM, . etc. > >have triggered work on the definition of new architecture and protocol >extensions allowing to combine well known shortest path based routing >paradigms with source/explicit routing methods. Some of these extensions >have been implemented already. > >Objective >--------- >Define an architecture where a node can steer a packet through a >controlled set of instructions, called segments while maintaining >per-explicit path state only at the ingress node. > >The instruction associated to a segment can be derived based on arbitrary >mechanisms which may include: > >. Shortest path routing or explicit/source routing paradigms . Intra and >inter domain path computation . Network or application layer . Network >virtualization . Centralized or distributed path computation . Unicast or >Multicast schemes . Others. > >The SEGROUTE architecture will support: > >. Tunnel and non-tunnel based paradigms >. Multiple data-planes: MPLS and IPv6. The SEGROUTE control plane > should be independent (agnostic) to the data-planes. > >The WG will work on the definition of the architecture and protocol >extensions. No new protocol specification is expected within this WG. >No MPLS data-plane changes are expected either. > >Instead the standardization work should consist in extensions in well >established protocols (ISIS, OSPF, BGP, PCEP, ...). > >It is expected that the SEGROUTE WG will help in the orchestration of >protocol extensions specification with the existing IETF Working Groups >(ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). > >Documents >--------- >The WG will produce the following documents: >. Problem Statement >. Requirements >. Use Cases >. Architecture >. Interoperability Report > >The protocol extensions and data-plane instantiations will be handled in >their respective WGs. >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status From Ruediger.Geib@telekom.de Mon Sep 9 00:09:07 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4801121E814B for ; Mon, 9 Sep 2013 00:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsSMo1kfnkaU for ; Mon, 9 Sep 2013 00:08:56 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1A21E814C for ; Mon, 9 Sep 2013 00:08:45 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 09 Sep 2013 09:08:43 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 Sep 2013 09:08:43 +0200 From: To: Date: Mon, 9 Sep 2013 09:08:42 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6rHhXJFnjKgfUDSRa6tWcOE10IbQCC1Umw Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> In-Reply-To: <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 07:09:07 -0000 Hannes, I'm worried about the proposal below, which seem to miss the most important= points of SR (I call it that): - SR allows to reduce complexity by getting rid of RSVP TE and LDP. Apart f= rom OAM I don't think SR is supposed to fill gaps. - I don't fully understand why the SR work must address inter domain relati= ons, if it is supposed to be primarily chartered with intra domain control plane = issues. - My take is, that intra-domain MPLS forwarding will remain as is initially= with SR. Your last bullet point means todays MPLS is out of scope, as no forwardin= g definitions need to be changed? - We agreed not work on protocols within the SR WG. Why has that been chang= ed? Regards, Ruediger --------------- The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between domains (interdomain). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Protocol work may be carried out in this working group or in other working = groups responsible for the protocols, in coordination with this WG, and in = agreement with the WG chairs and responsible ADs. However, no protocol work will be adopted by a working group to address the= identified use-cases until the requirements document motivating the protoc= ol work has been sent to the IESG for publication as an RFC. --- /hannes On Sep 4, 2013, at 10:02 AM, wrote: > Hannes, > > In case, we are using only directed forwarding (adjacency segment), > could we still talk about tunneling ? (it's a very very small tunnel) Mor= eover talking about "stacking" is really dataplane agnostic (MPLS) ... > > In the proposed segment routing architectural concepts, segments are at t= he same "level" and pointer moves on the segment list, then the MPLS instan= tiation is performing this using stacking ... > > IMHO, if we use "Stacked Tunnels", we already talk about a chosen solutio= n and it's closing the door to something else ... > > Finally, about the "routing" word, routing is essentially a "forward" act= ion which may limit the scope of what we can do by using a segment list. Ac= tions associated with a segment could be something else than forwarding. > > Do we want in the charter to limit the scope to routing actions ? > > I have no solution today to propose for the naming, but I completely agre= e with Loa, to first focus on working on the charter, and define a clear sc= ope of the work and then the name will be easier to find. > > Regarding your charter proposal : > > -------- > > - They form a connected network > [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). > > - They can forward traffic through the shortest paths or paths other than= the shortest (the latter called explicitly routed paths, or explicit paths= ) > [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. > > - They share a common trust model. In this model, any router within the E= RD can specify an explicit path between itself and any other router in the = ERD. It can then send any packet that passes through it through any path th= at it has specified. > [SLI] Security considerations may have to be addressed in the > charter , especially for the interAS case (trust yes, but not sure > access to everything may not be good) > > Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. > [SLI] Yes, but any router in the middle may be able to change the end to = end explicit path. > > > > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > > [SLI] Agree, I would add : > - defining the architecture framework > - analysing the security considerisations > > > --------- > > > Here would be my proposal to extend yours : > > A domain contains a set of routers with the followi= ng characteristics: > > - They form a connected network > - They can forward traffic through any path within the network using > shortest path, non shortest path or explicit path > - They may provide other types of services than forwarding and they can e= nforce service actions in the path. > - They share a common trust model. In this model, any router within the d= omain can specify a path between itself and any other router in the domain.= It may then send any packet that passes through it through any path that i= t has specified and that is conform to the security rules. Downstream route= rs within the ERD forward the packet as specified by the router at the head= -end of the path. > > The working group is chartered for the following ordered list of w= ork items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with the = security considerations. The architecture framework and security considerat= ions must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will ide= ntify gaps between currently available technologies and use-case requiremen= ts. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. However, no protocol wo= rk will be adopted by a working group to address the ERD use-cases until th= e requirements document motivating the protocol work has been sent to the I= ESG for publication as an RFC. > > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la > part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa > Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS > BOF and the next steps > > good point - what about this charter proposal ? > > --- > > Stacked Tunnels for Explicit Routing (STER) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A explicit routing domain (ERD) contains a set of routers with the follow= ing characteristics: > > - They form a connected network > - They can forward traffic through the shortest paths or paths other > than the shortest (the latter called explicitly routed paths, or > explicit paths) > - They share a common trust model. In this model, any router within the E= RD can specify an explicit path between itself and any other router in the = ERD. It can then send any packet that passes through it through any path th= at it has specified. Downstream routers within the ERD forward the packet a= s specified by the router at the head-end of the path. > > The STER working group is chartered for the following ordered list of wor= k items: > > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. However, no protocol wo= rk will be adopted by a working group to address the ERD use-cases until th= e requirements document motivating the protocol work has been sent to the I= ESG for publication as an RFC. > > --- > > > > /hannes > > > On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: > >> Folks, >> >> Excuse me if I'm slightly out of the loop, but so far I have not seen >> a charter proposal, if there is one please point me to it. >> >> It seems a bit odd to put the cart (what the wg should do) before the >> horse (wg name). If we drill down the the charter first the wg name >> might be easier to figure out. >> >> /Loa >> >> PS >> OK I understand that the horse and cart analogy limps a bit :). >> >> >> >> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>> " If the WG charter is limited to source routing, how will we handle th= e "non source routing" use cases of segment routing ? In another working gr= oup ? So we will go back to the WG synchronization issue that has been rais= ed for this technology ..." >>> >>> That's why I suggested SRV2. We are revisiting source routing with new = concepts. More generic number/action behavior. >>> >>> Peter >>> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of stephane.litkowski@orange.com >>> Sent: Tuesday, September 03, 2013 10:43 AM >>> To: AshwoodsmithPeter >>> Cc: status@ietf.org >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> There was a misunderstanding in my small comment :) so I will explain m= ore : >>> >>> In segment routing, you have more than basic source routing : segment r= outing is just associate a segment number to an action and then combine seg= ment as you want, yes you can do source routing, but you also can do more. >>> >>> In the other hand, I completely agree with your statement that >>> source routing is generic and dataplane agnostic, as segment routing is= ... >>> (segment routing is not a new dataplane ...) >>> >>> Now the definition of the WG naming must be inline with the charter >>> that will be defined ... (draft today) >>> >>> Based on the already existing consensus (at least for MPLS dataplane) b= rought up during Berlin STATUS BOF meeting, segment routing sounds to be a = good target candidate. >>> >>> So now, do we want to do more in the WG charter than just make progress= ing segment routing architecture and uses cases document and ensure coordin= ation for the standardization of this technology ? >>> >>> Do we want to standardize other technologies in this WG ? I don't think= so, based on Stewart's conclusion email from the BOF :"A new WG focused so= lely on SR therefore needs to be create" >>> >>> If the WG charter is limited to source routing, how will we handle the = "non source routing" use cases of segment routing ? In another working grou= p ? So we will go back to the WG synchronization issue that has been raised= for this technology ... >>> >>> If the WG is focused on SR, let's use a name in relation with SR. >>> >>> Feedback ? >>> >>> >>> Stephane >>> >>> >>> -----Message d'origine----- >>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>> [Status] Summary of STATUS BOF and the next steps >>> >>> The term "source routing" has been around for a very long time and is d= ata path agnostic. Its also the term used in the literature etc so my prefe= rence is to stick with this existing well known and data path agnostic term= . >>> >>> Peter >>> >>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>> >>>> Hi, >>>> >>>> "Source routing" is just a subcase of segment routing ... as it is for= IP routing ... >>>> >>>> Stephane >>>> >>>> >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mar= k >>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>> BOF and the next steps >>>> >>>> Hi, >>>> >>>> What is this 'segment routing' silliness? The correct term is 'source= routing'. >>>> >>>> Yours Irrespectively, >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of Mark Townsley >>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>> To: Victor Kuarsingh >>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>> (stbryant) >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> >>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I would also favour "Segment Routing WG" as well. >>>>>> >>>>>> I note this since attempting to come up with an all encompassing >>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>> to associate to multiple functions. >>>>> >>>>> Then we can just use "segroute" for the short name. WGs do not >>>>> have to have acronyms, but they do need to have an 8-char limited >>>>> short name for the various automated tools not to break. >>>>> >>>>> - Mark >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Victor K >>>>>> >>>>>> >>>>>> >>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> +1 for Segment Routing WG >>>>>>> >>>>>>> Roberta >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Segment Routing WG >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>> confusing in text and a difficult search term. >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> ___________________________________________________________________ >>>> _ __ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> ____________________________________________________________________ >>> _ ____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From rjs@rob.sh Mon Sep 9 01:25:22 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F4A11E818F for ; Mon, 9 Sep 2013 01:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPV2vuVcuzKY for ; Mon, 9 Sep 2013 01:25:11 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 2612A21F89A6 for ; Mon, 9 Sep 2013 01:25:00 -0700 (PDT) Received: from [130.208.20.117] (helo=epf-2013-h0117.rhnet.is) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VIwlO-0003wK-HY; Mon, 09 Sep 2013 09:24:02 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> Date: Mon, 9 Sep 2013 08:24:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1508) Cc: stephane.litkowski@orange.com, "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 08:25:22 -0000 Hannes, In-line as rjs>. On 6 Sep 2013, at 16:27, Hannes Gredler wrote: > hi stephane, >=20 > here is a revised draft charter as per your comments. >=20 > --- >=20 > domain contains a set of routers with the following > characteristics: >=20 > - They form a connected network > - They can forward traffic through any path within the network using > shortest path, or any other (e.g., an explicit) path > - They share a common trust model. In this model, any router within > the domain can specify a path between itself and any other router > in the domain. It may then send any packet that passes through it > through any path that it has specified and that is conform to the > security rules. Downstream routers along the path within the = > domain forward the packet as specified by the router at the head-end > of the path. >=20 > The working group is chartered for the following ordered > list of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains (inter = domain). rjs> It seems a little odd to me that we would identify that there are = inter-domain issues to solve when there is no suggested use case that = seemed to relate to this as a requirement. Any extensions of the = technology developed within the WG to be inter-domain can be for future = study. > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 > Protocol work may be carried out in this working group or in other > working groups responsible for the protocols, in coordination with > this WG, and in agreement with the WG chairs and responsible ADs. > However, no protocol work will be adopted by a working group to > address the identified use-cases until the requirements document > motivating the protocol work has been sent to the IESG for > publication as an RFC. rjs> I do not see the need to place this restriction on the WG -- often = we can shape and re-discuss requirements as we work through the details = of solutions, based on the practicality of realising particular = functions, or the complexity of supporting particular capabilities. = Since we do not have this restriction in other WGs, I'm not clear that = we need it defined here? Kind regards, r. >=20 > --- >=20 > /hannes >=20 > On Sep 4, 2013, at 10:02 AM, = wrote: >=20 >> Hannes, >>=20 >> In case, we are using only directed forwarding (adjacency segment), = could we still talk about tunneling ? (it's a very very small tunnel) >> Moreover talking about "stacking" is really dataplane agnostic (MPLS) = ... >>=20 >> In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >>=20 >> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>=20 >> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment = list. Actions associated with a segment could be something else than = forwarding. >>=20 >> Do we want in the charter to limit the scope to routing actions ? >>=20 >> I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>=20 >> Regarding your charter proposal : >>=20 >> -------- >>=20 >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>=20 >> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>=20 >> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >> [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) >>=20 >> Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. >> [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >>=20 >>=20 >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>=20 >> [SLI] Agree, I would add : >> - defining the architecture framework >> - analysing the security considerisations >>=20 >>=20 >> --------- >>=20 >>=20 >> Here would be my proposal to extend yours : >>=20 >> A domain contains a set of routers with the = following characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through any path within the network using = shortest path, non shortest path or explicit path >> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>=20 >> The working group is chartered for the following ordered list = of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case = requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>=20 >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la = part de Hannes Gredler >> Envoy=E9 : mardi 3 septembre 2013 18:31 >> =C0 : Loa Andersson >> Cc : status@ietf.org >> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>=20 >> good point - what about this charter proposal ? >>=20 >> --- >>=20 >> Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>=20 >> The STER working group is chartered for the following ordered list of = work items: >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>=20 >> --- >>=20 >> >>=20 >> /hannes >>=20 >>=20 >> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>=20 >>> Folks, >>>=20 >>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>> a charter proposal, if there is one please point me to it. >>>=20 >>> It seems a bit odd to put the cart (what the wg should do) before = the >>> horse (wg name). If we drill down the the charter first the wg name >>> might be easier to figure out. >>>=20 >>> /Loa >>>=20 >>> PS >>> OK I understand that the horse and cart analogy limps a bit :). >>>=20 >>>=20 >>>=20 >>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>=20 >>>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>>=20 >>>> Peter >>>>=20 >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of stephane.litkowski@orange.com >>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>> To: AshwoodsmithPeter >>>> Cc: status@ietf.org >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>>=20 >>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>=20 >>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>=20 >>>> In the other hand, I completely agree with your statement that = source >>>> routing is generic and dataplane agnostic, as segment routing is = ... >>>> (segment routing is not a new dataplane ...) >>>>=20 >>>> Now the definition of the WG naming must be inline with the charter >>>> that will be defined ... (draft today) >>>>=20 >>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>=20 >>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>=20 >>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>=20 >>>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>>=20 >>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>=20 >>>> Feedback ? >>>>=20 >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane = DTF/DERX >>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta = Maglione >>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>>> Summary of STATUS BOF and the next steps >>>>=20 >>>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>>=20 >>>> Peter >>>>=20 >>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS = BOF >>>>> and the next steps >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>=20 >>>>> Yours Irrespectively, >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of Mark Townsley >>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>> To: Victor Kuarsingh >>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>=20 >>>>>>> I note this since attempting to come up with an all encompassing >>>>>>> acronym will be difficult and Segment Routing is generic enough = to >>>>>>> associate to multiple functions. >>>>>>=20 >>>>>> Then we can just use "segroute" for the short name. WGs do not = have >>>>>> to have acronyms, but they do need to have an 8-char limited = short >>>>>> name for the various automated tools not to break. >>>>>>=20 >>>>>> - Mark >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Victor K >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> +1 for Segment Routing WG >>>>>>>>=20 >>>>>>>> Roberta >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>> to find a better working name for the WG, since it has been = put >>>>>>>>>> to me a number of times that STATUS is going to be confusing = in >>>>>>>>>> text and a difficult search term. >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = ____________________________________________________________________ >>>>> __ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = _____________________________________________________________________ >>>> ____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From hannes@juniper.net Mon Sep 9 01:59:18 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDB021F9D7C for ; Mon, 9 Sep 2013 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujRU6dfY8WOk for ; Mon, 9 Sep 2013 01:59:05 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2E29B11E81A6 for ; Mon, 9 Sep 2013 01:58:56 -0700 (PDT) Received: from mail36-db9-R.bigfish.com (10.174.16.251) by DB9EHSOBE019.bigfish.com (10.174.14.82) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 08:58:55 +0000 Received: from mail36-db9 (localhost [127.0.0.1]) by mail36-db9-R.bigfish.com (Postfix) with ESMTP id 728972E007C; Mon, 9 Sep 2013 08:58:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -71 X-BigFish: VPS-71(z551biz62a3I98dI9371Ic89bh936eI542Iec9I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail36-db9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail36-db9 (localhost.localdomain [127.0.0.1]) by mail36-db9 (MessageSwitch) id 1378717132195994_31046; Mon, 9 Sep 2013 08:58:52 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.242]) by mail36-db9.bigfish.com (Postfix) with ESMTP id 2A8F42A0048; Mon, 9 Sep 2013 08:58:52 +0000 (UTC) Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 08:58:50 +0000 Received: from [192.168.1.198] (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 08:58:47 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: Date: Mon, 9 Sep 2013 10:56:56 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 08:59:18 -0000 ruediger, On Sep 9, 2013, at 9:08 AM, wrote: > I'm worried about the proposal below, which seem to miss the most = important points of SR (I call it that): >=20 > - SR allows to reduce complexity by getting rid of RSVP TE and LDP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that seem to be a gross misunderstanding on your side; 'reducing complexity' means *obsoleting* technology A with technology B. the issue is that introduction of SR does *neither* obsolete LDP *nor* = RSVP, simply because SR is not a 100% replacement of LDP and RSVP = functionalities. SR lacks functionality in areas of: 1. LSP bandwidth reservation 2. LSP preemption 3. p2mp path construction 4. PW signaling 5. FRR node-protection adding the IGP as a label distribution protocol to the stack of = protocols allows the network to do tunnel discovery and with that capability we = can arguably fix a couple of interesting problems, but does this single capability make it a panacea for networking ? > - I don't fully understand why the SR work must address inter domain = relations, if > it is supposed to be primarily chartered with intra domain control = plane issues. > - My take is, that intra-domain MPLS forwarding will remain as is = initially with SR. there are SPs which operate multi-AS domains and the implications to connect those ASes using label-stacking technology should be worked = on. > - Your last bullet point means todays MPLS is out of scope, as no = forwarding > definitions need to be changed? not sure if we can get away with zero changes - issues that we need to = talk about are: 1. MPLS source labels 2. Entropy label implications of label stacking 3. Hardware capabilites (Maxpushlabels) and management > - We agreed not work on protocols within the SR WG. Why has that been = changed? there might be a a need to work on protocols which do not fit into = existing WGs. HTH, /hannes > --------------- >=20 > The working group is chartered for the following ordered = list of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains = (interdomain). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. > However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >=20 > --- >=20 > /hannes >=20 > On Sep 4, 2013, at 10:02 AM, = wrote: >=20 >> Hannes, >>=20 >> In case, we are using only directed forwarding (adjacency segment), >> could we still talk about tunneling ? (it's a very very small tunnel) = Moreover talking about "stacking" is really dataplane agnostic (MPLS) = ... >>=20 >> In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >>=20 >> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>=20 >> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment = list. Actions associated with a segment could be something else than = forwarding. >>=20 >> Do we want in the charter to limit the scope to routing actions ? >>=20 >> I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>=20 >> Regarding your charter proposal : >>=20 >> -------- >>=20 >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>=20 >> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>=20 >> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >> [SLI] Security considerations may have to be addressed in the >> charter , especially for the interAS case (trust yes, but not sure >> access to everything may not be good) >>=20 >> Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. >> [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >>=20 >>=20 >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>=20 >> [SLI] Agree, I would add : >> - defining the architecture framework >> - analysing the security considerisations >>=20 >>=20 >> --------- >>=20 >>=20 >> Here would be my proposal to extend yours : >>=20 >> A domain contains a set of routers with the = following characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, non shortest path or explicit path >> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>=20 >> The working group is chartered for the following ordered list = of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case = requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>=20 >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : = Loa >> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >> BOF and the next steps >>=20 >> good point - what about this charter proposal ? >>=20 >> --- >>=20 >> Stacked Tunnels for Explicit Routing (STER) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through the shortest paths or paths other >> than the shortest (the latter called explicitly routed paths, or >> explicit paths) >> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>=20 >> The STER working group is chartered for the following ordered list of = work items: >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>=20 >> --- >>=20 >> >>=20 >> /hannes >>=20 >>=20 >> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>=20 >>> Folks, >>>=20 >>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>> a charter proposal, if there is one please point me to it. >>>=20 >>> It seems a bit odd to put the cart (what the wg should do) before = the >>> horse (wg name). If we drill down the the charter first the wg name >>> might be easier to figure out. >>>=20 >>> /Loa >>>=20 >>> PS >>> OK I understand that the horse and cart analogy limps a bit :). >>>=20 >>>=20 >>>=20 >>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>=20 >>>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>>=20 >>>> Peter >>>>=20 >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of stephane.litkowski@orange.com >>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>> To: AshwoodsmithPeter >>>> Cc: status@ietf.org >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>>=20 >>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>=20 >>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>=20 >>>> In the other hand, I completely agree with your statement that >>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>> (segment routing is not a new dataplane ...) >>>>=20 >>>> Now the definition of the WG naming must be inline with the charter >>>> that will be defined ... (draft today) >>>>=20 >>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>=20 >>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>=20 >>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>=20 >>>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>>=20 >>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>=20 >>>> Feedback ? >>>>=20 >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; = Roberta >>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>> [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>>=20 >>>> Peter >>>>=20 >>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>> BOF and the next steps >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>=20 >>>>> Yours Irrespectively, >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of Mark Townsley >>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>> To: Victor Kuarsingh >>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>> (stbryant) >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>=20 >>>>>>> I note this since attempting to come up with an all encompassing >>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>> to associate to multiple functions. >>>>>>=20 >>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>> short name for the various automated tools not to break. >>>>>>=20 >>>>>> - Mark >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Victor K >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> +1 for Segment Routing WG >>>>>>>>=20 >>>>>>>> Roberta >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = ___________________________________________________________________ >>>>> _ __ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = ____________________________________________________________________ >>>> _ ____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 From hannes@juniper.net Mon Sep 9 02:23:43 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BB211E81B5 for ; Mon, 9 Sep 2013 02:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ0aBU6nsZPa for ; Mon, 9 Sep 2013 02:23:31 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 72AD911E81B3 for ; Mon, 9 Sep 2013 02:23:29 -0700 (PDT) Received: from mail157-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 09:23:20 +0000 Received: from mail157-co1 (localhost [127.0.0.1]) by mail157-co1-R.bigfish.com (Postfix) with ESMTP id CC458C4013F; Mon, 9 Sep 2013 09:23:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -75 X-BigFish: VPS-75(z551biz62a3I98dI9371Ic89bh936eI542I1432I15caKJ72dMdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail157-co1: domain of juniper.net designates 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=hannes@juniper.net; helo=BN1PRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail157-co1 (localhost.localdomain [127.0.0.1]) by mail157-co1 (MessageSwitch) id 1378718598273458_23993; Mon, 9 Sep 2013 09:23:18 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.244]) by mail157-co1.bigfish.com (Postfix) with ESMTP id 3E6D2C004D; Mon, 9 Sep 2013 09:23:18 +0000 (UTC) Received: from BN1PRD0512HT002.namprd05.prod.outlook.com (132.245.2.21) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 09:23:17 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.193.35) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 09:23:12 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: Date: Mon, 9 Sep 2013 11:23:01 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <994A8BDB-8C3A-4FCF-A7CD-E61E5A7377F9@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> To: Rob Shakir X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: stephane.litkowski@orange.com, "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 09:23:44 -0000 hi rob, On Sep 9, 2013, at 10:24 AM, Rob Shakir wrote: > Hannes, >=20 > In-line as rjs>. >=20 > On 6 Sep 2013, at 16:27, Hannes Gredler wrote: >=20 >> hi stephane, >>=20 >> here is a revised draft charter as per your comments. >>=20 >> --- >>=20 >> domain contains a set of routers with the following >> characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, or any other (e.g., an explicit) path >> - They share a common trust model. In this model, any router within >> the domain can specify a path between itself and any other router >> in the domain. It may then send any packet that passes through it >> through any path that it has specified and that is conform to the >> security rules. Downstream routers along the path within the = >> domain forward the packet as specified by the router at the head-end >> of the path. >>=20 >> The working group is chartered for the following ordered >> list of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains (inter = domain). >=20 > rjs> It seems a little odd to me that we would identify that there are = inter-domain issues to solve when there is no suggested use case that = seemed to relate to this as a requirement. Any extensions of the = technology developed within the WG to be inter-domain can be for future = study. HG> here is an example of an inter domain use-case: = http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#= section-3.2 >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other >> working groups responsible for the protocols, in coordination with >> this WG, and in agreement with the WG chairs and responsible ADs. >> However, no protocol work will be adopted by a working group to >> address the identified use-cases until the requirements document >> motivating the protocol work has been sent to the IESG for >> publication as an RFC. >=20 > rjs> I do not see the need to place this restriction on the WG -- = often we can shape and re-discuss requirements as we work through the = details of solutions, based on the practicality of realising particular = functions, or the complexity of supporting particular capabilities. = Since we do not have this restriction in other WGs, I'm not clear that = we need it defined here? >=20 HG> you are right that hacking protocols without use-cases and = requirements has been done in the past in other WGs, but its not a good habit. and since the = snake-oil dealers are already overselling this technology and what it can do, we = should stay very disciplined. >> On Sep 4, 2013, at 10:02 AM, = wrote: >>=20 >>> Hannes, >>>=20 >>> In case, we are using only directed forwarding (adjacency segment), = could we still talk about tunneling ? (it's a very very small tunnel) >>> Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>=20 >>> In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >>>=20 >>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>=20 >>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>=20 >>> Do we want in the charter to limit the scope to routing actions ? >>>=20 >>> I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>>=20 >>> Regarding your charter proposal : >>>=20 >>> -------- >>>=20 >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>=20 >>> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >>> [SLI] There is something else between SPT and Explicit path, you = can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>=20 >>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >>> [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) >>>=20 >>> Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. >>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>=20 >>>=20 >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>=20 >>> [SLI] Agree, I would add : >>> - defining the architecture framework >>> - analysing the security considerisations >>>=20 >>>=20 >>> --------- >>>=20 >>>=20 >>> Here would be my proposal to extend yours : >>>=20 >>> A domain contains a set of routers with the = following characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through any path within the network using = shortest path, non shortest path or explicit path >>> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >>> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>>=20 >>> The working group is chartered for the following ordered list = of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). >>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>=20 >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la = part de Hannes Gredler >>> Envoy=E9 : mardi 3 septembre 2013 18:31 >>> =C0 : Loa Andersson >>> Cc : status@ietf.org >>> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>>=20 >>> good point - what about this charter proposal ? >>>=20 >>> --- >>>=20 >>> Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>>=20 >>> The STER working group is chartered for the following ordered list = of work items: >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>=20 >>> --- >>>=20 >>> >>>=20 >>> /hannes >>>=20 >>>=20 >>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>> a charter proposal, if there is one please point me to it. >>>>=20 >>>> It seems a bit odd to put the cart (what the wg should do) before = the >>>> horse (wg name). If we drill down the the charter first the wg name >>>> might be easier to figure out. >>>>=20 >>>> /Loa >>>>=20 >>>> PS >>>> OK I understand that the horse and cart analogy limps a bit :). >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>=20 >>>>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of stephane.litkowski@orange.com >>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>> To: AshwoodsmithPeter >>>>> Cc: status@ietf.org >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>>=20 >>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>=20 >>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>=20 >>>>> In the other hand, I completely agree with your statement that = source >>>>> routing is generic and dataplane agnostic, as segment routing is = ... >>>>> (segment routing is not a new dataplane ...) >>>>>=20 >>>>> Now the definition of the WG naming must be inline with the = charter >>>>> that will be defined ... (draft today) >>>>>=20 >>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>=20 >>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>=20 >>>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>>=20 >>>>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>>>=20 >>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>=20 >>>>> Feedback ? >>>>>=20 >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane = DTF/DERX >>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta = Maglione >>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); >>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>>>> Summary of STATUS BOF and the next steps >>>>>=20 >>>>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : Mark >>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS = BOF >>>>>> and the next steps >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>=20 >>>>>> Yours Irrespectively, >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>> Behalf Of Mark Townsley >>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>> To: Victor Kuarsingh >>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>=20 >>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>> acronym will be difficult and Segment Routing is generic enough = to >>>>>>>> associate to multiple functions. >>>>>>>=20 >>>>>>> Then we can just use "segroute" for the short name. WGs do not = have >>>>>>> to have acronyms, but they do need to have an 8-char limited = short >>>>>>> name for the various automated tools not to break. >>>>>>>=20 >>>>>>> - Mark >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Victor K >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> +1 for Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Roberta >>>>>>>>>=20 >>>>>>>>> Sent from my iPad >>>>>>>>>=20 >>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>>> to find a better working name for the WG, since it has been = put >>>>>>>>>>> to me a number of times that STATUS is going to be confusing = in >>>>>>>>>>> text and a difficult search term. >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> = ____________________________________________________________________ >>>>>> __ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = _____________________________________________________________________ >>>>> ____________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>>> exploites ou copies sans autorisation. Si vous avez recu ce = message >>>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 >=20 From Ruediger.Geib@telekom.de Mon Sep 9 02:27:19 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43ED21F8CE0 for ; Mon, 9 Sep 2013 02:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjWcXRTL7mbE for ; Mon, 9 Sep 2013 02:27:08 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9F04221E80B6 for ; Mon, 9 Sep 2013 02:26:22 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 09 Sep 2013 11:26:09 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 Sep 2013 11:26:09 +0200 From: To: Date: Mon, 9 Sep 2013 11:26:10 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6tOtxhbzYpizNaQSerZi8RtwSovwAAWhWA Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> In-Reply-To: <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 09:27:19 -0000 Hannes, sorry, but why should the ISPs interested in standardising SR worry about i= ssues ocurring for ISPs who are not interested in migrating to SR? I don't = think, SR should look for replacements, SR should work on simplifications. = That's what the charter should express. I'm not interested in working withi= n a "LDP and RSVP-TE replacement WG". Sorry if my first mail was overstated= to that regard ("...get rid of"). DT so far does not utilise RSVP TE in parts of the backbone, but is interes= ted in SR based features offering similar routing properties. Bandwidth res= ervation and preemption are completely irrelevant to me. If there are issues, we will (dis)cover them while we work on the technolog= y. But discovering issues and analysing them shouldn't be core part of a ch= arter - the features to be developed should be. Serious issues on non core-aspects identified in advance may be removed fro= m the charter (I'd regard that as usual). Regards, Ruediger -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net] Sent: Monday, September 09, 2013 10:57 AM To: Geib, R=FCdiger Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps ruediger, On Sep 9, 2013, at 9:08 AM, wrote: > I'm worried about the proposal below, which seem to miss the most importa= nt points of SR (I call it that): > > - SR allows to reduce complexity by getting rid of RSVP TE and LDP. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that seem to be a gross misunderstanding on your side; 'reducing complexity' means *obsoleting* technology A with technology B. the issue is that introduction of SR does *neither* obsolete LDP *nor* RSVP= , simply because SR is not a 100% replacement of LDP and RSVP functionalities= . SR lacks functionality in areas of: 1. LSP bandwidth reservation 2. LSP preemption 3. p2mp path construction 4. PW signaling 5. FRR node-protection adding the IGP as a label distribution protocol to the stack of protocols allows the network to do tunnel discovery and with that capability we can a= rguably fix a couple of interesting problems, but does this single capability make it a panacea for networking ? > - I don't fully understand why the SR work must address inter domain rela= tions, if > it is supposed to be primarily chartered with intra domain control plane= issues. > - My take is, that intra-domain MPLS forwarding will remain as is initial= ly with SR. there are SPs which operate multi-AS domains and the implications to connect those ASes using label-stacking technology should be worked on. > - Your last bullet point means todays MPLS is out of scope, as no forward= ing > definitions need to be changed? not sure if we can get away with zero changes - issues that we need to talk= about are: 1. MPLS source labels 2. Entropy label implications of label stacking 3. Hardware capabilites (Maxpushlabels) and management > - We agreed not work on protocols within the SR WG. Why has that been cha= nged? there might be a a need to work on protocols which do not fit into existing= WGs. HTH, /hannes > --------------- > > The working group is chartered for the following ordered list = of work items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. > However, no protocol work will be adopted by a working group to address t= he identified use-cases until the requirements document motivating the prot= ocol work has been sent to the IESG for publication as an RFC. > > --- > > /hannes > > On Sep 4, 2013, at 10:02 AM, wrote: > >> Hannes, >> >> In case, we are using only directed forwarding (adjacency segment), >> could we still talk about tunneling ? (it's a very very small tunnel) Mo= reover talking about "stacking" is really dataplane agnostic (MPLS) ... >> >> In the proposed segment routing architectural concepts, segments are at = the same "level" and pointer moves on the segment list, then the MPLS insta= ntiation is performing this using stacking ... >> >> IMHO, if we use "Stacked Tunnels", we already talk about a chosen soluti= on and it's closing the door to something else ... >> >> Finally, about the "routing" word, routing is essentially a "forward" ac= tion which may limit the scope of what we can do by using a segment list. A= ctions associated with a segment could be something else than forwarding. >> >> Do we want in the charter to limit the scope to routing actions ? >> >> I have no solution today to propose for the naming, but I completely agr= ee with Loa, to first focus on working on the charter, and define a clear s= cope of the work and then the name will be easier to find. >> >> Regarding your charter proposal : >> >> -------- >> >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >> >> - They can forward traffic through the shortest paths or paths other tha= n the shortest (the latter called explicitly routed paths, or explicit path= s) >> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >> >> - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in the= ERD. It can then send any packet that passes through it through any path t= hat it has specified. >> [SLI] Security considerations may have to be addressed in the >> charter , especially for the interAS case (trust yes, but not sure >> access to everything may not be good) >> >> Downstream routers within the ERD forward the packet as specified by the= router at the head-end of the path. >> [SLI] Yes, but any router in the middle may be able to change the end to= end explicit path. >> >> >> >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between current= ly available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> >> [SLI] Agree, I would add : >> - defining the architecture framework >> - analysing the security considerisations >> >> >> --------- >> >> >> Here would be my proposal to extend yours : >> >> A domain contains a set of routers with the follow= ing characteristics: >> >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, non shortest path or explicit path >> - They may provide other types of services than forwarding and they can = enforce service actions in the path. >> - They share a common trust model. In this model, any router within the = domain can specify a path between itself and any other router in the domain= . It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream rout= ers within the ERD forward the packet as specified by the router at the hea= d-end of the path. >> >> The working group is chartered for the following ordered list of = work items: >> >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with the= security considerations. The architecture framework and security considera= tions must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will id= entify gaps between currently available technologies and use-case requireme= nts. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. However, no protocol w= ork will be adopted by a working group to address the ERD use-cases until t= he requirements document motivating the protocol work has been sent to the = IESG for publication as an RFC. >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa >> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >> BOF and the next steps >> >> good point - what about this charter proposal ? >> >> --- >> >> Stacked Tunnels for Explicit Routing (STER) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> A explicit routing domain (ERD) contains a set of routers with the follo= wing characteristics: >> >> - They form a connected network >> - They can forward traffic through the shortest paths or paths other >> than the shortest (the latter called explicitly routed paths, or >> explicit paths) >> - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in the= ERD. It can then send any packet that passes through it through any path t= hat it has specified. Downstream routers within the ERD forward the packet = as specified by the router at the head-end of the path. >> >> The STER working group is chartered for the following ordered list of wo= rk items: >> >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between current= ly available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. However, no protocol w= ork will be adopted by a working group to address the ERD use-cases until t= he requirements document motivating the protocol work has been sent to the = IESG for publication as an RFC. >> >> --- >> >> >> >> /hannes >> >> >> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >> >>> Folks, >>> >>> Excuse me if I'm slightly out of the loop, but so far I have not seen >>> a charter proposal, if there is one please point me to it. >>> >>> It seems a bit odd to put the cart (what the wg should do) before the >>> horse (wg name). If we drill down the the charter first the wg name >>> might be easier to figure out. >>> >>> /Loa >>> >>> PS >>> OK I understand that the horse and cart analogy limps a bit :). >>> >>> >>> >>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>> " If the WG charter is limited to source routing, how will we handle t= he "non source routing" use cases of segment routing ? In another working g= roup ? So we will go back to the WG synchronization issue that has been rai= sed for this technology ..." >>>> >>>> That's why I suggested SRV2. We are revisiting source routing with new= concepts. More generic number/action behavior. >>>> >>>> Peter >>>> >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of stephane.litkowski@orange.com >>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>> To: AshwoodsmithPeter >>>> Cc: status@ietf.org >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>> >>>> >>>> There was a misunderstanding in my small comment :) so I will explain = more : >>>> >>>> In segment routing, you have more than basic source routing : segment = routing is just associate a segment number to an action and then combine se= gment as you want, yes you can do source routing, but you also can do more. >>>> >>>> In the other hand, I completely agree with your statement that >>>> source routing is generic and dataplane agnostic, as segment routing i= s ... >>>> (segment routing is not a new dataplane ...) >>>> >>>> Now the definition of the WG naming must be inline with the charter >>>> that will be defined ... (draft today) >>>> >>>> Based on the already existing consensus (at least for MPLS dataplane) = brought up during Berlin STATUS BOF meeting, segment routing sounds to be a= good target candidate. >>>> >>>> So now, do we want to do more in the WG charter than just make progres= sing segment routing architecture and uses cases document and ensure coordi= nation for the standardization of this technology ? >>>> >>>> Do we want to standardize other technologies in this WG ? I don't thin= k so, based on Stewart's conclusion email from the BOF :"A new WG focused s= olely on SR therefore needs to be create" >>>> >>>> If the WG charter is limited to source routing, how will we handle the= "non source routing" use cases of segment routing ? In another working gro= up ? So we will go back to the WG synchronization issue that has been raise= d for this technology ... >>>> >>>> If the WG is focused on SR, let's use a name in relation with SR. >>>> >>>> Feedback ? >>>> >>>> >>>> Stephane >>>> >>>> >>>> -----Message d'origine----- >>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>> [Status] Summary of STATUS BOF and the next steps >>>> >>>> The term "source routing" has been around for a very long time and is = data path agnostic. Its also the term used in the literature etc so my pref= erence is to stick with this existing well known and data path agnostic ter= m. >>>> >>>> Peter >>>> >>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>> >>>>> Hi, >>>>> >>>>> "Source routing" is just a subcase of segment routing ... as it is fo= r IP routing ... >>>>> >>>>> Stephane >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Ma= rk >>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>> BOF and the next steps >>>>> >>>>> Hi, >>>>> >>>>> What is this 'segment routing' silliness? The correct term is 'sourc= e routing'. >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of Mark Townsley >>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>> To: Victor Kuarsingh >>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>> (stbryant) >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>> >>>>>> >>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>> >>>>>>> I note this since attempting to come up with an all encompassing >>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>> to associate to multiple functions. >>>>>> >>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>> short name for the various automated tools not to break. >>>>>> >>>>>> - Mark >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Victor K >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> +1 for Segment Routing WG >>>>>>>> >>>>>>>> Roberta >>>>>>>> >>>>>>>> Sent from my iPad >>>>>>>> >>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Segment Routing WG >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> ___________________________________________________________________ >>>>> _ __ ___________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> ____________________________________________________________________ >>>> _ ____________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >>> >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> >> > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > From rjs@rob.sh Mon Sep 9 02:40:48 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A8221E8130 for ; Mon, 9 Sep 2013 02:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVR-lv1qo+ch for ; Mon, 9 Sep 2013 02:40:40 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD421F918C for ; Mon, 9 Sep 2013 02:40:37 -0700 (PDT) Received: from [2a00:c88:f:ebf:69fb:e0ba:ba6f:2637] (helo=epf-2013-conference.rhnet.is) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VIxwb-0004H5-04; Mon, 09 Sep 2013 10:39:41 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <994A8BDB-8C3A-4FCF-A7CD-E61E5A7377F9@juniper.net> Date: Mon, 9 Sep 2013 09:40:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <65FBDC1D-3249-40F7-AC16-475424515DC4@rob.sh> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <994A8BDB-8C3A-4FCF-A7CD-E61E5A7377F9@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1508) Cc: stephane.litkowski@orange.com, "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 09:40:48 -0000 Hi Hannes, On 9 Sep 2013, at 09:23, Hannes Gredler wrote: > hi rob, >=20 >>> <..snip..> >>=20 >> rjs> It seems a little odd to me that we would identify that there = are inter-domain issues to solve when there is no suggested use case = that seemed to relate to this as a requirement. Any extensions of the = technology developed within the WG to be inter-domain can be for future = study. >=20 > HG> here is an example of an inter domain use-case: > = http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#= section-3.2 rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} = allocate the label and advertise it within the AS1 IGP. There is no = labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs = program a pop operation. I read inter-domain as segments being used to = influence routing within two separate autonomous systems which are not = within the same trust domain. >> rjs> I do not see the need to place this restriction on the WG -- = often we can shape and re-discuss requirements as we work through the = details of solutions, based on the practicality of realising particular = functions, or the complexity of supporting particular capabilities. = Since we do not have this restriction in other WGs, I'm not clear that = we need it defined here? >>=20 >=20 > HG> you are right that hacking protocols without use-cases and = requirements has been > done in the past in other WGs, but its not a good habit. and since the = snake-oil > dealers are already overselling this technology and what it can do, we = should > stay very disciplined. rjs> I can't comment on the assertions of others, and do not wish to do = so. In my view, there are pragmatic use cases (defined by a number of = operators) which are gaps that we cannot meet today. Let's identify = those, and work on those, and allow further uses of the technology going = forward if there is a convincing case to do so. rjs> I don't disagree that we should stay disciplined, but I do not see = the requirement to mandate that a document must be sent to the IESG to = be published *before* solutions drafts are adopted. Having a requirement = that the adopted solutions drafts should address the use cases within = previously adopted documents puts the same focus safe-guard in as far as = I can see. Kind regards, r. >=20 >>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>=20 >>>> Hannes, >>>>=20 >>>> In case, we are using only directed forwarding (adjacency segment), = could we still talk about tunneling ? (it's a very very small tunnel) >>>> Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>>=20 >>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the = MPLS instantiation is performing this using stacking ... >>>>=20 >>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>>=20 >>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>=20 >>>> Do we want in the charter to limit the scope to routing actions ? >>>>=20 >>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>=20 >>>> Regarding your charter proposal : >>>>=20 >>>> -------- >>>>=20 >>>> - They form a connected network >>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>=20 >>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>> [SLI] There is something else between SPT and Explicit path, you = can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>>=20 >>>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >>>> [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) >>>>=20 >>>> Downstream routers within the ERD forward the packet as specified = by the router at the head-end of the path. >>>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>>=20 >>>>=20 >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>=20 >>>> [SLI] Agree, I would add : >>>> - defining the architecture framework >>>> - analysing the security considerisations >>>>=20 >>>>=20 >>>> --------- >>>>=20 >>>>=20 >>>> Here would be my proposal to extend yours : >>>>=20 >>>> A domain contains a set of routers with the = following characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through any path within the network = using shortest path, non shortest path or explicit path >>>> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >>>> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>>>=20 >>>> The working group is chartered for the following ordered = list of work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>=20 >>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>=20 >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la = part de Hannes Gredler >>>> Envoy=E9 : mardi 3 septembre 2013 18:31 >>>> =C0 : Loa Andersson >>>> Cc : status@ietf.org >>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>> good point - what about this charter proposal ? >>>>=20 >>>> --- >>>>=20 >>>> Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>>>=20 >>>> The STER working group is chartered for the following ordered list = of work items: >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>=20 >>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>=20 >>>> --- >>>>=20 >>>> >>>>=20 >>>> /hannes >>>>=20 >>>>=20 >>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>>> a charter proposal, if there is one please point me to it. >>>>>=20 >>>>> It seems a bit odd to put the cart (what the wg should do) before = the >>>>> horse (wg name). If we drill down the the charter first the wg = name >>>>> might be easier to figure out. >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> PS >>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>=20 >>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of stephane.litkowski@orange.com >>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>> To: AshwoodsmithPeter >>>>>> Cc: status@ietf.org >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>=20 >>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>=20 >>>>>> In the other hand, I completely agree with your statement that = source >>>>>> routing is generic and dataplane agnostic, as segment routing is = ... >>>>>> (segment routing is not a new dataplane ...) >>>>>>=20 >>>>>> Now the definition of the WG naming must be inline with the = charter >>>>>> that will be defined ... (draft today) >>>>>>=20 >>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>=20 >>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>>=20 >>>>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>>>=20 >>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>=20 >>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>>=20 >>>>>> Feedback ? >>>>>>=20 >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane = DTF/DERX >>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta = Maglione >>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana = (aretana); >>>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>>>>> Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc = so my preference is to stick with this existing well known and data path = agnostic term. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : Mark >>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; = status@ietf.org; >>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS = BOF >>>>>>> and the next steps >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>>=20 >>>>>>> Yours Irrespectively, >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>>> Behalf Of Mark Townsley >>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>> To: Victor Kuarsingh >>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>=20 >>>>>>>>> All, >>>>>>>>>=20 >>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>=20 >>>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>>> acronym will be difficult and Segment Routing is generic = enough to >>>>>>>>> associate to multiple functions. >>>>>>>>=20 >>>>>>>> Then we can just use "segroute" for the short name. WGs do not = have >>>>>>>> to have acronyms, but they do need to have an 8-char limited = short >>>>>>>> name for the various automated tools not to break. >>>>>>>>=20 >>>>>>>> - Mark >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Victor K >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Roberta >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPad >>>>>>>>>>=20 >>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Segment Routing WG >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>=20 >>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>>>> to find a better working name for the WG, since it has been = put >>>>>>>>>>>> to me a number of times that STATUS is going to be = confusing in >>>>>>>>>>>> text and a difficult search term. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> = ____________________________________________________________________ >>>>>>> __ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> = _____________________________________________________________________ >>>>>> ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>>>> exploites ou copies sans autorisation. Si vous avez recu ce = message >>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = __________________________________________________________________________= _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>> they should not be distributed, used or copied without = authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From hannes@juniper.net Mon Sep 9 03:07:05 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6321E815F for ; Mon, 9 Sep 2013 03:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWtqQhImtocR for ; Mon, 9 Sep 2013 03:06:41 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 81A5621E815E for ; Mon, 9 Sep 2013 03:06:33 -0700 (PDT) Received: from mail36-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE033.bigfish.com (10.174.14.96) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 10:06:31 +0000 Received: from mail36-db9 (localhost [127.0.0.1]) by mail36-db9-R.bigfish.com (Postfix) with ESMTP id 590302E012F; Mon, 9 Sep 2013 10:06:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(z551biz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail36-db9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail36-db9 (localhost.localdomain [127.0.0.1]) by mail36-db9 (MessageSwitch) id 1378721188821129_27319; Mon, 9 Sep 2013 10:06:28 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.230]) by mail36-db9.bigfish.com (Postfix) with ESMTP id C3FE92A0048; Mon, 9 Sep 2013 10:06:28 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 10:06:27 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 10:06:20 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Mon, 9 Sep 2013 12:06:08 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <911B28D4-A6CA-45AF-9134-2B38CFA9DC38@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 10:07:05 -0000 robert, i am glad that you haven't discovered the hidden anagrams in the=20 proposed draft agenda, yet - it would have revealed a larger conspiracy and their satanic plan for removing free speech and freedom on the = internet. apart from that i simply fail to see the need for developing redundant technology within IETF. /hannes On Sep 6, 2013, at 6:52 PM, Robert Raszuk wrote: >=20 >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >>=20 >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >=20 >=20 > So this effectively says that if there is a way in today's protocols > to accomplish use-cases - no matter how operationally and deployment > difficult this turns out to be in practice - there would be no gaps - > hence no hope for the operators to see any new protocol extensions" > work to proceed. >=20 > I find those two sentences quoted above not acceptable. >=20 > Of course let's also observe that there is going to be clearly > difficulty - which we have already seen at the "BOF" - to evaluate > proposed use-cases and consider them as valid or not valid. Who will > be the judge and the jury - chairs ? ADs ? IESG ? Rough consensus ? [ =85 ]= From hannes@juniper.net Mon Sep 9 03:51:36 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DE621E8170 for ; Mon, 9 Sep 2013 03:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.068 X-Spam-Level: X-Spam-Status: No, score=-4.068 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej+TqINiyQnk for ; Mon, 9 Sep 2013 03:51:14 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2651521E816D for ; Mon, 9 Sep 2013 03:50:13 -0700 (PDT) Received: from mail202-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 10:49:56 +0000 Received: from mail202-co9 (localhost [127.0.0.1]) by mail202-co9-R.bigfish.com (Postfix) with ESMTP id 6F5B0C008E; Mon, 9 Sep 2013 10:49:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -71 X-BigFish: VPS-71(z551biz62a3I98dI9371Ic89bh936eI542Iec9I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail202-co9: domain of juniper.net designates 157.56.238.5 as permitted sender) client-ip=157.56.238.5; envelope-from=hannes@juniper.net; helo=BY2PRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail202-co9 (localhost.localdomain [127.0.0.1]) by mail202-co9 (MessageSwitch) id 1378723793909659_28610; Mon, 9 Sep 2013 10:49:53 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.231]) by mail202-co9.bigfish.com (Postfix) with ESMTP id C53E8B40050; Mon, 9 Sep 2013 10:49:53 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 10:49:53 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.243.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 10:49:19 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Mon, 9 Sep 2013 12:49:00 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 10:51:36 -0000 ruediger, On Sep 9, 2013, at 11:26 AM, wrote: > sorry, but why should the ISPs interested in standardising SR worry = about issues ocurring for ISPs who are not interested in migrating to = SR? I don't think, SR should look for replacements, SR should work on = simplifications. That's what the charter should express. I'm not = interested in working within a "LDP and RSVP-TE replacement WG". Sorry = if my first mail was overstated to that regard ("...get rid of"). if its not 'obsoleting' something, then it is by definition an = 'extension' of something. in other words the complexity of the 'something' will be going up and = never down. i haven't yet identified the code to be deleted, if SR is going to be a = success ;-) > DT so far does not utilise RSVP TE in parts of the backbone, but is = interested in SR based features offering similar routing properties. = Bandwidth reservation and preemption are completely irrelevant to me. that is fine and yet for the industry as a whole doing distributed bandwidth reservation *is* a relevant functionality. > If there are issues, we will (dis)cover them while we work on the = technology. But discovering issues and analysing them shouldn't be core = part of a charter - the features to be developed should be. i'd rather do the analysis and planning exercise before commencing work. > [ =85 ] /hannes > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, September 09, 2013 10:57 AM > To: Geib, R=FCdiger > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > ruediger, >=20 > On Sep 9, 2013, at 9:08 AM, wrote: >> I'm worried about the proposal below, which seem to miss the most = important points of SR (I call it that): >>=20 >> - SR allows to reduce complexity by getting rid of RSVP TE and LDP. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > that seem to be a gross misunderstanding on your side; >=20 > 'reducing complexity' means *obsoleting* technology A with technology = B. >=20 > the issue is that introduction of SR does *neither* obsolete LDP *nor* = RSVP, > simply because SR is not a 100% replacement of LDP and RSVP = functionalities. >=20 > SR lacks functionality in areas of: >=20 > 1. LSP bandwidth reservation > 2. LSP preemption > 3. p2mp path construction > 4. PW signaling > 5. FRR node-protection >=20 > adding the IGP as a label distribution protocol to the stack of = protocols > allows the network to do tunnel discovery and with that capability we = can arguably fix > a couple of interesting problems, but does this single capability > make it a panacea for networking ? >=20 >> - I don't fully understand why the SR work must address inter domain = relations, if >> it is supposed to be primarily chartered with intra domain control = plane issues. >> - My take is, that intra-domain MPLS forwarding will remain as is = initially with SR. >=20 > there are SPs which operate multi-AS domains and the implications > to connect those ASes using label-stacking technology should be worked = on. >=20 >> - Your last bullet point means todays MPLS is out of scope, as no = forwarding >> definitions need to be changed? >=20 > not sure if we can get away with zero changes - issues that we need to = talk about are: >=20 > 1. MPLS source labels > 2. Entropy label implications of label stacking > 3. Hardware capabilites (Maxpushlabels) and management >=20 >> - We agreed not work on protocols within the SR WG. Why has that been = changed? >=20 > there might be a a need to work on protocols which do not fit into = existing WGs. >=20 > HTH, >=20 > /hannes >=20 >> --------------- >>=20 >> The working group is chartered for the following ordered = list of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains = (interdomain). >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. >> However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >>=20 >> --- >>=20 >> /hannes >>=20 >> On Sep 4, 2013, at 10:02 AM, = wrote: >>=20 >>> Hannes, >>>=20 >>> In case, we are using only directed forwarding (adjacency segment), >>> could we still talk about tunneling ? (it's a very very small = tunnel) Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>=20 >>> In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >>>=20 >>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>=20 >>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>=20 >>> Do we want in the charter to limit the scope to routing actions ? >>>=20 >>> I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>>=20 >>> Regarding your charter proposal : >>>=20 >>> -------- >>>=20 >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>=20 >>> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >>> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>=20 >>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >>> [SLI] Security considerations may have to be addressed in the >>> charter , especially for the interAS case (trust yes, but not sure >>> access to everything may not be good) >>>=20 >>> Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. >>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>=20 >>>=20 >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>=20 >>> [SLI] Agree, I would add : >>> - defining the architecture framework >>> - analysing the security considerisations >>>=20 >>>=20 >>> --------- >>>=20 >>>=20 >>> Here would be my proposal to extend yours : >>>=20 >>> A domain contains a set of routers with the = following characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through any path within the network using >>> shortest path, non shortest path or explicit path >>> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >>> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>>=20 >>> The working group is chartered for the following ordered list = of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). >>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>=20 >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : = Loa >>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of = STATUS >>> BOF and the next steps >>>=20 >>> good point - what about this charter proposal ? >>>=20 >>> --- >>>=20 >>> Stacked Tunnels for Explicit Routing (STER) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through the shortest paths or paths other >>> than the shortest (the latter called explicitly routed paths, or >>> explicit paths) >>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>>=20 >>> The STER working group is chartered for the following ordered list = of work items: >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>=20 >>> --- >>>=20 >>> >>>=20 >>> /hannes >>>=20 >>>=20 >>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>> a charter proposal, if there is one please point me to it. >>>>=20 >>>> It seems a bit odd to put the cart (what the wg should do) before = the >>>> horse (wg name). If we drill down the the charter first the wg name >>>> might be easier to figure out. >>>>=20 >>>> /Loa >>>>=20 >>>> PS >>>> OK I understand that the horse and cart analogy limps a bit :). >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>=20 >>>>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of stephane.litkowski@orange.com >>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>> To: AshwoodsmithPeter >>>>> Cc: status@ietf.org >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>>=20 >>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>=20 >>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>=20 >>>>> In the other hand, I completely agree with your statement that >>>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>>> (segment routing is not a new dataplane ...) >>>>>=20 >>>>> Now the definition of the WG naming must be inline with the = charter >>>>> that will be defined ... (draft today) >>>>>=20 >>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>=20 >>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>=20 >>>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>>=20 >>>>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>>>=20 >>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>=20 >>>>> Feedback ? >>>>>=20 >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; = Roberta >>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>> [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : Mark >>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>> BOF and the next steps >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>=20 >>>>>> Yours Irrespectively, >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>> Behalf Of Mark Townsley >>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>> To: Victor Kuarsingh >>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>> (stbryant) >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>=20 >>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>>> to associate to multiple functions. >>>>>>>=20 >>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>> have to have acronyms, but they do need to have an 8-char = limited >>>>>>> short name for the various automated tools not to break. >>>>>>>=20 >>>>>>> - Mark >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Victor K >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> +1 for Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Roberta >>>>>>>>>=20 >>>>>>>>> Sent from my iPad >>>>>>>>>=20 >>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> = ___________________________________________________________________ >>>>>> _ __ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = ____________________________________________________________________ >>>>> _ ____________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >=20 >=20 >=20 >=20 From rraszuk@gmail.com Mon Sep 9 04:04:16 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566D821E8182 for ; Mon, 9 Sep 2013 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9LTclgXbmly for ; Mon, 9 Sep 2013 04:04:08 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 879EC21E815D for ; Mon, 9 Sep 2013 04:03:57 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id p5so4770015lbi.36 for ; Mon, 09 Sep 2013 04:03:56 -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=AfM07HmUqMIktrbc9tggGq2bd9h/oV3pukje/A+tc9Q=; b=QsEDCO/97fK9oWfua995V7pMXNDTjeShqNHk+5S16XNKssL40puxnHVSxgYR1hyAR4 jVZIekFoTd1FOjN2d0Y1RwBko3gMQErQhiq84yCznF+8CdWpAKb6CxyNZXjU+ruHdugQ zwTGLDL5a1Lf1+1mGg2CTcKbczH5EjOoQIjObCtkf35siA0WGupMuz1FDdpfUV5CtFA2 j57Wu7OZwcYFmhdKWxeddxY6yWIQRzcWPw8U13EDGKbu16XmTikpMjH+SpDrwjpyLRcs t1+jOR3WyneUOpBNAlSof9UHI0WvgB81glpGmkFcTof8d2z1P77lHjT76wKqQ3B6gx5Y Ce4A== MIME-Version: 1.0 X-Received: by 10.152.87.143 with SMTP id ay15mr16121829lab.2.1378724636477; Mon, 09 Sep 2013 04:03:56 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.37.135 with HTTP; Mon, 9 Sep 2013 04:03:55 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 13:03:55 +0200 X-Google-Sender-Auth: 8c1unLpd5neavE4nNnjOIlR5v4c Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: text/plain; charset=ISO-8859-1 Cc: Ruediger.Geib@telekom.de, "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:04:16 -0000 > i haven't yet identified the code to be deleted, if SR is going to be a success ;-) How about LDP as starter ? Which of the below are solved by LDP ? Which LDP functionality will not be covered by SR ? >> 1. LSP bandwidth reservation >> 2. LSP preemption >> 3. p2mp path construction Note that those are all done today in the control plane. Therefor it seems pretty trivial to accomplish all of those with SR using number of PCE or PCE like controllers rather then use RSVP-TE for explicit path signalling. >> 5. FRR node-protection As you know computing LFA sort of addresses this topic pretty well. Moreover SR may complete topologies where today LFA may not be possible in 100% of coverage. >> a couple of interesting problems, but does this single capability >> make it a panacea for networking ? Some folks think that MPLS is a panacea for networking .. SR with IP encap can prove it is not ;) That's the beauty of it. > apart from that i simply fail to see the need for developing redundant > technology within IETF. Why not since the redundant technology has much better scaling and operational properties. It simplifies control plane and that alone should be sufficient reason. Cheers, R. From hannes@juniper.net Mon Sep 9 04:05:56 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0E621E815D for ; Mon, 9 Sep 2013 04:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt5uXZUkxDEO for ; Mon, 9 Sep 2013 04:05:24 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id F3B8311E81A8 for ; Mon, 9 Sep 2013 04:05:16 -0700 (PDT) Received: from mail23-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE028.bigfish.com (10.243.66.91) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 11:05:16 +0000 Received: from mail23-co1 (localhost [127.0.0.1]) by mail23-co1-R.bigfish.com (Postfix) with ESMTP id 2504CC0020B; Mon, 9 Sep 2013 11:05:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -75 X-BigFish: VPS-75(z551biz62a3I98dI9371Ic89bh936eI542I1432I15caKJ72dMdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail23-co1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail23-co1 (localhost.localdomain [127.0.0.1]) by mail23-co1 (MessageSwitch) id 1378724713954207_32685; Mon, 9 Sep 2013 11:05:13 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.230]) by mail23-co1.bigfish.com (Postfix) with ESMTP id E556B800040; Mon, 9 Sep 2013 11:05:13 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 11:05:11 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 11:05:06 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: <65FBDC1D-3249-40F7-AC16-475424515DC4@rob.sh> Date: Mon, 9 Sep 2013 13:04:58 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <994A8BDB-8C3A-4FCF-A7CD-E61E5A7377F9@juniper.net> <65FBDC1D-3249-40F7-AC16-475424515DC4@rob.sh> To: Rob Shakir X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:05:56 -0000 hi rob, On Sep 9, 2013, at 11:40 AM, Rob Shakir wrote: > Hi Hannes, >=20 > On 9 Sep 2013, at 09:23, Hannes Gredler wrote: >=20 >> hi rob, >>=20 >>>> <..snip..> >>>=20 >>> rjs> It seems a little odd to me that we would identify that there = are inter-domain issues to solve when there is no suggested use case = that seemed to relate to this as a requirement. Any extensions of the = technology developed within the WG to be inter-domain can be for future = study. >>=20 >> HG> here is an example of an inter domain use-case: >> = http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05#= section-3.2 > rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} = allocate the label and advertise it within the AS1 IGP. There is no = labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs = program a pop operation. I read inter-domain as segments being used to = influence routing within two separate autonomous systems which are not = within the same trust domain. HG> it is =85 now think for a moment if there would be one AS in-between the egress link - as per the illustration below: the ingress router is in AS1 and it wants to control the exit link of = AS2-->AS3. AS1--AS2--AS3 >>> rjs> I do not see the need to place this restriction on the WG -- = often we can shape and re-discuss requirements as we work through the = details of solutions, based on the practicality of realising particular = functions, or the complexity of supporting particular capabilities. = Since we do not have this restriction in other WGs, I'm not clear that = we need it defined here? >>>=20 >>=20 >> HG> you are right that hacking protocols without use-cases and = requirements has been >> done in the past in other WGs, but its not a good habit. and since = the snake-oil >> dealers are already overselling this technology and what it can do, = we should >> stay very disciplined. >=20 > rjs> I can't comment on the assertions of others, and do not wish to = do so. In my view, there are pragmatic use cases (defined by a number of = operators) which are gaps that we cannot meet today. Let's identify = those, and work on those, and allow further uses of the technology going = forward if there is a convincing case to do so. HG> agreed. > rjs> I don't disagree that we should stay disciplined, but I do not = see the requirement to mandate that a document must be sent to the IESG = to be published *before* solutions drafts are adopted. Having a = requirement that the adopted solutions drafts should address the use = cases within previously adopted documents puts the same focus safe-guard = in as far as I can see. HG> that seems reasonable to me as well - do you have a suggestion for = the actual text ? >>>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>>=20 >>>>> Hannes, >>>>>=20 >>>>> In case, we are using only directed forwarding (adjacency = segment), could we still talk about tunneling ? (it's a very very small = tunnel) >>>>> Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>>>=20 >>>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the = MPLS instantiation is performing this using stacking ... >>>>>=20 >>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>>>=20 >>>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>>=20 >>>>> Do we want in the charter to limit the scope to routing actions ? >>>>>=20 >>>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>>=20 >>>>> Regarding your charter proposal : >>>>>=20 >>>>> -------- >>>>>=20 >>>>> - They form a connected network >>>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>>=20 >>>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>>> [SLI] There is something else between SPT and Explicit path, you = can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>>>=20 >>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. >>>>> [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) >>>>>=20 >>>>> Downstream routers within the ERD forward the packet as specified = by the router at the head-end of the path. >>>>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>=20 >>>>> [SLI] Agree, I would add : >>>>> - defining the architecture framework >>>>> - analysing the security considerisations >>>>>=20 >>>>>=20 >>>>> --------- >>>>>=20 >>>>>=20 >>>>> Here would be my proposal to extend yours : >>>>>=20 >>>>> A domain contains a set of routers with the = following characteristics: >>>>>=20 >>>>> - They form a connected network >>>>> - They can forward traffic through any path within the network = using shortest path, non shortest path or explicit path >>>>> - They may provide other types of services than forwarding and = they can enforce service actions in the path. >>>>> - They share a common trust model. In this model, any router = within the domain can specify a path between itself and any other router = in the domain. It may then send any packet that passes through it = through any path that it has specified and that is conform to the = security rules. Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>=20 >>>>> The working group is chartered for the following ordered = list of work items: >>>>>=20 >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la part de Hannes Gredler >>>>> Envoy=E9 : mardi 3 septembre 2013 18:31 >>>>> =C0 : Loa Andersson >>>>> Cc : status@ietf.org >>>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>> good point - what about this charter proposal ? >>>>>=20 >>>>> --- >>>>>=20 >>>>> Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>>>=20 >>>>> - They form a connected network >>>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. Downstream routers within the = ERD forward the packet as specified by the router at the head-end of the = path. >>>>>=20 >>>>> The STER working group is chartered for the following ordered list = of work items: >>>>>=20 >>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>>=20 >>>>> --- >>>>>=20 >>>>> >>>>>=20 >>>>> /hannes >>>>>=20 >>>>>=20 >>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>>>> a charter proposal, if there is one please point me to it. >>>>>>=20 >>>>>> It seems a bit odd to put the cart (what the wg should do) before = the >>>>>> horse (wg name). If we drill down the the charter first the wg = name >>>>>> might be easier to figure out. >>>>>>=20 >>>>>> /Loa >>>>>>=20 >>>>>> PS >>>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>>=20 >>>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>>=20 >>>>>>> Peter >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>> Behalf Of stephane.litkowski@orange.com >>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>> To: AshwoodsmithPeter >>>>>>> Cc: status@ietf.org >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>>=20 >>>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>>=20 >>>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>>=20 >>>>>>> In the other hand, I completely agree with your statement that = source >>>>>>> routing is generic and dataplane agnostic, as segment routing is = ... >>>>>>> (segment routing is not a new dataplane ...) >>>>>>>=20 >>>>>>> Now the definition of the WG naming must be inline with the = charter >>>>>>> that will be defined ... (draft today) >>>>>>>=20 >>>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>>=20 >>>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>>>=20 >>>>>>> Do we want to standardize other technologies in this WG ? I = don't think so, based on Stewart's conclusion email from the BOF :"A new = WG focused solely on SR therefore needs to be create" >>>>>>>=20 >>>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>>=20 >>>>>>> If the WG is focused on SR, let's use a name in relation with = SR. >>>>>>>=20 >>>>>>> Feedback ? >>>>>>>=20 >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane = DTF/DERX >>>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta = Maglione >>>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana = (aretana); >>>>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>>>>>> Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc = so my preference is to stick with this existing well known and data path = agnostic term. >>>>>>>=20 >>>>>>> Peter >>>>>>>=20 >>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>>>=20 >>>>>>>> Stephane >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] = De la >>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : Mark >>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; = status@ietf.org; >>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of = STATUS BOF >>>>>>>> and the next steps >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>>>=20 >>>>>>>> Yours Irrespectively, >>>>>>>>=20 >>>>>>>> John >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>>>> Behalf Of Mark Townsley >>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>> To: Victor Kuarsingh >>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>=20 >>>>>>>>>> All, >>>>>>>>>>=20 >>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>=20 >>>>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>>>> acronym will be difficult and Segment Routing is generic = enough to >>>>>>>>>> associate to multiple functions. >>>>>>>>>=20 >>>>>>>>> Then we can just use "segroute" for the short name. WGs do not = have >>>>>>>>> to have acronyms, but they do need to have an 8-char limited = short >>>>>>>>> name for the various automated tools not to break. >>>>>>>>>=20 >>>>>>>>> - Mark >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Victor K >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>=20 >>>>>>>>>>> Roberta >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPad >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>=20 >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> The second task, which hopefully should be relatively = easy, is >>>>>>>>>>>>> to find a better working name for the WG, since it has = been put >>>>>>>>>>>>> to me a number of times that STATUS is going to be = confusing in >>>>>>>>>>>>> text and a difficult search term. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> = ____________________________________________________________________ >>>>>>>> __ ___________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et = le detruire ainsi que les pieces jointes. Les messages electroniques = etant susceptibles d'alteration, Orange decline toute responsabilite si = ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> = _____________________________________________________________________ >>>>>>> ____________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>>>>> exploites ou copies sans autorisation. Si vous avez recu ce = message >>>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>> Senior MPLS Expert loa@pi.nu >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>>> they should not be distributed, used or copied without = authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 From Ruediger.Geib@telekom.de Mon Sep 9 05:00:31 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9321E8192 for ; Mon, 9 Sep 2013 05:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlD3CL9MQn2Q for ; Mon, 9 Sep 2013 05:00:20 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8617021E8197 for ; Mon, 9 Sep 2013 04:58:08 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 09 Sep 2013 13:58:06 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 Sep 2013 13:58:06 +0200 From: To: Date: Mon, 9 Sep 2013 13:58:04 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6tSlqW5VUA2FiAQ1COwLOoFY5OKwABSVkA Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:00:32 -0000 Hannes, please try to bring the discussion forward. - I do not support deployment of RSVP TE in the DT backbone because this adds undesired complexity. Why should I worry about obsoleting RSVP-TE or aim on that, if I think the cost of deploying RSVP-TE is too high as compared to the gain? - I'm happy extending ISIS, if this allows for an additional range of TE (and OAM) functions. That's what I'll gain if SR is a success= . I think my point is clear. I don't want to keep you from discussing RSVP-TE= related topics with others and I fully respect if others have RSVP-TE rela= ted issues. In addition, SR will allow for very scaleable LSP monitoring OAM. Trying to= to this with todays features is very complex (we've done that). SR can simplify LSP monitoring OAM as compared to what's available today. Finally, if you prefer to do analysis and planning work, then why shouldn't= you? In parallel to those commencing work on specifying SR. Regards, Ruediger -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net] Sent: Monday, September 09, 2013 12:49 PM To: Geib, R=FCdiger Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps ruediger, On Sep 9, 2013, at 11:26 AM, wrote: > sorry, but why should the ISPs interested in standardising SR worry about= issues ocurring for ISPs who are not interested in migrating to SR? I don'= t think, SR should look for replacements, SR should work on simplifications= . That's what the charter should express. I'm not interested in working wit= hin a "LDP and RSVP-TE replacement WG". Sorry if my first mail was overstat= ed to that regard ("...get rid of"). if its not 'obsoleting' something, then it is by definition an 'extension' = of something. in other words the complexity of the 'something' will be going up and never= down. i haven't yet identified the code to be deleted, if SR is going to be a suc= cess ;-) > DT so far does not utilise RSVP TE in parts of the backbone, but is inter= ested in SR based features offering similar routing properties. Bandwidth r= eservation and preemption are completely irrelevant to me. that is fine and yet for the industry as a whole doing distributed bandwidth reservation *is* a relevant functionality. > If there are issues, we will (dis)cover them while we work on the technol= ogy. But discovering issues and analysing them shouldn't be core part of a = charter - the features to be developed should be. i'd rather do the analysis and planning exercise before commencing work. > [ ... ] /hannes > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, September 09, 2013 10:57 AM > To: Geib, R=FCdiger > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > ruediger, > > On Sep 9, 2013, at 9:08 AM, wrote: >> I'm worried about the proposal below, which seem to miss the most import= ant points of SR (I call it that): >> >> - SR allows to reduce complexity by getting rid of RSVP TE and LDP. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > that seem to be a gross misunderstanding on your side; > > 'reducing complexity' means *obsoleting* technology A with technology B. > > the issue is that introduction of SR does *neither* obsolete LDP *nor* RS= VP, > simply because SR is not a 100% replacement of LDP and RSVP functionaliti= es. > > SR lacks functionality in areas of: > > 1. LSP bandwidth reservation > 2. LSP preemption > 3. p2mp path construction > 4. PW signaling > 5. FRR node-protection > > adding the IGP as a label distribution protocol to the stack of protocols > allows the network to do tunnel discovery and with that capability we can= arguably fix > a couple of interesting problems, but does this single capability > make it a panacea for networking ? > >> - I don't fully understand why the SR work must address inter domain rel= ations, if >> it is supposed to be primarily chartered with intra domain control plane= issues. >> - My take is, that intra-domain MPLS forwarding will remain as is initia= lly with SR. > > there are SPs which operate multi-AS domains and the implications > to connect those ASes using label-stacking technology should be worked on= . > >> - Your last bullet point means todays MPLS is out of scope, as no forwar= ding >> definitions need to be changed? > > not sure if we can get away with zero changes - issues that we need to ta= lk about are: > > 1. MPLS source labels > 2. Entropy label implications of label stacking > 3. Hardware capabilites (Maxpushlabels) and management > >> - We agreed not work on protocols within the SR WG. Why has that been ch= anged? > > there might be a a need to work on protocols which do not fit into existi= ng WGs. > > HTH, > > /hannes > >> --------------- >> >> The working group is chartered for the following ordered list= of work items: >> >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. >> However, no protocol work will be adopted by a working group to address = the identified use-cases until the requirements document motivating the pro= tocol work has been sent to the IESG for publication as an RFC. >> >> --- >> >> /hannes >> >> On Sep 4, 2013, at 10:02 AM, wrote: >> >>> Hannes, >>> >>> In case, we are using only directed forwarding (adjacency segment), >>> could we still talk about tunneling ? (it's a very very small tunnel) M= oreover talking about "stacking" is really dataplane agnostic (MPLS) ... >>> >>> In the proposed segment routing architectural concepts, segments are at= the same "level" and pointer moves on the segment list, then the MPLS inst= antiation is performing this using stacking ... >>> >>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solut= ion and it's closing the door to something else ... >>> >>> Finally, about the "routing" word, routing is essentially a "forward" a= ction which may limit the scope of what we can do by using a segment list. = Actions associated with a segment could be something else than forwarding. >>> >>> Do we want in the charter to limit the scope to routing actions ? >>> >>> I have no solution today to propose for the naming, but I completely ag= ree with Loa, to first focus on working on the charter, and define a clear = scope of the work and then the name will be easier to find. >>> >>> Regarding your charter proposal : >>> >>> -------- >>> >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>> >>> - They can forward traffic through the shortest paths or paths other th= an the shortest (the latter called explicitly routed paths, or explicit pat= hs) >>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>> >>> - They share a common trust model. In this model, any router within the= ERD can specify an explicit path between itself and any other router in th= e ERD. It can then send any packet that passes through it through any path = that it has specified. >>> [SLI] Security considerations may have to be addressed in the >>> charter , especially for the interAS case (trust yes, but not sure >>> access to everything may not be good) >>> >>> Downstream routers within the ERD forward the packet as specified by th= e router at the head-end of the path. >>> [SLI] Yes, but any router in the middle may be able to change the end t= o end explicit path. >>> >>> >>> >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between curren= tly available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> >>> [SLI] Agree, I would add : >>> - defining the architecture framework >>> - analysing the security considerisations >>> >>> >>> --------- >>> >>> >>> Here would be my proposal to extend yours : >>> >>> A domain contains a set of routers with the follo= wing characteristics: >>> >>> - They form a connected network >>> - They can forward traffic through any path within the network using >>> shortest path, non shortest path or explicit path >>> - They may provide other types of services than forwarding and they can= enforce service actions in the path. >>> - They share a common trust model. In this model, any router within the= domain can specify a path between itself and any other router in the domai= n. It may then send any packet that passes through it through any path that= it has specified and that is conform to the security rules. Downstream rou= ters within the ERD forward the packet as specified by the router at the he= ad-end of the path. >>> >>> The working group is chartered for the following ordered list of= work items: >>> >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with th= e security considerations. The architecture framework and security consider= ations must address the relations between domains (interdomain). >>> - Having identified use-cases, architecture and security, the WG will i= dentify gaps between currently available technologies and use-case requirem= ents. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>> >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. However, no protocol = work will be adopted by a working group to address the ERD use-cases until = the requirements document motivating the protocol work has been sent to the= IESG for publication as an RFC. >>> >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Lo= a >>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >>> BOF and the next steps >>> >>> good point - what about this charter proposal ? >>> >>> --- >>> >>> Stacked Tunnels for Explicit Routing (STER) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> A explicit routing domain (ERD) contains a set of routers with the foll= owing characteristics: >>> >>> - They form a connected network >>> - They can forward traffic through the shortest paths or paths other >>> than the shortest (the latter called explicitly routed paths, or >>> explicit paths) >>> - They share a common trust model. In this model, any router within the= ERD can specify an explicit path between itself and any other router in th= e ERD. It can then send any packet that passes through it through any path = that it has specified. Downstream routers within the ERD forward the packet= as specified by the router at the head-end of the path. >>> >>> The STER working group is chartered for the following ordered list of w= ork items: >>> >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between curren= tly available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. However, no protocol = work will be adopted by a working group to address the ERD use-cases until = the requirements document motivating the protocol work has been sent to the= IESG for publication as an RFC. >>> >>> --- >>> >>> >>> >>> /hannes >>> >>> >>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>> >>>> Folks, >>>> >>>> Excuse me if I'm slightly out of the loop, but so far I have not seen >>>> a charter proposal, if there is one please point me to it. >>>> >>>> It seems a bit odd to put the cart (what the wg should do) before the >>>> horse (wg name). If we drill down the the charter first the wg name >>>> might be easier to figure out. >>>> >>>> /Loa >>>> >>>> PS >>>> OK I understand that the horse and cart analogy limps a bit :). >>>> >>>> >>>> >>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>> " If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another working = group ? So we will go back to the WG synchronization issue that has been ra= ised for this technology ..." >>>>> >>>>> That's why I suggested SRV2. We are revisiting source routing with ne= w concepts. More generic number/action behavior. >>>>> >>>>> Peter >>>>> >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of stephane.litkowski@orange.com >>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>> To: AshwoodsmithPeter >>>>> Cc: status@ietf.org >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> >>>>> There was a misunderstanding in my small comment :) so I will explain= more : >>>>> >>>>> In segment routing, you have more than basic source routing : segment= routing is just associate a segment number to an action and then combine s= egment as you want, yes you can do source routing, but you also can do more= . >>>>> >>>>> In the other hand, I completely agree with your statement that >>>>> source routing is generic and dataplane agnostic, as segment routing = is ... >>>>> (segment routing is not a new dataplane ...) >>>>> >>>>> Now the definition of the WG naming must be inline with the charter >>>>> that will be defined ... (draft today) >>>>> >>>>> Based on the already existing consensus (at least for MPLS dataplane)= brought up during Berlin STATUS BOF meeting, segment routing sounds to be = a good target candidate. >>>>> >>>>> So now, do we want to do more in the WG charter than just make progre= ssing segment routing architecture and uses cases document and ensure coord= ination for the standardization of this technology ? >>>>> >>>>> Do we want to standardize other technologies in this WG ? I don't thi= nk so, based on Stewart's conclusion email from the BOF :"A new WG focused = solely on SR therefore needs to be create" >>>>> >>>>> If the WG charter is limited to source routing, how will we handle th= e "non source routing" use cases of segment routing ? In another working gr= oup ? So we will go back to the WG synchronization issue that has been rais= ed for this technology ... >>>>> >>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>> >>>>> Feedback ? >>>>> >>>>> >>>>> Stephane >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>> [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> The term "source routing" has been around for a very long time and is= data path agnostic. Its also the term used in the literature etc so my pre= ference is to stick with this existing well known and data path agnostic te= rm. >>>>> >>>>> Peter >>>>> >>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> "Source routing" is just a subcase of segment routing ... as it is f= or IP routing ... >>>>>> >>>>>> Stephane >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : M= ark >>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>> BOF and the next steps >>>>>> >>>>>> Hi, >>>>>> >>>>>> What is this 'segment routing' silliness? The correct term is 'sour= ce routing'. >>>>>> >>>>>> Yours Irrespectively, >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>>> Behalf Of Mark Townsley >>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>> To: Victor Kuarsingh >>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>> (stbryant) >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>> >>>>>>> >>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>> >>>>>>>> I note this since attempting to come up with an all encompassing >>>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>>> to associate to multiple functions. >>>>>>> >>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>>> short name for the various automated tools not to break. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Victor K >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 for Segment Routing WG >>>>>>>>> >>>>>>>>> Roberta >>>>>>>>> >>>>>>>>> Sent from my iPad >>>>>>>>> >>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Segment Routing WG >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> ___________________________________________________________________ >>>>>> _ __ ___________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> ____________________________________________________________________ >>>>> _ ____________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >>> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> >>> >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> > > > > From hannes@juniper.net Mon Sep 9 05:13:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C6621E81A3 for ; Mon, 9 Sep 2013 05:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foiZhv6NyYL7 for ; Mon, 9 Sep 2013 05:13:37 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1458021E8192 for ; Mon, 9 Sep 2013 05:13:28 -0700 (PDT) Received: from mail211-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 12:13:27 +0000 Received: from mail211-ch1 (localhost [127.0.0.1]) by mail211-ch1-R.bigfish.com (Postfix) with ESMTP id 7D26036016A; Mon, 9 Sep 2013 12:13:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0512HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(z551biz98dI9371Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail211-ch1: domain of juniper.net designates 157.56.238.5 as permitted sender) client-ip=157.56.238.5; envelope-from=hannes@juniper.net; helo=BY2PRD0512HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1 (MessageSwitch) id 1378728806153679_1739; Mon, 9 Sep 2013 12:13:26 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail211-ch1.bigfish.com (Postfix) with ESMTP id 20E3C260040; Mon, 9 Sep 2013 12:13:26 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 12:13:22 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.243.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 12:13:19 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Mon, 9 Sep 2013 14:13:02 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:13:51 -0000 robert, On Sep 9, 2013, at 1:03 PM, Robert Raszuk wrote: >> i haven't yet identified the code to be deleted, if SR is going to be = a success ;-) >=20 > How about LDP as starter ? this would really disappoint my RFC4447 (LDP pseudo wire) customers if i'd remove LDP support in favor of SR. > Which of the below are solved by LDP ? Which LDP functionality will > not be covered by SR ? (3) is solved by mLDP and RSVP-TE. (1) and (2) is solved by RSVP-TE >>> 1. LSP bandwidth reservation >>> 2. LSP preemption >>> 3. p2mp path construction >=20 > Note that those are all done today in the control plane. Therefor it > seems pretty trivial to accomplish all of those with SR using number ^^^^^^^^^^^^^^ > of PCE or PCE like controllers rather then use RSVP-TE for explicit > path signaling. "In theory there is no difference between theory and practice. In = practice there is." so lets discuss about the *practical* side of things. assume for a second that we have a single TE controller that updates potentially thousands of PCE clients. how long would it take to react after a topology change ? (=3Drecompute and upload new explicit routes). is it order of milliseconds ? order of seconds if not order of minutes = ? it is obvious that somehow you need to distribute the TE-controller functionality such that you can re-act fast enough to process topology changes. - the more distributed the controller = gets the more reactive the TE-controller system gets. next lets assume that every PCE client gets its own PCE server, = co-located with a zero-latency path and you will discover that this is no different than what we have today. so what SR does wrt to TE is essentially shifting functionality around rather than solving it in any better way. >>> 5. FRR node-protection >=20 > As you know computing LFA sort of addresses this topic pretty well. ^^^^^^^^^^^ no i don't - and for my own education would be really interested to = learn how to provide node-protection for 1-hop (per-adjacency) labels. > Moreover SR may complete topologies where today LFA may not be > possible in 100% of coverage. i am afraid SR is still not there - trouble is that LFA is like "star wars" - there are many episodes =85 episode 1: rfc5286=20 episode 2: remote-LFA episode 3: remote-LFA + DF note that even at this stage we haven't arrived at "100% coverage - no = matter what" so likely there will be: episode 4: remote-LFA + recursive DF >>> a couple of interesting problems, but does this single capability >>> make it a panacea for networking ? >=20 > Some folks think that MPLS is a panacea for networking .. SR with IP > encap can prove it is not ;) That's the beauty of it. do we really want to revamp 15 years old discussions - get over it ;-) MPLS is a useful technology and most important the MPLS data plane is available today. >> apart from that i simply fail to see the need for developing = redundant >> technology within IETF. >=20 > Why not since the redundant technology has much better scaling and ^^^^^^^ > operational properties. It simplifies control plane and that alone > should be sufficient reason. i have learned over the years that the pundits of "simpler, better cheaper" are very creative minds in omitting details which matter, (but do not necessarily work into their favor). /hannes From hannes@juniper.net Mon Sep 9 05:22:20 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3354621E81AA for ; Mon, 9 Sep 2013 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FazA8v41-v2Q for ; Mon, 9 Sep 2013 05:22:07 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7FC21E81A8 for ; Mon, 9 Sep 2013 05:20:18 -0700 (PDT) Received: from mail123-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 12:20:18 +0000 Received: from mail123-co9 (localhost [127.0.0.1]) by mail123-co9-R.bigfish.com (Postfix) with ESMTP id ECFE78C00C4; Mon, 9 Sep 2013 12:20:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -71 X-BigFish: VPS-71(z551biz62a3I98dI9371Ic89bh936eI542Iec9I1432I15caKJdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail123-co9: domain of juniper.net designates 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=hannes@juniper.net; helo=BN1PRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail123-co9 (localhost.localdomain [127.0.0.1]) by mail123-co9 (MessageSwitch) id 1378729208402186_12311; Mon, 9 Sep 2013 12:20:08 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.245]) by mail123-co9.bigfish.com (Postfix) with ESMTP id 5D220340040; Mon, 9 Sep 2013 12:20:08 +0000 (UTC) Received: from BN1PRD0512HT003.namprd05.prod.outlook.com (132.245.2.21) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 12:20:03 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.193.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 9 Sep 2013 12:19:48 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Mon, 9 Sep 2013 14:19:29 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:22:20 -0000 On Sep 9, 2013, at 1:58 PM, = wrote: > [ =85 ] > In addition, SR will allow for very scaleable LSP monitoring OAM. = Trying to to this with todays features is very complex (we've done = that). > SR can simplify LSP monitoring OAM as compared to what's available = today. thats fine - and the OAM use case is an undisputed one - no worries; the question to you is: for doing OAM do you need an IPv6-SR flavor and if so why ? > Finally, if you prefer to do analysis and planning work, then why = shouldn't you? In parallel to those commencing work on specifying SR. you cannot build a house without a plan beforehand, right ? > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, September 09, 2013 12:49 PM > To: Geib, R=FCdiger > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps >=20 > ruediger, >=20 > On Sep 9, 2013, at 11:26 AM, wrote: >> sorry, but why should the ISPs interested in standardising SR worry = about issues ocurring for ISPs who are not interested in migrating to = SR? I don't think, SR should look for replacements, SR should work on = simplifications. That's what the charter should express. I'm not = interested in working within a "LDP and RSVP-TE replacement WG". Sorry = if my first mail was overstated to that regard ("...get rid of"). >=20 > if its not 'obsoleting' something, then it is by definition an = 'extension' of something. > in other words the complexity of the 'something' will be going up and = never down. > i haven't yet identified the code to be deleted, if SR is going to be = a success ;-) >=20 >> DT so far does not utilise RSVP TE in parts of the backbone, but is = interested in SR based features offering similar routing properties. = Bandwidth reservation and preemption are completely irrelevant to me. >=20 > that is fine and yet for the industry as a whole doing distributed > bandwidth reservation *is* a relevant functionality. >=20 >> If there are issues, we will (dis)cover them while we work on the = technology. But discovering issues and analysing them shouldn't be core = part of a charter - the features to be developed should be. >=20 > i'd rather do the analysis and planning exercise > before commencing work. >=20 >> [ ... ] >=20 >=20 > /hannes >=20 >> -----Original Message----- >> From: Hannes Gredler [mailto:hannes@juniper.net] >> Sent: Monday, September 09, 2013 10:57 AM >> To: Geib, R=FCdiger >> Cc: status@ietf.org >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>=20 >> ruediger, >>=20 >> On Sep 9, 2013, at 9:08 AM, wrote: >>> I'm worried about the proposal below, which seem to miss the most = important points of SR (I call it that): >>>=20 >>> - SR allows to reduce complexity by getting rid of RSVP TE and LDP. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>=20 >> that seem to be a gross misunderstanding on your side; >>=20 >> 'reducing complexity' means *obsoleting* technology A with technology = B. >>=20 >> the issue is that introduction of SR does *neither* obsolete LDP = *nor* RSVP, >> simply because SR is not a 100% replacement of LDP and RSVP = functionalities. >>=20 >> SR lacks functionality in areas of: >>=20 >> 1. LSP bandwidth reservation >> 2. LSP preemption >> 3. p2mp path construction >> 4. PW signaling >> 5. FRR node-protection >>=20 >> adding the IGP as a label distribution protocol to the stack of = protocols >> allows the network to do tunnel discovery and with that capability we = can arguably fix >> a couple of interesting problems, but does this single capability >> make it a panacea for networking ? >>=20 >>> - I don't fully understand why the SR work must address inter domain = relations, if >>> it is supposed to be primarily chartered with intra domain control = plane issues. >>> - My take is, that intra-domain MPLS forwarding will remain as is = initially with SR. >>=20 >> there are SPs which operate multi-AS domains and the implications >> to connect those ASes using label-stacking technology should be = worked on. >>=20 >>> - Your last bullet point means todays MPLS is out of scope, as no = forwarding >>> definitions need to be changed? >>=20 >> not sure if we can get away with zero changes - issues that we need = to talk about are: >>=20 >> 1. MPLS source labels >> 2. Entropy label implications of label stacking >> 3. Hardware capabilites (Maxpushlabels) and management >>=20 >>> - We agreed not work on protocols within the SR WG. Why has that = been changed? >>=20 >> there might be a a need to work on protocols which do not fit into = existing WGs. >>=20 >> HTH, >>=20 >> /hannes >>=20 >>> --------------- >>>=20 >>> The working group is chartered for the following ordered = list of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with >>> the security considerations. The architecture framework and security >>> considerations must address the relations between domains = (interdomain). >>> - Having identified use-cases, architecture and security, the WG = will >>> identify gaps between currently available technologies and use-case >>> requirements. >>> - The WG will then define requirements for extensions to existing >>> protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. >>> However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >>>=20 >>> --- >>>=20 >>> /hannes >>>=20 >>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>=20 >>>> Hannes, >>>>=20 >>>> In case, we are using only directed forwarding (adjacency segment), >>>> could we still talk about tunneling ? (it's a very very small = tunnel) Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>>=20 >>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the = MPLS instantiation is performing this using stacking ... >>>>=20 >>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>>=20 >>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>=20 >>>> Do we want in the charter to limit the scope to routing actions ? >>>>=20 >>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>=20 >>>> Regarding your charter proposal : >>>>=20 >>>> -------- >>>>=20 >>>> - They form a connected network >>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>=20 >>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>>=20 >>>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >>>> [SLI] Security considerations may have to be addressed in the >>>> charter , especially for the interAS case (trust yes, but not sure >>>> access to everything may not be good) >>>>=20 >>>> Downstream routers within the ERD forward the packet as specified = by the router at the head-end of the path. >>>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>>=20 >>>>=20 >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>=20 >>>> [SLI] Agree, I would add : >>>> - defining the architecture framework >>>> - analysing the security considerisations >>>>=20 >>>>=20 >>>> --------- >>>>=20 >>>>=20 >>>> Here would be my proposal to extend yours : >>>>=20 >>>> A domain contains a set of routers with the = following characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through any path within the network = using >>>> shortest path, non shortest path or explicit path >>>> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >>>> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>>>=20 >>>> The working group is chartered for the following ordered = list of work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>=20 >>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>=20 >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 = : Loa >>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of = STATUS >>>> BOF and the next steps >>>>=20 >>>> good point - what about this charter proposal ? >>>>=20 >>>> --- >>>>=20 >>>> Stacked Tunnels for Explicit Routing (STER) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through the shortest paths or paths = other >>>> than the shortest (the latter called explicitly routed paths, or >>>> explicit paths) >>>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>>>=20 >>>> The STER working group is chartered for the following ordered list = of work items: >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>=20 >>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>=20 >>>> --- >>>>=20 >>>> >>>>=20 >>>> /hannes >>>>=20 >>>>=20 >>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>>> a charter proposal, if there is one please point me to it. >>>>>=20 >>>>> It seems a bit odd to put the cart (what the wg should do) before = the >>>>> horse (wg name). If we drill down the the charter first the wg = name >>>>> might be easier to figure out. >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> PS >>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>=20 >>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of stephane.litkowski@orange.com >>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>> To: AshwoodsmithPeter >>>>>> Cc: status@ietf.org >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>=20 >>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>=20 >>>>>> In the other hand, I completely agree with your statement that >>>>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>>>> (segment routing is not a new dataplane ...) >>>>>>=20 >>>>>> Now the definition of the WG naming must be inline with the = charter >>>>>> that will be defined ... (draft today) >>>>>>=20 >>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>=20 >>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>>=20 >>>>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>>>=20 >>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>=20 >>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>>=20 >>>>>> Feedback ? >>>>>>=20 >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; = Roberta >>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc = so my preference is to stick with this existing well known and data path = agnostic term. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : Mark >>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; = status@ietf.org; >>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>>> BOF and the next steps >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>>=20 >>>>>>> Yours Irrespectively, >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>>> Behalf Of Mark Townsley >>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>> To: Victor Kuarsingh >>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>> (stbryant) >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>=20 >>>>>>>>> All, >>>>>>>>>=20 >>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>=20 >>>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>>> acronym will be difficult and Segment Routing is generic = enough >>>>>>>>> to associate to multiple functions. >>>>>>>>=20 >>>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>>> have to have acronyms, but they do need to have an 8-char = limited >>>>>>>> short name for the various automated tools not to break. >>>>>>>>=20 >>>>>>>> - Mark >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Victor K >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Roberta >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPad >>>>>>>>>>=20 >>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Segment Routing WG >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>=20 >>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> = ___________________________________________________________________ >>>>>>> _ __ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> = ____________________________________________________________________ >>>>>> _ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = ______________________________________________________________________ >>>> ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 From rraszuk@gmail.com Mon Sep 9 05:47:32 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55E611E81DC for ; Mon, 9 Sep 2013 05:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVXCgmf7+n3q for ; Mon, 9 Sep 2013 05:47:25 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8D45211E81FF for ; Mon, 9 Sep 2013 05:44:39 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k10so4270087iea.33 for ; Mon, 09 Sep 2013 05:44:39 -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=dqmx8qrHc65QMuOG2/bvck7j2Tkyvx442B+t8IUqRqk=; b=Tamvxr7HDvoEb3vGYclUPJx6PDemv7aIrL6Npigd5I3kIuMU9HEfW8tmdaFjEQWP0l Fq1DcPq11ZYlIKEDtBYQmv5jsEqEx0lsqLb/zlUcPjIqGJfdgnR4Q/dj4ttZ4fiE4km9 FTM6wr985MuYFxnmx3adiCKuWD9u1psCjP8M/s7RwrOvQ58kTpWc1he+P5A3FRvcSeJR ofbAMnYqBsNuV8iUDZ3IL8TD+KbNsv5pBcTsrPpejVg7WqmuBhQcIswlBY2it5fjfpui getLTBigZIYvWofFTzZLZHmC7H+BR/UnFxdLItdTQNov2ZeGLS6UdqWDkxPARrA19z3W KQcA== MIME-Version: 1.0 X-Received: by 10.50.138.165 with SMTP id qr5mr7894980igb.25.1378730679184; Mon, 09 Sep 2013 05:44:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 9 Sep 2013 05:44:39 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 14:44:39 +0200 X-Google-Sender-Auth: fvwHTEheO_XEpy_EvL_euHnqCNQ Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:47:33 -0000 Hi Hannes, >> How about LDP as starter ? > > this would really disappoint my RFC4447 (LDP pseudo wire) customers > if i'd remove LDP support in favor of SR. Pseudowires is an overlay application/service. As such a mechanism which is much better suited to signal overlays should be recommended. Hint: RFC4761 BGP works pretty well for p2mp discovery and signalling ... I see no reason to use bunch of LDP p2p sessions for that. Recall discussions about LDP reflectors ;) ? Likewise there are new emerging ways to signal overlay services, but I think this is not the right place to discuss those. >> Which of the below are solved by LDP ? Which LDP functionality will >> not be covered by SR ? > > (3) is solved by mLDP and RSVP-TE. > (1) and (2) is solved by RSVP-TE > >>>> 1. LSP bandwidth reservation >>>> 2. LSP preemption >>>> 3. p2mp path construction mLDP has not much in common with LDP other then name. It is PIM ported to signal MPLS bindings. I did not say to get rid of mLDP. >> Note that those are all done today in the control plane. Therefor it >> seems pretty trivial to accomplish all of those with SR using number > ^^^^^^^^^^^^^^ >> of PCE or PCE like controllers rather then use RSVP-TE for explicit >> path signaling. > > "In theory there is no difference between theory and practice. In practic= e there is." You don't need to be that explicit .... ;-)) > so lets discuss about the *practical* side of things. > > assume for a second that we have a single TE controller > that updates potentially thousands of PCE clients. > how long would it take to react after a topology change ? > (=3Drecompute and upload new explicit routes). > is it order of milliseconds ? order of seconds if not order of minutes = ? As compared with what ? With today the same single controller instructing all headends to do the re- signalling Note that I am of the strong opinion that reaction to failures should be precomputed and preinstalled ahead of failure in any technology we use. Then upon failure control plane can take as much as needed to "converge". > it is obvious that somehow you need to distribute the > TE-controller functionality such that you can re-act fast enough > to process topology changes. - the more distributed the controller gets > the more reactive the TE-controller system gets. See above ... I would argue that link state flooding is much more faster then hop by hop RSVP signalling. You may not agree ... > next lets assume that every PCE client gets its own PCE server, co-loca= ted > with a zero-latency path and you will discover that this is no > different than what we have today. If you follow some of the PCE discussions you would see that this model does not allow for required optimization for number of traffic distributions needs. Hint: Google centralized PCE model described in public papers and presentations. > so what SR does wrt to TE is essentially shifting functionality around > rather than solving it in any better way. It solves the signalling issue. The domain wide coordination of computation of paths is still the same. >>>> 5. FRR node-protection >> >> As you know computing LFA sort of addresses this topic pretty well. > ^^^^^^^^^^^ > > no i don't - and for my own education would be really interested to learn > how to provide node-protection for 1-hop (per-adjacency) labels. Creating LFA bypass of each node with when required SR segment going far enough that loops are guaranteed not to occur looks like pretty easy exercise. Sorry I have no math prove that this will address any network topology, but I also see no reason why it would not. >> Moreover SR may complete topologies where today LFA may not be >> possible in 100% of coverage. > > i am afraid SR is still not there - Perfect topic for this WG to make it be there. Can we add this to the chart= er ? > trouble is that LFA is like "star wars" - there are many episodes =85 > > episode 1: rfc5286 > episode 2: remote-LFA > episode 3: remote-LFA + DF > > note that even at this stage we haven't arrived at "100% coverage - no ma= tter what" > so likely there will be: > > episode 4: remote-LFA + recursive DF And that's actually a great indication why issues are related and why it would be productive to work on SR documents in RTGWG. I am sure your familiarity with science-fiction movies could easily turn SR into series of "start trek" episodes ... > MPLS is a useful technology and most important the MPLS data plane > is available today. Sure. But as we do know MPLS lacks well defined inter-domain NNI, as well as it's adoption in number of emerging solutions (DC fabrics) is rather non existent. > i have learned over the years that the pundits of "simpler, better > cheaper" are very creative minds in omitting details which matter, > (but do not necessarily work into their favor). I am not afraid to discuss details. But discussing details is very different in practice from building the wall of let's just discuss missing gaps from what we have today. I am afraid this time it will not work that way .. sorry. Cheers, R. From Ruediger.Geib@telekom.de Mon Sep 9 05:56:37 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665AE21E8154 for ; Mon, 9 Sep 2013 05:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVsOoSRVJ14j for ; Mon, 9 Sep 2013 05:56:25 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 6A00B21E81A3 for ; Mon, 9 Sep 2013 05:54:46 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 09 Sep 2013 14:54:40 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 9 Sep 2013 14:54:39 +0200 From: To: Date: Mon, 9 Sep 2013 14:54:38 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6tVwXCNVKOqluPQ3CSNeOrdZ3ugwAAoOyQ Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:56:37 -0000 Hannes, I've talked about MPLS LSP monitoring. IPv6 to me is of interest in RFC4379= context only. As ECMP and tracing or adressing ECMP paths helps to reduce = label stacks, ECMP related RFC4379 functionality is desireable with SR too,= I think. I'm not yet interested native IPv6 OAM functions. Regards, Ruediger -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net] Sent: Monday, September 09, 2013 2:19 PM To: Geib, R=FCdiger Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps On Sep 9, 2013, at 1:58 PM, wrote: > [ ... ] > In addition, SR will allow for very scaleable LSP monitoring OAM. Trying = to to this with todays features is very complex (we've done that). > SR can simplify LSP monitoring OAM as compared to what's available today. thats fine - and the OAM use case is an undisputed one - no worries; the question to you is: for doing OAM do you need an IPv6-SR flavor and if so why ? > Finally, if you prefer to do analysis and planning work, then why shouldn= 't you? In parallel to those commencing work on specifying SR. you cannot build a house without a plan beforehand, right ? > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Monday, September 09, 2013 12:49 PM > To: Geib, R=FCdiger > Cc: status@ietf.org > Subject: Re: [Status] Summary of STATUS BOF and the next steps > > ruediger, > > On Sep 9, 2013, at 11:26 AM, wrote: >> sorry, but why should the ISPs interested in standardising SR worry abou= t issues ocurring for ISPs who are not interested in migrating to SR? I don= 't think, SR should look for replacements, SR should work on simplification= s. That's what the charter should express. I'm not interested in working wi= thin a "LDP and RSVP-TE replacement WG". Sorry if my first mail was oversta= ted to that regard ("...get rid of"). > > if its not 'obsoleting' something, then it is by definition an 'extension= ' of something. > in other words the complexity of the 'something' will be going up and nev= er down. > i haven't yet identified the code to be deleted, if SR is going to be a s= uccess ;-) > >> DT so far does not utilise RSVP TE in parts of the backbone, but is inte= rested in SR based features offering similar routing properties. Bandwidth = reservation and preemption are completely irrelevant to me. > > that is fine and yet for the industry as a whole doing distributed > bandwidth reservation *is* a relevant functionality. > >> If there are issues, we will (dis)cover them while we work on the techno= logy. But discovering issues and analysing them shouldn't be core part of a= charter - the features to be developed should be. > > i'd rather do the analysis and planning exercise > before commencing work. > >> [ ... ] > > > /hannes > >> -----Original Message----- >> From: Hannes Gredler [mailto:hannes@juniper.net] >> Sent: Monday, September 09, 2013 10:57 AM >> To: Geib, R=FCdiger >> Cc: status@ietf.org >> Subject: Re: [Status] Summary of STATUS BOF and the next steps >> >> ruediger, >> >> On Sep 9, 2013, at 9:08 AM, wrote: >>> I'm worried about the proposal below, which seem to miss the most impor= tant points of SR (I call it that): >>> >>> - SR allows to reduce complexity by getting rid of RSVP TE and LDP. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> that seem to be a gross misunderstanding on your side; >> >> 'reducing complexity' means *obsoleting* technology A with technology B. >> >> the issue is that introduction of SR does *neither* obsolete LDP *nor* R= SVP, >> simply because SR is not a 100% replacement of LDP and RSVP functionalit= ies. >> >> SR lacks functionality in areas of: >> >> 1. LSP bandwidth reservation >> 2. LSP preemption >> 3. p2mp path construction >> 4. PW signaling >> 5. FRR node-protection >> >> adding the IGP as a label distribution protocol to the stack of protocol= s >> allows the network to do tunnel discovery and with that capability we ca= n arguably fix >> a couple of interesting problems, but does this single capability >> make it a panacea for networking ? >> >>> - I don't fully understand why the SR work must address inter domain re= lations, if >>> it is supposed to be primarily chartered with intra domain control plan= e issues. >>> - My take is, that intra-domain MPLS forwarding will remain as is initi= ally with SR. >> >> there are SPs which operate multi-AS domains and the implications >> to connect those ASes using label-stacking technology should be worked o= n. >> >>> - Your last bullet point means todays MPLS is out of scope, as no forwa= rding >>> definitions need to be changed? >> >> not sure if we can get away with zero changes - issues that we need to t= alk about are: >> >> 1. MPLS source labels >> 2. Entropy label implications of label stacking >> 3. Hardware capabilites (Maxpushlabels) and management >> >>> - We agreed not work on protocols within the SR WG. Why has that been c= hanged? >> >> there might be a a need to work on protocols which do not fit into exist= ing WGs. >> >> HTH, >> >> /hannes >> >>> --------------- >>> >>> The working group is chartered for the following ordered lis= t of work items: >>> >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with >>> the security considerations. The architecture framework and security >>> considerations must address the relations between domains (interdomain)= . >>> - Having identified use-cases, architecture and security, the WG will >>> identify gaps between currently available technologies and use-case >>> requirements. >>> - The WG will then define requirements for extensions to existing >>> protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>> >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. >>> However, no protocol work will be adopted by a working group to address= the identified use-cases until the requirements document motivating the pr= otocol work has been sent to the IESG for publication as an RFC. >>> >>> --- >>> >>> /hannes >>> >>> On Sep 4, 2013, at 10:02 AM, wrote: >>> >>>> Hannes, >>>> >>>> In case, we are using only directed forwarding (adjacency segment), >>>> could we still talk about tunneling ? (it's a very very small tunnel) = Moreover talking about "stacking" is really dataplane agnostic (MPLS) ... >>>> >>>> In the proposed segment routing architectural concepts, segments are a= t the same "level" and pointer moves on the segment list, then the MPLS ins= tantiation is performing this using stacking ... >>>> >>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solu= tion and it's closing the door to something else ... >>>> >>>> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment list.= Actions associated with a segment could be something else than forwarding. >>>> >>>> Do we want in the charter to limit the scope to routing actions ? >>>> >>>> I have no solution today to propose for the naming, but I completely a= gree with Loa, to first focus on working on the charter, and define a clear= scope of the work and then the name will be easier to find. >>>> >>>> Regarding your charter proposal : >>>> >>>> -------- >>>> >>>> - They form a connected network >>>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>> >>>> - They can forward traffic through the shortest paths or paths other t= han the shortest (the latter called explicitly routed paths, or explicit pa= ths) >>>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>>> >>>> - They share a common trust model. In this model, any router within th= e ERD can specify an explicit path between itself and any other router in t= he ERD. It can then send any packet that passes through it through any path= that it has specified. >>>> [SLI] Security considerations may have to be addressed in the >>>> charter , especially for the interAS case (trust yes, but not sure >>>> access to everything may not be good) >>>> >>>> Downstream routers within the ERD forward the packet as specified by t= he router at the head-end of the path. >>>> [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >>>> >>>> >>>> >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between curre= ntly available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>> >>>> [SLI] Agree, I would add : >>>> - defining the architecture framework >>>> - analysing the security considerisations >>>> >>>> >>>> --------- >>>> >>>> >>>> Here would be my proposal to extend yours : >>>> >>>> A domain contains a set of routers with the foll= owing characteristics: >>>> >>>> - They form a connected network >>>> - They can forward traffic through any path within the network using >>>> shortest path, non shortest path or explicit path >>>> - They may provide other types of services than forwarding and they ca= n enforce service actions in the path. >>>> - They share a common trust model. In this model, any router within th= e domain can specify a path between itself and any other router in the doma= in. It may then send any packet that passes through it through any path tha= t it has specified and that is conform to the security rules. Downstream ro= uters within the ERD forward the packet as specified by the router at the h= ead-end of the path. >>>> >>>> The working group is chartered for the following ordered list o= f work items: >>>> >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated with t= he security considerations. The architecture framework and security conside= rations must address the relations between domains (interdomain). >>>> - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case require= ments. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding definition. >>>> >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols, in coordination with this WG, an= d in agreement with the WG chairs and responsible ADs. However, no protocol= work will be adopted by a working group to address the ERD use-cases until= the requirements document motivating the protocol work has been sent to th= e IESG for publication as an RFC. >>>> >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : L= oa >>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >>>> BOF and the next steps >>>> >>>> good point - what about this charter proposal ? >>>> >>>> --- >>>> >>>> Stacked Tunnels for Explicit Routing (STER) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> A explicit routing domain (ERD) contains a set of routers with the fol= lowing characteristics: >>>> >>>> - They form a connected network >>>> - They can forward traffic through the shortest paths or paths other >>>> than the shortest (the latter called explicitly routed paths, or >>>> explicit paths) >>>> - They share a common trust model. In this model, any router within th= e ERD can specify an explicit path between itself and any other router in t= he ERD. It can then send any packet that passes through it through any path= that it has specified. Downstream routers within the ERD forward the packe= t as specified by the router at the head-end of the path. >>>> >>>> The STER working group is chartered for the following ordered list of = work items: >>>> >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between curre= ntly available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>> >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols, in coordination with this WG, an= d in agreement with the WG chairs and responsible ADs. However, no protocol= work will be adopted by a working group to address the ERD use-cases until= the requirements document motivating the protocol work has been sent to th= e IESG for publication as an RFC. >>>> >>>> --- >>>> >>>> >>>> >>>> /hannes >>>> >>>> >>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>> >>>>> Folks, >>>>> >>>>> Excuse me if I'm slightly out of the loop, but so far I have not seen >>>>> a charter proposal, if there is one please point me to it. >>>>> >>>>> It seems a bit odd to put the cart (what the wg should do) before the >>>>> horse (wg name). If we drill down the the charter first the wg name >>>>> might be easier to figure out. >>>>> >>>>> /Loa >>>>> >>>>> PS >>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>> >>>>> >>>>> >>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>> " If the WG charter is limited to source routing, how will we handle= the "non source routing" use cases of segment routing ? In another working= group ? So we will go back to the WG synchronization issue that has been r= aised for this technology ..." >>>>>> >>>>>> That's why I suggested SRV2. We are revisiting source routing with n= ew concepts. More generic number/action behavior. >>>>>> >>>>>> Peter >>>>>> >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of stephane.litkowski@orange.com >>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>> To: AshwoodsmithPeter >>>>>> Cc: status@ietf.org >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>> >>>>>> >>>>>> There was a misunderstanding in my small comment :) so I will explai= n more : >>>>>> >>>>>> In segment routing, you have more than basic source routing : segmen= t routing is just associate a segment number to an action and then combine = segment as you want, yes you can do source routing, but you also can do mor= e. >>>>>> >>>>>> In the other hand, I completely agree with your statement that >>>>>> source routing is generic and dataplane agnostic, as segment routing= is ... >>>>>> (segment routing is not a new dataplane ...) >>>>>> >>>>>> Now the definition of the WG naming must be inline with the charter >>>>>> that will be defined ... (draft today) >>>>>> >>>>>> Based on the already existing consensus (at least for MPLS dataplane= ) brought up during Berlin STATUS BOF meeting, segment routing sounds to be= a good target candidate. >>>>>> >>>>>> So now, do we want to do more in the WG charter than just make progr= essing segment routing architecture and uses cases document and ensure coor= dination for the standardization of this technology ? >>>>>> >>>>>> Do we want to standardize other technologies in this WG ? I don't th= ink so, based on Stewart's conclusion email from the BOF :"A new WG focused= solely on SR therefore needs to be create" >>>>>> >>>>>> If the WG charter is limited to source routing, how will we handle t= he "non source routing" use cases of segment routing ? In another working g= roup ? So we will go back to the WG synchronization issue that has been rai= sed for this technology ... >>>>>> >>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>> >>>>>> Feedback ? >>>>>> >>>>>> >>>>>> Stephane >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>>>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>> >>>>>> The term "source routing" has been around for a very long time and i= s data path agnostic. Its also the term used in the literature etc so my pr= eference is to stick with this existing well known and data path agnostic t= erm. >>>>>> >>>>>> Peter >>>>>> >>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>>>> >>>>>>> Stephane >>>>>>> >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>>> BOF and the next steps >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> What is this 'segment routing' silliness? The correct term is 'sou= rce routing'. >>>>>>> >>>>>>> Yours Irrespectively, >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>>>> Behalf Of Mark Townsley >>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>> To: Victor Kuarsingh >>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>> (stbryant) >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>> >>>>>>>> >>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>> >>>>>>>>> I note this since attempting to come up with an all encompassing >>>>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>>>> to associate to multiple functions. >>>>>>>> >>>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>>>> short name for the various automated tools not to break. >>>>>>>> >>>>>>>> - Mark >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Victor K >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>> >>>>>>>>>> Roberta >>>>>>>>>> >>>>>>>>>> Sent from my iPad >>>>>>>>>> >>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Segment Routing WG >>>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> ___________________________________________________________________ >>>>>>> _ __ ___________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de= truire ainsi que les pieces jointes. Les messages electroniques etant susce= ptibles d'alteration, Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >>>>>>> >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should no= t be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> ____________________________________________________________________ >>>>>> _ ____________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> ______________________________________________________________________ >>>> ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >>> >> >> >> >> > > > > From rjs@rob.sh Mon Sep 9 06:28:34 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737BF21E81A5 for ; Mon, 9 Sep 2013 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMJ6OPtbGyKa for ; Mon, 9 Sep 2013 06:28:25 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id D81D621E818F for ; Mon, 9 Sep 2013 06:28:24 -0700 (PDT) Received: from [2a00:c88:f:ebf:39aa:36ac:b04f:1bfa] (helo=epf-2013-conference.rhnet.is) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VJ1V1-0005Kl-7S; Mon, 09 Sep 2013 14:27:27 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Mon, 9 Sep 2013 13:28:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1C62FB-19F4-427E-9D39-212459A9FDF2@rob.sh> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <994A8BDB-8C3A-4FCF-A7CD-E61E5A7377F9@juniper.net> <65FBDC1D-3249-40F7-AC16-475424515DC4@rob.sh> To: Hannes Gredler X-Mailer: Apple Mail (2.1508) Cc: status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 13:28:34 -0000 Hi Hannes, On 9 Sep 2013, at 11:04, Hannes Gredler wrote: > hi rob, >=20 >>>=20 >> rjs> Isn't this an intra-domain use case? As I read it, ASBR{1,2} = allocate the label and advertise it within the AS1 IGP. There is no = labelled traffic passed between AS1 and AS{3,4,5,6} as both the ASBRs = program a pop operation. I read inter-domain as segments being used to = influence routing within two separate autonomous systems which are not = within the same trust domain. >=20 > HG> it is =85 now think for a moment if there would be one AS = in-between > the egress link - as per the illustration below: > the ingress router is in AS1 and it wants to control the exit link = of AS2-->AS3. >=20 > AS1--AS2--AS3 rjs> I haven't seen any demand for this use case though. Similarly to = the lack of demand (from my perspective) of inter-domain explicit = routing/path placement. rjs> I am going to go out on a limb here, and assert that there a huge = set of other problems if one starts allowing AS1 to explicitly define = routes within AS2 when they are outside different trust-domains. If we = try and bring anything like this in scope in the initial phase, then I = think we need to consult with the wider operational community as to how = AS2 looks after its own interests, before considering what the = technology solution is. Too often there are suggestions that we should = develop technology solutions, where the current operational reality is = that they are not implementable (based on commercial constraints, or = requirements for deterministic behaviour). rjs> So, based on this, let's tackle the intra-domain cases to start = with. If and when we have operators who have requirements for this to be = inter-domain, but intra-trust domain, then we can debate whether these = are of interest to the WG, similarly to the debate we can have when = there are operators raising requirements that need inter-domain, = inter-trust domain functionality. However, I do not see why we should = delay the implementation of intra-domain cases based on a possible = future extension :-) >> <=85snip=85> >> rjs> I can't comment on the assertions of others, and do not wish to = do so. In my view, there are pragmatic use cases (defined by a number of = operators) which are gaps that we cannot meet today. Let's identify = those, and work on those, and allow further uses of the technology going = forward if there is a convincing case to do so. >=20 > HG> agreed. >=20 >> rjs> I don't disagree that we should stay disciplined, but I do not = see the requirement to mandate that a document must be sent to the IESG = to be published *before* solutions drafts are adopted. Having a = requirement that the adopted solutions drafts should address the use = cases within previously adopted documents puts the same focus safe-guard = in as far as I can see. >=20 > HG> that seems reasonable to me as well - do you have a suggestion for = the actual text ? >=20 original> Protocol work may be carried out in this working group or in = other original> working groups responsible for the protocols, in coordination = with original> this WG, and in agreement with the WG chairs and responsible = ADs. original> However, no protocol work will be adopted by a working group = to original> address the identified use-cases until the requirements = document original> motivating the protocol work has been sent to the IESG for original> publication as an RFC. revised> The working group will initially produce = descriptions of=20 revised> use cases, and requirements to be addressed. Where there is = consensus revised> within the WG for these use cases to be solved (demonstrated = through revised> WG adoption, and/or agreement with the chairs and responsible = ADs), revised> architectural specifications and requirements for protocol = extensions=20 revised> will be developed. Where new protocol extensions are developed, = the revised> relevant working groups (e.g., IS-IS, OSPF, IDR, PCEP=85) will = develop revised> these, in conjunction with the WG. rjs> Not perfect, but maybe a reasonable starting point? r. >=20 >>>>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>>>=20 >>>>>> Hannes, >>>>>>=20 >>>>>> In case, we are using only directed forwarding (adjacency = segment), could we still talk about tunneling ? (it's a very very small = tunnel) >>>>>> Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>>>>=20 >>>>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the = MPLS instantiation is performing this using stacking ... >>>>>>=20 >>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>>>>=20 >>>>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>>>=20 >>>>>> Do we want in the charter to limit the scope to routing actions ? >>>>>>=20 >>>>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>>>=20 >>>>>> Regarding your charter proposal : >>>>>>=20 >>>>>> -------- >>>>>>=20 >>>>>> - They form a connected network >>>>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>>>=20 >>>>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>>>> [SLI] There is something else between SPT and Explicit path, you = can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>>>>=20 >>>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. >>>>>> [SLI] Security considerations may have to be addressed in the = charter , especially for the interAS case (trust yes, but not sure = access to everything may not be good) >>>>>>=20 >>>>>> Downstream routers within the ERD forward the packet as specified = by the router at the head-end of the path. >>>>>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> - The first goal of the STER WG is to identify use-cases for = ERDs. >>>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>>=20 >>>>>> [SLI] Agree, I would add : >>>>>> - defining the architecture framework >>>>>> - analysing the security considerisations >>>>>>=20 >>>>>>=20 >>>>>> --------- >>>>>>=20 >>>>>>=20 >>>>>> Here would be my proposal to extend yours : >>>>>>=20 >>>>>> A domain contains a set of routers with the = following characteristics: >>>>>>=20 >>>>>> - They form a connected network >>>>>> - They can forward traffic through any path within the network = using shortest path, non shortest path or explicit path >>>>>> - They may provide other types of services than forwarding and = they can enforce service actions in the path. >>>>>> - They share a common trust model. In this model, any router = within the domain can specify a path between itself and any other router = in the domain. It may then send any packet that passes through it = through any path that it has specified and that is conform to the = security rules. Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>>=20 >>>>>> The working group is chartered for the following ordered = list of work items: >>>>>>=20 >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. = However, no protocol work will be adopted by a working group to address = the ERD use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la part de Hannes Gredler >>>>>> Envoy=E9 : mardi 3 septembre 2013 18:31 >>>>>> =C0 : Loa Andersson >>>>>> Cc : status@ietf.org >>>>>> Objet : Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>> good point - what about this charter proposal ? >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> Stacked Tunnels for Explicit Routing (STER) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>>> A explicit routing domain (ERD) contains a set of routers with = the following characteristics: >>>>>>=20 >>>>>> - They form a connected network >>>>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. Downstream routers within the = ERD forward the packet as specified by the router at the head-end of the = path. >>>>>>=20 >>>>>> The STER working group is chartered for the following ordered = list of work items: >>>>>>=20 >>>>>> - The first goal of the STER WG is to identify use-cases for = ERDs. >>>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. = However, no protocol work will be adopted by a working group to address = the ERD use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> >>>>>>=20 >>>>>> /hannes >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>>=20 >>>>>>> Folks, >>>>>>>=20 >>>>>>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>>>>>> a charter proposal, if there is one please point me to it. >>>>>>>=20 >>>>>>> It seems a bit odd to put the cart (what the wg should do) = before the >>>>>>> horse (wg name). If we drill down the the charter first the wg = name >>>>>>> might be easier to figure out. >>>>>>>=20 >>>>>>> /Loa >>>>>>>=20 >>>>>>> PS >>>>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>>>=20 >>>>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>>>=20 >>>>>>>> Peter >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>>> Behalf Of stephane.litkowski@orange.com >>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>>> To: AshwoodsmithPeter >>>>>>>> Cc: status@ietf.org >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>>>=20 >>>>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>>>=20 >>>>>>>> In the other hand, I completely agree with your statement that = source >>>>>>>> routing is generic and dataplane agnostic, as segment routing = is ... >>>>>>>> (segment routing is not a new dataplane ...) >>>>>>>>=20 >>>>>>>> Now the definition of the WG naming must be inline with the = charter >>>>>>>> that will be defined ... (draft today) >>>>>>>>=20 >>>>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>>>=20 >>>>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>>>>=20 >>>>>>>> Do we want to standardize other technologies in this WG ? I = don't think so, based on Stewart's conclusion email from the BOF :"A new = WG focused solely on SR therefore needs to be create" >>>>>>>>=20 >>>>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>>>=20 >>>>>>>> If the WG is focused on SR, let's use a name in relation with = SR. >>>>>>>>=20 >>>>>>>> Feedback ? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Stephane >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI = Stephane DTF/DERX >>>>>>>> Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta = Maglione >>>>>>>> (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana = (aretana); >>>>>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: [Status] >>>>>>>> Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc = so my preference is to stick with this existing well known and data path = agnostic term. >>>>>>>>=20 >>>>>>>> Peter >>>>>>>>=20 >>>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> "Source routing" is just a subcase of segment routing ... as = it is for IP routing ... >>>>>>>>>=20 >>>>>>>>> Stephane >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] = De la >>>>>>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0= : Mark >>>>>>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); = John G. >>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; = status@ietf.org; >>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of = STATUS BOF >>>>>>>>> and the next steps >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>>>>=20 >>>>>>>>> Yours Irrespectively, >>>>>>>>>=20 >>>>>>>>> John >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: status-bounces@ietf.org = [mailto:status-bounces@ietf.org] On >>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>>> To: Victor Kuarsingh >>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian = Farrel; >>>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) >>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next = steps >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>>=20 >>>>>>>>>>> All, >>>>>>>>>>>=20 >>>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>>=20 >>>>>>>>>>> I note this since attempting to come up with an all = encompassing >>>>>>>>>>> acronym will be difficult and Segment Routing is generic = enough to >>>>>>>>>>> associate to multiple functions. >>>>>>>>>>=20 >>>>>>>>>> Then we can just use "segroute" for the short name. WGs do = not have >>>>>>>>>> to have acronyms, but they do need to have an 8-char limited = short >>>>>>>>>> name for the various automated tools not to break. >>>>>>>>>>=20 >>>>>>>>>> - Mark >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Victor K >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>>=20 >>>>>>>>>>>> Roberta >>>>>>>>>>>>=20 >>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The second task, which hopefully should be relatively = easy, is >>>>>>>>>>>>>> to find a better working name for the WG, since it has = been put >>>>>>>>>>>>>> to me a number of times that STATUS is going to be = confusing in >>>>>>>>>>>>>> text and a difficult search term. >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> status mailing list >>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>> = ____________________________________________________________________ >>>>>>>>> __ ___________________________________________________ >>>>>>>>>=20 >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et = le detruire ainsi que les pieces jointes. Les messages electroniques = etant susceptibles d'alteration, Orange decline toute responsabilite si = ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>=20 >>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> = _____________________________________________________________________ >>>>>>>> ____________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>>>>>> exploites ou copies sans autorisation. Si vous avez recu ce = message >>>>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>> Loa Andersson email: = loa@mail01.huawei.com >>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> = __________________________________________________________________________= _______________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>>>> they should not be distributed, used or copied without = authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From rjs@rob.sh Mon Sep 9 06:51:37 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A140C21F9CBD for ; Mon, 9 Sep 2013 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwFBfdH0sggW for ; Mon, 9 Sep 2013 06:51:28 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 0A25621F9A96 for ; Mon, 9 Sep 2013 06:49:02 -0700 (PDT) Received: from [130.208.20.117] (helo=epf-2013-h0117.rhnet.is) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VJ1ov-0005PP-ME; Mon, 09 Sep 2013 14:48:01 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Mon, 9 Sep 2013 13:48:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> To: Hannes Gredler X-Mailer: Apple Mail (2.1508) Cc: status@ietf.org, Robert Raszuk Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 13:51:38 -0000 Hannes, On 9 Sep 2013, at 12:13, Hannes Gredler wrote: > so what SR does wrt to TE is essentially shifting functionality = around > rather than solving it in any better way. As there has been significant effort to try and cover in the existing = drafts, there are two classes of explicit routing problems (~=3D = "traffic engineering" problems). 1) those that require admission control into resources, 2) those that require only placement away from the SPT, with no = admission control. With RSVP-TE we have to incur per-hop state for both cases - which means = we must also perform signalling per-LSP, and incur mid-point load during = re-signalling. This has real and practical problems which result in = RSVP-TE not being deployed or SPs restricting their RSVP-TE deployment's = scale. This, to me, is enough of a reason for us to determine that we'd = like to try and find something that would solve 2), where we can remove = the constraint on the # of LSPs. If we develop something akin to this, then we are not so much "moving = functionality around", but removing the need for the state which gives = us no value for LSP type 1) (no constraint is specified where the = mid-point would return a PathErr in RSVP-TE terms, so why do we keep it = anywhere?). For 1), we now have two choices, we can add the admission control = centrally, or we can do it in a distributed fashion. Different planning = approaches (for different organisations) will lend themselves to = different approaches being taken. I can foresee that some networks will = run RSVP-TE for 1) and IGP labels/SR LSPs for 2). Others will want = stricter control on the paths requiring 1), such that they will want = central computation instantiated in the data plane in the same manner as = those in 2). I don't see a reason to restrict these approaches being = available to operators such that they can make their own choices. Additionally, we should bear in mind that RSVP-TE itself is not a = panacea to centralised computation -- if we want to take consideration = of information that is not immediately visible to the head-end PEs then = we are likely to need ways that we can give each head-end device a hint = (e.g., ERO) to describe how to route services. Cheers, r. From akatlas@gmail.com Mon Sep 9 07:38:04 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B1521E81D9 for ; Mon, 9 Sep 2013 07:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOJwryqAc2dH for ; Mon, 9 Sep 2013 07:37:56 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E627321F9FED for ; Mon, 9 Sep 2013 07:26:41 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id es8so6041828obc.14 for ; Mon, 09 Sep 2013 07:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uVRVgWFZu9wp8vOmUIerczZQHodBeHewa2LaU9JiUr8=; b=ghlzj8VEKevl1MKdecaTl0M62Z6dhqnOXzHnm8/vT74H9FxPgJHhAFCdxsuAuB5M5o AyAur+zBHNxKWxBIhqhL4B+EjQwafWPfwT/POBKYIlVm+2lHFI+wqf43cmGMMur7DRyz F/Tm/2qkwj2TUdI6/CaFZP7e/vPeME8prQ5HnO12872tMm4hbyimvCjlXcUi7IpW2SXj uzcAxH4vQSK74jeqbtzeh7o7gxkZwqGTbqgZonbGOF78kz+P5ComFTMLlTT8SdhrTQmm 3k4IZljMQ0YCSU/heDh3fVrxCeHuJBqYsz0+1hp9+lvE9I5943pkRtNvUw+fhxcbdhQ9 cpWw== MIME-Version: 1.0 X-Received: by 10.60.117.198 with SMTP id kg6mr64230oeb.80.1378736801492; Mon, 09 Sep 2013 07:26:41 -0700 (PDT) Received: by 10.182.56.229 with HTTP; Mon, 9 Sep 2013 07:26:40 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 10:26:40 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7b3a99f84ab8fc04e5f42d1e Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:38:04 -0000 --047d7b3a99f84ab8fc04e5f42d1e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Monday, September 9, 2013, Robert Raszuk wrote: > > >>>> 5. FRR node-protection > >> > >> As you know computing LFA sort of addresses this topic pretty well. > > ^^^^^^^^^^^ > > > > no i don't - and for my own education would be really interested to lea= rn > > how to provide node-protection for 1-hop (per-adjacency) labels. > > Creating LFA bypass of each node with when required SR segment going > far enough that loops are guaranteed not to occur looks like pretty > easy exercise. > > Sorry I have no math prove that this will address any network > topology, but I also see no reason why it would not. [Alia] Robert, you are missing the problem. The end of each segment has the same egress and ingress protection problems that any LSP has. If a segment just describes the next interface or router, how is that router's failure protected against? > > >> Moreover SR may complete topologies where today LFA may not be > >> possible in 100% of coverage. > > > > i am afraid SR is still not there - > > Perfect topic for this WG to make it be there. Can we add this to the > charter ? > > Alia] I believe that all hop-by-hop fast-reroute techniques are in charte= r already for RTGWG. The need for arbitrarily long explicitly routed paths for complete coverage with the rLFA (PQ-tunnels approach) is part of why the approach was discarded in favor of not-via by its authors. That said, RTGWG is in the process of standardizing MRT-FRR, which provides 100% link and node protection in any topologies without risk of looping traffic. > trouble is that LFA is like "star wars" - there are many episodes =85 > > [Alia] A complete solution is preferable to the need for continuing episodes. Alia --047d7b3a99f84ab8fc04e5f42d1e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Monday, September 9, 2013, Robert Raszuk wrote:
>>>> 5. FRR node-protection
>>
>> As you know computing LFA sort of addresses this topic pretty well= .
> =A0^^^^^^^^^^^
>
> no i don't - and for my own education would be really interested t= o learn
> how to provide node-protection for 1-hop (per-adjacency) labels.

Creating LFA bypass of each node with when required SR segment going
far enough that loops are guaranteed not to occur looks like pretty
easy exercise.

Sorry I have no math prove that this will address any network
topology, but I also see no reason why it would not.

[Alia] Robert, you ar= e missing the problem. =A0The end of each segment has the same egress
and ingress=A0protection problems that any LSP has. =A0If a segment ju= st describes the next interface
or router, how is that router'= ;s failure protected against?

>> Moreover SR may complete topologies where today LFA may not be
>> possible in 100% of coverage.
>
> i am afraid SR is still not there -

Perfect topic for this WG to make it be there. Can we add this to the chart= er ?

Alia]=A0I believe that all hop-by-hop fast-reroute te= chniques are in charter already for RTGWG.
The need for arbitrari= ly long explicitly routed paths for complete coverage with the rLFA (PQ-tun= nels approach) is part of why the approach was discarded in favor of not-vi= a by its authors. =A0That said, RTGWG is in the process of standardizing MR= T-FRR, which provides 100% link and node protection in any topologies witho= ut risk of looping traffic.=A0

> trouble is that LFA is like "star wars" - there are many epi= sodes =85

[Alia] A complete solution is preferable= to the need for continuing episodes.=A0

Alia
--047d7b3a99f84ab8fc04e5f42d1e-- From rraszuk@gmail.com Mon Sep 9 07:50:28 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23C011E81C4 for ; Mon, 9 Sep 2013 07:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2abxCkWduypI for ; Mon, 9 Sep 2013 07:50:21 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5521F99E7 for ; Mon, 9 Sep 2013 07:41:57 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id u16so12756203iet.20 for ; Mon, 09 Sep 2013 07:41:56 -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=+prRe3Jp99m2vz+QLUZdR1pOUatVOAofIxO9j0S3AlU=; b=rUnooMq9/Lcn2rHgL/cmCvuJUaHV44GapTRDE42Bz/wmQ3FkVrD3hN1j5Okru5w3Zg qZhV/QyXgtx3WaSsgv6ZT7bGaClnn0pa42BISBz6g9ZEgth3u1WPS/CPs0El166EQKCp hICNzFe77r5Lrp9j+ms7j/zR2ZqbMb72Np4O1uu2tMoF5t6kJXOwy9Gsf/OF5dO0XQHE n/kIv1snIPWXugmUjD9UU6YRJi89JNCfD4Y009yWXUGWGbo8YHea8kLJHBf9SxQ2oLdn 5Yai8vjc6SQSmLzavhOz4IIHr31DIPjbPzTo/oD2OHyXmmDGeP3Q3I6sLfZ+aREcrULt ++Eg== MIME-Version: 1.0 X-Received: by 10.42.204.4 with SMTP id fk4mr9937372icb.31.1378737716811; Mon, 09 Sep 2013 07:41:56 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 9 Sep 2013 07:41:56 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 16:41:56 +0200 X-Google-Sender-Auth: LqBmcRb0lmVAiQcaUBCLCPdLBUs Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:50:28 -0000 Hi Alia, >> Creating LFA bypass of each node with when required SR segment going >> far enough that loops are guaranteed not to occur looks like pretty >> easy exercise. >> >> Sorry I have no math prove that this will address any network >> topology, but I also see no reason why it would not. > > [Alia] Robert, you are missing the problem. The end of each segment has the > same egress > and ingress protection problems that any LSP has. If a segment just > describes the next interface > or router, how is that router's failure protected against? Why is that difficult ? When I am a transit node and I am forwarding packets to the end of segment (egress) the awareness of egress being down (from directly connected detection protocol of your choice) I have ability to bypass the failed node with a fixup of removing the end of segment label/header from the packet's header. That way the failed egress is bypassed/protected as long as failure continues. The operation is local and uses to it's advantage the global (domain wide) property of repair paths. It in fact get's better as by looking at the next header the steering of the repair traffic can be made optimal. Contrary with labels of local significance such repair will not be possible without employing yet another signalling protocol and I see no good way to make it optimal at all. Regards, R. From akatlas@gmail.com Mon Sep 9 08:06:07 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D5721E8053 for ; Mon, 9 Sep 2013 08:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emJX2aRaic2n for ; Mon, 9 Sep 2013 08:05:59 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7492D11E8212 for ; Mon, 9 Sep 2013 07:56:47 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m6so6444008oag.4 for ; Mon, 09 Sep 2013 07:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E9ALkP07D8+vyEWZ20bTCY4JB7wNuBeG0AdHGfDe0b4=; b=lMiv7rCg0w1eCFKmghMicJS3XwfOAhFOYR58bMIgRHGycst9rtZdO5e+DatjLnESwR M2i5j2WfdJaMIXXCuFe11qL24K/gpBo3rA2Gnl7JhT1zsIExkByqjxKMdCMD94asZPNx kQTixrffUEt/zpDFKE15HS3ukGvE7dP7b/ZGdVDTjSeKmXpedYAU0PMok3Ug4V5o61O8 rCjR9bbl4WTPz4WpHI6uEmF2Jsx6d+pZxzddTjlGydPhSIeQ3MpYY6wmdbe3i4mKuU+/ G/4KaoK0WE8Zkbbnh/OVZHw3FXY6O+f54qpknNzyZlp3wmQxHj3GY5G37zjsFXV1aK9H xjwQ== MIME-Version: 1.0 X-Received: by 10.182.214.98 with SMTP id nz2mr11556696obc.37.1378738607000; Mon, 09 Sep 2013 07:56:47 -0700 (PDT) Received: by 10.182.56.229 with HTTP; Mon, 9 Sep 2013 07:56:46 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 10:56:46 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=e89a8ff1cefee8939504e5f4987a Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:06:07 -0000 --e89a8ff1cefee8939504e5f4987a Content-Type: text/plain; charset=ISO-8859-1 Hi Robert, On Monday, September 9, 2013, Robert Raszuk wrote: > Hi Alia, > > >> Creating LFA bypass of each node with when required SR segment going > >> far enough that loops are guaranteed not to occur looks like pretty > >> easy exercise. > >> > >> Sorry I have no math prove that this will address any network > >> topology, but I also see no reason why it would not. > > > > [Alia] Robert, you are missing the problem. The end of each segment has > the > > same egress > > and ingress protection problems that any LSP has. If a segment just > > describes the next interface > > or router, how is that router's failure protected against? > > Why is that difficult ? > > When I am a transit node and I am forwarding packets to the end of > segment (egress) the awareness of egress being down (from directly > connected detection protocol of your choice) I have ability to bypass > the failed node with a fixup of removing the end of segment > label/header from the packet's header. [Alia] It requires looking beyond the the top/current segment and understanding what is beneath. More than just that,it requires setting up the necessary different forwarding state for all possible combinations. Of course, if a segment points to an LSP or an algorithmically computed segment, the next-hop of that is not known by the router before the segment starts. So - to summarize - it requires a router to make forwarding decisions based on labels under the top of stack (if MPLS) or beyond the current pointer, it blows up the forwarding state needed, and the router may not know what the segment underneath means in terms of next-next hop(s). If only 1-hop segments are considered, the state expansion and added info to read are still needed. There are also the concerns about label stack expansion and MTU. Regards, Alia and > > That way the failed egress is bypassed/protected as long as failure > continues. The operation is local and uses to it's advantage the > global (domain wide) property of repair paths. It in fact get's better > as by looking at the next header the steering of the repair traffic > can be made optimal. > > Contrary with labels of local significance such repair will not be > possible without employing yet another signalling protocol and I see > no good way to make it optimal at all. > > Regards, > R. > --e89a8ff1cefee8939504e5f4987a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Robert,

On Monday, September 9, 2013, Robert Raszuk wrote:
Hi Alia,

>> Creating LFA bypass of each node with when required SR segment goi= ng
>> far enough that loops are guaranteed not to occur looks like prett= y
>> easy exercise.
>>
>> Sorry I have no math prove that this will address any network
>> topology, but I also see no reason why it would not.
>
> [Alia] Robert, you are missing the problem. =A0The end of each segment= has the
> same egress
> and ingress protection problems that any LSP has. =A0If a segment just=
> describes the next interface
> or router, how is that router's failure protected against?

Why is that difficult ?

When I am a transit node and I am forwarding packets to the end of
segment =A0(egress) the awareness of egress being down (from directly
connected detection protocol of your choice) I have ability to bypass
the failed node with a fixup of removing the end of segment
label/header from the packet's header.

= [Alia] It requires looking beyond the the top/current segment and understan= ding what
is beneath. =A0More than just that,it requires setting = up the necessary different forwarding
state for all possible combinations. =A0Of course, if a segment points= to an LSP or an algorithmically
computed segment, the next-hop o= f that is not known by the router before the segment starts.

So - to summarize - it requires a router to make forwarding deci= sions based on labels under the
top of stack (if MPLS) or beyond = the current pointer, it blows up the forwarding state needed, and
the router may not know what the segment underneath means in terms of = next-next hop(s).

If only 1-hop segments are consi= dered, the state expansion and added info to read are still needed.
There are also the concerns about label stack expansion and MTU.=

Regards,
Alia






and
That way the failed egress is bypassed/protected as long as failure
continues. The operation is local and uses to it's advantage the
global (domain wide) property of repair paths. It in fact get's better<= br> as by looking at the next header the steering of the repair traffic
can be made optimal.

Contrary with labels of local significance such repair will not be
possible without employing yet another signalling protocol and I see
no good way to make it optimal at all.

Regards,
R.
--e89a8ff1cefee8939504e5f4987a-- From rraszuk@gmail.com Mon Sep 9 08:18:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69DB21E81D5 for ; Mon, 9 Sep 2013 08:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jbPGpp-tnWn for ; Mon, 9 Sep 2013 08:18:17 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6021E81E6 for ; Mon, 9 Sep 2013 08:08:34 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id qa5so10577002ieb.4 for ; Mon, 09 Sep 2013 08:08: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=+Fbk9/Q1kSMzRoElIp8lK4ZKYMJsnX76UmS8jOh1KeY=; b=nSuN+6zw6nNlvLbSs/BlIDhlABa7v54YE8xVd8/8X3NhkNkntZ2rCIp2EvofZt0wxq DrWPXfhVmMlM/KhplxiHlCGNsrWVKwIAO7wL055ED788JNAWcvC6nNIduA9tsyZdEgN8 N3Scnq3gmw2Mj2RwYevfWoR3JFeMcjc9bzpH6J2iTeEXJKYLj7XvrFP2+kQyg0d/+ufC QJo92mSsOARBh9QkXbJvVYjvssuShJj8m2MqhftpKs3xLJYObLIeFWqvkjqhb2G0MYu2 5y1GZlf2FGtQpl1/df9ruazZ+gZp4h5SqBsOePBpUUf3X9Sqkg54ZIkQSMdnvmha91MP bMsg== MIME-Version: 1.0 X-Received: by 10.50.73.194 with SMTP id n2mr8354325igv.6.1378739313463; Mon, 09 Sep 2013 08:08:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 9 Sep 2013 08:08:33 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 17:08:33 +0200 X-Google-Sender-Auth: mMBftRINiMzK7LyKq6D0p0PRdtg Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:18:25 -0000 Please notice that if we assume IPv6 forwarding the IPv6 header will always contain destination IP address (most often BGP next hop in the overlay) and included extension headers will provide just hints for the segments. Therefor the complication you describe with MPLS based forwarding I see non existent with IP forwarding paradigm. As far as state explosion .. I easily see a lot of room for optimization as it will be very often the case that bypass can be shared by many destinations. Best regards, R. On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas wrote: > Hi Robert, > > > On Monday, September 9, 2013, Robert Raszuk wrote: >> >> Hi Alia, >> >> >> Creating LFA bypass of each node with when required SR segment going >> >> far enough that loops are guaranteed not to occur looks like pretty >> >> easy exercise. >> >> >> >> Sorry I have no math prove that this will address any network >> >> topology, but I also see no reason why it would not. >> > >> > [Alia] Robert, you are missing the problem. The end of each segment has >> > the >> > same egress >> > and ingress protection problems that any LSP has. If a segment just >> > describes the next interface >> > or router, how is that router's failure protected against? >> >> Why is that difficult ? >> >> When I am a transit node and I am forwarding packets to the end of >> segment (egress) the awareness of egress being down (from directly >> connected detection protocol of your choice) I have ability to bypass >> the failed node with a fixup of removing the end of segment >> label/header from the packet's header. > > > [Alia] It requires looking beyond the the top/current segment and > understanding what > is beneath. More than just that,it requires setting up the necessary > different forwarding > state for all possible combinations. Of course, if a segment points to an > LSP or an algorithmically > computed segment, the next-hop of that is not known by the router before the > segment starts. > > So - to summarize - it requires a router to make forwarding decisions based > on labels under the > top of stack (if MPLS) or beyond the current pointer, it blows up the > forwarding state needed, and > the router may not know what the segment underneath means in terms of > next-next hop(s). > > If only 1-hop segments are considered, the state expansion and added info to > read are still needed. > There are also the concerns about label stack expansion and MTU. > > Regards, > Alia > > > > > > > and >> >> That way the failed egress is bypassed/protected as long as failure >> continues. The operation is local and uses to it's advantage the >> global (domain wide) property of repair paths. It in fact get's better >> as by looking at the next header the steering of the repair traffic >> can be made optimal. >> >> Contrary with labels of local significance such repair will not be >> possible without employing yet another signalling protocol and I see >> no good way to make it optimal at all. >> >> Regards, >> R. From akatlas@gmail.com Mon Sep 9 08:47:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6E21F9D31 for ; Mon, 9 Sep 2013 08:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPQsnYROW5Ix for ; Mon, 9 Sep 2013 08:47:16 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB721F9EAF for ; Mon, 9 Sep 2013 08:31:40 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so2671791ieb.23 for ; Mon, 09 Sep 2013 08:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hhgm6h+KKtyoAwCaHac5iuUvZOmfdZWk4Yj/WCuGmTs=; b=nOUBdKaqCF0tZsVDWVn8aRgqUyU5Y09zMUspK0TtJ5XptgMCQK0+JFOah3L2V3Bfa3 0U2IIenGsqxHmCFPS269ElEK+yMYCBaC/UZSc9yGQHCJY7eI6+zb65ub8WFRZWjXTmuq YJrNFDMQxHYqy9p1DDX72Fb+UJfdNUw+7htAFh0aKQX6dLx7MbWTOY6OkkZdaCWPcO4E ULfE5C/fepJ8/mfjmWvzXrqWWIgtwZ9Bk0HUDTaWneyPbIKmcse7mgPQhLU61TaBlVL2 YN/XMYDX8NTGPR/B+/2w1GeMPZHm8qS1ttIOVS0XDXLZA5AeBbCIB8C4bm+pqOQeoZYi SwJQ== MIME-Version: 1.0 X-Received: by 10.50.120.104 with SMTP id lb8mr8557745igb.22.1378740699059; Mon, 09 Sep 2013 08:31:39 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Mon, 9 Sep 2013 08:31:38 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Mon, 9 Sep 2013 08:31:38 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 11:31:38 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7bd76bb29ae99004e5f515c5 Cc: Hannes Gredler , status@ietf.org Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:47:24 -0000 --047d7bd76bb29ae99004e5f515c5 Content-Type: text/plain; charset=ISO-8859-1 On Sep 9, 2013 11:08 AM, "Robert Raszuk" wrote: > > Please notice that if we assume IPv6 forwarding the IPv6 header will > always contain destination IP address (most often BGP next hop in the > overlay) and included extension headers will provide just hints for > the segments. > > Therefor the complication you describe with MPLS based forwarding I > see non existent with IP forwarding paradigm. [Alia] A strong desire doesn't make it so. First, in IPv6, if the segment info is just a hint, then ignoring it on failure could cause the traffic to loop unless you are also stripping the segment extensions. Second, if the router respects the segments, then this will still require reading ahead in the segment list - with all of the extra microcode and handling that implies. It doesn't violate the existing architecture only because that hasn't been fully defined. > As far as state explosion .. I easily see a lot of room for > optimization as it will be very often the case that bypass can be > shared by many destinations. Instead of 1 forwarding entry per neighbor, a router will need 1 for each neighbor's neighbor and that assumes label or segment manipulation doesn't need to be differentiated. This would only work for 1-hop globally understood segments - though with more computation, it might be possible for some algorithmically-based segments to be figured out. There are also the details around updating the segment list for fast-reroute and what impact that has. To be clear, IMHO, there are some interesting use-cases for segment-routing, but it also has limitations that need to be well-understood. We need to define the architecture clearly and the requirements and trade-offs. We can't just assume that it will all work. Alia > Best regards, > R. > > > > On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas wrote: > > Hi Robert, > > > > > > On Monday, September 9, 2013, Robert Raszuk wrote: > >> > >> Hi Alia, > >> > >> >> Creating LFA bypass of each node with when required SR segment going > >> >> far enough that loops are guaranteed not to occur looks like pretty > >> >> easy exercise. > >> >> > >> >> Sorry I have no math prove that this will address any network > >> >> topology, but I also see no reason why it would not. > >> > > >> > [Alia] Robert, you are missing the problem. The end of each segment has > >> > the > >> > same egress > >> > and ingress protection problems that any LSP has. If a segment just > >> > describes the next interface > >> > or router, how is that router's failure protected against? > >> > >> Why is that difficult ? > >> > >> When I am a transit node and I am forwarding packets to the end of > >> segment (egress) the awareness of egress being down (from directly > >> connected detection protocol of your choice) I have ability to bypass > >> the failed node with a fixup of removing the end of segment > >> label/header from the packet's header. > > > > > > [Alia] It requires looking beyond the the top/current segment and > > understanding what > > is beneath. More than just that,it requires setting up the necessary > > different forwarding > > state for all possible combinations. Of course, if a segment points to an > > LSP or an algorithmically > > computed segment, the next-hop of that is not known by the router before the > > segment starts. > > > > So - to summarize - it requires a router to make forwarding decisions based > > on labels under the > > top of stack (if MPLS) or beyond the current pointer, it blows up the > > forwarding state needed, and > > the router may not know what the segment underneath means in terms of > > next-next hop(s). > > > > If only 1-hop segments are considered, the state expansion and added info to > > read are still needed. > > There are also the concerns about label stack expansion and MTU. > > > > Regards, > > Alia > > > > > > > > > > > > > > and > >> > >> That way the failed egress is bypassed/protected as long as failure > >> continues. The operation is local and uses to it's advantage the > >> global (domain wide) property of repair paths. It in fact get's better > >> as by looking at the next header the steering of the repair traffic > >> can be made optimal. > >> > >> Contrary with labels of local significance such repair will not be > >> possible without employing yet another signalling protocol and I see > >> no good way to make it optimal at all. > >> > >> Regards, > >> R. --047d7bd76bb29ae99004e5f515c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 9, 2013 11:08 AM, "Robert Raszuk" <robert@raszuk.net> wrote:
>
> Please notice that if we assume IPv6 forwarding the IPv6 header will > always contain destination IP address (most often BGP next hop in the<= br> > overlay) and included extension headers will provide just hints for > the segments.
>
> Therefor the complication you describe with MPLS based forwarding I > see non existent with IP forwarding paradigm.

[Alia] A strong desire doesn't make it so.=A0=A0 First, = in IPv6, if the segment info is just a hint, then ignoring it on failure co= uld cause the traffic to loop unless you are also stripping the segment ext= ensions.=A0 Second, if the router respects the=A0 segments, then this will = still require reading ahead in the segment list - with all of the extra mic= rocode and handling that implies.=A0 It doesn't violate the existing ar= chitecture only because that hasn't been fully defined.

> As far as state explosion .. I easily see a lot of room= for
> optimization as it will be very often the case that bypass can be
> shared by many destinations.

Instead of 1 forwarding entry per neighbor, a router will ne= ed 1 for each neighbor's neighbor and that assumes label or segment man= ipulation doesn't need to be differentiated.

This would only work for 1-hop globally understood segments = - though with more computation, it might be possible for some algorithmical= ly-based segments to be figured out.

There are also the details around updating the segment list = for fast-reroute and what impact that has.

To be clear,=A0 IMHO,=A0 there are some interesting use-case= s for segment-routing, but it also has limitations that need to be well-und= erstood.=A0 We need to define the architecture clearly and the requirements= and trade-offs.=A0 We can't just assume that it will all work.

Alia

> Best regards,
> R.
>
>
>
> On Mon, Sep 9, 2013 at 4:56 PM, Alia Atlas <akatlas@gmail.com> wrote:
> > Hi Robert,
> >
> >
> > On Monday, September 9, 2013, Robert Raszuk wrote:
> >>
> >> Hi Alia,
> >>
> >> >> Creating LFA bypass of each node with when required = SR segment going
> >> >> far enough that loops are guaranteed not to occur lo= oks like pretty
> >> >> easy exercise.
> >> >>
> >> >> Sorry I have no math prove that this will address an= y network
> >> >> topology, but I also see no reason why it would not.=
> >> >
> >> > [Alia] Robert, you are missing the problem. =A0The end o= f each segment has
> >> > the
> >> > same egress
> >> > and ingress protection problems that any LSP has. =A0If = a segment just
> >> > describes the next interface
> >> > or router, how is that router's failure protected ag= ainst?
> >>
> >> Why is that difficult ?
> >>
> >> When I am a transit node and I am forwarding packets to the e= nd of
> >> segment =A0(egress) the awareness of egress being down (from = directly
> >> connected detection protocol of your choice) I have ability t= o bypass
> >> the failed node with a fixup of removing the end of segment > >> label/header from the packet's header.
> >
> >
> > [Alia] It requires looking beyond the the top/current segment and=
> > understanding what
> > is beneath. =A0More than just that,it requires setting up the nec= essary
> > different forwarding
> > state for all possible combinations. =A0Of course, if a segment p= oints to an
> > LSP or an algorithmically
> > computed segment, the next-hop of that is not known by the router= before the
> > segment starts.
> >
> > So - to summarize - it requires a router to make forwarding decis= ions based
> > on labels under the
> > top of stack (if MPLS) or beyond the current pointer, it blows up= the
> > forwarding state needed, and
> > the router may not know what the segment underneath means in term= s of
> > next-next hop(s).
> >
> > If only 1-hop segments are considered, the state expansion and ad= ded info to
> > read are still needed.
> > There are also the concerns about label stack expansion and MTU.<= br> > >
> > Regards,
> > Alia
> >
> >
> >
> >
> >
> >
> > and
> >>
> >> That way the failed egress is bypassed/protected as long as f= ailure
> >> continues. The operation is local and uses to it's advant= age the
> >> global (domain wide) property of repair paths. It in fact get= 's better
> >> as by looking at the next header the steering of the repair t= raffic
> >> can be made optimal.
> >>
> >> Contrary with labels of local significance such repair will n= ot be
> >> possible without employing yet another signalling protocol an= d I see
> >> no good way to make it optimal at all.
> >>
> >> Regards,
> >> R.

--047d7bd76bb29ae99004e5f515c5-- From stephane.litkowski@orange.com Mon Sep 9 09:14:52 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6270A21F99E1 for ; Mon, 9 Sep 2013 09:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4-ajheyGArV for ; Mon, 9 Sep 2013 09:14:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E956111E80F4 for ; Mon, 9 Sep 2013 08:51:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id CE87222C1B1; Mon, 9 Sep 2013 17:51:54 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id ABB6C35C045; Mon, 9 Sep 2013 17:51:54 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 9 Sep 2013 17:51:54 +0200 From: To: Alia Atlas , Robert Raszuk Date: Mon, 9 Sep 2013 17:51:52 +0200 Thread-Topic: [Status] Summary of STATUS BOF and the next steps Thread-Index: Ac6tbh6VeX9wWryHQk+dOIxKfJhRswABHhZw Message-ID: <29982_1378741914_522DEE9A_29982_5994_1_EEE55384044474429A926C625D0FCC81096327908E@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.9.120615 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:14:52 -0000 --_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think the discussion is moving to reviewing details rather than focusing = anymore on the charter ... :) Let's keep this discussion for the WG discuss= ion when it will exist and have a charter and a name :) Now regarding the points from the last long email exchanges : - I would also be in favor that interAS discussion must be part of the char= ter : intra-AS is first priority, but interAS is clearly needed : we have m= ultiple ASes that would be able to run SR, so interdomain SR discussion wou= ld be interresting for us. Use case of multiple internal ASes is interresti= ng, but dealing with Partners that are also running SR in their network is = interresting also (including security concerns). - I agree with Hannes point, that we are not here to say SR will replace th= is protocol or this protocol. We have some use case that must be addressed,= let's find a solution for these. If some people can replace totally LDP or= RSVP-TE in their network, it's good for them. If some other people are hap= py with what they have today and they want to keep RSVP-TE and LDP, it's fi= ne too ... Please just focus on the use case and solutions ... I agree that today SR, as its is defined now, may not be able to replace LD= P or RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is no= t a target ... Many networks, many different use case, many protocol usage = ! Let's keep a place for everyone :) - For FRR node protection, let's wait a couple of weeks/months to have the = WG starting ... we may probably find something new in this area ... so we = must not condamn SR today in this area ... it's just starting ... We must l= ist this as a use case, and then propose a solution ... Stephane ________________________________ De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la part de= Alia Atlas Envoy=E9 : lundi 9 septembre 2013 16:57 =C0 : Robert Raszuk Cc : Hannes Gredler; status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the next steps Hi Robert, On Monday, September 9, 2013, Robert Raszuk wrote: Hi Alia, >> Creating LFA bypass of each node with when required SR segment going >> far enough that loops are guaranteed not to occur looks like pretty >> easy exercise. >> >> Sorry I have no math prove that this will address any network >> topology, but I also see no reason why it would not. > > [Alia] Robert, you are missing the problem. The end of each segment has = the > same egress > and ingress protection problems that any LSP has. If a segment just > describes the next interface > or router, how is that router's failure protected against? Why is that difficult ? When I am a transit node and I am forwarding packets to the end of segment (egress) the awareness of egress being down (from directly connected detection protocol of your choice) I have ability to bypass the failed node with a fixup of removing the end of segment label/header from the packet's header. [Alia] It requires looking beyond the the top/current segment and understan= ding what is beneath. More than just that,it requires setting up the necessary diffe= rent forwarding state for all possible combinations. Of course, if a segment points to an = LSP or an algorithmically computed segment, the next-hop of that is not known by the router before th= e segment starts. So - to summarize - it requires a router to make forwarding decisions based= on labels under the top of stack (if MPLS) or beyond the current pointer, it blows up the forwa= rding state needed, and the router may not know what the segment underneath means in terms of next-= next hop(s). If only 1-hop segments are considered, the state expansion and added info t= o read are still needed. There are also the concerns about label stack expansion and MTU. Regards, Alia and That way the failed egress is bypassed/protected as long as failure continues. The operation is local and uses to it's advantage the global (domain wide) property of repair paths. It in fact get's better as by looking at the next header the steering of the repair traffic can be made optimal. Contrary with labels of local significance such repair will not be possible without employing yet another signalling protocol and I see no good way to make it optimal at all. Regards, R. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 think the discussion is moving to reviewing details rather than focusing an= ymore=20 on the charter ... :) Let's keep this discussion for the WG discussion when= it=20 will exist and have a charter and a name :)
 
Now regarding the points from the last long email exchanges=20 :
 
-=20 I would also be in favor that interAS discussion must be part of the charte= r :=20 intra-AS is first priority, but interAS is clearly needed : we have multipl= e=20 ASes that would be able to run SR, so interdomain SR discussion would = be=20 interresting for us. Use case of multiple internal ASes is interresting, bu= t=20 dealing with Partners that are also running SR in their network is interres= ting=20 also (including security concerns).
 
-=20 I agree with Hannes point, that we are not here to say SR will replace this= =20 protocol or this protocol. We have some use case that must be addressed, le= t's=20 find a solution for these. If some people can replace totally LDP or RSVP-T= E in=20 their network, it's good for them. If some other people are happy with what= they=20 have today and they want to keep RSVP-TE and LDP, it's fine too=20 ...
Please just focus on the use case and solutions ... =
I=20 agree that today SR, as its is defined now, may not be able to replace LDP = or=20 RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is not a t= arget=20 ... Many networks, many different use case, many protocol usage !=20 Let's keep a place for everyone :)
 
-=20 For FRR node protection, let's wait a couple of weeks/months to have the WG= =20 starting ...  we may probably find something new in this area ... so w= e=20 must not condamn SR today in this area ... it's just starting ... We must l= ist=20 this as a use case, and then propose a solution ...
 
 
 
Stephane
 <= /DIV>
 

De : status-bounces@ietf.org=20 [mailto:status-bounces@ietf.org] De la part de Alia=20 Atlas
Envoy=E9 : lundi 9 septembre 2013 16:57
=C0&nb= sp;:=20 Robert Raszuk
Cc : Hannes Gredler;=20 status@ietf.org
Objet : Re: [Status] Summary of STATUS BOF= and=20 the next steps

Hi Robert,

On Monday, September 9, 2013, Robert Raszuk= =20 wrote:
Hi=20 Alia,

>> Creating LFA bypass of each node with when requir= ed SR=20 segment going
>> far enough that loops are guaranteed not to o= ccur=20 looks like pretty
>> easy exercise.
>>
>> So= rry I=20 have no math prove that this will address any network
>> topol= ogy,=20 but I also see no reason why it would not.
>
> [Alia] Rober= t,=20 you are missing the problem.  The end of each segment has the
&= gt;=20 same egress
> and ingress protection problems that any LSP has.= =20  If a segment just
> describes the next interface
> or= =20 router, how is that router's failure protected against?

Why is t= hat=20 difficult ?

When I am a transit node and I am forwarding packets= to=20 the end of
segment  (egress) the awareness of egress being down= =20 (from directly
connected detection protocol of your choice) I have= =20 ability to bypass
the failed node with a fixup of removing the end o= f=20 segment
label/header from the packet's header.

[Alia] It requires looking beyond the the top/current segment and=20 understanding what
is beneath.  More than just that,it requires setting up the=20 necessary different forwarding
state for all possible combinations.  Of course, if a segment p= oints=20 to an LSP or an algorithmically
computed segment, the next-hop of that is not known by the router be= fore=20 the segment starts.

So - to summarize - it requires a router to make forwarding decision= s=20 based on labels under the
top of stack (if MPLS) or beyond the current pointer, it blows up th= e=20 forwarding state needed, and
the router may not know what the segment underneath means in terms o= f=20 next-next hop(s).

If only 1-hop segments are considered, the state expansion and added= info=20 to read are still needed.
There are also the concerns about label stack expansion and=20 MTU.

Regards,
Alia






and
That=20 way the failed egress is bypassed/protected as long as failure
conti= nues.=20 The operation is local and uses to it's advantage the
global (domain= =20 wide) property of repair paths. It in fact get's better
as by lookin= g at=20 the next header the steering of the repair traffic
can be made=20 optimal.

Contrary with labels of local significance such repair = will=20 not be
possible without employing yet another signalling protocol an= d I=20 see
no good way to make it optimal at=20 all.

Regards,
R.
____________=
___________________________________________________________________________=
__________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_EEE55384044474429A926C625D0FCC81096327908EPUEXCB2Fnante_-- From rraszuk@gmail.com Mon Sep 9 09:22:30 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4E621E81F2 for ; Mon, 9 Sep 2013 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4jSiKHLGi3y for ; Mon, 9 Sep 2013 09:22:30 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB621E8189 for ; Mon, 9 Sep 2013 08:44:23 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so13118981ieb.14 for ; Mon, 09 Sep 2013 08:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=foh/n+PMi4qjzoQOuOI5t04eL/L4dg9l037mfdBG/hE=; b=pSC7TkdG7u5P6NxO1l2ZMEymTvfCK8DeQBzAvOkQz7+FfpZzgvgqI7aaYFdJMlP869 6GFhQPDPK3n6cNMpiqlcXxzpNXXRznrcZ9RNCBTwszuzoZPjhxm5R9ND9iSwdhMRjWqC ik++DPQdOCW9AD0SNoshN6OYrqQ2DivD2HE+AvPz/LNMctu8qDE+WXdbx3+eRTWHJMJT cIYxlTaDkK5/WFlHv0xjzI7dDv8JnHotXiT3H7UwKv8zs+XBmeL0tUmWUFd0mqDLKtSD GGrguve4OTKnt9JCl3WdVwhJTR6TmCzLdXVrBlhBAk/1KwBFTc83IAkUz8skkljfVOAe q7pg== MIME-Version: 1.0 X-Received: by 10.50.73.194 with SMTP id n2mr8482756igv.6.1378741463043; Mon, 09 Sep 2013 08:44:23 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 9 Sep 2013 08:44:22 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 17:44:22 +0200 X-Google-Sender-Auth: v5254ybOg892DR4SBz2asxflT30 Message-ID: From: Robert Raszuk To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:22:30 -0000 > unless you are also stripping the segment extensions. Of course you should strip it. What's the point to keep it if you know the segment endpoint is down ? > router respects the segments, then this will still require reading ahead in > the segment list - with all of the extra microcode and handling that > implies. True. > Instead of 1 forwarding entry per neighbor, a router will need 1 for each > neighbor's neighbor and that assumes label or segment manipulation doesn't > need to be differentiated. Not really "neighbor's neighbor". At most to each segment end point, but again subject to grouping. > This would only work for 1-hop globally understood segments - though with > more computation, it might be possible for some algorithmically-based > segments to be figured out. I am not sure where "1-hop" limitation comes from. > To be clear, IMHO, there are some interesting use-cases for > segment-routing, but it also has limitations that need to be > well-understood. We need to define the architecture clearly and the > requirements and trade-offs. We can't just assume that it will all work. I fully agree. r. From akatlas@gmail.com Mon Sep 9 09:45:21 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B93021F9DB0 for ; Mon, 9 Sep 2013 09:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXedhh+HnDAR for ; Mon, 9 Sep 2013 09:45:09 -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 0AD0521F9DAF for ; Mon, 9 Sep 2013 09:45:07 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so13623790iec.27 for ; Mon, 09 Sep 2013 09:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MzEWcchAyRN9kSSLjYAgz2g1U0YItPl3aokM4V6cfAc=; b=XDj3DHOm1LwVkvDq22qLkYfOtBlamojAQF5Jhu29ay4mtMMEY9JgIQDt36mUOd1FHg uc1Nf0SOP5y36fGH5oAYLj3t03O9mAemMPBnGQdvaFQxyKYbhVW3P1acrBwqm2Gtk2xB EBDGjhBaE8W54M7s1VUus8PbuQXUBKQJBwudvD4YBw8L1OxvdDYl5pcvOC+ELRjcDUMG zTicZhY2y/W2QTOzW+1qj/HSnofKzzgf/+RihwfaiThmlE83bbghcSlNpoAzZbegT3kJ AKyDnnujh3fGO6R3e5q+LVjjusdaledw1ZYxTpEwSsWwiBhwBXHCGOqliwwVw1BUI59F NQ+g== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr8769391igb.36.1378745107572; Mon, 09 Sep 2013 09:45:07 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Mon, 9 Sep 2013 09:45:07 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> Date: Mon, 9 Sep 2013 12:45:07 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7b10cf0d5f6f4404e5f61c8f Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:45:21 -0000 --047d7b10cf0d5f6f4404e5f61c8f Content-Type: text/plain; charset=ISO-8859-1 Hi Robert, Here's my last message on this - because the key point is not really the details of how and at what cost this could be done, but that there can be architectural implications and the proper architecture and use-cases needs to be nailed down before the protocol aspects. On Mon, Sep 9, 2013 at 11:44 AM, Robert Raszuk wrote: > > unless you are also stripping the segment extensions. > > Of course you should strip it. What's the point to keep it if you know > the segment endpoint is down ? > [Alia] First, this would be stripping all the segment information from the IPv6 packet to ensure it doesn't loop again. I assume the alternate would be to move the context past the current segment to newly inserted segments for the alternate. Presumably, keeping the history of segments crossed is valuable for IPv6 or else the proposed IPv6 extensions wouldn't focus on that. > > router respects the segments, then this will still require reading > ahead in > > the segment list - with all of the extra microcode and handling that > > implies. > > True. > > > Instead of 1 forwarding entry per neighbor, a router will need 1 for each > > neighbor's neighbor and that assumes label or segment manipulation > doesn't > > need to be differentiated. > > Not really "neighbor's neighbor". At most to each segment end point, > but again subject to grouping. [Alia] No - EXACTLY to each neighbor's neighbor. For each segment that ends at a neighbor N, the traffic in that segment would need to be looked up (using MPLS terms) in the context of neighbor N and, having prepopulated what label to swap to, be forwarded to the appropriate neighbor X of N. The point is to protect the segment end-points. This would have to be done for protecting traffic going to every neighbor Y of N because N's advertised segments and whether traffic is using them is unknown. [Alia] An alternate, of course, is to advertise 1-hop+ segments where the segment says end at N but the next-next-hop should be X. That removes the need for context label space at the cost of additional flooding - and wouldn't work as well for algorithmically-based segments because of reflooding upon topology changes. > This would only work for 1-hop globally understood segments - though with > > more computation, it might be possible for some algorithmically-based > > segments to be figured out. > > I am not sure where "1-hop" limitation comes from. > [Alia] How does the router S know what its neighbor N meant by segment-id L in specific terms of the next-hop that N would forward the packet to? > > To be clear, IMHO, there are some interesting use-cases for > > segment-routing, but it also has limitations that need to be > > well-understood. We need to define the architecture clearly and the > > requirements and trade-offs. We can't just assume that it will all work. > > I fully agree. [Alia] For the charter discussion, that's the important part. I, personally, want to see the architecture and use-cases clearly written out (and there are some good starts) in a WG consensus process so that what is and isn't feasible would be well understood. Regards, Alia --047d7b10cf0d5f6f4404e5f61c8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Robert,

Here's my last message on this - because the key po= int is not really the details of how and at what cost this could be done, b= ut that there can be architectural implications and the proper architecture= and use-cases needs to be nailed down before the protocol aspects.

On Mon, Sep 9, 2013 at 11:44 AM, Robert Rasz= uk <robert@raszuk.net> wrote:
> unless you are also stripping the segment extensions= .

Of course you should strip it. What's the point to keep it if you= know
the segment endpoint is down ?

[Alia] F= irst, this would be stripping all the segment information from the IPv6 pac= ket to ensure it doesn't loop again. =A0I assume the alternate would be= to move the context past the current segment to newly inserted segments fo= r the alternate. =A0Presumably, keeping the history of segments crossed is = valuable for IPv6 or else the proposed IPv6 extensions wouldn't focus o= n that.
=A0
> router respects the =A0segments, then this will stil= l require reading ahead in
> the segment list - with all of the extra microcode and handling that > implies.

True.

> Instead of 1 forwarding entry per neighbor, a router will need 1 for e= ach
> neighbor's neighbor and that assumes label or segment manipulation= doesn't
> need to be differentiated.

Not really "neighbor's neighbor". At most to each segme= nt end point,
but again subject to grouping.
=A0
[Alia] No - E= XACTLY to each neighbor's neighbor. =A0For each segment that ends at a = neighbor N, the traffic in that segment would need to be looked up (using M= PLS terms) in the context of neighbor N and, having prepopulated what label= to swap to, be forwarded to the appropriate neighbor X of N. =A0 The point= is to protect the segment end-points. =A0This would have to be done for pr= otecting traffic going to every neighbor Y of N because N's advertised = segments and whether traffic is using them is unknown.

[Alia] An alternate, of course, is to advertise 1-hop+ = segments where the segment says end at N but the next-next-hop should be X.= =A0That removes the need for context label space at the cost of additional= flooding - and wouldn't work as well for algorithmically-based segment= s because of reflooding upon topology changes.

> This would only work for 1-hop globally understood segments - though w= ith
> more computation, it might be possible for some algorithmically-based<= br> > segments to be figured out.

I am not sure where "1-hop" limitation comes from.
[Alia] How does the router S know what its neighbor N meant by= segment-id L in specific terms of the next-hop that N would forward the pa= cket to?
=A0
> To be clear, =A0IMHO, =A0there are some interesting = use-cases for
> segment-routing, but it also has limitations that need to be
> well-understood. =A0We need to define the architecture clearly and the=
> requirements and trade-offs. =A0We can't just assume that it will = all work.

I fully agree.
=A0
[Alia] For the charter= discussion, that's the important part. =A0I, personally, want to see t= he architecture and use-cases clearly written out (and there are some good = starts) in a WG consensus process so that what is and isn't feasible wo= uld be well understood.

Regards,
Alia
--047d7b10cf0d5f6f4404e5f61c8f-- From akatlas@gmail.com Mon Sep 9 09:51:12 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385EE21F977A for ; Mon, 9 Sep 2013 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK-8ieaA0Buz for ; Mon, 9 Sep 2013 09:51:11 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 689DA21F9A64 for ; Mon, 9 Sep 2013 09:50:59 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so2936516ieb.23 for ; Mon, 09 Sep 2013 09:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pjDprmiDGI/v2SIjvjB/z1OIt8ArUgmR+w+et8uk0es=; b=WQ/GrYfc+Iv0CpKYOy2RvsPsFRY+6LmXs2r6loUUQcYb6RiYODJoy9je7CD/xvk6eT Hbg7q2krwxU9dejD8bXTgqYvRWvYBnXIW8VFCvu5yvuYwDUnBp3WrODqGv01qYlfmsS4 kAI80zIW2l0Am9Bu9qKCncpZ+OXP+JdIab5plDOrdl2UqD6B25BBTf363VfZMBZ5mcUW beIMd1ifSBpZAatPKJVnpZ0jCBiRpwdFlqAku08+uPwCSUu0IicCcFDKE435dy5mAGn0 0m/CPrhFN1YVU30p1Vw4j/G3K0mw/l4ZS2NS6mtReVKd0qnDIW3l+frh+aNVUZJ/5RPb pzrQ== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr8569415igh.5.1378745458996; Mon, 09 Sep 2013 09:50:58 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Mon, 9 Sep 2013 09:50:58 -0700 (PDT) In-Reply-To: <29982_1378741914_522DEE9A_29982_5994_1_EEE55384044474429A926C625D0FCC81096327908E@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> <29982_1378741914_522DEE9A_29982_5994_1_EEE55384044474429A926C625D0FCC81096327908E@PUEXCB2F.nanterre.francetelecom.fr> Date: Mon, 9 Sep 2013 12:50:58 -0400 Message-ID: From: Alia Atlas To: stephane.litkowski@orange.com Content-Type: multipart/alternative; boundary=047d7bdc9db251bce104e5f631ac Cc: Hannes Gredler , "status@ietf.org" , Robert Raszuk Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:51:12 -0000 --047d7bdc9db251bce104e5f631ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stephane, On Mon, Sep 9, 2013 at 11:51 AM, wrote: > ** > I think the discussion is moving to reviewing details rather than focusin= g > anymore on the charter ... :) Let's keep this discussion for the WG > discussion when it will exist and have a charter and a name :) > [Alia] Sure - that discussion was triggered by a claim that a limitation of SR isn't at all an issue. Given that one of the discussion points is how fast to just dive into protocol-extensions because all this architecture and use-cases isn't critical, I think it is important to consider some of the assumptions of capability and their implications. > Now regarding the points from the last long email exchanges : > > - I would also be in favor that interAS discussion must be part of the > charter : intra-AS is first priority, but interAS is clearly needed : we > have multiple ASes that would be able to run SR, so interdomain > SR discussion would be interresting for us. Use case of multiple internal > ASes is interresting, but dealing with Partners that are also running SR = in > their network is interresting also (including security concerns). > [Alia] This is useful to hear. > - I agree with Hannes point, that we are not here to say SR will replace > this protocol or this protocol. We have some use case that must be > addressed, let's find a solution for these. If some people can replace > totally LDP or RSVP-TE in their network, it's good for them. If some othe= r > people are happy with what they have today and they want to keep RSVP-TE > and LDP, it's fine too ... > Please just focus on the use case and solutions ... > I agree that today SR, as its is defined now, may not be able to replace > LDP or RSVP-TE depending of the use case. And replacing LDP and RSVP-TE i= s > not a target ... Many networks, many different use case, many protocol > usage ! Let's keep a place for everyone :) > > - For FRR node protection, let's wait a couple of weeks/months to have th= e > WG starting ... we may probably find something new in this area ... so w= e > must not condamn SR today in this area ... it's just starting ... We must > list this as a use case, and then propose a solution ... > [Alia] If we don't have an architecture that supports it, our options are less. Fully describing the use-case would be good. A strong motivation for RSVP-TE has been its good fast-reroute solutions - covering link, node, and SRLG. Regards, Alia > Stephane > > > > ------------------------------ > *De :* status-bounces@ietf.org [mailto:status-bounces@ietf.org] *De la > part de* Alia Atlas > *Envoy=E9 :* lundi 9 septembre 2013 16:57 > *=C0 :* Robert Raszuk > *Cc :* Hannes Gredler; status@ietf.org > > *Objet :* Re: [Status] Summary of STATUS BOF and the next steps > > Hi Robert, > > On Monday, September 9, 2013, Robert Raszuk wrote: > >> Hi Alia, >> >> >> Creating LFA bypass of each node with when required SR segment going >> >> far enough that loops are guaranteed not to occur looks like pretty >> >> easy exercise. >> >> >> >> Sorry I have no math prove that this will address any network >> >> topology, but I also see no reason why it would not. >> > >> > [Alia] Robert, you are missing the problem. The end of each segment >> has the >> > same egress >> > and ingress protection problems that any LSP has. If a segment just >> > describes the next interface >> > or router, how is that router's failure protected against? >> >> Why is that difficult ? >> >> When I am a transit node and I am forwarding packets to the end of >> segment (egress) the awareness of egress being down (from directly >> connected detection protocol of your choice) I have ability to bypass >> the failed node with a fixup of removing the end of segment >> label/header from the packet's header. > > > [Alia] It requires looking beyond the the top/current segment and > understanding what > is beneath. More than just that,it requires setting up the necessary > different forwarding > state for all possible combinations. Of course, if a segment points to a= n > LSP or an algorithmically > computed segment, the next-hop of that is not known by the router before > the segment starts. > > So - to summarize - it requires a router to make forwarding decisions > based on labels under the > top of stack (if MPLS) or beyond the current pointer, it blows up the > forwarding state needed, and > the router may not know what the segment underneath means in terms of > next-next hop(s). > > If only 1-hop segments are considered, the state expansion and added info > to read are still needed. > There are also the concerns about label stack expansion and MTU. > > Regards, > Alia > > > > > > > and >> >> That way the failed egress is bypassed/protected as long as failure >> continues. The operation is local and uses to it's advantage the >> global (domain wide) property of repair paths. It in fact get's better >> as by looking at the next header the steering of the repair traffic >> can be made optimal. >> >> Contrary with labels of local significance such repair will not be >> possible without employing yet another signalling protocol and I see >> no good way to make it optimal at all. >> >> Regards, >> R. >> > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --047d7bdc9db251bce104e5f631ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stephane,


On Mon, Sep 9, 2013 at 11:51 AM, <= ;stephan= e.litkowski@orange.com> wrote:
I=20 think the discussion is moving to reviewing details rather than focusing an= ymore=20 on the charter ... :) Let's keep this discussion for the WG discussion = when it=20 will exist and have a charter and a name :)

[Alia] Sure - that discussion was triggered by a= claim that a limitation of SR isn't at all an issue. =A0Given that one= of the discussion points is how fast to just dive into protocol-extensions= because all this architecture and use-cases isn't critical, I think it= is important to consider some of the assumptions of capability and their i= mplications. =A0=A0
=A0
=A0Now regarding the points from t= he last long email exchanges=20 :
= =A0
-=20 I would also be in favor that interAS discussion must be part of the charte= r :=20 intra-AS is first priority, but interAS is clearly needed : we have multipl= e=20 ASes that would be able to run SR, so interdomain SR=A0discussion would be= =20 interresting for us. Use case of multiple internal ASes is interresting, bu= t=20 dealing with Partners that are also running SR in their network is interres= ting=20 also (including security concerns).
<= div>
[Alia] This is useful to hear. =A0
=A0
= =A0-=20 I agree with Hannes point, that we are not here to say SR will replace this= =20 protocol or this protocol. We have some use case that must be addressed, le= t's=20 find a solution for these. If some people can replace totally LDP or RSVP-T= E in=20 their network, it's good for them. If some other people are happy with = what they=20 have today and they want to keep RSVP-TE and LDP, it's fine too=20 ...
Please just focu= s on the use case and solutions ...
I=20 agree that today SR, as its is defined now, may not be able to replace LDP = or=20 RSVP-TE depending of the use case. And replacing LDP and RSVP-TE is not a t= arget=20 ... Many networks, many different use case, many protocol usage !=20 Let's=A0keep a place for everyone :)
= =A0
-=20 For FRR node protection, let's wait a couple of weeks/months to have th= e WG=20 starting ...=A0 we may probably find something new in this area ... so we= =20 must not condamn SR today in this area ... it's just starting ... We mu= st list=20 this as a use case, and then propose a solution ...

[Alia] If we don't have an architect= ure that supports it, our options are less. =A0Fully describing the use-cas= e would be good. =A0A strong motivation for RSVP-TE has been its good fast-= reroute solutions - covering link, node, and SRLG.

Regards,
Alia
=A0
= =A0Stephane
=A0
= =A0

De=A0: status-bounces@ietf.org=20 [mailto:stat= us-bounces@ietf.org] De la part de Alia=20 Atlas
Envoy=E9=A0: lundi 9 septembre 2013 16:57
=C0=A0:=20 Robert Raszuk
Cc=A0: Hannes Gredler;=20 status@ietf.org<= div class=3D"im">
Objet=A0: Re: [Status] Summary of STATUS BOF an= d=20 the next steps

Hi Robert,

On Monday, September 9, 2013, Robert Raszuk= =20 wrote:
Hi=20 Alia,

>> Creating LFA bypass of each node with when requir= ed SR=20 segment going
>> far enough that loops are guaranteed not to o= ccur=20 looks like pretty
>> easy exercise.
>>
>> So= rry I=20 have no math prove that this will address any network
>> topol= ogy,=20 but I also see no reason why it would not.
>
> [Alia] Rober= t,=20 you are missing the problem. =A0The end of each segment has the
>= =20 same egress
> and ingress protection problems that any LSP has.= =20 =A0If a segment just
> describes the next interface
> or=20 router, how is that router's failure protected against?

Why = is that=20 difficult ?

When I am a transit node and I am forwarding packets= to=20 the end of
segment =A0(egress) the awareness of egress being down=20 (from directly
connected detection protocol of your choice) I have= =20 ability to bypass
the failed node with a fixup of removing the end o= f=20 segment
label/header from the packet's header.

[Alia] It requires looking beyond the the top/current segment and=20 understanding what
is beneath. =A0More than just that,it requires setting up the=20 necessary different forwarding
state for all possible combinations. =A0Of course, if a segment poin= ts=20 to an LSP or an algorithmically
computed segment, the next-hop of that is not known by the router be= fore=20 the segment starts.

So - to summarize - it requires a router to make forwarding decision= s=20 based on labels under the
top of stack (if MPLS) or beyond the current pointer, it blows up th= e=20 forwarding state needed, and
the router may not know what the segment underneath means in terms o= f=20 next-next hop(s).

If only 1-hop segments are considered, the state expansion and added= info=20 to read are still needed.
There are also the concerns about label stack expansion and=20 MTU.

Regards,
Alia






and
That=20 way the failed egress is bypassed/protected as long as failure
conti= nues.=20 The operation is local and uses to it's advantage the
global (do= main=20 wide) property of repair paths. It in fact get's better
as by lo= oking at=20 the next header the steering of the repair traffic
can be made=20 optimal.

Contrary with labels of local significance such repair = will=20 not be
possible without employing yet another signalling protocol an= d I=20 see
no good way to make it optimal at=20 all.

Regards,
R.
_________________________________________________________=
________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--047d7bdc9db251bce104e5f631ac-- From yakov@juniper.net Mon Sep 9 10:02:07 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0779411E81FA for ; Mon, 9 Sep 2013 10:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol45jbqW51iL for ; Mon, 9 Sep 2013 10:01:51 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0774611E8123 for ; Mon, 9 Sep 2013 10:01:35 -0700 (PDT) Received: from mail125-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 17:01:35 +0000 Received: from mail125-va3 (localhost [127.0.0.1]) by mail125-va3-R.bigfish.com (Postfix) with ESMTP id 226A38017D; Mon, 9 Sep 2013 17:01:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(z551bizec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail125-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail125-va3 (localhost.localdomain [127.0.0.1]) by mail125-va3 (MessageSwitch) id 1378746093675451_433; Mon, 9 Sep 2013 17:01:33 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.245]) by mail125-va3.bigfish.com (Postfix) with ESMTP id 9DE1518004C; Mon, 9 Sep 2013 17:01:33 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 17:01:33 +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; Mon, 9 Sep 2013 10:01:31 -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 r89H1SL31445; Mon, 9 Sep 2013 10:01:28 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201309091701.r89H1SL31445@magenta.juniper.net> To: Robert Raszuk In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> X-MH-In-Reply-To: Robert Raszuk message dated "Mon, 09 Sep 2013 13:03:55 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <47470.1378746088.1@juniper.net> Date: Mon, 9 Sep 2013 10:01:28 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:02:07 -0000 Robert, > > i haven't yet identified the code to be deleted, if SR is going > > to be a success ;-) > > How about LDP as starter ? > > Which of the below are solved by LDP ? Which LDP functionality will > not be covered by SR ? > > >> 1. LSP bandwidth reservation > >> 2. LSP preemption > >> 3. p2mp path construction > > Note that those are all done today in the control plane. Therefor it > seems pretty trivial to accomplish all of those with SR using number > of PCE or PCE like controllers rather then use RSVP-TE for explicit > path signalling. Since you claim that it is "pretty trivial to accompish all of those with SR..." please point to the document that describes how "trivial" it is to accomplish one of those items, namely p2mp path construction, with SR. Yakov. From yakov@juniper.net Mon Sep 9 10:20:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196E921F9A5B for ; Mon, 9 Sep 2013 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbwH5ZM3kuVd for ; Mon, 9 Sep 2013 10:20:12 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id 01CA121F9B5B for ; Mon, 9 Sep 2013 10:20:11 -0700 (PDT) Received: from mail22-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 17:20:10 +0000 Received: from mail22-db8 (localhost [127.0.0.1]) by mail22-db8-R.bigfish.com (Postfix) with ESMTP id BE427640073; Mon, 9 Sep 2013 17:20:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z551biz98dI1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h1155h) Received-SPF: pass (mail22-db8: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail22-db8 (localhost.localdomain [127.0.0.1]) by mail22-db8 (MessageSwitch) id 137874720965571_6874; Mon, 9 Sep 2013 17:20:09 +0000 (UTC) Received: from DB8EHSMHS026.bigfish.com (unknown [10.174.8.251]) by mail22-db8.bigfish.com (Postfix) with ESMTP id 01707480041; Mon, 9 Sep 2013 17:20:09 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by DB8EHSMHS026.bigfish.com (10.174.4.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 17:20:08 +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; Mon, 9 Sep 2013 10:20:06 -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 r89HK1L43920; Mon, 9 Sep 2013 10:20:02 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201309091720.r89HK1L43920@magenta.juniper.net> To: Rob Shakir In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> X-MH-In-Reply-To: Rob Shakir message dated "Mon, 09 Sep 2013 08:24:59 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <48178.1378747201.1@juniper.net> Date: Mon, 9 Sep 2013 10:20:01 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Hannes Gredler , "status@ietf.org" , stephane.litkowski@orange.com Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:20:17 -0000 Rob, > Hannes, > > In-line as rjs>. in-line... > On 6 Sep 2013, at 16:27, Hannes Gredler wrote: > > > hi stephane, > > > > here is a revised draft charter as per your comments. > > > > --- > > > > domain contains a set of routers with the following > > characteristics: > > > > - They form a connected network > > - They can forward traffic through any path within the network using > > shortest path, or any other (e.g., an explicit) path > > - They share a common trust model. In this model, any router within > > the domain can specify a path between itself and any other router > > in the domain. It may then send any packet that passes through it > > through any path that it has specified and that is conform to the > > security rules. Downstream routers along the path within the > > domain forward the packet as specified by the router at the head-end > > of the path. > > > > The working group is chartered for the following ordered > > list of work items: > > > > - The first goal of the WG is to identify use-cases. > > - The WG will then define the architecture framework associated with > > the security considerations. The architecture framework and security > > considerations must address the relations between domains (inter domain). rjs> It seems a little odd to me that we would identify that there are inter- rjs> domain issues to solve when there is no suggested use case that seemed rjs> to relate to this as a requirement. Any extensions of the technology rjs> developed within the WG to be inter-domain can be for future study. Please note that the above bullet about the security considerations and inter-domain has been taken verbatim from Stephane's proposal to extend Hannes' proposed charter. See http://www.ietf.org/mail-archive/web/status/current/msg00129.html. Yakov. From rraszuk@gmail.com Mon Sep 9 11:25:27 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AEB21E80AB for ; Mon, 9 Sep 2013 11:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJlhKtd1-T2C for ; Mon, 9 Sep 2013 11:25:26 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0E721E809A for ; Mon, 9 Sep 2013 11:25:26 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 16so2763395iea.30 for ; Mon, 09 Sep 2013 11:25:25 -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=DIaKtTRA7ChQHlV2hmt68PpNppdiUM1pk0v+wxdBX4g=; b=BlQnyl6SwTtBFC4NO5cRoYQ4ftbV5HSNioqOlMFFPmq47Ouwv1d362PGA02rltk02r nv4tAfyjshKwl51bYfHkmGUwxAGGM7H8hauqCa5GzGm38mUlG7j6tXo54idCSil/xcR3 TUnmXevzRviEgGVCz8JMrFiMuiK+bJSqbnqHNf59JeYw4h84286ae7nTTCMQ+MuxDd9u s6c8iGtyJS+ww9JbOaMuzUNQMxWE9aDyEFmuMd+/F14UBqmxIRO4zTFi+3U4QfjQpDVx TV09zwLoAUHJFJnyvi7wOq+YdUCXACLu9CFUqJpYGujIJ/YyZtYxVDxi+iot/bjy8bdl Jypw== MIME-Version: 1.0 X-Received: by 10.42.84.130 with SMTP id m2mr10301281icl.16.1378751125798; Mon, 09 Sep 2013 11:25:25 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 9 Sep 2013 11:25:25 -0700 (PDT) In-Reply-To: <201309091701.r89H1SL31445@magenta.juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <16443063-C950-42D5-8963-1E7C171F5608@juniper.net> <201309091701.r89H1SL31445@magenta.juniper.net> Date: Mon, 9 Sep 2013 20:25:25 +0200 X-Google-Sender-Auth: vQa3z2X9Xdw_lrbz21J2H_Ibhdg Message-ID: From: Robert Raszuk To: Yakov Rekhter Content-Type: text/plain; charset=ISO-8859-1 Cc: "status@ietf.org" Subject: Re: [Status] Summary of STATUS BOF and the next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:25:27 -0000 Hi Yakov, > please point to the document that describes how "trivial" > it is to accomplish one of those items, namely p2mp path > construction with SR. p2mp paths can be created in two ways: A. Via multicast routing protocol in distributed fashion (ex mLDP, PIM etc ...) B. Via controller programming replication points. My claim was referring to the latter where using (for example I2RS IETF protocol) replication points of segment X to segment Y, Z etc ... can be programmed from controller to network elements. Segment Routing is really helpful in this as notion of domain wide labels allows easy traffic mapping to segments and on a per segment base data plane traffic handling without any need for explicit path signalling. Note that this is not to say that I dismiss the need for former (point A) and as you noticed in subsequent email to Hannes I clearly made the distinction that mLDP is not something I would consider to be replaced. An interesting exercise could be undertaken to accomplish B with today's locally significant MPLS without SR. I think it is doable however it will require much more controller to network signalling as well as clearly additional data plane support on today's network equipment. Best regards, R. > On Mon, Sep 9, 2013 at 7:01 PM, Yakov Rekhter wrote: > Robert, > >> > i haven't yet identified the code to be deleted, if SR is going >> > to be a success ;-) >> >> How about LDP as starter ? >> >> Which of the below are solved by LDP ? Which LDP functionality will >> not be covered by SR ? >> >> >> 1. LSP bandwidth reservation >> >> 2. LSP preemption >> >> 3. p2mp path construction >> >> Note that those are all done today in the control plane. Therefor it >> seems pretty trivial to accomplish all of those with SR using number >> of PCE or PCE like controllers rather then use RSVP-TE for explicit >> path signalling. > > Since you claim that it is "pretty trivial to accompish all of those > with SR..." please point to the document that describes how "trivial" > it is to accomplish one of those items, namely p2mp path construction, > with SR. > > Yakov. > From stephane.litkowski@orange.com Tue Sep 10 01:50:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7341521F9D38 for ; Tue, 10 Sep 2013 01:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.331 X-Spam-Level: * X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zagf3aHJ6EZ9 for ; Tue, 10 Sep 2013 01:50:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8621F9D50 for ; Tue, 10 Sep 2013 01:50:09 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 2B37837433F; Tue, 10 Sep 2013 10:50:08 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 0FB4A384057; Tue, 10 Sep 2013 10:50:08 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 10 Sep 2013 10:50:07 +0200 From: To: Hannes Gredler , "Stefano Previdi (sprevidi)" Date: Tue, 10 Sep 2013 10:50:06 +0200 Thread-Topic: Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: Ac6rHgSJ52ZP2TArSt6Ka+fefqdPvwC390XQ Message-ID: <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> In-Reply-To: <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.63915 Cc: "status@ietf.org" Subject: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:50:17 -0000 Hi all, I'm creating a new mail topic because the "Summary of STATUS BOF ..." start= s to be unreadable :) Hannes and Stefano send to us two charter proposals that sounds good to me. The main difference between the two proposals is that Stefano propose a seg= ment bound to any type of instruction (forwarding, application or service b= ased) while Hannes is focusing on forwarding actions (which is the first pr= iority, and I think everybody agree on this). It would be interresting to have a feedback from the mailinglist on this sp= ecific point. IMHO, there is a strong interrest to explore the service actions bound to s= egment in a second step keeping forwarding as a priority. Apart of this problem, here is a merge try of the two good proposals (I'm p= utting '<>' on hot topics :) ) : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a network or= set of networks (interdomain) on any path (shortest, non shortest, explici= t, ). In this architecture, routers are sharing a common trust model and are form= ing a domain. Within this domain, a node can specify a path between itself and any destin= ation in the domain. . It may then send any packet that passes through it through any path that it= has specified and that is conform to the security rules. Downstream router= s along the path within the domain forward the packet as specifi= ed by the router at the head-end of the path. The architecture should support centralized and distributed path computatio= n. Work items : ------------------ The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between domains (interdomain). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations - Protocol extension requirements . Interoperability Report Protocol work may be carried out in this working group or in other working = groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordinat= ion with this WG, and in agreement with the WG chairs and responsible ADs. Hope it helps to progress on the definition. Stephane -----Message d'origine----- De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the next steps hi stephane, here is a revised draft charter as per your comments. --- domain contains a set of routers with the following characteristics: - They form a connected network - They can forward traffic through any path within the network using shortest path, or any other (e.g., an explicit) path - They share a common trust model. In this model, any router within the domain can specify a path between itself and any other router in the domain. It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the domain forward the packet as specified by the router at the head-end of the path. The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between domains (interdomain). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Protocol work may be carried out in this working group or in other working = groups responsible for the protocols, in coordination with this WG, and in = agreement with the WG chairs and responsible ADs. However, no protocol work will be adopted by a working group to address the= identified use-cases until the requirements document motivating the protoc= ol work has been sent to the IESG for publication as an RFC. --- /hannes On Sep 4, 2013, at 10:02 AM, wrote: > Hannes, > > In case, we are using only directed forwarding (adjacency segment), > could we still talk about tunneling ? (it's a very very small tunnel) Mor= eover talking about "stacking" is really dataplane agnostic (MPLS) ... > > In the proposed segment routing architectural concepts, segments are at t= he same "level" and pointer moves on the segment list, then the MPLS instan= tiation is performing this using stacking ... > > IMHO, if we use "Stacked Tunnels", we already talk about a chosen solutio= n and it's closing the door to something else ... > > Finally, about the "routing" word, routing is essentially a "forward" act= ion which may limit the scope of what we can do by using a segment list. Ac= tions associated with a segment could be something else than forwarding. > > Do we want in the charter to limit the scope to routing actions ? > > I have no solution today to propose for the naming, but I completely agre= e with Loa, to first focus on working on the charter, and define a clear sc= ope of the work and then the name will be easier to find. > > Regarding your charter proposal : > > -------- > > - They form a connected network > [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). > > - They can forward traffic through the shortest paths or paths other than= the shortest (the latter called explicitly routed paths, or explicit paths) > [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. > > - They share a common trust model. In this model, any router within the E= RD can specify an explicit path between itself and any other router in the = ERD. It can then send any packet that passes through it through any path th= at it has specified. > [SLI] Security considerations may have to be addressed in the > charter , especially for the interAS case (trust yes, but not sure > access to everything may not be good) > > Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. > [SLI] Yes, but any router in the middle may be able to change the end to = end explicit path. > > > > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > > [SLI] Agree, I would add : > - defining the architecture framework > - analysing the security considerisations > > > --------- > > > Here would be my proposal to extend yours : > > A domain contains a set of routers with the followi= ng characteristics: > > - They form a connected network > - They can forward traffic through any path within the network using > shortest path, non shortest path or explicit path > - They may provide other types of services than forwarding and they can e= nforce service actions in the path. > - They share a common trust model. In this model, any router within the d= omain can specify a path between itself and any other router in the domain.= It may then send any packet that passes through it through any path that i= t has specified and that is conform to the security rules. Downstream route= rs within the ERD forward the packet as specified by the router at the head= -end of the path. > > The working group is chartered for the following ordered list of w= ork items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with the = security considerations. The architecture framework and security considerat= ions must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will ide= ntify gaps between currently available technologies and use-case requiremen= ts. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. However, no protocol wo= rk will be adopted by a working group to address the ERD use-cases until th= e requirements document motivating the protocol work has been sent to the I= ESG for publication as an RFC. > > -----Message d'origine----- > De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la > part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa > Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS > BOF and the next steps > > good point - what about this charter proposal ? > > --- > > Stacked Tunnels for Explicit Routing (STER) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A explicit routing domain (ERD) contains a set of routers with the follow= ing characteristics: > > - They form a connected network > - They can forward traffic through the shortest paths or paths other > than the shortest (the latter called explicitly routed paths, or > explicit paths) > - They share a common trust model. In this model, any router within the E= RD can specify an explicit path between itself and any other router in the = ERD. It can then send any packet that passes through it through any path th= at it has specified. Downstream routers within the ERD forward the packet a= s specified by the router at the head-end of the path. > > The STER working group is chartered for the following ordered list of wor= k items: > > - The first goal of the STER WG is to identify use-cases for ERDs. > - Having identified use-cases, the WG will identify gaps between currentl= y available technologies and use-case requirements. > - The WG will then define requirements for extensions to existing protoco= ls or new protocols that address gaps that are identified. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. However, no protocol wo= rk will be adopted by a working group to address the ERD use-cases until th= e requirements document motivating the protocol work has been sent to the I= ESG for publication as an RFC. > > --- > > > > /hannes > > > On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: > >> Folks, >> >> Excuse me if I'm slightly out of the loop, but so far I have not seen >> a charter proposal, if there is one please point me to it. >> >> It seems a bit odd to put the cart (what the wg should do) before the >> horse (wg name). If we drill down the the charter first the wg name >> might be easier to figure out. >> >> /Loa >> >> PS >> OK I understand that the horse and cart analogy limps a bit :). >> >> >> >> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>> " If the WG charter is limited to source routing, how will we handle th= e "non source routing" use cases of segment routing ? In another working gr= oup ? So we will go back to the WG synchronization issue that has been rais= ed for this technology ..." >>> >>> That's why I suggested SRV2. We are revisiting source routing with new = concepts. More generic number/action behavior. >>> >>> Peter >>> >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of stephane.litkowski@orange.com >>> Sent: Tuesday, September 03, 2013 10:43 AM >>> To: AshwoodsmithPeter >>> Cc: status@ietf.org >>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>> >>> >>> There was a misunderstanding in my small comment :) so I will explain m= ore : >>> >>> In segment routing, you have more than basic source routing : segment r= outing is just associate a segment number to an action and then combine seg= ment as you want, yes you can do source routing, but you also can do more. >>> >>> In the other hand, I completely agree with your statement that >>> source routing is generic and dataplane agnostic, as segment routing is= ... >>> (segment routing is not a new dataplane ...) >>> >>> Now the definition of the WG naming must be inline with the charter >>> that will be defined ... (draft today) >>> >>> Based on the already existing consensus (at least for MPLS dataplane) b= rought up during Berlin STATUS BOF meeting, segment routing sounds to be a = good target candidate. >>> >>> So now, do we want to do more in the WG charter than just make progress= ing segment routing architecture and uses cases document and ensure coordin= ation for the standardization of this technology ? >>> >>> Do we want to standardize other technologies in this WG ? I don't think= so, based on Stewart's conclusion email from the BOF :"A new WG focused so= lely on SR therefore needs to be create" >>> >>> If the WG charter is limited to source routing, how will we handle the = "non source routing" use cases of segment routing ? In another working grou= p ? So we will go back to the WG synchronization issue that has been raised= for this technology ... >>> >>> If the WG is focused on SR, let's use a name in relation with SR. >>> >>> Feedback ? >>> >>> >>> Stephane >>> >>> >>> -----Message d'origine----- >>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; Roberta >>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>> [Status] Summary of STATUS BOF and the next steps >>> >>> The term "source routing" has been around for a very long time and is d= ata path agnostic. Its also the term used in the literature etc so my prefe= rence is to stick with this existing well known and data path agnostic term. >>> >>> Peter >>> >>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>> >>>> Hi, >>>> >>>> "Source routing" is just a subcase of segment routing ... as it is for= IP routing ... >>>> >>>> Stephane >>>> >>>> >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : Mark >>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>> BOF and the next steps >>>> >>>> Hi, >>>> >>>> What is this 'segment routing' silliness? The correct term is 'source= routing'. >>>> >>>> Yours Irrespectively, >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of Mark Townsley >>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>> To: Victor Kuarsingh >>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>> (stbryant) >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> >>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>> >>>>>> All, >>>>>> >>>>>> I would also favour "Segment Routing WG" as well. >>>>>> >>>>>> I note this since attempting to come up with an all encompassing >>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>> to associate to multiple functions. >>>>> >>>>> Then we can just use "segroute" for the short name. WGs do not >>>>> have to have acronyms, but they do need to have an 8-char limited >>>>> short name for the various automated tools not to break. >>>>> >>>>> - Mark >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Victor K >>>>>> >>>>>> >>>>>> >>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> +1 for Segment Routing WG >>>>>>> >>>>>>> Roberta >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Segment Routing WG >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The second task, which hopefully should be relatively easy, is >>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>> confusing in text and a difficult search term. >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> ___________________________________________________________________ >>>> _ __ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> >>> ____________________________________________________________________ >>> _ ____________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From rjs@rob.sh Tue Sep 10 02:05:07 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BBF21F9C0E for ; Tue, 10 Sep 2013 02:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=-1.790, BAYES_00=-2.599, FRT_INTEREST=3.579] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF3oPHcH0nzv for ; Tue, 10 Sep 2013 02:05:05 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 9581521F9BB1 for ; Tue, 10 Sep 2013 02:05:04 -0700 (PDT) Received: from [130.208.20.117] (helo=epf-2013-h0117.rhnet.is) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VJJri-0001fs-Kt; Tue, 10 Sep 2013 10:04:06 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> Date: Tue, 10 Sep 2013 09:04:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) Cc: Hannes Gredler , "status@ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:05:07 -0000 Hi Stephane, Thanks for this, looks good! Comments in-line marked rjs>. On 10 Sep 2013, at 08:50, wrote: > Hi all, >=20 > I'm creating a new mail topic because the "Summary of STATUS BOF ..." = starts to be unreadable :) >=20 > Hannes and Stefano send to us two charter proposals that sounds good = to me. >=20 > The main difference between the two proposals is that Stefano propose = a segment bound to any type of instruction (forwarding, application or = service based) while Hannes is focusing on forwarding actions (which is = the first priority, and I think everybody agree on this). rjs> Agreed -- I think it would be useful to allow definitions of = segments to identify different types of "service", since there appear to = be some use cases (e.g., the explicit exit selection case) which require = a segment type describing something that is not explicitly IGP-based. >=20 > It would be interresting to have a feedback from the mailinglist on = this specific point. >=20 > IMHO, there is a strong interrest to explore the service actions bound = to segment in a second step keeping forwarding as a priority. >=20 > Apart of this problem, here is a merge try of the two good proposals = (I'm putting '<>' on hot topics :) ) : >=20 >=20 > ------------------------------------------------------------------- > Name: > Charter: >=20 >=20 > Introduction > ------------ > The following use cases: > . Path computation based on awareness of utilization or performance > data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >=20 > have triggered work on the definition of new architecture and protocol = extensions allowing to combine well known shortest path based routing = paradigms with source/explicit routing methods. Some of these extensions = have been implemented already. >=20 >=20 > Objective > --------- >=20 > Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path (shortest, non = shortest, explicit, ). >=20 > In this architecture, routers are sharing a common trust model and are = forming a domain. > Within this domain, a node can specify a path between itself and any = destination in the domain. . rjs> To clarify here, we define that our domain is under a common trust = model (essentially, under common administrative control?), but then go = on to talk about inter-domain elsewhere. Can we perhaps clarify (by = defining a specific " domain" nomenclature) and say something = like: "In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers)." > It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >=20 > The architecture should support centralized and distributed path = computation. >=20 >=20 > Work items : > ------------------ >=20 > The working group is chartered for the following ordered = list of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains (inter = domain). rjs> And then here "networks forming the domain"? Thanks for the efforts, r. > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 >=20 > Documents : > ------------------ > . Use Cases > . Architecture including security considerations > - Protocol extension requirements > . Interoperability Report >=20 >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), = in coordination with this WG, and in agreement with the WG chairs and = responsible ADs. >=20 >=20 >=20 > Hope it helps to progress on the definition. >=20 >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : Hannes Gredler [mailto:hannes@juniper.net] > Envoy=E9 : vendredi 6 septembre 2013 18:27 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : status@ietf.org > Objet : Re: [Status] Summary of STATUS BOF and the next steps >=20 > hi stephane, >=20 > here is a revised draft charter as per your comments. >=20 > --- >=20 > domain contains a set of routers with the following > characteristics: >=20 > - They form a connected network > - They can forward traffic through any path within the network using > shortest path, or any other (e.g., an explicit) path > - They share a common trust model. In this model, any router within > the domain can specify a path between itself and any other router > in the domain. It may then send any packet that passes through it > through any path that it has specified and that is conform to the > security rules. Downstream routers along the path within the = > domain forward the packet as specified by the router at the head-end > of the path. >=20 > The working group is chartered for the following ordered = list of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains = (interdomain). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 > Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. > However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >=20 > --- >=20 > /hannes >=20 > On Sep 4, 2013, at 10:02 AM, = wrote: >=20 >> Hannes, >>=20 >> In case, we are using only directed forwarding (adjacency segment), >> could we still talk about tunneling ? (it's a very very small tunnel) = Moreover talking about "stacking" is really dataplane agnostic (MPLS) = ... >>=20 >> In the proposed segment routing architectural concepts, segments are = at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >>=20 >> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>=20 >> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment = list. Actions associated with a segment could be something else than = forwarding. >>=20 >> Do we want in the charter to limit the scope to routing actions ? >>=20 >> I have no solution today to propose for the naming, but I completely = agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>=20 >> Regarding your charter proposal : >>=20 >> -------- >>=20 >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>=20 >> - They can forward traffic through the shortest paths or paths other = than the shortest (the latter called explicitly routed paths, or = explicit paths) >> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>=20 >> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. >> [SLI] Security considerations may have to be addressed in the >> charter , especially for the interAS case (trust yes, but not sure >> access to everything may not be good) >>=20 >> Downstream routers within the ERD forward the packet as specified by = the router at the head-end of the path. >> [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >>=20 >>=20 >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>=20 >> [SLI] Agree, I would add : >> - defining the architecture framework >> - analysing the security considerisations >>=20 >>=20 >> --------- >>=20 >>=20 >> Here would be my proposal to extend yours : >>=20 >> A domain contains a set of routers with the = following characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, non shortest path or explicit path >> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the = domain. It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers within the ERD forward the packet as specified by the = router at the head-end of the path. >>=20 >> The working group is chartered for the following ordered list = of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with = the security considerations. The architecture framework and security = considerations must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case = requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>=20 >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : = Loa >> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >> BOF and the next steps >>=20 >> good point - what about this charter proposal ? >>=20 >> --- >>=20 >> Stacked Tunnels for Explicit Routing (STER) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through the shortest paths or paths other >> than the shortest (the latter called explicitly routed paths, or >> explicit paths) >> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router = in the ERD. It can then send any packet that passes through it through = any path that it has specified. Downstream routers within the ERD = forward the packet as specified by the router at the head-end of the = path. >>=20 >> The STER working group is chartered for the following ordered list of = work items: >>=20 >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>=20 >> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>=20 >> --- >>=20 >> >>=20 >> /hannes >>=20 >>=20 >> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>=20 >>> Folks, >>>=20 >>> Excuse me if I'm slightly out of the loop, but so far I have not = seen >>> a charter proposal, if there is one please point me to it. >>>=20 >>> It seems a bit odd to put the cart (what the wg should do) before = the >>> horse (wg name). If we drill down the the charter first the wg name >>> might be easier to figure out. >>>=20 >>> /Loa >>>=20 >>> PS >>> OK I understand that the horse and cart analogy limps a bit :). >>>=20 >>>=20 >>>=20 >>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>=20 >>>> That's why I suggested SRV2. We are revisiting source routing with = new concepts. More generic number/action behavior. >>>>=20 >>>> Peter >>>>=20 >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of stephane.litkowski@orange.com >>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>> To: AshwoodsmithPeter >>>> Cc: status@ietf.org >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>>=20 >>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>=20 >>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>=20 >>>> In the other hand, I completely agree with your statement that >>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>> (segment routing is not a new dataplane ...) >>>>=20 >>>> Now the definition of the WG naming must be inline with the charter >>>> that will be defined ... (draft today) >>>>=20 >>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>=20 >>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>=20 >>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG = focused solely on SR therefore needs to be create" >>>>=20 >>>> If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another = working group ? So we will go back to the WG synchronization issue that = has been raised for this technology ... >>>>=20 >>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>=20 >>>> Feedback ? >>>>=20 >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; = Roberta >>>> Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana >>>> (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>> [Status] Summary of STATUS BOF and the next steps >>>>=20 >>>> The term "source routing" has been around for a very long time and = is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path = agnostic term. >>>>=20 >>>> Peter >>>>=20 >>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>> part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : = Mark >>>>> Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John G. >>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>> BOF and the next steps >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>=20 >>>>> Yours Irrespectively, >>>>>=20 >>>>> John >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of Mark Townsley >>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>> To: Victor Kuarsingh >>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>> (stbryant) >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>=20 >>>>>>> I note this since attempting to come up with an all encompassing >>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>> to associate to multiple functions. >>>>>>=20 >>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>> short name for the various automated tools not to break. >>>>>>=20 >>>>>> - Mark >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Victor K >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> +1 for Segment Routing WG >>>>>>>>=20 >>>>>>>> Roberta >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> The second task, which hopefully should be relatively easy, = is >>>>>>>>>> to find a better working name for the WG, since it has been >>>>>>>>>> put to me a number of times that STATUS is going to be >>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = ___________________________________________________________________ >>>>> _ __ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> = ____________________________________________________________________ >>>> _ ____________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >>=20 >>=20 >=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From stephane.litkowski@orange.com Tue Sep 10 02:19:10 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7483B21E80A6 for ; Tue, 10 Sep 2013 02:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.158 X-Spam-Level: X-Spam-Status: No, score=-0.158 tagged_above=-999 required=5 tests=[AWL=-1.489, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuyJZLJvif0z for ; Tue, 10 Sep 2013 02:19:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4D011E810B for ; Tue, 10 Sep 2013 02:19:02 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3C51022C0DF; Tue, 10 Sep 2013 11:19:01 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1DAE135C048; Tue, 10 Sep 2013 11:19:01 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 10 Sep 2013 11:19:00 +0200 From: To: Rob Shakir Date: Tue, 10 Sep 2013 11:19:00 +0200 Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: Ac6uBNbrkBRLBSV9S6y8pktOp3jZcQAAQGew Message-ID: <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> In-Reply-To: <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.90030 Cc: Hannes Gredler , "status@ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:19:11 -0000 Souns good to me, (adding OAM also) New recap : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a network or= set of networks (interdomain) on any path. In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node = to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-sh= ortest, explicit or based on other characteristics specified by segment ide= ntifiers). It may then send any packet that passes through it through any path that it= has specified and that is conform to the security rules. Downstream router= s along the path within the domain forward the packet as specifi= ed by the router at the head-end of the path. The architecture should support centralized and distributed path computatio= n. The architecture should support OAM functions. Work items : ------------------ The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations - Protocol extension requirements . Interoperability Report Protocol work may be carried out in this working group or in other working = groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordinat= ion with this WG, and in agreement with the WG chairs and responsible ADs. -----Message d'origine----- De : Rob Shakir [mailto:rjs@rob.sh] Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try t= o merge ... Hi Stephane, Thanks for this, looks good! Comments in-line marked rjs>. On 10 Sep 2013, at 08:50, wrote: > Hi all, > > I'm creating a new mail topic because the "Summary of STATUS BOF ..." > starts to be unreadable :) > > Hannes and Stefano send to us two charter proposals that sounds good to m= e. > > The main difference between the two proposals is that Stefano propose a s= egment bound to any type of instruction (forwarding, application or service= based) while Hannes is focusing on forwarding actions (which is the first = priority, and I think everybody agree on this). rjs> Agreed -- I think it would be useful to allow definitions of segments = to identify different types of "service", since there appear to be some use= cases (e.g., the explicit exit selection case) which require a segment typ= e describing something that is not explicitly IGP-based. > > It would be interresting to have a feedback from the mailinglist on this = specific point. > > IMHO, there is a strong interrest to explore the service actions bound to= segment in a second step keeping forwarding as a priority. > > Apart of this problem, here is a merge try of the two good proposals (I'm= putting '<>' on hot topics :) ) : > > > ------------------------------------------------------------------- > Name: > Charter: > > > Introduction > ------------ > The following use cases: > . Path computation based on awareness of utilization or performance > data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. > > have triggered work on the definition of new architecture and protocol ex= tensions allowing to combine well known shortest path based routing paradig= ms with source/explicit routing methods. Some of these extensions have been= implemented already. > > > Objective > --------- > > Define an architecture where a node can steer a packet through a network = or set of networks (interdomain) on any path (shortest, non shortest, expli= cit, ). > > In this architecture, routers are sharing a common trust model and are fo= rming a domain. > Within this domain, a node can specify a path between itself and any dest= ination in the domain. . rjs> To clarify here, we define that our domain is under a common trust mod= el (essentially, under common administrative control?), but then go on to t= alk about inter-domain elsewhere. Can we perhaps clarify (by defining a spe= cific " domain" nomenclature) and say something like: "In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node= to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-s= hortest, explicit or based on other characteristics specified by segment id= entifiers)." > It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream rout= ers along the path within the domain forward the packet as speci= fied by the router at the head-end of the path. > > The architecture should support centralized and distributed path computat= ion. > > > Work items : > ------------------ > > The working group is chartered for the following ordered list = of work items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains (inter domain). rjs> And then here "networks forming the domain"? Thanks for the efforts, r. > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. > > > Documents : > ------------------ > . Use Cases > . Architecture including security considerations > - Protocol extension requirements > . Interoperability Report > > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordin= ation with this WG, and in agreement with the WG chairs and responsible ADs. > > > > Hope it helps to progress on the definition. > > > Stephane > > > -----Message d'origine----- > De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi 6 > septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : > status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the > next steps > > hi stephane, > > here is a revised draft charter as per your comments. > > --- > > domain contains a set of routers with the following > characteristics: > > - They form a connected network > - They can forward traffic through any path within the network using > shortest path, or any other (e.g., an explicit) path > - They share a common trust model. In this model, any router within > the domain can specify a path between itself and any other router in > the domain. It may then send any packet that passes through it > through any path that it has specified and that is conform to the > security rules. Downstream routers along the path within the > domain forward the packet as specified by the router at > the head-end of the path. > > The working group is chartered for the following ordered list = of work items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between domains (interdomain). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols, in coordination with this WG, and i= n agreement with the WG chairs and responsible ADs. > However, no protocol work will be adopted by a working group to address t= he identified use-cases until the requirements document motivating the prot= ocol work has been sent to the IESG for publication as an RFC. > > --- > > /hannes > > On Sep 4, 2013, at 10:02 AM, wrote: > >> Hannes, >> >> In case, we are using only directed forwarding (adjacency segment), >> could we still talk about tunneling ? (it's a very very small tunnel) Mo= reover talking about "stacking" is really dataplane agnostic (MPLS) ... >> >> In the proposed segment routing architectural concepts, segments are at = the same "level" and pointer moves on the segment list, then the MPLS insta= ntiation is performing this using stacking ... >> >> IMHO, if we use "Stacked Tunnels", we already talk about a chosen soluti= on and it's closing the door to something else ... >> >> Finally, about the "routing" word, routing is essentially a "forward" ac= tion which may limit the scope of what we can do by using a segment list. A= ctions associated with a segment could be something else than forwarding. >> >> Do we want in the charter to limit the scope to routing actions ? >> >> I have no solution today to propose for the naming, but I completely agr= ee with Loa, to first focus on working on the charter, and define a clear s= cope of the work and then the name will be easier to find. >> >> Regarding your charter proposal : >> >> -------- >> >> - They form a connected network >> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >> >> - They can forward traffic through the shortest paths or paths other tha= n the shortest (the latter called explicitly routed paths, or explicit path= s) >> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >> >> - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in the= ERD. It can then send any packet that passes through it through any path t= hat it has specified. >> [SLI] Security considerations may have to be addressed in the >> charter , especially for the interAS case (trust yes, but not sure >> access to everything may not be good) >> >> Downstream routers within the ERD forward the packet as specified by the= router at the head-end of the path. >> [SLI] Yes, but any router in the middle may be able to change the end to= end explicit path. >> >> >> >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between current= ly available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> >> [SLI] Agree, I would add : >> - defining the architecture framework >> - analysing the security considerisations >> >> >> --------- >> >> >> Here would be my proposal to extend yours : >> >> A domain contains a set of routers with the follow= ing characteristics: >> >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, non shortest path or explicit path >> - They may provide other types of services than forwarding and they can = enforce service actions in the path. >> - They share a common trust model. In this model, any router within the = domain can specify a path between itself and any other router in the domain= . It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream rout= ers within the ERD forward the packet as specified by the router at the hea= d-end of the path. >> >> The working group is chartered for the following ordered list of = work items: >> >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with the= security considerations. The architecture framework and security considera= tions must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will id= entify gaps between currently available technologies and use-case requireme= nts. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. However, no protocol w= ork will be adopted by a working group to address the ERD use-cases until t= he requirements document motivating the protocol work has been sent to the = IESG for publication as an RFC. >> >> -----Message d'origine----- >> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa >> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >> BOF and the next steps >> >> good point - what about this charter proposal ? >> >> --- >> >> Stacked Tunnels for Explicit Routing (STER) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> A explicit routing domain (ERD) contains a set of routers with the follo= wing characteristics: >> >> - They form a connected network >> - They can forward traffic through the shortest paths or paths other >> than the shortest (the latter called explicitly routed paths, or >> explicit paths) >> - They share a common trust model. In this model, any router within the = ERD can specify an explicit path between itself and any other router in the= ERD. It can then send any packet that passes through it through any path t= hat it has specified. Downstream routers within the ERD forward the packet = as specified by the router at the head-end of the path. >> >> The STER working group is chartered for the following ordered list of wo= rk items: >> >> - The first goal of the STER WG is to identify use-cases for ERDs. >> - Having identified use-cases, the WG will identify gaps between current= ly available technologies and use-case requirements. >> - The WG will then define requirements for extensions to existing protoc= ols or new protocols that address gaps that are identified. >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. However, no protocol w= ork will be adopted by a working group to address the ERD use-cases until t= he requirements document motivating the protocol work has been sent to the = IESG for publication as an RFC. >> >> --- >> >> >> >> /hannes >> >> >> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >> >>> Folks, >>> >>> Excuse me if I'm slightly out of the loop, but so far I have not >>> seen a charter proposal, if there is one please point me to it. >>> >>> It seems a bit odd to put the cart (what the wg should do) before >>> the horse (wg name). If we drill down the the charter first the wg >>> name might be easier to figure out. >>> >>> /Loa >>> >>> PS >>> OK I understand that the horse and cart analogy limps a bit :). >>> >>> >>> >>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>> " If the WG charter is limited to source routing, how will we handle t= he "non source routing" use cases of segment routing ? In another working g= roup ? So we will go back to the WG synchronization issue that has been rai= sed for this technology ..." >>>> >>>> That's why I suggested SRV2. We are revisiting source routing with new= concepts. More generic number/action behavior. >>>> >>>> Peter >>>> >>>> -----Original Message----- >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>> Behalf Of stephane.litkowski@orange.com >>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>> To: AshwoodsmithPeter >>>> Cc: status@ietf.org >>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>> >>>> >>>> There was a misunderstanding in my small comment :) so I will explain = more : >>>> >>>> In segment routing, you have more than basic source routing : segment = routing is just associate a segment number to an action and then combine se= gment as you want, yes you can do source routing, but you also can do more. >>>> >>>> In the other hand, I completely agree with your statement that >>>> source routing is generic and dataplane agnostic, as segment routing i= s ... >>>> (segment routing is not a new dataplane ...) >>>> >>>> Now the definition of the WG naming must be inline with the charter >>>> that will be defined ... (draft today) >>>> >>>> Based on the already existing consensus (at least for MPLS dataplane) = brought up during Berlin STATUS BOF meeting, segment routing sounds to be a= good target candidate. >>>> >>>> So now, do we want to do more in the WG charter than just make progres= sing segment routing architecture and uses cases document and ensure coordi= nation for the standardization of this technology ? >>>> >>>> Do we want to standardize other technologies in this WG ? I don't thin= k so, based on Stewart's conclusion email from the BOF :"A new WG focused s= olely on SR therefore needs to be create" >>>> >>>> If the WG charter is limited to source routing, how will we handle the= "non source routing" use cases of segment routing ? In another working gro= up ? So we will go back to the WG synchronization issue that has been raise= d for this technology ... >>>> >>>> If the WG is focused on SR, let's use a name in relation with SR. >>>> >>>> Feedback ? >>>> >>>> >>>> Stephane >>>> >>>> >>>> -----Message d'origine----- >>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : R= e: >>>> [Status] Summary of STATUS BOF and the next steps >>>> >>>> The term "source routing" has been around for a very long time and is = data path agnostic. Its also the term used in the literature etc so my pref= erence is to stick with this existing well known and data path agnostic ter= m. >>>> >>>> Peter >>>> >>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>> >>>>> Hi, >>>>> >>>>> "Source routing" is just a subcase of segment routing ... as it is fo= r IP routing ... >>>>> >>>>> Stephane >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : >>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John = G. >>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>> BOF and the next steps >>>>> >>>>> Hi, >>>>> >>>>> What is this 'segment routing' silliness? The correct term is 'sourc= e routing'. >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of Mark Townsley >>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>> To: Victor Kuarsingh >>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>> (stbryant) >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>> >>>>>> >>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>> >>>>>>> I note this since attempting to come up with an all encompassing >>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>> to associate to multiple functions. >>>>>> >>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>> short name for the various automated tools not to break. >>>>>> >>>>>> - Mark >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Victor K >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> +1 for Segment Routing WG >>>>>>>> >>>>>>>> Roberta >>>>>>>> >>>>>>>> Sent from my iPad >>>>>>>> >>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Segment Routing WG >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> The second task, which hopefully should be relatively easy, >>>>>>>>>> is to find a better working name for the WG, since it has >>>>>>>>>> been put to me a number of times that STATUS is going to be >>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> __________________________________________________________________ >>>>> _ _ __ ___________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> ___________________________________________________________________ >>>> _ _ ____________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >>> >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> >> > > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From Ruediger.Geib@telekom.de Tue Sep 10 02:48:45 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E4721E80A3 for ; Tue, 10 Sep 2013 02:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g55wjB15kC+I for ; Tue, 10 Sep 2013 02:48:40 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1E33621F99F3 for ; Tue, 10 Sep 2013 02:48:39 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 10 Sep 2013 11:48:37 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 10 Sep 2013 11:48:37 +0200 From: To: Date: Tue, 10 Sep 2013 11:48:36 +0200 Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: Ac6uBNbrkBRLBSV9S6y8pktOp3jZcQAAQGewAABIa/A= Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:48:45 -0000 Hi Stephane, thanks for your proposal. Three remarks marked [RG] in line. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= stephane.litkowski@orange.com Sent: Tuesday, September 10, 2013 11:19 AM To: Rob Shakir Cc: Hannes Gredler; status@ietf.org; Stefano Previdi (sprevidi) Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try = to merge ... Souns good to me, (adding OAM also) New recap : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol extensions allowing to combine well known shortest path based routing paradigms with source/explicit routing methods. Some of these extensions have been implemented already. Objective --------- Define an architecture where a node can steer a packet through a network or set of networks (interdomain) on any path. In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-shortest, explicit or based on other characteristics specified by segment identifiers). It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the domain forward the packet as specified by the router at the head-end of the path. [RG] may be nit picking: to avoid the interpretation, that downstream routers have to contact the head-end router to get specific routing instructions.: ..forward the packet by the address stack inserted by the router at the head-end... The architecture should support centralized and distributed path computation. The architecture should support OAM functions. Work items : ------------------ The working group is chartered for the following ordered list = of work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations . Protocol extension requirements . Interoperability Report Protocol work may be carried out in this working group or in other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordination with this WG, and in agreement with the WG chairs and responsible ADs. [RG] Would the following be better: Required protocol extensions are carried out in working groups responsible...(). Work on new protocols may be carried out by the WG ... [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS forwarding plane, at least in the first phase. That should be part of the charter. We could re-charter, should this result in a deadlock later. From stephane.litkowski@orange.com Tue Sep 10 03:03:57 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7C021E8142 for ; Tue, 10 Sep 2013 03:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=1.790, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4+ISp3ljE86 for ; Tue, 10 Sep 2013 03:03:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D121E813D for ; Tue, 10 Sep 2013 03:03:51 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 32393C01DF; Tue, 10 Sep 2013 12:03:47 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 147C018004B; Tue, 10 Sep 2013 12:03:47 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 10 Sep 2013 12:03:46 +0200 From: To: "Ruediger.Geib@telekom.de" Date: Tue, 10 Sep 2013 12:03:46 +0200 Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: Ac6uBNbrkBRLBSV9S6y8pktOp3jZcQAAQGewAABIa/AAATPeoA== Message-ID: <4140_1378807427_522EEE83_4140_2750_1_EEE55384044474429A926C625D0FCC810964DEC4FF@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.91515 Cc: "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 10:03:57 -0000 [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS = forwarding plane, at least in the first phase. That should be part of the c= harter. We could re-charter, should this result in a deadlock later. [SLI] Agree also [RG] may be nit picking: to avoid the interpretation, that downstream route= rs have to contact the head-end router to get specific routing instructions.: ..forward the packet by the address stack inserted by the router at the hea= d-end... [SLI] Changed by :=20 "forward the packet by using the informations inserted by the router at th= e head-end" ---------------------------- Here is updated proposal : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a network or= set of networks (interdomain) on any path. In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node = to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-sh= ortest, explicit or based on other characteristics specified by segment ide= ntifiers). It may then send any packet that passes through it through any path that it= has specified and that is conform to the security rules. Downstream router= s along the path within the domain forward the packet by using t= he informations inserted by the router at the head-end The architecture should support centralized and distributed path computatio= n. The architecture should support OAM functions. As MPLS dataplane is largely deployed, the WG should avoid any m= odification in the MPLS dataplane when defining the architecture. Work items : ------------------ The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations - Protocol extension requirements . Interoperability Report Required protocol extensions are carried out in working groups responsible = (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <= Name-TBD> WG.=20 -----Message d'origine----- De : Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Envoy=E9 : mardi 10 septembre 2013 11:49 =C0 : LITKOWSKI Stephane DTF/DERX Cc : status@ietf.org Objet : RE: [Status] Good charter proposals from Hannes and Stefano : try t= o merge ... Hi Stephane, thanks for your proposal. Three remarks marked [RG] in line. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= stephane.litkowski@orange.com Sent: Tuesday, September 10, 2013 11:19 AM To: Rob Shakir Cc: Hannes Gredler; status@ietf.org; Stefano Previdi (sprevidi) Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try = to merge ... Souns good to me, (adding OAM also) New recap : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol extensions allowing to combine well known shortest path based routing paradigms with source/explicit routing methods. Some of these extensions have been implemented already. Objective --------- Define an architecture where a node can steer a packet through a network or set of networks (interdomain) on any path. In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-shortest, explicit or based on other characteristics specified by segment identifiers). It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the domain forward the packet as specified by the router at the head-end of the path. [RG] may be nit picking: to avoid the interpretation, that downstream route= rs have to contact the head-end router to get specific routing instructions.: ..forward the packet by the address stack inserted by the router at the hea= d-end... The architecture should support centralized and distributed path computation. The architecture should support OAM functions. Work items : ------------------ The working group is chartered for the following ordered list = of work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations . Protocol extension requirements . Interoperability Report Protocol work may be carried out in this working group or in other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordination with this WG, and in agreement with the WG chairs and responsible ADs. [RG] Would the following be better: Required protocol extensions are carried out in working groups responsible.= ..(). Work on new protocols may be carried out by the WG ... [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS f= orwarding plane, at least in the first phase. That should be part of the ch= arter. We could re-charter, should this result in a deadlock later. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From Ruediger.Geib@telekom.de Tue Sep 10 03:12:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD121E80D1 for ; Tue, 10 Sep 2013 03:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqfBUw1ISH+I for ; Tue, 10 Sep 2013 03:12:43 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 7335021E80B6 for ; Tue, 10 Sep 2013 03:12:39 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 10 Sep 2013 12:12:36 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 10 Sep 2013 12:12:36 +0200 From: To: Date: Tue, 10 Sep 2013 12:12:36 +0200 Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: Ac6uBNbrkBRLBSV9S6y8pktOp3jZcQAAQGewAABIa/AAATPeoAAAmPEA Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4140_1378807427_522EEE83_4140_2750_1_EEE55384044474429A926C625D0FCC810964DEC4FF@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <4140_1378807427_522EEE83_4140_2750_1_EEE55384044474429A926C625D0FCC810964DEC4FF@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 10:12:49 -0000 Hi Stephane, allright, thanks. Regards, Ruediger -----Original Message----- From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Tuesday, September 10, 2013 12:04 PM To: Geib, R=FCdiger Cc: status@ietf.org Subject: RE: [Status] Good charter proposals from Hannes and Stefano : try = to merge ... [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS = forwarding plane, at least in the first phase. That should be part of the c= harter. We could re-charter, should this result in a deadlock later. [SLI] Agree also [RG] may be nit picking: to avoid the interpretation, that downstream route= rs have to contact the head-end router to get specific routing instructions.: ..forward the packet by the address stack inserted by the router at the hea= d-end... [SLI] Changed by : "forward the packet by using the informations inserted by the router at th= e head-end" ---------------------------- Here is updated proposal : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a network or= set of networks (interdomain) on any path. In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node = to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-sh= ortest, explicit or based on other characteristics specified by segment ide= ntifiers). It may then send any packet that passes through it through any path that it= has specified and that is conform to the security rules. Downstream router= s along the path within the domain forward the packet by using t= he informations inserted by the router at the head-end The architecture should support centralized and distributed path computatio= n. The architecture should support OAM functions. As MPLS dataplane is largely deployed, the WG should avoid any m= odification in the MPLS dataplane when defining the architecture. Work items : ------------------ The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations - Protocol extension requirements . Interoperability Report Required protocol extensions are carried out in working groups responsible = (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <= Name-TBD> WG. -----Message d'origine----- De : Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Envoy=E9 : mardi 10 septembre 2013 11:49 =C0 : LITKOWSKI Stephane DTF/DERX Cc : status@ietf.org Objet : RE: [Status] Good charter proposals from Hannes and Stefano : try t= o merge ... Hi Stephane, thanks for your proposal. Three remarks marked [RG] in line. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= stephane.litkowski@orange.com Sent: Tuesday, September 10, 2013 11:19 AM To: Rob Shakir Cc: Hannes Gredler; status@ietf.org; Stefano Previdi (sprevidi) Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try = to merge ... Souns good to me, (adding OAM also) New recap : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topology (dual planes, disjoint trees), . Simplification and reduction of signaling components (scaling), . Combined application and network layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol extensions allowing to combine well known shortest path based routing paradigms with source/explicit routing methods. Some of these extensions have been implemented already. Objective --------- Define an architecture where a node can steer a packet through a network or set of networks (interdomain) on any path. In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a node to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-shortest, explicit or based on other characteristics specified by segment identifiers). It may then send any packet that passes through it through any path that it has specified and that is conform to the security rules. Downstream routers along the path within the domain forward the packet as specified by the router at the head-end of the path. [RG] may be nit picking: to avoid the interpretation, that downstream route= rs have to contact the head-end router to get specific routing instructions.: ..forward the packet by the address stack inserted by the router at the hea= d-end... The architecture should support centralized and distributed path computation. The architecture should support OAM functions. Work items : ------------------ The working group is chartered for the following ordered list = of work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations . Protocol extension requirements . Interoperability Report Protocol work may be carried out in this working group or in other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordination with this WG, and in agreement with the WG chairs and responsible ADs. [RG] Would the following be better: Required protocol extensions are carried out in working groups responsible.= ..(). Work on new protocols may be carried out by the WG ... [RG] I'd appreciate if we were able to agree to avoid changes in the MPLS f= orwarding plane, at least in the first phase. That should be part of the ch= arter. We could re-charter, should this result in a deadlock later. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From sprevidi@cisco.com Tue Sep 10 03:30:30 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD921F9E98 for ; Tue, 10 Sep 2013 03:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.02 X-Spam-Level: X-Spam-Status: No, score=-107.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9Gy0Zn07lP6 for ; Tue, 10 Sep 2013 03:30:17 -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 7A17B21F9C16 for ; Tue, 10 Sep 2013 03:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34109; q=dns/txt; s=iport; t=1378809017; x=1380018617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u2Js/BJiLcZtR3LbUnCuuO62CI3JvFoD2O93bPBh9Gw=; b=hwH8xsqG9GYnqDk8euxMnE6FFpuw9W4hobqSM04pwl1cSgYEhXaEjE0E ZKO5FM7xbkgcK3q7zNmsTo0PDMIcgYd2VVjpvRoksgxyGwdqDmsYfv1mH fDD/2AbIYAgksbdFXp/ZJr0LVbhlw78TEYdhr2o+ClSzV4OZ9yNvNIU60 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGLzLlKtJXG+/2dsb2JhbABRCoMHOFHCMYEoFnSCJQEBAQMBAQEBFwFMBAMEBwUHAgICAQgRAQMBAQEKHQcbDAsUAwYIAgQBDQUIE4dhBgyxc411BASODgYEAQWBBgIGJgUHAgSDF4EAA4h+oGODIIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.90,877,1371081600"; d="scan'208";a="257855354" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2013 10:30:07 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8AAU4rE015157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 10:30:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 05:30:04 -0500 From: "Stefano Previdi (sprevidi)" To: Stephane Litkowski , Rob Shakir Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAA== Date: Tue, 10 Sep 2013 10:30:03 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.84.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <60E7F89D4FF23A4A95B737067DF33815@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 10:30:30 -0000 Hi Stephane, Rob, one preliminary remark: I prefer to use he therm "node" rather=20 than "router". Use cases, such as Service Chaining requires that=20 terminology. some other comments below... On Sep 10, 2013, at 11:19 AM, wrote: > Souns good to me, (adding OAM also) >=20 > New recap : >=20 > ------------------------------------------------------------------- > Name: > Charter: >=20 >=20 > Introduction > ------------ > The following use cases: > . Path computation based on awareness of utilization or performance > data, within both centralized and distributed environments, . Multi-topo= logy (dual planes, disjoint trees), . Simplification and reduction of signa= ling components (scaling), . Combined application and network layer path sp= ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >=20 > have triggered work on the definition of new architecture and protocol ex= tensions allowing to combine well known shortest path based routing paradig= ms with source/explicit routing methods. Some of these extensions have been= implemented already. >=20 >=20 > Objective > --------- >=20 > Define an architecture where a node can steer a packet through a network = or set of networks (interdomain) on any path. [SP] As stated above, I'm fine with the above definition but I=20 assume this includes service chaining and that by "network=20 or set of networks" you intend "nodes" which may include=20 others things than just routers. =20 > In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a nod= e to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-= shortest, explicit or based on other characteristics specified by segment i= dentifiers). [SP] without requiring to maintain state along the path, other=20 than in the ingress node. > It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream rout= ers along the path within the domain forward the packet as speci= fied by the router at the head-end of the path. >=20 > The architecture should support centralized and distributed path computat= ion. >=20 > The architecture should support OAM functions. [SP] The architecture should allow different mechanisms through which=20 a path is constructed. SR allows a variety of mechanisms, not=20 confined IGP/BGP path computation. > Work items : > ------------------ >=20 > The working group is chartered for the following ordered list = of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between networks forming the <= Name-TBD> domain (interAS). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. [SP] The architecture will support tunnel and non-tunnel paradigms The architecture will support multiple dataplanes: MPLS and V6=09 =20 Thanks. s. > Documents : > ------------------ > . Use Cases > . Architecture including security considerations > - Protocol extension requirements > . Interoperability Report >=20 >=20 > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordin= ation with this WG, and in agreement with the WG chairs and responsible ADs= . >=20 > -----Message d'origine----- > De : Rob Shakir [mailto:rjs@rob.sh] > Envoy=E9 : mardi 10 septembre 2013 11:05 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org > Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try= to merge ... >=20 > Hi Stephane, >=20 > Thanks for this, looks good! Comments in-line marked rjs>. >=20 > On 10 Sep 2013, at 08:50, wrote: >=20 >> Hi all, >>=20 >> I'm creating a new mail topic because the "Summary of STATUS BOF ..." >> starts to be unreadable :) >>=20 >> Hannes and Stefano send to us two charter proposals that sounds good to = me. >>=20 >> The main difference between the two proposals is that Stefano propose a = segment bound to any type of instruction (forwarding, application or servic= e based) while Hannes is focusing on forwarding actions (which is the first= priority, and I think everybody agree on this). >=20 > rjs> Agreed -- I think it would be useful to allow definitions of segment= s to identify different types of "service", since there appear to be some u= se cases (e.g., the explicit exit selection case) which require a segment t= ype describing something that is not explicitly IGP-based. >=20 >>=20 >> It would be interresting to have a feedback from the mailinglist on this= specific point. >>=20 >> IMHO, there is a strong interrest to explore the service actions bound t= o segment in a second step keeping forwarding as a priority. >>=20 >> Apart of this problem, here is a merge try of the two good proposals (I'= m putting '<>' on hot topics :) ) : >>=20 >>=20 >> ------------------------------------------------------------------- >> Name: >> Charter: >>=20 >>=20 >> Introduction >> ------------ >> The following use cases: >> . Path computation based on awareness of utilization or performance >> data, within both centralized and distributed environments, . Multi-topo= logy (dual planes, disjoint trees), . Simplification and reduction of signa= ling components (scaling), . Combined application and network layer path sp= ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>=20 >> have triggered work on the definition of new architecture and protocol e= xtensions allowing to combine well known shortest path based routing paradi= gms with source/explicit routing methods. Some of these extensions have bee= n implemented already. >>=20 >>=20 >> Objective >> --------- >>=20 >> Define an architecture where a node can steer a packet through a network= or set of networks (interdomain) on any path (shortest, non shortest, expl= icit, ). >>=20 >> In this architecture, routers are sharing a common trust model and are f= orming a domain. >> Within this domain, a node can specify a path between itself and any des= tination in the domain. . >=20 > rjs> To clarify here, we define that our domain is under a common trust m= odel (essentially, under common administrative control?), but then go on to= talk about inter-domain elsewhere. Can we perhaps clarify (by defining a s= pecific " domain" nomenclature) and say something like: >=20 > "In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a no= de to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non= -shortest, explicit or based on other characteristics specified by segment = identifiers)." >=20 >> It may then send any packet that passes through it through any path that= it has specified and that is conform to the security rules. Downstream rou= ters along the path within the domain forward the packet as spec= ified by the router at the head-end of the path. >>=20 >> The architecture should support centralized and distributed path computa= tion. >>=20 >>=20 >> Work items : >> ------------------ >>=20 >> The working group is chartered for the following ordered list= of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains (inter domain)= . >=20 > rjs> And then here "networks forming the domain"? >=20 > Thanks for the efforts, > r. >=20 >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >>=20 >> Documents : >> ------------------ >> . Use Cases >> . Architecture including security considerations >> - Protocol extension requirements >> . Interoperability Report >>=20 >>=20 >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordi= nation with this WG, and in agreement with the WG chairs and responsible AD= s. >>=20 >>=20 >>=20 >> Hope it helps to progress on the definition. >>=20 >>=20 >> Stephane >>=20 >>=20 >> -----Message d'origine----- >> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi 6 >> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the >> next steps >>=20 >> hi stephane, >>=20 >> here is a revised draft charter as per your comments. >>=20 >> --- >>=20 >> domain contains a set of routers with the following >> characteristics: >>=20 >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, or any other (e.g., an explicit) path >> - They share a common trust model. In this model, any router within >> the domain can specify a path between itself and any other router in >> the domain. It may then send any packet that passes through it >> through any path that it has specified and that is conform to the >> security rules. Downstream routers along the path within the >> domain forward the packet as specified by the router at >> the head-end of the path. >>=20 >> The working group is chartered for the following ordered list= of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. >> However, no protocol work will be adopted by a working group to address = the identified use-cases until the requirements document motivating the pro= tocol work has been sent to the IESG for publication as an RFC. >>=20 >> --- >>=20 >> /hannes >>=20 >> On Sep 4, 2013, at 10:02 AM, wrote: >>=20 >>> Hannes, >>>=20 >>> In case, we are using only directed forwarding (adjacency segment), >>> could we still talk about tunneling ? (it's a very very small tunnel) M= oreover talking about "stacking" is really dataplane agnostic (MPLS) ... >>>=20 >>> In the proposed segment routing architectural concepts, segments are at= the same "level" and pointer moves on the segment list, then the MPLS inst= antiation is performing this using stacking ... >>>=20 >>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solut= ion and it's closing the door to something else ... >>>=20 >>> Finally, about the "routing" word, routing is essentially a "forward" a= ction which may limit the scope of what we can do by using a segment list. = Actions associated with a segment could be something else than forwarding. >>>=20 >>> Do we want in the charter to limit the scope to routing actions ? >>>=20 >>> I have no solution today to propose for the naming, but I completely ag= ree with Loa, to first focus on working on the charter, and define a clear = scope of the work and then the name will be easier to find. >>>=20 >>> Regarding your charter proposal : >>>=20 >>> -------- >>>=20 >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>=20 >>> - They can forward traffic through the shortest paths or paths other th= an the shortest (the latter called explicitly routed paths, or explicit pat= hs) >>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>>=20 >>> - They share a common trust model. In this model, any router within the= ERD can specify an explicit path between itself and any other router in th= e ERD. It can then send any packet that passes through it through any path = that it has specified. >>> [SLI] Security considerations may have to be addressed in the >>> charter , especially for the interAS case (trust yes, but not sure >>> access to everything may not be good) >>>=20 >>> Downstream routers within the ERD forward the packet as specified by th= e router at the head-end of the path. >>> [SLI] Yes, but any router in the middle may be able to change the end t= o end explicit path. >>>=20 >>>=20 >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between curren= tly available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>>=20 >>> [SLI] Agree, I would add : >>> - defining the architecture framework >>> - analysing the security considerisations >>>=20 >>>=20 >>> --------- >>>=20 >>>=20 >>> Here would be my proposal to extend yours : >>>=20 >>> A domain contains a set of routers with the follo= wing characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through any path within the network using >>> shortest path, non shortest path or explicit path >>> - They may provide other types of services than forwarding and they can= enforce service actions in the path. >>> - They share a common trust model. In this model, any router within the= domain can specify a path between itself and any other router in the domai= n. It may then send any packet that passes through it through any path that= it has specified and that is conform to the security rules. Downstream rou= ters within the ERD forward the packet as specified by the router at the he= ad-end of the path. >>>=20 >>> The working group is chartered for the following ordered list of= work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with th= e security considerations. The architecture framework and security consider= ations must address the relations between domains (interdomain). >>> - Having identified use-cases, architecture and security, the WG will i= dentify gaps between currently available technologies and use-case requirem= ents. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. However, no protocol = work will be adopted by a working group to address the ERD use-cases until = the requirements document motivating the protocol work has been sent to the= IESG for publication as an RFC. >>>=20 >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Lo= a >>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of STATUS >>> BOF and the next steps >>>=20 >>> good point - what about this charter proposal ? >>>=20 >>> --- >>>=20 >>> Stacked Tunnels for Explicit Routing (STER) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> A explicit routing domain (ERD) contains a set of routers with the foll= owing characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through the shortest paths or paths other >>> than the shortest (the latter called explicitly routed paths, or >>> explicit paths) >>> - They share a common trust model. In this model, any router within the= ERD can specify an explicit path between itself and any other router in th= e ERD. It can then send any packet that passes through it through any path = that it has specified. Downstream routers within the ERD forward the packet= as specified by the router at the head-end of the path. >>>=20 >>> The STER working group is chartered for the following ordered list of w= ork items: >>>=20 >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between curren= tly available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>>=20 >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. However, no protocol = work will be adopted by a working group to address the ERD use-cases until = the requirements document motivating the protocol work has been sent to the= IESG for publication as an RFC. >>>=20 >>> --- >>>=20 >>> >>>=20 >>> /hannes >>>=20 >>>=20 >>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>=20 >>>> Folks, >>>>=20 >>>> Excuse me if I'm slightly out of the loop, but so far I have not >>>> seen a charter proposal, if there is one please point me to it. >>>>=20 >>>> It seems a bit odd to put the cart (what the wg should do) before >>>> the horse (wg name). If we drill down the the charter first the wg >>>> name might be easier to figure out. >>>>=20 >>>> /Loa >>>>=20 >>>> PS >>>> OK I understand that the horse and cart analogy limps a bit :). >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>> " If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another working = group ? So we will go back to the WG synchronization issue that has been ra= ised for this technology ..." >>>>>=20 >>>>> That's why I suggested SRV2. We are revisiting source routing with ne= w concepts. More generic number/action behavior. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of stephane.litkowski@orange.com >>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>> To: AshwoodsmithPeter >>>>> Cc: status@ietf.org >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>>=20 >>>>> There was a misunderstanding in my small comment :) so I will explain= more : >>>>>=20 >>>>> In segment routing, you have more than basic source routing : segment= routing is just associate a segment number to an action and then combine s= egment as you want, yes you can do source routing, but you also can do more= . >>>>>=20 >>>>> In the other hand, I completely agree with your statement that >>>>> source routing is generic and dataplane agnostic, as segment routing = is ... >>>>> (segment routing is not a new dataplane ...) >>>>>=20 >>>>> Now the definition of the WG naming must be inline with the charter >>>>> that will be defined ... (draft today) >>>>>=20 >>>>> Based on the already existing consensus (at least for MPLS dataplane)= brought up during Berlin STATUS BOF meeting, segment routing sounds to be = a good target candidate. >>>>>=20 >>>>> So now, do we want to do more in the WG charter than just make progre= ssing segment routing architecture and uses cases document and ensure coord= ination for the standardization of this technology ? >>>>>=20 >>>>> Do we want to standardize other technologies in this WG ? I don't thi= nk so, based on Stewart's conclusion email from the BOF :"A new WG focused = solely on SR therefore needs to be create" >>>>>=20 >>>>> If the WG charter is limited to source routing, how will we handle th= e "non source routing" use cases of segment routing ? In another working gr= oup ? So we will go back to the WG synchronization issue that has been rais= ed for this technology ... >>>>>=20 >>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>=20 >>>>> Feedback ? >>>>>=20 >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : = Re: >>>>> [Status] Summary of STATUS BOF and the next steps >>>>>=20 >>>>> The term "source routing" has been around for a very long time and is= data path agnostic. Its also the term used in the literature etc so my pre= ference is to stick with this existing well known and data path agnostic te= rm. >>>>>=20 >>>>> Peter >>>>>=20 >>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> "Source routing" is just a subcase of segment routing ... as it is f= or IP routing ... >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 = : >>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John= G. >>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>> BOF and the next steps >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> What is this 'segment routing' silliness? The correct term is 'sour= ce routing'. >>>>>>=20 >>>>>> Yours Irrespectively, >>>>>>=20 >>>>>> John >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>>> Behalf Of Mark Townsley >>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>> To: Victor Kuarsingh >>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>> (stbryant) >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>=20 >>>>>>>> I note this since attempting to come up with an all encompassing >>>>>>>> acronym will be difficult and Segment Routing is generic enough >>>>>>>> to associate to multiple functions. >>>>>>>=20 >>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>> have to have acronyms, but they do need to have an 8-char limited >>>>>>> short name for the various automated tools not to break. >>>>>>>=20 >>>>>>> - Mark >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Victor K >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> +1 for Segment Routing WG >>>>>>>>>=20 >>>>>>>>> Roberta >>>>>>>>>=20 >>>>>>>>> Sent from my iPad >>>>>>>>>=20 >>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> The second task, which hopefully should be relatively easy, >>>>>>>>>>> is to find a better working name for the WG, since it has >>>>>>>>>>> been put to me a number of times that STATUS is going to be >>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> __________________________________________________________________ >>>>>> _ _ __ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> ___________________________________________________________________ >>>>> _ _ ____________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From stephane.litkowski@orange.com Tue Sep 10 04:25:21 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B433A21F9371 for ; Tue, 10 Sep 2013 04:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3IwcKfe+EcX for ; Tue, 10 Sep 2013 04:25:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id F3C2121F93C4 for ; Tue, 10 Sep 2013 04:25:06 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 3E7C9C06D6; Tue, 10 Sep 2013 13:25:06 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 25A2D180049; Tue, 10 Sep 2013 13:25:06 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 10 Sep 2013 13:25:03 +0200 From: To: "Stefano Previdi (sprevidi)" , Rob Shakir Date: Tue, 10 Sep 2013 13:25:01 +0200 Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAP//uVuA Message-ID: <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: Hannes Gredler , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:25:21 -0000 Agree on all proposal except : "[SP] The architecture will support tunnel and non-tunnel paradigms The architecture will support multiple dataplanes: MPLS and V6" I don't see the reason for this ... IMHO, the gap analysis and requirements= inventory will result on saying or not : we must use tunnels and/or non tu= nnels, and the following dataplanes ... But I don't see the reason to put s= olutions directly in the charter ... Could you explain your point ? updated with the other comments : ------------------------------------------------------------------- Name: Charter: Introduction ------------ The following use cases: . Path computation based on awareness of utilization or performance data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. have triggered work on the definition of new architecture and protocol exte= nsions allowing to combine well known shortest path based routing paradigms= with source/explicit routing methods. Some of these extensions have been i= mplemented already. Objective --------- Define an architecture where a node can steer a packet through a network or= set of networks (interdomain) on any path without requiring to maintain st= ate along the path, other than in the ingress node. A node may be any type of device including routers or appliances. In this architecture, nodes sharing a common trust model form a = domain. The architecture defined by this working group will allow a node to= steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-shor= test, explicit or based on other characteristics specified by segment ident= ifiers). It may then send any packet that passes through it through any path that it= has specified and that is conform to the security rules. Downstream nodes = along the path within the domain forward the packet by using the= informations inserted by the node at the head-end The architecture should support centralized and distributed path computatio= n. The architecture should support OAM functions. The architecture should allow different mechanisms through which a path is constructed. SR allows a variety of mechanisms, not confined IGP/BGP path computation. As MPLS dataplane is largely deployed, the WG should avoid any m= odification in the MPLS dataplane when defining the architecture. Work items : ------------------ The working group is chartered for the following ordered list of= work items: - The first goal of the WG is to identify use-cases. - The WG will then define the architecture framework associated with the security considerations. The architecture framework and security considerations must address the relations between networks forming the domain (interAS). - Having identified use-cases, architecture and security, the WG will identify gaps between currently available technologies and use-case requirements. - The WG will then define requirements for extensions to existing protocols or new protocols that address gaps that are identified. - The WG will first focus on the intra-domain forwarding definition. Documents : ------------------ . Use Cases . Architecture including security considerations - Protocol extension requirements . Interoperability Report Required protocol extensions are carried out in working groups responsible = (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the <= Name-TBD> WG. -----Message d'origine----- De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir Cc : Hannes Gredler; status@ietf.org Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try t= o merge ... Hi Stephane, Rob, one preliminary remark: I prefer to use he therm "node" rather than "router= ". Use cases, such as Service Chaining requires that terminology. some other comments below... On Sep 10, 2013, at 11:19 AM, wrote: > Souns good to me, (adding OAM also) > > New recap : > > ------------------------------------------------------------------- > Name: > Charter: > > > Introduction > ------------ > The following use cases: > . Path computation based on awareness of utilization or performance > data, within both centralized and distributed environments, . Multi-topol= ogy (dual planes, disjoint trees), . Simplification and reduction of signal= ing components (scaling), . Combined application and network layer path spe= cification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. > > have triggered work on the definition of new architecture and protocol ex= tensions allowing to combine well known shortest path based routing paradig= ms with source/explicit routing methods. Some of these extensions have been= implemented already. > > > Objective > --------- > > Define an architecture where a node can steer a packet through a network = or set of networks (interdomain) on any path. [SP] As stated above, I'm fine with the above definition but I assume this includes service chaining and that by "network or set of networks" you intend "nodes" which may include others things than just routers. [SLI] Agree > In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a nod= e to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-= shortest, explicit or based on other characteristics specified by segment i= dentifiers). [SP] without requiring to maintain state along the path, other than in the ingress node. [SLI] Agree > It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream rout= ers along the path within the domain forward the packet as speci= fied by the router at the head-end of the path. > > The architecture should support centralized and distributed path computat= ion. > > The architecture should support OAM functions. [SP] The architecture should allow different mechanisms through which a path is constructed. SR allows a variety of mechanisms, not confined IGP/BGP path computation. [SLI] Agree > Work items : > ------------------ > > The working group is chartered for the following ordered list = of work items: > > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between networks forming the domain (interAS). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. [SP] The architecture will support tunnel and non-tunnel paradigms The architecture will support multiple dataplanes: MPLS and V6 Thanks. s. > Documents : > ------------------ > . Use Cases > . Architecture including security considerations > - Protocol extension requirements > . Interoperability Report > > > Protocol work may be carried out in this working group or in other workin= g groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordin= ation with this WG, and in agreement with the WG chairs and responsible ADs. > > -----Message d'origine----- > De : Rob Shakir [mailto:rjs@rob.sh] > Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org Objet > : Re: [Status] Good charter proposals from Hannes and Stefano : try to me= rge ... > > Hi Stephane, > > Thanks for this, looks good! Comments in-line marked rjs>. > > On 10 Sep 2013, at 08:50, wrote: > >> Hi all, >> >> I'm creating a new mail topic because the "Summary of STATUS BOF ..." >> starts to be unreadable :) >> >> Hannes and Stefano send to us two charter proposals that sounds good to = me. >> >> The main difference between the two proposals is that Stefano propose a = segment bound to any type of instruction (forwarding, application or servic= e based) while Hannes is focusing on forwarding actions (which is the first= priority, and I think everybody agree on this). > > rjs> Agreed -- I think it would be useful to allow definitions of segment= s to identify different types of "service", since there appear to be some u= se cases (e.g., the explicit exit selection case) which require a segment t= ype describing something that is not explicitly IGP-based. > >> >> It would be interresting to have a feedback from the mailinglist on this= specific point. >> >> IMHO, there is a strong interrest to explore the service actions bound t= o segment in a second step keeping forwarding as a priority. >> >> Apart of this problem, here is a merge try of the two good proposals (I'= m putting '<>' on hot topics :) ) : >> >> >> ------------------------------------------------------------------- >> Name: >> Charter: >> >> >> Introduction >> ------------ >> The following use cases: >> . Path computation based on awareness of utilization or performance >> data, within both centralized and distributed environments, . Multi-topo= logy (dual planes, disjoint trees), . Simplification and reduction of signa= ling components (scaling), . Combined application and network layer path sp= ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >> >> have triggered work on the definition of new architecture and protocol e= xtensions allowing to combine well known shortest path based routing paradi= gms with source/explicit routing methods. Some of these extensions have bee= n implemented already. >> >> >> Objective >> --------- >> >> Define an architecture where a node can steer a packet through a network= or set of networks (interdomain) on any path (shortest, non shortest, expl= icit, ). >> >> In this architecture, routers are sharing a common trust model and are f= orming a domain. >> Within this domain, a node can specify a path between itself and any des= tination in the domain. . > > rjs> To clarify here, we define that our domain is under a common trust m= odel (essentially, under common administrative control?), but then go on to= talk about inter-domain elsewhere. Can we perhaps clarify (by defining a s= pecific " domain" nomenclature) and say something like: > > "In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a no= de to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non= -shortest, explicit or based on other characteristics specified by segment = identifiers)." > >> It may then send any packet that passes through it through any path that= it has specified and that is conform to the security rules. Downstream rou= ters along the path within the domain forward the packet as spec= ified by the router at the head-end of the path. >> >> The architecture should support centralized and distributed path computa= tion. >> >> >> Work items : >> ------------------ >> >> The working group is chartered for the following ordered list= of work items: >> >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains (inter domain). > > rjs> And then here "networks forming the domain"? > > Thanks for the efforts, > r. > >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >> >> >> Documents : >> ------------------ >> . Use Cases >> . Architecture including security considerations >> - Protocol extension requirements >> . Interoperability Report >> >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordi= nation with this WG, and in agreement with the WG chairs and responsible AD= s. >> >> >> >> Hope it helps to progress on the definition. >> >> >> Stephane >> >> >> -----Message d'origine----- >> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi 6 >> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the >> next steps >> >> hi stephane, >> >> here is a revised draft charter as per your comments. >> >> --- >> >> domain contains a set of routers with the following >> characteristics: >> >> - They form a connected network >> - They can forward traffic through any path within the network using >> shortest path, or any other (e.g., an explicit) path >> - They share a common trust model. In this model, any router within >> the domain can specify a path between itself and any other router in >> the domain. It may then send any packet that passes through it >> through any path that it has specified and that is conform to the >> security rules. Downstream routers along the path within the >> domain forward the packet as specified by the router at >> the head-end of the path. >> >> The working group is chartered for the following ordered list= of work items: >> >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between domains (interdomain). >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >> >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols, in coordination with this WG, and = in agreement with the WG chairs and responsible ADs. >> However, no protocol work will be adopted by a working group to address = the identified use-cases until the requirements document motivating the pro= tocol work has been sent to the IESG for publication as an RFC. >> >> --- >> >> /hannes >> >> On Sep 4, 2013, at 10:02 AM, wrote: >> >>> Hannes, >>> >>> In case, we are using only directed forwarding (adjacency segment), >>> could we still talk about tunneling ? (it's a very very small tunnel) M= oreover talking about "stacking" is really dataplane agnostic (MPLS) ... >>> >>> In the proposed segment routing architectural concepts, segments are at= the same "level" and pointer moves on the segment list, then the MPLS inst= antiation is performing this using stacking ... >>> >>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solut= ion and it's closing the door to something else ... >>> >>> Finally, about the "routing" word, routing is essentially a "forward" a= ction which may limit the scope of what we can do by using a segment list. = Actions associated with a segment could be something else than forwarding. >>> >>> Do we want in the charter to limit the scope to routing actions ? >>> >>> I have no solution today to propose for the naming, but I completely ag= ree with Loa, to first focus on working on the charter, and define a clear = scope of the work and then the name will be easier to find. >>> >>> Regarding your charter proposal : >>> >>> -------- >>> >>> - They form a connected network >>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>> >>> - They can forward traffic through the shortest paths or paths other th= an the shortest (the latter called explicitly routed paths, or explicit pat= hs) >>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>> >>> - They share a common trust model. In this model, any router within the= ERD can specify an explicit path between itself and any other router in th= e ERD. It can then send any packet that passes through it through any path = that it has specified. >>> [SLI] Security considerations may have to be addressed in the >>> charter , especially for the interAS case (trust yes, but not sure >>> access to everything may not be good) >>> >>> Downstream routers within the ERD forward the packet as specified by th= e router at the head-end of the path. >>> [SLI] Yes, but any router in the middle may be able to change the end t= o end explicit path. >>> >>> >>> >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between curren= tly available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> >>> [SLI] Agree, I would add : >>> - defining the architecture framework >>> - analysing the security considerisations >>> >>> >>> --------- >>> >>> >>> Here would be my proposal to extend yours : >>> >>> A domain contains a set of routers with the follo= wing characteristics: >>> >>> - They form a connected network >>> - They can forward traffic through any path within the network using >>> shortest path, non shortest path or explicit path >>> - They may provide other types of services than forwarding and they can= enforce service actions in the path. >>> - They share a common trust model. In this model, any router within the= domain can specify a path between itself and any other router in the domai= n. It may then send any packet that passes through it through any path that= it has specified and that is conform to the security rules. Downstream rou= ters within the ERD forward the packet as specified by the router at the he= ad-end of the path. >>> >>> The working group is chartered for the following ordered list of= work items: >>> >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with th= e security considerations. The architecture framework and security consider= ations must address the relations between domains (interdomain). >>> - Having identified use-cases, architecture and security, the WG will i= dentify gaps between currently available technologies and use-case requirem= ents. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>> >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. However, no protocol = work will be adopted by a working group to address the ERD use-cases until = the requirements document motivating the protocol work has been sent to the= IESG for publication as an RFC. >>> >>> -----Message d'origine----- >>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : Loa >>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of >>> STATUS BOF and the next steps >>> >>> good point - what about this charter proposal ? >>> >>> --- >>> >>> Stacked Tunnels for Explicit Routing (STER) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> A explicit routing domain (ERD) contains a set of routers with the foll= owing characteristics: >>> >>> - They form a connected network >>> - They can forward traffic through the shortest paths or paths other >>> than the shortest (the latter called explicitly routed paths, or >>> explicit paths) >>> - They share a common trust model. In this model, any router within the= ERD can specify an explicit path between itself and any other router in th= e ERD. It can then send any packet that passes through it through any path = that it has specified. Downstream routers within the ERD forward the packet= as specified by the router at the head-end of the path. >>> >>> The STER working group is chartered for the following ordered list of w= ork items: >>> >>> - The first goal of the STER WG is to identify use-cases for ERDs. >>> - Having identified use-cases, the WG will identify gaps between curren= tly available technologies and use-case requirements. >>> - The WG will then define requirements for extensions to existing proto= cols or new protocols that address gaps that are identified. >>> >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. However, no protocol = work will be adopted by a working group to address the ERD use-cases until = the requirements document motivating the protocol work has been sent to the= IESG for publication as an RFC. >>> >>> --- >>> >>> >>> >>> /hannes >>> >>> >>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>> >>>> Folks, >>>> >>>> Excuse me if I'm slightly out of the loop, but so far I have not >>>> seen a charter proposal, if there is one please point me to it. >>>> >>>> It seems a bit odd to put the cart (what the wg should do) before >>>> the horse (wg name). If we drill down the the charter first the wg >>>> name might be easier to figure out. >>>> >>>> /Loa >>>> >>>> PS >>>> OK I understand that the horse and cart analogy limps a bit :). >>>> >>>> >>>> >>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>> " If the WG charter is limited to source routing, how will we handle = the "non source routing" use cases of segment routing ? In another working = group ? So we will go back to the WG synchronization issue that has been ra= ised for this technology ..." >>>>> >>>>> That's why I suggested SRV2. We are revisiting source routing with ne= w concepts. More generic number/action behavior. >>>>> >>>>> Peter >>>>> >>>>> -----Original Message----- >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf Of stephane.litkowski@orange.com >>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>> To: AshwoodsmithPeter >>>>> Cc: status@ietf.org >>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> >>>>> There was a misunderstanding in my small comment :) so I will explain= more : >>>>> >>>>> In segment routing, you have more than basic source routing : segment= routing is just associate a segment number to an action and then combine s= egment as you want, yes you can do source routing, but you also can do more. >>>>> >>>>> In the other hand, I completely agree with your statement that >>>>> source routing is generic and dataplane agnostic, as segment routing = is ... >>>>> (segment routing is not a new dataplane ...) >>>>> >>>>> Now the definition of the WG naming must be inline with the >>>>> charter that will be defined ... (draft today) >>>>> >>>>> Based on the already existing consensus (at least for MPLS dataplane)= brought up during Berlin STATUS BOF meeting, segment routing sounds to be = a good target candidate. >>>>> >>>>> So now, do we want to do more in the WG charter than just make progre= ssing segment routing architecture and uses cases document and ensure coord= ination for the standardization of this technology ? >>>>> >>>>> Do we want to standardize other technologies in this WG ? I don't thi= nk so, based on Stewart's conclusion email from the BOF :"A new WG focused = solely on SR therefore needs to be create" >>>>> >>>>> If the WG charter is limited to source routing, how will we handle th= e "non source routing" use cases of segment routing ? In another working gr= oup ? So we will go back to the WG synchronization issue that has been rais= ed for this technology ... >>>>> >>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>> >>>>> Feedback ? >>>>> >>>>> >>>>> Stephane >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet : = Re: >>>>> [Status] Summary of STATUS BOF and the next steps >>>>> >>>>> The term "source routing" has been around for a very long time and is= data path agnostic. Its also the term used in the literature etc so my pre= ference is to stick with this existing well known and data path agnostic te= rm. >>>>> >>>>> Peter >>>>> >>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> "Source routing" is just a subcase of segment routing ... as it is f= or IP routing ... >>>>>> >>>>>> Stephane >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0 : >>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); John= G. >>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>> BOF and the next steps >>>>>> >>>>>> Hi, >>>>>> >>>>>> What is this 'segment routing' silliness? The correct term is 'sour= ce routing'. >>>>>> >>>>>> Yours Irrespectively, >>>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>> On Behalf Of Mark Townsley >>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>> To: Victor Kuarsingh >>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>> (stbryant) >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>> >>>>>>> >>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>> >>>>>>>> I note this since attempting to come up with an all >>>>>>>> encompassing acronym will be difficult and Segment Routing is >>>>>>>> generic enough to associate to multiple functions. >>>>>>> >>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>> have to have acronyms, but they do need to have an 8-char >>>>>>> limited short name for the various automated tools not to break. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Victor K >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> +1 for Segment Routing WG >>>>>>>>> >>>>>>>>> Roberta >>>>>>>>> >>>>>>>>> Sent from my iPad >>>>>>>>> >>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Segment Routing WG >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> The second task, which hopefully should be relatively easy, >>>>>>>>>>> is to find a better working name for the WG, since it has >>>>>>>>>>> been put to me a number of times that STATUS is going to be >>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>>> _________________________________________________________________ >>>>>> _ _ _ __ ___________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> __________________________________________________________________ >>>>> _ _ _ ____________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>>> >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >>> ____________________________________________________________________ >>> _ _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler a l'expediteur et le detrui= re ainsi que les pieces jointes. Les messages electroniques etant susceptib= les d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> >>> >> >> >> >> _____________________________________________________________________ >> _ ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From sprevidi@cisco.com Tue Sep 10 09:58:43 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C242721E8166 for ; Tue, 10 Sep 2013 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.02 X-Spam-Level: X-Spam-Status: No, score=-107.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HugD2a7x838 for ; Tue, 10 Sep 2013 09:58:37 -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 DEB3921E817D for ; Tue, 10 Sep 2013 09:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41390; q=dns/txt; s=iport; t=1378832312; x=1380041912; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MDdJW8M+LcmW4dVHsM852MHVUjM5vjTLbQOl49N8tvg=; b=RqdcUeRiy8ckHSPTtITiraGg6xiZIViBRUsY8omLVGuEqxrOAjxDCvMw isBTNaY149jUWuitvUbIV6SiKx+5mCf/QJknW6Ujvqe0LyHUC9jCrTRXK M/8HTnDXZGYRhZlPGhqmWFn3tiYpXRkK/F++USjua8cDV7bB8Ky1g0TjD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPBOL1KtJXG9/2dsb2JhbABRCoMHOFHCQIElFnSCJQEBAQMBAQEBFwFMBAMEBwUHAgICAQgRAQMBAQEKHQcbDAsUAwYIAgQOBQgTh2EGDLIWjVUEBI4OBgQBBYEGAgYmBQcCBIMXgQADiH6gY4MggWgBCBci X-IronPort-AV: E=Sophos;i="4.90,879,1371081600"; d="scan'208";a="258018332" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2013 16:58:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8AGwTjp008338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 16:58:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 11:58:29 -0500 From: "Stefano Previdi (sprevidi)" To: Stephane Litkowski Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAP//uVuAgACzLAA= Date: Tue, 10 Sep 2013 16:58:28 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.204.178] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Gredler , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 16:58:43 -0000 On Sep 10, 2013, at 1:25 PM, wrote: > Agree on all proposal except : >=20 > "[SP] The architecture will support tunnel and non-tunnel paradigms > The architecture will support multiple dataplanes: MPLS and V6" >=20 > I don't see the reason for this ... IMHO, the gap analysis and requiremen= ts inventory will result on saying or not [SP] While I understand what brought the following statements in the proposed charter: "Having identified use-cases, architecture and security,=20 the WG will identify gaps between currently available=20 technologies and use-case requirements. The WG will then define requirements for extensions to=20 existing protocols or new protocols that address gaps=20 that are identified." I'd like to point out with better precision what are the=20 directions we are ALREADY engaged into: dataplanes and=20 paradigms. As I mentioned in my charter proposal, we do have=20 implementations and multi-vendor interoperability tests will happen soon. So, I just want to be sure we don't ignore this=20 reality. MPLS and v6 data-plane are part of this reality, as well as=20 tunnel-based and non-tunnel based approaches. > : we must use tunnels and/or non tunnels, and the following dataplanes ..= . But I don't see the reason to put solutions directly in the charter ... these are not solutions these are way to avoid boundaries in the framework. Thanks. s. > Could you explain your point ? >=20 >=20 > updated with the other comments : >=20 > ------------------------------------------------------------------- > Name: > Charter: >=20 >=20 > Introduction > ------------ > The following use cases: > . Path computation based on awareness of utilization or performance > data, within both centralized and distributed environments, . Multi-topo= logy (dual planes, disjoint trees), . Simplification and reduction of signa= ling components (scaling), . Combined application and network layer path sp= ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >=20 > have triggered work on the definition of new architecture and protocol ex= tensions allowing to combine well known shortest path based routing paradig= ms with source/explicit routing methods. Some of these extensions have been= implemented already. >=20 >=20 > Objective > --------- >=20 > Define an architecture where a node can steer a packet through a network = or set of networks (interdomain) on any path without requiring to maintain = state along the path, other than in the ingress node. >=20 > A node may be any type of device including routers or appliances. >=20 > In this architecture, nodes sharing a common trust model form a domain. The architecture defined by this working group will allow a node = to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-sh= ortest, explicit or based on other characteristics specified by segment ide= ntifiers). >=20 > It may then send any packet that passes through it through any path that = it has specified and that is conform to the security rules. Downstream node= s along the path within the domain forward the packet by using t= he informations inserted by the node at the head-end >=20 > The architecture should support centralized and distributed path computat= ion. >=20 > The architecture should support OAM functions. >=20 > The architecture should allow different mechanisms through which > a path is constructed. SR allows a variety of mechanisms, not > confined IGP/BGP path computation. >=20 > As MPLS dataplane is largely deployed, the WG should avoid any= modification in the MPLS dataplane when defining the architecture. >=20 >=20 > Work items : > ------------------ >=20 > The working group is chartered for the following ordered list = of work items: >=20 > - The first goal of the WG is to identify use-cases. > - The WG will then define the architecture framework associated with > the security considerations. The architecture framework and security > considerations must address the relations between networks forming the <= Name-TBD> domain (interAS). > - Having identified use-cases, architecture and security, the WG will > identify gaps between currently available technologies and use-case > requirements. > - The WG will then define requirements for extensions to existing > protocols or new protocols that address gaps that are identified. > - The WG will first focus on the intra-domain forwarding definition. >=20 >=20 > Documents : > ------------------ > . Use Cases > . Architecture including security considerations > - Protocol extension requirements > . Interoperability Report >=20 >=20 > Required protocol extensions are carried out in working groups responsibl= e (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by the= WG. >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > Envoy=E9 : mardi 10 septembre 2013 12:30 > =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir > Cc : Hannes Gredler; status@ietf.org > Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try= to merge ... >=20 > Hi Stephane, Rob, >=20 > one preliminary remark: I prefer to use he therm "node" rather than "rout= er". Use cases, such as Service Chaining requires that terminology. >=20 > some other comments below... >=20 >=20 > On Sep 10, 2013, at 11:19 AM, wrote: >> Souns good to me, (adding OAM also) >>=20 >> New recap : >>=20 >> ------------------------------------------------------------------- >> Name: >> Charter: >>=20 >>=20 >> Introduction >> ------------ >> The following use cases: >> . Path computation based on awareness of utilization or performance >> data, within both centralized and distributed environments, . Multi-topo= logy (dual planes, disjoint trees), . Simplification and reduction of signa= ling components (scaling), . Combined application and network layer path sp= ecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>=20 >> have triggered work on the definition of new architecture and protocol e= xtensions allowing to combine well known shortest path based routing paradi= gms with source/explicit routing methods. Some of these extensions have bee= n implemented already. >>=20 >>=20 >> Objective >> --------- >>=20 >> Define an architecture where a node can steer a packet through a network= or set of networks (interdomain) on any path. >=20 >=20 > [SP] As stated above, I'm fine with the above definition but I > assume this includes service chaining and that by "network > or set of networks" you intend "nodes" which may include > others things than just routers. >=20 > [SLI] Agree >=20 >=20 >> In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a no= de to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non= -shortest, explicit or based on other characteristics specified by segment = identifiers). >=20 >=20 > [SP] without requiring to maintain state along the path, other > than in the ingress node. >=20 > [SLI] Agree >=20 >=20 >> It may then send any packet that passes through it through any path that= it has specified and that is conform to the security rules. Downstream rou= ters along the path within the domain forward the packet as spec= ified by the router at the head-end of the path. >=20 >>=20 >> The architecture should support centralized and distributed path computa= tion. >>=20 >> The architecture should support OAM functions. >=20 >=20 > [SP] The architecture should allow different mechanisms through which > a path is constructed. SR allows a variety of mechanisms, not > confined IGP/BGP path computation. >=20 > [SLI] Agree >=20 >> Work items : >> ------------------ >>=20 >> The working group is chartered for the following ordered list= of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between networks forming the <= Name-TBD> domain (interAS). >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >=20 >=20 > [SP] The architecture will support tunnel and non-tunnel paradigms > The architecture will support multiple dataplanes: MPLS and V6 >=20 >=20 > Thanks. > s. >=20 >=20 >> Documents : >> ------------------ >> . Use Cases >> . Architecture including security considerations >> - Protocol extension requirements >> . Interoperability Report >>=20 >>=20 >> Protocol work may be carried out in this working group or in other worki= ng groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coordi= nation with this WG, and in agreement with the WG chairs and responsible AD= s. >>=20 >> -----Message d'origine----- >> De : Rob Shakir [mailto:rjs@rob.sh] >> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DE= RX >> Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org Objet >> : Re: [Status] Good charter proposals from Hannes and Stefano : try to m= erge ... >>=20 >> Hi Stephane, >>=20 >> Thanks for this, looks good! Comments in-line marked rjs>. >>=20 >> On 10 Sep 2013, at 08:50, wrote: >>=20 >>> Hi all, >>>=20 >>> I'm creating a new mail topic because the "Summary of STATUS BOF ..." >>> starts to be unreadable :) >>>=20 >>> Hannes and Stefano send to us two charter proposals that sounds good to= me. >>>=20 >>> The main difference between the two proposals is that Stefano propose a= segment bound to any type of instruction (forwarding, application or servi= ce based) while Hannes is focusing on forwarding actions (which is the firs= t priority, and I think everybody agree on this). >>=20 >> rjs> Agreed -- I think it would be useful to allow definitions of segmen= ts to identify different types of "service", since there appear to be some = use cases (e.g., the explicit exit selection case) which require a segment = type describing something that is not explicitly IGP-based. >>=20 >>>=20 >>> It would be interresting to have a feedback from the mailinglist on thi= s specific point. >>>=20 >>> IMHO, there is a strong interrest to explore the service actions bound = to segment in a second step keeping forwarding as a priority. >>>=20 >>> Apart of this problem, here is a merge try of the two good proposals (I= 'm putting '<>' on hot topics :) ) : >>>=20 >>>=20 >>> ------------------------------------------------------------------- >>> Name: >>> Charter: >>>=20 >>>=20 >>> Introduction >>> ------------ >>> The following use cases: >>> . Path computation based on awareness of utilization or performance >>> data, within both centralized and distributed environments, . Multi-top= ology (dual planes, disjoint trees), . Simplification and reduction of sign= aling components (scaling), . Combined application and network layer path s= pecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>>=20 >>> have triggered work on the definition of new architecture and protocol = extensions allowing to combine well known shortest path based routing parad= igms with source/explicit routing methods. Some of these extensions have be= en implemented already. >>>=20 >>>=20 >>> Objective >>> --------- >>>=20 >>> Define an architecture where a node can steer a packet through a networ= k or set of networks (interdomain) on any path (shortest, non shortest, exp= licit, ). >>>=20 >>> In this architecture, routers are sharing a common trust model and are = forming a domain. >>> Within this domain, a node can specify a path between itself and any de= stination in the domain. . >>=20 >> rjs> To clarify here, we define that our domain is under a common trust = model (essentially, under common administrative control?), but then go on t= o talk about inter-domain elsewhere. Can we perhaps clarify (by defining a = specific " domain" nomenclature) and say something like: >>=20 >> "In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a n= ode to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, no= n-shortest, explicit or based on other characteristics specified by segment= identifiers)." >>=20 >>> It may then send any packet that passes through it through any path tha= t it has specified and that is conform to the security rules. Downstream ro= uters along the path within the domain forward the packet as spe= cified by the router at the head-end of the path. >>>=20 >>> The architecture should support centralized and distributed path comput= ation. >>>=20 >>>=20 >>> Work items : >>> ------------------ >>>=20 >>> The working group is chartered for the following ordered lis= t of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with >>> the security considerations. The architecture framework and security >>> considerations must address the relations between domains (inter domain= ). >>=20 >> rjs> And then here "networks forming the domain"? >>=20 >> Thanks for the efforts, >> r. >>=20 >>> - Having identified use-cases, architecture and security, the WG will >>> identify gaps between currently available technologies and use-case >>> requirements. >>> - The WG will then define requirements for extensions to existing >>> protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>>=20 >>> Documents : >>> ------------------ >>> . Use Cases >>> . Architecture including security considerations >>> - Protocol extension requirements >>> . Interoperability Report >>>=20 >>>=20 >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coord= ination with this WG, and in agreement with the WG chairs and responsible A= Ds. >>>=20 >>>=20 >>>=20 >>> Hope it helps to progress on the definition. >>>=20 >>>=20 >>> Stephane >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi 6 >>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the >>> next steps >>>=20 >>> hi stephane, >>>=20 >>> here is a revised draft charter as per your comments. >>>=20 >>> --- >>>=20 >>> domain contains a set of routers with the following >>> characteristics: >>>=20 >>> - They form a connected network >>> - They can forward traffic through any path within the network using >>> shortest path, or any other (e.g., an explicit) path >>> - They share a common trust model. In this model, any router within >>> the domain can specify a path between itself and any other router in >>> the domain. It may then send any packet that passes through it >>> through any path that it has specified and that is conform to the >>> security rules. Downstream routers along the path within the >>> domain forward the packet as specified by the router at >>> the head-end of the path. >>>=20 >>> The working group is chartered for the following ordered lis= t of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with >>> the security considerations. The architecture framework and security >>> considerations must address the relations between domains (interdomain)= . >>> - Having identified use-cases, architecture and security, the WG will >>> identify gaps between currently available technologies and use-case >>> requirements. >>> - The WG will then define requirements for extensions to existing >>> protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>> Protocol work may be carried out in this working group or in other work= ing groups responsible for the protocols, in coordination with this WG, and= in agreement with the WG chairs and responsible ADs. >>> However, no protocol work will be adopted by a working group to address= the identified use-cases until the requirements document motivating the pr= otocol work has been sent to the IESG for publication as an RFC. >>>=20 >>> --- >>>=20 >>> /hannes >>>=20 >>> On Sep 4, 2013, at 10:02 AM, wrote: >>>=20 >>>> Hannes, >>>>=20 >>>> In case, we are using only directed forwarding (adjacency segment), >>>> could we still talk about tunneling ? (it's a very very small tunnel) = Moreover talking about "stacking" is really dataplane agnostic (MPLS) ... >>>>=20 >>>> In the proposed segment routing architectural concepts, segments are a= t the same "level" and pointer moves on the segment list, then the MPLS ins= tantiation is performing this using stacking ... >>>>=20 >>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen solu= tion and it's closing the door to something else ... >>>>=20 >>>> Finally, about the "routing" word, routing is essentially a "forward" = action which may limit the scope of what we can do by using a segment list.= Actions associated with a segment could be something else than forwarding. >>>>=20 >>>> Do we want in the charter to limit the scope to routing actions ? >>>>=20 >>>> I have no solution today to propose for the naming, but I completely a= gree with Loa, to first focus on working on the charter, and define a clear= scope of the work and then the name will be easier to find. >>>>=20 >>>> Regarding your charter proposal : >>>>=20 >>>> -------- >>>>=20 >>>> - They form a connected network >>>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>>=20 >>>> - They can forward traffic through the shortest paths or paths other t= han the shortest (the latter called explicitly routed paths, or explicit pa= ths) >>>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>>>=20 >>>> - They share a common trust model. In this model, any router within th= e ERD can specify an explicit path between itself and any other router in t= he ERD. It can then send any packet that passes through it through any path= that it has specified. >>>> [SLI] Security considerations may have to be addressed in the >>>> charter , especially for the interAS case (trust yes, but not sure >>>> access to everything may not be good) >>>>=20 >>>> Downstream routers within the ERD forward the packet as specified by t= he router at the head-end of the path. >>>> [SLI] Yes, but any router in the middle may be able to change the end = to end explicit path. >>>>=20 >>>>=20 >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between curre= ntly available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>>=20 >>>> [SLI] Agree, I would add : >>>> - defining the architecture framework >>>> - analysing the security considerisations >>>>=20 >>>>=20 >>>> --------- >>>>=20 >>>>=20 >>>> Here would be my proposal to extend yours : >>>>=20 >>>> A domain contains a set of routers with the foll= owing characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through any path within the network using >>>> shortest path, non shortest path or explicit path >>>> - They may provide other types of services than forwarding and they ca= n enforce service actions in the path. >>>> - They share a common trust model. In this model, any router within th= e domain can specify a path between itself and any other router in the doma= in. It may then send any packet that passes through it through any path tha= t it has specified and that is conform to the security rules. Downstream ro= uters within the ERD forward the packet as specified by the router at the h= ead-end of the path. >>>>=20 >>>> The working group is chartered for the following ordered list o= f work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated with t= he security considerations. The architecture framework and security conside= rations must address the relations between domains (interdomain). >>>> - Having identified use-cases, architecture and security, the WG will = identify gaps between currently available technologies and use-case require= ments. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding definition. >>>>=20 >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols, in coordination with this WG, an= d in agreement with the WG chairs and responsible ADs. However, no protocol= work will be adopted by a working group to address the ERD use-cases until= the requirements document motivating the protocol work has been sent to th= e IESG for publication as an RFC. >>>>=20 >>>> -----Message d'origine----- >>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 : L= oa >>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of >>>> STATUS BOF and the next steps >>>>=20 >>>> good point - what about this charter proposal ? >>>>=20 >>>> --- >>>>=20 >>>> Stacked Tunnels for Explicit Routing (STER) >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> A explicit routing domain (ERD) contains a set of routers with the fol= lowing characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through the shortest paths or paths other >>>> than the shortest (the latter called explicitly routed paths, or >>>> explicit paths) >>>> - They share a common trust model. In this model, any router within th= e ERD can specify an explicit path between itself and any other router in t= he ERD. It can then send any packet that passes through it through any path= that it has specified. Downstream routers within the ERD forward the packe= t as specified by the router at the head-end of the path. >>>>=20 >>>> The STER working group is chartered for the following ordered list of = work items: >>>>=20 >>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>> - Having identified use-cases, the WG will identify gaps between curre= ntly available technologies and use-case requirements. >>>> - The WG will then define requirements for extensions to existing prot= ocols or new protocols that address gaps that are identified. >>>>=20 >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols, in coordination with this WG, an= d in agreement with the WG chairs and responsible ADs. However, no protocol= work will be adopted by a working group to address the ERD use-cases until= the requirements document motivating the protocol work has been sent to th= e IESG for publication as an RFC. >>>>=20 >>>> --- >>>>=20 >>>> >>>>=20 >>>> /hannes >>>>=20 >>>>=20 >>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> Excuse me if I'm slightly out of the loop, but so far I have not >>>>> seen a charter proposal, if there is one please point me to it. >>>>>=20 >>>>> It seems a bit odd to put the cart (what the wg should do) before >>>>> the horse (wg name). If we drill down the the charter first the wg >>>>> name might be easier to figure out. >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> PS >>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>> " If the WG charter is limited to source routing, how will we handle= the "non source routing" use cases of segment routing ? In another working= group ? So we will go back to the WG synchronization issue that has been r= aised for this technology ..." >>>>>>=20 >>>>>> That's why I suggested SRV2. We are revisiting source routing with n= ew concepts. More generic number/action behavior. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf Of stephane.litkowski@orange.com >>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>> To: AshwoodsmithPeter >>>>>> Cc: status@ietf.org >>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>>=20 >>>>>> There was a misunderstanding in my small comment :) so I will explai= n more : >>>>>>=20 >>>>>> In segment routing, you have more than basic source routing : segmen= t routing is just associate a segment number to an action and then combine = segment as you want, yes you can do source routing, but you also can do mor= e. >>>>>>=20 >>>>>> In the other hand, I completely agree with your statement that >>>>>> source routing is generic and dataplane agnostic, as segment routing= is ... >>>>>> (segment routing is not a new dataplane ...) >>>>>>=20 >>>>>> Now the definition of the WG naming must be inline with the >>>>>> charter that will be defined ... (draft today) >>>>>>=20 >>>>>> Based on the already existing consensus (at least for MPLS dataplane= ) brought up during Berlin STATUS BOF meeting, segment routing sounds to be= a good target candidate. >>>>>>=20 >>>>>> So now, do we want to do more in the WG charter than just make progr= essing segment routing architecture and uses cases document and ensure coor= dination for the standardization of this technology ? >>>>>>=20 >>>>>> Do we want to standardize other technologies in this WG ? I don't th= ink so, based on Stewart's conclusion email from the BOF :"A new WG focused= solely on SR therefore needs to be create" >>>>>>=20 >>>>>> If the WG charter is limited to source routing, how will we handle t= he "non source routing" use cases of segment routing ? In another working g= roup ? So we will go back to the WG synchronization issue that has been rai= sed for this technology ... >>>>>>=20 >>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>>=20 >>>>>> Feedback ? >>>>>>=20 >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>>>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet := Re: >>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>=20 >>>>>> The term "source routing" has been around for a very long time and i= s data path agnostic. Its also the term used in the literature etc so my pr= eference is to stick with this existing well known and data path agnostic t= erm. >>>>>>=20 >>>>>> Peter >>>>>>=20 >>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> "Source routing" is just a subcase of segment routing ... as it is = for IP routing ... >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 =C0= : >>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); Joh= n G. >>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>>> BOF and the next steps >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> What is this 'segment routing' silliness? The correct term is 'sou= rce routing'. >>>>>>>=20 >>>>>>> Yours Irrespectively, >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>> On Behalf Of Mark Townsley >>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>> To: Victor Kuarsingh >>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>> (stbryant) >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>=20 >>>>>>>>> All, >>>>>>>>>=20 >>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>=20 >>>>>>>>> I note this since attempting to come up with an all >>>>>>>>> encompassing acronym will be difficult and Segment Routing is >>>>>>>>> generic enough to associate to multiple functions. >>>>>>>>=20 >>>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>>> have to have acronyms, but they do need to have an 8-char >>>>>>>> limited short name for the various automated tools not to break. >>>>>>>>=20 >>>>>>>> - Mark >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Victor K >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>=20 >>>>>>>>>> Roberta >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPad >>>>>>>>>>=20 >>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Segment Routing WG >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>=20 >>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> The second task, which hopefully should be relatively easy, >>>>>>>>>>>> is to find a better working name for the WG, since it has >>>>>>>>>>>> been put to me a number of times that STATUS is going to be >>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> _________________________________________________________________ >>>>>>> _ _ _ __ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteu= r et le detruire ainsi que les pieces jointes. Les messages electroniques e= tant susceptibles d'alteration, Orange decline toute responsabilite si ce m= essage a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should no= t be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> __________________________________________________________________ >>>>>> _ _ _ ____________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >> ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From hannes@juniper.net Tue Sep 10 10:27:27 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93221F9C38 for ; Tue, 10 Sep 2013 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[AWL=-2.452, BAYES_00=-2.599, FRT_INTEREST=3.579] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3scAYRpsG1Ju for ; Tue, 10 Sep 2013 10:27:22 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5A32F21F9C06 for ; Tue, 10 Sep 2013 10:27:21 -0700 (PDT) Received: from mail74-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE016.bigfish.com (10.174.4.79) with Microsoft SMTP Server id 14.1.225.22; Tue, 10 Sep 2013 17:27:20 +0000 Received: from mail74-db8 (localhost [127.0.0.1]) by mail74-db8-R.bigfish.com (Postfix) with ESMTP id 3D90BDC01AE; Tue, 10 Sep 2013 17:27:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -73 X-BigFish: VPS-73(zz62a3I98dI9371Ic89bh936eI542I1432I15caKJ1447I14ffIdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail74-db8: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail74-db8 (localhost.localdomain [127.0.0.1]) by mail74-db8 (MessageSwitch) id 1378834037484332_25925; Tue, 10 Sep 2013 17:27:17 +0000 (UTC) Received: from DB8EHSMHS032.bigfish.com (unknown [10.174.8.228]) by mail74-db8.bigfish.com (Postfix) with ESMTP id 6F693A40041; Tue, 10 Sep 2013 17:27:17 +0000 (UTC) Received: from BL2PRD0512HT003.namprd05.prod.outlook.com (157.56.242.197) by DB8EHSMHS032.bigfish.com (10.174.4.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 10 Sep 2013 17:27:13 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 10 Sep 2013 17:27:06 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: Date: Tue, 10 Sep 2013 19:27:03 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> To: "Stefano Previdi (sprevidi)" X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephane Litkowski , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:27:27 -0000 stefano, On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: >=20 > On Sep 10, 2013, at 1:25 PM, wrote: >=20 >> Agree on all proposal except : >>=20 >> "[SP] The architecture will support tunnel and non-tunnel paradigms >> The architecture will support multiple dataplanes: MPLS and V6" >>=20 >> I don't see the reason for this ... IMHO, the gap analysis and = requirements inventory will result on saying or not >=20 >=20 > [SP] While I understand what brought the following statements > in the proposed charter: > "Having identified use-cases, architecture and security,=20 > the WG will identify gaps between currently available=20 > technologies and use-case requirements. > The WG will then define requirements for extensions to=20 > existing protocols or new protocols that address gaps=20 > that are identified." >=20 > I'd like to point out with better precision what are the=20 > directions we are ALREADY engaged into: dataplanes and=20 > paradigms. As I mentioned in my charter proposal, we do have=20 > implementations and multi-vendor interoperability tests will > happen soon. So, I just want to be sure we don't ignore this=20 > reality. HG> just because you have an implementation for does not = constitute community interest. we are trying to build here a charter that matches what a broader community wants. if the use-case that you're = concerned about (service-chaining and a new internet data plane #4) are = compelling enough the group will work on it, but mandating that into the = charter, without asking the though questions first seems a wrong start to me. /hannes >> : we must use tunnels and/or non tunnels, and the following = dataplanes ... But I don't see the reason to put solutions directly in = the charter ... >=20 >=20 > these are not solutions these are way to avoid boundaries in the > framework. >=20 > Thanks. > s. >=20 >=20 >> Could you explain your point ? >>=20 >>=20 >> updated with the other comments : >>=20 >> ------------------------------------------------------------------- >> Name: >> Charter: >>=20 >>=20 >> Introduction >> ------------ >> The following use cases: >> . Path computation based on awareness of utilization or performance >> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>=20 >> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>=20 >>=20 >> Objective >> --------- >>=20 >> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path without requiring = to maintain state along the path, other than in the ingress node. >>=20 >> A node may be any type of device including routers or appliances. >>=20 >> In this architecture, nodes sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers). >>=20 >> It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. = Downstream nodes along the path within the domain forward the = packet by using the informations inserted by the node at the head-end >>=20 >> The architecture should support centralized and distributed path = computation. >>=20 >> The architecture should support OAM functions. >>=20 >> The architecture should allow different mechanisms through which >> a path is constructed. SR allows a variety of mechanisms, not >> confined IGP/BGP path computation. >>=20 >> As MPLS dataplane is largely deployed, the WG should avoid = any modification in the MPLS dataplane when defining the architecture. >>=20 >>=20 >> Work items : >> ------------------ >>=20 >> The working group is chartered for the following ordered = list of work items: >>=20 >> - The first goal of the WG is to identify use-cases. >> - The WG will then define the architecture framework associated with >> the security considerations. The architecture framework and security >> considerations must address the relations between networks forming = the domain (interAS). >> - Having identified use-cases, architecture and security, the WG will >> identify gaps between currently available technologies and use-case >> requirements. >> - The WG will then define requirements for extensions to existing >> protocols or new protocols that address gaps that are identified. >> - The WG will first focus on the intra-domain forwarding definition. >>=20 >>=20 >> Documents : >> ------------------ >> . Use Cases >> . Architecture including security considerations >> - Protocol extension requirements >> . Interoperability Report >>=20 >>=20 >> Required protocol extensions are carried out in working groups = responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be = carried out by the WG. >>=20 >> -----Message d'origine----- >> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >> Envoy=E9 : mardi 10 septembre 2013 12:30 >> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir >> Cc : Hannes Gredler; status@ietf.org >> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : = try to merge ... >>=20 >> Hi Stephane, Rob, >>=20 >> one preliminary remark: I prefer to use he therm "node" rather than = "router". Use cases, such as Service Chaining requires that terminology. >>=20 >> some other comments below... >>=20 >>=20 >> On Sep 10, 2013, at 11:19 AM, wrote: >>> Souns good to me, (adding OAM also) >>>=20 >>> New recap : >>>=20 >>> ------------------------------------------------------------------- >>> Name: >>> Charter: >>>=20 >>>=20 >>> Introduction >>> ------------ >>> The following use cases: >>> . Path computation based on awareness of utilization or performance >>> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>>=20 >>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>=20 >>>=20 >>> Objective >>> --------- >>>=20 >>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path. >>=20 >>=20 >> [SP] As stated above, I'm fine with the above definition but I >> assume this includes service chaining and that by "network >> or set of networks" you intend "nodes" which may include >> others things than just routers. >>=20 >> [SLI] Agree >>=20 >>=20 >>> In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers). >>=20 >>=20 >> [SP] without requiring to maintain state along the path, other >> than in the ingress node. >>=20 >> [SLI] Agree >>=20 >>=20 >>> It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >>=20 >>>=20 >>> The architecture should support centralized and distributed path = computation. >>>=20 >>> The architecture should support OAM functions. >>=20 >>=20 >> [SP] The architecture should allow different mechanisms through which >> a path is constructed. SR allows a variety of mechanisms, not >> confined IGP/BGP path computation. >>=20 >> [SLI] Agree >>=20 >>> Work items : >>> ------------------ >>>=20 >>> The working group is chartered for the following ordered = list of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with >>> the security considerations. The architecture framework and security >>> considerations must address the relations between networks forming = the domain (interAS). >>> - Having identified use-cases, architecture and security, the WG = will >>> identify gaps between currently available technologies and use-case >>> requirements. >>> - The WG will then define requirements for extensions to existing >>> protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>=20 >>=20 >> [SP] The architecture will support tunnel and non-tunnel paradigms >> The architecture will support multiple dataplanes: MPLS and V6 >>=20 >>=20 >> Thanks. >> s. >>=20 >>=20 >>> Documents : >>> ------------------ >>> . Use Cases >>> . Architecture including security considerations >>> - Protocol extension requirements >>> . Interoperability Report >>>=20 >>>=20 >>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), = in coordination with this WG, and in agreement with the WG chairs and = responsible ADs. >>>=20 >>> -----Message d'origine----- >>> De : Rob Shakir [mailto:rjs@rob.sh] >>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane = DTF/DERX >>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org = Objet >>> : Re: [Status] Good charter proposals from Hannes and Stefano : try = to merge ... >>>=20 >>> Hi Stephane, >>>=20 >>> Thanks for this, looks good! Comments in-line marked rjs>. >>>=20 >>> On 10 Sep 2013, at 08:50, wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I'm creating a new mail topic because the "Summary of STATUS BOF = ..." >>>> starts to be unreadable :) >>>>=20 >>>> Hannes and Stefano send to us two charter proposals that sounds = good to me. >>>>=20 >>>> The main difference between the two proposals is that Stefano = propose a segment bound to any type of instruction (forwarding, = application or service based) while Hannes is focusing on forwarding = actions (which is the first priority, and I think everybody agree on = this). >>>=20 >>> rjs> Agreed -- I think it would be useful to allow definitions of = segments to identify different types of "service", since there appear to = be some use cases (e.g., the explicit exit selection case) which require = a segment type describing something that is not explicitly IGP-based. >>>=20 >>>>=20 >>>> It would be interresting to have a feedback from the mailinglist on = this specific point. >>>>=20 >>>> IMHO, there is a strong interrest to explore the service actions = bound to segment in a second step keeping forwarding as a priority. >>>>=20 >>>> Apart of this problem, here is a merge try of the two good = proposals (I'm putting '<>' on hot topics :) ) : >>>>=20 >>>>=20 >>>> ------------------------------------------------------------------- >>>> Name: >>>> Charter: >>>>=20 >>>>=20 >>>> Introduction >>>> ------------ >>>> The following use cases: >>>> . Path computation based on awareness of utilization or performance >>>> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>>>=20 >>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>=20 >>>>=20 >>>> Objective >>>> --------- >>>>=20 >>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path (shortest, non = shortest, explicit, ). >>>>=20 >>>> In this architecture, routers are sharing a common trust model and = are forming a domain. >>>> Within this domain, a node can specify a path between itself and = any destination in the domain. . >>>=20 >>> rjs> To clarify here, we define that our domain is under a common = trust model (essentially, under common administrative control?), but = then go on to talk about inter-domain elsewhere. Can we perhaps clarify = (by defining a specific " domain" nomenclature) and say = something like: >>>=20 >>> "In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers)." >>>=20 >>>> It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >>>>=20 >>>> The architecture should support centralized and distributed path = computation. >>>>=20 >>>>=20 >>>> Work items : >>>> ------------------ >>>>=20 >>>> The working group is chartered for the following ordered = list of work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated = with >>>> the security considerations. The architecture framework and = security >>>> considerations must address the relations between domains (inter = domain). >>>=20 >>> rjs> And then here "networks forming the domain"? >>>=20 >>> Thanks for the efforts, >>> r. >>>=20 >>>> - Having identified use-cases, architecture and security, the WG = will >>>> identify gaps between currently available technologies and use-case >>>> requirements. >>>> - The WG will then define requirements for extensions to existing >>>> protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>=20 >>>>=20 >>>> Documents : >>>> ------------------ >>>> . Use Cases >>>> . Architecture including security considerations >>>> - Protocol extension requirements >>>> . Interoperability Report >>>>=20 >>>>=20 >>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), = in coordination with this WG, and in agreement with the WG chairs and = responsible ADs. >>>>=20 >>>>=20 >>>>=20 >>>> Hope it helps to progress on the definition. >>>>=20 >>>>=20 >>>> Stephane >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi = 6 >>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the >>>> next steps >>>>=20 >>>> hi stephane, >>>>=20 >>>> here is a revised draft charter as per your comments. >>>>=20 >>>> --- >>>>=20 >>>> domain contains a set of routers with the following >>>> characteristics: >>>>=20 >>>> - They form a connected network >>>> - They can forward traffic through any path within the network = using >>>> shortest path, or any other (e.g., an explicit) path >>>> - They share a common trust model. In this model, any router within >>>> the domain can specify a path between itself and any other router = in >>>> the domain. It may then send any packet that passes through it >>>> through any path that it has specified and that is conform to the >>>> security rules. Downstream routers along the path within the >>>> domain forward the packet as specified by the router at >>>> the head-end of the path. >>>>=20 >>>> The working group is chartered for the following ordered = list of work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated = with >>>> the security considerations. The architecture framework and = security >>>> considerations must address the relations between domains = (interdomain). >>>> - Having identified use-cases, architecture and security, the WG = will >>>> identify gaps between currently available technologies and use-case >>>> requirements. >>>> - The WG will then define requirements for extensions to existing >>>> protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>=20 >>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. >>>> However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >>>>=20 >>>> --- >>>>=20 >>>> /hannes >>>>=20 >>>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>>=20 >>>>> Hannes, >>>>>=20 >>>>> In case, we are using only directed forwarding (adjacency = segment), >>>>> could we still talk about tunneling ? (it's a very very small = tunnel) Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>>>=20 >>>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the = MPLS instantiation is performing this using stacking ... >>>>>=20 >>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen = solution and it's closing the door to something else ... >>>>>=20 >>>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>>=20 >>>>> Do we want in the charter to limit the scope to routing actions ? >>>>>=20 >>>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>>=20 >>>>> Regarding your charter proposal : >>>>>=20 >>>>> -------- >>>>>=20 >>>>> - They form a connected network >>>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>>=20 >>>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>>> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>>>=20 >>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. >>>>> [SLI] Security considerations may have to be addressed in the >>>>> charter , especially for the interAS case (trust yes, but not sure >>>>> access to everything may not be good) >>>>>=20 >>>>> Downstream routers within the ERD forward the packet as specified = by the router at the head-end of the path. >>>>> [SLI] Yes, but any router in the middle may be able to change the = end to end explicit path. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>=20 >>>>> [SLI] Agree, I would add : >>>>> - defining the architecture framework >>>>> - analysing the security considerisations >>>>>=20 >>>>>=20 >>>>> --------- >>>>>=20 >>>>>=20 >>>>> Here would be my proposal to extend yours : >>>>>=20 >>>>> A domain contains a set of routers with the = following characteristics: >>>>>=20 >>>>> - They form a connected network >>>>> - They can forward traffic through any path within the network = using >>>>> shortest path, non shortest path or explicit path >>>>> - They may provide other types of services than forwarding and = they can enforce service actions in the path. >>>>> - They share a common trust model. In this model, any router = within the domain can specify a path between itself and any other router = in the domain. It may then send any packet that passes through it = through any path that it has specified and that is conform to the = security rules. Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>=20 >>>>> The working group is chartered for the following ordered = list of work items: >>>>>=20 >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 = : Loa >>>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of >>>>> STATUS BOF and the next steps >>>>>=20 >>>>> good point - what about this charter proposal ? >>>>>=20 >>>>> --- >>>>>=20 >>>>> Stacked Tunnels for Explicit Routing (STER) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>>>=20 >>>>> - They form a connected network >>>>> - They can forward traffic through the shortest paths or paths = other >>>>> than the shortest (the latter called explicitly routed paths, or >>>>> explicit paths) >>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. Downstream routers within the = ERD forward the packet as specified by the router at the head-end of the = path. >>>>>=20 >>>>> The STER working group is chartered for the following ordered list = of work items: >>>>>=20 >>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>> - The WG will then define requirements for extensions to existing = protocols or new protocols that address gaps that are identified. >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this = WG, and in agreement with the WG chairs and responsible ADs. However, no = protocol work will be adopted by a working group to address the ERD = use-cases until the requirements document motivating the protocol work = has been sent to the IESG for publication as an RFC. >>>>>=20 >>>>> --- >>>>>=20 >>>>> >>>>>=20 >>>>> /hannes >>>>>=20 >>>>>=20 >>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> Excuse me if I'm slightly out of the loop, but so far I have not >>>>>> seen a charter proposal, if there is one please point me to it. >>>>>>=20 >>>>>> It seems a bit odd to put the cart (what the wg should do) before >>>>>> the horse (wg name). If we drill down the the charter first the = wg >>>>>> name might be easier to figure out. >>>>>>=20 >>>>>> /Loa >>>>>>=20 >>>>>> PS >>>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>>=20 >>>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>>=20 >>>>>>> Peter >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>> Behalf Of stephane.litkowski@orange.com >>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>> To: AshwoodsmithPeter >>>>>>> Cc: status@ietf.org >>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>>=20 >>>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>>=20 >>>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>>=20 >>>>>>> In the other hand, I completely agree with your statement that >>>>>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>>>>> (segment routing is not a new dataplane ...) >>>>>>>=20 >>>>>>> Now the definition of the WG naming must be inline with the >>>>>>> charter that will be defined ... (draft today) >>>>>>>=20 >>>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>>=20 >>>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>>>=20 >>>>>>> Do we want to standardize other technologies in this WG ? I = don't think so, based on Stewart's conclusion email from the BOF :"A new = WG focused solely on SR therefore needs to be create" >>>>>>>=20 >>>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>>=20 >>>>>>> If the WG is focused on SR, let's use a name in relation with = SR. >>>>>>>=20 >>>>>>> Feedback ? >>>>>>>=20 >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; = Alvaro >>>>>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) = Objet : Re: >>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>=20 >>>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc = so my preference is to stick with this existing well known and data path = agnostic term. >>>>>>>=20 >>>>>>> Peter >>>>>>>=20 >>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>>>=20 >>>>>>>> Stephane >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] = De >>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 = =C0 : >>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); = John G. >>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; = status@ietf.org; >>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of = STATUS >>>>>>>> BOF and the next steps >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> What is this 'segment routing' silliness? The correct term is = 'source routing'. >>>>>>>>=20 >>>>>>>> Yours Irrespectively, >>>>>>>>=20 >>>>>>>> John >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>>> On Behalf Of Mark Townsley >>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>> To: Victor Kuarsingh >>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>>> (stbryant) >>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>=20 >>>>>>>>>> All, >>>>>>>>>>=20 >>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>=20 >>>>>>>>>> I note this since attempting to come up with an all >>>>>>>>>> encompassing acronym will be difficult and Segment Routing is >>>>>>>>>> generic enough to associate to multiple functions. >>>>>>>>>=20 >>>>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>>>> have to have acronyms, but they do need to have an 8-char >>>>>>>>> limited short name for the various automated tools not to = break. >>>>>>>>>=20 >>>>>>>>> - Mark >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Victor K >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>=20 >>>>>>>>>>> Roberta >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPad >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>=20 >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> The second task, which hopefully should be relatively = easy, >>>>>>>>>>>>> is to find a better working name for the WG, since it has >>>>>>>>>>>>> been put to me a number of times that STATUS is going to = be >>>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> = _________________________________________________________________ >>>>>>>> _ _ _ __ ___________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si = vous >>>>>>>> avez recu ce message par erreur, veuillez le signaler a = l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> = __________________________________________________________________ >>>>>>> _ _ _ ____________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>> Senior MPLS Expert loa@pi.nu >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>> = ____________________________________________________________________ >>>>> _ _ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> = _____________________________________________________________________ >>>> _ ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>=20 >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >=20 >=20 >=20 From sprevidi@cisco.com Tue Sep 10 10:35:10 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ED921E8092 for ; Tue, 10 Sep 2013 10:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.02 X-Spam-Level: X-Spam-Status: No, score=-107.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LenBIa5Cm1dK for ; Tue, 10 Sep 2013 10:35:05 -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 4134521E808E for ; Tue, 10 Sep 2013 10:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44337; q=dns/txt; s=iport; t=1378834505; x=1380044105; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jgwIBrjh4MfAmpg7rH11K4/f8NzbCVGRTTiy3xmS7qA=; b=RBnxhtWf7Ut1ivAd3VOBI4omG+fakksPxtgeeDMS/WpvyNJwXS1hFYiP p2oTmaEUh+5hm1pmrgLXQxM3OkMta3DLrMPEHvoU0nFxXbAljymZOZAfh GmY4MY2OPnEZxe8fKFOLY33mc0msCf6kKqt530DSo0irLePb+lR2KEZeE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACNXL1KtJXG9/2dsb2JhbABRCoMHOFHCQIEmFnSCJQEBAQQBAQEXAUwEAwQHDAICAgEIEQEDAQEBCh0HGwwLFAMGCAIEDgUIDAeHZwyyM41PBASODgYEAQWBBgIGJgUHAgSDF4EAA4h+oGODIIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.90,879,1371081600"; d="scan'208";a="254952316" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 10 Sep 2013 17:34:59 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8AHYxwr016044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 17:34:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 12:34:58 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAP//uVuAgACzLACAAAgBgIAAAjCA Date: Tue, 10 Sep 2013 17:34:58 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.204.178] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <42834775116C274891B86C29A88227CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stephane Litkowski , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:35:10 -0000 Hannes, On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote: > stefano, >=20 > On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: >=20 >>=20 >> On Sep 10, 2013, at 1:25 PM, wrote: >>=20 >>> Agree on all proposal except : >>>=20 >>> "[SP] The architecture will support tunnel and non-tunnel paradigms >>> The architecture will support multiple dataplanes: MPLS and V6" >>>=20 >>> I don't see the reason for this ... IMHO, the gap analysis and requirem= ents inventory will result on saying or not >>=20 >>=20 >> [SP] While I understand what brought the following statements >> in the proposed charter: >> "Having identified use-cases, architecture and security,=20 >> the WG will identify gaps between currently available=20 >> technologies and use-case requirements. >> The WG will then define requirements for extensions to=20 >> existing protocols or new protocols that address gaps=20 >> that are identified." >>=20 >> I'd like to point out with better precision what are the=20 >> directions we are ALREADY engaged into: dataplanes and=20 >> paradigms. As I mentioned in my charter proposal, we do have=20 >> implementations and multi-vendor interoperability tests will >> happen soon. So, I just want to be sure we don't ignore this=20 >> reality. >=20 > HG> just because you have an implementation for does not constitute > community interest. we are trying to build here a charter that > matches what a broader community wants. if the use-case that you're co= ncerned > about (service-chaining and a new internet data plane #4) are compelli= ng > enough the group will work on it, but mandating that into the charter, > without asking the though questions first seems a wrong start to me. [SP] Sorry to contradict but it's the exact opposite. If a group=20 of vendors decide to invest in implementations is because=20 they received, analyzed, processed a set of requirements=20 coming for operators who know pretty well what they do, what=20 they want to deploy and the technology they want the vendors=20 to deliver. This fits the definition of "community interest". My point is that I strongly _suggest_ IETF WG (any) not to=20 neglect these facts and not write a down a charter that will=20 take the "community" to argue whether "RSVP can do the job"=20 for the next 3 years. Having said that, whoever does NOT believe in the benefit of=20 a newly proposed technology, is always free to not implement=20 it and to not deploy it. s. >=20 > /hannes >=20 >>> : we must use tunnels and/or non tunnels, and the following dataplanes = ... But I don't see the reason to put solutions directly in the charter ... >>=20 >>=20 >> these are not solutions these are way to avoid boundaries in the >> framework. >>=20 >> Thanks. >> s. >>=20 >>=20 >>> Could you explain your point ? >>>=20 >>>=20 >>> updated with the other comments : >>>=20 >>> ------------------------------------------------------------------- >>> Name: >>> Charter: >>>=20 >>>=20 >>> Introduction >>> ------------ >>> The following use cases: >>> . Path computation based on awareness of utilization or performance >>> data, within both centralized and distributed environments, . Multi-top= ology (dual planes, disjoint trees), . Simplification and reduction of sign= aling components (scaling), . Combined application and network layer path s= pecification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>>=20 >>> have triggered work on the definition of new architecture and protocol = extensions allowing to combine well known shortest path based routing parad= igms with source/explicit routing methods. Some of these extensions have be= en implemented already. >>>=20 >>>=20 >>> Objective >>> --------- >>>=20 >>> Define an architecture where a node can steer a packet through a networ= k or set of networks (interdomain) on any path without requiring to maintai= n state along the path, other than in the ingress node. >>>=20 >>> A node may be any type of device including routers or appliances. >>>=20 >>> In this architecture, nodes sharing a common trust model form a domain. The architecture defined by this working group will allow a nod= e to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non-= shortest, explicit or based on other characteristics specified by segment i= dentifiers). >>>=20 >>> It may then send any packet that passes through it through any path tha= t it has specified and that is conform to the security rules. Downstream no= des along the path within the domain forward the packet by using= the informations inserted by the node at the head-end >>>=20 >>> The architecture should support centralized and distributed path comput= ation. >>>=20 >>> The architecture should support OAM functions. >>>=20 >>> The architecture should allow different mechanisms through which >>> a path is constructed. SR allows a variety of mechanisms, not >>> confined IGP/BGP path computation. >>>=20 >>> As MPLS dataplane is largely deployed, the WG should avoid a= ny modification in the MPLS dataplane when defining the architecture. >>>=20 >>>=20 >>> Work items : >>> ------------------ >>>=20 >>> The working group is chartered for the following ordered lis= t of work items: >>>=20 >>> - The first goal of the WG is to identify use-cases. >>> - The WG will then define the architecture framework associated with >>> the security considerations. The architecture framework and security >>> considerations must address the relations between networks forming the = domain (interAS). >>> - Having identified use-cases, architecture and security, the WG will >>> identify gaps between currently available technologies and use-case >>> requirements. >>> - The WG will then define requirements for extensions to existing >>> protocols or new protocols that address gaps that are identified. >>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>>=20 >>> Documents : >>> ------------------ >>> . Use Cases >>> . Architecture including security considerations >>> - Protocol extension requirements >>> . Interoperability Report >>>=20 >>>=20 >>> Required protocol extensions are carried out in working groups responsi= ble (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by t= he WG. >>>=20 >>> -----Message d'origine----- >>> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>> Envoy=E9 : mardi 10 septembre 2013 12:30 >>> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir >>> Cc : Hannes Gredler; status@ietf.org >>> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : t= ry to merge ... >>>=20 >>> Hi Stephane, Rob, >>>=20 >>> one preliminary remark: I prefer to use he therm "node" rather than "ro= uter". Use cases, such as Service Chaining requires that terminology. >>>=20 >>> some other comments below... >>>=20 >>>=20 >>> On Sep 10, 2013, at 11:19 AM, wrote: >>>> Souns good to me, (adding OAM also) >>>>=20 >>>> New recap : >>>>=20 >>>> ------------------------------------------------------------------- >>>> Name: >>>> Charter: >>>>=20 >>>>=20 >>>> Introduction >>>> ------------ >>>> The following use cases: >>>> . Path computation based on awareness of utilization or performance >>>> data, within both centralized and distributed environments, . Multi-to= pology (dual planes, disjoint trees), . Simplification and reduction of sig= naling components (scaling), . Combined application and network layer path = specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>>>=20 >>>> have triggered work on the definition of new architecture and protocol= extensions allowing to combine well known shortest path based routing para= digms with source/explicit routing methods. Some of these extensions have b= een implemented already. >>>>=20 >>>>=20 >>>> Objective >>>> --------- >>>>=20 >>>> Define an architecture where a node can steer a packet through a netwo= rk or set of networks (interdomain) on any path. >>>=20 >>>=20 >>> [SP] As stated above, I'm fine with the above definition but I >>> assume this includes service chaining and that by "network >>> or set of networks" you intend "nodes" which may include >>> others things than just routers. >>>=20 >>> [SLI] Agree >>>=20 >>>=20 >>>> In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a = node to steer a packet between any source and destination node within the <= Name-TBD> domain (formed of one or more networks), on any path (shortest, n= on-shortest, explicit or based on other characteristics specified by segmen= t identifiers). >>>=20 >>>=20 >>> [SP] without requiring to maintain state along the path, other >>> than in the ingress node. >>>=20 >>> [SLI] Agree >>>=20 >>>=20 >>>> It may then send any packet that passes through it through any path th= at it has specified and that is conform to the security rules. Downstream r= outers along the path within the domain forward the packet as sp= ecified by the router at the head-end of the path. >>>=20 >>>>=20 >>>> The architecture should support centralized and distributed path compu= tation. >>>>=20 >>>> The architecture should support OAM functions. >>>=20 >>>=20 >>> [SP] The architecture should allow different mechanisms through which >>> a path is constructed. SR allows a variety of mechanisms, not >>> confined IGP/BGP path computation. >>>=20 >>> [SLI] Agree >>>=20 >>>> Work items : >>>> ------------------ >>>>=20 >>>> The working group is chartered for the following ordered li= st of work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated with >>>> the security considerations. The architecture framework and security >>>> considerations must address the relations between networks forming the= domain (interAS). >>>> - Having identified use-cases, architecture and security, the WG will >>>> identify gaps between currently available technologies and use-case >>>> requirements. >>>> - The WG will then define requirements for extensions to existing >>>> protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding definition. >>>=20 >>>=20 >>> [SP] The architecture will support tunnel and non-tunnel paradigms >>> The architecture will support multiple dataplanes: MPLS and V6 >>>=20 >>>=20 >>> Thanks. >>> s. >>>=20 >>>=20 >>>> Documents : >>>> ------------------ >>>> . Use Cases >>>> . Architecture including security considerations >>>> - Protocol extension requirements >>>> . Interoperability Report >>>>=20 >>>>=20 >>>> Protocol work may be carried out in this working group or in other wor= king groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coor= dination with this WG, and in agreement with the WG chairs and responsible = ADs. >>>>=20 >>>> -----Message d'origine----- >>>> De : Rob Shakir [mailto:rjs@rob.sh] >>>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane DTF/= DERX >>>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org Objet >>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try to= merge ... >>>>=20 >>>> Hi Stephane, >>>>=20 >>>> Thanks for this, looks good! Comments in-line marked rjs>. >>>>=20 >>>> On 10 Sep 2013, at 08:50, wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I'm creating a new mail topic because the "Summary of STATUS BOF ..." >>>>> starts to be unreadable :) >>>>>=20 >>>>> Hannes and Stefano send to us two charter proposals that sounds good = to me. >>>>>=20 >>>>> The main difference between the two proposals is that Stefano propose= a segment bound to any type of instruction (forwarding, application or ser= vice based) while Hannes is focusing on forwarding actions (which is the fi= rst priority, and I think everybody agree on this). >>>>=20 >>>> rjs> Agreed -- I think it would be useful to allow definitions of segm= ents to identify different types of "service", since there appear to be som= e use cases (e.g., the explicit exit selection case) which require a segmen= t type describing something that is not explicitly IGP-based. >>>>=20 >>>>>=20 >>>>> It would be interresting to have a feedback from the mailinglist on t= his specific point. >>>>>=20 >>>>> IMHO, there is a strong interrest to explore the service actions boun= d to segment in a second step keeping forwarding as a priority. >>>>>=20 >>>>> Apart of this problem, here is a merge try of the two good proposals = (I'm putting '<>' on hot topics :) ) : >>>>>=20 >>>>>=20 >>>>> ------------------------------------------------------------------- >>>>> Name: >>>>> Charter: >>>>>=20 >>>>>=20 >>>>> Introduction >>>>> ------------ >>>>> The following use cases: >>>>> . Path computation based on awareness of utilization or performance >>>>> data, within both centralized and distributed environments, . Multi-t= opology (dual planes, disjoint trees), . Simplification and reduction of si= gnaling components (scaling), . Combined application and network layer path= specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>>>>=20 >>>>> have triggered work on the definition of new architecture and protoco= l extensions allowing to combine well known shortest path based routing par= adigms with source/explicit routing methods. Some of these extensions have = been implemented already. >>>>>=20 >>>>>=20 >>>>> Objective >>>>> --------- >>>>>=20 >>>>> Define an architecture where a node can steer a packet through a netw= ork or set of networks (interdomain) on any path (shortest, non shortest, e= xplicit, ). >>>>>=20 >>>>> In this architecture, routers are sharing a common trust model and ar= e forming a domain. >>>>> Within this domain, a node can specify a path between itself and any = destination in the domain. . >>>>=20 >>>> rjs> To clarify here, we define that our domain is under a common trus= t model (essentially, under common administrative control?), but then go on= to talk about inter-domain elsewhere. Can we perhaps clarify (by defining = a specific " domain" nomenclature) and say something like: >>>>=20 >>>> "In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a= node to steer a packet between any source and destination node within the = domain (formed of one or more networks), on any path (shortest, = non-shortest, explicit or based on other characteristics specified by segme= nt identifiers)." >>>>=20 >>>>> It may then send any packet that passes through it through any path t= hat it has specified and that is conform to the security rules. Downstream = routers along the path within the domain forward the packet as s= pecified by the router at the head-end of the path. >>>>>=20 >>>>> The architecture should support centralized and distributed path comp= utation. >>>>>=20 >>>>>=20 >>>>> Work items : >>>>> ------------------ >>>>>=20 >>>>> The working group is chartered for the following ordered l= ist of work items: >>>>>=20 >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated with >>>>> the security considerations. The architecture framework and security >>>>> considerations must address the relations between domains (inter doma= in). >>>>=20 >>>> rjs> And then here "networks forming the domain"? >>>>=20 >>>> Thanks for the efforts, >>>> r. >>>>=20 >>>>> - Having identified use-cases, architecture and security, the WG will >>>>> identify gaps between currently available technologies and use-case >>>>> requirements. >>>>> - The WG will then define requirements for extensions to existing >>>>> protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>=20 >>>>>=20 >>>>> Documents : >>>>> ------------------ >>>>> . Use Cases >>>>> . Architecture including security considerations >>>>> - Protocol extension requirements >>>>> . Interoperability Report >>>>>=20 >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other wo= rking groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coo= rdination with this WG, and in agreement with the WG chairs and responsible= ADs. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Hope it helps to progress on the definition. >>>>>=20 >>>>>=20 >>>>> Stephane >>>>>=20 >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi 6 >>>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>>>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and the >>>>> next steps >>>>>=20 >>>>> hi stephane, >>>>>=20 >>>>> here is a revised draft charter as per your comments. >>>>>=20 >>>>> --- >>>>>=20 >>>>> domain contains a set of routers with the following >>>>> characteristics: >>>>>=20 >>>>> - They form a connected network >>>>> - They can forward traffic through any path within the network using >>>>> shortest path, or any other (e.g., an explicit) path >>>>> - They share a common trust model. In this model, any router within >>>>> the domain can specify a path between itself and any other router in >>>>> the domain. It may then send any packet that passes through it >>>>> through any path that it has specified and that is conform to the >>>>> security rules. Downstream routers along the path within the >>>>> domain forward the packet as specified by the router at >>>>> the head-end of the path. >>>>>=20 >>>>> The working group is chartered for the following ordered l= ist of work items: >>>>>=20 >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated with >>>>> the security considerations. The architecture framework and security >>>>> considerations must address the relations between domains (interdomai= n). >>>>> - Having identified use-cases, architecture and security, the WG will >>>>> identify gaps between currently available technologies and use-case >>>>> requirements. >>>>> - The WG will then define requirements for extensions to existing >>>>> protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other wo= rking groups responsible for the protocols, in coordination with this WG, a= nd in agreement with the WG chairs and responsible ADs. >>>>> However, no protocol work will be adopted by a working group to addre= ss the identified use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>=20 >>>>> --- >>>>>=20 >>>>> /hannes >>>>>=20 >>>>> On Sep 4, 2013, at 10:02 AM, wrote: >>>>>=20 >>>>>> Hannes, >>>>>>=20 >>>>>> In case, we are using only directed forwarding (adjacency segment), >>>>>> could we still talk about tunneling ? (it's a very very small tunnel= ) Moreover talking about "stacking" is really dataplane agnostic (MPLS) ... >>>>>>=20 >>>>>> In the proposed segment routing architectural concepts, segments are= at the same "level" and pointer moves on the segment list, then the MPLS i= nstantiation is performing this using stacking ... >>>>>>=20 >>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen so= lution and it's closing the door to something else ... >>>>>>=20 >>>>>> Finally, about the "routing" word, routing is essentially a "forward= " action which may limit the scope of what we can do by using a segment lis= t. Actions associated with a segment could be something else than forwardin= g. >>>>>>=20 >>>>>> Do we want in the charter to limit the scope to routing actions ? >>>>>>=20 >>>>>> I have no solution today to propose for the naming, but I completely= agree with Loa, to first focus on working on the charter, and define a cle= ar scope of the work and then the name will be easier to find. >>>>>>=20 >>>>>> Regarding your charter proposal : >>>>>>=20 >>>>>> -------- >>>>>>=20 >>>>>> - They form a connected network >>>>>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>>>>=20 >>>>>> - They can forward traffic through the shortest paths or paths other= than the shortest (the latter called explicitly routed paths, or explicit = paths) >>>>>> [SLI] There is something else between SPT and Explicit path, you c= an define other algorithms than SPT to define a path, and it's not explicit= path. Moreover I come back to my comment, on do we want to limit the scope= to routing ? I would say no. >>>>>>=20 >>>>>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router in= the ERD. It can then send any packet that passes through it through any pa= th that it has specified. >>>>>> [SLI] Security considerations may have to be addressed in the >>>>>> charter , especially for the interAS case (trust yes, but not sure >>>>>> access to everything may not be good) >>>>>>=20 >>>>>> Downstream routers within the ERD forward the packet as specified by= the router at the head-end of the path. >>>>>> [SLI] Yes, but any router in the middle may be able to change the en= d to end explicit path. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>>> - Having identified use-cases, the WG will identify gaps between cur= rently available technologies and use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing pr= otocols or new protocols that address gaps that are identified. >>>>>>=20 >>>>>> [SLI] Agree, I would add : >>>>>> - defining the architecture framework >>>>>> - analysing the security considerisations >>>>>>=20 >>>>>>=20 >>>>>> --------- >>>>>>=20 >>>>>>=20 >>>>>> Here would be my proposal to extend yours : >>>>>>=20 >>>>>> A domain contains a set of routers with the fo= llowing characteristics: >>>>>>=20 >>>>>> - They form a connected network >>>>>> - They can forward traffic through any path within the network using >>>>>> shortest path, non shortest path or explicit path >>>>>> - They may provide other types of services than forwarding and they = can enforce service actions in the path. >>>>>> - They share a common trust model. In this model, any router within = the domain can specify a path between itself and any other router in the do= main. It may then send any packet that passes through it through any path t= hat it has specified and that is conform to the security rules. Downstream = routers within the ERD forward the packet as specified by the router at the= head-end of the path. >>>>>>=20 >>>>>> The working group is chartered for the following ordered list= of work items: >>>>>>=20 >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated with= the security considerations. The architecture framework and security consi= derations must address the relations between domains (interdomain). >>>>>> - Having identified use-cases, architecture and security, the WG wil= l identify gaps between currently available technologies and use-case requi= rements. >>>>>> - The WG will then define requirements for extensions to existing pr= otocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in other w= orking groups responsible for the protocols, in coordination with this WG, = and in agreement with the WG chairs and responsible ADs. However, no protoc= ol work will be adopted by a working group to address the ERD use-cases unt= il the requirements document motivating the protocol work has been sent to = the IESG for publication as an RFC. >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De la >>>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0 := Loa >>>>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of >>>>>> STATUS BOF and the next steps >>>>>>=20 >>>>>> good point - what about this charter proposal ? >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> Stacked Tunnels for Explicit Routing (STER) >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>=20 >>>>>> A explicit routing domain (ERD) contains a set of routers with the f= ollowing characteristics: >>>>>>=20 >>>>>> - They form a connected network >>>>>> - They can forward traffic through the shortest paths or paths other >>>>>> than the shortest (the latter called explicitly routed paths, or >>>>>> explicit paths) >>>>>> - They share a common trust model. In this model, any router within = the ERD can specify an explicit path between itself and any other router in= the ERD. It can then send any packet that passes through it through any pa= th that it has specified. Downstream routers within the ERD forward the pac= ket as specified by the router at the head-end of the path. >>>>>>=20 >>>>>> The STER working group is chartered for the following ordered list o= f work items: >>>>>>=20 >>>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>>> - Having identified use-cases, the WG will identify gaps between cur= rently available technologies and use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing pr= otocols or new protocols that address gaps that are identified. >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in other w= orking groups responsible for the protocols, in coordination with this WG, = and in agreement with the WG chairs and responsible ADs. However, no protoc= ol work will be adopted by a working group to address the ERD use-cases unt= il the requirements document motivating the protocol work has been sent to = the IESG for publication as an RFC. >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> >>>>>>=20 >>>>>> /hannes >>>>>>=20 >>>>>>=20 >>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>>=20 >>>>>>> Folks, >>>>>>>=20 >>>>>>> Excuse me if I'm slightly out of the loop, but so far I have not >>>>>>> seen a charter proposal, if there is one please point me to it. >>>>>>>=20 >>>>>>> It seems a bit odd to put the cart (what the wg should do) before >>>>>>> the horse (wg name). If we drill down the the charter first the wg >>>>>>> name might be easier to figure out. >>>>>>>=20 >>>>>>> /Loa >>>>>>>=20 >>>>>>> PS >>>>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>>> " If the WG charter is limited to source routing, how will we hand= le the "non source routing" use cases of segment routing ? In another worki= ng group ? So we will go back to the WG synchronization issue that has been= raised for this technology ..." >>>>>>>>=20 >>>>>>>> That's why I suggested SRV2. We are revisiting source routing with= new concepts. More generic number/action behavior. >>>>>>>>=20 >>>>>>>> Peter >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>>>> Behalf Of stephane.litkowski@orange.com >>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>>> To: AshwoodsmithPeter >>>>>>>> Cc: status@ietf.org >>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> There was a misunderstanding in my small comment :) so I will expl= ain more : >>>>>>>>=20 >>>>>>>> In segment routing, you have more than basic source routing : segm= ent routing is just associate a segment number to an action and then combin= e segment as you want, yes you can do source routing, but you also can do m= ore. >>>>>>>>=20 >>>>>>>> In the other hand, I completely agree with your statement that >>>>>>>> source routing is generic and dataplane agnostic, as segment routi= ng is ... >>>>>>>> (segment routing is not a new dataplane ...) >>>>>>>>=20 >>>>>>>> Now the definition of the WG naming must be inline with the >>>>>>>> charter that will be defined ... (draft today) >>>>>>>>=20 >>>>>>>> Based on the already existing consensus (at least for MPLS datapla= ne) brought up during Berlin STATUS BOF meeting, segment routing sounds to = be a good target candidate. >>>>>>>>=20 >>>>>>>> So now, do we want to do more in the WG charter than just make pro= gressing segment routing architecture and uses cases document and ensure co= ordination for the standardization of this technology ? >>>>>>>>=20 >>>>>>>> Do we want to standardize other technologies in this WG ? I don't = think so, based on Stewart's conclusion email from the BOF :"A new WG focus= ed solely on SR therefore needs to be create" >>>>>>>>=20 >>>>>>>> If the WG charter is limited to source routing, how will we handle= the "non source routing" use cases of segment routing ? In another working= group ? So we will go back to the WG synchronization issue that has been r= aised for this technology ... >>>>>>>>=20 >>>>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>>>>=20 >>>>>>>> Feedback ? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Stephane >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro >>>>>>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) Objet= : Re: >>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>> The term "source routing" has been around for a very long time and= is data path agnostic. Its also the term used in the literature etc so my = preference is to stick with this existing well known and data path agnostic= term. >>>>>>>>=20 >>>>>>>> Peter >>>>>>>>=20 >>>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> "Source routing" is just a subcase of segment routing ... as it i= s for IP routing ... >>>>>>>>>=20 >>>>>>>>> Stephane >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:02 = =C0 : >>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); J= ohn G. >>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; status@ietf.org; >>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of STATUS >>>>>>>>> BOF and the next steps >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> What is this 'segment routing' silliness? The correct term is 's= ource routing'. >>>>>>>>>=20 >>>>>>>>> Yours Irrespectively, >>>>>>>>>=20 >>>>>>>>> John >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>>>> On Behalf Of Mark Townsley >>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>>> To: Victor Kuarsingh >>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>>>> (stbryant) >>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>>=20 >>>>>>>>>>> All, >>>>>>>>>>>=20 >>>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>>=20 >>>>>>>>>>> I note this since attempting to come up with an all >>>>>>>>>>> encompassing acronym will be difficult and Segment Routing is >>>>>>>>>>> generic enough to associate to multiple functions. >>>>>>>>>>=20 >>>>>>>>>> Then we can just use "segroute" for the short name. WGs do not >>>>>>>>>> have to have acronyms, but they do need to have an 8-char >>>>>>>>>> limited short name for the various automated tools not to break. >>>>>>>>>>=20 >>>>>>>>>> - Mark >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Victor K >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>>=20 >>>>>>>>>>>> Roberta >>>>>>>>>>>>=20 >>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The second task, which hopefully should be relatively easy, >>>>>>>>>>>>>> is to find a better working name for the WG, since it has >>>>>>>>>>>>>> been put to me a number of times that STATUS is going to be >>>>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> status mailing list >>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>> _________________________________________________________________ >>>>>>>>> _ _ _ __ ___________________________________________________ >>>>>>>>>=20 >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expedit= eur et le detruire ainsi que les pieces jointes. Les messages electroniques= etant susceptibles d'alteration, Orange decline toute responsabilite si ce= message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>=20 >>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>>>> If you have received this email in error, please notify the sende= r and delete this message and its attachments. >>>>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> __________________________________________________________________ >>>>>>>> _ _ _ ____________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le d= etruire ainsi que les pieces jointes. Les messages electroniques etant susc= eptibles d'alteration, Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they should n= ot be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the sender= and delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>> ____________________________________________________________________ >>>>>> _ _ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _____________________________________________________________________ >>>>> _ ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles d'alt= eration, Orange decline toute responsabilite si ce message a ete altere, de= forme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>=20 >>>>=20 >>>> ______________________________________________________________________ >>>> ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>=20 >>>=20 >>> _______________________________________________________________________= __________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>>=20 >>=20 >>=20 >>=20 >=20 >=20 From xuxiaohu@huawei.com Tue Sep 10 19:15:22 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6721E80D4 for ; Tue, 10 Sep 2013 19:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOQeWNbarCk0 for ; Tue, 10 Sep 2013 19:15:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0521F9CBF for ; Tue, 10 Sep 2013 19:15:03 -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.5-GA FastPath queued) with ESMTP id AXE78629; Wed, 11 Sep 2013 02:15:02 +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.146.0; Wed, 11 Sep 2013 03:14:42 +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.146.0; Wed, 11 Sep 2013 03:14:51 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0146.000; Wed, 11 Sep 2013 10:14:43 +0800 From: Xuxiaohu To: "Stefano Previdi (sprevidi)" , Stephane Litkowski Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgbVbHaZSD4n1kCavdRcQiSghJm+P0GAgAAPW4CAAF0rAIABGKhQ Date: Wed, 11 Sep 2013 02:14:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> 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.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Hannes Gredler , Rob Shakir , "status@ietf.org" Subject: [Status] =?utf-8?b?562U5aSNOiAgR29vZCBjaGFydGVyIHByb3Bvc2FscyBm?= =?utf-8?q?rom_Hannes_and_Stefano_=3A_try_to_merge_=2E=2E=2E?= X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 02:15:22 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHN0YXR1cy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiBTdGVm YW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ55pyIMTHml6Ug MDo1OA0KPiDmlLbku7bkuro6IFN0ZXBoYW5lIExpdGtvd3NraQ0KPiDmioTpgIE6IEhhbm5lcyBH cmVkbGVyOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogW1N0YXR1 c10gR29vZCBjaGFydGVyIHByb3Bvc2FscyBmcm9tIEhhbm5lcyBhbmQgU3RlZmFubyA6IHRyeSB0 bw0KPiBtZXJnZSAuLi4NCj4gDQo+IA0KPiBPbiBTZXAgMTAsIDIwMTMsIGF0IDE6MjUgUE0sIDxz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEFncmVlIG9uIGFs bCBwcm9wb3NhbCBleGNlcHQgOg0KPiA+DQo+ID4gIltTUF0gVGhlIGFyY2hpdGVjdHVyZSB3aWxs IHN1cHBvcnQgdHVubmVsIGFuZCBub24tdHVubmVsIHBhcmFkaWdtcw0KPiA+ICAgICBUaGUgYXJj aGl0ZWN0dXJlIHdpbGwgc3VwcG9ydCBtdWx0aXBsZSBkYXRhcGxhbmVzOiBNUExTIGFuZCBWNiIN Cj4gPg0KPiA+IEkgZG9uJ3Qgc2VlIHRoZSByZWFzb24gZm9yIHRoaXMgLi4uIElNSE8sIHRoZSBn YXAgYW5hbHlzaXMgYW5kIHJlcXVpcmVtZW50cw0KPiBpbnZlbnRvcnkgd2lsbCByZXN1bHQgb24g c2F5aW5nIG9yIG5vdA0KPiANCj4gDQo+IFtTUF0gV2hpbGUgSSB1bmRlcnN0YW5kIHdoYXQgYnJv dWdodCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMNCj4gICAgICBpbiB0aGUgcHJvcG9zZWQgY2hh cnRlcjoNCj4gCSJIYXZpbmcgaWRlbnRpZmllZCB1c2UtY2FzZXMsIGFyY2hpdGVjdHVyZSBhbmQg c2VjdXJpdHksDQo+IAkgdGhlIFdHIHdpbGwgaWRlbnRpZnkgZ2FwcyBiZXR3ZWVuIGN1cnJlbnRs eSBhdmFpbGFibGUNCj4gCSB0ZWNobm9sb2dpZXMgYW5kIHVzZS1jYXNlIHJlcXVpcmVtZW50cy4N Cj4gCSBUaGUgV0cgd2lsbCB0aGVuIGRlZmluZSByZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMg dG8NCj4gCSBleGlzdGluZyBwcm90b2NvbHMgb3IgbmV3IHByb3RvY29scyB0aGF0IGFkZHJlc3Mg Z2Fwcw0KPiAJIHRoYXQgYXJlIGlkZW50aWZpZWQuIg0KPiANCj4gICAgICBJJ2QgbGlrZSB0byBw b2ludCBvdXQgd2l0aCBiZXR0ZXIgcHJlY2lzaW9uIHdoYXQgYXJlIHRoZQ0KPiAgICAgIGRpcmVj dGlvbnMgd2UgYXJlIEFMUkVBRFkgZW5nYWdlZCBpbnRvOiBkYXRhcGxhbmVzIGFuZA0KPiAgICAg IHBhcmFkaWdtcy4gQXMgSSBtZW50aW9uZWQgaW4gbXkgY2hhcnRlciBwcm9wb3NhbCwgd2UgZG8g aGF2ZQ0KPiAgICAgIGltcGxlbWVudGF0aW9ucyBhbmQgbXVsdGktdmVuZG9yIGludGVyb3BlcmFi aWxpdHkgdGVzdHMgd2lsbA0KPiAgICAgIGhhcHBlbiBzb29uLiBTbywgSSBqdXN0IHdhbnQgdG8g YmUgc3VyZSB3ZSBkb24ndCBpZ25vcmUgdGhpcw0KPiAgICAgIHJlYWxpdHkuDQo+IA0KPiAgICAg IE1QTFMgYW5kIHY2IGRhdGEtcGxhbmUgYXJlIHBhcnQgb2YgdGhpcyByZWFsaXR5LCBhcyB3ZWxs IGFzDQo+ICAgICAgdHVubmVsLWJhc2VkIGFuZCBub24tdHVubmVsIGJhc2VkIGFwcHJvYWNoZXMu DQoNCkkgZG9uJ3QgdGhpbmsgaXQncyBzdWl0YWJsZSB0byBtZW50aW9uIGRldmVsb3BpbmcgSVB2 NiBzcGVjaWZpYyBTUiBtZWNoYW5pc20gaW4gdGhlIGN1cnJlbnQgY2hhcnRlciB1bmxlc3MgdGhl cmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFueSBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5nIElQdjYg ZGF0YSBwbGFuZS4NCg0KQWNjb3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBxdW90 ZWQgZnJvbSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmlscy1ydGd3Zy1z ZWdtZW50LXJvdXRpbmctMDAjcGFnZS05LCAiLi4uVGhlIHNvdXJjZSByb3V0ZSBpcyBlbmNvZGVk IGFzIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBpbnN0ZWFkIG9mIElQIGFkZHJlc3Nlcy4u LiIgSWYgc28sIHdoeSBub3QgZGlyZWN0bHkgdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiBsYWJlbHMg KGkuZS4sIE1QTFMgbGFiZWwgc3RhY2spIHRvIGRvIHRoYXQgKHNlZSBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvc3RhdHVzL2N1cnJlbnQvbXNnMDAxNjUuaHRtbCk/IA0KDQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICBUaGUgbWFpbiBk aWZmZXJlbmNlcyBmcm9tIHRoZSBJUHY2IHNvdXJjZSByb3V0ZSBtb2RlbCBhcmU6DQoNCg0KDQpG aWxzZmlscywgZXQgYWwuICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDMwLCAyMDEzICAgICAgICAg ICAgICAgW1BhZ2UgOV0NCiANCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU2VnbWVudCBS b3V0aW5nICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxMw0KDQoNCiAgICAgIFRoZSBzb3VyY2Ug cm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaW5zdGVhZA0K ICAgICAgb2YgSVAgYWRkcmVzc2VzLg0KDQogICAgICBBIHNlZ21lbnQgY2FuIHJlcHJlc2VudCBh bnkgaW5zdHJ1Y3Rpb24gZWl0aGVyIGEgc2VydmljZSBvciBhDQogICAgICB0b3BvbG9naWNhbCBw YXRoLiAgVG9wb2xvZ2ljYWxseSwgdGhlIHBhdGggdG8gYW4gSVAgYWRkcmVzcyBpcw0KICAgICAg b2Z0ZW4gbGltaXRlZCB0byB0aGUgc2hvcnRlc3QtcGF0aCB0byB0aGF0IGFkZHJlc3MuICBBIHNl Z21lbnQgY2FuDQogICAgICByZXByZXNlbnQgYW55IHBhdGggKGUuZy4gYW4gYWRqYWNlbmN5IHNl Z21lbnQgZm9yY2VzIGEgcGFja2V0IHRvIGENCiAgICAgIG5leHRob3AgdGhyb3VnaCBhIHNwZWNp ZmljIGFkamFjZW5jeSBldmVuIGlmIHRoZSBzaG9ydGVzdC1wYXRoIHRvDQogICAgICB0aGUgbmV4 dC1ob3AgZG9lcyBub3QgdXNlIHRoYXQgYWRqYWNlbmN5KS4NCg0KICAgICAgVGhlIGluZ3Jlc3Mg YW5kIGVncmVzcyBlZ2RlIHJvdXRlcnMgYXJlIGlkZW50aWZpZWQgYW5kIGFsd2F5cw0KICAgICAg YXZhaWxhYmxlLCBhbGxvd2luZyBmb3IgaW50ZXJlc3RpbmcgYWNjb3VudGluZyBhbmQgcG9saWN5 DQogICAgICBhcHBsaWNhdGlvbnMuDQoNCiAgICAgIFRoZSBzb3VyY2Ugcm91dGUgZnVuY3Rpb25h bGl0eSBjYW5ub3QgYmUgY29udHJvbGxlZCBmcm9tIG91dHNpZGUNCiAgICAgIHRoZSBTUiBkb21h aW4uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odSANCg0K From hannes@juniper.net Tue Sep 10 23:15:00 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0376411E8175 for ; Tue, 10 Sep 2013 23:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+MH2LS79Wlz for ; Tue, 10 Sep 2013 23:14:54 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 633D911E812C for ; Tue, 10 Sep 2013 23:14:54 -0700 (PDT) Received: from mail72-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Wed, 11 Sep 2013 06:14:53 +0000 Received: from mail72-tx2 (localhost [127.0.0.1]) by mail72-tx2-R.bigfish.com (Postfix) with ESMTP id A68A84600F8; Wed, 11 Sep 2013 06:14:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -73 X-BigFish: VPS-73(zz62a3I98dI9371Ic89bh936eI542I1432I15caKJ1447I14ffIdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail72-tx2: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail72-tx2 (localhost.localdomain [127.0.0.1]) by mail72-tx2 (MessageSwitch) id 1378880090582455_20385; Wed, 11 Sep 2013 06:14:50 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.253]) by mail72-tx2.bigfish.com (Postfix) with ESMTP id 7FAEF38017D; Wed, 11 Sep 2013 06:14:50 +0000 (UTC) Received: from BL2PRD0512HT004.namprd05.prod.outlook.com (157.56.242.197) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 11 Sep 2013 06:14:50 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.37) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 11 Sep 2013 06:14:40 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Wed, 11 Sep 2013 08:14:35 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> To: Stefano Previdi X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephane Litkowski , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 06:15:00 -0000 stefano, On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote: > Hannes, >=20 > On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote: >> stefano, >>=20 >> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: >>=20 >>>=20 >>> On Sep 10, 2013, at 1:25 PM, wrote: >>>=20 >>>> Agree on all proposal except : >>>>=20 >>>> "[SP] The architecture will support tunnel and non-tunnel paradigms >>>> The architecture will support multiple dataplanes: MPLS and V6" >>>>=20 >>>> I don't see the reason for this ... IMHO, the gap analysis and = requirements inventory will result on saying or not >>>=20 >>>=20 >>> [SP] While I understand what brought the following statements >>> in the proposed charter: >>> "Having identified use-cases, architecture and security,=20 >>> the WG will identify gaps between currently available=20 >>> technologies and use-case requirements. >>> The WG will then define requirements for extensions to=20 >>> existing protocols or new protocols that address gaps=20 >>> that are identified." >>>=20 >>> I'd like to point out with better precision what are the=20 >>> directions we are ALREADY engaged into: dataplanes and=20 >>> paradigms. As I mentioned in my charter proposal, we do have=20 >>> implementations and multi-vendor interoperability tests will >>> happen soon. So, I just want to be sure we don't ignore this=20 >>> reality. >>=20 >> HG> just because you have an implementation for does not = constitute >> community interest. we are trying to build here a charter that >> matches what a broader community wants. if the use-case that you're = concerned >> about (service-chaining and a new internet data plane #4) are = compelling >> enough the group will work on it, but mandating that into the = charter, >> without asking the though questions first seems a wrong start to = me. >=20 >=20 > [SP] Sorry to contradict but it's the exact opposite. If a group=20 > of vendors decide to invest in implementations is because=20 > they received, analyzed, processed a set of requirements=20 > coming for operators who know pretty well what they do, what=20 > they want to deploy and the technology they want the vendors=20 > to deliver. This fits the definition of "community interest". HG> interestingly enough i haven't encountered a network operator so far who says 'i need SR for service chaining' nor=20 we had somebody asking for this in the 'operator use case' slots in Berlin. - So who are they ? - can you manage such that they speak up and make their case ? > My point is that I strongly _suggest_ IETF WG (any) not to=20 > neglect these facts and not write a down a charter ... [ =85 ] HG> i'd like to have some proof point for your 'facts' prior to making 'service chaining' a charter item. > Having said that, whoever does NOT believe in the benefit of=20 > a newly proposed technology, is always free to not implement=20 > it and to not deploy it. HG> that is fine and well understood, but since you have a desire to standardize your 'newly proposed technology' you also need to play a bit by the rules. >>>> : we must use tunnels and/or non tunnels, and the following = dataplanes ... But I don't see the reason to put solutions directly in = the charter ... >>>=20 >>>=20 >>> these are not solutions these are way to avoid boundaries in the >>> framework. >>>=20 >>> Thanks. >>> s. >>>=20 >>>=20 >>>> Could you explain your point ? >>>>=20 >>>>=20 >>>> updated with the other comments : >>>>=20 >>>> ------------------------------------------------------------------- >>>> Name: >>>> Charter: >>>>=20 >>>>=20 >>>> Introduction >>>> ------------ >>>> The following use cases: >>>> . Path computation based on awareness of utilization or performance >>>> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>>>=20 >>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>=20 >>>>=20 >>>> Objective >>>> --------- >>>>=20 >>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path without requiring = to maintain state along the path, other than in the ingress node. >>>>=20 >>>> A node may be any type of device including routers or appliances. >>>>=20 >>>> In this architecture, nodes sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers). >>>>=20 >>>> It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. = Downstream nodes along the path within the domain forward the = packet by using the informations inserted by the node at the head-end >>>>=20 >>>> The architecture should support centralized and distributed path = computation. >>>>=20 >>>> The architecture should support OAM functions. >>>>=20 >>>> The architecture should allow different mechanisms through which >>>> a path is constructed. SR allows a variety of mechanisms, not >>>> confined IGP/BGP path computation. >>>>=20 >>>> As MPLS dataplane is largely deployed, the WG should = avoid any modification in the MPLS dataplane when defining the = architecture. >>>>=20 >>>>=20 >>>> Work items : >>>> ------------------ >>>>=20 >>>> The working group is chartered for the following ordered = list of work items: >>>>=20 >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated = with >>>> the security considerations. The architecture framework and = security >>>> considerations must address the relations between networks forming = the domain (interAS). >>>> - Having identified use-cases, architecture and security, the WG = will >>>> identify gaps between currently available technologies and use-case >>>> requirements. >>>> - The WG will then define requirements for extensions to existing >>>> protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>=20 >>>>=20 >>>> Documents : >>>> ------------------ >>>> . Use Cases >>>> . Architecture including security considerations >>>> - Protocol extension requirements >>>> . Interoperability Report >>>>=20 >>>>=20 >>>> Required protocol extensions are carried out in working groups = responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be = carried out by the WG. >>>>=20 >>>> -----Message d'origine----- >>>> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>> Envoy=E9 : mardi 10 septembre 2013 12:30 >>>> =C0 : LITKOWSKI Stephane DTF/DERX; Rob Shakir >>>> Cc : Hannes Gredler; status@ietf.org >>>> Objet : Re: [Status] Good charter proposals from Hannes and Stefano = : try to merge ... >>>>=20 >>>> Hi Stephane, Rob, >>>>=20 >>>> one preliminary remark: I prefer to use he therm "node" rather than = "router". Use cases, such as Service Chaining requires that terminology. >>>>=20 >>>> some other comments below... >>>>=20 >>>>=20 >>>> On Sep 10, 2013, at 11:19 AM, = wrote: >>>>> Souns good to me, (adding OAM also) >>>>>=20 >>>>> New recap : >>>>>=20 >>>>> = ------------------------------------------------------------------- >>>>> Name: >>>>> Charter: >>>>>=20 >>>>>=20 >>>>> Introduction >>>>> ------------ >>>>> The following use cases: >>>>> . Path computation based on awareness of utilization or = performance >>>>> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>>>>=20 >>>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>>=20 >>>>>=20 >>>>> Objective >>>>> --------- >>>>>=20 >>>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path. >>>>=20 >>>>=20 >>>> [SP] As stated above, I'm fine with the above definition but I >>>> assume this includes service chaining and that by "network >>>> or set of networks" you intend "nodes" which may include >>>> others things than just routers. >>>>=20 >>>> [SLI] Agree >>>>=20 >>>>=20 >>>>> In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers). >>>>=20 >>>>=20 >>>> [SP] without requiring to maintain state along the path, other >>>> than in the ingress node. >>>>=20 >>>> [SLI] Agree >>>>=20 >>>>=20 >>>>> It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >>>>=20 >>>>>=20 >>>>> The architecture should support centralized and distributed path = computation. >>>>>=20 >>>>> The architecture should support OAM functions. >>>>=20 >>>>=20 >>>> [SP] The architecture should allow different mechanisms through = which >>>> a path is constructed. SR allows a variety of mechanisms, not >>>> confined IGP/BGP path computation. >>>>=20 >>>> [SLI] Agree >>>>=20 >>>>> Work items : >>>>> ------------------ >>>>>=20 >>>>> The working group is chartered for the following = ordered list of work items: >>>>>=20 >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated = with >>>>> the security considerations. The architecture framework and = security >>>>> considerations must address the relations between networks forming = the domain (interAS). >>>>> - Having identified use-cases, architecture and security, the WG = will >>>>> identify gaps between currently available technologies and = use-case >>>>> requirements. >>>>> - The WG will then define requirements for extensions to existing >>>>> protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>=20 >>>>=20 >>>> [SP] The architecture will support tunnel and non-tunnel paradigms >>>> The architecture will support multiple dataplanes: MPLS and V6 >>>>=20 >>>>=20 >>>> Thanks. >>>> s. >>>>=20 >>>>=20 >>>>> Documents : >>>>> ------------------ >>>>> . Use Cases >>>>> . Architecture including security considerations >>>>> - Protocol extension requirements >>>>> . Interoperability Report >>>>>=20 >>>>>=20 >>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), = in coordination with this WG, and in agreement with the WG chairs and = responsible ADs. >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Rob Shakir [mailto:rjs@rob.sh] >>>>> Envoy=E9 : mardi 10 septembre 2013 11:05 =C0 : LITKOWSKI Stephane = DTF/DERX >>>>> Cc : Hannes Gredler; Stefano Previdi (sprevidi); status@ietf.org = Objet >>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : = try to merge ... >>>>>=20 >>>>> Hi Stephane, >>>>>=20 >>>>> Thanks for this, looks good! Comments in-line marked rjs>. >>>>>=20 >>>>> On 10 Sep 2013, at 08:50, wrote: >>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF = ..." >>>>>> starts to be unreadable :) >>>>>>=20 >>>>>> Hannes and Stefano send to us two charter proposals that sounds = good to me. >>>>>>=20 >>>>>> The main difference between the two proposals is that Stefano = propose a segment bound to any type of instruction (forwarding, = application or service based) while Hannes is focusing on forwarding = actions (which is the first priority, and I think everybody agree on = this). >>>>>=20 >>>>> rjs> Agreed -- I think it would be useful to allow definitions of = segments to identify different types of "service", since there appear to = be some use cases (e.g., the explicit exit selection case) which require = a segment type describing something that is not explicitly IGP-based. >>>>>=20 >>>>>>=20 >>>>>> It would be interresting to have a feedback from the mailinglist = on this specific point. >>>>>>=20 >>>>>> IMHO, there is a strong interrest to explore the service actions = bound to segment in a second step keeping forwarding as a priority. >>>>>>=20 >>>>>> Apart of this problem, here is a merge try of the two good = proposals (I'm putting '<>' on hot topics :) ) : >>>>>>=20 >>>>>>=20 >>>>>> = ------------------------------------------------------------------- >>>>>> Name: >>>>>> Charter: >>>>>>=20 >>>>>>=20 >>>>>> Introduction >>>>>> ------------ >>>>>> The following use cases: >>>>>> . Path computation based on awareness of utilization or = performance >>>>>> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>>>>>=20 >>>>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>>>=20 >>>>>>=20 >>>>>> Objective >>>>>> --------- >>>>>>=20 >>>>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path (shortest, non = shortest, explicit, ). >>>>>>=20 >>>>>> In this architecture, routers are sharing a common trust model = and are forming a domain. >>>>>> Within this domain, a node can specify a path between itself and = any destination in the domain. . >>>>>=20 >>>>> rjs> To clarify here, we define that our domain is under a common = trust model (essentially, under common administrative control?), but = then go on to talk about inter-domain elsewhere. Can we perhaps clarify = (by defining a specific " domain" nomenclature) and say = something like: >>>>>=20 >>>>> "In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers)." >>>>>=20 >>>>>> It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >>>>>>=20 >>>>>> The architecture should support centralized and distributed path = computation. >>>>>>=20 >>>>>>=20 >>>>>> Work items : >>>>>> ------------------ >>>>>>=20 >>>>>> The working group is chartered for the following = ordered list of work items: >>>>>>=20 >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated = with >>>>>> the security considerations. The architecture framework and = security >>>>>> considerations must address the relations between domains (inter = domain). >>>>>=20 >>>>> rjs> And then here "networks forming the domain"? >>>>>=20 >>>>> Thanks for the efforts, >>>>> r. >>>>>=20 >>>>>> - Having identified use-cases, architecture and security, the WG = will >>>>>> identify gaps between currently available technologies and = use-case >>>>>> requirements. >>>>>> - The WG will then define requirements for extensions to existing >>>>>> protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>=20 >>>>>>=20 >>>>>> Documents : >>>>>> ------------------ >>>>>> . Use Cases >>>>>> . Architecture including security considerations >>>>>> - Protocol extension requirements >>>>>> . Interoperability Report >>>>>>=20 >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP = ...), in coordination with this WG, and in agreement with the WG chairs = and responsible ADs. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hope it helps to progress on the definition. >>>>>>=20 >>>>>>=20 >>>>>> Stephane >>>>>>=20 >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : = vendredi 6 >>>>>> septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>>>>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and = the >>>>>> next steps >>>>>>=20 >>>>>> hi stephane, >>>>>>=20 >>>>>> here is a revised draft charter as per your comments. >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> domain contains a set of routers with the following >>>>>> characteristics: >>>>>>=20 >>>>>> - They form a connected network >>>>>> - They can forward traffic through any path within the network = using >>>>>> shortest path, or any other (e.g., an explicit) path >>>>>> - They share a common trust model. In this model, any router = within >>>>>> the domain can specify a path between itself and any other router = in >>>>>> the domain. It may then send any packet that passes through it >>>>>> through any path that it has specified and that is conform to the >>>>>> security rules. Downstream routers along the path within the >>>>>> domain forward the packet as specified by the router = at >>>>>> the head-end of the path. >>>>>>=20 >>>>>> The working group is chartered for the following = ordered list of work items: >>>>>>=20 >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated = with >>>>>> the security considerations. The architecture framework and = security >>>>>> considerations must address the relations between domains = (interdomain). >>>>>> - Having identified use-cases, architecture and security, the WG = will >>>>>> identify gaps between currently available technologies and = use-case >>>>>> requirements. >>>>>> - The WG will then define requirements for extensions to existing >>>>>> protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. >>>>>> However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> /hannes >>>>>>=20 >>>>>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>>>>=20 >>>>>>> Hannes, >>>>>>>=20 >>>>>>> In case, we are using only directed forwarding (adjacency = segment), >>>>>>> could we still talk about tunneling ? (it's a very very small = tunnel) Moreover talking about "stacking" is really dataplane agnostic = (MPLS) ... >>>>>>>=20 >>>>>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the = MPLS instantiation is performing this using stacking ... >>>>>>>=20 >>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a = chosen solution and it's closing the door to something else ... >>>>>>>=20 >>>>>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>>>>=20 >>>>>>> Do we want in the charter to limit the scope to routing actions = ? >>>>>>>=20 >>>>>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>>>>=20 >>>>>>> Regarding your charter proposal : >>>>>>>=20 >>>>>>> -------- >>>>>>>=20 >>>>>>> - They form a connected network >>>>>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>>>>=20 >>>>>>> - They can forward traffic through the shortest paths or paths = other than the shortest (the latter called explicitly routed paths, or = explicit paths) >>>>>>> [SLI] There is something else between SPT and Explicit path, = you can define other algorithms than SPT to define a path, and it's not = explicit path. Moreover I come back to my comment, on do we want to = limit the scope to routing ? I would say no. >>>>>>>=20 >>>>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. >>>>>>> [SLI] Security considerations may have to be addressed in the >>>>>>> charter , especially for the interAS case (trust yes, but not = sure >>>>>>> access to everything may not be good) >>>>>>>=20 >>>>>>> Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>>> [SLI] Yes, but any router in the middle may be able to change = the end to end explicit path. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> - The first goal of the STER WG is to identify use-cases for = ERDs. >>>>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>>>> - The WG will then define requirements for extensions to = existing protocols or new protocols that address gaps that are = identified. >>>>>>>=20 >>>>>>> [SLI] Agree, I would add : >>>>>>> - defining the architecture framework >>>>>>> - analysing the security considerisations >>>>>>>=20 >>>>>>>=20 >>>>>>> --------- >>>>>>>=20 >>>>>>>=20 >>>>>>> Here would be my proposal to extend yours : >>>>>>>=20 >>>>>>> A domain contains a set of routers with = the following characteristics: >>>>>>>=20 >>>>>>> - They form a connected network >>>>>>> - They can forward traffic through any path within the network = using >>>>>>> shortest path, non shortest path or explicit path >>>>>>> - They may provide other types of services than forwarding and = they can enforce service actions in the path. >>>>>>> - They share a common trust model. In this model, any router = within the domain can specify a path between itself and any other router = in the domain. It may then send any packet that passes through it = through any path that it has specified and that is conform to the = security rules. Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>>>=20 >>>>>>> The working group is chartered for the following ordered = list of work items: >>>>>>>=20 >>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>>>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case = requirements. >>>>>>> - The WG will then define requirements for extensions to = existing protocols or new protocols that address gaps that are = identified. >>>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>>=20 >>>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. = However, no protocol work will be adopted by a working group to address = the ERD use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De = la >>>>>>> part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 =C0= : Loa >>>>>>> Andersson Cc : status@ietf.org Objet : Re: [Status] Summary of >>>>>>> STATUS BOF and the next steps >>>>>>>=20 >>>>>>> good point - what about this charter proposal ? >>>>>>>=20 >>>>>>> --- >>>>>>>=20 >>>>>>> Stacked Tunnels for Explicit Routing (STER) >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>>> A explicit routing domain (ERD) contains a set of routers with = the following characteristics: >>>>>>>=20 >>>>>>> - They form a connected network >>>>>>> - They can forward traffic through the shortest paths or paths = other >>>>>>> than the shortest (the latter called explicitly routed paths, or >>>>>>> explicit paths) >>>>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. Downstream routers within the = ERD forward the packet as specified by the router at the head-end of the = path. >>>>>>>=20 >>>>>>> The STER working group is chartered for the following ordered = list of work items: >>>>>>>=20 >>>>>>> - The first goal of the STER WG is to identify use-cases for = ERDs. >>>>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>>>> - The WG will then define requirements for extensions to = existing protocols or new protocols that address gaps that are = identified. >>>>>>>=20 >>>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. = However, no protocol work will be adopted by a working group to address = the ERD use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>>>=20 >>>>>>> --- >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> /hannes >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>>>=20 >>>>>>>> Folks, >>>>>>>>=20 >>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have = not >>>>>>>> seen a charter proposal, if there is one please point me to it. >>>>>>>>=20 >>>>>>>> It seems a bit odd to put the cart (what the wg should do) = before >>>>>>>> the horse (wg name). If we drill down the the charter first the = wg >>>>>>>> name might be easier to figure out. >>>>>>>>=20 >>>>>>>> /Loa >>>>>>>>=20 >>>>>>>> PS >>>>>>>> OK I understand that the horse and cart analogy limps a bit = :). >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>>>>=20 >>>>>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>>>>=20 >>>>>>>>> Peter >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] = On >>>>>>>>> Behalf Of stephane.litkowski@orange.com >>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>>>> To: AshwoodsmithPeter >>>>>>>>> Cc: status@ietf.org >>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>>>>=20 >>>>>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>>>>=20 >>>>>>>>> In the other hand, I completely agree with your statement that >>>>>>>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>>>>>>> (segment routing is not a new dataplane ...) >>>>>>>>>=20 >>>>>>>>> Now the definition of the WG naming must be inline with the >>>>>>>>> charter that will be defined ... (draft today) >>>>>>>>>=20 >>>>>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>>>>=20 >>>>>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and = ensure coordination for the standardization of this technology ? >>>>>>>>>=20 >>>>>>>>> Do we want to standardize other technologies in this WG ? I = don't think so, based on Stewart's conclusion email from the BOF :"A new = WG focused solely on SR therefore needs to be create" >>>>>>>>>=20 >>>>>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>>>>=20 >>>>>>>>> If the WG is focused on SR, let's use a name in relation with = SR. >>>>>>>>>=20 >>>>>>>>> Feedback ? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Stephane >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI = Stephane >>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; = Alvaro >>>>>>>>> Retana (aretana); status@ietf.org; Stewart Bryant (stbryant) = Objet : Re: >>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>>=20 >>>>>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc = so my preference is to stick with this existing well known and data path = agnostic term. >>>>>>>>>=20 >>>>>>>>> Peter >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> "Source routing" is just a subcase of segment routing ... as = it is for IP routing ... >>>>>>>>>>=20 >>>>>>>>>> Stephane >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] = De >>>>>>>>>> la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 = 15:02 =C0 : >>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione = (robmgl); John G. >>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; = status@ietf.org; >>>>>>>>>> Stewart Bryant (stbryant) Objet : Re: [Status] Summary of = STATUS >>>>>>>>>> BOF and the next steps >>>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> What is this 'segment routing' silliness? The correct term = is 'source routing'. >>>>>>>>>>=20 >>>>>>>>>> Yours Irrespectively, >>>>>>>>>>=20 >>>>>>>>>> John >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: status-bounces@ietf.org = [mailto:status-bounces@ietf.org] >>>>>>>>>>> On Behalf Of Mark Townsley >>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>>>> To: Victor Kuarsingh >>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian = Farrel; >>>>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant >>>>>>>>>>> (stbryant) >>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next = steps >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> All, >>>>>>>>>>>>=20 >>>>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>>>=20 >>>>>>>>>>>> I note this since attempting to come up with an all >>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing = is >>>>>>>>>>>> generic enough to associate to multiple functions. >>>>>>>>>>>=20 >>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do = not >>>>>>>>>>> have to have acronyms, but they do need to have an 8-char >>>>>>>>>>> limited short name for the various automated tools not to = break. >>>>>>>>>>>=20 >>>>>>>>>>> - Mark >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>>=20 >>>>>>>>>>>> Victor K >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Roberta >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The second task, which hopefully should be relatively = easy, >>>>>>>>>>>>>>> is to find a better working name for the WG, since it = has >>>>>>>>>>>>>>> been put to me a number of times that STATUS is going to = be >>>>>>>>>>>>>>> confusing in text and a difficult search term. >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> status mailing list >>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>> = _________________________________________________________________ >>>>>>>>>> _ _ _ __ ___________________________________________________ >>>>>>>>>>=20 >>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>> informations confidentielles ou privilegiees et ne doivent = donc >>>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si = vous >>>>>>>>>> avez recu ce message par erreur, veuillez le signaler a = l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>>=20 >>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>>>> Thank you. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>> = __________________________________________________________________ >>>>>>>>> _ _ _ ____________________________________________________ >>>>>>>>>=20 >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et = le detruire ainsi que les pieces jointes. Les messages electroniques = etant susceptibles d'alteration, Orange decline toute responsabilite si = ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>=20 >>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Loa Andersson email: = loa@mail01.huawei.com >>>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>> = ____________________________________________________________________ >>>>>>> _ _ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = _____________________________________________________________________ >>>>>> _ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>>>> exploites ou copies sans autorisation. Si vous avez recu ce = message >>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>=20 >>>>>=20 >>>>> = ______________________________________________________________________ >>>>> ___________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>>>> exploites ou copies sans autorisation. Si vous avez recu ce = message >>>>> par erreur, veuillez le signaler a l'expediteur et le detruire = ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>=20 >>>>=20 >>>> = __________________________________________________________________________= _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>>> they should not be distributed, used or copied without = authorisation. >>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 >=20 From stephane.litkowski@orange.com Wed Sep 11 02:53:42 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5621E80B3 for ; Wed, 11 Sep 2013 02:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.586 X-Spam-Level: X-Spam-Status: No, score=0.586 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_00=-2.599, FRT_INTEREST=3.579, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkpzl9lAhbz3 for ; Wed, 11 Sep 2013 02:53:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D535921E8093 for ; Wed, 11 Sep 2013 02:53:34 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E9C4E3240C3; Wed, 11 Sep 2013 11:53:33 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id CA75F27C058; Wed, 11 Sep 2013 11:53:33 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 11 Sep 2013 11:53:33 +0200 From: To: Hannes Gredler , Stefano Previdi Date: Wed, 11 Sep 2013 11:53:32 +0200 Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: Ac6utjzL0kgCaYjzT3eWkP8jXfnTfQAHaQZQ Message-ID: <10969_1378893213_52303D9D_10969_5864_1_EEE55384044474429A926C625D0FCC810964DECA2B@PUEXCB2F.nanterre.francetelecom.fr> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.11.90616 Cc: Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 09:53:42 -0000 Hannes, Regarding "Service chaining", I would agree to not mention it directly in t= he charter (it's not mentionned explictly in my last proposal) BUT I don't = want to close the door to other "action types" than forwarding. That's why = using the wording "node" , "steering packets" seems to be good because it's= large enough to address use cases that are not detailled today (for exampl= e service chaining). So my approach would be , keep it large in definition using the proposed wo= rding and then the use case analysis (in the work items) will give us what = we need to address exactly. Does it make sense for you to use this way ? Thanks, Stephane -----Message d'origine----- De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : mercredi 11 septembre 2013 08:15 =C0 : Stefano Previdi Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; status@ietf.org Objet : Re: [Status] Good charter proposals from Hannes and Stefano : try t= o merge ... stefano, On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote: > Hannes, > > On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote: >> stefano, >> >> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: >> >>> >>> On Sep 10, 2013, at 1:25 PM, wrote: >>> >>>> Agree on all proposal except : >>>> >>>> "[SP] The architecture will support tunnel and non-tunnel paradigms >>>> The architecture will support multiple dataplanes: MPLS and V6" >>>> >>>> I don't see the reason for this ... IMHO, the gap analysis and >>>> requirements inventory will result on saying or not >>> >>> >>> [SP] While I understand what brought the following statements >>> in the proposed charter: >>> "Having identified use-cases, architecture and security, >>> the WG will identify gaps between currently available >>> technologies and use-case requirements. >>> The WG will then define requirements for extensions to >>> existing protocols or new protocols that address gaps >>> that are identified." >>> >>> I'd like to point out with better precision what are the >>> directions we are ALREADY engaged into: dataplanes and >>> paradigms. As I mentioned in my charter proposal, we do have >>> implementations and multi-vendor interoperability tests will >>> happen soon. So, I just want to be sure we don't ignore this >>> reality. >> >> HG> just because you have an implementation for does not >> HG> constitute >> community interest. we are trying to build here a charter that >> matches what a broader community wants. if the use-case that you're co= ncerned >> about (service-chaining and a new internet data plane #4) are compelli= ng >> enough the group will work on it, but mandating that into the charter, >> without asking the though questions first seems a wrong start to me. > > > [SP] Sorry to contradict but it's the exact opposite. If a group > of vendors decide to invest in implementations is because > they received, analyzed, processed a set of requirements > coming for operators who know pretty well what they do, what > they want to deploy and the technology they want the vendors > to deliver. This fits the definition of "community interest". HG> interestingly enough i haven't encountered a network operator so far who says 'i need SR for service chaining' nor we had somebody asking for this in the 'operator use case' slots in Berlin. - So who are they ? - can you manage such that they speak up and make their case ? > My point is that I strongly _suggest_ IETF WG (any) not to > neglect these facts and not write a down a charter ... [ ... ] HG> i'd like to have some proof point for your 'facts' prior to making 'service chaining' a charter item. > Having said that, whoever does NOT believe in the benefit of > a newly proposed technology, is always free to not implement > it and to not deploy it. HG> that is fine and well understood, but since you have a desire to standardize your 'newly proposed technology' you also need to play a bit by the rules. >>>> : we must use tunnels and/or non tunnels, and the following dataplanes= ... But I don't see the reason to put solutions directly in the charter ... >>> >>> >>> these are not solutions these are way to avoid boundaries in the >>> framework. >>> >>> Thanks. >>> s. >>> >>> >>>> Could you explain your point ? >>>> >>>> >>>> updated with the other comments : >>>> >>>> ------------------------------------------------------------------- >>>> Name: >>>> Charter: >>>> >>>> >>>> Introduction >>>> ------------ >>>> The following use cases: >>>> . Path computation based on awareness of utilization or performance >>>> data, within both centralized and distributed environments, . Multi-to= pology (dual planes, disjoint trees), . Simplification and reduction of sig= naling components (scaling), . Combined application and network layer path = specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>>> >>>> have triggered work on the definition of new architecture and protocol= extensions allowing to combine well known shortest path based routing para= digms with source/explicit routing methods. Some of these extensions have b= een implemented already. >>>> >>>> >>>> Objective >>>> --------- >>>> >>>> Define an architecture where a node can steer a packet through a netwo= rk or set of networks (interdomain) on any path without requiring to mainta= in state along the path, other than in the ingress node. >>>> >>>> A node may be any type of device including routers or appliances. >>>> >>>> In this architecture, nodes sharing a common trust model form a domain. The architecture defined by this working group will allow a no= de to steer a packet between any source and destination node within the domain (formed of one or more networks), on any path (shortest, non= -shortest, explicit or based on other characteristics specified by segment = identifiers). >>>> >>>> It may then send any packet that passes through it through any path >>>> that it has specified and that is conform to the security rules. >>>> Downstream nodes along the path within the domain >>>> forward the packet by using the informations inserted by the node >>>> at the head-end >>>> >>>> The architecture should support centralized and distributed path compu= tation. >>>> >>>> The architecture should support OAM functions. >>>> >>>> The architecture should allow different mechanisms through which a >>>> path is constructed. SR allows a variety of mechanisms, not >>>> confined IGP/BGP path computation. >>>> >>>> As MPLS dataplane is largely deployed, the WG should avoid = any modification in the MPLS dataplane when defining the architecture. >>>> >>>> >>>> Work items : >>>> ------------------ >>>> >>>> The working group is chartered for the following ordered li= st of work items: >>>> >>>> - The first goal of the WG is to identify use-cases. >>>> - The WG will then define the architecture framework associated >>>> with the security considerations. The architecture framework and >>>> security considerations must address the relations between networks fo= rming the domain (interAS). >>>> - Having identified use-cases, architecture and security, the WG >>>> will identify gaps between currently available technologies and >>>> use-case requirements. >>>> - The WG will then define requirements for extensions to existing >>>> protocols or new protocols that address gaps that are identified. >>>> - The WG will first focus on the intra-domain forwarding definition. >>>> >>>> >>>> Documents : >>>> ------------------ >>>> . Use Cases >>>> . Architecture including security considerations >>>> - Protocol extension requirements >>>> . Interoperability Report >>>> >>>> >>>> Required protocol extensions are carried out in working groups respons= ible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out by = the WG. >>>> >>>> -----Message d'origine----- >>>> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 >>>> : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX; >>>> Rob Shakir Cc : Hannes Gredler; status@ietf.org Objet : Re: >>>> [Status] Good charter proposals from Hannes and Stefano : try to merge= ... >>>> >>>> Hi Stephane, Rob, >>>> >>>> one preliminary remark: I prefer to use he therm "node" rather than "r= outer". Use cases, such as Service Chaining requires that terminology. >>>> >>>> some other comments below... >>>> >>>> >>>> On Sep 10, 2013, at 11:19 AM, wrote: >>>>> Souns good to me, (adding OAM also) >>>>> >>>>> New recap : >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> Name: >>>>> Charter: >>>>> >>>>> >>>>> Introduction >>>>> ------------ >>>>> The following use cases: >>>>> . Path computation based on awareness of utilization or >>>>> performance data, within both centralized and distributed environment= s, . Multi-topology (dual planes, disjoint trees), . Simplification and red= uction of signaling components (scaling), . Combined application and networ= k layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM, = . etc. >>>>> >>>>> have triggered work on the definition of new architecture and protoco= l extensions allowing to combine well known shortest path based routing par= adigms with source/explicit routing methods. Some of these extensions have = been implemented already. >>>>> >>>>> >>>>> Objective >>>>> --------- >>>>> >>>>> Define an architecture where a node can steer a packet through a netw= ork or set of networks (interdomain) on any path. >>>> >>>> >>>> [SP] As stated above, I'm fine with the above definition but I >>>> assume this includes service chaining and that by "network or set >>>> of networks" you intend "nodes" which may include others things >>>> than just routers. >>>> >>>> [SLI] Agree >>>> >>>> >>>>> In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow a= node to steer a packet between any source and destination node within the = domain (formed of one or more networks), on any path (shortest, = non-shortest, explicit or based on other characteristics specified by segme= nt identifiers). >>>> >>>> >>>> [SP] without requiring to maintain state along the path, other >>>> than in the ingress node. >>>> >>>> [SLI] Agree >>>> >>>> >>>>> It may then send any packet that passes through it through any path t= hat it has specified and that is conform to the security rules. Downstream = routers along the path within the domain forward the packet as s= pecified by the router at the head-end of the path. >>>> >>>>> >>>>> The architecture should support centralized and distributed path comp= utation. >>>>> >>>>> The architecture should support OAM functions. >>>> >>>> >>>> [SP] The architecture should allow different mechanisms through >>>> which a path is constructed. SR allows a variety of mechanisms, >>>> not confined IGP/BGP path computation. >>>> >>>> [SLI] Agree >>>> >>>>> Work items : >>>>> ------------------ >>>>> >>>>> The working group is chartered for the following ordered l= ist of work items: >>>>> >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated >>>>> with the security considerations. The architecture framework and >>>>> security considerations must address the relations between networks f= orming the domain (interAS). >>>>> - Having identified use-cases, architecture and security, the WG >>>>> will identify gaps between currently available technologies and >>>>> use-case requirements. >>>>> - The WG will then define requirements for extensions to existing >>>>> protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding definition. >>>> >>>> >>>> [SP] The architecture will support tunnel and non-tunnel paradigms >>>> The architecture will support multiple dataplanes: MPLS and V6 >>>> >>>> >>>> Thanks. >>>> s. >>>> >>>> >>>>> Documents : >>>>> ------------------ >>>>> . Use Cases >>>>> . Architecture including security considerations >>>>> - Protocol extension requirements >>>>> . Interoperability Report >>>>> >>>>> >>>>> Protocol work may be carried out in this working group or in other wo= rking groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in coo= rdination with this WG, and in agreement with the WG chairs and responsible= ADs. >>>>> >>>>> -----Message d'origine----- >>>>> De : Rob Shakir [mailto:rjs@rob.sh] Envoy=E9 : mardi 10 septembre >>>>> 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler; >>>>> Stefano Previdi (sprevidi); status@ietf.org Objet >>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try t= o merge ... >>>>> >>>>> Hi Stephane, >>>>> >>>>> Thanks for this, looks good! Comments in-line marked rjs>. >>>>> >>>>> On 10 Sep 2013, at 08:50, wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF ..." >>>>>> starts to be unreadable :) >>>>>> >>>>>> Hannes and Stefano send to us two charter proposals that sounds good= to me. >>>>>> >>>>>> The main difference between the two proposals is that Stefano propos= e a segment bound to any type of instruction (forwarding, application or se= rvice based) while Hannes is focusing on forwarding actions (which is the f= irst priority, and I think everybody agree on this). >>>>> >>>>> rjs> Agreed -- I think it would be useful to allow definitions of seg= ments to identify different types of "service", since there appear to be so= me use cases (e.g., the explicit exit selection case) which require a segme= nt type describing something that is not explicitly IGP-based. >>>>> >>>>>> >>>>>> It would be interresting to have a feedback from the mailinglist on = this specific point. >>>>>> >>>>>> IMHO, there is a strong interrest to explore the service actions bou= nd to segment in a second step keeping forwarding as a priority. >>>>>> >>>>>> Apart of this problem, here is a merge try of the two good proposals= (I'm putting '<>' on hot topics :) ) : >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> -- >>>>>> Name: >>>>>> Charter: >>>>>> >>>>>> >>>>>> Introduction >>>>>> ------------ >>>>>> The following use cases: >>>>>> . Path computation based on awareness of utilization or >>>>>> performance data, within both centralized and distributed environmen= ts, . Multi-topology (dual planes, disjoint trees), . Simplification and re= duction of signaling components (scaling), . Combined application and netwo= rk layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM,= . etc. >>>>>> >>>>>> have triggered work on the definition of new architecture and protoc= ol extensions allowing to combine well known shortest path based routing pa= radigms with source/explicit routing methods. Some of these extensions have= been implemented already. >>>>>> >>>>>> >>>>>> Objective >>>>>> --------- >>>>>> >>>>>> Define an architecture where a node can steer a packet through a net= work or set of networks (interdomain) on any path (shortest, non shortest, = explicit, ). >>>>>> >>>>>> In this architecture, routers are sharing a common trust model and a= re forming a domain. >>>>>> Within this domain, a node can specify a path between itself and any= destination in the domain. . >>>>> >>>>> rjs> To clarify here, we define that our domain is under a common tru= st model (essentially, under common administrative control?), but then go o= n to talk about inter-domain elsewhere. Can we perhaps clarify (by defining= a specific " domain" nomenclature) and say something like: >>>>> >>>>> "In this architecture, routers sharing a common trust model form a domain. The architecture defined by this working group will allow = a node to steer a packet between any source and destination node within the= domain (formed of one or more networks), on any path (shortest,= non-shortest, explicit or based on other characteristics specified by segm= ent identifiers)." >>>>> >>>>>> It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. Downstream= routers along the path within the domain forward the packet as = specified by the router at the head-end of the path. >>>>>> >>>>>> The architecture should support centralized and distributed path com= putation. >>>>>> >>>>>> >>>>>> Work items : >>>>>> ------------------ >>>>>> >>>>>> The working group is chartered for the following ordered = list of work items: >>>>>> >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated >>>>>> with the security considerations. The architecture framework and >>>>>> security considerations must address the relations between domains (= inter domain). >>>>> >>>>> rjs> And then here "networks forming the domain"? >>>>> >>>>> Thanks for the efforts, >>>>> r. >>>>> >>>>>> - Having identified use-cases, architecture and security, the WG >>>>>> will identify gaps between currently available technologies and >>>>>> use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing >>>>>> protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>> >>>>>> >>>>>> Documents : >>>>>> ------------------ >>>>>> . Use Cases >>>>>> . Architecture including security considerations >>>>>> - Protocol extension requirements . Interoperability Report >>>>>> >>>>>> >>>>>> Protocol work may be carried out in this working group or in other w= orking groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in co= ordination with this WG, and in agreement with the WG chairs and responsibl= e ADs. >>>>>> >>>>>> >>>>>> >>>>>> Hope it helps to progress on the definition. >>>>>> >>>>>> >>>>>> Stephane >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendredi >>>>>> 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>>>>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and >>>>>> the next steps >>>>>> >>>>>> hi stephane, >>>>>> >>>>>> here is a revised draft charter as per your comments. >>>>>> >>>>>> --- >>>>>> >>>>>> domain contains a set of routers with the following >>>>>> characteristics: >>>>>> >>>>>> - They form a connected network >>>>>> - They can forward traffic through any path within the network >>>>>> using shortest path, or any other (e.g., an explicit) path >>>>>> - They share a common trust model. In this model, any router >>>>>> within the domain can specify a path between itself and any other >>>>>> router in the domain. It may then send any packet that passes >>>>>> through it through any path that it has specified and that is >>>>>> conform to the security rules. Downstream routers along the path >>>>>> within the domain forward the packet as specified by >>>>>> the router at the head-end of the path. >>>>>> >>>>>> The working group is chartered for the following ordered = list of work items: >>>>>> >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated >>>>>> with the security considerations. The architecture framework and >>>>>> security considerations must address the relations between domains (= interdomain). >>>>>> - Having identified use-cases, architecture and security, the WG >>>>>> will identify gaps between currently available technologies and >>>>>> use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing >>>>>> protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>> >>>>>> Protocol work may be carried out in this working group or in other w= orking groups responsible for the protocols, in coordination with this WG, = and in agreement with the WG chairs and responsible ADs. >>>>>> However, no protocol work will be adopted by a working group to addr= ess the identified use-cases until the requirements document motivating the= protocol work has been sent to the IESG for publication as an RFC. >>>>>> >>>>>> --- >>>>>> >>>>>> /hannes >>>>>> >>>>>> On Sep 4, 2013, at 10:02 AM, wrote: >>>>>> >>>>>>> Hannes, >>>>>>> >>>>>>> In case, we are using only directed forwarding (adjacency >>>>>>> segment), could we still talk about tunneling ? (it's a very very s= mall tunnel) Moreover talking about "stacking" is really dataplane agnostic= (MPLS) ... >>>>>>> >>>>>>> In the proposed segment routing architectural concepts, segments ar= e at the same "level" and pointer moves on the segment list, then the MPLS = instantiation is performing this using stacking ... >>>>>>> >>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen s= olution and it's closing the door to something else ... >>>>>>> >>>>>>> Finally, about the "routing" word, routing is essentially a "forwar= d" action which may limit the scope of what we can do by using a segment li= st. Actions associated with a segment could be something else than forwardi= ng. >>>>>>> >>>>>>> Do we want in the charter to limit the scope to routing actions ? >>>>>>> >>>>>>> I have no solution today to propose for the naming, but I completel= y agree with Loa, to first focus on working on the charter, and define a cl= ear scope of the work and then the name will be easier to find. >>>>>>> >>>>>>> Regarding your charter proposal : >>>>>>> >>>>>>> -------- >>>>>>> >>>>>>> - They form a connected network >>>>>>> [SLI] InterAS case must be included, but the WG can go step by ste= p and first release intraAS, and then doing interAS (in relation with IDR ?= ?). >>>>>>> >>>>>>> - They can forward traffic through the shortest paths or paths >>>>>>> other than the shortest (the latter called explicitly routed paths,= or explicit paths) [SLI] There is something else between SPT and Explicit= path, you can define other algorithms than SPT to define a path, and it's = not explicit path. Moreover I come back to my comment, on do we want to lim= it the scope to routing ? I would say no. >>>>>>> >>>>>>> - They share a common trust model. In this model, any router within= the ERD can specify an explicit path between itself and any other router i= n the ERD. It can then send any packet that passes through it through any p= ath that it has specified. >>>>>>> [SLI] Security considerations may have to be addressed in the >>>>>>> charter , especially for the interAS case (trust yes, but not >>>>>>> sure access to everything may not be good) >>>>>>> >>>>>>> Downstream routers within the ERD forward the packet as specified b= y the router at the head-end of the path. >>>>>>> [SLI] Yes, but any router in the middle may be able to change the e= nd to end explicit path. >>>>>>> >>>>>>> >>>>>>> >>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>>>> - Having identified use-cases, the WG will identify gaps between cu= rrently available technologies and use-case requirements. >>>>>>> - The WG will then define requirements for extensions to existing p= rotocols or new protocols that address gaps that are identified. >>>>>>> >>>>>>> [SLI] Agree, I would add : >>>>>>> - defining the architecture framework >>>>>>> - analysing the security considerisations >>>>>>> >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> >>>>>>> Here would be my proposal to extend yours : >>>>>>> >>>>>>> A domain contains a set of routers with the f= ollowing characteristics: >>>>>>> >>>>>>> - They form a connected network >>>>>>> - They can forward traffic through any path within the network >>>>>>> using shortest path, non shortest path or explicit path >>>>>>> - They may provide other types of services than forwarding and they= can enforce service actions in the path. >>>>>>> - They share a common trust model. In this model, any router within= the domain can specify a path between itself and any other router in the d= omain. It may then send any packet that passes through it through any path = that it has specified and that is conform to the security rules. Downstream= routers within the ERD forward the packet as specified by the router at th= e head-end of the path. >>>>>>> >>>>>>> The working group is chartered for the following ordered lis= t of work items: >>>>>>> >>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>> - The WG will then define the architecture framework associated wit= h the security considerations. The architecture framework and security cons= iderations must address the relations between domains (interdomain). >>>>>>> - Having identified use-cases, architecture and security, the WG wi= ll identify gaps between currently available technologies and use-case requ= irements. >>>>>>> - The WG will then define requirements for extensions to existing p= rotocols or new protocols that address gaps that are identified. >>>>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>>> >>>>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this WG,= and in agreement with the WG chairs and responsible ADs. However, no proto= col work will be adopted by a working group to address the ERD use-cases un= til the requirements document motivating the protocol work has been sent to= the IESG for publication as an RFC. >>>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>>>> la part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 >>>>>>> =C0 : Loa Andersson Cc : status@ietf.org Objet : Re: [Status] >>>>>>> Summary of STATUS BOF and the next steps >>>>>>> >>>>>>> good point - what about this charter proposal ? >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Stacked Tunnels for Explicit Routing (STER) >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> A explicit routing domain (ERD) contains a set of routers with the = following characteristics: >>>>>>> >>>>>>> - They form a connected network >>>>>>> - They can forward traffic through the shortest paths or paths >>>>>>> other than the shortest (the latter called explicitly routed >>>>>>> paths, or explicit paths) >>>>>>> - They share a common trust model. In this model, any router within= the ERD can specify an explicit path between itself and any other router i= n the ERD. It can then send any packet that passes through it through any p= ath that it has specified. Downstream routers within the ERD forward the pa= cket as specified by the router at the head-end of the path. >>>>>>> >>>>>>> The STER working group is chartered for the following ordered list = of work items: >>>>>>> >>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs. >>>>>>> - Having identified use-cases, the WG will identify gaps between cu= rrently available technologies and use-case requirements. >>>>>>> - The WG will then define requirements for extensions to existing p= rotocols or new protocols that address gaps that are identified. >>>>>>> >>>>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols, in coordination with this WG,= and in agreement with the WG chairs and responsible ADs. However, no proto= col work will be adopted by a working group to address the ERD use-cases un= til the requirements document motivating the protocol work has been sent to= the IESG for publication as an RFC. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> >>>>>>> >>>>>>> /hannes >>>>>>> >>>>>>> >>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have >>>>>>>> not seen a charter proposal, if there is one please point me to it. >>>>>>>> >>>>>>>> It seems a bit odd to put the cart (what the wg should do) >>>>>>>> before the horse (wg name). If we drill down the the charter >>>>>>>> first the wg name might be easier to figure out. >>>>>>>> >>>>>>>> /Loa >>>>>>>> >>>>>>>> PS >>>>>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>>>> " If the WG charter is limited to source routing, how will we han= dle the "non source routing" use cases of segment routing ? In another work= ing group ? So we will go back to the WG synchronization issue that has bee= n raised for this technology ..." >>>>>>>>> >>>>>>>>> That's why I suggested SRV2. We are revisiting source routing wit= h new concepts. More generic number/action behavior. >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>>> On Behalf Of stephane.litkowski@orange.com >>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>>>> To: AshwoodsmithPeter >>>>>>>>> Cc: status@ietf.org >>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>> >>>>>>>>> >>>>>>>>> There was a misunderstanding in my small comment :) so I will exp= lain more : >>>>>>>>> >>>>>>>>> In segment routing, you have more than basic source routing : seg= ment routing is just associate a segment number to an action and then combi= ne segment as you want, yes you can do source routing, but you also can do = more. >>>>>>>>> >>>>>>>>> In the other hand, I completely agree with your statement that >>>>>>>>> source routing is generic and dataplane agnostic, as segment rout= ing is ... >>>>>>>>> (segment routing is not a new dataplane ...) >>>>>>>>> >>>>>>>>> Now the definition of the WG naming must be inline with the >>>>>>>>> charter that will be defined ... (draft today) >>>>>>>>> >>>>>>>>> Based on the already existing consensus (at least for MPLS datapl= ane) brought up during Berlin STATUS BOF meeting, segment routing sounds to= be a good target candidate. >>>>>>>>> >>>>>>>>> So now, do we want to do more in the WG charter than just make pr= ogressing segment routing architecture and uses cases document and ensure c= oordination for the standardization of this technology ? >>>>>>>>> >>>>>>>>> Do we want to standardize other technologies in this WG ? I don't= think so, based on Stewart's conclusion email from the BOF :"A new WG focu= sed solely on SR therefore needs to be create" >>>>>>>>> >>>>>>>>> If the WG charter is limited to source routing, how will we handl= e the "non source routing" use cases of segment routing ? In another workin= g group ? So we will go back to the WG synchronization issue that has been = raised for this technology ... >>>>>>>>> >>>>>>>>> If the WG is focused on SR, let's use a name in relation with SR. >>>>>>>>> >>>>>>>>> Feedback ? >>>>>>>>> >>>>>>>>> >>>>>>>>> Stephane >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephane >>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbryan= t) Objet : Re: >>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>> >>>>>>>>> The term "source routing" has been around for a very long time an= d is data path agnostic. Its also the term used in the literature etc so my= preference is to stick with this existing well known and data path agnosti= c term. >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> "Source routing" is just a subcase of segment routing ... as it = is for IP routing ... >>>>>>>>>> >>>>>>>>>> Stephane >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>>>> De la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 15:= 02 =C0 : >>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl); = John G. >>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; >>>>>>>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> What is this 'segment routing' silliness? The correct term is '= source routing'. >>>>>>>>>> >>>>>>>>>> Yours Irrespectively, >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: status-bounces@ietf.org >>>>>>>>>>> [mailto:status-bounces@ietf.org] On Behalf Of Mark Townsley >>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>>>> To: Victor Kuarsingh >>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian >>>>>>>>>>> Farrel; Alvaro Retana (aretana); status@ietf.org; Stewart >>>>>>>>>>> Bryant >>>>>>>>>>> (stbryant) >>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next >>>>>>>>>>> steps >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>>> >>>>>>>>>>>> All, >>>>>>>>>>>> >>>>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>>> >>>>>>>>>>>> I note this since attempting to come up with an all >>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing >>>>>>>>>>>> is generic enough to associate to multiple functions. >>>>>>>>>>> >>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do >>>>>>>>>>> not have to have acronyms, but they do need to have an >>>>>>>>>>> 8-char limited short name for the various automated tools not t= o break. >>>>>>>>>>> >>>>>>>>>>> - Mark >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Victor K >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>>> >>>>>>>>>>>>> Roberta >>>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>> >>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The second task, which hopefully should be relatively >>>>>>>>>>>>>>> easy, is to find a better working name for the WG, since >>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is >>>>>>>>>>>>>>> going to be confusing in text and a difficult search term. >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> status mailing list >>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> >>>>>>>>>> _____________________________________________________________ >>>>>>>>>> ____ _ _ _ __ >>>>>>>>>> ___________________________________________________ >>>>>>>>>> >>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>>> donc pas etre diffuses, exploites ou copies sans >>>>>>>>>> autorisation. Si vous avez recu ce message par erreur, veuillez = le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les= messages electroniques etant susceptibles d'alteration, Orange decline tou= te responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>> >>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>> privileged information that may be protected by law; they should= not be distributed, used or copied without authorisation. >>>>>>>>>> If you have received this email in error, please notify the send= er and delete this message and its attachments. >>>>>>>>>> As emails may be altered, Orange is not liable for messages that= have been modified, changed or falsified. >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> >>>>>>>>> ______________________________________________________________ >>>>>>>>> ____ _ _ _ >>>>>>>>> ____________________________________________________ >>>>>>>>> >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>> donc pas etre diffuses, exploites ou copies sans autorisation. >>>>>>>>> Si vous avez recu ce message par erreur, veuillez le signaler a l= 'expediteur et le detruire ainsi que les pieces jointes. Les messages elect= roniques etant susceptibles d'alteration, Orange decline toute responsabili= te si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>> >>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>>>> If you have received this email in error, please notify the sende= r and delete this message and its attachments. >>>>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> ____ _ _ ___________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si >>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'expe= diteur et le detruire ainsi que les pieces jointes. Les messages electroniq= ues etant susceptibles d'alteration, Orange decline toute responsabilite si= ce message a ete altere, deforme ou falsifie. Merci. >>>>>>> >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should no= t be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________________________ >>>>>> ____ _ ___________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>> avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi que les pieces jointes. Les messages electroniques et= ant susceptibles d'alteration, Orange decline toute responsabilite si ce me= ssage a ete altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>>> >>>>> __________________________________________________________________ >>>>> ____ ___________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>> >>>> >>>> >>>> ___________________________________________________________________ >>>> ______________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>> >>> >>> >> >> > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From sprevidi@cisco.com Wed Sep 11 03:37:57 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E0421E80AC for ; Wed, 11 Sep 2013 03:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlobRCKzq2ev for ; Wed, 11 Sep 2013 03:37:51 -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 EA54E21E80A3 for ; Wed, 11 Sep 2013 03:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5374; q=dns/txt; s=iport; t=1378895871; x=1380105471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T0qibzkfdNXXBtWdkfnBEGW8PKEN7sh+OHe+CHJkpis=; b=SZoyhqL22gnWqfaWg7GXQUhHILGyeQLLyKXNUtuaQSVbwgaueFws8YRn MZVbwDJX6DBiKosg8A7GEUwIo/FX8gK+TqizZWqUSnCCwTTU87A3UCPkD jg8TZOBToPvsN+r06GeWl3XMU5HAuyjZE8G10pBSqLcf1KzQ1F0GUBqha U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAO1GMFKtJXHB/2dsb2JhbABRCoMHOFGDKr8/F4EFFnSCJQEBAQMBIxFFBQsCAQYCEgYCAgYdAwICAjAUAQIOAgQOBQgBEodhBgyVeJtTkWqBKYx6BAaBCDEHgmk0gQADmSeQQ4MggWgJFyI X-IronPort-AV: E=Sophos;i="4.90,883,1371081600"; d="scan'208";a="258271461" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 11 Sep 2013 10:37:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8BAbkaI024259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Sep 2013 10:37:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 11 Sep 2013 05:37:46 -0500 From: "Stefano Previdi (sprevidi)" To: Xuxiaohu Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAP//uVuAgACzLACAAJtuAIAAjIYA Date: Wed, 11 Sep 2013 10:37:45 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.205.82] Content-Type: text/plain; charset="utf-8" Content-ID: <63BFA676443A84468018514C5CAC6F4E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Stephane Litkowski , Rob Shakir , "status@ietf.org" , Hannes Gredler Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 10:37:58 -0000 SGkgWGlhb2h1LA0KDQpPbiBTZXAgMTEsIDIwMTMsIGF0IDQ6MTQgQU0sIFh1eGlhb2h1IHdyb3Rl Og0KPiANCj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+IOWPkeS7tuS6ujogc3RhdHVzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+ PiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0Oeac iDEx5pelIDA6NTgNCj4+IOaUtuS7tuS6ujogU3RlcGhhbmUgTGl0a293c2tpDQo+PiDmioTpgIE6 IEhhbm5lcyBHcmVkbGVyOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5vcmcNCj4+IOS4u+mimDog UmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9wb3NhbHMgZnJvbSBIYW5uZXMgYW5kIFN0ZWZh bm8gOiB0cnkgdG8NCj4+IG1lcmdlIC4uLg0KPj4gDQo+PiANCj4+IE9uIFNlcCAxMCwgMjAxMywg YXQgMToyNSBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiB3cm90ZToNCj4+IA0K Pj4+IEFncmVlIG9uIGFsbCBwcm9wb3NhbCBleGNlcHQgOg0KPj4+IA0KPj4+ICJbU1BdIFRoZSBh cmNoaXRlY3R1cmUgd2lsbCBzdXBwb3J0IHR1bm5lbCBhbmQgbm9uLXR1bm5lbCBwYXJhZGlnbXMN Cj4+PiAgICBUaGUgYXJjaGl0ZWN0dXJlIHdpbGwgc3VwcG9ydCBtdWx0aXBsZSBkYXRhcGxhbmVz OiBNUExTIGFuZCBWNiINCj4+PiANCj4+PiBJIGRvbid0IHNlZSB0aGUgcmVhc29uIGZvciB0aGlz IC4uLiBJTUhPLCB0aGUgZ2FwIGFuYWx5c2lzIGFuZCByZXF1aXJlbWVudHMNCj4+IGludmVudG9y eSB3aWxsIHJlc3VsdCBvbiBzYXlpbmcgb3Igbm90DQo+PiANCj4+IA0KPj4gW1NQXSBXaGlsZSBJ IHVuZGVyc3RhbmQgd2hhdCBicm91Z2h0IHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cw0KPj4gICAg IGluIHRoZSBwcm9wb3NlZCBjaGFydGVyOg0KPj4gCSJIYXZpbmcgaWRlbnRpZmllZCB1c2UtY2Fz ZXMsIGFyY2hpdGVjdHVyZSBhbmQgc2VjdXJpdHksDQo+PiAJIHRoZSBXRyB3aWxsIGlkZW50aWZ5 IGdhcHMgYmV0d2VlbiBjdXJyZW50bHkgYXZhaWxhYmxlDQo+PiAJIHRlY2hub2xvZ2llcyBhbmQg dXNlLWNhc2UgcmVxdWlyZW1lbnRzLg0KPj4gCSBUaGUgV0cgd2lsbCB0aGVuIGRlZmluZSByZXF1 aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8NCj4+IAkgZXhpc3RpbmcgcHJvdG9jb2xzIG9yIG5l dyBwcm90b2NvbHMgdGhhdCBhZGRyZXNzIGdhcHMNCj4+IAkgdGhhdCBhcmUgaWRlbnRpZmllZC4i DQo+PiANCj4+ICAgICBJJ2QgbGlrZSB0byBwb2ludCBvdXQgd2l0aCBiZXR0ZXIgcHJlY2lzaW9u IHdoYXQgYXJlIHRoZQ0KPj4gICAgIGRpcmVjdGlvbnMgd2UgYXJlIEFMUkVBRFkgZW5nYWdlZCBp bnRvOiBkYXRhcGxhbmVzIGFuZA0KPj4gICAgIHBhcmFkaWdtcy4gQXMgSSBtZW50aW9uZWQgaW4g bXkgY2hhcnRlciBwcm9wb3NhbCwgd2UgZG8gaGF2ZQ0KPj4gICAgIGltcGxlbWVudGF0aW9ucyBh bmQgbXVsdGktdmVuZG9yIGludGVyb3BlcmFiaWxpdHkgdGVzdHMgd2lsbA0KPj4gICAgIGhhcHBl biBzb29uLiBTbywgSSBqdXN0IHdhbnQgdG8gYmUgc3VyZSB3ZSBkb24ndCBpZ25vcmUgdGhpcw0K Pj4gICAgIHJlYWxpdHkuDQo+PiANCj4+ICAgICBNUExTIGFuZCB2NiBkYXRhLXBsYW5lIGFyZSBw YXJ0IG9mIHRoaXMgcmVhbGl0eSwgYXMgd2VsbCBhcw0KPj4gICAgIHR1bm5lbC1iYXNlZCBhbmQg bm9uLXR1bm5lbCBiYXNlZCBhcHByb2FjaGVzLg0KPiANCj4gSSBkb24ndCB0aGluayBpdCdzIHN1 aXRhYmxlIHRvIG1lbnRpb24gZGV2ZWxvcGluZyBJUHY2IHNwZWNpZmljIFNSIG1lY2hhbmlzbSBp biB0aGUgY3VycmVudCBjaGFydGVyIHVubGVzcyB0aGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3Ig YW55IGNoYW5nZSB0byB0aGUgZXhpc3RpbmcgSVB2NiBkYXRhIHBsYW5lLg0KDQo+IEFjY29yZGlu ZyB0byB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMgcXVvdGVkIGZyb20gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZmlsc2ZpbHMtcnRnd2ctc2VnbWVudC1yb3V0aW5nLTAwI3BhZ2Ut OSwgIi4uLlRoZSBzb3VyY2Ugcm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVkIGxpc3Qgb2Yg c2VnbWVudHMgaW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMuLi4iIElmIHNvLCB3aHkgbm90IGRpcmVj dGx5IHVzZSBhbiBvcmRlcmVkIGxpc3Qgb2YgbGFiZWxzIChpLmUuLCBNUExTIGxhYmVsIHN0YWNr KSB0byBkbyB0aGF0IChzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3N0 YXR1cy9jdXJyZW50L21zZzAwMTY1Lmh0bWwpPyANCg0KDQp2NiBkYXRhcGxhbmUgYWxsb3dzIG1v cmUgZWZmZWN0aXZlIHNvdXJjZSByb3V0ZSBjYXBhYmlsaXR5IGJ5IA0KbGV2ZXJhZ2luZyBleHRl bnNpb25zIGhlYWRlcnMuIEhlbmNlIHRoZSBwcm9wb3NhbCB0aGF0IHdpbGwNCmNvbnNpc3Qgb2Yg ZGVmaW5pbmcgYSBuZXcgRXh0ZW5zaW9uIEhlYWRlciBmb3IgU1Igd2hlcmUgdGhlIA0Kc2VnbWVu dCBsaXN0IGlzIGVuY29kZWQgYW5kIF9wcmVzZXJ2ZWRfIHRocm91Z2hvdXQgdGhlIHBhdGguDQoN ClNvLCBJIGRvIHN0cm9uZ2x5IGJlbGlldmUgd2UgaGF2ZSB0byB3b3JrIG9uIHY2IGFuZCBzaW5j ZSB3ZSdyZSANCmluIHRoZSBkZWZpbml0aW9uIG9mIGEgY2hhcnRlciAoaS5lLjogbm90IHRoZSBk ZXRhaWxlZCByZXZpZXcgDQpvZiB0aGUgc29sdXRpb25zKSBJIGJlbGlldmUgdjYgc2hvdWxkIGJl IHBhcnQgb2YgaXQuDQoNClRoYW5rcy4NCnMuDQoNCg0KPiANCj4gKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAgIFRoZSBtYWluIGRpZmZlcmVuY2VzIGZyb20g dGhlIElQdjYgc291cmNlIHJvdXRlIG1vZGVsIGFyZToNCj4gDQo+IA0KPiANCj4gRmlsc2ZpbHMs IGV0IGFsLiAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQ YWdlIDldDQo+IA0KPiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFNlZ21lbnQgUm91dGlu ZyAgICAgICAgICAgICAgICAgICBKdW5lIDIwMTMNCj4gDQo+IA0KPiAgICAgIFRoZSBzb3VyY2Ug cm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaW5zdGVhZA0K PiAgICAgIG9mIElQIGFkZHJlc3Nlcy4NCj4gDQo+ICAgICAgQSBzZWdtZW50IGNhbiByZXByZXNl bnQgYW55IGluc3RydWN0aW9uIGVpdGhlciBhIHNlcnZpY2Ugb3IgYQ0KPiAgICAgIHRvcG9sb2dp Y2FsIHBhdGguICBUb3BvbG9naWNhbGx5LCB0aGUgcGF0aCB0byBhbiBJUCBhZGRyZXNzIGlzDQo+ ICAgICAgb2Z0ZW4gbGltaXRlZCB0byB0aGUgc2hvcnRlc3QtcGF0aCB0byB0aGF0IGFkZHJlc3Mu ICBBIHNlZ21lbnQgY2FuDQo+ICAgICAgcmVwcmVzZW50IGFueSBwYXRoIChlLmcuIGFuIGFkamFj ZW5jeSBzZWdtZW50IGZvcmNlcyBhIHBhY2tldCB0byBhDQo+ICAgICAgbmV4dGhvcCB0aHJvdWdo IGEgc3BlY2lmaWMgYWRqYWNlbmN5IGV2ZW4gaWYgdGhlIHNob3J0ZXN0LXBhdGggdG8NCj4gICAg ICB0aGUgbmV4dC1ob3AgZG9lcyBub3QgdXNlIHRoYXQgYWRqYWNlbmN5KS4NCj4gDQo+ICAgICAg VGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBlZ2RlIHJvdXRlcnMgYXJlIGlkZW50aWZpZWQgYW5kIGFs d2F5cw0KPiAgICAgIGF2YWlsYWJsZSwgYWxsb3dpbmcgZm9yIGludGVyZXN0aW5nIGFjY291bnRp bmcgYW5kIHBvbGljeQ0KPiAgICAgIGFwcGxpY2F0aW9ucy4NCj4gDQo+ICAgICAgVGhlIHNvdXJj ZSByb3V0ZSBmdW5jdGlvbmFsaXR5IGNhbm5vdCBiZSBjb250cm9sbGVkIGZyb20gb3V0c2lkZQ0K PiAgICAgIHRoZSBTUiBkb21haW4uDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1IA0KPiANCg0K From jgs@juniper.net Wed Sep 11 11:32:31 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0957921F8B35 for ; Wed, 11 Sep 2013 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.94 X-Spam-Level: * X-Spam-Status: No, score=1.94 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHXR9SpICep4 for ; Wed, 11 Sep 2013 11:32:25 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9EE21F89FF for ; Wed, 11 Sep 2013 11:32:25 -0700 (PDT) Received: from mail73-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 11 Sep 2013 18:32:24 +0000 Received: from mail73-va3 (localhost [127.0.0.1]) by mail73-va3-R.bigfish.com (Postfix) with ESMTP id C012B160171; Wed, 11 Sep 2013 18:32:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -66 X-BigFish: VPS-66(zz62a3I98dI9371Ic89bh936eI542I1432I15caKJ4015I1447I14ffIdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b2m20b3m1155h) Received-SPF: pass (mail73-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(53754006)(377424004)(189002)(199002)(377454003)(51914003)(252514010)(24454002)(55784002)(13464003)(164054003)(69226001)(19580395003)(66066001)(51856001)(80976001)(62966002)(561944002)(76786001)(53416003)(47976001)(65816001)(47736001)(33656001)(80022001)(81686001)(49866001)(81816001)(76796001)(74706001)(74662001)(50986001)(83072001)(19580405001)(83322001)(23756003)(4396001)(50466002)(74502001)(47446002)(82746002)(74366001)(50226001)(15975445006)(76482001)(59766001)(77982001)(81542001)(57306001)(53806001)(42186004)(46102001)(56776001)(54316002)(81342001)(74876001)(31966008)(63696002)(79102001)(77096001)(36756003)(47776003)(56816003)(77156001)(83706001)(83716001)(42262001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB120; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail73-va3 (localhost.localdomain [127.0.0.1]) by mail73-va3 (MessageSwitch) id 137892434043316_29146; Wed, 11 Sep 2013 18:32:20 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.253]) by mail73-va3.bigfish.com (Postfix) with ESMTP id 02A7C1A0041; Wed, 11 Sep 2013 18:32:20 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 11 Sep 2013 18:32:19 +0000 Received: from BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Wed, 11 Sep 2013 18:32:19 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 11 Sep 2013 18:32:16 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "John G. Scudder" In-Reply-To: <10969_1378893213_52303D9D_10969_5864_1_EEE55384044474429A926C625D0FCC810964DECA2B@PUEXCB2F.nanterre.francetelecom.fr> Date: Wed, 11 Sep 2013 14:32:08 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <474760C9-0057-46A7-A744-6EF45BAF349B@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <10969_1378893213_52303D9D_10969_5864_1_EEE55384044474429A926C625D0FCC810964DECA2B@PUEXCB2F.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BL2PR08CA012.namprd08.prod.outlook.com (10.141.66.32) To BLUPR05MB120.namprd05.prod.outlook.com (10.255.214.28) X-Forefront-PRVS: 09669DB681 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Hannes Gredler , Rob Shakir , "status@ietf.org" , Stefano Previdi Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 18:32:31 -0000 Stephane, This seems like a very reasonable way forward to me and I think the last = draft charter you posted is "about right". In particular I want to = support the idea that "the use case analysis ... will give us what we = need to address exactly".=20 --John On Sep 11, 2013, at 5:53 AM, stephane.litkowski@orange.com wrote: > Hannes, >=20 > Regarding "Service chaining", I would agree to not mention it directly = in the charter (it's not mentionned explictly in my last proposal) BUT I = don't want to close the door to other "action types" than forwarding. = That's why using the wording "node" , "steering packets" seems to be = good because it's large enough to address use cases that are not = detailled today (for example service chaining). >=20 > So my approach would be , keep it large in definition using the = proposed wording and then the use case analysis (in the work items) will = give us what we need to address exactly. >=20 > Does it make sense for you to use this way ? >=20 >=20 > Thanks, >=20 > Stephane >=20 >=20 >=20 > -----Message d'origine----- > De : Hannes Gredler [mailto:hannes@juniper.net] > Envoy=E9 : mercredi 11 septembre 2013 08:15 > =C0 : Stefano Previdi > Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; status@ietf.org > Objet : Re: [Status] Good charter proposals from Hannes and Stefano : = try to merge ... >=20 > stefano, >=20 > On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote: >=20 >> Hannes, >>=20 >> On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote: >>> stefano, >>>=20 >>> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: >>>=20 >>>>=20 >>>> On Sep 10, 2013, at 1:25 PM, wrote: >>>>=20 >>>>> Agree on all proposal except : >>>>>=20 >>>>> "[SP] The architecture will support tunnel and non-tunnel = paradigms >>>>> The architecture will support multiple dataplanes: MPLS and V6" >>>>>=20 >>>>> I don't see the reason for this ... IMHO, the gap analysis and >>>>> requirements inventory will result on saying or not >>>>=20 >>>>=20 >>>> [SP] While I understand what brought the following statements >>>> in the proposed charter: >>>> "Having identified use-cases, architecture and security, >>>> the WG will identify gaps between currently available >>>> technologies and use-case requirements. >>>> The WG will then define requirements for extensions to >>>> existing protocols or new protocols that address gaps >>>> that are identified." >>>>=20 >>>> I'd like to point out with better precision what are the >>>> directions we are ALREADY engaged into: dataplanes and >>>> paradigms. As I mentioned in my charter proposal, we do have >>>> implementations and multi-vendor interoperability tests will >>>> happen soon. So, I just want to be sure we don't ignore this >>>> reality. >>>=20 >>> HG> just because you have an implementation for does not >>> HG> constitute >>> community interest. we are trying to build here a charter that >>> matches what a broader community wants. if the use-case that you're = concerned >>> about (service-chaining and a new internet data plane #4) are = compelling >>> enough the group will work on it, but mandating that into the = charter, >>> without asking the though questions first seems a wrong start to = me. >>=20 >>=20 >> [SP] Sorry to contradict but it's the exact opposite. If a group >> of vendors decide to invest in implementations is because >> they received, analyzed, processed a set of requirements >> coming for operators who know pretty well what they do, what >> they want to deploy and the technology they want the vendors >> to deliver. This fits the definition of "community interest". >=20 > HG> interestingly enough i haven't encountered a network operator so > far who says 'i need SR for service chaining' nor > we had somebody asking for this in the 'operator use case' slots > in Berlin. - So who are they ? - can you manage such that > they speak up and make their case ? >=20 >> My point is that I strongly _suggest_ IETF WG (any) not to >> neglect these facts and not write a down a charter ... > [ ... ] >=20 > HG> i'd like to have some proof point for your 'facts' prior > to making 'service chaining' a charter item. >=20 >> Having said that, whoever does NOT believe in the benefit of >> a newly proposed technology, is always free to not implement >> it and to not deploy it. >=20 > HG> that is fine and well understood, but since you have a desire to > standardize your 'newly proposed technology' you also need to play > a bit by the rules. >=20 >>>>> : we must use tunnels and/or non tunnels, and the following = dataplanes ... But I don't see the reason to put solutions directly in = the charter ... >>>>=20 >>>>=20 >>>> these are not solutions these are way to avoid boundaries in the >>>> framework. >>>>=20 >>>> Thanks. >>>> s. >>>>=20 >>>>=20 >>>>> Could you explain your point ? >>>>>=20 >>>>>=20 >>>>> updated with the other comments : >>>>>=20 >>>>> = ------------------------------------------------------------------- >>>>> Name: >>>>> Charter: >>>>>=20 >>>>>=20 >>>>> Introduction >>>>> ------------ >>>>> The following use cases: >>>>> . Path computation based on awareness of utilization or = performance >>>>> data, within both centralized and distributed environments, . = Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and = network layer path specification, . Full coverage LFA-FRR, . Topology = Aware OAM, . etc. >>>>>=20 >>>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>>=20 >>>>>=20 >>>>> Objective >>>>> --------- >>>>>=20 >>>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path without requiring = to maintain state along the path, other than in the ingress node. >>>>>=20 >>>>> A node may be any type of device including routers or appliances. >>>>>=20 >>>>> In this architecture, nodes sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers). >>>>>=20 >>>>> It may then send any packet that passes through it through any = path >>>>> that it has specified and that is conform to the security rules. >>>>> Downstream nodes along the path within the domain >>>>> forward the packet by using the informations inserted by the node >>>>> at the head-end >>>>>=20 >>>>> The architecture should support centralized and distributed path = computation. >>>>>=20 >>>>> The architecture should support OAM functions. >>>>>=20 >>>>> The architecture should allow different mechanisms through which = a >>>>> path is constructed. SR allows a variety of mechanisms, not >>>>> confined IGP/BGP path computation. >>>>>=20 >>>>> As MPLS dataplane is largely deployed, the WG should = avoid any modification in the MPLS dataplane when defining the = architecture. >>>>>=20 >>>>>=20 >>>>> Work items : >>>>> ------------------ >>>>>=20 >>>>> The working group is chartered for the following = ordered list of work items: >>>>>=20 >>>>> - The first goal of the WG is to identify use-cases. >>>>> - The WG will then define the architecture framework associated >>>>> with the security considerations. The architecture framework and >>>>> security considerations must address the relations between = networks forming the domain (interAS). >>>>> - Having identified use-cases, architecture and security, the WG >>>>> will identify gaps between currently available technologies and >>>>> use-case requirements. >>>>> - The WG will then define requirements for extensions to existing >>>>> protocols or new protocols that address gaps that are identified. >>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>=20 >>>>>=20 >>>>> Documents : >>>>> ------------------ >>>>> . Use Cases >>>>> . Architecture including security considerations >>>>> - Protocol extension requirements >>>>> . Interoperability Report >>>>>=20 >>>>>=20 >>>>> Required protocol extensions are carried out in working groups = responsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be = carried out by the WG. >>>>>=20 >>>>> -----Message d'origine----- >>>>> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9= >>>>> : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX; >>>>> Rob Shakir Cc : Hannes Gredler; status@ietf.org Objet : Re: >>>>> [Status] Good charter proposals from Hannes and Stefano : try to = merge ... >>>>>=20 >>>>> Hi Stephane, Rob, >>>>>=20 >>>>> one preliminary remark: I prefer to use he therm "node" rather = than "router". Use cases, such as Service Chaining requires that = terminology. >>>>>=20 >>>>> some other comments below... >>>>>=20 >>>>>=20 >>>>> On Sep 10, 2013, at 11:19 AM, = wrote: >>>>>> Souns good to me, (adding OAM also) >>>>>>=20 >>>>>> New recap : >>>>>>=20 >>>>>> = ------------------------------------------------------------------ >>>>>> - >>>>>> Name: >>>>>> Charter: >>>>>>=20 >>>>>>=20 >>>>>> Introduction >>>>>> ------------ >>>>>> The following use cases: >>>>>> . Path computation based on awareness of utilization or >>>>>> performance data, within both centralized and distributed = environments, . Multi-topology (dual planes, disjoint trees), . = Simplification and reduction of signaling components (scaling), . = Combined application and network layer path specification, . Full = coverage LFA-FRR, . Topology Aware OAM, . etc. >>>>>>=20 >>>>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>>>=20 >>>>>>=20 >>>>>> Objective >>>>>> --------- >>>>>>=20 >>>>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path. >>>>>=20 >>>>>=20 >>>>> [SP] As stated above, I'm fine with the above definition but I >>>>> assume this includes service chaining and that by "network or set >>>>> of networks" you intend "nodes" which may include others things >>>>> than just routers. >>>>>=20 >>>>> [SLI] Agree >>>>>=20 >>>>>=20 >>>>>> In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers). >>>>>=20 >>>>>=20 >>>>> [SP] without requiring to maintain state along the path, other >>>>> than in the ingress node. >>>>>=20 >>>>> [SLI] Agree >>>>>=20 >>>>>=20 >>>>>> It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >>>>>=20 >>>>>>=20 >>>>>> The architecture should support centralized and distributed path = computation. >>>>>>=20 >>>>>> The architecture should support OAM functions. >>>>>=20 >>>>>=20 >>>>> [SP] The architecture should allow different mechanisms through >>>>> which a path is constructed. SR allows a variety of mechanisms, >>>>> not confined IGP/BGP path computation. >>>>>=20 >>>>> [SLI] Agree >>>>>=20 >>>>>> Work items : >>>>>> ------------------ >>>>>>=20 >>>>>> The working group is chartered for the following = ordered list of work items: >>>>>>=20 >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated >>>>>> with the security considerations. The architecture framework and >>>>>> security considerations must address the relations between = networks forming the domain (interAS). >>>>>> - Having identified use-cases, architecture and security, the WG >>>>>> will identify gaps between currently available technologies and >>>>>> use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing >>>>>> protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>=20 >>>>>=20 >>>>> [SP] The architecture will support tunnel and non-tunnel paradigms >>>>> The architecture will support multiple dataplanes: MPLS and V6 >>>>>=20 >>>>>=20 >>>>> Thanks. >>>>> s. >>>>>=20 >>>>>=20 >>>>>> Documents : >>>>>> ------------------ >>>>>> . Use Cases >>>>>> . Architecture including security considerations >>>>>> - Protocol extension requirements >>>>>> . Interoperability Report >>>>>>=20 >>>>>>=20 >>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP = ...), in coordination with this WG, and in agreement with the WG chairs = and responsible ADs. >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Rob Shakir [mailto:rjs@rob.sh] Envoy=E9 : mardi 10 septembre >>>>>> 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler; >>>>>> Stefano Previdi (sprevidi); status@ietf.org Objet >>>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : = try to merge ... >>>>>>=20 >>>>>> Hi Stephane, >>>>>>=20 >>>>>> Thanks for this, looks good! Comments in-line marked rjs>. >>>>>>=20 >>>>>> On 10 Sep 2013, at 08:50, wrote: >>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF = ..." >>>>>>> starts to be unreadable :) >>>>>>>=20 >>>>>>> Hannes and Stefano send to us two charter proposals that sounds = good to me. >>>>>>>=20 >>>>>>> The main difference between the two proposals is that Stefano = propose a segment bound to any type of instruction (forwarding, = application or service based) while Hannes is focusing on forwarding = actions (which is the first priority, and I think everybody agree on = this). >>>>>>=20 >>>>>> rjs> Agreed -- I think it would be useful to allow definitions of = segments to identify different types of "service", since there appear to = be some use cases (e.g., the explicit exit selection case) which require = a segment type describing something that is not explicitly IGP-based. >>>>>>=20 >>>>>>>=20 >>>>>>> It would be interresting to have a feedback from the mailinglist = on this specific point. >>>>>>>=20 >>>>>>> IMHO, there is a strong interrest to explore the service actions = bound to segment in a second step keeping forwarding as a priority. >>>>>>>=20 >>>>>>> Apart of this problem, here is a merge try of the two good = proposals (I'm putting '<>' on hot topics :) ) : >>>>>>>=20 >>>>>>>=20 >>>>>>> = ----------------------------------------------------------------- >>>>>>> -- >>>>>>> Name: >>>>>>> Charter: >>>>>>>=20 >>>>>>>=20 >>>>>>> Introduction >>>>>>> ------------ >>>>>>> The following use cases: >>>>>>> . Path computation based on awareness of utilization or >>>>>>> performance data, within both centralized and distributed = environments, . Multi-topology (dual planes, disjoint trees), . = Simplification and reduction of signaling components (scaling), . = Combined application and network layer path specification, . Full = coverage LFA-FRR, . Topology Aware OAM, . etc. >>>>>>>=20 >>>>>>> have triggered work on the definition of new architecture and = protocol extensions allowing to combine well known shortest path based = routing paradigms with source/explicit routing methods. Some of these = extensions have been implemented already. >>>>>>>=20 >>>>>>>=20 >>>>>>> Objective >>>>>>> --------- >>>>>>>=20 >>>>>>> Define an architecture where a node can steer a packet through a = network or set of networks (interdomain) on any path (shortest, non = shortest, explicit, ). >>>>>>>=20 >>>>>>> In this architecture, routers are sharing a common trust model = and are forming a domain. >>>>>>> Within this domain, a node can specify a path between itself and = any destination in the domain. . >>>>>>=20 >>>>>> rjs> To clarify here, we define that our domain is under a common = trust model (essentially, under common administrative control?), but = then go on to talk about inter-domain elsewhere. Can we perhaps clarify = (by defining a specific " domain" nomenclature) and say = something like: >>>>>>=20 >>>>>> "In this architecture, routers sharing a common trust model form = a domain. The architecture defined by this working group will = allow a node to steer a packet between any source and destination node = within the domain (formed of one or more networks), on any = path (shortest, non-shortest, explicit or based on other characteristics = specified by segment identifiers)." >>>>>>=20 >>>>>>> It may then send any packet that passes through it through any = path that it has specified and that is conform to the security rules. = Downstream routers along the path within the domain forward = the packet as specified by the router at the head-end of the path. >>>>>>>=20 >>>>>>> The architecture should support centralized and distributed path = computation. >>>>>>>=20 >>>>>>>=20 >>>>>>> Work items : >>>>>>> ------------------ >>>>>>>=20 >>>>>>> The working group is chartered for the following = ordered list of work items: >>>>>>>=20 >>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>> - The WG will then define the architecture framework associated >>>>>>> with the security considerations. The architecture framework and >>>>>>> security considerations must address the relations between = domains (inter domain). >>>>>>=20 >>>>>> rjs> And then here "networks forming the domain"? >>>>>>=20 >>>>>> Thanks for the efforts, >>>>>> r. >>>>>>=20 >>>>>>> - Having identified use-cases, architecture and security, the WG >>>>>>> will identify gaps between currently available technologies and >>>>>>> use-case requirements. >>>>>>> - The WG will then define requirements for extensions to = existing >>>>>>> protocols or new protocols that address gaps that are = identified. >>>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>>=20 >>>>>>>=20 >>>>>>> Documents : >>>>>>> ------------------ >>>>>>> . Use Cases >>>>>>> . Architecture including security considerations >>>>>>> - Protocol extension requirements . Interoperability Report >>>>>>>=20 >>>>>>>=20 >>>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP = ...), in coordination with this WG, and in agreement with the WG chairs = and responsible ADs. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Hope it helps to progress on the definition. >>>>>>>=20 >>>>>>>=20 >>>>>>> Stephane >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : = vendredi >>>>>>> 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>>>>>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and >>>>>>> the next steps >>>>>>>=20 >>>>>>> hi stephane, >>>>>>>=20 >>>>>>> here is a revised draft charter as per your comments. >>>>>>>=20 >>>>>>> --- >>>>>>>=20 >>>>>>> domain contains a set of routers with the following >>>>>>> characteristics: >>>>>>>=20 >>>>>>> - They form a connected network >>>>>>> - They can forward traffic through any path within the network >>>>>>> using shortest path, or any other (e.g., an explicit) path >>>>>>> - They share a common trust model. In this model, any router >>>>>>> within the domain can specify a path between itself and any = other >>>>>>> router in the domain. It may then send any packet that passes >>>>>>> through it through any path that it has specified and that is >>>>>>> conform to the security rules. Downstream routers along the path >>>>>>> within the domain forward the packet as specified by >>>>>>> the router at the head-end of the path. >>>>>>>=20 >>>>>>> The working group is chartered for the following = ordered list of work items: >>>>>>>=20 >>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>> - The WG will then define the architecture framework associated >>>>>>> with the security considerations. The architecture framework and >>>>>>> security considerations must address the relations between = domains (interdomain). >>>>>>> - Having identified use-cases, architecture and security, the WG >>>>>>> will identify gaps between currently available technologies and >>>>>>> use-case requirements. >>>>>>> - The WG will then define requirements for extensions to = existing >>>>>>> protocols or new protocols that address gaps that are = identified. >>>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>>=20 >>>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. >>>>>>> However, no protocol work will be adopted by a working group to = address the identified use-cases until the requirements document = motivating the protocol work has been sent to the IESG for publication = as an RFC. >>>>>>>=20 >>>>>>> --- >>>>>>>=20 >>>>>>> /hannes >>>>>>>=20 >>>>>>> On Sep 4, 2013, at 10:02 AM, = wrote: >>>>>>>=20 >>>>>>>> Hannes, >>>>>>>>=20 >>>>>>>> In case, we are using only directed forwarding (adjacency >>>>>>>> segment), could we still talk about tunneling ? (it's a very = very small tunnel) Moreover talking about "stacking" is really dataplane = agnostic (MPLS) ... >>>>>>>>=20 >>>>>>>> In the proposed segment routing architectural concepts, = segments are at the same "level" and pointer moves on the segment list, = then the MPLS instantiation is performing this using stacking ... >>>>>>>>=20 >>>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a = chosen solution and it's closing the door to something else ... >>>>>>>>=20 >>>>>>>> Finally, about the "routing" word, routing is essentially a = "forward" action which may limit the scope of what we can do by using a = segment list. Actions associated with a segment could be something else = than forwarding. >>>>>>>>=20 >>>>>>>> Do we want in the charter to limit the scope to routing actions = ? >>>>>>>>=20 >>>>>>>> I have no solution today to propose for the naming, but I = completely agree with Loa, to first focus on working on the charter, and = define a clear scope of the work and then the name will be easier to = find. >>>>>>>>=20 >>>>>>>> Regarding your charter proposal : >>>>>>>>=20 >>>>>>>> -------- >>>>>>>>=20 >>>>>>>> - They form a connected network >>>>>>>> [SLI] InterAS case must be included, but the WG can go step by = step and first release intraAS, and then doing interAS (in relation with = IDR ??). >>>>>>>>=20 >>>>>>>> - They can forward traffic through the shortest paths or paths >>>>>>>> other than the shortest (the latter called explicitly routed = paths, or explicit paths) [SLI] There is something else between SPT and = Explicit path, you can define other algorithms than SPT to define a = path, and it's not explicit path. Moreover I come back to my comment, on = do we want to limit the scope to routing ? I would say no. >>>>>>>>=20 >>>>>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. >>>>>>>> [SLI] Security considerations may have to be addressed in the >>>>>>>> charter , especially for the interAS case (trust yes, but not >>>>>>>> sure access to everything may not be good) >>>>>>>>=20 >>>>>>>> Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>>>> [SLI] Yes, but any router in the middle may be able to change = the end to end explicit path. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> - The first goal of the STER WG is to identify use-cases for = ERDs. >>>>>>>> - Having identified use-cases, the WG will identify gaps = between currently available technologies and use-case requirements. >>>>>>>> - The WG will then define requirements for extensions to = existing protocols or new protocols that address gaps that are = identified. >>>>>>>>=20 >>>>>>>> [SLI] Agree, I would add : >>>>>>>> - defining the architecture framework >>>>>>>> - analysing the security considerisations >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --------- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Here would be my proposal to extend yours : >>>>>>>>=20 >>>>>>>> A domain contains a set of routers with = the following characteristics: >>>>>>>>=20 >>>>>>>> - They form a connected network >>>>>>>> - They can forward traffic through any path within the network >>>>>>>> using shortest path, non shortest path or explicit path >>>>>>>> - They may provide other types of services than forwarding and = they can enforce service actions in the path. >>>>>>>> - They share a common trust model. In this model, any router = within the domain can specify a path between itself and any other router = in the domain. It may then send any packet that passes through it = through any path that it has specified and that is conform to the = security rules. Downstream routers within the ERD forward the packet as = specified by the router at the head-end of the path. >>>>>>>>=20 >>>>>>>> The working group is chartered for the following ordered = list of work items: >>>>>>>>=20 >>>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>>> - The WG will then define the architecture framework associated = with the security considerations. The architecture framework and = security considerations must address the relations between domains = (interdomain). >>>>>>>> - Having identified use-cases, architecture and security, the = WG will identify gaps between currently available technologies and = use-case requirements. >>>>>>>> - The WG will then define requirements for extensions to = existing protocols or new protocols that address gaps that are = identified. >>>>>>>> - The WG will first focus on the intra-domain forwarding = definition. >>>>>>>>=20 >>>>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. = However, no protocol work will be adopted by a working group to address = the ERD use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] = De >>>>>>>> la part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 = 18:31 >>>>>>>> =C0 : Loa Andersson Cc : status@ietf.org Objet : Re: [Status] >>>>>>>> Summary of STATUS BOF and the next steps >>>>>>>>=20 >>>>>>>> good point - what about this charter proposal ? >>>>>>>>=20 >>>>>>>> --- >>>>>>>>=20 >>>>>>>> Stacked Tunnels for Explicit Routing (STER) >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>=20 >>>>>>>> A explicit routing domain (ERD) contains a set of routers with = the following characteristics: >>>>>>>>=20 >>>>>>>> - They form a connected network >>>>>>>> - They can forward traffic through the shortest paths or paths >>>>>>>> other than the shortest (the latter called explicitly routed >>>>>>>> paths, or explicit paths) >>>>>>>> - They share a common trust model. In this model, any router = within the ERD can specify an explicit path between itself and any other = router in the ERD. It can then send any packet that passes through it = through any path that it has specified. Downstream routers within the = ERD forward the packet as specified by the router at the head-end of the = path. >>>>>>>>=20 >>>>>>>> The STER working group is chartered for the following ordered = list of work items: >>>>>>>>=20 >>>>>>>> - The first goal of the STER WG is to identify use-cases for = ERDs. >>>>>>>> - Having identified use-cases, the WG will identify gaps = between currently available technologies and use-case requirements. >>>>>>>> - The WG will then define requirements for extensions to = existing protocols or new protocols that address gaps that are = identified. >>>>>>>>=20 >>>>>>>> Protocol work may be carried out in this working group or in = other working groups responsible for the protocols, in coordination with = this WG, and in agreement with the WG chairs and responsible ADs. = However, no protocol work will be adopted by a working group to address = the ERD use-cases until the requirements document motivating the = protocol work has been sent to the IESG for publication as an RFC. >>>>>>>>=20 >>>>>>>> --- >>>>>>>>=20 >>>>>>>> >>>>>>>>=20 >>>>>>>> /hannes >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>>>>=20 >>>>>>>>> Folks, >>>>>>>>>=20 >>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have >>>>>>>>> not seen a charter proposal, if there is one please point me = to it. >>>>>>>>>=20 >>>>>>>>> It seems a bit odd to put the cart (what the wg should do) >>>>>>>>> before the horse (wg name). If we drill down the the charter >>>>>>>>> first the wg name might be easier to figure out. >>>>>>>>>=20 >>>>>>>>> /Loa >>>>>>>>>=20 >>>>>>>>> PS >>>>>>>>> OK I understand that the horse and cart analogy limps a bit = :). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>>>>> " If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ..." >>>>>>>>>>=20 >>>>>>>>>> That's why I suggested SRV2. We are revisiting source routing = with new concepts. More generic number/action behavior. >>>>>>>>>>=20 >>>>>>>>>> Peter >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: status-bounces@ietf.org = [mailto:status-bounces@ietf.org] >>>>>>>>>> On Behalf Of stephane.litkowski@orange.com >>>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>>>>> To: AshwoodsmithPeter >>>>>>>>>> Cc: status@ietf.org >>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next = steps >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> There was a misunderstanding in my small comment :) so I will = explain more : >>>>>>>>>>=20 >>>>>>>>>> In segment routing, you have more than basic source routing : = segment routing is just associate a segment number to an action and then = combine segment as you want, yes you can do source routing, but you also = can do more. >>>>>>>>>>=20 >>>>>>>>>> In the other hand, I completely agree with your statement = that >>>>>>>>>> source routing is generic and dataplane agnostic, as segment = routing is ... >>>>>>>>>> (segment routing is not a new dataplane ...) >>>>>>>>>>=20 >>>>>>>>>> Now the definition of the WG naming must be inline with the >>>>>>>>>> charter that will be defined ... (draft today) >>>>>>>>>>=20 >>>>>>>>>> Based on the already existing consensus (at least for MPLS = dataplane) brought up during Berlin STATUS BOF meeting, segment routing = sounds to be a good target candidate. >>>>>>>>>>=20 >>>>>>>>>> So now, do we want to do more in the WG charter than just = make progressing segment routing architecture and uses cases document = and ensure coordination for the standardization of this technology ? >>>>>>>>>>=20 >>>>>>>>>> Do we want to standardize other technologies in this WG ? I = don't think so, based on Stewart's conclusion email from the BOF :"A new = WG focused solely on SR therefore needs to be create" >>>>>>>>>>=20 >>>>>>>>>> If the WG charter is limited to source routing, how will we = handle the "non source routing" use cases of segment routing ? In = another working group ? So we will go back to the WG synchronization = issue that has been raised for this technology ... >>>>>>>>>>=20 >>>>>>>>>> If the WG is focused on SR, let's use a name in relation with = SR. >>>>>>>>>>=20 >>>>>>>>>> Feedback ? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Stephane >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI = Stephane >>>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant = (stbryant) Objet : Re: >>>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>>>=20 >>>>>>>>>> The term "source routing" has been around for a very long = time and is data path agnostic. Its also the term used in the literature = etc so my preference is to stick with this existing well known and data = path agnostic term. >>>>>>>>>>=20 >>>>>>>>>> Peter >>>>>>>>>>=20 >>>>>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" = wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> "Source routing" is just a subcase of segment routing ... as = it is for IP routing ... >>>>>>>>>>>=20 >>>>>>>>>>> Stephane >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Message d'origine----- >>>>>>>>>>> De : status-bounces@ietf.org = [mailto:status-bounces@ietf.org] >>>>>>>>>>> De la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 = 15:02 =C0 : >>>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione = (robmgl); John G. >>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; >>>>>>>>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> What is this 'segment routing' silliness? The correct term = is 'source routing'. >>>>>>>>>>>=20 >>>>>>>>>>> Yours Irrespectively, >>>>>>>>>>>=20 >>>>>>>>>>> John >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: status-bounces@ietf.org >>>>>>>>>>>> [mailto:status-bounces@ietf.org] On Behalf Of Mark Townsley >>>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>>>>> To: Victor Kuarsingh >>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian >>>>>>>>>>>> Farrel; Alvaro Retana (aretana); status@ietf.org; Stewart >>>>>>>>>>>> Bryant >>>>>>>>>>>> (stbryant) >>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next >>>>>>>>>>>> steps >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> All, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I note this since attempting to come up with an all >>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing >>>>>>>>>>>>> is generic enough to associate to multiple functions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do >>>>>>>>>>>> not have to have acronyms, but they do need to have an >>>>>>>>>>>> 8-char limited short name for the various automated tools = not to break. >>>>>>>>>>>>=20 >>>>>>>>>>>> - Mark >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Victor K >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Roberta >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The second task, which hopefully should be relatively >>>>>>>>>>>>>>>> easy, is to find a better working name for the WG, = since >>>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is >>>>>>>>>>>>>>>> going to be confusing in text and a difficult search = term. >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> status mailing list >>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>> = _____________________________________________________________ >>>>>>>>>>> ____ _ _ _ __ >>>>>>>>>>> ___________________________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans >>>>>>>>>>> autorisation. Si vous avez recu ce message par erreur, = veuillez le signaler a l'expediteur et le detruire ainsi que les pieces = jointes. Les messages electroniques etant susceptibles d'alteration, = Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>>>>>>>>>>=20 >>>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>>>>> Thank you. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>> = ______________________________________________________________ >>>>>>>>>> ____ _ _ _ >>>>>>>>>> ____________________________________________________ >>>>>>>>>>=20 >>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>>> donc pas etre diffuses, exploites ou copies sans = autorisation. >>>>>>>>>> Si vous avez recu ce message par erreur, veuillez le signaler = a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>>=20 >>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>>>> Thank you. >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Loa Andersson email: = loa@mail01.huawei.com >>>>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>=20 >>>>>>>> = ________________________________________________________________ >>>>>>>> ____ _ _ ___________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si >>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a = l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they = should not be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages = that have been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> = _________________________________________________________________ >>>>>>> ____ _ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si = vous >>>>>>> avez recu ce message par erreur, veuillez le signaler a = l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> status mailing list >>>>>>> status@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>=20 >>>>>>=20 >>>>>> = __________________________________________________________________ >>>>>> ____ ___________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des = informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez = recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the = sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ___________________________________________________________________ >>>>> ______________________________________________________ >>>>>=20 >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le = detruire ainsi que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>=20 >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>> Thank you. >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 From xuxiaohu@huawei.com Wed Sep 11 18:28:16 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFEF21F9A40 for ; Wed, 11 Sep 2013 18:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceJJMtN0gGwZ for ; Wed, 11 Sep 2013 18:28:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9800E21F99D0 for ; Wed, 11 Sep 2013 18:28:08 -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.5-GA FastPath queued) with ESMTP id AXF75273; Thu, 12 Sep 2013 01:28:05 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 02:27:53 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 02:28:04 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Thu, 12 Sep 2013 09:27:58 +0800 From: Xuxiaohu To: "Stefano Previdi (sprevidi)" Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgbVbHaZSD4n1kCavdRcQiSghJm+P0GAgAAPW4CAAF0rAIABGKhQgAAPTYCAAXw9kA== Date: Thu, 12 Sep 2013 01:27:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@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.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stephane Litkowski , Rob Shakir , "status@ietf.org" , Hannes Gredler Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 01:28:17 -0000 SGkgU3RlZmFubywNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogc3Rh dHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9yZ10g5Luj 6KGoDQo+IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpDQo+IOWPkemAgeaXtumXtDogMjAxM+W5 tDnmnIgxMeaXpSAxODozOA0KPiDmlLbku7bkuro6IFh1eGlhb2h1DQo+IOaKhOmAgTogU3RlcGhh bmUgTGl0a293c2tpOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5vcmc7IEhhbm5lcyBHcmVkbGVy DQo+IOS4u+mimDogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9wb3NhbHMgZnJvbSBIYW5u ZXMgYW5kIFN0ZWZhbm8gOiB0cnkgdG8NCj4gbWVyZ2UgLi4uDQo+IA0KPiBIaSBYaWFvaHUsDQo+ IA0KPiBPbiBTZXAgMTEsIDIwMTMsIGF0IDQ6MTQgQU0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+DQo+ ID4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPj4g5Y+R5Lu25Lq6OiBzdGF0dXMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYub3JnXSDku6PooagNCj4gPj4g U3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4gPj4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0Oeac iDEx5pelIDA6NTgNCj4gPj4g5pS25Lu25Lq6OiBTdGVwaGFuZSBMaXRrb3dza2kNCj4gPj4g5oqE 6YCBOiBIYW5uZXMgR3JlZGxlcjsgUm9iIFNoYWtpcjsgc3RhdHVzQGlldGYub3JnDQo+ID4+IOS4 u+mimDogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9wb3NhbHMgZnJvbSBIYW5uZXMgYW5k IFN0ZWZhbm8gOiB0cnkgdG8NCj4gPj4gbWVyZ2UgLi4uDQo+ID4+DQo+ID4+DQo+ID4+IE9uIFNl cCAxMCwgMjAxMywgYXQgMToyNSBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiB3 cm90ZToNCj4gPj4NCj4gPj4+IEFncmVlIG9uIGFsbCBwcm9wb3NhbCBleGNlcHQgOg0KPiA+Pj4N Cj4gPj4+ICJbU1BdIFRoZSBhcmNoaXRlY3R1cmUgd2lsbCBzdXBwb3J0IHR1bm5lbCBhbmQgbm9u LXR1bm5lbCBwYXJhZGlnbXMNCj4gPj4+ICAgIFRoZSBhcmNoaXRlY3R1cmUgd2lsbCBzdXBwb3J0 IG11bHRpcGxlIGRhdGFwbGFuZXM6IE1QTFMgYW5kIFY2Ig0KPiA+Pj4NCj4gPj4+IEkgZG9uJ3Qg c2VlIHRoZSByZWFzb24gZm9yIHRoaXMgLi4uIElNSE8sIHRoZSBnYXAgYW5hbHlzaXMgYW5kIHJl cXVpcmVtZW50cw0KPiA+PiBpbnZlbnRvcnkgd2lsbCByZXN1bHQgb24gc2F5aW5nIG9yIG5vdA0K PiA+Pg0KPiA+Pg0KPiA+PiBbU1BdIFdoaWxlIEkgdW5kZXJzdGFuZCB3aGF0IGJyb3VnaHQgdGhl IGZvbGxvd2luZyBzdGF0ZW1lbnRzDQo+ID4+ICAgICBpbiB0aGUgcHJvcG9zZWQgY2hhcnRlcjoN Cj4gPj4gCSJIYXZpbmcgaWRlbnRpZmllZCB1c2UtY2FzZXMsIGFyY2hpdGVjdHVyZSBhbmQgc2Vj dXJpdHksDQo+ID4+IAkgdGhlIFdHIHdpbGwgaWRlbnRpZnkgZ2FwcyBiZXR3ZWVuIGN1cnJlbnRs eSBhdmFpbGFibGUNCj4gPj4gCSB0ZWNobm9sb2dpZXMgYW5kIHVzZS1jYXNlIHJlcXVpcmVtZW50 cy4NCj4gPj4gCSBUaGUgV0cgd2lsbCB0aGVuIGRlZmluZSByZXF1aXJlbWVudHMgZm9yIGV4dGVu c2lvbnMgdG8NCj4gPj4gCSBleGlzdGluZyBwcm90b2NvbHMgb3IgbmV3IHByb3RvY29scyB0aGF0 IGFkZHJlc3MgZ2Fwcw0KPiA+PiAJIHRoYXQgYXJlIGlkZW50aWZpZWQuIg0KPiA+Pg0KPiA+PiAg ICAgSSdkIGxpa2UgdG8gcG9pbnQgb3V0IHdpdGggYmV0dGVyIHByZWNpc2lvbiB3aGF0IGFyZSB0 aGUNCj4gPj4gICAgIGRpcmVjdGlvbnMgd2UgYXJlIEFMUkVBRFkgZW5nYWdlZCBpbnRvOiBkYXRh cGxhbmVzIGFuZA0KPiA+PiAgICAgcGFyYWRpZ21zLiBBcyBJIG1lbnRpb25lZCBpbiBteSBjaGFy dGVyIHByb3Bvc2FsLCB3ZSBkbyBoYXZlDQo+ID4+ICAgICBpbXBsZW1lbnRhdGlvbnMgYW5kIG11 bHRpLXZlbmRvciBpbnRlcm9wZXJhYmlsaXR5IHRlc3RzIHdpbGwNCj4gPj4gICAgIGhhcHBlbiBz b29uLiBTbywgSSBqdXN0IHdhbnQgdG8gYmUgc3VyZSB3ZSBkb24ndCBpZ25vcmUgdGhpcw0KPiA+ PiAgICAgcmVhbGl0eS4NCj4gPj4NCj4gPj4gICAgIE1QTFMgYW5kIHY2IGRhdGEtcGxhbmUgYXJl IHBhcnQgb2YgdGhpcyByZWFsaXR5LCBhcyB3ZWxsIGFzDQo+ID4+ICAgICB0dW5uZWwtYmFzZWQg YW5kIG5vbi10dW5uZWwgYmFzZWQgYXBwcm9hY2hlcy4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsg aXQncyBzdWl0YWJsZSB0byBtZW50aW9uIGRldmVsb3BpbmcgSVB2NiBzcGVjaWZpYyBTUiBtZWNo YW5pc20gaW4NCj4gdGhlIGN1cnJlbnQgY2hhcnRlciB1bmxlc3MgdGhlcmUgaXMgbm8gcmVxdWly ZW1lbnQgZm9yIGFueSBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5nDQo+IElQdjYgZGF0YSBwbGFuZS4N Cj4gDQo+ID4gQWNjb3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBxdW90ZWQgZnJv bQ0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmlscy1ydGd3Zy1zZWdt ZW50LXJvdXRpbmctMDAjcGFnZS05LCAiLi4uVGhlDQo+IHNvdXJjZSByb3V0ZSBpcyBlbmNvZGVk IGFzIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBpbnN0ZWFkIG9mIElQIGFkZHJlc3Nlcy4u LiINCj4gSWYgc28sIHdoeSBub3QgZGlyZWN0bHkgdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiBsYWJl bHMgKGkuZS4sIE1QTFMgbGFiZWwgc3RhY2spIHRvIGRvDQo+IHRoYXQgKHNlZQ0KPiBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc3RhdHVzL2N1cnJlbnQvbXNnMDAxNjUuaHRt bCk/DQo+IA0KPiANCj4gdjYgZGF0YXBsYW5lIGFsbG93cyBtb3JlIGVmZmVjdGl2ZSBzb3VyY2Ug cm91dGUgY2FwYWJpbGl0eSBieQ0KPiBsZXZlcmFnaW5nIGV4dGVuc2lvbnMgaGVhZGVycy4gSGVu Y2UgdGhlIHByb3Bvc2FsIHRoYXQgd2lsbA0KPiBjb25zaXN0IG9mIGRlZmluaW5nIGEgbmV3IEV4 dGVuc2lvbiBIZWFkZXIgZm9yIFNSIHdoZXJlIHRoZQ0KPiBzZWdtZW50IGxpc3QgaXMgZW5jb2Rl ZCBhbmQgX3ByZXNlcnZlZF8gdGhyb3VnaG91dCB0aGUgcGF0aC4NCg0KV2hhdCdzIHRoZSBwdXJw b3NlIG9mIHByZXNlcnZpbmcgdGhlIHdob2xlIHNlZ21lbnQgbGlzdCB0aHJvdWdob3V0IHRoZSBw YXRoPyBJbiBvdGhlciB3b3JkcywgaXNuJ3QgaXQgZW5vdWdoIHRvIGNvbnRhaW4gdGhlIGluZm9y bWF0aW9uIG9mIGluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyB0aHJvdWdob3V0IHRoZSBwYXRoPw0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBTbywgSSBkbyBzdHJvbmdseSBiZWxpZXZlIHdl IGhhdmUgdG8gd29yayBvbiB2NiBhbmQgc2luY2Ugd2UncmUNCj4gaW4gdGhlIGRlZmluaXRpb24g b2YgYSBjaGFydGVyIChpLmUuOiBub3QgdGhlIGRldGFpbGVkIHJldmlldw0KPiBvZiB0aGUgc29s dXRpb25zKSBJIGJlbGlldmUgdjYgc2hvdWxkIGJlIHBhcnQgb2YgaXQuDQo+IA0KPiBUaGFua3Mu DQo+IHMuDQo+IA0KPiANCj4gPg0KPiA+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCj4gPiAgIFRoZSBtYWluIGRpZmZlcmVuY2VzIGZyb20gdGhlIElQdjYgc291 cmNlIHJvdXRlIG1vZGVsIGFyZToNCj4gPg0KPiA+DQo+ID4NCj4gPiBGaWxzZmlscywgZXQgYWwu ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDMwLCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgOV0N Cj4gPg0KPiA+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU2VnbWVudCBSb3V0aW5nICAg ICAgICAgICAgICAgICAgIEp1bmUNCj4gMjAxMw0KPiA+DQo+ID4NCj4gPiAgICAgIFRoZSBzb3Vy Y2Ugcm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaW5zdGVh ZA0KPiA+ICAgICAgb2YgSVAgYWRkcmVzc2VzLg0KPiA+DQo+ID4gICAgICBBIHNlZ21lbnQgY2Fu IHJlcHJlc2VudCBhbnkgaW5zdHJ1Y3Rpb24gZWl0aGVyIGEgc2VydmljZSBvciBhDQo+ID4gICAg ICB0b3BvbG9naWNhbCBwYXRoLiAgVG9wb2xvZ2ljYWxseSwgdGhlIHBhdGggdG8gYW4gSVAgYWRk cmVzcyBpcw0KPiA+ICAgICAgb2Z0ZW4gbGltaXRlZCB0byB0aGUgc2hvcnRlc3QtcGF0aCB0byB0 aGF0IGFkZHJlc3MuICBBIHNlZ21lbnQgY2FuDQo+ID4gICAgICByZXByZXNlbnQgYW55IHBhdGgg KGUuZy4gYW4gYWRqYWNlbmN5IHNlZ21lbnQgZm9yY2VzIGEgcGFja2V0IHRvIGENCj4gPiAgICAg IG5leHRob3AgdGhyb3VnaCBhIHNwZWNpZmljIGFkamFjZW5jeSBldmVuIGlmIHRoZSBzaG9ydGVz dC1wYXRoIHRvDQo+ID4gICAgICB0aGUgbmV4dC1ob3AgZG9lcyBub3QgdXNlIHRoYXQgYWRqYWNl bmN5KS4NCj4gPg0KPiA+ICAgICAgVGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBlZ2RlIHJvdXRlcnMg YXJlIGlkZW50aWZpZWQgYW5kIGFsd2F5cw0KPiA+ICAgICAgYXZhaWxhYmxlLCBhbGxvd2luZyBm b3IgaW50ZXJlc3RpbmcgYWNjb3VudGluZyBhbmQgcG9saWN5DQo+ID4gICAgICBhcHBsaWNhdGlv bnMuDQo+ID4NCj4gPiAgICAgIFRoZSBzb3VyY2Ugcm91dGUgZnVuY3Rpb25hbGl0eSBjYW5ub3Qg YmUgY29udHJvbGxlZCBmcm9tIG91dHNpZGUNCj4gPiAgICAgIHRoZSBTUiBkb21haW4uDQo+ID4g KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+DQo+ID4gQmVz dCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+IHN0YXR1 c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1 cw0K From sprevidi@cisco.com Thu Sep 12 05:43:52 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1919A21E81EA for ; Thu, 12 Sep 2013 05:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgWsdMpBGCS8 for ; Thu, 12 Sep 2013 05:43:47 -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 1A17321E80CC for ; Thu, 12 Sep 2013 05:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7250; q=dns/txt; s=iport; t=1378989827; x=1380199427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L/VsCbPaKg4Wil67B4nRV8G+WsfippZCGx3s5p4B+Pg=; b=EbUaK4RZ4s/HlarfP0KDecZHV6H2v78ZtT7MMUWpgWxWFf+TzIBEv1/2 /Yhrb6DikmXt0ayxxb3l6SX9aBYx+3qVEw7VsgEpEwqR61wcMK5lcjLHH FN51BW6nb/7kGKOePmG1nryJu1L1+k37mBAa2vrD8rTvPoVdjEIfsvknV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPK1MVKtJXG+/2dsb2JhbABRCoMHOFKDKr04F4EEFnSCJQEBAQMBAQEBIBE6CxACAQYCEgYCAgYdAwICAiULFAECDgIEDgUIARKHYQYMji6bU5IKgSmMfwQGgQYCMQeCaTSBAAOZKJBEgyKBaAkXIg X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258827122" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 12 Sep 2013 12:43:46 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8CChkmX013472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 12:43:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 07:43:45 -0500 From: "Stefano Previdi (sprevidi)" To: Xuxiaohu Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAP//uVuAgACzLACAAJtuAIAAjIYAgAD4wACAALzSgA== Date: Thu, 12 Sep 2013 12:43:45 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.200.199] Content-Type: text/plain; charset="utf-8" Content-ID: <71F96AC2F6AA16478299625727D8B36C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Stephane Litkowski , Rob Shakir , "status@ietf.org" , Hannes Gredler Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 12:43:52 -0000 SGkgWGlhb2h1LA0KDQpPbiBTZXAgMTIsIDIwMTMsIGF0IDM6MjcgQU0sIFh1eGlhb2h1IHdyb3Rl Og0KPiBIaSBTdGVmYW5vLA0KPiANCj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+IOWPkeS7 tuS6ujogc3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoDQo+PiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPj4g5Y+R6YCB5pe2 6Ze0OiAyMDEz5bm0OeaciDEx5pelIDE4OjM4DQo+PiDmlLbku7bkuro6IFh1eGlhb2h1DQo+PiDm ioTpgIE6IFN0ZXBoYW5lIExpdGtvd3NraTsgUm9iIFNoYWtpcjsgc3RhdHVzQGlldGYub3JnOyBI YW5uZXMgR3JlZGxlcg0KPj4g5Li76aKYOiBSZTogW1N0YXR1c10gR29vZCBjaGFydGVyIHByb3Bv c2FscyBmcm9tIEhhbm5lcyBhbmQgU3RlZmFubyA6IHRyeSB0bw0KPj4gbWVyZ2UgLi4uDQo+PiAN Cj4+IEhpIFhpYW9odSwNCj4+IA0KPj4gT24gU2VwIDExLCAyMDEzLCBhdCA0OjE0IEFNLCBYdXhp YW9odSB3cm90ZToNCj4+PiANCj4+Pj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4+PiDlj5Hk u7bkuro6IHN0YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0 Zi5vcmddIOS7o+ihqA0KPj4+PiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPj4+PiDlj5Hp gIHml7bpl7Q6IDIwMTPlubQ55pyIMTHml6UgMDo1OA0KPj4+PiDmlLbku7bkuro6IFN0ZXBoYW5l IExpdGtvd3NraQ0KPj4+PiDmioTpgIE6IEhhbm5lcyBHcmVkbGVyOyBSb2IgU2hha2lyOyBzdGF0 dXNAaWV0Zi5vcmcNCj4+Pj4g5Li76aKYOiBSZTogW1N0YXR1c10gR29vZCBjaGFydGVyIHByb3Bv c2FscyBmcm9tIEhhbm5lcyBhbmQgU3RlZmFubyA6IHRyeSB0bw0KPj4+PiBtZXJnZSAuLi4NCj4+ Pj4gDQo+Pj4+IA0KPj4+PiBPbiBTZXAgMTAsIDIwMTMsIGF0IDE6MjUgUE0sIDxzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gQWdyZWUgb24gYWxsIHBy b3Bvc2FsIGV4Y2VwdCA6DQo+Pj4+PiANCj4+Pj4+ICJbU1BdIFRoZSBhcmNoaXRlY3R1cmUgd2ls bCBzdXBwb3J0IHR1bm5lbCBhbmQgbm9uLXR1bm5lbCBwYXJhZGlnbXMNCj4+Pj4+ICAgVGhlIGFy Y2hpdGVjdHVyZSB3aWxsIHN1cHBvcnQgbXVsdGlwbGUgZGF0YXBsYW5lczogTVBMUyBhbmQgVjYi DQo+Pj4+PiANCj4+Pj4+IEkgZG9uJ3Qgc2VlIHRoZSByZWFzb24gZm9yIHRoaXMgLi4uIElNSE8s IHRoZSBnYXAgYW5hbHlzaXMgYW5kIHJlcXVpcmVtZW50cw0KPj4+PiBpbnZlbnRvcnkgd2lsbCBy ZXN1bHQgb24gc2F5aW5nIG9yIG5vdA0KPj4+PiANCj4+Pj4gDQo+Pj4+IFtTUF0gV2hpbGUgSSB1 bmRlcnN0YW5kIHdoYXQgYnJvdWdodCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMNCj4+Pj4gICAg aW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXI6DQo+Pj4+IAkiSGF2aW5nIGlkZW50aWZpZWQgdXNlLWNh c2VzLCBhcmNoaXRlY3R1cmUgYW5kIHNlY3VyaXR5LA0KPj4+PiAJIHRoZSBXRyB3aWxsIGlkZW50 aWZ5IGdhcHMgYmV0d2VlbiBjdXJyZW50bHkgYXZhaWxhYmxlDQo+Pj4+IAkgdGVjaG5vbG9naWVz IGFuZCB1c2UtY2FzZSByZXF1aXJlbWVudHMuDQo+Pj4+IAkgVGhlIFdHIHdpbGwgdGhlbiBkZWZp bmUgcmVxdWlyZW1lbnRzIGZvciBleHRlbnNpb25zIHRvDQo+Pj4+IAkgZXhpc3RpbmcgcHJvdG9j b2xzIG9yIG5ldyBwcm90b2NvbHMgdGhhdCBhZGRyZXNzIGdhcHMNCj4+Pj4gCSB0aGF0IGFyZSBp ZGVudGlmaWVkLiINCj4+Pj4gDQo+Pj4+ICAgIEknZCBsaWtlIHRvIHBvaW50IG91dCB3aXRoIGJl dHRlciBwcmVjaXNpb24gd2hhdCBhcmUgdGhlDQo+Pj4+ICAgIGRpcmVjdGlvbnMgd2UgYXJlIEFM UkVBRFkgZW5nYWdlZCBpbnRvOiBkYXRhcGxhbmVzIGFuZA0KPj4+PiAgICBwYXJhZGlnbXMuIEFz IEkgbWVudGlvbmVkIGluIG15IGNoYXJ0ZXIgcHJvcG9zYWwsIHdlIGRvIGhhdmUNCj4+Pj4gICAg aW1wbGVtZW50YXRpb25zIGFuZCBtdWx0aS12ZW5kb3IgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cyB3 aWxsDQo+Pj4+ICAgIGhhcHBlbiBzb29uLiBTbywgSSBqdXN0IHdhbnQgdG8gYmUgc3VyZSB3ZSBk b24ndCBpZ25vcmUgdGhpcw0KPj4+PiAgICByZWFsaXR5Lg0KPj4+PiANCj4+Pj4gICAgTVBMUyBh bmQgdjYgZGF0YS1wbGFuZSBhcmUgcGFydCBvZiB0aGlzIHJlYWxpdHksIGFzIHdlbGwgYXMNCj4+ Pj4gICAgdHVubmVsLWJhc2VkIGFuZCBub24tdHVubmVsIGJhc2VkIGFwcHJvYWNoZXMuDQo+Pj4g DQo+Pj4gSSBkb24ndCB0aGluayBpdCdzIHN1aXRhYmxlIHRvIG1lbnRpb24gZGV2ZWxvcGluZyBJ UHY2IHNwZWNpZmljIFNSIG1lY2hhbmlzbSBpbg0KPj4gdGhlIGN1cnJlbnQgY2hhcnRlciB1bmxl c3MgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFueSBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5n DQo+PiBJUHY2IGRhdGEgcGxhbmUuDQo+PiANCj4+PiBBY2NvcmRpbmcgdG8gdGhlIGZvbGxvd2lu ZyBzdGF0ZW1lbnRzIHF1b3RlZCBmcm9tDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1maWxzZmlscy1ydGd3Zy1zZWdtZW50LXJvdXRpbmctMDAjcGFnZS05LCAiLi4uVGhlDQo+ PiBzb3VyY2Ugcm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMg aW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMuLi4iDQo+PiBJZiBzbywgd2h5IG5vdCBkaXJlY3RseSB1 c2UgYW4gb3JkZXJlZCBsaXN0IG9mIGxhYmVscyAoaS5lLiwgTVBMUyBsYWJlbCBzdGFjaykgdG8g ZG8NCj4+IHRoYXQgKHNlZQ0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3N0YXR1cy9jdXJyZW50L21zZzAwMTY1Lmh0bWwpPw0KPj4gDQo+PiANCj4+IHY2IGRhdGFwbGFu ZSBhbGxvd3MgbW9yZSBlZmZlY3RpdmUgc291cmNlIHJvdXRlIGNhcGFiaWxpdHkgYnkNCj4+IGxl dmVyYWdpbmcgZXh0ZW5zaW9ucyBoZWFkZXJzLiBIZW5jZSB0aGUgcHJvcG9zYWwgdGhhdCB3aWxs DQo+PiBjb25zaXN0IG9mIGRlZmluaW5nIGEgbmV3IEV4dGVuc2lvbiBIZWFkZXIgZm9yIFNSIHdo ZXJlIHRoZQ0KPj4gc2VnbWVudCBsaXN0IGlzIGVuY29kZWQgYW5kIF9wcmVzZXJ2ZWRfIHRocm91 Z2hvdXQgdGhlIHBhdGguDQo+IA0KPiBXaGF0J3MgdGhlIHB1cnBvc2Ugb2YgcHJlc2VydmluZyB0 aGUgd2hvbGUgc2VnbWVudCBsaXN0IHRocm91Z2hvdXQgdGhlIHBhdGg/IEluIG90aGVyIHdvcmRz LCBpc24ndCBpdCBlbm91Z2ggdG8gY29udGFpbiB0aGUgaW5mb3JtYXRpb24gb2YgaW5ncmVzcyBh bmQgZWdyZXNzIG5vZGVzIHRocm91Z2hvdXQgdGhlIHBhdGg/DQoNCg0KdGhlcmUgYXJlIHVzZSBj YXNlcywgYW1vbmcgd2hpY2ggT0FNLCB0aGF0IHdpbGwgbGV2ZXJhZ2UgdGhlIA0KYXZhaWxhYmls aXR5IG9mIHRoZSBzZWdtZW50IGxpc3QuIHY2IGhhcyBnb29kIG5hdGl2ZSBwcm9wZXJ0aWVzIA0K dGhhdCBhbGxvdyB0byBpbnNlcnQgZXhwbGljaXQvc291cmNlIHJvdXRpbmcgcGFyYWRpZ21zIGlu IHRoZSANCmZvcndhcmRpbmcgcGxhbmUuIE1vc3Qgb2YgU1cvSFcgaW1wbGVtZW50YXRpb25zIHRv ZGF5IGNhbiBoYW5kbGUgDQp0aGlzIHdpdGhvdXQgaW5jdXJyaW5nIEhXIHBlcmZvcm1hbmNlIHBl bmFsdHkuDQoNClRoYW5rcy4NCnMuDQoNCg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUN Cj4gDQo+PiBTbywgSSBkbyBzdHJvbmdseSBiZWxpZXZlIHdlIGhhdmUgdG8gd29yayBvbiB2NiBh bmQgc2luY2Ugd2UncmUNCj4+IGluIHRoZSBkZWZpbml0aW9uIG9mIGEgY2hhcnRlciAoaS5lLjog bm90IHRoZSBkZXRhaWxlZCByZXZpZXcNCj4+IG9mIHRoZSBzb2x1dGlvbnMpIEkgYmVsaWV2ZSB2 NiBzaG91bGQgYmUgcGFydCBvZiBpdC4NCj4+IA0KPj4gVGhhbmtzLg0KPj4gcy4NCj4+IA0KPj4g DQo+Pj4gDQo+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K Pj4+ICBUaGUgbWFpbiBkaWZmZXJlbmNlcyBmcm9tIHRoZSBJUHY2IHNvdXJjZSByb3V0ZSBtb2Rl bCBhcmU6DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRmlsc2ZpbHMsIGV0IGFsLiAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDldDQo+Pj4gDQo+Pj4g SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBTZWdtZW50IFJvdXRpbmcgICAgICAgICAgICAg ICAgICAgSnVuZQ0KPj4gMjAxMw0KPj4+IA0KPj4+IA0KPj4+ICAgICBUaGUgc291cmNlIHJvdXRl IGlzIGVuY29kZWQgYXMgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGluc3RlYWQNCj4+PiAg ICAgb2YgSVAgYWRkcmVzc2VzLg0KPj4+IA0KPj4+ICAgICBBIHNlZ21lbnQgY2FuIHJlcHJlc2Vu dCBhbnkgaW5zdHJ1Y3Rpb24gZWl0aGVyIGEgc2VydmljZSBvciBhDQo+Pj4gICAgIHRvcG9sb2dp Y2FsIHBhdGguICBUb3BvbG9naWNhbGx5LCB0aGUgcGF0aCB0byBhbiBJUCBhZGRyZXNzIGlzDQo+ Pj4gICAgIG9mdGVuIGxpbWl0ZWQgdG8gdGhlIHNob3J0ZXN0LXBhdGggdG8gdGhhdCBhZGRyZXNz LiAgQSBzZWdtZW50IGNhbg0KPj4+ICAgICByZXByZXNlbnQgYW55IHBhdGggKGUuZy4gYW4gYWRq YWNlbmN5IHNlZ21lbnQgZm9yY2VzIGEgcGFja2V0IHRvIGENCj4+PiAgICAgbmV4dGhvcCB0aHJv dWdoIGEgc3BlY2lmaWMgYWRqYWNlbmN5IGV2ZW4gaWYgdGhlIHNob3J0ZXN0LXBhdGggdG8NCj4+ PiAgICAgdGhlIG5leHQtaG9wIGRvZXMgbm90IHVzZSB0aGF0IGFkamFjZW5jeSkuDQo+Pj4gDQo+ Pj4gICAgIFRoZSBpbmdyZXNzIGFuZCBlZ3Jlc3MgZWdkZSByb3V0ZXJzIGFyZSBpZGVudGlmaWVk IGFuZCBhbHdheXMNCj4+PiAgICAgYXZhaWxhYmxlLCBhbGxvd2luZyBmb3IgaW50ZXJlc3Rpbmcg YWNjb3VudGluZyBhbmQgcG9saWN5DQo+Pj4gICAgIGFwcGxpY2F0aW9ucy4NCj4+PiANCj4+PiAg ICAgVGhlIHNvdXJjZSByb3V0ZSBmdW5jdGlvbmFsaXR5IGNhbm5vdCBiZSBjb250cm9sbGVkIGZy b20gb3V0c2lkZQ0KPj4+ICAgICB0aGUgU1IgZG9tYWluLg0KPj4+ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4g WGlhb2h1DQo+Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+PiBzdGF0dXNAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RhdHVzDQoNCg== From sprevidi@cisco.com Thu Sep 12 05:53:31 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A6911E8166 for ; Thu, 12 Sep 2013 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.02 X-Spam-Level: X-Spam-Status: No, score=-107.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_INTEREST=3.579, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vzu71WUtD8u for ; Thu, 12 Sep 2013 05:53:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0F11E8113 for ; Thu, 12 Sep 2013 05:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50440; q=dns/txt; s=iport; t=1378990395; x=1380199995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cfrJuK4d6SQhwDsnxfyHLhUrddHU7ADbGvOgCzioirM=; b=BZUxEEB1q56SbwxV23G0f8aWHUgYYLOdhf4qSrw7yEQ+XFWu7/0rCfoC 7GsNMIMKklhWPP+67nxdVnBbc4nHumo/uT3EPMdUY8f3tn4DH47g/SeMM kOC0Dn8VfDrByDqcS/o7qjlwHwToByI0SYrshhz0WTU7JFc8ItYVm3uGJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFe4MVKtJV2b/2dsb2JhbABRCoMHOFLAYoEcFnSCJQEBAQMBAQEBFwFMBAMEBwUHAgICAQgRAQMBAQEKHQcbDAsUAwYIAgQOBQgMB4dhBgyuIo1kBASOHgYEAQWBBgIGJgUHAgSDF4EAA4h/oG2DIoFoAQgXIg X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258801793" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 12 Sep 2013 12:53:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8CCrD0R025004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 12:53:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 07:53:12 -0500 From: "Stefano Previdi (sprevidi)" To: "John G. Scudder" Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrx1KGHFth8pYsUKuWKfNINLAs5nCY6yA Date: Thu, 12 Sep 2013 12:53:12 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <10969_1378893213_52303D9D_10969_5864_1_EEE55384044474429A926C625D0FCC810964DECA2B@PUEXCB2F.nanterre.francetelecom.fr> <474760C9-0057-46A7-A744-6EF45BAF349B@juniper.net> In-Reply-To: <474760C9-0057-46A7-A744-6EF45BAF349B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.200.199] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <52F5B8F604037E4795A91B0899D56AD4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Rob Shakir , "status@ietf.org" , Hannes Gredler Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 12:53:32 -0000 Hi John, On Sep 11, 2013, at 8:32 PM, John G. Scudder wrote: > Stephane, >=20 > This seems like a very reasonable way forward to me and I think the last = draft charter you posted is "about right". I have some concerns. At least, Id' like to see IPv6 explicitly mentioned.=20 s. > In particular I want to support the idea that "the use case analysis ... = will give us what we need to address exactly".=20 >=20 > --John >=20 > On Sep 11, 2013, at 5:53 AM, stephane.litkowski@orange.com wrote: >=20 >> Hannes, >>=20 >> Regarding "Service chaining", I would agree to not mention it directly i= n the charter (it's not mentionned explictly in my last proposal) BUT I don= 't want to close the door to other "action types" than forwarding. That's w= hy using the wording "node" , "steering packets" seems to be good because i= t's large enough to address use cases that are not detailled today (for exa= mple service chaining). >>=20 >> So my approach would be , keep it large in definition using the proposed= wording and then the use case analysis (in the work items) will give us wh= at we need to address exactly. >>=20 >> Does it make sense for you to use this way ? >>=20 >>=20 >> Thanks, >>=20 >> Stephane >>=20 >>=20 >>=20 >> -----Message d'origine----- >> De : Hannes Gredler [mailto:hannes@juniper.net] >> Envoy=E9 : mercredi 11 septembre 2013 08:15 >> =C0 : Stefano Previdi >> Cc : LITKOWSKI Stephane DTF/DERX; Rob Shakir; status@ietf.org >> Objet : Re: [Status] Good charter proposals from Hannes and Stefano : tr= y to merge ... >>=20 >> stefano, >>=20 >> On Sep 10, 2013, at 7:34 PM, Stefano Previdi (sprevidi) wrote: >>=20 >>> Hannes, >>>=20 >>> On Sep 10, 2013, at 7:27 PM, Hannes Gredler wrote: >>>> stefano, >>>>=20 >>>> On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: >>>>=20 >>>>>=20 >>>>> On Sep 10, 2013, at 1:25 PM, wrote: >>>>>=20 >>>>>> Agree on all proposal except : >>>>>>=20 >>>>>> "[SP] The architecture will support tunnel and non-tunnel paradigms >>>>>> The architecture will support multiple dataplanes: MPLS and V6" >>>>>>=20 >>>>>> I don't see the reason for this ... IMHO, the gap analysis and >>>>>> requirements inventory will result on saying or not >>>>>=20 >>>>>=20 >>>>> [SP] While I understand what brought the following statements >>>>> in the proposed charter: >>>>> "Having identified use-cases, architecture and security, >>>>> the WG will identify gaps between currently available >>>>> technologies and use-case requirements. >>>>> The WG will then define requirements for extensions to >>>>> existing protocols or new protocols that address gaps >>>>> that are identified." >>>>>=20 >>>>> I'd like to point out with better precision what are the >>>>> directions we are ALREADY engaged into: dataplanes and >>>>> paradigms. As I mentioned in my charter proposal, we do have >>>>> implementations and multi-vendor interoperability tests will >>>>> happen soon. So, I just want to be sure we don't ignore this >>>>> reality. >>>>=20 >>>> HG> just because you have an implementation for does not >>>> HG> constitute >>>> community interest. we are trying to build here a charter that >>>> matches what a broader community wants. if the use-case that you're co= ncerned >>>> about (service-chaining and a new internet data plane #4) are compelli= ng >>>> enough the group will work on it, but mandating that into the charter, >>>> without asking the though questions first seems a wrong start to me. >>>=20 >>>=20 >>> [SP] Sorry to contradict but it's the exact opposite. If a group >>> of vendors decide to invest in implementations is because >>> they received, analyzed, processed a set of requirements >>> coming for operators who know pretty well what they do, what >>> they want to deploy and the technology they want the vendors >>> to deliver. This fits the definition of "community interest". >>=20 >> HG> interestingly enough i haven't encountered a network operator so >> far who says 'i need SR for service chaining' nor >> we had somebody asking for this in the 'operator use case' slots >> in Berlin. - So who are they ? - can you manage such that >> they speak up and make their case ? >>=20 >>> My point is that I strongly _suggest_ IETF WG (any) not to >>> neglect these facts and not write a down a charter ... >> [ ... ] >>=20 >> HG> i'd like to have some proof point for your 'facts' prior >> to making 'service chaining' a charter item. >>=20 >>> Having said that, whoever does NOT believe in the benefit of >>> a newly proposed technology, is always free to not implement >>> it and to not deploy it. >>=20 >> HG> that is fine and well understood, but since you have a desire to >> standardize your 'newly proposed technology' you also need to play >> a bit by the rules. >>=20 >>>>>> : we must use tunnels and/or non tunnels, and the following dataplan= es ... But I don't see the reason to put solutions directly in the charter = ... >>>>>=20 >>>>>=20 >>>>> these are not solutions these are way to avoid boundaries in the >>>>> framework. >>>>>=20 >>>>> Thanks. >>>>> s. >>>>>=20 >>>>>=20 >>>>>> Could you explain your point ? >>>>>>=20 >>>>>>=20 >>>>>> updated with the other comments : >>>>>>=20 >>>>>> ------------------------------------------------------------------- >>>>>> Name: >>>>>> Charter: >>>>>>=20 >>>>>>=20 >>>>>> Introduction >>>>>> ------------ >>>>>> The following use cases: >>>>>> . Path computation based on awareness of utilization or performance >>>>>> data, within both centralized and distributed environments, . Multi-= topology (dual planes, disjoint trees), . Simplification and reduction of s= ignaling components (scaling), . Combined application and network layer pat= h specification, . Full coverage LFA-FRR, . Topology Aware OAM, . etc. >>>>>>=20 >>>>>> have triggered work on the definition of new architecture and protoc= ol extensions allowing to combine well known shortest path based routing pa= radigms with source/explicit routing methods. Some of these extensions have= been implemented already. >>>>>>=20 >>>>>>=20 >>>>>> Objective >>>>>> --------- >>>>>>=20 >>>>>> Define an architecture where a node can steer a packet through a net= work or set of networks (interdomain) on any path without requiring to main= tain state along the path, other than in the ingress node. >>>>>>=20 >>>>>> A node may be any type of device including routers or appliances. >>>>>>=20 >>>>>> In this architecture, nodes sharing a common trust model form a domain. The architecture defined by this working group will allow a = node to steer a packet between any source and destination node within the <= Name-TBD> domain (formed of one or more networks), on any path (shortest, n= on-shortest, explicit or based on other characteristics specified by segmen= t identifiers). >>>>>>=20 >>>>>> It may then send any packet that passes through it through any path >>>>>> that it has specified and that is conform to the security rules. >>>>>> Downstream nodes along the path within the domain >>>>>> forward the packet by using the informations inserted by the node >>>>>> at the head-end >>>>>>=20 >>>>>> The architecture should support centralized and distributed path com= putation. >>>>>>=20 >>>>>> The architecture should support OAM functions. >>>>>>=20 >>>>>> The architecture should allow different mechanisms through which a >>>>>> path is constructed. SR allows a variety of mechanisms, not >>>>>> confined IGP/BGP path computation. >>>>>>=20 >>>>>> As MPLS dataplane is largely deployed, the WG should avoi= d any modification in the MPLS dataplane when defining the architecture. >>>>>>=20 >>>>>>=20 >>>>>> Work items : >>>>>> ------------------ >>>>>>=20 >>>>>> The working group is chartered for the following ordered = list of work items: >>>>>>=20 >>>>>> - The first goal of the WG is to identify use-cases. >>>>>> - The WG will then define the architecture framework associated >>>>>> with the security considerations. The architecture framework and >>>>>> security considerations must address the relations between networks = forming the domain (interAS). >>>>>> - Having identified use-cases, architecture and security, the WG >>>>>> will identify gaps between currently available technologies and >>>>>> use-case requirements. >>>>>> - The WG will then define requirements for extensions to existing >>>>>> protocols or new protocols that address gaps that are identified. >>>>>> - The WG will first focus on the intra-domain forwarding definition. >>>>>>=20 >>>>>>=20 >>>>>> Documents : >>>>>> ------------------ >>>>>> . Use Cases >>>>>> . Architecture including security considerations >>>>>> - Protocol extension requirements >>>>>> . Interoperability Report >>>>>>=20 >>>>>>=20 >>>>>> Required protocol extensions are carried out in working groups respo= nsible (ISIS,OSPF,BGP,PCEP ...). Work on new protocols may be carried out b= y the WG. >>>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 >>>>>> : mardi 10 septembre 2013 12:30 =C0 : LITKOWSKI Stephane DTF/DERX; >>>>>> Rob Shakir Cc : Hannes Gredler; status@ietf.org Objet : Re: >>>>>> [Status] Good charter proposals from Hannes and Stefano : try to mer= ge ... >>>>>>=20 >>>>>> Hi Stephane, Rob, >>>>>>=20 >>>>>> one preliminary remark: I prefer to use he therm "node" rather than = "router". Use cases, such as Service Chaining requires that terminology. >>>>>>=20 >>>>>> some other comments below... >>>>>>=20 >>>>>>=20 >>>>>> On Sep 10, 2013, at 11:19 AM, wrote: >>>>>>> Souns good to me, (adding OAM also) >>>>>>>=20 >>>>>>> New recap : >>>>>>>=20 >>>>>>> ------------------------------------------------------------------ >>>>>>> - >>>>>>> Name: >>>>>>> Charter: >>>>>>>=20 >>>>>>>=20 >>>>>>> Introduction >>>>>>> ------------ >>>>>>> The following use cases: >>>>>>> . Path computation based on awareness of utilization or >>>>>>> performance data, within both centralized and distributed environme= nts, . Multi-topology (dual planes, disjoint trees), . Simplification and r= eduction of signaling components (scaling), . Combined application and netw= ork layer path specification, . Full coverage LFA-FRR, . Topology Aware OAM= , . etc. >>>>>>>=20 >>>>>>> have triggered work on the definition of new architecture and proto= col extensions allowing to combine well known shortest path based routing p= aradigms with source/explicit routing methods. Some of these extensions hav= e been implemented already. >>>>>>>=20 >>>>>>>=20 >>>>>>> Objective >>>>>>> --------- >>>>>>>=20 >>>>>>> Define an architecture where a node can steer a packet through a ne= twork or set of networks (interdomain) on any path. >>>>>>=20 >>>>>>=20 >>>>>> [SP] As stated above, I'm fine with the above definition but I >>>>>> assume this includes service chaining and that by "network or set >>>>>> of networks" you intend "nodes" which may include others things >>>>>> than just routers. >>>>>>=20 >>>>>> [SLI] Agree >>>>>>=20 >>>>>>=20 >>>>>>> In this architecture, routers sharing a common trust model form a <= Name-TBD> domain. The architecture defined by this working group will allow= a node to steer a packet between any source and destination node within th= e domain (formed of one or more networks), on any path (shortest= , non-shortest, explicit or based on other characteristics specified by seg= ment identifiers). >>>>>>=20 >>>>>>=20 >>>>>> [SP] without requiring to maintain state along the path, other >>>>>> than in the ingress node. >>>>>>=20 >>>>>> [SLI] Agree >>>>>>=20 >>>>>>=20 >>>>>>> It may then send any packet that passes through it through any path= that it has specified and that is conform to the security rules. Downstrea= m routers along the path within the domain forward the packet as= specified by the router at the head-end of the path. >>>>>>=20 >>>>>>>=20 >>>>>>> The architecture should support centralized and distributed path co= mputation. >>>>>>>=20 >>>>>>> The architecture should support OAM functions. >>>>>>=20 >>>>>>=20 >>>>>> [SP] The architecture should allow different mechanisms through >>>>>> which a path is constructed. SR allows a variety of mechanisms, >>>>>> not confined IGP/BGP path computation. >>>>>>=20 >>>>>> [SLI] Agree >>>>>>=20 >>>>>>> Work items : >>>>>>> ------------------ >>>>>>>=20 >>>>>>> The working group is chartered for the following ordered= list of work items: >>>>>>>=20 >>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>> - The WG will then define the architecture framework associated >>>>>>> with the security considerations. The architecture framework and >>>>>>> security considerations must address the relations between networks= forming the domain (interAS). >>>>>>> - Having identified use-cases, architecture and security, the WG >>>>>>> will identify gaps between currently available technologies and >>>>>>> use-case requirements. >>>>>>> - The WG will then define requirements for extensions to existing >>>>>>> protocols or new protocols that address gaps that are identified. >>>>>>> - The WG will first focus on the intra-domain forwarding definition= . >>>>>>=20 >>>>>>=20 >>>>>> [SP] The architecture will support tunnel and non-tunnel paradigms >>>>>> The architecture will support multiple dataplanes: MPLS and V6 >>>>>>=20 >>>>>>=20 >>>>>> Thanks. >>>>>> s. >>>>>>=20 >>>>>>=20 >>>>>>> Documents : >>>>>>> ------------------ >>>>>>> . Use Cases >>>>>>> . Architecture including security considerations >>>>>>> - Protocol extension requirements >>>>>>> . Interoperability Report >>>>>>>=20 >>>>>>>=20 >>>>>>> Protocol work may be carried out in this working group or in other = working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in c= oordination with this WG, and in agreement with the WG chairs and responsib= le ADs. >>>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : Rob Shakir [mailto:rjs@rob.sh] Envoy=E9 : mardi 10 septembre >>>>>>> 2013 11:05 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Hannes Gredler; >>>>>>> Stefano Previdi (sprevidi); status@ietf.org Objet >>>>>>> : Re: [Status] Good charter proposals from Hannes and Stefano : try= to merge ... >>>>>>>=20 >>>>>>> Hi Stephane, >>>>>>>=20 >>>>>>> Thanks for this, looks good! Comments in-line marked rjs>. >>>>>>>=20 >>>>>>> On 10 Sep 2013, at 08:50, wrote: >>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I'm creating a new mail topic because the "Summary of STATUS BOF .= .." >>>>>>>> starts to be unreadable :) >>>>>>>>=20 >>>>>>>> Hannes and Stefano send to us two charter proposals that sounds go= od to me. >>>>>>>>=20 >>>>>>>> The main difference between the two proposals is that Stefano prop= ose a segment bound to any type of instruction (forwarding, application or = service based) while Hannes is focusing on forwarding actions (which is the= first priority, and I think everybody agree on this). >>>>>>>=20 >>>>>>> rjs> Agreed -- I think it would be useful to allow definitions of s= egments to identify different types of "service", since there appear to be = some use cases (e.g., the explicit exit selection case) which require a seg= ment type describing something that is not explicitly IGP-based. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> It would be interresting to have a feedback from the mailinglist o= n this specific point. >>>>>>>>=20 >>>>>>>> IMHO, there is a strong interrest to explore the service actions b= ound to segment in a second step keeping forwarding as a priority. >>>>>>>>=20 >>>>>>>> Apart of this problem, here is a merge try of the two good proposa= ls (I'm putting '<>' on hot topics :) ) : >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ----------------------------------------------------------------- >>>>>>>> -- >>>>>>>> Name: >>>>>>>> Charter: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Introduction >>>>>>>> ------------ >>>>>>>> The following use cases: >>>>>>>> . Path computation based on awareness of utilization or >>>>>>>> performance data, within both centralized and distributed environm= ents, . Multi-topology (dual planes, disjoint trees), . Simplification and = reduction of signaling components (scaling), . Combined application and net= work layer path specification, . Full coverage LFA-FRR, . Topology Aware OA= M, . etc. >>>>>>>>=20 >>>>>>>> have triggered work on the definition of new architecture and prot= ocol extensions allowing to combine well known shortest path based routing = paradigms with source/explicit routing methods. Some of these extensions ha= ve been implemented already. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Objective >>>>>>>> --------- >>>>>>>>=20 >>>>>>>> Define an architecture where a node can steer a packet through a n= etwork or set of networks (interdomain) on any path (shortest, non shortest= , explicit, ). >>>>>>>>=20 >>>>>>>> In this architecture, routers are sharing a common trust model and= are forming a domain. >>>>>>>> Within this domain, a node can specify a path between itself and a= ny destination in the domain. . >>>>>>>=20 >>>>>>> rjs> To clarify here, we define that our domain is under a common t= rust model (essentially, under common administrative control?), but then go= on to talk about inter-domain elsewhere. Can we perhaps clarify (by defini= ng a specific " domain" nomenclature) and say something like: >>>>>>>=20 >>>>>>> "In this architecture, routers sharing a common trust model form a = domain. The architecture defined by this working group will allo= w a node to steer a packet between any source and destination node within t= he domain (formed of one or more networks), on any path (shortes= t, non-shortest, explicit or based on other characteristics specified by se= gment identifiers)." >>>>>>>=20 >>>>>>>> It may then send any packet that passes through it through any pat= h that it has specified and that is conform to the security rules. Downstre= am routers along the path within the domain forward the packet a= s specified by the router at the head-end of the path. >>>>>>>>=20 >>>>>>>> The architecture should support centralized and distributed path c= omputation. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Work items : >>>>>>>> ------------------ >>>>>>>>=20 >>>>>>>> The working group is chartered for the following ordere= d list of work items: >>>>>>>>=20 >>>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>>> - The WG will then define the architecture framework associated >>>>>>>> with the security considerations. The architecture framework and >>>>>>>> security considerations must address the relations between domains= (inter domain). >>>>>>>=20 >>>>>>> rjs> And then here "networks forming the domain"? >>>>>>>=20 >>>>>>> Thanks for the efforts, >>>>>>> r. >>>>>>>=20 >>>>>>>> - Having identified use-cases, architecture and security, the WG >>>>>>>> will identify gaps between currently available technologies and >>>>>>>> use-case requirements. >>>>>>>> - The WG will then define requirements for extensions to existing >>>>>>>> protocols or new protocols that address gaps that are identified. >>>>>>>> - The WG will first focus on the intra-domain forwarding definitio= n. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Documents : >>>>>>>> ------------------ >>>>>>>> . Use Cases >>>>>>>> . Architecture including security considerations >>>>>>>> - Protocol extension requirements . Interoperability Report >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Protocol work may be carried out in this working group or in other= working groups responsible for the protocols (ISIS,OSPF,BGP,PCEP ...), in = coordination with this WG, and in agreement with the WG chairs and responsi= ble ADs. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hope it helps to progress on the definition. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Stephane >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : Hannes Gredler [mailto:hannes@juniper.net] Envoy=E9 : vendred= i >>>>>>>> 6 septembre 2013 18:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : >>>>>>>> status@ietf.org Objet : Re: [Status] Summary of STATUS BOF and >>>>>>>> the next steps >>>>>>>>=20 >>>>>>>> hi stephane, >>>>>>>>=20 >>>>>>>> here is a revised draft charter as per your comments. >>>>>>>>=20 >>>>>>>> --- >>>>>>>>=20 >>>>>>>> domain contains a set of routers with the following >>>>>>>> characteristics: >>>>>>>>=20 >>>>>>>> - They form a connected network >>>>>>>> - They can forward traffic through any path within the network >>>>>>>> using shortest path, or any other (e.g., an explicit) path >>>>>>>> - They share a common trust model. In this model, any router >>>>>>>> within the domain can specify a path between itself and any other >>>>>>>> router in the domain. It may then send any packet that passes >>>>>>>> through it through any path that it has specified and that is >>>>>>>> conform to the security rules. Downstream routers along the path >>>>>>>> within the domain forward the packet as specified by >>>>>>>> the router at the head-end of the path. >>>>>>>>=20 >>>>>>>> The working group is chartered for the following ordere= d list of work items: >>>>>>>>=20 >>>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>>> - The WG will then define the architecture framework associated >>>>>>>> with the security considerations. The architecture framework and >>>>>>>> security considerations must address the relations between domains= (interdomain). >>>>>>>> - Having identified use-cases, architecture and security, the WG >>>>>>>> will identify gaps between currently available technologies and >>>>>>>> use-case requirements. >>>>>>>> - The WG will then define requirements for extensions to existing >>>>>>>> protocols or new protocols that address gaps that are identified. >>>>>>>> - The WG will first focus on the intra-domain forwarding definitio= n. >>>>>>>>=20 >>>>>>>> Protocol work may be carried out in this working group or in other= working groups responsible for the protocols, in coordination with this WG= , and in agreement with the WG chairs and responsible ADs. >>>>>>>> However, no protocol work will be adopted by a working group to ad= dress the identified use-cases until the requirements document motivating t= he protocol work has been sent to the IESG for publication as an RFC. >>>>>>>>=20 >>>>>>>> --- >>>>>>>>=20 >>>>>>>> /hannes >>>>>>>>=20 >>>>>>>> On Sep 4, 2013, at 10:02 AM, wrote: >>>>>>>>=20 >>>>>>>>> Hannes, >>>>>>>>>=20 >>>>>>>>> In case, we are using only directed forwarding (adjacency >>>>>>>>> segment), could we still talk about tunneling ? (it's a very very= small tunnel) Moreover talking about "stacking" is really dataplane agnost= ic (MPLS) ... >>>>>>>>>=20 >>>>>>>>> In the proposed segment routing architectural concepts, segments = are at the same "level" and pointer moves on the segment list, then the MPL= S instantiation is performing this using stacking ... >>>>>>>>>=20 >>>>>>>>> IMHO, if we use "Stacked Tunnels", we already talk about a chosen= solution and it's closing the door to something else ... >>>>>>>>>=20 >>>>>>>>> Finally, about the "routing" word, routing is essentially a "forw= ard" action which may limit the scope of what we can do by using a segment = list. Actions associated with a segment could be something else than forwar= ding. >>>>>>>>>=20 >>>>>>>>> Do we want in the charter to limit the scope to routing actions ? >>>>>>>>>=20 >>>>>>>>> I have no solution today to propose for the naming, but I complet= ely agree with Loa, to first focus on working on the charter, and define a = clear scope of the work and then the name will be easier to find. >>>>>>>>>=20 >>>>>>>>> Regarding your charter proposal : >>>>>>>>>=20 >>>>>>>>> -------- >>>>>>>>>=20 >>>>>>>>> - They form a connected network >>>>>>>>> [SLI] InterAS case must be included, but the WG can go step by st= ep and first release intraAS, and then doing interAS (in relation with IDR = ??). >>>>>>>>>=20 >>>>>>>>> - They can forward traffic through the shortest paths or paths >>>>>>>>> other than the shortest (the latter called explicitly routed path= s, or explicit paths) [SLI] There is something else between SPT and Explic= it path, you can define other algorithms than SPT to define a path, and it'= s not explicit path. Moreover I come back to my comment, on do we want to l= imit the scope to routing ? I would say no. >>>>>>>>>=20 >>>>>>>>> - They share a common trust model. In this model, any router with= in the ERD can specify an explicit path between itself and any other router= in the ERD. It can then send any packet that passes through it through any= path that it has specified. >>>>>>>>> [SLI] Security considerations may have to be addressed in the >>>>>>>>> charter , especially for the interAS case (trust yes, but not >>>>>>>>> sure access to everything may not be good) >>>>>>>>>=20 >>>>>>>>> Downstream routers within the ERD forward the packet as specified= by the router at the head-end of the path. >>>>>>>>> [SLI] Yes, but any router in the middle may be able to change the= end to end explicit path. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs= . >>>>>>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>>>>>> - The WG will then define requirements for extensions to existing= protocols or new protocols that address gaps that are identified. >>>>>>>>>=20 >>>>>>>>> [SLI] Agree, I would add : >>>>>>>>> - defining the architecture framework >>>>>>>>> - analysing the security considerisations >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --------- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Here would be my proposal to extend yours : >>>>>>>>>=20 >>>>>>>>> A domain contains a set of routers with the= following characteristics: >>>>>>>>>=20 >>>>>>>>> - They form a connected network >>>>>>>>> - They can forward traffic through any path within the network >>>>>>>>> using shortest path, non shortest path or explicit path >>>>>>>>> - They may provide other types of services than forwarding and th= ey can enforce service actions in the path. >>>>>>>>> - They share a common trust model. In this model, any router with= in the domain can specify a path between itself and any other router in the= domain. It may then send any packet that passes through it through any pat= h that it has specified and that is conform to the security rules. Downstre= am routers within the ERD forward the packet as specified by the router at = the head-end of the path. >>>>>>>>>=20 >>>>>>>>> The working group is chartered for the following ordered l= ist of work items: >>>>>>>>>=20 >>>>>>>>> - The first goal of the WG is to identify use-cases. >>>>>>>>> - The WG will then define the architecture framework associated w= ith the security considerations. The architecture framework and security co= nsiderations must address the relations between domains (interdomain). >>>>>>>>> - Having identified use-cases, architecture and security, the WG = will identify gaps between currently available technologies and use-case re= quirements. >>>>>>>>> - The WG will then define requirements for extensions to existing= protocols or new protocols that address gaps that are identified. >>>>>>>>> - The WG will first focus on the intra-domain forwarding definiti= on. >>>>>>>>>=20 >>>>>>>>> Protocol work may be carried out in this working group or in othe= r working groups responsible for the protocols, in coordination with this W= G, and in agreement with the WG chairs and responsible ADs. However, no pro= tocol work will be adopted by a working group to address the ERD use-cases = until the requirements document motivating the protocol work has been sent = to the IESG for publication as an RFC. >>>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] De >>>>>>>>> la part de Hannes Gredler Envoy=E9 : mardi 3 septembre 2013 18:31 >>>>>>>>> =C0 : Loa Andersson Cc : status@ietf.org Objet : Re: [Status] >>>>>>>>> Summary of STATUS BOF and the next steps >>>>>>>>>=20 >>>>>>>>> good point - what about this charter proposal ? >>>>>>>>>=20 >>>>>>>>> --- >>>>>>>>>=20 >>>>>>>>> Stacked Tunnels for Explicit Routing (STER) >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>>=20 >>>>>>>>> A explicit routing domain (ERD) contains a set of routers with th= e following characteristics: >>>>>>>>>=20 >>>>>>>>> - They form a connected network >>>>>>>>> - They can forward traffic through the shortest paths or paths >>>>>>>>> other than the shortest (the latter called explicitly routed >>>>>>>>> paths, or explicit paths) >>>>>>>>> - They share a common trust model. In this model, any router with= in the ERD can specify an explicit path between itself and any other router= in the ERD. It can then send any packet that passes through it through any= path that it has specified. Downstream routers within the ERD forward the = packet as specified by the router at the head-end of the path. >>>>>>>>>=20 >>>>>>>>> The STER working group is chartered for the following ordered lis= t of work items: >>>>>>>>>=20 >>>>>>>>> - The first goal of the STER WG is to identify use-cases for ERDs= . >>>>>>>>> - Having identified use-cases, the WG will identify gaps between = currently available technologies and use-case requirements. >>>>>>>>> - The WG will then define requirements for extensions to existing= protocols or new protocols that address gaps that are identified. >>>>>>>>>=20 >>>>>>>>> Protocol work may be carried out in this working group or in othe= r working groups responsible for the protocols, in coordination with this W= G, and in agreement with the WG chairs and responsible ADs. However, no pro= tocol work will be adopted by a working group to address the ERD use-cases = until the requirements document motivating the protocol work has been sent = to the IESG for publication as an RFC. >>>>>>>>>=20 >>>>>>>>> --- >>>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> /hannes >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sep 3, 2013, at 5:31 PM, Loa Andersson wrote: >>>>>>>>>=20 >>>>>>>>>> Folks, >>>>>>>>>>=20 >>>>>>>>>> Excuse me if I'm slightly out of the loop, but so far I have >>>>>>>>>> not seen a charter proposal, if there is one please point me to = it. >>>>>>>>>>=20 >>>>>>>>>> It seems a bit odd to put the cart (what the wg should do) >>>>>>>>>> before the horse (wg name). If we drill down the the charter >>>>>>>>>> first the wg name might be easier to figure out. >>>>>>>>>>=20 >>>>>>>>>> /Loa >>>>>>>>>>=20 >>>>>>>>>> PS >>>>>>>>>> OK I understand that the horse and cart analogy limps a bit :). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2013-09-03 17:22, AshwoodsmithPeter wrote: >>>>>>>>>>> " If the WG charter is limited to source routing, how will we h= andle the "non source routing" use cases of segment routing ? In another wo= rking group ? So we will go back to the WG synchronization issue that has b= een raised for this technology ..." >>>>>>>>>>>=20 >>>>>>>>>>> That's why I suggested SRV2. We are revisiting source routing w= ith new concepts. More generic number/action behavior. >>>>>>>>>>>=20 >>>>>>>>>>> Peter >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>>>>> On Behalf Of stephane.litkowski@orange.com >>>>>>>>>>> Sent: Tuesday, September 03, 2013 10:43 AM >>>>>>>>>>> To: AshwoodsmithPeter >>>>>>>>>>> Cc: status@ietf.org >>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next steps >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> There was a misunderstanding in my small comment :) so I will e= xplain more : >>>>>>>>>>>=20 >>>>>>>>>>> In segment routing, you have more than basic source routing : s= egment routing is just associate a segment number to an action and then com= bine segment as you want, yes you can do source routing, but you also can d= o more. >>>>>>>>>>>=20 >>>>>>>>>>> In the other hand, I completely agree with your statement that >>>>>>>>>>> source routing is generic and dataplane agnostic, as segment ro= uting is ... >>>>>>>>>>> (segment routing is not a new dataplane ...) >>>>>>>>>>>=20 >>>>>>>>>>> Now the definition of the WG naming must be inline with the >>>>>>>>>>> charter that will be defined ... (draft today) >>>>>>>>>>>=20 >>>>>>>>>>> Based on the already existing consensus (at least for MPLS data= plane) brought up during Berlin STATUS BOF meeting, segment routing sounds = to be a good target candidate. >>>>>>>>>>>=20 >>>>>>>>>>> So now, do we want to do more in the WG charter than just make = progressing segment routing architecture and uses cases document and ensure= coordination for the standardization of this technology ? >>>>>>>>>>>=20 >>>>>>>>>>> Do we want to standardize other technologies in this WG ? I don= 't think so, based on Stewart's conclusion email from the BOF :"A new WG fo= cused solely on SR therefore needs to be create" >>>>>>>>>>>=20 >>>>>>>>>>> If the WG charter is limited to source routing, how will we han= dle the "non source routing" use cases of segment routing ? In another work= ing group ? So we will go back to the WG synchronization issue that has bee= n raised for this technology ... >>>>>>>>>>>=20 >>>>>>>>>>> If the WG is focused on SR, let's use a name in relation with S= R. >>>>>>>>>>>=20 >>>>>>>>>>> Feedback ? >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Stephane >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Message d'origine----- >>>>>>>>>>> De : AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] >>>>>>>>>>> Envoy=E9 : mardi 3 septembre 2013 15:27 =C0 : LITKOWSKI Stephan= e >>>>>>>>>>> DTF/DERX Cc : John E Drake; Mark Townsley; Victor Kuarsingh; >>>>>>>>>>> Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; >>>>>>>>>>> Alvaro Retana (aretana); status@ietf.org; Stewart Bryant (stbry= ant) Objet : Re: >>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>>>>=20 >>>>>>>>>>> The term "source routing" has been around for a very long time = and is data path agnostic. Its also the term used in the literature etc so = my preference is to stick with this existing well known and data path agnos= tic term. >>>>>>>>>>>=20 >>>>>>>>>>> Peter >>>>>>>>>>>=20 >>>>>>>>>>> On Sep 3, 2013, at 9:07 AM, "stephane.litkowski@orange.com" wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> "Source routing" is just a subcase of segment routing ... as i= t is for IP routing ... >>>>>>>>>>>>=20 >>>>>>>>>>>> Stephane >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Message d'origine----- >>>>>>>>>>>> De : status-bounces@ietf.org [mailto:status-bounces@ietf.org] >>>>>>>>>>>> De la part de John E Drake Envoy=E9 : mardi 3 septembre 2013 1= 5:02 =C0 : >>>>>>>>>>>> Mark Townsley; Victor Kuarsingh Cc : Roberta Maglione (robmgl)= ; John G. >>>>>>>>>>>> Scudder; Alvaro Retana (aretana); Adrian Farrel; >>>>>>>>>>>> status@ietf.org; Stewart Bryant (stbryant) Objet : Re: >>>>>>>>>>>> [Status] Summary of STATUS BOF and the next steps >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> What is this 'segment routing' silliness? The correct term is= 'source routing'. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yours Irrespectively, >>>>>>>>>>>>=20 >>>>>>>>>>>> John >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: status-bounces@ietf.org >>>>>>>>>>>>> [mailto:status-bounces@ietf.org] On Behalf Of Mark Townsley >>>>>>>>>>>>> Sent: Sunday, September 01, 2013 10:08 AM >>>>>>>>>>>>> To: Victor Kuarsingh >>>>>>>>>>>>> Cc: Roberta Maglione (robmgl); John G. Scudder; Adrian >>>>>>>>>>>>> Farrel; Alvaro Retana (aretana); status@ietf.org; Stewart >>>>>>>>>>>>> Bryant >>>>>>>>>>>>> (stbryant) >>>>>>>>>>>>> Subject: Re: [Status] Summary of STATUS BOF and the next >>>>>>>>>>>>> steps >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Sep 1, 2013, at 5:38 PM, Victor Kuarsingh wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> All, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I would also favour "Segment Routing WG" as well. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I note this since attempting to come up with an all >>>>>>>>>>>>>> encompassing acronym will be difficult and Segment Routing >>>>>>>>>>>>>> is generic enough to associate to multiple functions. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Then we can just use "segroute" for the short name. WGs do >>>>>>>>>>>>> not have to have acronyms, but they do need to have an >>>>>>>>>>>>> 8-char limited short name for the various automated tools not= to break. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> - Mark >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Victor K >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 2013-08-31 6:51 PM, "Roberta Maglione (robmgl)" >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +1 for Segment Routing WG >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Roberta >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sent from my iPad >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 2013-08-30, at 2:55 PM, "Alvaro Retana (aretana)" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Segment Routing WG >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Aug 30, 2013, at 1:39 PM, "Stewart Bryant (stbryant)" >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The second task, which hopefully should be relatively >>>>>>>>>>>>>>>>> easy, is to find a better working name for the WG, since >>>>>>>>>>>>>>>>> it has been put to me a number of times that STATUS is >>>>>>>>>>>>>>>>> going to be confusing in text and a difficult search term= . >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> status mailing list >>>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> status mailing list >>>>>>>>>>>>> status@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>>=20 >>>>>>>>>>>> _____________________________________________________________ >>>>>>>>>>>> ____ _ _ _ __ >>>>>>>>>>>> ___________________________________________________ >>>>>>>>>>>>=20 >>>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans >>>>>>>>>>>> autorisation. Si vous avez recu ce message par erreur, veuille= z le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es messages electroniques etant susceptibles d'alteration, Orange decline t= oute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>>>>=20 >>>>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>>>> privileged information that may be protected by law; they shou= ld not be distributed, used or copied without authorisation. >>>>>>>>>>>> If you have received this email in error, please notify the se= nder and delete this message and its attachments. >>>>>>>>>>>> As emails may be altered, Orange is not liable for messages th= at have been modified, changed or falsified. >>>>>>>>>>>> Thank you. >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> status mailing list >>>>>>>>>>>> status@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>> ______________________________________________________________ >>>>>>>>>>> ____ _ _ _ >>>>>>>>>>> ____________________________________________________ >>>>>>>>>>>=20 >>>>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>>>> informations confidentielles ou privilegiees et ne doivent >>>>>>>>>>> donc pas etre diffuses, exploites ou copies sans autorisation. >>>>>>>>>>> Si vous avez recu ce message par erreur, veuillez le signaler a= l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele= ctroniques etant susceptibles d'alteration, Orange decline toute responsabi= lite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>>>=20 >>>>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>>>> privileged information that may be protected by law; they shoul= d not be distributed, used or copied without authorisation. >>>>>>>>>>> If you have received this email in error, please notify the sen= der and delete this message and its attachments. >>>>>>>>>>> As emails may be altered, Orange is not liable for messages tha= t have been modified, changed or falsified. >>>>>>>>>>> Thank you. >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> status mailing list >>>>>>>>>>> status@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Loa Andersson email: loa@mail01.huawei.co= m >>>>>>>>>> Senior MPLS Expert loa@pi.nu >>>>>>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>>>>> _______________________________________________ >>>>>>>>>> status mailing list >>>>>>>>>> status@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> status mailing list >>>>>>>>> status@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>>>=20 >>>>>>>>> ________________________________________________________________ >>>>>>>>> ____ _ _ ___________________________________________________ >>>>>>>>>=20 >>>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si >>>>>>>>> vous avez recu ce message par erreur, veuillez le signaler a l'ex= pediteur et le detruire ainsi que les pieces jointes. Les messages electron= iques etant susceptibles d'alteration, Orange decline toute responsabilite = si ce message a ete altere, deforme ou falsifie. Merci. >>>>>>>>>=20 >>>>>>>>> This message and its attachments may contain confidential or >>>>>>>>> privileged information that may be protected by law; they should = not be distributed, used or copied without authorisation. >>>>>>>>> If you have received this email in error, please notify the sende= r and delete this message and its attachments. >>>>>>>>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>>>>>>>> Thank you. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _________________________________________________________________ >>>>>>>> ____ _ ___________________________________________________ >>>>>>>>=20 >>>>>>>> Ce message et ses pieces jointes peuvent contenir des >>>>>>>> informations confidentielles ou privilegiees et ne doivent donc >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous >>>>>>>> avez recu ce message par erreur, veuillez le signaler a l'expedite= ur et le detruire ainsi que les pieces jointes. Les messages electroniques = etant susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci. >>>>>>>>=20 >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; they should n= ot be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the sender= and delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> status mailing list >>>>>>>> status@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>>>=20 >>>>>>>=20 >>>>>>> __________________________________________________________________ >>>>>>> ____ ___________________________________________________ >>>>>>>=20 >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de= truire ainsi que les pieces jointes. Les messages electroniques etant susce= ptibles d'alteration, Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >>>>>>>=20 >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should no= t be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified. >>>>>>> Thank you. >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ___________________________________________________________________ >>>>>> ______________________________________________________ >>>>>>=20 >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le det= ruire ainsi que les pieces jointes. Les messages electroniques etant suscep= tibles d'alteration, Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. >>>>>>=20 >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not= be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that hav= e been modified, changed or falsified. >>>>>> Thank you. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >>=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From hannes@juniper.net Thu Sep 12 06:24:05 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FB021E80B7 for ; Thu, 12 Sep 2013 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3Q8M2USNWXD for ; Thu, 12 Sep 2013 06:23:59 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2788B21E80D0 for ; Thu, 12 Sep 2013 06:23:59 -0700 (PDT) Received: from mail134-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.22; Thu, 12 Sep 2013 13:23:54 +0000 Received: from mail134-co1 (localhost [127.0.0.1]) by mail134-co1-R.bigfish.com (Postfix) with ESMTP id 9267E18012B; Thu, 12 Sep 2013 13:23:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz98dI9371I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail134-co1: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail134-co1 (localhost.localdomain [127.0.0.1]) by mail134-co1 (MessageSwitch) id 137899223281711_16617; Thu, 12 Sep 2013 13:23:52 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.241]) by mail134-co1.bigfish.com (Postfix) with ESMTP id 0FF5C5E023A; Thu, 12 Sep 2013 13:23:52 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 12 Sep 2013 13:23:51 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.233.34) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 12 Sep 2013 13:23:48 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Thu, 12 Sep 2013 15:23:41 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> To: "Stefano Previdi (sprevidi)" X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephane Litkowski , Xuxiaohu , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 13:24:05 -0000 hi stefano, can you *share* your proposed 'extension header' spec ? such that ASIC/hardware people can assess themselves: 1. what are the implications wrt to deployed hardware 2. if there is a forwarding penalty /hannes On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote: [ =85 ] >>>=20 >>> v6 dataplane allows more effective source route capability by >>> leveraging extensions headers. Hence the proposal that will >>> consist of defining a new Extension Header for SR where the >>> segment list is encoded and _preserved_ throughout the path. >>=20 >> What's the purpose of preserving the whole segment list throughout = the path? In other words, isn't it enough to contain the information of = ingress and egress nodes throughout the path? >=20 >=20 > there are use cases, among which OAM, that will leverage the=20 > availability of the segment list. v6 has good native properties=20 > that allow to insert explicit/source routing paradigms in the=20 > forwarding plane. Most of SW/HW implementations today can handle=20 > this without incurring HW performance penalty. >=20 > Thanks. > s. From sprevidi@cisco.com Thu Sep 12 07:10:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF0B11E8194 for ; Thu, 12 Sep 2013 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6QbRhQrLZ8F for ; Thu, 12 Sep 2013 07:10:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7811E8117 for ; Thu, 12 Sep 2013 07:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1468; q=dns/txt; s=iport; t=1378995021; x=1380204621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XWAmxoOAZ1Qm0pL++RbO05uvH3MebODf4EoE5o/SR9A=; b=e6Bg8JVdjKDFwlsoharyFZZtOxZ5ctRAZQl3hSEqFf74C7Cg6AtZn4WZ 2vV77jfaHnsRS0zByGfXac6YdajQSNV45BggSebVOog4s9//NZtkpA2C4 u3xvpz5YSEkOoT/FmdUBJfL+vT70oyl6S1pWKjoxFSlieoF6miO5PPF2v Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABjKMVKtJV2Z/2dsb2JhbABbgweBCsBigRsWdIIlAQEBAwF5BQsCAQgYCiQyJQIEDg2HdAa8IY84AjEHgx2BAAOpbIMigio X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258836876" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 12 Sep 2013 14:10:19 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8CEAJ8x006200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 14:10:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 09:10:18 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCOU6onlhRv02/sy9dxUhyQpm/AXKAgAAD6wCAABPUAP//uVuAgACzLACAAJtuAIAAjIYAgAD4wACAALzSgIAACyaAgAANCAA= Date: Thu, 12 Sep 2013 14:10:18 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.167.240] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1D33629A2AE2A549AD80FD877A85ABAF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stephane Litkowski , Xuxiaohu , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 14:10:35 -0000 On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote: > hi stefano, >=20 > can you *share* your proposed 'extension header' spec ? when ready, yes. It's going to be submitted by Vancouver meeting. In the mean time, I believe we can still talk about the charter=20 or is the rule that we have to spec out all details first ? s. > such that ASIC/hardware people can assess themselves: >=20 > 1. what are the implications wrt to deployed hardware > 2. if there is a forwarding penalty >=20 > /hannes >=20 > On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote: > [ =85 ] >>>>=20 >>>> v6 dataplane allows more effective source route capability by >>>> leveraging extensions headers. Hence the proposal that will >>>> consist of defining a new Extension Header for SR where the >>>> segment list is encoded and _preserved_ throughout the path. >>>=20 >>> What's the purpose of preserving the whole segment list throughout the = path? In other words, isn't it enough to contain the information of ingress= and egress nodes throughout the path? >>=20 >>=20 >> there are use cases, among which OAM, that will leverage the=20 >> availability of the segment list. v6 has good native properties=20 >> that allow to insert explicit/source routing paradigms in the=20 >> forwarding plane. Most of SW/HW implementations today can handle=20 >> this without incurring HW performance penalty. >>=20 >> Thanks. >> s. >=20 >=20 From akatlas@gmail.com Thu Sep 12 07:28:31 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC921E813D for ; Thu, 12 Sep 2013 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7yVFkBjx7GG for ; Thu, 12 Sep 2013 07:28:30 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 52AE221E8104 for ; Thu, 12 Sep 2013 07:28:30 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so1218813iec.32 for ; Thu, 12 Sep 2013 07:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JELltjG73lniV1DkpMhOFfT88nVgrIun6nwCu0KXFcM=; b=0mQ3HG3xw9k/Qm4WwGc8OGWPT8F1k4HDF0IhvwGi8RhGuZtaj2f3aAK8/yMA/DvBbn qCmzeFgjRsQz1RNGMQ/krdObAl2WykPzN5ZMusA68Wgzj/tYtmLaVfgclb/AHHZPdxkc zyZkoeJ1P3MAEYK8FojidgM2W+KJt+sKOjw9KKUBTGFL+lLQV0+WTY3wXpbaVrObSk46 tU5LWrR5rTNBDG3i3fOU48fJmQYLQVTMAB5hMa6Yi1m8Dko2xnNleK8L9fMoU8qOCrCn Jqn7GFhQMOnLAHj8C4VR9pzpd2GWUGxMG8C+GQcfHPyMIPAFRPxEiDesQoWjtdFUMAtw DmUA== MIME-Version: 1.0 X-Received: by 10.50.120.104 with SMTP id lb8mr13744101igb.22.1378996109813; Thu, 12 Sep 2013 07:28:29 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 12 Sep 2013 07:28:29 -0700 (PDT) In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> Date: Thu, 12 Sep 2013 10:28:29 -0400 Message-ID: From: Alia Atlas To: "Stefano Previdi (sprevidi)" Content-Type: multipart/alternative; boundary=047d7bd76bb245fa5004e6308ddf Cc: Hannes Gredler , Xuxiaohu , Rob Shakir , "status@ietf.org" , Stephane Litkowski Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 14:28:32 -0000 --047d7bd76bb245fa5004e6308ddf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stefano, On Thu, Sep 12, 2013 at 10:10 AM, Stefano Previdi (sprevidi) < sprevidi@cisco.com> wrote: > > On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote: > > > hi stefano, > > > > can you *share* your proposed 'extension header' spec ? > > > when ready, yes. It's going to be submitted by Vancouver meeting. > In the mean time, I believe we can still talk about the charter > or is the rule that we have to spec out all details first ? > When you both claim " Most of SW/HW implementations today can handle this without incurring HW performance penalty." and that there is interoperability testing planned for an unstandardized version and not wanting to wait to document use-cases that would require it, then - yes - a certain degree of transparency is desirable. Personally, having it work both ways a) all ready, interoperable, no HW penalties (on any hardware?), and needed b) not ready to fully document use-cases requiring it nor the proposed header extensions seems like remarkable double-think. To expect everyone to accept your assertions of (a) without any of (b) seems unusually absurd. If you don't even have a draft documenting the proposed 'extension header' spec, then the claim that it works without penalty on all HW seems like an astonishing stretch. Finally, work on drafts and discussions should happen between meetings too. It's much easier to focus on specific drafts and issues when everything else in the IETF isn't happening. Deciding to focus only on the deadlines associated with IETF meetings is part of what slows the IETF down. I believe that isn't your goal here... Getting continuous work is something that I, for instance, am trying to stress in I2RS. Regards, Alia > s. > > > > such that ASIC/hardware people can assess themselves: > > > > 1. what are the implications wrt to deployed hardware > > 2. if there is a forwarding penalty > > > > /hannes > > > > On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote: > > [ =85 ] > >>>> > >>>> v6 dataplane allows more effective source route capability by > >>>> leveraging extensions headers. Hence the proposal that will > >>>> consist of defining a new Extension Header for SR where the > >>>> segment list is encoded and _preserved_ throughout the path. > >>> > >>> What's the purpose of preserving the whole segment list throughout th= e > path? In other words, isn't it enough to contain the information of ingre= ss > and egress nodes throughout the path? > >> > >> > >> there are use cases, among which OAM, that will leverage the > >> availability of the segment list. v6 has good native properties > >> that allow to insert explicit/source routing paradigms in the > >> forwarding plane. Most of SW/HW implementations today can handle > >> this without incurring HW performance penalty. > >> > >> Thanks. > >> s. > > > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --047d7bd76bb245fa5004e6308ddf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Stefano,

On Thu, Sep 12, 2013 at 10:10 AM, Stefano Previdi (sprevidi) <spr= evidi@cisco.com> wrote:

On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote:

> hi stefano,
>
> can you *share* your proposed 'extension header' spec ?


when ready, yes. It's going to be submitted by Vancouver meeting.=
In the mean time, I believe we can still talk about the charter
or is the rule that we have to spec out all details first ?

When you both claim
"=A0= Most of SW/HW implementations today can handle=A0this without in= curring HW performance penalty."
and that there is interoperability testing planned for an unstandardiz= ed version and not wanting to wait
to document use-cases that wou= ld require it, then - yes - a certain degree of transparency is desirable.<= /div>

Personally, having it work both ways=A0
=A0 = =A0a) all ready, interoperable, no HW penalties (on any hardware?), and nee= ded
=A0 =A0b) not ready to fully document use-cases requiring it = nor the proposed header extensions

seems like remarkable double-think. To expect everyone = to accept your assertions of (a) without any of (b)
seems unusual= ly absurd.

If you don't even have a draft docu= menting the proposed 'extension header' spec, then the claim that i= t
works without penalty on all HW seems like an astonishing stretch.

Finally, work on drafts and discussions should happen= between meetings too. =A0It's much easier to focus on
specif= ic drafts and issues when everything else in the IETF isn't happening. = =A0 Deciding to focus only on the deadlines
associated with IETF meetings is part of what slows the IETF down. =A0= I believe that isn't your goal here... =A0Getting
continuous = work is something that I, for instance, am trying to stress in I2RS.
<= div>
Regards,
Alia


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
s.


> such that ASIC/hardware people can assess themselves:
>
> 1. what are the implications wrt to deployed hardware
> 2. if there is a forwarding penalty
>
> /hannes
>
> On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote:
> [ =85 ]
>>>>
>>>> v6 dataplane allows more effective source route capability= by
>>>> leveraging extensions headers. Hence the proposal that wil= l
>>>> consist of defining a new Extension Header for SR where th= e
>>>> segment list is encoded and _preserved_ throughout the pat= h.
>>>
>>> What's the purpose of preserving the whole segment list th= roughout the path? In other words, isn't it enough to contain the infor= mation of ingress and egress nodes throughout the path?
>>
>>
>> there are use cases, among which OAM, that will leverage the
>> availability of the segment list. v6 has good native properties >> that allow to insert explicit/source routing paradigms in the
>> forwarding plane. Most of SW/HW implementations today can handle >> this without incurring HW performance penalty.
>>
>> Thanks.
>> s.
>
>

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

--047d7bd76bb245fa5004e6308ddf-- From hannes@juniper.net Thu Sep 12 07:45:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5C811E81B1 for ; Thu, 12 Sep 2013 07:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKOzL7aasvxa for ; Thu, 12 Sep 2013 07:45:42 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B74411E8117 for ; Thu, 12 Sep 2013 07:45:42 -0700 (PDT) Received: from mail211-va3-R.bigfish.com (10.7.14.227) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 12 Sep 2013 14:45:41 +0000 Received: from mail211-va3 (localhost [127.0.0.1]) by mail211-va3-R.bigfish.com (Postfix) with ESMTP id 070E5C001A1; Thu, 12 Sep 2013 14:45:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); IPV:NLI; H:BN1PRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h946hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail211-va3: domain of juniper.net designates 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=hannes@juniper.net; helo=BN1PRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail211-va3 (localhost.localdomain [127.0.0.1]) by mail211-va3 (MessageSwitch) id 1378997138889318_24566; Thu, 12 Sep 2013 14:45:38 +0000 (UTC) Received: from VA3EHSMHS037.bigfish.com (unknown [10.7.14.235]) by mail211-va3.bigfish.com (Postfix) with ESMTP id D553640040; Thu, 12 Sep 2013 14:45:38 +0000 (UTC) Received: from BN1PRD0512HT001.namprd05.prod.outlook.com (132.245.2.21) by VA3EHSMHS037.bigfish.com (10.7.99.47) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 12 Sep 2013 14:45:38 +0000 Received: from hannes-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.193.34) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 12 Sep 2013 14:45:35 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Hannes Gredler In-Reply-To: Date: Thu, 12 Sep 2013 16:45:05 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <002EACA1-D4D6-4286-873B-43B92386A4AF@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> To: Stefano Previdi X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephane Litkowski , Xuxiaohu , Rob Shakir , "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 14:45:51 -0000 stefano, On Sep 12, 2013, at 4:10 PM, Stefano Previdi (sprevidi) wrote: >=20 > On Sep 12, 2013, at 3:23 PM, Hannes Gredler wrote: >=20 >> hi stefano, >>=20 >> can you *share* your proposed 'extension header' spec ? >=20 >=20 > when ready, yes. It's going to be submitted by Vancouver meeting. ^^^^^^^^^^^^^^^^^^ HG> as per your email below i was under the impression that 'soon' is = 'sooner' - and having a spec is precursor for doing interop testing. - looks like that you are not there yet. --- On Sep 10, 2013, at 6:58 PM, Stefano Previdi (sprevidi) wrote: [ =85 ] As I mentioned in my charter proposal, we do have implementations and multi-vendor interoperability tests will happen soon. So, I just want to be sure we don't ignore this reality. --- in summary: the list hasn't seen a good case for both service-chaining and why we need another data plane in support for this. i concur therefore with stephane that we shall add exploration if those things are needed in the charter, but its a bit premature (also in lieu of written down use-cases and proposals) to make it mandatory to include now. > In the mean time, I believe we can still talk about the charter=20 > or is the rule that we have to spec out all details first ? HG> there is a difference between: "i want the charter to look like this, because this is what i am currently developing" and "lets work on question(s) in an open-forum and the answers are going to shape what changes we need to existing protocols and forwarding paradigms" /hannes > such that ASIC/hardware people can assess themselves: >>=20 >>=20 >> 1. what are the implications wrt to deployed hardware >> 2. if there is a forwarding penalty >>=20 >> /hannes >>=20 >> On Sep 12, 2013, at 2:43 PM, Stefano Previdi (sprevidi) wrote: >> [ =85 ] >>>>>=20 >>>>> v6 dataplane allows more effective source route capability by >>>>> leveraging extensions headers. Hence the proposal that will >>>>> consist of defining a new Extension Header for SR where the >>>>> segment list is encoded and _preserved_ throughout the path. >>>>=20 >>>> What's the purpose of preserving the whole segment list throughout = the path? In other words, isn't it enough to contain the information of = ingress and egress nodes throughout the path? >>>=20 >>>=20 >>> there are use cases, among which OAM, that will leverage the=20 >>> availability of the segment list. v6 has good native properties=20 >>> that allow to insert explicit/source routing paradigms in the=20 >>> forwarding plane. Most of SW/HW implementations today can handle=20 >>> this without incurring HW performance penalty. >>>=20 >>> Thanks. >>> s. >>=20 >>=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 From jdrake@juniper.net Thu Sep 12 07:56:59 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A811E8238 for ; Thu, 12 Sep 2013 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KndL-5umjuLm for ; Thu, 12 Sep 2013 07:56:49 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 129C811E821E for ; Thu, 12 Sep 2013 07:56:46 -0700 (PDT) Received: from mail35-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE001.bigfish.com (10.236.130.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 12 Sep 2013 14:56:24 +0000 Received: from mail35-co9 (localhost [127.0.0.1]) by mail35-co9-R.bigfish.com (Postfix) with ESMTP id CEFEE200098; Thu, 12 Sep 2013 14:56:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: VPS-18(zz98dI9371Ic89bh1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h941hd25he5bhf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail35-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(199002)(189002)(377454003)(31966008)(33656001)(36756003)(83072001)(15202345003)(81542001)(50986001)(47976001)(19580395003)(83322001)(47736001)(49866001)(19580405001)(51856001)(77096001)(79102001)(561944002)(56816003)(4396001)(76482001)(69226001)(54316002)(80976001)(74662001)(54356001)(47446002)(81686001)(74876001)(15975445006)(74706001)(76786001)(76796001)(65816001)(82746002)(59766001)(66066001)(56776001)(74366001)(81342001)(63696002)(80022001)(77982001)(81816001)(74502001)(46102001)(53806001)(83716001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB254; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:64.134.234.205; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail35-co9 (localhost.localdomain [127.0.0.1]) by mail35-co9 (MessageSwitch) id 1378997750851326_23154; Thu, 12 Sep 2013 14:55:50 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.237]) by mail35-co9.bigfish.com (Postfix) with ESMTP id C135112046B; Thu, 12 Sep 2013 14:55:50 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 12 Sep 2013 14:55:42 +0000 Received: from BY2PR05MB254.namprd05.prod.outlook.com (10.242.41.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 12 Sep 2013 14:55:38 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB254.namprd05.prod.outlook.com (10.242.41.152) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 12 Sep 2013 14:55:35 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.224]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.224]) with mapi id 15.00.0745.000; Thu, 12 Sep 2013 14:55:35 +0000 From: John E Drake To: "Stefano Previdi (sprevidi)" Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrtsJ2l2pO7IzQkaX2N7UOeUQgpnBUOkAgAC80ICAACTVQA== Date: Thu, 12 Sep 2013 14:55:34 +0000 Message-ID: <76C1435B-763F-4672-8F69-D12D80A12E31@juniper.net> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.234.205] x-forefront-prvs: 0967749BC1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephane Litkowski , Xuxiaohu , Rob Shakir , "status@ietf.org" , Hannes Gredler Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 14:56:59 -0000 U3RlZmFubywNCg0KQXMgSSBwb2ludGVkIG91dCB0byBQZXRlciBsYXN0IHdlZWssIGl0IGlzIG11 Y2ggYmV0dGVyIHRvIGhhdmUgdGhlIHJvdXRlIGEgcGFja2V0IHRha2VzIHRocm91Z2ggYSBuZXR3 b3JrIHRoYW4gdGhlIHJvdXRlIHRoZSBpbmdyZXNzIG5vZGUgdGhpbmtzIGl0IHdpbGwgdGFrZS4g IEZ1cnRoZXIsIGlmIHRoZSBsYXR0ZXIgaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIG5vZGFs IHNlZ21lbnRzLCB0aGVuIGFsbCB5b3Ugd2lsbCBoYXZlIGlzIGEgbG9vc2Ugc291cmNlIHJvdXRl Lg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIFNlcCAxMiwgMjAxMywgYXQgNTo0NCBBTSwg IlN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIiA8c3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToN Cg0KPiBIaSBYaWFvaHUsDQo+IA0KPiBPbiBTZXAgMTIsIDIwMTMsIGF0IDM6MjcgQU0sIFh1eGlh b2h1IHdyb3RlOg0KPj4gSGkgU3RlZmFubywNCj4+IA0KPj4+IC0tLS0t08q8/tStvP4tLS0tLQ0K Pj4+ILeivP7Iyzogc3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNl c0BpZXRmLm9yZ10gtPqx7Q0KPj4+IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpDQo+Pj4gt6LL zcqxvOQ6IDIwMTPE6jnUwjExyNUgMTg6MzgNCj4+PiDK1bz+yMs6IFh1eGlhb2h1DQo+Pj4gs63L zTogU3RlcGhhbmUgTGl0a293c2tpOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5vcmc7IEhhbm5l cyBHcmVkbGVyDQo+Pj4g1vfM4jogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9wb3NhbHMg ZnJvbSBIYW5uZXMgYW5kIFN0ZWZhbm8gOiB0cnkgdG8NCj4+PiBtZXJnZSAuLi4NCj4+PiANCj4+ PiBIaSBYaWFvaHUsDQo+Pj4gDQo+Pj4gT24gU2VwIDExLCAyMDEzLCBhdCA0OjE0IEFNLCBYdXhp YW9odSB3cm90ZToNCj4+Pj4gDQo+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+Pj4+ILeivP7I yzogc3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9y Z10gtPqx7Q0KPj4+Pj4gU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4+Pj4+ILeiy83Ksbzk OiAyMDEzxOo51MIxMcjVIDA6NTgNCj4+Pj4+IMrVvP7IyzogU3RlcGhhbmUgTGl0a293c2tpDQo+ Pj4+PiCzrcvNOiBIYW5uZXMgR3JlZGxlcjsgUm9iIFNoYWtpcjsgc3RhdHVzQGlldGYub3JnDQo+ Pj4+PiDW98ziOiBSZTogW1N0YXR1c10gR29vZCBjaGFydGVyIHByb3Bvc2FscyBmcm9tIEhhbm5l cyBhbmQgU3RlZmFubyA6IHRyeSB0bw0KPj4+Pj4gbWVyZ2UgLi4uDQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4gT24gU2VwIDEwLCAyMDEzLCBhdCAxOjI1IFBNLCA8c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gQWdyZWUgb24gYWxsIHByb3Bvc2FsIGV4 Y2VwdCA6DQo+Pj4+Pj4gDQo+Pj4+Pj4gIltTUF0gVGhlIGFyY2hpdGVjdHVyZSB3aWxsIHN1cHBv cnQgdHVubmVsIGFuZCBub24tdHVubmVsIHBhcmFkaWdtcw0KPj4+Pj4+ICBUaGUgYXJjaGl0ZWN0 dXJlIHdpbGwgc3VwcG9ydCBtdWx0aXBsZSBkYXRhcGxhbmVzOiBNUExTIGFuZCBWNiINCj4+Pj4+ PiANCj4+Pj4+PiBJIGRvbid0IHNlZSB0aGUgcmVhc29uIGZvciB0aGlzIC4uLiBJTUhPLCB0aGUg Z2FwIGFuYWx5c2lzIGFuZCByZXF1aXJlbWVudHMNCj4+Pj4+IGludmVudG9yeSB3aWxsIHJlc3Vs dCBvbiBzYXlpbmcgb3Igbm90DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gW1NQXSBXaGlsZSBJIHVu ZGVyc3RhbmQgd2hhdCBicm91Z2h0IHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cw0KPj4+Pj4gICBp biB0aGUgcHJvcG9zZWQgY2hhcnRlcjoNCj4+Pj4+ICAgICJIYXZpbmcgaWRlbnRpZmllZCB1c2Ut Y2FzZXMsIGFyY2hpdGVjdHVyZSBhbmQgc2VjdXJpdHksDQo+Pj4+PiAgICAgdGhlIFdHIHdpbGwg aWRlbnRpZnkgZ2FwcyBiZXR3ZWVuIGN1cnJlbnRseSBhdmFpbGFibGUNCj4+Pj4+ICAgICB0ZWNo bm9sb2dpZXMgYW5kIHVzZS1jYXNlIHJlcXVpcmVtZW50cy4NCj4+Pj4+ICAgICBUaGUgV0cgd2ls bCB0aGVuIGRlZmluZSByZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8NCj4+Pj4+ICAgICBl eGlzdGluZyBwcm90b2NvbHMgb3IgbmV3IHByb3RvY29scyB0aGF0IGFkZHJlc3MgZ2Fwcw0KPj4+ Pj4gICAgIHRoYXQgYXJlIGlkZW50aWZpZWQuIg0KPj4+Pj4gDQo+Pj4+PiAgIEknZCBsaWtlIHRv IHBvaW50IG91dCB3aXRoIGJldHRlciBwcmVjaXNpb24gd2hhdCBhcmUgdGhlDQo+Pj4+PiAgIGRp cmVjdGlvbnMgd2UgYXJlIEFMUkVBRFkgZW5nYWdlZCBpbnRvOiBkYXRhcGxhbmVzIGFuZA0KPj4+ Pj4gICBwYXJhZGlnbXMuIEFzIEkgbWVudGlvbmVkIGluIG15IGNoYXJ0ZXIgcHJvcG9zYWwsIHdl IGRvIGhhdmUNCj4+Pj4+ICAgaW1wbGVtZW50YXRpb25zIGFuZCBtdWx0aS12ZW5kb3IgaW50ZXJv cGVyYWJpbGl0eSB0ZXN0cyB3aWxsDQo+Pj4+PiAgIGhhcHBlbiBzb29uLiBTbywgSSBqdXN0IHdh bnQgdG8gYmUgc3VyZSB3ZSBkb24ndCBpZ25vcmUgdGhpcw0KPj4+Pj4gICByZWFsaXR5Lg0KPj4+ Pj4gDQo+Pj4+PiAgIE1QTFMgYW5kIHY2IGRhdGEtcGxhbmUgYXJlIHBhcnQgb2YgdGhpcyByZWFs aXR5LCBhcyB3ZWxsIGFzDQo+Pj4+PiAgIHR1bm5lbC1iYXNlZCBhbmQgbm9uLXR1bm5lbCBiYXNl ZCBhcHByb2FjaGVzLg0KPj4+PiANCj4+Pj4gSSBkb24ndCB0aGluayBpdCdzIHN1aXRhYmxlIHRv IG1lbnRpb24gZGV2ZWxvcGluZyBJUHY2IHNwZWNpZmljIFNSIG1lY2hhbmlzbSBpbg0KPj4+IHRo ZSBjdXJyZW50IGNoYXJ0ZXIgdW5sZXNzIHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IGZvciBhbnkg Y2hhbmdlIHRvIHRoZSBleGlzdGluZw0KPj4+IElQdjYgZGF0YSBwbGFuZS4NCj4+PiANCj4+Pj4g QWNjb3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBxdW90ZWQgZnJvbQ0KPj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbHNmaWxzLXJ0Z3dnLXNlZ21lbnQtcm91 dGluZy0wMCNwYWdlLTksICIuLi5UaGUNCj4+PiBzb3VyY2Ugcm91dGUgaXMgZW5jb2RlZCBhcyBh biBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMuLi4iDQo+ Pj4gSWYgc28sIHdoeSBub3QgZGlyZWN0bHkgdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiBsYWJlbHMg KGkuZS4sIE1QTFMgbGFiZWwgc3RhY2spIHRvIGRvDQo+Pj4gdGhhdCAoc2VlDQo+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3N0YXR1cy9jdXJyZW50L21zZzAwMTY1Lmh0 bWwpPw0KPj4+IA0KPj4+IA0KPj4+IHY2IGRhdGFwbGFuZSBhbGxvd3MgbW9yZSBlZmZlY3RpdmUg c291cmNlIHJvdXRlIGNhcGFiaWxpdHkgYnkNCj4+PiBsZXZlcmFnaW5nIGV4dGVuc2lvbnMgaGVh ZGVycy4gSGVuY2UgdGhlIHByb3Bvc2FsIHRoYXQgd2lsbA0KPj4+IGNvbnNpc3Qgb2YgZGVmaW5p bmcgYSBuZXcgRXh0ZW5zaW9uIEhlYWRlciBmb3IgU1Igd2hlcmUgdGhlDQo+Pj4gc2VnbWVudCBs aXN0IGlzIGVuY29kZWQgYW5kIF9wcmVzZXJ2ZWRfIHRocm91Z2hvdXQgdGhlIHBhdGguDQo+PiAN Cj4+IFdoYXQncyB0aGUgcHVycG9zZSBvZiBwcmVzZXJ2aW5nIHRoZSB3aG9sZSBzZWdtZW50IGxp c3QgdGhyb3VnaG91dCB0aGUgcGF0aD8gSW4gb3RoZXIgd29yZHMsIGlzbid0IGl0IGVub3VnaCB0 byBjb250YWluIHRoZSBpbmZvcm1hdGlvbiBvZiBpbmdyZXNzIGFuZCBlZ3Jlc3Mgbm9kZXMgdGhy b3VnaG91dCB0aGUgcGF0aD8NCj4gDQo+IA0KPiB0aGVyZSBhcmUgdXNlIGNhc2VzLCBhbW9uZyB3 aGljaCBPQU0sIHRoYXQgd2lsbCBsZXZlcmFnZSB0aGUgDQo+IGF2YWlsYWJpbGl0eSBvZiB0aGUg c2VnbWVudCBsaXN0LiB2NiBoYXMgZ29vZCBuYXRpdmUgcHJvcGVydGllcyANCj4gdGhhdCBhbGxv dyB0byBpbnNlcnQgZXhwbGljaXQvc291cmNlIHJvdXRpbmcgcGFyYWRpZ21zIGluIHRoZSANCj4g Zm9yd2FyZGluZyBwbGFuZS4gTW9zdCBvZiBTVy9IVyBpbXBsZW1lbnRhdGlvbnMgdG9kYXkgY2Fu IGhhbmRsZSANCj4gdGhpcyB3aXRob3V0IGluY3VycmluZyBIVyBwZXJmb3JtYW5jZSBwZW5hbHR5 Lg0KPiANCj4gVGhhbmtzLg0KPiBzLg0KPiANCj4gDQo+PiANCj4+IEJlc3QgcmVnYXJkcywNCj4+ IFhpYW9odQ0KPj4gDQo+Pj4gU28sIEkgZG8gc3Ryb25nbHkgYmVsaWV2ZSB3ZSBoYXZlIHRvIHdv cmsgb24gdjYgYW5kIHNpbmNlIHdlJ3JlDQo+Pj4gaW4gdGhlIGRlZmluaXRpb24gb2YgYSBjaGFy dGVyIChpLmUuOiBub3QgdGhlIGRldGFpbGVkIHJldmlldw0KPj4+IG9mIHRoZSBzb2x1dGlvbnMp IEkgYmVsaWV2ZSB2NiBzaG91bGQgYmUgcGFydCBvZiBpdC4NCj4+PiANCj4+PiBUaGFua3MuDQo+ Pj4gcy4NCj4+PiANCj4+PiANCj4+Pj4gDQo+Pj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCj4+Pj4gVGhlIG1haW4gZGlmZmVyZW5jZXMgZnJvbSB0aGUgSVB2 NiBzb3VyY2Ugcm91dGUgbW9kZWwgYXJlOg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBGaWxz ZmlscywgZXQgYWwuICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDMwLCAyMDEzICAgICAgICAgICAg ICAgW1BhZ2UgOV0NCj4+Pj4gDQo+Pj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgU2Vn bWVudCBSb3V0aW5nICAgICAgICAgICAgICAgICAgIEp1bmUNCj4+PiAyMDEzDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gICAgVGhlIHNvdXJjZSByb3V0ZSBpcyBlbmNvZGVkIGFzIGFuIG9yZGVyZWQgbGlz dCBvZiBzZWdtZW50cyBpbnN0ZWFkDQo+Pj4+ICAgIG9mIElQIGFkZHJlc3Nlcy4NCj4+Pj4gDQo+ Pj4+ICAgIEEgc2VnbWVudCBjYW4gcmVwcmVzZW50IGFueSBpbnN0cnVjdGlvbiBlaXRoZXIgYSBz ZXJ2aWNlIG9yIGENCj4+Pj4gICAgdG9wb2xvZ2ljYWwgcGF0aC4gIFRvcG9sb2dpY2FsbHksIHRo ZSBwYXRoIHRvIGFuIElQIGFkZHJlc3MgaXMNCj4+Pj4gICAgb2Z0ZW4gbGltaXRlZCB0byB0aGUg c2hvcnRlc3QtcGF0aCB0byB0aGF0IGFkZHJlc3MuICBBIHNlZ21lbnQgY2FuDQo+Pj4+ICAgIHJl cHJlc2VudCBhbnkgcGF0aCAoZS5nLiBhbiBhZGphY2VuY3kgc2VnbWVudCBmb3JjZXMgYSBwYWNr ZXQgdG8gYQ0KPj4+PiAgICBuZXh0aG9wIHRocm91Z2ggYSBzcGVjaWZpYyBhZGphY2VuY3kgZXZl biBpZiB0aGUgc2hvcnRlc3QtcGF0aCB0bw0KPj4+PiAgICB0aGUgbmV4dC1ob3AgZG9lcyBub3Qg dXNlIHRoYXQgYWRqYWNlbmN5KS4NCj4+Pj4gDQo+Pj4+ICAgIFRoZSBpbmdyZXNzIGFuZCBlZ3Jl c3MgZWdkZSByb3V0ZXJzIGFyZSBpZGVudGlmaWVkIGFuZCBhbHdheXMNCj4+Pj4gICAgYXZhaWxh YmxlLCBhbGxvd2luZyBmb3IgaW50ZXJlc3RpbmcgYWNjb3VudGluZyBhbmQgcG9saWN5DQo+Pj4+ ICAgIGFwcGxpY2F0aW9ucy4NCj4+Pj4gDQo+Pj4+ICAgIFRoZSBzb3VyY2Ugcm91dGUgZnVuY3Rp b25hbGl0eSBjYW5ub3QgYmUgY29udHJvbGxlZCBmcm9tIG91dHNpZGUNCj4+Pj4gICAgdGhlIFNS IGRvbWFpbi4NCj4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KPj4+PiANCj4+Pj4gQmVzdCByZWdhcmRzLA0KPj4+PiBYaWFvaHUNCj4+PiANCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHN0YXR1cyBt YWlsaW5nIGxpc3QNCj4+PiBzdGF0dXNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiBzdGF0dXNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMN Cg== From sprevidi@cisco.com Thu Sep 12 08:14:32 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0994321E809F for ; Thu, 12 Sep 2013 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.809 X-Spam-Level: X-Spam-Status: No, score=-108.809 tagged_above=-999 required=5 tests=[AWL=1.790, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfIABRuJnz1X for ; Thu, 12 Sep 2013 08:14:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6B221F8F07 for ; Thu, 12 Sep 2013 08:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1384; q=dns/txt; s=iport; t=1378998861; x=1380208461; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wYF99kIqKOgQ1+KYp9jmE8gtm1Kb7Zs2yJ+AAiHbqss=; b=ExM+bB5Fc8h7ja2cBvnYkOhjYMTzrERFw4uPztQHOyZlLbN9vuY8Jabw u2Vi3iaqZ5Y87RFiofrPSUJPE2AgNFD6fUw/YiePQluuVh8Kj4+YUD0nA Hi5HlRwhYXA4aVpBguhzMDWSi+cd/tT33DBjeebpM7rvSGu2TnNaP1paX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFHZMVKtJV2Y/2dsb2JhbABbgweBCsBigRwWdIIlAQEBAwF5BQsCAQgYCiQyJQIEAQ0Nh3QGvCyOIoEWAjEHgx2BAAOpbIMigXE5 X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208";a="258867763" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 12 Sep 2013 15:14:19 +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 r8CFEJaB030892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 15:14:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 10:14:19 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler , Alia Atlas Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOr8bL4yhqfxf/XkWluYFbTdM/AZnCiceA Date: Thu, 12 Sep 2013 15:14:18 +0000 Message-ID: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com> <002EACA1-D4D6-4286-873B-43B92386A4AF@juniper.net> In-Reply-To: <002EACA1-D4D6-4286-873B-43B92386A4AF@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: <165D08EB8E704D42B84A0C195F60D951@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 15:14:32 -0000 Alia, Hannes, On Sep 12, 2013, at 4:45 PM, Hannes Gredler wrote: >=20 > HG> as per your email below i was under the impression that 'soon' is 'so= oner' - > and having a spec is precursor for doing interop testing. - > looks like that you are not there yet. > Finally, work on drafts and discussions should happen between meetings to= o. It's much easier to focus on > specific drafts and issues when everything else in the IETF isn't happeni= ng. Deciding to focus only on the deadlines > associated with IETF meetings is part of what slows the IETF down. I bel= ieve that isn't your goal here... Getting > continuous work is something that I, for instance, am trying to stress in= I2RS. the implementations interop tests are based on mpls data-plane. What I'd like to see in the charter is that the control plane must/should=20 be agnostic to data-plane instantiation so to support mpls and v6. Note that we already have the SR-ISIS draft which _is_ data-plane agnostic. Same in the mechanisms can be constructed, i.e., not bound to solely IGP=20 but rather give the ability to other components to construct paths using=20 segments. My time availability doesn't allow me to go faster so I will submit SR-v6=20 use-cases SR-IPv6 Extension Header and hopefully I'll be allowed to present= =20 them both at next meeting. s. From Peter.AshwoodSmith@huawei.com Thu Sep 12 09:11:22 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521DC11E824F for ; Thu, 12 Sep 2013 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlOO8JiSogX4 for ; Thu, 12 Sep 2013 09:11:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 568C011E826E for ; Thu, 12 Sep 2013 09:09:26 -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.5-GA FastPath queued) with ESMTP id AVI62212; Thu, 12 Sep 2013 16:09:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 17:08:21 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 17:08:33 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 12 Sep 2013 09:08:27 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCe3ehZT3wb0SYcUxDJhSIm5m/AXKAgAAD6wCAABPUAP//uVuAgACzLACAAJtuAIAAjIYAgAD4wACAALzSgIAARlkA//+Q10A= Date: Thu, 12 Sep 2013 16:08:27 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2099012FA@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com>, <76C1435B-763F-4672-8F69-D12D80A12E31@juniper.net> In-Reply-To: <76C1435B-763F-4672-8F69-D12D80A12E31@juniper.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.162] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 16:11:22 -0000 U29ycnksIEpvaG4sIGRpZCBub3Qgc2VlIHlvdXIgcmVzcG9uc2UgYnV0IHdlJ3ZlIGJlZW4gaGF2 aW5nIHNwYW0gZmlsdGVyIHByb2JsZW1zIGxhdGVseSBoZXJlLg0KDQpObyBkaXNhZ3JlZW1lbnQg d2l0aCAiaXQgaXMgbXVjaCBiZXR0ZXIgdG8gaGF2ZSB0aGUgcm91dGUgYSBwYWNrZXQgdGFrZXMg dGhyb3VnaCBhIG5ldHdvcmsgdGhhbiB0aGUgcm91dGUgdGhlIGluZ3Jlc3Mgbm9kZSB0aGlua3Mg aXQgd2lsbCB0YWtlIg0KDQpBbHRob3VnaCB0aGUgZGV2aWF0aW9ucyBmcm9tIHRoZSBpbnRlbmRl ZCByb3V0ZSBuZWVkIHRvIGNvbnRyb2xsYWJsZSAob24vb2ZmKSBzbyB0aGF0IGNlbnRyYWxpemVk IFRFICggbGlrZSBTRE4gd2FudHMgdG8gZG8gKSBjYW4gYmUgYXNzdXJlZCB0aGF0IGl0cyBtYXRo IGlzIGNvbnNpc3RlbnQgd2l0aCB3aGF0IGlzIHJlYWxseSBoYXBwZW5pbmcgaW4gdGhlIG5ldHdv cmsuDQoNCkNoZWVycywNCg0KUGV0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHN0YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb2huIEUgRHJha2UNClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIg MTIsIDIwMTMgMTA6NTYgQU0NClRvOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KQ2M6IFN0 ZXBoYW5lIExpdGtvd3NraTsgWHV4aWFvaHU7IFJvYiBTaGFraXI7IHN0YXR1c0BpZXRmLm9yZzsg SGFubmVzIEdyZWRsZXINClN1YmplY3Q6IFJlOiBbU3RhdHVzXSBHb29kIGNoYXJ0ZXIgcHJvcG9z YWxzIGZyb20gSGFubmVzIGFuZCBTdGVmYW5vIDogdHJ5IHRvIG1lcmdlIC4uLg0KDQpTdGVmYW5v LA0KDQpBcyBJIHBvaW50ZWQgb3V0IHRvIFBldGVyIGxhc3Qgd2VlaywgaXQgaXMgbXVjaCBiZXR0 ZXIgdG8gaGF2ZSB0aGUgcm91dGUgYSBwYWNrZXQgdGFrZXMgdGhyb3VnaCBhIG5ldHdvcmsgdGhh biB0aGUgcm91dGUgdGhlIGluZ3Jlc3Mgbm9kZSB0aGlua3MgaXQgd2lsbCB0YWtlLiAgRnVydGhl ciwgaWYgdGhlIGxhdHRlciBpcyB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggbm9kYWwgc2VnbWVu dHMsIHRoZW4gYWxsIHlvdSB3aWxsIGhhdmUgaXMgYSBsb29zZSBzb3VyY2Ugcm91dGUuDQoNClNl bnQgZnJvbSBteSBpUGhvbmUNCg0KT24gU2VwIDEyLCAyMDEzLCBhdCA1OjQ0IEFNLCAiU3RlZmFu byBQcmV2aWRpIChzcHJldmlkaSkiIDxzcHJldmlkaUBjaXNjby5jb20+IHdyb3RlOg0KDQo+IEhp IFhpYW9odSwNCj4gDQo+IE9uIFNlcCAxMiwgMjAxMywgYXQgMzoyNyBBTSwgWHV4aWFvaHUgd3Jv dGU6DQo+PiBIaSBTdGVmYW5vLA0KPj4gDQo+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+Pj4gt6K8 /sjLOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYu b3JnXSC0+rHtDQo+Pj4gU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4+PiC3osvNyrG85Dog MjAxM8TqOdTCMTHI1SAxODozOA0KPj4+IMrVvP7IyzogWHV4aWFvaHUNCj4+PiCzrcvNOiBTdGVw aGFuZSBMaXRrb3dza2k7IFJvYiBTaGFraXI7IHN0YXR1c0BpZXRmLm9yZzsgSGFubmVzIEdyZWRs ZXINCj4+PiDW98ziOiBSZTogW1N0YXR1c10gR29vZCBjaGFydGVyIHByb3Bvc2FscyBmcm9tIEhh bm5lcyBhbmQgU3RlZmFubyA6IHRyeSB0bw0KPj4+IG1lcmdlIC4uLg0KPj4+IA0KPj4+IEhpIFhp YW9odSwNCj4+PiANCj4+PiBPbiBTZXAgMTEsIDIwMTMsIGF0IDQ6MTQgQU0sIFh1eGlhb2h1IHdy b3RlOg0KPj4+PiANCj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+Pj4gt6K8/sjLOiBzdGF0 dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYub3JnXSC0+rHt DQo+Pj4+PiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPj4+Pj4gt6LLzcqxvOQ6IDIwMTPE 6jnUwjExyNUgMDo1OA0KPj4+Pj4gytW8/sjLOiBTdGVwaGFuZSBMaXRrb3dza2kNCj4+Pj4+ILOt y806IEhhbm5lcyBHcmVkbGVyOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5vcmcNCj4+Pj4+INb3 zOI6IFJlOiBbU3RhdHVzXSBHb29kIGNoYXJ0ZXIgcHJvcG9zYWxzIGZyb20gSGFubmVzIGFuZCBT dGVmYW5vIDogdHJ5IHRvDQo+Pj4+PiBtZXJnZSAuLi4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBP biBTZXAgMTAsIDIwMTMsIGF0IDE6MjUgUE0sIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiBBZ3JlZSBvbiBhbGwgcHJvcG9zYWwgZXhjZXB0IDoN Cj4+Pj4+PiANCj4+Pj4+PiAiW1NQXSBUaGUgYXJjaGl0ZWN0dXJlIHdpbGwgc3VwcG9ydCB0dW5u ZWwgYW5kIG5vbi10dW5uZWwgcGFyYWRpZ21zDQo+Pj4+Pj4gIFRoZSBhcmNoaXRlY3R1cmUgd2ls bCBzdXBwb3J0IG11bHRpcGxlIGRhdGFwbGFuZXM6IE1QTFMgYW5kIFY2Ig0KPj4+Pj4+IA0KPj4+ Pj4+IEkgZG9uJ3Qgc2VlIHRoZSByZWFzb24gZm9yIHRoaXMgLi4uIElNSE8sIHRoZSBnYXAgYW5h bHlzaXMgYW5kIHJlcXVpcmVtZW50cw0KPj4+Pj4gaW52ZW50b3J5IHdpbGwgcmVzdWx0IG9uIHNh eWluZyBvciBub3QNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBbU1BdIFdoaWxlIEkgdW5kZXJzdGFu ZCB3aGF0IGJyb3VnaHQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzDQo+Pj4+PiAgIGluIHRoZSBw cm9wb3NlZCBjaGFydGVyOg0KPj4+Pj4gICAgIkhhdmluZyBpZGVudGlmaWVkIHVzZS1jYXNlcywg YXJjaGl0ZWN0dXJlIGFuZCBzZWN1cml0eSwNCj4+Pj4+ICAgICB0aGUgV0cgd2lsbCBpZGVudGlm eSBnYXBzIGJldHdlZW4gY3VycmVudGx5IGF2YWlsYWJsZQ0KPj4+Pj4gICAgIHRlY2hub2xvZ2ll cyBhbmQgdXNlLWNhc2UgcmVxdWlyZW1lbnRzLg0KPj4+Pj4gICAgIFRoZSBXRyB3aWxsIHRoZW4g ZGVmaW5lIHJlcXVpcmVtZW50cyBmb3IgZXh0ZW5zaW9ucyB0bw0KPj4+Pj4gICAgIGV4aXN0aW5n IHByb3RvY29scyBvciBuZXcgcHJvdG9jb2xzIHRoYXQgYWRkcmVzcyBnYXBzDQo+Pj4+PiAgICAg dGhhdCBhcmUgaWRlbnRpZmllZC4iDQo+Pj4+PiANCj4+Pj4+ICAgSSdkIGxpa2UgdG8gcG9pbnQg b3V0IHdpdGggYmV0dGVyIHByZWNpc2lvbiB3aGF0IGFyZSB0aGUNCj4+Pj4+ICAgZGlyZWN0aW9u cyB3ZSBhcmUgQUxSRUFEWSBlbmdhZ2VkIGludG86IGRhdGFwbGFuZXMgYW5kDQo+Pj4+PiAgIHBh cmFkaWdtcy4gQXMgSSBtZW50aW9uZWQgaW4gbXkgY2hhcnRlciBwcm9wb3NhbCwgd2UgZG8gaGF2 ZQ0KPj4+Pj4gICBpbXBsZW1lbnRhdGlvbnMgYW5kIG11bHRpLXZlbmRvciBpbnRlcm9wZXJhYmls aXR5IHRlc3RzIHdpbGwNCj4+Pj4+ICAgaGFwcGVuIHNvb24uIFNvLCBJIGp1c3Qgd2FudCB0byBi ZSBzdXJlIHdlIGRvbid0IGlnbm9yZSB0aGlzDQo+Pj4+PiAgIHJlYWxpdHkuDQo+Pj4+PiANCj4+ Pj4+ICAgTVBMUyBhbmQgdjYgZGF0YS1wbGFuZSBhcmUgcGFydCBvZiB0aGlzIHJlYWxpdHksIGFz IHdlbGwgYXMNCj4+Pj4+ICAgdHVubmVsLWJhc2VkIGFuZCBub24tdHVubmVsIGJhc2VkIGFwcHJv YWNoZXMuDQo+Pj4+IA0KPj4+PiBJIGRvbid0IHRoaW5rIGl0J3Mgc3VpdGFibGUgdG8gbWVudGlv biBkZXZlbG9waW5nIElQdjYgc3BlY2lmaWMgU1IgbWVjaGFuaXNtIGluDQo+Pj4gdGhlIGN1cnJl bnQgY2hhcnRlciB1bmxlc3MgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFueSBjaGFuZ2Ug dG8gdGhlIGV4aXN0aW5nDQo+Pj4gSVB2NiBkYXRhIHBsYW5lLg0KPj4+IA0KPj4+PiBBY2NvcmRp bmcgdG8gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIHF1b3RlZCBmcm9tDQo+Pj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmlsc2ZpbHMtcnRnd2ctc2VnbWVudC1yb3V0aW5nLTAw I3BhZ2UtOSwgIi4uLlRoZQ0KPj4+IHNvdXJjZSByb3V0ZSBpcyBlbmNvZGVkIGFzIGFuIG9yZGVy ZWQgbGlzdCBvZiBzZWdtZW50cyBpbnN0ZWFkIG9mIElQIGFkZHJlc3Nlcy4uLiINCj4+PiBJZiBz bywgd2h5IG5vdCBkaXJlY3RseSB1c2UgYW4gb3JkZXJlZCBsaXN0IG9mIGxhYmVscyAoaS5lLiwg TVBMUyBsYWJlbCBzdGFjaykgdG8gZG8NCj4+PiB0aGF0IChzZWUNCj4+PiBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc3RhdHVzL2N1cnJlbnQvbXNnMDAxNjUuaHRtbCk/DQo+ Pj4gDQo+Pj4gDQo+Pj4gdjYgZGF0YXBsYW5lIGFsbG93cyBtb3JlIGVmZmVjdGl2ZSBzb3VyY2Ug cm91dGUgY2FwYWJpbGl0eSBieQ0KPj4+IGxldmVyYWdpbmcgZXh0ZW5zaW9ucyBoZWFkZXJzLiBI ZW5jZSB0aGUgcHJvcG9zYWwgdGhhdCB3aWxsDQo+Pj4gY29uc2lzdCBvZiBkZWZpbmluZyBhIG5l dyBFeHRlbnNpb24gSGVhZGVyIGZvciBTUiB3aGVyZSB0aGUNCj4+PiBzZWdtZW50IGxpc3QgaXMg ZW5jb2RlZCBhbmQgX3ByZXNlcnZlZF8gdGhyb3VnaG91dCB0aGUgcGF0aC4NCj4+IA0KPj4gV2hh dCdzIHRoZSBwdXJwb3NlIG9mIHByZXNlcnZpbmcgdGhlIHdob2xlIHNlZ21lbnQgbGlzdCB0aHJv dWdob3V0IHRoZSBwYXRoPyBJbiBvdGhlciB3b3JkcywgaXNuJ3QgaXQgZW5vdWdoIHRvIGNvbnRh aW4gdGhlIGluZm9ybWF0aW9uIG9mIGluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyB0aHJvdWdob3V0 IHRoZSBwYXRoPw0KPiANCj4gDQo+IHRoZXJlIGFyZSB1c2UgY2FzZXMsIGFtb25nIHdoaWNoIE9B TSwgdGhhdCB3aWxsIGxldmVyYWdlIHRoZSANCj4gYXZhaWxhYmlsaXR5IG9mIHRoZSBzZWdtZW50 IGxpc3QuIHY2IGhhcyBnb29kIG5hdGl2ZSBwcm9wZXJ0aWVzIA0KPiB0aGF0IGFsbG93IHRvIGlu c2VydCBleHBsaWNpdC9zb3VyY2Ugcm91dGluZyBwYXJhZGlnbXMgaW4gdGhlIA0KPiBmb3J3YXJk aW5nIHBsYW5lLiBNb3N0IG9mIFNXL0hXIGltcGxlbWVudGF0aW9ucyB0b2RheSBjYW4gaGFuZGxl IA0KPiB0aGlzIHdpdGhvdXQgaW5jdXJyaW5nIEhXIHBlcmZvcm1hbmNlIHBlbmFsdHkuDQo+IA0K PiBUaGFua3MuDQo+IHMuDQo+IA0KPiANCj4+IA0KPj4gQmVzdCByZWdhcmRzLA0KPj4gWGlhb2h1 DQo+PiANCj4+PiBTbywgSSBkbyBzdHJvbmdseSBiZWxpZXZlIHdlIGhhdmUgdG8gd29yayBvbiB2 NiBhbmQgc2luY2Ugd2UncmUNCj4+PiBpbiB0aGUgZGVmaW5pdGlvbiBvZiBhIGNoYXJ0ZXIgKGku ZS46IG5vdCB0aGUgZGV0YWlsZWQgcmV2aWV3DQo+Pj4gb2YgdGhlIHNvbHV0aW9ucykgSSBiZWxp ZXZlIHY2IHNob3VsZCBiZSBwYXJ0IG9mIGl0Lg0KPj4+IA0KPj4+IFRoYW5rcy4NCj4+PiBzLg0K Pj4+IA0KPj4+IA0KPj4+PiANCj4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KPj4+PiBUaGUgbWFpbiBkaWZmZXJlbmNlcyBmcm9tIHRoZSBJUHY2IHNvdXJj ZSByb3V0ZSBtb2RlbCBhcmU6DQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IEZpbHNmaWxzLCBl dCBhbC4gICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMzAsIDIwMTMgICAgICAgICAgICAgICBbUGFn ZSA5XQ0KPj4+PiANCj4+Pj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBTZWdtZW50IFJv dXRpbmcgICAgICAgICAgICAgICAgICAgSnVuZQ0KPj4+IDIwMTMNCj4+Pj4gDQo+Pj4+IA0KPj4+ PiAgICBUaGUgc291cmNlIHJvdXRlIGlzIGVuY29kZWQgYXMgYW4gb3JkZXJlZCBsaXN0IG9mIHNl Z21lbnRzIGluc3RlYWQNCj4+Pj4gICAgb2YgSVAgYWRkcmVzc2VzLg0KPj4+PiANCj4+Pj4gICAg QSBzZWdtZW50IGNhbiByZXByZXNlbnQgYW55IGluc3RydWN0aW9uIGVpdGhlciBhIHNlcnZpY2Ug b3IgYQ0KPj4+PiAgICB0b3BvbG9naWNhbCBwYXRoLiAgVG9wb2xvZ2ljYWxseSwgdGhlIHBhdGgg dG8gYW4gSVAgYWRkcmVzcyBpcw0KPj4+PiAgICBvZnRlbiBsaW1pdGVkIHRvIHRoZSBzaG9ydGVz dC1wYXRoIHRvIHRoYXQgYWRkcmVzcy4gIEEgc2VnbWVudCBjYW4NCj4+Pj4gICAgcmVwcmVzZW50 IGFueSBwYXRoIChlLmcuIGFuIGFkamFjZW5jeSBzZWdtZW50IGZvcmNlcyBhIHBhY2tldCB0byBh DQo+Pj4+ICAgIG5leHRob3AgdGhyb3VnaCBhIHNwZWNpZmljIGFkamFjZW5jeSBldmVuIGlmIHRo ZSBzaG9ydGVzdC1wYXRoIHRvDQo+Pj4+ICAgIHRoZSBuZXh0LWhvcCBkb2VzIG5vdCB1c2UgdGhh dCBhZGphY2VuY3kpLg0KPj4+PiANCj4+Pj4gICAgVGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBlZ2Rl IHJvdXRlcnMgYXJlIGlkZW50aWZpZWQgYW5kIGFsd2F5cw0KPj4+PiAgICBhdmFpbGFibGUsIGFs bG93aW5nIGZvciBpbnRlcmVzdGluZyBhY2NvdW50aW5nIGFuZCBwb2xpY3kNCj4+Pj4gICAgYXBw bGljYXRpb25zLg0KPj4+PiANCj4+Pj4gICAgVGhlIHNvdXJjZSByb3V0ZSBmdW5jdGlvbmFsaXR5 IGNhbm5vdCBiZSBjb250cm9sbGVkIGZyb20gb3V0c2lkZQ0KPj4+PiAgICB0aGUgU1IgZG9tYWlu Lg0KPj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pj4+ IA0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+IFhpYW9odQ0KPj4+IA0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc3RhdHVzIG1haWxpbmcg bGlzdA0KPj4+IHN0YXR1c0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3RhdHVzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+IHN0YXR1c0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0YXR1cyBtYWlsaW5n IGxpc3QNCnN0YXR1c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zdGF0dXMNCg== From jdrake@juniper.net Thu Sep 12 09:45:32 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1198621E80C8 for ; Thu, 12 Sep 2013 09:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.943 X-Spam-Level: X-Spam-Status: No, score=0.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CakQaMQiRuPe for ; Thu, 12 Sep 2013 09:45:13 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5B75511E81A8 for ; Thu, 12 Sep 2013 09:45:03 -0700 (PDT) Received: from mail224-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 12 Sep 2013 16:45:02 +0000 Received: from mail224-va3 (localhost [127.0.0.1]) by mail224-va3-R.bigfish.com (Postfix) with ESMTP id 772D3700225; Thu, 12 Sep 2013 16:45:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic89bh542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h941hd24hf0ah1269h1288h12a5h12a9h12bdh12e1h137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail224-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(13464003)(51704005)(199002)(189002)(24454002)(80976001)(19580395003)(69226001)(46102001)(65816001)(49866001)(50986001)(47976001)(47736001)(83322001)(19580405001)(81542001)(561944002)(33646001)(4396001)(54316002)(56776001)(81342001)(66066001)(54356001)(15975445006)(74706001)(74366001)(31966008)(74876001)(81816001)(47446002)(74502001)(74662001)(79102001)(63696002)(56816003)(77096001)(76576001)(74316001)(77982001)(59766001)(15202345003)(80022001)(76786001)(76796001)(76482001)(83072001)(81686001)(53806001)(51856001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.50; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail224-va3 (localhost.localdomain [127.0.0.1]) by mail224-va3 (MessageSwitch) id 1379004223411111_15149; Thu, 12 Sep 2013 16:43:43 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.249]) by mail224-va3.bigfish.com (Postfix) with ESMTP id 5FAAF740057; Thu, 12 Sep 2013 16:43:43 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 12 Sep 2013 16:43:42 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 12 Sep 2013 16:43:40 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 12 Sep 2013 16:43:37 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.224]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.224]) with mapi id 15.00.0745.000; Thu, 12 Sep 2013 16:43:37 +0000 From: John E Drake To: AshwoodsmithPeter , "status@ietf.org" Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrtsJ2l2pO7IzQkaX2N7UOeUQgpnBUOkAgAC80ICAACTVQIAAFF2AgAAIFAA= Date: Thu, 12 Sep 2013 16:43:36 +0000 Message-ID: <19a973e7a0fa40ce8b0a549d1db1eb53@BY2PR05MB142.namprd05.prod.outlook.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com>, <76C1435B-763F-4672-8F69-D12D80A12E31@juniper.net> <7AE6A4247B044C4ABE0A5B6BF427F8E2099012FA@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E2099012FA@dfweml513-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] x-forefront-prvs: 0967749BC1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 16:45:33 -0000 UGV0ZXIsDQoNCkkgY2FuIHRoaW5rIG9mIGEgbGVhc3QgdGhyZWUgcmVhc29ucyB3aHkgdGhlcmUg d2lsbCBiZSBhIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgc291cmNlIHJvdXRlIGNvbXB1dGVkIGJ5 IHRoZSBpbmdyZXNzIGFuZCB0aGUgcm91dGUgYSBwYWNrZXQgYWN0dWFsbHkgdGFrZXMuICBWaXos IGEgdHJhbnNpdCBub2RlIGluY29ycmVjdGx5IHByb2Nlc3NlcyB0aGUgc291cmNlIHJvdXRlLCBh IHRyYW5zaXQgbm9kZSBwZXJmb3JtcyBmYXN0IHJlcm91dGUsIGFuZCBhIHRyYW5zaXQgbm9kZSBw ZXJmb3JtcyBsb29zZSByb3V0ZSBleHBhbnNpb24gd2hlbiB0aGUgc291cmNlIHJvdXRlIGNvbnRh aW5zIG9uZSBvciBtb3JlIG5vZGUgc2VnbWVudHMuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0K DQpKb2huDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc3RhdHVzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm DQo+IE9mIEFzaHdvb2RzbWl0aFBldGVyDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTIs IDIwMTMgOTowOCBBTQ0KPiBUbzogc3RhdHVzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU3Rh dHVzXSBHb29kIGNoYXJ0ZXIgcHJvcG9zYWxzIGZyb20gSGFubmVzIGFuZCBTdGVmYW5vIDogdHJ5 DQo+IHRvIG1lcmdlIC4uLg0KPiANCj4gU29ycnksIEpvaG4sIGRpZCBub3Qgc2VlIHlvdXIgcmVz cG9uc2UgYnV0IHdlJ3ZlIGJlZW4gaGF2aW5nIHNwYW0gZmlsdGVyDQo+IHByb2JsZW1zIGxhdGVs eSBoZXJlLg0KPiANCj4gTm8gZGlzYWdyZWVtZW50IHdpdGggIml0IGlzIG11Y2ggYmV0dGVyIHRv IGhhdmUgdGhlIHJvdXRlIGEgcGFja2V0IHRha2VzDQo+IHRocm91Z2ggYSBuZXR3b3JrIHRoYW4g dGhlIHJvdXRlIHRoZSBpbmdyZXNzIG5vZGUgdGhpbmtzIGl0IHdpbGwgdGFrZSINCj4gDQo+IEFs dGhvdWdoIHRoZSBkZXZpYXRpb25zIGZyb20gdGhlIGludGVuZGVkIHJvdXRlIG5lZWQgdG8gY29u dHJvbGxhYmxlDQo+IChvbi9vZmYpIHNvIHRoYXQgY2VudHJhbGl6ZWQgVEUgKCBsaWtlIFNETiB3 YW50cyB0byBkbyApIGNhbiBiZSBhc3N1cmVkIHRoYXQgaXRzDQo+IG1hdGggaXMgY29uc2lzdGVu dCB3aXRoIHdoYXQgaXMgcmVhbGx5IGhhcHBlbmluZyBpbiB0aGUgbmV0d29yay4NCj4gDQo+IENo ZWVycywNCj4gDQo+IFBldGVyDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj4gT2YgSm9obiBFIERyYWtlDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0 ZW1iZXIgMTIsIDIwMTMgMTA6NTYgQU0NCj4gVG86IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkp DQo+IENjOiBTdGVwaGFuZSBMaXRrb3dza2k7IFh1eGlhb2h1OyBSb2IgU2hha2lyOyBzdGF0dXNA aWV0Zi5vcmc7IEhhbm5lcw0KPiBHcmVkbGVyDQo+IFN1YmplY3Q6IFJlOiBbU3RhdHVzXSBHb29k IGNoYXJ0ZXIgcHJvcG9zYWxzIGZyb20gSGFubmVzIGFuZCBTdGVmYW5vIDogdHJ5DQo+IHRvIG1l cmdlIC4uLg0KPiANCj4gU3RlZmFubywNCj4gDQo+IEFzIEkgcG9pbnRlZCBvdXQgdG8gUGV0ZXIg bGFzdCB3ZWVrLCBpdCBpcyBtdWNoIGJldHRlciB0byBoYXZlIHRoZSByb3V0ZSBhDQo+IHBhY2tl dCB0YWtlcyB0aHJvdWdoIGEgbmV0d29yayB0aGFuIHRoZSByb3V0ZSB0aGUgaW5ncmVzcyBub2Rl IHRoaW5rcyBpdCB3aWxsDQo+IHRha2UuICBGdXJ0aGVyLCBpZiB0aGUgbGF0dGVyIGlzIHVzZWQg aW4gY29uanVuY3Rpb24gd2l0aCBub2RhbCBzZWdtZW50cywgdGhlbg0KPiBhbGwgeW91IHdpbGwg aGF2ZSBpcyBhIGxvb3NlIHNvdXJjZSByb3V0ZS4NCj4gDQo+IFNlbnQgZnJvbSBteSBpUGhvbmUN Cj4gDQo+IE9uIFNlcCAxMiwgMjAxMywgYXQgNTo0NCBBTSwgIlN0ZWZhbm8gUHJldmlkaSAoc3By ZXZpZGkpIg0KPiA8c3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+ID4gSGkgWGlhb2h1 LA0KPiA+DQo+ID4gT24gU2VwIDEyLCAyMDEzLCBhdCAzOjI3IEFNLCBYdXhpYW9odSB3cm90ZToN Cj4gPj4gSGkgU3RlZmFubywNCj4gPj4NCj4gPj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4g t6K8/sjLOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGll dGYub3JnXSC0+rHtDQo+ID4+PiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPiA+Pj4gt6LL zcqxvOQ6IDIwMTPE6jnUwjExyNUgMTg6MzgNCj4gPj4+IMrVvP7IyzogWHV4aWFvaHUNCj4gPj4+ ILOty806IFN0ZXBoYW5lIExpdGtvd3NraTsgUm9iIFNoYWtpcjsgc3RhdHVzQGlldGYub3JnOyBI YW5uZXMgR3JlZGxlcg0KPiA+Pj4g1vfM4jogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9w b3NhbHMgZnJvbSBIYW5uZXMgYW5kIFN0ZWZhbm8gOg0KPiA+Pj4gdHJ5IHRvIG1lcmdlIC4uLg0K PiA+Pj4NCj4gPj4+IEhpIFhpYW9odSwNCj4gPj4+DQo+ID4+PiBPbiBTZXAgMTEsIDIwMTMsIGF0 IDQ6MTQgQU0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0t08q8/tStvP4t LS0tLQ0KPiA+Pj4+PiC3orz+yMs6IHN0YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c3Rh dHVzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gPj4+Pj4gU3RlZmFubyBQcmV2aWRpIChzcHJl dmlkaSkNCj4gPj4+Pj4gt6LLzcqxvOQ6IDIwMTPE6jnUwjExyNUgMDo1OA0KPiA+Pj4+PiDK1bz+ yMs6IFN0ZXBoYW5lIExpdGtvd3NraQ0KPiA+Pj4+PiCzrcvNOiBIYW5uZXMgR3JlZGxlcjsgUm9i IFNoYWtpcjsgc3RhdHVzQGlldGYub3JnDQo+ID4+Pj4+INb3zOI6IFJlOiBbU3RhdHVzXSBHb29k IGNoYXJ0ZXIgcHJvcG9zYWxzIGZyb20gSGFubmVzIGFuZCBTdGVmYW5vIDoNCj4gPj4+Pj4gdHJ5 IHRvIG1lcmdlIC4uLg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiBTZXAgMTAsIDIwMTMs IGF0IDE6MjUgUE0sIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCj4gd3JvdGU6DQo+ ID4+Pj4+DQo+ID4+Pj4+PiBBZ3JlZSBvbiBhbGwgcHJvcG9zYWwgZXhjZXB0IDoNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiAiW1NQXSBUaGUgYXJjaGl0ZWN0dXJlIHdpbGwgc3VwcG9ydCB0dW5uZWwgYW5k IG5vbi10dW5uZWwNCj4gPj4+Pj4+IHBhcmFkaWdtcyAgVGhlIGFyY2hpdGVjdHVyZSB3aWxsIHN1 cHBvcnQgbXVsdGlwbGUgZGF0YXBsYW5lczogTVBMUw0KPiBhbmQgVjYiDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gSSBkb24ndCBzZWUgdGhlIHJlYXNvbiBmb3IgdGhpcyAuLi4gSU1ITywgdGhlIGdhcCBh bmFseXNpcyBhbmQNCj4gPj4+Pj4+IHJlcXVpcmVtZW50cw0KPiA+Pj4+PiBpbnZlbnRvcnkgd2ls bCByZXN1bHQgb24gc2F5aW5nIG9yIG5vdA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBbU1Bd IFdoaWxlIEkgdW5kZXJzdGFuZCB3aGF0IGJyb3VnaHQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRz DQo+ID4+Pj4+ICAgaW4gdGhlIHByb3Bvc2VkIGNoYXJ0ZXI6DQo+ID4+Pj4+ICAgICJIYXZpbmcg aWRlbnRpZmllZCB1c2UtY2FzZXMsIGFyY2hpdGVjdHVyZSBhbmQgc2VjdXJpdHksDQo+ID4+Pj4+ ICAgICB0aGUgV0cgd2lsbCBpZGVudGlmeSBnYXBzIGJldHdlZW4gY3VycmVudGx5IGF2YWlsYWJs ZQ0KPiA+Pj4+PiAgICAgdGVjaG5vbG9naWVzIGFuZCB1c2UtY2FzZSByZXF1aXJlbWVudHMuDQo+ ID4+Pj4+ICAgICBUaGUgV0cgd2lsbCB0aGVuIGRlZmluZSByZXF1aXJlbWVudHMgZm9yIGV4dGVu c2lvbnMgdG8NCj4gPj4+Pj4gICAgIGV4aXN0aW5nIHByb3RvY29scyBvciBuZXcgcHJvdG9jb2xz IHRoYXQgYWRkcmVzcyBnYXBzDQo+ID4+Pj4+ICAgICB0aGF0IGFyZSBpZGVudGlmaWVkLiINCj4g Pj4+Pj4NCj4gPj4+Pj4gICBJJ2QgbGlrZSB0byBwb2ludCBvdXQgd2l0aCBiZXR0ZXIgcHJlY2lz aW9uIHdoYXQgYXJlIHRoZQ0KPiA+Pj4+PiAgIGRpcmVjdGlvbnMgd2UgYXJlIEFMUkVBRFkgZW5n YWdlZCBpbnRvOiBkYXRhcGxhbmVzIGFuZA0KPiA+Pj4+PiAgIHBhcmFkaWdtcy4gQXMgSSBtZW50 aW9uZWQgaW4gbXkgY2hhcnRlciBwcm9wb3NhbCwgd2UgZG8gaGF2ZQ0KPiA+Pj4+PiAgIGltcGxl bWVudGF0aW9ucyBhbmQgbXVsdGktdmVuZG9yIGludGVyb3BlcmFiaWxpdHkgdGVzdHMgd2lsbA0K PiA+Pj4+PiAgIGhhcHBlbiBzb29uLiBTbywgSSBqdXN0IHdhbnQgdG8gYmUgc3VyZSB3ZSBkb24n dCBpZ25vcmUgdGhpcw0KPiA+Pj4+PiAgIHJlYWxpdHkuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgTVBM UyBhbmQgdjYgZGF0YS1wbGFuZSBhcmUgcGFydCBvZiB0aGlzIHJlYWxpdHksIGFzIHdlbGwgYXMN Cj4gPj4+Pj4gICB0dW5uZWwtYmFzZWQgYW5kIG5vbi10dW5uZWwgYmFzZWQgYXBwcm9hY2hlcy4N Cj4gPj4+Pg0KPiA+Pj4+IEkgZG9uJ3QgdGhpbmsgaXQncyBzdWl0YWJsZSB0byBtZW50aW9uIGRl dmVsb3BpbmcgSVB2NiBzcGVjaWZpYyBTUg0KPiA+Pj4+IG1lY2hhbmlzbSBpbg0KPiA+Pj4gdGhl IGN1cnJlbnQgY2hhcnRlciB1bmxlc3MgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFueSBj aGFuZ2UgdG8NCj4gPj4+IHRoZSBleGlzdGluZw0KPiA+Pj4gSVB2NiBkYXRhIHBsYW5lLg0KPiA+ Pj4NCj4gPj4+PiBBY2NvcmRpbmcgdG8gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIHF1b3RlZCBm cm9tDQo+ID4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maWxzZmlscy1ydGd3 Zy1zZWdtZW50LXJvdXRpbmctMDAjcA0KPiA+Pj4gYWdlLTksICIuLi5UaGUgc291cmNlIHJvdXRl IGlzIGVuY29kZWQgYXMgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzDQo+IGluc3RlYWQgb2Yg SVAgYWRkcmVzc2VzLi4uIg0KPiA+Pj4gSWYgc28sIHdoeSBub3QgZGlyZWN0bHkgdXNlIGFuIG9y ZGVyZWQgbGlzdCBvZiBsYWJlbHMgKGkuZS4sIE1QTFMNCj4gPj4+IGxhYmVsIHN0YWNrKSB0byBk byB0aGF0IChzZWUNCj4gPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9z dGF0dXMvY3VycmVudC9tc2cwMDE2NS5odG1sKT8NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gdjYgZGF0 YXBsYW5lIGFsbG93cyBtb3JlIGVmZmVjdGl2ZSBzb3VyY2Ugcm91dGUgY2FwYWJpbGl0eSBieQ0K PiA+Pj4gbGV2ZXJhZ2luZyBleHRlbnNpb25zIGhlYWRlcnMuIEhlbmNlIHRoZSBwcm9wb3NhbCB0 aGF0IHdpbGwgY29uc2lzdA0KPiA+Pj4gb2YgZGVmaW5pbmcgYSBuZXcgRXh0ZW5zaW9uIEhlYWRl ciBmb3IgU1Igd2hlcmUgdGhlIHNlZ21lbnQgbGlzdCBpcw0KPiA+Pj4gZW5jb2RlZCBhbmQgX3By ZXNlcnZlZF8gdGhyb3VnaG91dCB0aGUgcGF0aC4NCj4gPj4NCj4gPj4gV2hhdCdzIHRoZSBwdXJw b3NlIG9mIHByZXNlcnZpbmcgdGhlIHdob2xlIHNlZ21lbnQgbGlzdCB0aHJvdWdob3V0IHRoZQ0K PiBwYXRoPyBJbiBvdGhlciB3b3JkcywgaXNuJ3QgaXQgZW5vdWdoIHRvIGNvbnRhaW4gdGhlIGlu Zm9ybWF0aW9uIG9mIGluZ3Jlc3MNCj4gYW5kIGVncmVzcyBub2RlcyB0aHJvdWdob3V0IHRoZSBw YXRoPw0KPiA+DQo+ID4NCj4gPiB0aGVyZSBhcmUgdXNlIGNhc2VzLCBhbW9uZyB3aGljaCBPQU0s IHRoYXQgd2lsbCBsZXZlcmFnZSB0aGUNCj4gPiBhdmFpbGFiaWxpdHkgb2YgdGhlIHNlZ21lbnQg bGlzdC4gdjYgaGFzIGdvb2QgbmF0aXZlIHByb3BlcnRpZXMgdGhhdA0KPiA+IGFsbG93IHRvIGlu c2VydCBleHBsaWNpdC9zb3VyY2Ugcm91dGluZyBwYXJhZGlnbXMgaW4gdGhlIGZvcndhcmRpbmcN Cj4gPiBwbGFuZS4gTW9zdCBvZiBTVy9IVyBpbXBsZW1lbnRhdGlvbnMgdG9kYXkgY2FuIGhhbmRs ZSB0aGlzIHdpdGhvdXQNCj4gPiBpbmN1cnJpbmcgSFcgcGVyZm9ybWFuY2UgcGVuYWx0eS4NCj4g Pg0KPiA+IFRoYW5rcy4NCj4gPiBzLg0KPiA+DQo+ID4NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRz LA0KPiA+PiBYaWFvaHUNCj4gPj4NCj4gPj4+IFNvLCBJIGRvIHN0cm9uZ2x5IGJlbGlldmUgd2Ug aGF2ZSB0byB3b3JrIG9uIHY2IGFuZCBzaW5jZSB3ZSdyZSBpbg0KPiA+Pj4gdGhlIGRlZmluaXRp b24gb2YgYSBjaGFydGVyIChpLmUuOiBub3QgdGhlIGRldGFpbGVkIHJldmlldyBvZiB0aGUNCj4g Pj4+IHNvbHV0aW9ucykgSSBiZWxpZXZlIHY2IHNob3VsZCBiZSBwYXJ0IG9mIGl0Lg0KPiA+Pj4N Cj4gPj4+IFRoYW5rcy4NCj4gPj4+IHMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPj4+PiBUaGUgbWFp biBkaWZmZXJlbmNlcyBmcm9tIHRoZSBJUHY2IHNvdXJjZSByb3V0ZSBtb2RlbCBhcmU6DQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gRmlsc2ZpbHMsIGV0IGFsLiAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAzMCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDldDQo+ID4+Pj4NCj4gPj4+ PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIFNlZ21lbnQgUm91dGluZyAgICAgICAgICAg ICAgICAgICBKdW5lDQo+ID4+PiAyMDEzDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ICAgIFRoZSBz b3VyY2Ugcm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVkIGxpc3Qgb2Ygc2VnbWVudHMgaW5z dGVhZA0KPiA+Pj4+ICAgIG9mIElQIGFkZHJlc3Nlcy4NCj4gPj4+Pg0KPiA+Pj4+ICAgIEEgc2Vn bWVudCBjYW4gcmVwcmVzZW50IGFueSBpbnN0cnVjdGlvbiBlaXRoZXIgYSBzZXJ2aWNlIG9yIGEN Cj4gPj4+PiAgICB0b3BvbG9naWNhbCBwYXRoLiAgVG9wb2xvZ2ljYWxseSwgdGhlIHBhdGggdG8g YW4gSVAgYWRkcmVzcyBpcw0KPiA+Pj4+ICAgIG9mdGVuIGxpbWl0ZWQgdG8gdGhlIHNob3J0ZXN0 LXBhdGggdG8gdGhhdCBhZGRyZXNzLiAgQSBzZWdtZW50IGNhbg0KPiA+Pj4+ICAgIHJlcHJlc2Vu dCBhbnkgcGF0aCAoZS5nLiBhbiBhZGphY2VuY3kgc2VnbWVudCBmb3JjZXMgYSBwYWNrZXQgdG8g YQ0KPiA+Pj4+ICAgIG5leHRob3AgdGhyb3VnaCBhIHNwZWNpZmljIGFkamFjZW5jeSBldmVuIGlm IHRoZSBzaG9ydGVzdC1wYXRoIHRvDQo+ID4+Pj4gICAgdGhlIG5leHQtaG9wIGRvZXMgbm90IHVz ZSB0aGF0IGFkamFjZW5jeSkuDQo+ID4+Pj4NCj4gPj4+PiAgICBUaGUgaW5ncmVzcyBhbmQgZWdy ZXNzIGVnZGUgcm91dGVycyBhcmUgaWRlbnRpZmllZCBhbmQgYWx3YXlzDQo+ID4+Pj4gICAgYXZh aWxhYmxlLCBhbGxvd2luZyBmb3IgaW50ZXJlc3RpbmcgYWNjb3VudGluZyBhbmQgcG9saWN5DQo+ ID4+Pj4gICAgYXBwbGljYXRpb25zLg0KPiA+Pj4+DQo+ID4+Pj4gICAgVGhlIHNvdXJjZSByb3V0 ZSBmdW5jdGlvbmFsaXR5IGNhbm5vdCBiZSBjb250cm9sbGVkIGZyb20gb3V0c2lkZQ0KPiA+Pj4+ ICAgIHRoZSBTUiBkb21haW4uDQo+ID4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKg0KPiA+Pj4+DQo+ID4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+IFhpYW9o dQ0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+ID4+PiBzdGF0dXNAaWV0Zi5vcmcN Cj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RhdHVzDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IHN0YXR1cyBtYWlsaW5nIGxpc3QNCj4gPiBzdGF0dXNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+IHN0 YXR1c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0 YXR1cw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+IHN0YXR1c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0K From Peter.AshwoodSmith@huawei.com Thu Sep 12 12:47:09 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5111E81E3 for ; Thu, 12 Sep 2013 12:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4xoqZP3ROJj for ; Thu, 12 Sep 2013 12:47:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B311E81A8 for ; Thu, 12 Sep 2013 12:47:03 -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.5-GA FastPath queued) with ESMTP id AXG58060; Thu, 12 Sep 2013 19:47:02 +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.146.0; Thu, 12 Sep 2013 20:46:46 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 12 Sep 2013 20:47:00 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Thu, 12 Sep 2013 12:46:52 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Good charter proposals from Hannes and Stefano : try to merge ... Thread-Index: AQHOrgLCe3ehZT3wb0SYcUxDJhSIm5m/AXKAgAAD6wCAABPUAP//uVuAgACzLACAAJtuAIAAjIYAgAD4wACAALzSgIAARlkA//+Q10CAAI1YAP//n7ZQ Date: Thu, 12 Sep 2013 19:46:52 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2099014A1@dfweml513-mbb.china.huawei.com> References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com>, <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820EB2A@NKGEML512-MBS.china.huawei.com>, <76C1435B-763F-4672-8F69-D12D80A12E31@juniper.net> <7AE6A4247B044C4ABE0A5B6BF427F8E2099012FA@dfweml513-mbb.china.huawei.com> <19a973e7a0fa40ce8b0a549d1db1eb53@BY2PR05MB142.namprd05.prod.outlook.com> In-Reply-To: <19a973e7a0fa40ce8b0a549d1db1eb53@BY2PR05MB142.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.162] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 19:47:09 -0000 Sm9obiwgeWVzIGFncmVlLCANCg0KVGhlICdpbmNvcnJlY3QgZm9yd2FyZGluZycgb25lIGlzIGlu dGVyZXN0aW5nIGJlY2F1c2UgeW91IGNhbiBnbyBhIGxvbmcgd2F5IGJlZm9yZSB0aGUgZXJyb3Ig aXMgZm91bmQgd2hlbiB0aGUgaG9wcyBhcmUgc3RyaWN0IGxvY2FsIGxpbmsgaWRlbnRpZmllcnMu IEhvd2V2ZXIgaXQncyBwb3NzaWJsZSB0byBkbyBhIGZvcm0gb2YgcmV2ZXJzZSBzZWdtZW50IGNo ZWNrIHRvIG1pbmltaXplIHRoZXNlIGVycm9ycyBpZiB5b3UgYXJlIHJlY29yZGluZyBhdCBsZWFz dCB0aGUgcHJldmlvdXMgaG9wIGJ1dCBpdCdzIG5vdCBmb29scHJvb2Ygb2YgY291cnNlLg0KDQpB bnl3YXkgLSByZXZlcnNhbCBpcyB1c2VmdWwsIHJlY29yZGluZyByZXZlcnNlIG9mIHdoZXJlIHlv dSd2ZSBhY3R1YWxseSBiZWVuIGlzIHVzZWZ1bCwgZm9yY2luZyBhZGhlcmVuY2UgdG8gdGhlIGlu Z3Jlc3Mgbm9kZSdzIFNSIGlzIHVzZWZ1bCwgYnV0IHNvIGlzIGFsbG93aW5nIGEgZGVncmVlIG9m IGZsZXhpYmlsaXR5IGZvciBmYXN0IHJlcm91dGUgLyBsb29zZSBob3BzLg0KDQpDaGVlcnMsDQoN ClBldGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIEUgRHJha2Ug W21haWx0bzpqZHJha2VAanVuaXBlci5uZXRdIA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAx MiwgMjAxMyAxMjo0NCBQTQ0KVG86IEFzaHdvb2RzbWl0aFBldGVyOyBzdGF0dXNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJFOiBbU3RhdHVzXSBHb29kIGNoYXJ0ZXIgcHJvcG9zYWxzIGZyb20gSGFubmVz IGFuZCBTdGVmYW5vIDogdHJ5IHRvIG1lcmdlIC4uLg0KDQpQZXRlciwNCg0KSSBjYW4gdGhpbmsg b2YgYSBsZWFzdCB0aHJlZSByZWFzb25zIHdoeSB0aGVyZSB3aWxsIGJlIGEgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSBzb3VyY2Ugcm91dGUgY29tcHV0ZWQgYnkgdGhlIGluZ3Jlc3MgYW5kIHRoZSBy b3V0ZSBhIHBhY2tldCBhY3R1YWxseSB0YWtlcy4gIFZpeiwgYSB0cmFuc2l0IG5vZGUgaW5jb3Jy ZWN0bHkgcHJvY2Vzc2VzIHRoZSBzb3VyY2Ugcm91dGUsIGEgdHJhbnNpdCBub2RlIHBlcmZvcm1z IGZhc3QgcmVyb3V0ZSwgYW5kIGEgdHJhbnNpdCBub2RlIHBlcmZvcm1zIGxvb3NlIHJvdXRlIGV4 cGFuc2lvbiB3aGVuIHRoZSBzb3VyY2Ugcm91dGUgY29udGFpbnMgb25lIG9yIG1vcmUgbm9kZSBz ZWdtZW50cy4NCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoNCkpvaG4NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnN0YXR1cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgQXNod29vZHNtaXRoUGV0 ZXINCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMiwgMjAxMyA5OjA4IEFNDQo+IFRvOiBz dGF0dXNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9w b3NhbHMgZnJvbSBIYW5uZXMgYW5kIFN0ZWZhbm8gOiB0cnkNCj4gdG8gbWVyZ2UgLi4uDQo+IA0K PiBTb3JyeSwgSm9obiwgZGlkIG5vdCBzZWUgeW91ciByZXNwb25zZSBidXQgd2UndmUgYmVlbiBo YXZpbmcgc3BhbSBmaWx0ZXINCj4gcHJvYmxlbXMgbGF0ZWx5IGhlcmUuDQo+IA0KPiBObyBkaXNh Z3JlZW1lbnQgd2l0aCAiaXQgaXMgbXVjaCBiZXR0ZXIgdG8gaGF2ZSB0aGUgcm91dGUgYSBwYWNr ZXQgdGFrZXMNCj4gdGhyb3VnaCBhIG5ldHdvcmsgdGhhbiB0aGUgcm91dGUgdGhlIGluZ3Jlc3Mg bm9kZSB0aGlua3MgaXQgd2lsbCB0YWtlIg0KPiANCj4gQWx0aG91Z2ggdGhlIGRldmlhdGlvbnMg ZnJvbSB0aGUgaW50ZW5kZWQgcm91dGUgbmVlZCB0byBjb250cm9sbGFibGUNCj4gKG9uL29mZikg c28gdGhhdCBjZW50cmFsaXplZCBURSAoIGxpa2UgU0ROIHdhbnRzIHRvIGRvICkgY2FuIGJlIGFz c3VyZWQgdGhhdCBpdHMNCj4gbWF0aCBpcyBjb25zaXN0ZW50IHdpdGggd2hhdCBpcyByZWFsbHkg aGFwcGVuaW5nIGluIHRoZSBuZXR3b3JrLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gUGV0ZXINCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHN0YXR1cy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBK b2huIEUgRHJha2UNCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMiwgMjAxMyAxMDo1NiBB TQ0KPiBUbzogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4gQ2M6IFN0ZXBoYW5lIExpdGtv d3NraTsgWHV4aWFvaHU7IFJvYiBTaGFraXI7IHN0YXR1c0BpZXRmLm9yZzsgSGFubmVzDQo+IEdy ZWRsZXINCj4gU3ViamVjdDogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9wb3NhbHMgZnJv bSBIYW5uZXMgYW5kIFN0ZWZhbm8gOiB0cnkNCj4gdG8gbWVyZ2UgLi4uDQo+IA0KPiBTdGVmYW5v LA0KPiANCj4gQXMgSSBwb2ludGVkIG91dCB0byBQZXRlciBsYXN0IHdlZWssIGl0IGlzIG11Y2gg YmV0dGVyIHRvIGhhdmUgdGhlIHJvdXRlIGENCj4gcGFja2V0IHRha2VzIHRocm91Z2ggYSBuZXR3 b3JrIHRoYW4gdGhlIHJvdXRlIHRoZSBpbmdyZXNzIG5vZGUgdGhpbmtzIGl0IHdpbGwNCj4gdGFr ZS4gIEZ1cnRoZXIsIGlmIHRoZSBsYXR0ZXIgaXMgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIG5v ZGFsIHNlZ21lbnRzLCB0aGVuDQo+IGFsbCB5b3Ugd2lsbCBoYXZlIGlzIGEgbG9vc2Ugc291cmNl IHJvdXRlLg0KPiANCj4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiANCj4gT24gU2VwIDEyLCAyMDEz LCBhdCA1OjQ0IEFNLCAiU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkiDQo+IDxzcHJldmlkaUBj aXNjby5jb20+IHdyb3RlOg0KPiANCj4gPiBIaSBYaWFvaHUsDQo+ID4NCj4gPiBPbiBTZXAgMTIs IDIwMTMsIGF0IDM6MjcgQU0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+PiBIaSBTdGVmYW5vLA0KPiA+ Pg0KPiA+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+PiC3orz+yMs6IHN0YXR1cy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gPj4+IFN0 ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpDQo+ID4+PiC3osvNyrG85DogMjAxM8TqOdTCMTHI1SAx ODozOA0KPiA+Pj4gytW8/sjLOiBYdXhpYW9odQ0KPiA+Pj4gs63LzTogU3RlcGhhbmUgTGl0a293 c2tpOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5vcmc7IEhhbm5lcyBHcmVkbGVyDQo+ID4+PiDW 98ziOiBSZTogW1N0YXR1c10gR29vZCBjaGFydGVyIHByb3Bvc2FscyBmcm9tIEhhbm5lcyBhbmQg U3RlZmFubyA6DQo+ID4+PiB0cnkgdG8gbWVyZ2UgLi4uDQo+ID4+Pg0KPiA+Pj4gSGkgWGlhb2h1 LA0KPiA+Pj4NCj4gPj4+IE9uIFNlcCAxMSwgMjAxMywgYXQgNDoxNCBBTSwgWHV4aWFvaHUgd3Jv dGU6DQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+Pj4+ILeivP7Iyzog c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9yZ10g tPqx7Q0KPiA+Pj4+PiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KPiA+Pj4+PiC3osvNyrG8 5DogMjAxM8TqOdTCMTHI1SAwOjU4DQo+ID4+Pj4+IMrVvP7IyzogU3RlcGhhbmUgTGl0a293c2tp DQo+ID4+Pj4+ILOty806IEhhbm5lcyBHcmVkbGVyOyBSb2IgU2hha2lyOyBzdGF0dXNAaWV0Zi5v cmcNCj4gPj4+Pj4g1vfM4jogUmU6IFtTdGF0dXNdIEdvb2QgY2hhcnRlciBwcm9wb3NhbHMgZnJv bSBIYW5uZXMgYW5kIFN0ZWZhbm8gOg0KPiA+Pj4+PiB0cnkgdG8gbWVyZ2UgLi4uDQo+ID4+Pj4+ DQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIFNlcCAxMCwgMjAxMywgYXQgMToyNSBQTSwgPHN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPg0KPiB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4+IEFncmVl IG9uIGFsbCBwcm9wb3NhbCBleGNlcHQgOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICJbU1BdIFRoZSBh cmNoaXRlY3R1cmUgd2lsbCBzdXBwb3J0IHR1bm5lbCBhbmQgbm9uLXR1bm5lbA0KPiA+Pj4+Pj4g cGFyYWRpZ21zICBUaGUgYXJjaGl0ZWN0dXJlIHdpbGwgc3VwcG9ydCBtdWx0aXBsZSBkYXRhcGxh bmVzOiBNUExTDQo+IGFuZCBWNiINCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJIGRvbid0IHNlZSB0aGUg cmVhc29uIGZvciB0aGlzIC4uLiBJTUhPLCB0aGUgZ2FwIGFuYWx5c2lzIGFuZA0KPiA+Pj4+Pj4g cmVxdWlyZW1lbnRzDQo+ID4+Pj4+IGludmVudG9yeSB3aWxsIHJlc3VsdCBvbiBzYXlpbmcgb3Ig bm90DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IFtTUF0gV2hpbGUgSSB1bmRlcnN0YW5kIHdo YXQgYnJvdWdodCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMNCj4gPj4+Pj4gICBpbiB0aGUgcHJv cG9zZWQgY2hhcnRlcjoNCj4gPj4+Pj4gICAgIkhhdmluZyBpZGVudGlmaWVkIHVzZS1jYXNlcywg YXJjaGl0ZWN0dXJlIGFuZCBzZWN1cml0eSwNCj4gPj4+Pj4gICAgIHRoZSBXRyB3aWxsIGlkZW50 aWZ5IGdhcHMgYmV0d2VlbiBjdXJyZW50bHkgYXZhaWxhYmxlDQo+ID4+Pj4+ICAgICB0ZWNobm9s b2dpZXMgYW5kIHVzZS1jYXNlIHJlcXVpcmVtZW50cy4NCj4gPj4+Pj4gICAgIFRoZSBXRyB3aWxs IHRoZW4gZGVmaW5lIHJlcXVpcmVtZW50cyBmb3IgZXh0ZW5zaW9ucyB0bw0KPiA+Pj4+PiAgICAg ZXhpc3RpbmcgcHJvdG9jb2xzIG9yIG5ldyBwcm90b2NvbHMgdGhhdCBhZGRyZXNzIGdhcHMNCj4g Pj4+Pj4gICAgIHRoYXQgYXJlIGlkZW50aWZpZWQuIg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgIEknZCBs aWtlIHRvIHBvaW50IG91dCB3aXRoIGJldHRlciBwcmVjaXNpb24gd2hhdCBhcmUgdGhlDQo+ID4+ Pj4+ICAgZGlyZWN0aW9ucyB3ZSBhcmUgQUxSRUFEWSBlbmdhZ2VkIGludG86IGRhdGFwbGFuZXMg YW5kDQo+ID4+Pj4+ICAgcGFyYWRpZ21zLiBBcyBJIG1lbnRpb25lZCBpbiBteSBjaGFydGVyIHBy b3Bvc2FsLCB3ZSBkbyBoYXZlDQo+ID4+Pj4+ICAgaW1wbGVtZW50YXRpb25zIGFuZCBtdWx0aS12 ZW5kb3IgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cyB3aWxsDQo+ID4+Pj4+ICAgaGFwcGVuIHNvb24u IFNvLCBJIGp1c3Qgd2FudCB0byBiZSBzdXJlIHdlIGRvbid0IGlnbm9yZSB0aGlzDQo+ID4+Pj4+ ICAgcmVhbGl0eS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICBNUExTIGFuZCB2NiBkYXRhLXBsYW5lIGFy ZSBwYXJ0IG9mIHRoaXMgcmVhbGl0eSwgYXMgd2VsbCBhcw0KPiA+Pj4+PiAgIHR1bm5lbC1iYXNl ZCBhbmQgbm9uLXR1bm5lbCBiYXNlZCBhcHByb2FjaGVzLg0KPiA+Pj4+DQo+ID4+Pj4gSSBkb24n dCB0aGluayBpdCdzIHN1aXRhYmxlIHRvIG1lbnRpb24gZGV2ZWxvcGluZyBJUHY2IHNwZWNpZmlj IFNSDQo+ID4+Pj4gbWVjaGFuaXNtIGluDQo+ID4+PiB0aGUgY3VycmVudCBjaGFydGVyIHVubGVz cyB0aGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3IgYW55IGNoYW5nZSB0bw0KPiA+Pj4gdGhlIGV4 aXN0aW5nDQo+ID4+PiBJUHY2IGRhdGEgcGxhbmUuDQo+ID4+Pg0KPiA+Pj4+IEFjY29yZGluZyB0 byB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMgcXVvdGVkIGZyb20NCj4gPj4+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbHNmaWxzLXJ0Z3dnLXNlZ21lbnQtcm91dGluZy0wMCNw DQo+ID4+PiBhZ2UtOSwgIi4uLlRoZSBzb3VyY2Ugcm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRl cmVkIGxpc3Qgb2Ygc2VnbWVudHMNCj4gaW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMuLi4iDQo+ID4+ PiBJZiBzbywgd2h5IG5vdCBkaXJlY3RseSB1c2UgYW4gb3JkZXJlZCBsaXN0IG9mIGxhYmVscyAo aS5lLiwgTVBMUw0KPiA+Pj4gbGFiZWwgc3RhY2spIHRvIGRvIHRoYXQgKHNlZQ0KPiA+Pj4gaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3N0YXR1cy9jdXJyZW50L21zZzAwMTY1 Lmh0bWwpPw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiB2NiBkYXRhcGxhbmUgYWxsb3dzIG1vcmUgZWZm ZWN0aXZlIHNvdXJjZSByb3V0ZSBjYXBhYmlsaXR5IGJ5DQo+ID4+PiBsZXZlcmFnaW5nIGV4dGVu c2lvbnMgaGVhZGVycy4gSGVuY2UgdGhlIHByb3Bvc2FsIHRoYXQgd2lsbCBjb25zaXN0DQo+ID4+ PiBvZiBkZWZpbmluZyBhIG5ldyBFeHRlbnNpb24gSGVhZGVyIGZvciBTUiB3aGVyZSB0aGUgc2Vn bWVudCBsaXN0IGlzDQo+ID4+PiBlbmNvZGVkIGFuZCBfcHJlc2VydmVkXyB0aHJvdWdob3V0IHRo ZSBwYXRoLg0KPiA+Pg0KPiA+PiBXaGF0J3MgdGhlIHB1cnBvc2Ugb2YgcHJlc2VydmluZyB0aGUg d2hvbGUgc2VnbWVudCBsaXN0IHRocm91Z2hvdXQgdGhlDQo+IHBhdGg/IEluIG90aGVyIHdvcmRz LCBpc24ndCBpdCBlbm91Z2ggdG8gY29udGFpbiB0aGUgaW5mb3JtYXRpb24gb2YgaW5ncmVzcw0K PiBhbmQgZWdyZXNzIG5vZGVzIHRocm91Z2hvdXQgdGhlIHBhdGg/DQo+ID4NCj4gPg0KPiA+IHRo ZXJlIGFyZSB1c2UgY2FzZXMsIGFtb25nIHdoaWNoIE9BTSwgdGhhdCB3aWxsIGxldmVyYWdlIHRo ZQ0KPiA+IGF2YWlsYWJpbGl0eSBvZiB0aGUgc2VnbWVudCBsaXN0LiB2NiBoYXMgZ29vZCBuYXRp dmUgcHJvcGVydGllcyB0aGF0DQo+ID4gYWxsb3cgdG8gaW5zZXJ0IGV4cGxpY2l0L3NvdXJjZSBy b3V0aW5nIHBhcmFkaWdtcyBpbiB0aGUgZm9yd2FyZGluZw0KPiA+IHBsYW5lLiBNb3N0IG9mIFNX L0hXIGltcGxlbWVudGF0aW9ucyB0b2RheSBjYW4gaGFuZGxlIHRoaXMgd2l0aG91dA0KPiA+IGlu Y3VycmluZyBIVyBwZXJmb3JtYW5jZSBwZW5hbHR5Lg0KPiA+DQo+ID4gVGhhbmtzLg0KPiA+IHMu DQo+ID4NCj4gPg0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+IFhpYW9odQ0KPiA+Pg0K PiA+Pj4gU28sIEkgZG8gc3Ryb25nbHkgYmVsaWV2ZSB3ZSBoYXZlIHRvIHdvcmsgb24gdjYgYW5k IHNpbmNlIHdlJ3JlIGluDQo+ID4+PiB0aGUgZGVmaW5pdGlvbiBvZiBhIGNoYXJ0ZXIgKGkuZS46 IG5vdCB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHRoZQ0KPiA+Pj4gc29sdXRpb25zKSBJIGJlbGll dmUgdjYgc2hvdWxkIGJlIHBhcnQgb2YgaXQuDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzLg0KPiA+Pj4g cy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KPiA+Pj4+IFRoZSBtYWluIGRpZmZlcmVuY2VzIGZyb20gdGhl IElQdjYgc291cmNlIHJvdXRlIG1vZGVsIGFyZToNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4g Pj4+PiBGaWxzZmlscywgZXQgYWwuICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDMwLCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCj4gPj4+Pg0KPiA+Pj4+IEludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgU2VnbWVudCBSb3V0aW5nICAgICAgICAgICAgICAgICAgIEp1bmUNCj4gPj4+IDIw MTMNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gICAgVGhlIHNvdXJjZSByb3V0ZSBpcyBlbmNvZGVk IGFzIGFuIG9yZGVyZWQgbGlzdCBvZiBzZWdtZW50cyBpbnN0ZWFkDQo+ID4+Pj4gICAgb2YgSVAg YWRkcmVzc2VzLg0KPiA+Pj4+DQo+ID4+Pj4gICAgQSBzZWdtZW50IGNhbiByZXByZXNlbnQgYW55 IGluc3RydWN0aW9uIGVpdGhlciBhIHNlcnZpY2Ugb3IgYQ0KPiA+Pj4+ICAgIHRvcG9sb2dpY2Fs IHBhdGguICBUb3BvbG9naWNhbGx5LCB0aGUgcGF0aCB0byBhbiBJUCBhZGRyZXNzIGlzDQo+ID4+ Pj4gICAgb2Z0ZW4gbGltaXRlZCB0byB0aGUgc2hvcnRlc3QtcGF0aCB0byB0aGF0IGFkZHJlc3Mu ICBBIHNlZ21lbnQgY2FuDQo+ID4+Pj4gICAgcmVwcmVzZW50IGFueSBwYXRoIChlLmcuIGFuIGFk amFjZW5jeSBzZWdtZW50IGZvcmNlcyBhIHBhY2tldCB0byBhDQo+ID4+Pj4gICAgbmV4dGhvcCB0 aHJvdWdoIGEgc3BlY2lmaWMgYWRqYWNlbmN5IGV2ZW4gaWYgdGhlIHNob3J0ZXN0LXBhdGggdG8N Cj4gPj4+PiAgICB0aGUgbmV4dC1ob3AgZG9lcyBub3QgdXNlIHRoYXQgYWRqYWNlbmN5KS4NCj4g Pj4+Pg0KPiA+Pj4+ICAgIFRoZSBpbmdyZXNzIGFuZCBlZ3Jlc3MgZWdkZSByb3V0ZXJzIGFyZSBp ZGVudGlmaWVkIGFuZCBhbHdheXMNCj4gPj4+PiAgICBhdmFpbGFibGUsIGFsbG93aW5nIGZvciBp bnRlcmVzdGluZyBhY2NvdW50aW5nIGFuZCBwb2xpY3kNCj4gPj4+PiAgICBhcHBsaWNhdGlvbnMu DQo+ID4+Pj4NCj4gPj4+PiAgICBUaGUgc291cmNlIHJvdXRlIGZ1bmN0aW9uYWxpdHkgY2Fubm90 IGJlIGNvbnRyb2xsZWQgZnJvbSBvdXRzaWRlDQo+ID4+Pj4gICAgdGhlIFNSIGRvbWFpbi4NCj4g Pj4+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ID4+Pj4N Cj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4gWGlhb2h1DQo+ID4+Pg0KPiA+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IHN0YXR1cyBt YWlsaW5nIGxpc3QNCj4gPj4+IHN0YXR1c0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc3RhdHVzIG1haWxpbmcgbGlzdA0K PiA+IHN0YXR1c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3RhdHVzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHN0YXR1cyBtYWlsaW5nIGxpc3QNCj4gc3RhdHVzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RhdHVzDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHN0YXR1cyBtYWlsaW5nIGxpc3QN Cj4gc3RhdHVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3RhdHVzDQo= From rjs@rob.sh Thu Sep 12 14:11:57 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D5711E813B for ; Thu, 12 Sep 2013 14:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mdFNNcaql-L for ; Thu, 12 Sep 2013 14:11:55 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF9311E8267 for ; Thu, 12 Sep 2013 14:11:54 -0700 (PDT) Received: from [109.144.250.198] (helo=[10.210.4.87]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VKEAB-0007Tk-Tg; Thu, 12 Sep 2013 22:10:55 +0100 From: Rob Shakir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Sep 2013 22:11:49 +0100 Message-Id: To: "status@ietf.org" , Hannes Gredler , sprevidi Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "" Subject: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 21:11:57 -0000 Hi STATUS, Hannes, Stefano, Following some discussion with Stephane, I tried to consolidate the = wording from the various threads into one charter proposal, which can be = found below this message. I would specifically draw your attention to the following paragraph: > The architecture has been postulated to be applicable to = multiple data planes (e.g., MPLS,=20 > IPv6), and hence the working group should strive to create a single = framework which=20 > maintains data plane independence where possible. Where use cases are = documented, care should be taken=20 > to define the data plane requirements for the environment within which = they are to be implemented. The > architecture should avoid = modifications to the MPLS data-plane, in order to remain=20 > compatible with existing extensive deployments of MPLS. There are of course a number of different opinions relating to the = network deployments in which different operators would like to deploy = the technology that will be developed by this effort. In my humble = opinion, the debates as to the exact requirements can (and should) be = done in the working group as we develop on the use cases. I have = therefore tried to make sure that the wording in the charter does not = pre-judge the result of such debates, but does not close the door on = them in the future (should consensus exist to work on them). I believe = this also captures the points relating to data-planes that the ADs noted = in the evaluation of the BoF. Your feedback on this proposal would be very much appreciated (and = thanks to Stephane for his initial proposal and help with this)! Kind regards, r. Name: A number of use cases, including: o Path computation based on awareness of utilisation or performance data, within both centralised and distributed environments, o Multi-topology routing (dual planes, disjoint trees), o Simplification and reduction of signalling, o Combined application and network-layer path specification. o Full coverage LFA FRR, o Topology Aware OAM, =20 have triggered work on the definition of a new architecture and protocol = extensions, allowing nodes to steer packets through a network, allowing = combination of well-known shortest-path based routing paradigms with = source or explicit routing methods. Some of the extensions allowing = steering of packets in this manner have already been implemented. The working group will define an architecture allowing a node = to steer a packet through a network, or set of networks, on any path = without requiring state to be maintained by transited nodes (but rather = at the source device). The source node may send any packet along a path = within the domain through specifying the identifiers = referring to this path. Subsequent downstream nodes along the path = within the domain will forward packets according to the = instructions inserted by the head-end. Within the architecture, a node may be of any type - = including routers and appliances. A set of such nodes sharing a common = trust model form a domain. The architecture defined by this = working group will allow steering of packets between any source and = destination node within the domain, which may be formed of = one or more networks, on any path (shortest, non-shortest, explicit, or = based on other resources or characteristics specified by segment = identifiers). The architecture should support both centralised and = distributed path computation - through both existing routing protocols = (IGP, BGP) and new approaches to such path calculation. The architecture = should also support OAM functions. The architecture has been postulated to be applicable to = multiple data planes (e.g., MPLS, IPv6), and hence the working group = should strive to create a single framework which maintains = data plane independence where possible. Where use cases are documented, = care should be taken to define the data plane requirements for the = environment within which they are to be implemented. The = architecture should avoid modifications to the MPLS data-plane, in order = to remain compatible with existing extensive deployments of MPLS. The working group is chartered for the following (ordered) = list of items: o Identification of use-cases for the architecture for = which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between = networks forming the domain). o Having identified use-cases, and developed a framework, the WG = will identify gaps in currently available technologies, and define requirements for extensions or new functionality that is required. o The working group will then develop solutions - = focusing=20 initially on intra-domain forwarding implementations. Where such solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will be done in conjunction with the responsible IETF working group. = Work on new protocols may be carried out by the working = group. =20 The working group will develop the following documents: o One or more documents describing use cases, o A architecture, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of = extensions supporting . =20 From rraszuk@gmail.com Thu Sep 12 14:56:06 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE1E21E80B0 for ; Thu, 12 Sep 2013 14:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMSVulqjR5fL for ; Thu, 12 Sep 2013 14:55:58 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 253BF21E81F8 for ; Thu, 12 Sep 2013 14:55:51 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id q8so1451113lbi.11 for ; Thu, 12 Sep 2013 14:55:50 -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=HcTQMHy6XQWy1/wVh9H+KbJqzy5v8pyD3nDhWUjWp5U=; b=A3Cu3HlKNNenCom8yCVzClL/ZRqO6bcgGuwJ2f54jtB0j/Wmr2rJ3r3jLz/B4zzmTx xQK/qLXtNIRaYPte8fLOctzo/YZCv7mOxm8jQy5Le8J2JLu8PSZOgV0w/WJ1tVz3x4Yd G9tAPRcAQ3iy/qkeo94ckrkmdjDV9WohvWWTNBfJ8gyok/dISTStLaZUpXkVL/DPQTb+ lj8Zq+Zod/UYKorA8Sb6fdzvGMfCerIjCLiC0r40kwpdBDB+rzSrFnQzOl7Nszok31cZ HD/lFRv8Kz+Xa/pcUseNQINV3cIZRMsiCOiuBYtcyn4wAciVc1HBlhvyX8snkcP//y9b tq1w== MIME-Version: 1.0 X-Received: by 10.152.203.233 with SMTP id kt9mr3591377lac.29.1379022950011; Thu, 12 Sep 2013 14:55:50 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.138.33 with HTTP; Thu, 12 Sep 2013 14:55:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Sep 2013 23:55:49 +0200 X-Google-Sender-Auth: RKw8r5e26SStF3VI-Cmco8TsLGE Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: text/plain; charset=ISO-8859-1 Cc: Hannes Gredler , "status@ietf.org" , sprevidi , "" Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 21:56:06 -0000 Hi Rob, Let me provide two comments to your proposal: > A number of use cases, including: > > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, I think the above is a very important statement. In fact perhaps we could explicitly mentioned there that such paths could be p2p as well as p2mp. > o Having identified use-cases, and developed a framework, the WG will > identify gaps in currently available technologies, and define > requirements for extensions or new functionality that is required. As said before I disagree that we need to work off "gaps". Imagine if we all in IETF/networking would be walled to work off *gaps* we will be still improving FDDI, Token Ring, ATM and Frame Relay technologies. You can do a lot with RSVP-TE .. but there is not only control plane complexity associated with this, but also unnecessary state. Same for LDP. I would recommend to rephrase the above: o Having identified use-cases, and developed a framework, the WG will work on proposing a new architectures which substantially improve current technologies identify gaps in currently available technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocol. Best regards, R. From rraszuk@gmail.com Thu Sep 12 15:19:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F9A11E81B0 for ; Thu, 12 Sep 2013 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV9RlzSBe4MQ for ; Thu, 12 Sep 2013 15:19:35 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2162C11E814F for ; Thu, 12 Sep 2013 15:19:34 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so1485018lbj.27 for ; Thu, 12 Sep 2013 15:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VKbGc8Ox6SxHK+vJlCf/ybm2zVM6KUkTeGAWxluuYJg=; b=ntTh7aEJEgj3iXhgeHIPUnZL73p021XkPlqR0buUQi7owY/eKxh3vTO0xxlmODWbni lJoLItIoSgxXf7lONGq585pnfythfrgoWZuFaIPYMIzXUE1o/Uy7Td+vkPe7DMSLPVho 05T/2HpPlNjvnMoJK6HPalQmnFg3g0MOvCtKrGFasV2lZ6GVXEsXN1Fvjf4uQQmxerTc Hxm5jUKjub0OosctRZrkwdexEQLSfS3jeBjcxdgtp9qh6XR4W/gvoPvhuKEU4j9AhtZy GNYUr/a6/T+1tlkhH1qXSpnMrzYkU9OwjoNg+SAV+oIw/1JQy44iV9quDBy/g8mRm80K NPxg== MIME-Version: 1.0 X-Received: by 10.112.149.197 with SMTP id uc5mr8889954lbb.19.1379024373938; Thu, 12 Sep 2013 15:19:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.112.138.33 with HTTP; Thu, 12 Sep 2013 15:19:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 00:19:33 +0200 X-Google-Sender-Auth: WQa4s8xLPAVIAHxEal_3d9FKhFc Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: text/plain; charset=ISO-8859-1 Cc: Hannes Gredler , "status@ietf.org" , sprevidi , "" Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 22:19:35 -0000 Apologies ... fixed the below due to copy error: > I would recommend to rephrase the above: > > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocol. r. From rjs@rob.sh Thu Sep 12 15:23:27 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEFD21F9E46 for ; Thu, 12 Sep 2013 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHYDq1mICaEl for ; Thu, 12 Sep 2013 15:23:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 412D421E804C for ; Thu, 12 Sep 2013 15:23:13 -0700 (PDT) Received: from [109.144.250.198] (helo=[10.210.4.87]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VKFHB-0007jG-58; Thu, 12 Sep 2013 23:22:13 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Rob Shakir In-Reply-To: Date: Thu, 12 Sep 2013 23:23:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Raszuk X-Mailer: Apple Mail (2.1503) Cc: Hannes Gredler , "status@ietf.org" , sprevidi , "" Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 22:23:27 -0000 On 12 Sep 2013, at 23:19, Robert Raszuk wrote: > Apologies ... fixed the below due to copy error: >=20 >> I would recommend to rephrase the above: >>=20 >> o Having identified use-cases, and developed a framework, the WG will >> work on proposing a new architectures which substantially improve >> current technologies and define requirements for extensions or new >> functionality in existing routing protocols and/or I2RS protocol. Hi Robert, Sure - I have no problems with this. I think the key is to ensure that = we are working on problems that need solutions, either through omissions = of current technologies, or where there is scope for improvement. I'll = merge the change. On the p2p/p2mp case, I'm not clear that we need to explicitly define = this in the charter. The text currently makes no reference to the type = of path, since these should be defined within the use case documents = IMHO. Updated text is below. Thanks, r. Name: A number of use cases, including: o Path computation based on awareness of utilisation or performance data, within both centralised and distributed environments, o Multi-topology routing (dual planes, disjoint trees), o Simplification and reduction of signalling, o Combined application and network-layer path specification. o Full coverage LFA FRR, o Topology Aware OAM, =20 have triggered work on the definition of a new architecture and protocol = extensions, allowing nodes to steer packets through a network, allowing = combination of well-known shortest-path based routing paradigms with = source or explicit routing methods. Some of the extensions allowing = steering of packets in this manner have already been implemented. The working group will define an architecture allowing a node = to steer a packet through a network, or set of networks, on any path = without requiring state to be maintained by transited nodes (but rather = at the source device). The source node may send any packet along a path = within the domain through specifying the identifiers = referring to this path. Subsequent downstream nodes along the path = within the domain will forward packets according to the = instructions inserted by the head-end. Within the architecture, a node may be of any type - = including routers and appliances. A set of such nodes sharing a common = trust model form a domain. The architecture defined by this = working group will allow steering of packets between any source and = destination node within the domain, which may be formed of = one or more networks, on any path (shortest, non-shortest, explicit, or = based on other resources or characteristics specified by segment = identifiers). The architecture should support both centralised and = distributed path computation - through both existing routing protocols = (IGP, BGP) and new approaches to such path calculation. The architecture = should also support OAM functions. The architecture has been postulated to be applicable to = multiple data planes (e.g., MPLS, IPv6), and hence the working group = should strive to create a single framework which maintains = data plane independence where possible. Where use cases are documented, = care should be taken to define the data plane requirements for the = environment within which they are to be implemented. The = architecture should avoid modifications to the MPLS data-plane, in order = to remain compatible with existing extensive deployments of MPLS. The working group is chartered for the following (ordered) = list of items: o Identification of use-cases for the architecture for = which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between = networks forming the domain). =20 o Having identified use-cases, and developed a framework, the WG = will work on proposing a new architectures which substantially improve current technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocols. = =20 o The working group will then develop solutions - = focusing=20 initially on intra-domain forwarding implementations. Where such solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will be done in conjunction with the responsible IETF working group. = Work on new protocols may be carried out by the working = group. =20 The working group will develop the following documents: o One or more documents describing use cases, o A architecture, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of = extensions supporting . =20 From xuxiaohu@huawei.com Thu Sep 12 19:56:03 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F248121E80F9 for ; Thu, 12 Sep 2013 19:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L2LU64L+8p3 for ; Thu, 12 Sep 2013 19:55:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1482721E804D for ; Thu, 12 Sep 2013 19:55:47 -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.5-GA FastPath queued) with ESMTP id AXG76721; Fri, 13 Sep 2013 02:55:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 03:55:30 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 03:55:45 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 10:55:40 +0800 From: Xuxiaohu To: Rob Shakir , "status@ietf.org" , "Hannes Gredler" , sprevidi Thread-Topic: [Status] Updated Merged Charter. Thread-Index: AQHOr/y76jP/W/G5L0egXZKsnx8ckpnC82Tw Date: Fri, 13 Sep 2013 02:55:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820F202@NKGEML512-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: [Status] =?gb2312?b?tPC4tDogIFVwZGF0ZWQgTWVyZ2VkIENoYXJ0ZXIu?= X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 02:56:03 -0000 VG8gbWFrZSB0aGlzIHdvcmsgbW92ZSBmb3J3YXJkLCBpdCdkIGJldHRlciBmb3IgdXMgdG8gZm9j dXMgb24gdGhvc2UgaXRlbXMgd2hpY2ggaGF2ZSBnYWluZWQgd2lkZSBjb25zZW5zdXMgd2hpbGUg bGVhdmluZyBhc2lkZSB0aG9zZSB1bmNlcnRhaW4gYW5kIGNvbnRyb3ZlcnNpYWwgaXRlbXMuIE9u Y2UgdGhlcmUgYXJlIHNvbWUgc2tldGNoZXMgZm9yIHRoZSBsYXR0ZXIsIHdlIGNvdWxkIGV2YWx1 YXRlIHdoZXRoZXIgaXQncyB3b3J0aHdoaWxlIHRvIHJlY2hhcnRlciBmb3IgdGhlbSBhdCB0aGF0 IHRpbWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odSANCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4gt6K8/sjLOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFJvYg0KPiBTaGFraXINCj4gt6LLzcqxvOQ6IDIwMTPE6jnUwjEzyNUg NToxMg0KPiDK1bz+yMs6IHN0YXR1c0BpZXRmLm9yZzsgSGFubmVzIEdyZWRsZXI7IHNwcmV2aWRp DQo+ILOty806IDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCj4g1vfM4jogW1N0YXR1 c10gVXBkYXRlZCBNZXJnZWQgQ2hhcnRlci4NCj4gDQo+IEhpIFNUQVRVUywgSGFubmVzLCBTdGVm YW5vLA0KPiANCj4gRm9sbG93aW5nIHNvbWUgZGlzY3Vzc2lvbiB3aXRoIFN0ZXBoYW5lLCBJIHRy aWVkIHRvIGNvbnNvbGlkYXRlIHRoZSB3b3JkaW5nDQo+IGZyb20gdGhlIHZhcmlvdXMgdGhyZWFk cyBpbnRvIG9uZSBjaGFydGVyIHByb3Bvc2FsLCB3aGljaCBjYW4gYmUgZm91bmQgYmVsb3cNCj4g dGhpcyBtZXNzYWdlLg0KPiANCj4gSSB3b3VsZCBzcGVjaWZpY2FsbHkgZHJhdyB5b3VyIGF0dGVu dGlvbiB0byB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4gDQo+ID4gVGhlIDxOYW1lLVRCRD4g YXJjaGl0ZWN0dXJlIGhhcyBiZWVuIHBvc3R1bGF0ZWQgdG8gYmUgYXBwbGljYWJsZSB0bw0KPiBt dWx0aXBsZSBkYXRhIHBsYW5lcyAoZS5nLiwgTVBMUywNCj4gPiBJUHY2KSwgYW5kIGhlbmNlIHRo ZSB3b3JraW5nIGdyb3VwIHNob3VsZCBzdHJpdmUgdG8gY3JlYXRlIGEgc2luZ2xlDQo+IDxOYW1l LVRCRD4gZnJhbWV3b3JrIHdoaWNoDQo+ID4gbWFpbnRhaW5zIGRhdGEgcGxhbmUgaW5kZXBlbmRl bmNlIHdoZXJlIHBvc3NpYmxlLiBXaGVyZSB1c2UgY2FzZXMgYXJlDQo+IGRvY3VtZW50ZWQsIGNh cmUgc2hvdWxkIGJlIHRha2VuDQo+ID4gdG8gZGVmaW5lIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVt ZW50cyBmb3IgdGhlIGVudmlyb25tZW50IHdpdGhpbiB3aGljaCB0aGV5DQo+IGFyZSB0byBiZSBp bXBsZW1lbnRlZC4gVGhlID4gPE5hbWUtVEJEPiBhcmNoaXRlY3R1cmUgc2hvdWxkIGF2b2lkDQo+ IG1vZGlmaWNhdGlvbnMgdG8gdGhlIE1QTFMgZGF0YS1wbGFuZSwgaW4gb3JkZXIgdG8gcmVtYWlu DQo+ID4gY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIGV4dGVuc2l2ZSBkZXBsb3ltZW50cyBvZiBN UExTLg0KPiANCj4gVGhlcmUgYXJlIG9mIGNvdXJzZSBhIG51bWJlciBvZiBkaWZmZXJlbnQgb3Bp bmlvbnMgcmVsYXRpbmcgdG8gdGhlIG5ldHdvcmsNCj4gZGVwbG95bWVudHMgaW4gd2hpY2ggZGlm ZmVyZW50IG9wZXJhdG9ycyB3b3VsZCBsaWtlIHRvIGRlcGxveSB0aGUgdGVjaG5vbG9neQ0KPiB0 aGF0IHdpbGwgYmUgZGV2ZWxvcGVkIGJ5IHRoaXMgZWZmb3J0LiBJbiBteSBodW1ibGUgb3Bpbmlv biwgdGhlIGRlYmF0ZXMgYXMgdG8NCj4gdGhlIGV4YWN0IHJlcXVpcmVtZW50cyBjYW4gKGFuZCBz aG91bGQpIGJlIGRvbmUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgYXMgd2UNCj4gZGV2ZWxvcCBvbiB0 aGUgdXNlIGNhc2VzLiBJIGhhdmUgdGhlcmVmb3JlIHRyaWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRo ZSB3b3JkaW5nDQo+IGluIHRoZSBjaGFydGVyIGRvZXMgbm90IHByZS1qdWRnZSB0aGUgcmVzdWx0 IG9mIHN1Y2ggZGViYXRlcywgYnV0IGRvZXMgbm90IGNsb3NlDQo+IHRoZSBkb29yIG9uIHRoZW0g aW4gdGhlIGZ1dHVyZSAoc2hvdWxkIGNvbnNlbnN1cyBleGlzdCB0byB3b3JrIG9uIHRoZW0pLiBJ DQo+IGJlbGlldmUgdGhpcyBhbHNvIGNhcHR1cmVzIHRoZSBwb2ludHMgcmVsYXRpbmcgdG8gZGF0 YS1wbGFuZXMgdGhhdCB0aGUgQURzIG5vdGVkDQo+IGluIHRoZSBldmFsdWF0aW9uIG9mIHRoZSBC b0YuDQo+IA0KPiBZb3VyIGZlZWRiYWNrIG9uIHRoaXMgcHJvcG9zYWwgd291bGQgYmUgdmVyeSBt dWNoIGFwcHJlY2lhdGVkIChhbmQgdGhhbmtzIHRvDQo+IFN0ZXBoYW5lIGZvciBoaXMgaW5pdGlh bCBwcm9wb3NhbCBhbmQgaGVscCB3aXRoIHRoaXMpIQ0KPiANCj4gS2luZCByZWdhcmRzLA0KPiBy Lg0KPiANCj4gTmFtZTogPFRCRD4NCj4gDQo+IEEgbnVtYmVyIG9mIHVzZSBjYXNlcywgaW5jbHVk aW5nOg0KPiAgICAgbyBQYXRoIGNvbXB1dGF0aW9uIGJhc2VkIG9uIGF3YXJlbmVzcyBvZiB1dGls aXNhdGlvbiBvciBwZXJmb3JtYW5jZQ0KPiAgICAgICBkYXRhLCB3aXRoaW4gYm90aCBjZW50cmFs aXNlZCBhbmQgZGlzdHJpYnV0ZWQgZW52aXJvbm1lbnRzLA0KPiAgICAgbyBNdWx0aS10b3BvbG9n eSByb3V0aW5nIChkdWFsIHBsYW5lcywgZGlzam9pbnQgdHJlZXMpLA0KPiAgICAgbyBTaW1wbGlm aWNhdGlvbiBhbmQgcmVkdWN0aW9uIG9mIHNpZ25hbGxpbmcsDQo+ICAgICBvIENvbWJpbmVkIGFw cGxpY2F0aW9uIGFuZCBuZXR3b3JrLWxheWVyIHBhdGggc3BlY2lmaWNhdGlvbi4NCj4gICAgIG8g RnVsbCBjb3ZlcmFnZSBMRkEgRlJSLA0KPiAgICAgbyBUb3BvbG9neSBBd2FyZSBPQU0sDQo+IGhh dmUgdHJpZ2dlcmVkIHdvcmsgb24gdGhlIGRlZmluaXRpb24gb2YgYSBuZXcgYXJjaGl0ZWN0dXJl IGFuZCBwcm90b2NvbA0KPiBleHRlbnNpb25zLCBhbGxvd2luZyBub2RlcyB0byBzdGVlciBwYWNr ZXRzIHRocm91Z2ggYSBuZXR3b3JrLCBhbGxvd2luZw0KPiBjb21iaW5hdGlvbiBvZiB3ZWxsLWtu b3duIHNob3J0ZXN0LXBhdGggYmFzZWQgcm91dGluZyBwYXJhZGlnbXMgd2l0aCBzb3VyY2UNCj4g b3IgZXhwbGljaXQgcm91dGluZyBtZXRob2RzLiBTb21lIG9mIHRoZSBleHRlbnNpb25zIGFsbG93 aW5nIHN0ZWVyaW5nIG9mIHBhY2tldHMNCj4gaW4gdGhpcyBtYW5uZXIgaGF2ZSBhbHJlYWR5IGJl ZW4gaW1wbGVtZW50ZWQuDQo+IA0KPiBUaGUgPE5hbWUtVEJEPiB3b3JraW5nIGdyb3VwIHdpbGwg ZGVmaW5lIGFuIGFyY2hpdGVjdHVyZSBhbGxvd2luZyBhIG5vZGUgdG8NCj4gc3RlZXIgYSBwYWNr ZXQgdGhyb3VnaCBhIG5ldHdvcmssIG9yIHNldCBvZiBuZXR3b3Jrcywgb24gYW55IHBhdGggd2l0 aG91dA0KPiByZXF1aXJpbmcgc3RhdGUgdG8gYmUgbWFpbnRhaW5lZCBieSB0cmFuc2l0ZWQgbm9k ZXMgKGJ1dCByYXRoZXIgYXQgdGhlIHNvdXJjZQ0KPiBkZXZpY2UpLiBUaGUgc291cmNlIG5vZGUg bWF5IHNlbmQgYW55IHBhY2tldCBhbG9uZyBhIHBhdGggd2l0aGluIHRoZQ0KPiA8TmFtZS1UQkQ+ IGRvbWFpbiB0aHJvdWdoIHNwZWNpZnlpbmcgdGhlIGlkZW50aWZpZXJzIHJlZmVycmluZyB0byB0 aGlzIHBhdGguDQo+IFN1YnNlcXVlbnQgZG93bnN0cmVhbSBub2RlcyBhbG9uZyB0aGUgcGF0aCB3 aXRoaW4gdGhlIDxOYW1lLVRCRD4gZG9tYWluDQo+IHdpbGwgZm9yd2FyZCBwYWNrZXRzIGFjY29y ZGluZyB0byB0aGUgaW5zdHJ1Y3Rpb25zIGluc2VydGVkIGJ5IHRoZSBoZWFkLWVuZC4NCj4gDQo+ IFdpdGhpbiB0aGUgPE5hbWUtVEJEPiBhcmNoaXRlY3R1cmUsIGEgbm9kZSBtYXkgYmUgb2YgYW55 IHR5cGUgLSBpbmNsdWRpbmcNCj4gcm91dGVycyBhbmQgYXBwbGlhbmNlcy4gQSBzZXQgb2Ygc3Vj aCBub2RlcyBzaGFyaW5nIGEgY29tbW9uIHRydXN0IG1vZGVsIGZvcm0NCj4gYSA8TmFtZS1UQkQ+ IGRvbWFpbi4gVGhlIGFyY2hpdGVjdHVyZSBkZWZpbmVkIGJ5IHRoaXMgd29ya2luZyBncm91cCB3 aWxsDQo+IGFsbG93IHN0ZWVyaW5nIG9mIHBhY2tldHMgYmV0d2VlbiBhbnkgc291cmNlIGFuZCBk ZXN0aW5hdGlvbiBub2RlIHdpdGhpbiB0aGUNCj4gPE5hbWUtVEJEPiBkb21haW4sIHdoaWNoIG1h eSBiZSBmb3JtZWQgb2Ygb25lIG9yIG1vcmUgbmV0d29ya3MsIG9uIGFueQ0KPiBwYXRoIChzaG9y dGVzdCwgbm9uLXNob3J0ZXN0LCBleHBsaWNpdCwgb3IgYmFzZWQgb24gb3RoZXIgcmVzb3VyY2Vz IG9yDQo+IGNoYXJhY3RlcmlzdGljcyBzcGVjaWZpZWQgYnkgc2VnbWVudCBpZGVudGlmaWVycyku DQo+IA0KPiBUaGUgPE5hbWUtVEJEPiBhcmNoaXRlY3R1cmUgc2hvdWxkIHN1cHBvcnQgYm90aCBj ZW50cmFsaXNlZCBhbmQgZGlzdHJpYnV0ZWQNCj4gcGF0aCBjb21wdXRhdGlvbiAtIHRocm91Z2gg Ym90aCBleGlzdGluZyByb3V0aW5nIHByb3RvY29scyAoSUdQLCBCR1ApIGFuZCBuZXcNCj4gYXBw cm9hY2hlcyB0byBzdWNoIHBhdGggY2FsY3VsYXRpb24uIFRoZSBhcmNoaXRlY3R1cmUgc2hvdWxk IGFsc28gc3VwcG9ydCBPQU0NCj4gZnVuY3Rpb25zLg0KPiANCj4gVGhlIDxOYW1lLVRCRD4gYXJj aGl0ZWN0dXJlIGhhcyBiZWVuIHBvc3R1bGF0ZWQgdG8gYmUgYXBwbGljYWJsZSB0byBtdWx0aXBs ZQ0KPiBkYXRhIHBsYW5lcyAoZS5nLiwgTVBMUywgSVB2NiksIGFuZCBoZW5jZSB0aGUgd29ya2lu ZyBncm91cCBzaG91bGQgc3RyaXZlIHRvDQo+IGNyZWF0ZSBhIHNpbmdsZSA8TmFtZS1UQkQ+IGZy YW1ld29yayB3aGljaCBtYWludGFpbnMgZGF0YSBwbGFuZQ0KPiBpbmRlcGVuZGVuY2Ugd2hlcmUg cG9zc2libGUuIFdoZXJlIHVzZSBjYXNlcyBhcmUgZG9jdW1lbnRlZCwgY2FyZSBzaG91bGQgYmUN Cj4gdGFrZW4gdG8gZGVmaW5lIHRoZSBkYXRhIHBsYW5lIHJlcXVpcmVtZW50cyBmb3IgdGhlIGVu dmlyb25tZW50IHdpdGhpbiB3aGljaA0KPiB0aGV5IGFyZSB0byBiZSBpbXBsZW1lbnRlZC4gVGhl IDxOYW1lLVRCRD4gYXJjaGl0ZWN0dXJlIHNob3VsZCBhdm9pZA0KPiBtb2RpZmljYXRpb25zIHRv IHRoZSBNUExTIGRhdGEtcGxhbmUsIGluIG9yZGVyIHRvIHJlbWFpbiBjb21wYXRpYmxlIHdpdGgN Cj4gZXhpc3RpbmcgZXh0ZW5zaXZlIGRlcGxveW1lbnRzIG9mIE1QTFMuDQo+IA0KPiBUaGUgPE5h bWUtVEJEPiB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCBmb3IgdGhlIGZvbGxvd2luZyAob3Jk ZXJlZCkgbGlzdCBvZg0KPiBpdGVtczoNCj4gICAgIG8gSWRlbnRpZmljYXRpb24gb2YgdXNlLWNh c2VzIGZvciB0aGUgPE5hbWUtVEJEPiBhcmNoaXRlY3R1cmUgZm9yIHdoaWNoDQo+ICAgICAgIHRo ZXJlIGlzIGNvbnNlbnN1cyB3aXRoaW4gdGhlIFdHLg0KPiAgICAgbyBEZWZpbml0aW9uIG9mIGFu IGFyY2hpdGVjdHVyYWwgZnJhbWV3b3JrLCB3aGljaCBtdXN0IGNvdmVyDQo+ICAgICAgIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIChpbmNsdWRpbmcgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIG5l dHdvcmtzDQo+ICAgICAgIGZvcm1pbmcgdGhlIDxOYW1lLVRCRD4gZG9tYWluKS4NCj4gICAgIG8g SGF2aW5nIGlkZW50aWZpZWQgdXNlLWNhc2VzLCBhbmQgZGV2ZWxvcGVkIGEgZnJhbWV3b3JrLCB0 aGUgV0cgd2lsbA0KPiAgICAgICBpZGVudGlmeSBnYXBzIGluIGN1cnJlbnRseSBhdmFpbGFibGUg dGVjaG5vbG9naWVzLCBhbmQgZGVmaW5lDQo+ICAgICAgIHJlcXVpcmVtZW50cyBmb3IgZXh0ZW5z aW9ucyBvciBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHJlcXVpcmVkLg0KPiAgICAgbyBUaGUg PE5hbWUtVEJEPiB3b3JraW5nIGdyb3VwIHdpbGwgdGhlbiBkZXZlbG9wIHNvbHV0aW9ucyAtIGZv Y3VzaW5nDQo+ICAgICAgIGluaXRpYWxseSBvbiBpbnRyYS1kb21haW4gZm9yd2FyZGluZyBpbXBs ZW1lbnRhdGlvbnMuIFdoZXJlIHN1Y2gNCj4gICAgICAgc29sdXRpb25zIHV0aWxpc2UgZXhpc3Rp bmcgcHJvdG9jb2xzIChJUy1JUywgT1NQRiwgQkdQLCBQQ0UpIHRoaXMgd2lsbA0KPiAgICAgICBi ZSBkb25lIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIHJlc3BvbnNpYmxlIElFVEYgd29ya2luZyBn cm91cC4gV29yaw0KPiAgICAgICBvbiBuZXcgcHJvdG9jb2xzIG1heSBiZSBjYXJyaWVkIG91dCBi eSB0aGUgPE5hbWUtVEJEPiB3b3JraW5nIGdyb3VwLg0KPiANCj4gVGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBkZXZlbG9wIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzOg0KPiAgICAgbyBPbmUgb3IgbW9y ZSBkb2N1bWVudHMgZGVzY3JpYmluZyA8TmFtZS1UQkQ+IHVzZSBjYXNlcywNCj4gICAgIG8gQSA8 TmFtZS1UQkQ+IGFyY2hpdGVjdHVyZSwNCj4gICAgIG8gQSBzZXQgb2Ygb25lIG9yIG1vcmUgcHJv dG9jb2wgZXh0ZW5zaW9ucyByZXF1aXJlbWVudHMgZG9jdW1lbnRzLA0KPiAgICAgbyBJbnRlci1v cGVyYWJpbGl0eSByZXBvcnRzIHBlcnRhaW5pbmcgdG8gdGhlIGltcGxlbWVudGF0aW9uIG9mIGV4 dGVuc2lvbnMNCj4gICAgICAgc3VwcG9ydGluZyA8TmFtZS1UQkQ+Lg0KPiANCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHN0YXR1cyBtYWls aW5nIGxpc3QNCj4gc3RhdHVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3RhdHVzDQo= From Ruediger.Geib@telekom.de Thu Sep 12 23:16:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC25611E814C for ; Thu, 12 Sep 2013 23:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEAU+j2GEoGh for ; Thu, 12 Sep 2013 23:16:44 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2AD11E8144 for ; Thu, 12 Sep 2013 23:16:37 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 13 Sep 2013 08:16:33 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 13 Sep 2013 08:16:33 +0200 From: To: , , Date: Fri, 13 Sep 2013 08:16:32 +0200 Thread-Topic: [Status] Updated Merged Charter. Thread-Index: Ac6wBr3o5FNEzoSRRQukUpVt4HCQBQAQYoqw Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 06:16:49 -0000 Rob, Stephane and Robert, thanks again for your constructive input. I support your proposal. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Rob Shakir Sent: Friday, September 13, 2013 12:23 AM To: Robert Raszuk Cc: Hannes Gredler; status@ietf.org; sprevidi; Subject: Re: [Status] Updated Merged Charter. On 12 Sep 2013, at 23:19, Robert Raszuk wrote: > Apologies ... fixed the below due to copy error: > >> I would recommend to rephrase the above: >> >> o Having identified use-cases, and developed a framework, the WG will >> work on proposing a new architectures which substantially improve >> current technologies and define requirements for extensions or new >> functionality in existing routing protocols and/or I2RS protocol. Hi Robert, Sure - I have no problems with this. I think the key is to ensure that we a= re working on problems that need solutions, either through omissions of cur= rent technologies, or where there is scope for improvement. I'll merge the = change. On the p2p/p2mp case, I'm not clear that we need to explicitly define this = in the charter. The text currently makes no reference to the type of path, = since these should be defined within the use case documents IMHO. Updated text is below. Thanks, r. Name: A number of use cases, including: o Path computation based on awareness of utilisation or performance data, within both centralised and distributed environments, o Multi-topology routing (dual planes, disjoint trees), o Simplification and reduction of signalling, o Combined application and network-layer path specification. o Full coverage LFA FRR, o Topology Aware OAM, have triggered work on the definition of a new architecture and protocol ex= tensions, allowing nodes to steer packets through a network, allowing combi= nation of well-known shortest-path based routing paradigms with source or e= xplicit routing methods. Some of the extensions allowing steering of packet= s in this manner have already been implemented. The working group will define an architecture allowing a node to= steer a packet through a network, or set of networks, on any path without = requiring state to be maintained by transited nodes (but rather at the sour= ce device). The source node may send any packet along a path within the domain through specifying the identifiers referring to this path. S= ubsequent downstream nodes along the path within the domain will= forward packets according to the instructions inserted by the head-end. Within the architecture, a node may be of any type - including r= outers and appliances. A set of such nodes sharing a common trust model for= m a domain. The architecture defined by this working group will = allow steering of packets between any source and destination node within th= e domain, which may be formed of one or more networks, on any pa= th (shortest, non-shortest, explicit, or based on other resources or charac= teristics specified by segment identifiers). The architecture should support both centralised and distributed= path computation - through both existing routing protocols (IGP, BGP) and = new approaches to such path calculation. The architecture should also suppo= rt OAM functions. The architecture has been postulated to be applicable to multipl= e data planes (e.g., MPLS, IPv6), and hence the working group should strive= to create a single framework which maintains data plane indepen= dence where possible. Where use cases are documented, care should be taken = to define the data plane requirements for the environment within which they= are to be implemented. The architecture should avoid modificati= ons to the MPLS data-plane, in order to remain compatible with existing ext= ensive deployments of MPLS. The working group is chartered for the following (ordered) list = of items: o Identification of use-cases for the architecture for which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between networks forming the domain). o Having identified use-cases, and developed a framework, the WG will work on proposing a new architectures which substantially improve current technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocols. o The working group will then develop solutions - focusing initially on intra-domain forwarding implementations. Where such solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wil= l be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. The working group will develop the following documents: o One or more documents describing use cases, o A architecture, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensi= ons supporting . _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From sprevidi@cisco.com Fri Sep 13 03:07:55 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F521F0D36 for ; Fri, 13 Sep 2013 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.167 X-Spam-Level: X-Spam-Status: No, score=-109.167 tagged_above=-999 required=5 tests=[AWL=1.432, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLCgpRtNdjWK for ; Fri, 13 Sep 2013 03:07:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D83CA1F0CB2 for ; Fri, 13 Sep 2013 03:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5720; q=dns/txt; s=iport; t=1379066869; x=1380276469; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TBSLF37Gv/vlSUxWRzeVIuyYy1BLjXpMHCkMzIbso+A=; b=lZfIT8XqlE2+/JBypLm4tVYUpTB1SqKrcF5jshKIUc8DiamyFCkPiMe5 nwAk1D232C4I/cVThw0RdGXYw6sDox7Si+Supc9vykv1Khsi3vFpz1BCG GhVcAkiJduGkrqGeI5ipk8T5bubwr/zk/eIZTXKf0EnJZfD1wsd/q6hXt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKjiMlKtJV2b/2dsb2JhbABbgweBCsBwgR0WdIIlAQEBAwE6LQsHEAIBCA4EBgoUEDIXDgIEDgUIE4diBqwdjWmPPgIxB4MegQADlB6VUIMkgio X-IronPort-AV: E=Sophos;i="4.90,897,1371081600"; d="scan'208";a="259298854" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 13 Sep 2013 10:07:47 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8DA7lmW030852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 10:07:47 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.02.0318.004; Fri, 13 Sep 2013 05:07:47 -0500 From: "Stefano Previdi (sprevidi)" To: Rob Shakir Thread-Topic: [Status] Updated Merged Charter. Thread-Index: AQHOr/y36V0yf3M8dEyLABsLFbNoWpnC+YaAgAAGooCAAAD/gIAAxN2A Date: Fri, 13 Sep 2013 10:07:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hannes Gredler , Stephane Litkowski , "Clarence Filsfils \(cfilsfil\)" , Robert Raszuk , "status@ietf.org" Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 10:07:55 -0000 Hi Rob, Stephane, Robert, Thanks for the effort. I think we're in the good direction. I support your proposal of updated charter and I'd propose "SEGROUTE"=20 as WG name since it reflects pretty well the architecture that has=20 been proposed (SR) and it's inline with RFC2460 which uses "segments"=20 and "ordered list of segments" terminology in the framework of source=20 routing (section 4.4). s. On Sep 13, 2013, at 12:23 AM, Rob Shakir wrote: >=20 > On 12 Sep 2013, at 23:19, Robert Raszuk wrote: >=20 >> Apologies ... fixed the below due to copy error: >>=20 >>> I would recommend to rephrase the above: >>>=20 >>> o Having identified use-cases, and developed a framework, the WG will >>> work on proposing a new architectures which substantially improve >>> current technologies and define requirements for extensions or new >>> functionality in existing routing protocols and/or I2RS protocol. >=20 > Hi Robert, >=20 > Sure - I have no problems with this. I think the key is to ensure that we= are working on problems that need solutions, either through omissions of c= urrent technologies, or where there is scope for improvement. I'll merge th= e change. >=20 > On the p2p/p2mp case, I'm not clear that we need to explicitly define thi= s in the charter. The text currently makes no reference to the type of path= , since these should be defined within the use case documents IMHO. >=20 > Updated text is below. >=20 > Thanks, > r. >=20 > Name: >=20 > A number of use cases, including: > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, > o Multi-topology routing (dual planes, disjoint trees), > o Simplification and reduction of signalling, > o Combined application and network-layer path specification. > o Full coverage LFA FRR, > o Topology Aware OAM, =20 > have triggered work on the definition of a new architecture and protocol = extensions, allowing nodes to steer packets through a network, allowing com= bination of well-known shortest-path based routing paradigms with source or= explicit routing methods. Some of the extensions allowing steering of pack= ets in this manner have already been implemented. >=20 > The working group will define an architecture allowing a node = to steer a packet through a network, or set of networks, on any path withou= t requiring state to be maintained by transited nodes (but rather at the so= urce device). The source node may send any packet along a path within the <= Name-TBD> domain through specifying the identifiers referring to this path.= Subsequent downstream nodes along the path within the domain wi= ll forward packets according to the instructions inserted by the head-end. >=20 > Within the architecture, a node may be of any type - including= routers and appliances. A set of such nodes sharing a common trust model f= orm a domain. The architecture defined by this working group wil= l allow steering of packets between any source and destination node within = the domain, which may be formed of one or more networks, on any = path (shortest, non-shortest, explicit, or based on other resources or char= acteristics specified by segment identifiers). >=20 > The architecture should support both centralised and distribut= ed path computation - through both existing routing protocols (IGP, BGP) an= d new approaches to such path calculation. The architecture should also sup= port OAM functions. >=20 > The architecture has been postulated to be applicable to multi= ple data planes (e.g., MPLS, IPv6), and hence the working group should stri= ve to create a single framework which maintains data plane indep= endence where possible. Where use cases are documented, care should be take= n to define the data plane requirements for the environment within which th= ey are to be implemented. The architecture should avoid modifica= tions to the MPLS data-plane, in order to remain compatible with existing e= xtensive deployments of MPLS. >=20 > The working group is chartered for the following (ordered) lis= t of items: > o Identification of use-cases for the architecture for whic= h > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). =20 > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. = =20 > o The working group will then develop solutions - focusing= =20 > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi= ll > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. >=20 > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extens= ions > supporting . >=20 >=20 From brian_field@cable.comcast.com Fri Sep 13 04:50:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1771021F9EC8 for ; Fri, 13 Sep 2013 04:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKZsZV0ggULb for ; Fri, 13 Sep 2013 04:50:30 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id E9EA521F9EDF for ; Fri, 13 Sep 2013 04:50:19 -0700 (PDT) Received: from ([147.191.109.24]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.65335235; Fri, 13 Sep 2013 07:50:15 -0400 Received: from COPDCEXMB07.cable.comcast.com ([169.254.5.75]) by copdcexhub04.cable.comcast.com ([fe80::8952:4d82:130a:e769%16]) with mapi id 14.02.0318.001; Fri, 13 Sep 2013 05:50:15 -0600 From: "Field, Brian" To: "Stefano Previdi (sprevidi)" , Rob Shakir Thread-Topic: [Status] Updated Merged Charter. Thread-Index: AQHOr/y9TR3c1rrItkyqNsGs8fqtIZnDGw2A///134CAAAD/gIAAxN+A//+4DoA= Date: Fri, 13 Sep 2013 11:50:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [24.40.56.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DD6588ECC7BEE49A79B2A80045B4201@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" , Hannes Gredler , Robert Raszuk , "Clarence Filsfils \(cfilsfil\)" , Stephane Litkowski Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 11:50:35 -0000 I support the updated charter as proposed by Rob and I am particularly interested in an end-to-end IPv6 solution. Brian On 9/13/13 4:07 AM, "Stefano Previdi (sprevidi)" wrote: >Hi Rob, Stephane, Robert, > >Thanks for the effort. I think we're in the good direction. > >I support your proposal of updated charter and I'd propose "SEGROUTE" >as WG name since it reflects pretty well the architecture that has >been proposed (SR) and it's inline with RFC2460 which uses "segments" >and "ordered list of segments" terminology in the framework of source >routing (section 4.4). > > >s. > > >On Sep 13, 2013, at 12:23 AM, Rob Shakir wrote: > >>=20 >> On 12 Sep 2013, at 23:19, Robert Raszuk wrote: >>=20 >>> Apologies ... fixed the below due to copy error: >>>=20 >>>> I would recommend to rephrase the above: >>>>=20 >>>> o Having identified use-cases, and developed a framework, the WG will >>>> work on proposing a new architectures which substantially improve >>>> current technologies and define requirements for extensions or new >>>> functionality in existing routing protocols and/or I2RS protocol. >>=20 >> Hi Robert, >>=20 >> Sure - I have no problems with this. I think the key is to ensure that >>we are working on problems that need solutions, either through omissions >>of current technologies, or where there is scope for improvement. I'll >>merge the change. >>=20 >> On the p2p/p2mp case, I'm not clear that we need to explicitly define >>this in the charter. The text currently makes no reference to the type >>of path, since these should be defined within the use case documents >>IMHO. >>=20 >> Updated text is below. >>=20 >> Thanks, >> r. >>=20 >> Name: >>=20 >> A number of use cases, including: >> o Path computation based on awareness of utilisation or performance >> data, within both centralised and distributed environments, >> o Multi-topology routing (dual planes, disjoint trees), >> o Simplification and reduction of signalling, >> o Combined application and network-layer path specification. >> o Full coverage LFA FRR, >> o Topology Aware OAM, >> have triggered work on the definition of a new architecture and >>protocol extensions, allowing nodes to steer packets through a network, >>allowing combination of well-known shortest-path based routing paradigms >>with source or explicit routing methods. Some of the extensions allowing >>steering of packets in this manner have already been implemented. >>=20 >> The working group will define an architecture allowing a >>node to steer a packet through a network, or set of networks, on any >>path without requiring state to be maintained by transited nodes (but >>rather at the source device). The source node may send any packet along >>a path within the domain through specifying the identifiers >>referring to this path. Subsequent downstream nodes along the path >>within the domain will forward packets according to the >>instructions inserted by the head-end. >>=20 >> Within the architecture, a node may be of any type - >>including routers and appliances. A set of such nodes sharing a common >>trust model form a domain. The architecture defined by this >>working group will allow steering of packets between any source and >>destination node within the domain, which may be formed of >>one or more networks, on any path (shortest, non-shortest, explicit, or >>based on other resources or characteristics specified by segment >>identifiers). >>=20 >> The architecture should support both centralised and >>distributed path computation - through both existing routing protocols >>(IGP, BGP) and new approaches to such path calculation. The architecture >>should also support OAM functions. >>=20 >> The architecture has been postulated to be applicable to >>multiple data planes (e.g., MPLS, IPv6), and hence the working group >>should strive to create a single framework which maintains >>data plane independence where possible. Where use cases are documented, >>care should be taken to define the data plane requirements for the >>environment within which they are to be implemented. The >>architecture should avoid modifications to the MPLS data-plane, in order >>to remain compatible with existing extensive deployments of MPLS. >>=20 >> The working group is chartered for the following (ordered) >>list of items: >> o Identification of use-cases for the architecture for >>which >> there is consensus within the WG. >> o Definition of an architectural framework, which must cover >> security considerations (including the relationship between >>networks >> forming the domain). >> o Having identified use-cases, and developed a framework, the WG will >> work on proposing a new architectures which substantially improve >> current technologies and define requirements for extensions or new >> functionality in existing routing protocols and/or I2RS protocols. >> =20 >> o The working group will then develop solutions - >>focusing=20 >> initially on intra-domain forwarding implementations. Where such >> solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this >>will >> be done in conjunction with the responsible IETF working group. >>Work >> on new protocols may be carried out by the working >>group. >>=20 >> The working group will develop the following documents: >> o One or more documents describing use cases, >> o A architecture, >> o A set of one or more protocol extensions requirements documents, >> o Inter-operability reports pertaining to the implementation of >>extensions >> supporting . >>=20 >>=20 > >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status From Peter.AshwoodSmith@huawei.com Fri Sep 13 06:24:25 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766B221E8055 for ; Fri, 13 Sep 2013 06:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=2.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewAKEfsgO3Mi for ; Fri, 13 Sep 2013 06:24:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8914C21E80AD for ; Fri, 13 Sep 2013 06:24:20 -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.5-GA FastPath queued) with ESMTP id AXH27588; Fri, 13 Sep 2013 13:24:19 +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.146.0; Fri, 13 Sep 2013 14:23:47 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 14:23:59 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 06:23:53 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Updated Merged Charter. Thread-Index: AQHOr/y9oJ6AH88IMkWeJ+cZv7dcD5nDGw2AgAAGooCAAAD/gIAAhEYAgAAA2bA= Date: Fri, 13 Sep 2013 13:23:52 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E209901C82@dfweml513-mbb.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 13:24:25 -0000 Support, However suggest that "Some of the extensions allowing steering of packets i= n this manner have already been implemented" is not really relevant to the = charter as consensus and working code is a back end requirement. Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Ruediger.Geib@telekom.de Sent: Friday, September 13, 2013 2:17 AM To: rjs@rob.sh; robert@raszuk.net; stephane.litkowski@orange.com Cc: status@ietf.org Subject: Re: [Status] Updated Merged Charter. Rob, Stephane and Robert, thanks again for your constructive input. I support your proposal. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Rob Shakir Sent: Friday, September 13, 2013 12:23 AM To: Robert Raszuk Cc: Hannes Gredler; status@ietf.org; sprevidi; Subject: Re: [Status] Updated Merged Charter. On 12 Sep 2013, at 23:19, Robert Raszuk wrote: > Apologies ... fixed the below due to copy error: > >> I would recommend to rephrase the above: >> >> o Having identified use-cases, and developed a framework, the WG will >> work on proposing a new architectures which substantially improve >> current technologies and define requirements for extensions or new >> functionality in existing routing protocols and/or I2RS protocol. Hi Robert, Sure - I have no problems with this. I think the key is to ensure that we a= re working on problems that need solutions, either through omissions of cur= rent technologies, or where there is scope for improvement. I'll merge the = change. On the p2p/p2mp case, I'm not clear that we need to explicitly define this = in the charter. The text currently makes no reference to the type of path, = since these should be defined within the use case documents IMHO. Updated text is below. Thanks, r. Name: A number of use cases, including: o Path computation based on awareness of utilisation or performance data, within both centralised and distributed environments, o Multi-topology routing (dual planes, disjoint trees), o Simplification and reduction of signalling, o Combined application and network-layer path specification. o Full coverage LFA FRR, o Topology Aware OAM, have triggered work on the definition of a new architecture and protocol ex= tensions, allowing nodes to steer packets through a network, allowing combi= nation of well-known shortest-path based routing paradigms with source or e= xplicit routing methods. Some of the extensions allowing steering of packet= s in this manner have already been implemented. The working group will define an architecture allowing a node to= steer a packet through a network, or set of networks, on any path without = requiring state to be maintained by transited nodes (but rather at the sour= ce device). The source node may send any packet along a path within the domain through specifying the identifiers referring to this path. S= ubsequent downstream nodes along the path within the domain will= forward packets according to the instructions inserted by the head-end. Within the architecture, a node may be of any type - including r= outers and appliances. A set of such nodes sharing a common trust model for= m a domain. The architecture defined by this working group will = allow steering of packets between any source and destination node within th= e domain, which may be formed of one or more networks, on any pa= th (shortest, non-shortest, explicit, or based on other resources or charac= teristics specified by segment identifiers). The architecture should support both centralised and distributed= path computation - through both existing routing protocols (IGP, BGP) and = new approaches to such path calculation. The architecture should also suppo= rt OAM functions. The architecture has been postulated to be applicable to multipl= e data planes (e.g., MPLS, IPv6), and hence the working group should strive= to create a single framework which maintains data plane indepen= dence where possible. Where use cases are documented, care should be taken = to define the data plane requirements for the environment within which they= are to be implemented. The architecture should avoid modificati= ons to the MPLS data-plane, in order to remain compatible with existing ext= ensive deployments of MPLS. The working group is chartered for the following (ordered) list = of items: o Identification of use-cases for the architecture for which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between networks forming the domain). o Having identified use-cases, and developed a framework, the WG will work on proposing a new architectures which substantially improve current technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocols. o The working group will then develop solutions - focusing initially on intra-domain forwarding implementations. Where such solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wil= l be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. The working group will develop the following documents: o One or more documents describing use cases, o A architecture, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensi= ons supporting . _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From sprevidi@cisco.com Fri Sep 13 06:28:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59D721F9C7A for ; Fri, 13 Sep 2013 06:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTRIdMsZKqRM for ; Fri, 13 Sep 2013 06:28:30 -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 835A321F9CE2 for ; Fri, 13 Sep 2013 06:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7005; q=dns/txt; s=iport; t=1379078910; x=1380288510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Jupfw1G47crMOdEawsP+9Pc01eBAfOUQCTTHvBiFiNc=; b=N5slK17ih29H2hVCha0ZJcWdY4cVNR7z96DzYBmISTVE0m4FNBHk85ac P0+aspTRn+xG2dZfWxu+dT57fcynu2tJOxjiNCFm9ue5+Gzs4KlswXAg/ ZcfIuOXk19fiHdqXAEhFUmnEqANLS+TYA+Z6e81ZsywpupSdMI5gNHw2Q U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALcSM1KtJXHB/2dsb2JhbABbgwc4UsBqgRwWdIIlAQEBAwEBAQE3LQcEBwwEAgEIEQEDAQEBChQJBycLFAMGCAIEDgUIE4diBgysKI1gBI8+AgYrBwaDGIEAA5QelVCDJIIq X-IronPort-AV: E=Sophos;i="4.90,898,1371081600"; d="scan'208";a="259332840" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 13 Sep 2013 13:28:08 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8DDRm0T002499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 13:28:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 08:27:56 -0500 From: "Stefano Previdi (sprevidi)" To: AshwoodsmithPeter Thread-Topic: [Status] Updated Merged Charter. Thread-Index: AQHOr/y36V0yf3M8dEyLABsLFbNoWpnC+YaAgAAGooCAAAD/gIAAhEYAgAB3ZQCAAAEeAA== Date: Fri, 13 Sep 2013 13:27:55 +0000 Message-ID: References: <7AE6A4247B044C4ABE0A5B6BF427F8E209901C82@dfweml513-mbb.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E209901C82@dfweml513-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <75C9979E04CA0245AACD679F42DFBB52@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 13:28:41 -0000 Hi Peter, On Sep 13, 2013, at 3:23 PM, AshwoodsmithPeter wrote: > Support, >=20 > However suggest that "Some of the extensions allowing steering of packets= in this manner have already been implemented" is not really relevant to th= e charter as consensus and working code is a back end requirement. indeed. However, it's a way to illustrate that requirements (even if=20 not yet documented) do exist. Obviously, they must be documented=20 appropriately and we are working on it. Thanks for your support. s. >=20 > Peter >=20 > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of Ruediger.Geib@telekom.de > Sent: Friday, September 13, 2013 2:17 AM > To: rjs@rob.sh; robert@raszuk.net; stephane.litkowski@orange.com > Cc: status@ietf.org > Subject: Re: [Status] Updated Merged Charter. >=20 > Rob, Stephane and Robert, >=20 > thanks again for your constructive input. I support your proposal. >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of Rob Shakir > Sent: Friday, September 13, 2013 12:23 AM > To: Robert Raszuk > Cc: Hannes Gredler; status@ietf.org; sprevidi; > Subject: Re: [Status] Updated Merged Charter. >=20 >=20 > On 12 Sep 2013, at 23:19, Robert Raszuk wrote: >=20 >> Apologies ... fixed the below due to copy error: >>=20 >>> I would recommend to rephrase the above: >>>=20 >>> o Having identified use-cases, and developed a framework, the WG will >>> work on proposing a new architectures which substantially improve >>> current technologies and define requirements for extensions or new >>> functionality in existing routing protocols and/or I2RS protocol. >=20 > Hi Robert, >=20 > Sure - I have no problems with this. I think the key is to ensure that we= are working on problems that need solutions, either through omissions of c= urrent technologies, or where there is scope for improvement. I'll merge th= e change. >=20 > On the p2p/p2mp case, I'm not clear that we need to explicitly define thi= s in the charter. The text currently makes no reference to the type of path= , since these should be defined within the use case documents IMHO. >=20 > Updated text is below. >=20 > Thanks, > r. >=20 > Name: >=20 > A number of use cases, including: > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, > o Multi-topology routing (dual planes, disjoint trees), > o Simplification and reduction of signalling, > o Combined application and network-layer path specification. > o Full coverage LFA FRR, > o Topology Aware OAM, > have triggered work on the definition of a new architecture and protocol = extensions, allowing nodes to steer packets through a network, allowing com= bination of well-known shortest-path based routing paradigms with source or= explicit routing methods. Some of the extensions allowing steering of pack= ets in this manner have already been implemented. >=20 > The working group will define an architecture allowing a node = to steer a packet through a network, or set of networks, on any path withou= t requiring state to be maintained by transited nodes (but rather at the so= urce device). The source node may send any packet along a path within the <= Name-TBD> domain through specifying the identifiers referring to this path.= Subsequent downstream nodes along the path within the domain wi= ll forward packets according to the instructions inserted by the head-end. >=20 > Within the architecture, a node may be of any type - including= routers and appliances. A set of such nodes sharing a common trust model f= orm a domain. The architecture defined by this working group wil= l allow steering of packets between any source and destination node within = the domain, which may be formed of one or more networks, on any = path (shortest, non-shortest, explicit, or based on other resources or char= acteristics specified by segment identifiers). >=20 > The architecture should support both centralised and distribut= ed path computation - through both existing routing protocols (IGP, BGP) an= d new approaches to such path calculation. The architecture should also sup= port OAM functions. >=20 > The architecture has been postulated to be applicable to multi= ple data planes (e.g., MPLS, IPv6), and hence the working group should stri= ve to create a single framework which maintains data plane indep= endence where possible. Where use cases are documented, care should be take= n to define the data plane requirements for the environment within which th= ey are to be implemented. The architecture should avoid modifica= tions to the MPLS data-plane, in order to remain compatible with existing e= xtensive deployments of MPLS. >=20 > The working group is chartered for the following (ordered) lis= t of items: > o Identification of use-cases for the architecture for whic= h > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi= ll > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. >=20 > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extens= ions > supporting . >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From Peter.AshwoodSmith@huawei.com Fri Sep 13 06:41:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0A811E8203 for ; Fri, 13 Sep 2013 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.085 X-Spam-Level: X-Spam-Status: No, score=-5.085 tagged_above=-999 required=5 tests=[AWL=1.514, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFuDKLsYComB for ; Fri, 13 Sep 2013 06:41:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A17F511E818E for ; Fri, 13 Sep 2013 06:41:44 -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.5-GA FastPath queued) with ESMTP id AVJ42072; Fri, 13 Sep 2013 13:41:43 +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.146.0; Fri, 13 Sep 2013 14:39:54 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 14:40:09 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 06:40:05 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Updated Merged Charter. Thread-Index: AQHOr/y9oJ6AH88IMkWeJ+cZv7dcD5nDGw2AgAAGooCAAAD/gIAAhEYAgAAA2bCAAHetgP//izww Date: Fri, 13 Sep 2013 13:40:04 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E209901CCE@dfweml513-mbb.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E209901C82@dfweml513-mbb.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Updated Merged Charter. X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 13:41:49 -0000 Fine, as long as that's not used as an argument that something has already = been implemented and therefore can't be changed. Peter -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stefano Previdi (sprevidi) Sent: Friday, September 13, 2013 9:28 AM To: AshwoodsmithPeter Cc: status@ietf.org Subject: Re: [Status] Updated Merged Charter. Hi Peter, On Sep 13, 2013, at 3:23 PM, AshwoodsmithPeter wrote: > Support, >=20 > However suggest that "Some of the extensions allowing steering of packets= in this manner have already been implemented" is not really relevant to th= e charter as consensus and working code is a back end requirement. indeed. However, it's a way to illustrate that requirements (even if=20 not yet documented) do exist. Obviously, they must be documented=20 appropriately and we are working on it. Thanks for your support. s. >=20 > Peter >=20 > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of Ruediger.Geib@telekom.de > Sent: Friday, September 13, 2013 2:17 AM > To: rjs@rob.sh; robert@raszuk.net; stephane.litkowski@orange.com > Cc: status@ietf.org > Subject: Re: [Status] Updated Merged Charter. >=20 > Rob, Stephane and Robert, >=20 > thanks again for your constructive input. I support your proposal. >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of Rob Shakir > Sent: Friday, September 13, 2013 12:23 AM > To: Robert Raszuk > Cc: Hannes Gredler; status@ietf.org; sprevidi; > Subject: Re: [Status] Updated Merged Charter. >=20 >=20 > On 12 Sep 2013, at 23:19, Robert Raszuk wrote: >=20 >> Apologies ... fixed the below due to copy error: >>=20 >>> I would recommend to rephrase the above: >>>=20 >>> o Having identified use-cases, and developed a framework, the WG will >>> work on proposing a new architectures which substantially improve >>> current technologies and define requirements for extensions or new >>> functionality in existing routing protocols and/or I2RS protocol. >=20 > Hi Robert, >=20 > Sure - I have no problems with this. I think the key is to ensure that we= are working on problems that need solutions, either through omissions of c= urrent technologies, or where there is scope for improvement. I'll merge th= e change. >=20 > On the p2p/p2mp case, I'm not clear that we need to explicitly define thi= s in the charter. The text currently makes no reference to the type of path= , since these should be defined within the use case documents IMHO. >=20 > Updated text is below. >=20 > Thanks, > r. >=20 > Name: >=20 > A number of use cases, including: > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, > o Multi-topology routing (dual planes, disjoint trees), > o Simplification and reduction of signalling, > o Combined application and network-layer path specification. > o Full coverage LFA FRR, > o Topology Aware OAM, > have triggered work on the definition of a new architecture and protocol = extensions, allowing nodes to steer packets through a network, allowing com= bination of well-known shortest-path based routing paradigms with source or= explicit routing methods. Some of the extensions allowing steering of pack= ets in this manner have already been implemented. >=20 > The working group will define an architecture allowing a node = to steer a packet through a network, or set of networks, on any path withou= t requiring state to be maintained by transited nodes (but rather at the so= urce device). The source node may send any packet along a path within the <= Name-TBD> domain through specifying the identifiers referring to this path.= Subsequent downstream nodes along the path within the domain wi= ll forward packets according to the instructions inserted by the head-end. >=20 > Within the architecture, a node may be of any type - including= routers and appliances. A set of such nodes sharing a common trust model f= orm a domain. The architecture defined by this working group wil= l allow steering of packets between any source and destination node within = the domain, which may be formed of one or more networks, on any = path (shortest, non-shortest, explicit, or based on other resources or char= acteristics specified by segment identifiers). >=20 > The architecture should support both centralised and distribut= ed path computation - through both existing routing protocols (IGP, BGP) an= d new approaches to such path calculation. The architecture should also sup= port OAM functions. >=20 > The architecture has been postulated to be applicable to multi= ple data planes (e.g., MPLS, IPv6), and hence the working group should stri= ve to create a single framework which maintains data plane indep= endence where possible. Where use cases are documented, care should be take= n to define the data plane requirements for the environment within which th= ey are to be implemented. The architecture should avoid modifica= tions to the MPLS data-plane, in order to remain compatible with existing e= xtensive deployments of MPLS. >=20 > The working group is chartered for the following (ordered) lis= t of items: > o Identification of use-cases for the architecture for whic= h > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi= ll > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. >=20 > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extens= ions > supporting . >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From stbryant@cisco.com Fri Sep 13 08:24:48 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61121E80CA for ; Fri, 13 Sep 2013 08:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kknO1TzqpZEA for ; Fri, 13 Sep 2013 08:24:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6621E80A7 for ; Fri, 13 Sep 2013 08:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5310; q=dns/txt; s=iport; t=1379085880; x=1380295480; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=t2WmOvNsKiB5D5SaKMKgxw8E19kM2RRMcHPJSnq8POc=; b=ctdJEWXZZIE/b1d52SSFz1Nynxj913Fz6JYLzwNurYiex3XStgQjnE2Y M6NSGJVJ5UWPxRSm69+EyvPAL4sBEMDsNIrfcZAXy84SIjCp4IfkoJI4l 8Uo43SlJUVDA2wh4hnF0BP0Yg84ttZDHh5Zf/iV80j1cbbUcAWHqQ3cOz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAKEtM1KQ/khN/2dsb2JhbABbgwfBeYEaFm0HgmQvBQYEAgEtDxYYAwIBAgE3FA0BBwEBEAeHaKArjCaNZY9xhCUDlB6DXJF0gyU X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208";a="159593136" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2013 15:24:38 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8DFOaqC023205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 15:24:37 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8DFOauT011916; Fri, 13 Sep 2013 16:24:36 +0100 (BST) Message-ID: <52332E33.1040603@cisco.com> Date: Fri, 13 Sep 2013 16:24:35 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "status@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Farrel Subject: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 13 Sep 2013 15:24:49 -0000 Thanks to those that have worked on pulling together the charter text. I now need to check whether there is consensus that this represents the right starting point for the Routing ADs to engage with the list and polish it to the point where we are confident that it will gain the approval of the IESG. Some notes on timeline are appropriate. In order to meet as a WG in Vancouver this needs to be approved for external review at the IESG telechat on 10th October. This means that we have to add it to the agenda by 26th September. This means that we (the Routing ADs) need to have a view that the text of 26th September is likely to be acceptable to both the community and the IESG. It also mean an active dialog with members of the IESG regarding review comments raised in the period up to 10th October. For reference, I am about to put a placeholder for this on the BOF page, in order for an agenda slot to be reserved for this work, hopefully to meet as a WG, but otherwise to meet to finish of the charter. So back to the question, is there consensus that text below is now at the point where the RTG ADs should actively engage to get it ready for IESG approval - yes/no? Thanks Stewart ================= Name: A number of use cases, including: o Path computation based on awareness of utilisation or performance data, within both centralised and distributed environments, o Multi-topology routing (dual planes, disjoint trees), o Simplification and reduction of signalling, o Combined application and network-layer path specification. o Full coverage LFA FRR, o Topology Aware OAM, have triggered work on the definition of a new architecture and protocol extensions, allowing nodes to steer packets through a network, allowing combination of well-known shortest-path based routing paradigms with source or explicit routing methods. Some of the extensions allowing steering of packets in this manner have already been implemented. The working group will define an architecture allowing a node to steer a packet through a network, or set of networks, on any path without requiring state to be maintained by transited nodes (but rather at the source device). The source node may send any packet along a path within the domain through specifying the identifiers referring to this path. Subsequent downstream nodes along the path within the domain will forward packets according to the instructions inserted by the head-end. Within the architecture, a node may be of any type - including routers and appliances. A set of such nodes sharing a common trust model form a domain. The architecture defined by this working group will allow steering of packets between any source and destination node within the domain, which may be formed of one or more networks, on any path (shortest, non-shortest, explicit, or based on other resources or characteristics specified by segment identifiers). The architecture should support both centralised and distributed path computation - through both existing routing protocols (IGP, BGP) and new approaches to such path calculation. The architecture should also support OAM functions. The architecture has been postulated to be applicable to multiple data planes (e.g., MPLS, IPv6), and hence the working group should strive to create a single framework which maintains data plane independence where possible. Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The architecture should avoid modifications to the MPLS data-plane, in order to remain compatible with existing extensive deployments of MPLS. The working group is chartered for the following (ordered) list of items: o Identification of use-cases for the architecture for which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between networks forming the domain). o Having identified use-cases, and developed a framework, the WG will work on proposing a new architectures which substantially improve current technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocols. o The working group will then develop solutions - focusing initially on intra-domain forwarding implementations. Where such solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. The working group will develop the following documents: o One or more documents describing use cases, o A architecture, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensions supporting . ============== From rjs@rob.sh Fri Sep 13 08:40:29 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D0811E8170 for ; Fri, 13 Sep 2013 08:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZxC5YQLIX0G for ; Fri, 13 Sep 2013 08:40:29 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 0254F11E812F for ; Fri, 13 Sep 2013 08:40:29 -0700 (PDT) Received: from [109.144.242.114] (helo=[10.248.26.84]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VKVT1-0005c6-Vo; Fri, 13 Sep 2013 16:39:32 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <52332E33.1040603@cisco.com> Date: Fri, 13 Sep 2013 16:40:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9103CF62-CE9A-4677-8A93-BCC7D0C8E08B@rob.sh> References: <52332E33.1040603@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1508) Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 15:40:29 -0000 Hi Stewart, On 13 Sep 2013, at 16:24, Stewart Bryant wrote: > So back to the question, is there consensus that text > below is now at the point where the RTG ADs should > actively engage to get it ready for IESG approval > - yes/no? Thanks, I believe that this charter is ready for the examination of the = routing ADs, and forward for IESG approval. Kind regards, r.=20= From sprevidi@cisco.com Fri Sep 13 10:54:04 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB7F21F9F31 for ; Fri, 13 Sep 2013 10:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr+7Fod-mwk1 for ; Fri, 13 Sep 2013 10:53:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA121F9D94 for ; Fri, 13 Sep 2013 10:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4719; q=dns/txt; s=iport; t=1379094825; x=1380304425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fNbNg9Gp2hYIiE0n3Yxs9+sd0ocQ8+USKwTrRfAWSFg=; b=UuUdWmIH0jR+Nnxo4ERQjfYlbmVVuJswzwdCnQD7dMxZYLghsoggrg5D 8V5vOXX2EjLeCzSZoMyFJdVqAugE/yaHK76QJw+ZpVo6sWP0OITwu3ILd 4VhkMc4ZNJCyyTup0P9nRLN7hPlWqetqqEpzbS4wC47QnAp4ljCxCcToD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAM5QM1KtJV2b/2dsb2JhbABbgwc4RgzAdYEcFnSCJQEBAQMBAQEBNy0HBAcQAgEIEgYKFBAnCxcOAgQOBQgTh2IGDKwEjT0Ejz4CMQeDHoEAA5QelVCDJIIq X-IronPort-AV: E=Sophos;i="4.90,899,1371081600"; d="scan'208";a="259480498" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 13 Sep 2013 17:53:34 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8DHrYhJ022308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 17:53:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 12:53:33 -0500 From: "Stefano Previdi (sprevidi)" To: "Stewart Bryant (stbryant)" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVoHimsYDaTXkKT2SnKgr9E2ZnERvgA Date: Fri, 13 Sep 2013 17:53:33 +0000 Message-ID: References: <52332E33.1040603@cisco.com> In-Reply-To: <52332E33.1040603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.169.242] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 17:54:05 -0000 On Sep 13, 2013, at 5:24 PM, Stewart Bryant wrote: >=20 > So back to the question, is there consensus that text > below is now at the point where the RTG ADs should > actively engage to get it ready for IESG approval > - yes/no? yes. s. >=20 > Thanks >=20 > Stewart >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Name: >=20 > A number of use cases, including: > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, > o Multi-topology routing (dual planes, disjoint trees), > o Simplification and reduction of signalling, > o Combined application and network-layer path specification. > o Full coverage LFA FRR, > o Topology Aware OAM, > have triggered work on the definition of a new architecture and protocol = extensions, allowing nodes to steer packets through a network, allowing com= bination of well-known shortest-path based routing paradigms with source or= explicit routing methods. Some of the extensions allowing steering of pack= ets in this manner have already been implemented. >=20 > The working group will define an architecture allowing a node = to steer a packet through a network, or set of networks, on any path withou= t requiring state to be maintained by transited nodes (but rather at the so= urce device). The source node may send any packet along a path within the <= Name-TBD> domain through specifying the identifiers referring to this path.= Subsequent downstream nodes along the path within the domain wi= ll forward packets according to the instructions inserted by the head-end. >=20 > Within the architecture, a node may be of any type - including= routers and appliances. A set of such nodes sharing a common trust model f= orm a domain. The architecture defined by this working group wil= l allow steering of packets between any source and destination node within = the domain, which may be formed of one or more networks, on any = path (shortest, non-shortest, explicit, or based on other resources or char= acteristics specified by segment identifiers). >=20 > The architecture should support both centralised and distribut= ed path computation - through both existing routing protocols (IGP, BGP) an= d new approaches to such path calculation. The architecture should also sup= port OAM functions. >=20 > The architecture has been postulated to be applicable to multi= ple data planes (e.g., MPLS, IPv6), and hence the working group should stri= ve to create a single framework which maintains data plane indep= endence where possible. Where use cases are documented, care should be take= n to define the data plane requirements for the environment within which th= ey are to be implemented. The architecture should avoid modifica= tions to the MPLS data-plane, in order to remain compatible with existing e= xtensive deployments of MPLS. >=20 > The working group is chartered for the following (ordered) lis= t of items: > o Identification of use-cases for the architecture for whic= h > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi= ll > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extens= ions > supporting . > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From victor@jvknet.com Fri Sep 13 11:13:44 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1E21F9FD5 for ; Fri, 13 Sep 2013 11:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVcLDZtjmJQ1 for ; Fri, 13 Sep 2013 11:13:39 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4506321F9D62 for ; Fri, 13 Sep 2013 11:13:38 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so1189903wid.15 for ; Fri, 13 Sep 2013 11:13:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UbHh0/drh/2O47f/z6Xe4mmmI52hAiNU3UisVAXI2jk=; b=gk7l1/Ova8Tww77v2aW2HvZn7X5MlEHjlIfxa+4aPuHRmeCJZdHO6wcBQPEVFANct7 8t/7iM093ElLumgnM7dUdo5UkEMeDQIHLNkX5LLeu4BUM/Yy/Cy380octqyQShs6X4sU 65LszcH0IrpTjvEeJJsxJlP/WcpMU61MErAImhA0pJ8UgLr6cXiaW0k8HKrNGPh7lmMb Bas9ZN+3aeZgXv5fyQJzmN8KM2kkSQAu0CWSJvQeRPeqjOCUsL9XxKj/Vv5neEm77ZkK Kg6y3BF9daBlAwRz3V7ZIGp/oVlDHDeuMwb16N3Xl3T6fwFnMPXGWWv6P3yu7O2MD2ap 1Cow== X-Gm-Message-State: ALoCoQl/1z41vegITozv57fukPMCtr9EZJm/VMTt3Z/RJsdkJgXCNaoSm9n1SyQRvBNo4IBe/re3 MIME-Version: 1.0 X-Received: by 10.180.90.197 with SMTP id by5mr3555030wib.43.1379096015227; Fri, 13 Sep 2013 11:13:35 -0700 (PDT) Received: by 10.216.255.19 with HTTP; Fri, 13 Sep 2013 11:13:35 -0700 (PDT) X-Originating-IP: [24.114.255.99] In-Reply-To: References: <13008b9cfd934647ab76a0326623ee1a@BY2PR05MB142.namprd05.prod.outlook.com> <25959_1378213600_5225DEE0_25959_4505_1_EEE55384044474429A926C625D0FCC810962D1E5E2@PUEXCB2F.nanterre.francetelecom.fr> <3E259A28-6157-4794-8769-0437A3183A21@huawei.com> <1808_1378219408_5225F590_1808_18992_1_EEE55384044474429A926C625D0FCC810962D1E707@PUEXCB2F.nanterre.francetelecom.fr> <7AE6A4247B044C4ABE0A5B6BF427F8E2098E387A@dfweml513-mbb.china.huawei.com> <522600E0.8050004@pi.nu> <84F91B33-5976-455B-B1C3-7AAA6C546903@juniper.net> <27969_1378281767_5226E927_27969_18473_1_EEE55384044474429A926C625D0FCC810963161A7F@PUEXCB2F.nanterre.francetelecom.fr> <6ABDA90D-560D-49D4-A76C-578A0AEE9E25@juniper.net> <30399_1378803008_522EDD40_30399_3914_1_EEE55384044474429A926C625D0FCC810964DEC454@PUEXCB2F.nanterre.francetelecom.fr> <79F0BC80-54A4-489F-A525-6DFBDDDFD1C4@rob.sh> <4756_1378804741_522EE405_4756_115_1_EEE55384044474429A926C625D0FCC810964DEC490@PUEXCB2F.nanterre.francetelecom.fr> <4139_1378812306_522F0192_4139_1368_1_EEE55384044474429A926C625D0FCC810964DEC54F@PUEXCB2F.nanterre.francetelecom.fr> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0820D255@NKGEML512-MBS.china.huawei.com> Date: Fri, 13 Sep 2013 14:13:35 -0400 Message-ID: From: Victor Kuarsingh To: "Stefano Previdi (sprevidi)" Content-Type: multipart/alternative; boundary=f46d0438eb6d19653f04e647d07c Cc: Stephane Litkowski , Xuxiaohu , Rob Shakir , "status@ietf.org" , Hannes Gredler Subject: Re: [Status] Good charter proposals from Hannes and Stefano : try to merge ... X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 18:13:44 -0000 --f46d0438eb6d19653f04e647d07c Content-Type: text/plain; charset=ISO-8859-1 Stefano/Xiaohu, On Wed, Sep 11, 2013 at 6:37 AM, Stefano Previdi (sprevidi) < sprevidi@cisco.com> wrote: > > > > > I don't think it's suitable to mention developing IPv6 specific SR > mechanism in the current charter unless there is no requirement for any > change to the existing IPv6 data plane. > > > According to the following statements quoted from > http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00#page-9, > "...The source route is encoded as an ordered list of segments instead of > IP addresses..." If so, why not directly use an ordered list of labels > (i.e., MPLS label stack) to do that (see > http://www.ietf.org/mail-archive/web/status/current/msg00165.html)? > > > v6 dataplane allows more effective source route capability by > leveraging extensions headers. Hence the proposal that will > consist of defining a new Extension Header for SR where the > segment list is encoded and _preserved_ throughout the path. > > So, I do strongly believe we have to work on v6 and since we're > in the definition of a charter (i.e.: not the detailed review > of the solutions) I believe v6 should be part of it. > > [VK]. I strongly agree that we should be including v6 work within the charter. As noted at the BoF in Berlin, I made similar comments (along with at least one other operator) of the need for this. I think discounting a v6 data plan option at this point is premature and will be ignoring input from operators which provided use case(s). We should include it. Regards, Victor K > Thanks. > s. > > > > --f46d0438eb6d19653f04e647d07c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stefano/Xiaohu,


On Wed, Sep 11, 2013 at 6:37 AM, Stefano Previdi (sprevi= di) <sprevidi@cisco.com> wrote:

>
> I don't think it's suitable to mention developing IPv6 specifi= c SR mechanism in the current charter unless there is no requirement for an= y change to the existing IPv6 data plane.

> According to the following statements quoted from http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00= #page-9, "...The source route is encoded as an ordered list of seg= ments instead of IP addresses..." If so, why not directly use an order= ed list of labels (i.e., MPLS label stack) to do that (see http://www.ietf.org/mail-archive/web/status/current/msg00165.html)= ?


v6 dataplane allows more effective source route capability by
leveraging extensions headers. Hence the proposal that will
consist of defining a new Extension Header for SR where the
segment list is encoded and _preserved_ throughout the path.

So, I do strongly believe we have to work on v6 and since we're
in the definition of a charter (i.e.: not the detailed review
of the solutions) I believe v6 should be part of it.


[VK].=A0=A0I strongly agree that we should be including v6 wo= rk within the

charter.=A0=A0As noted at the BoF in Berlin,= I made similar comments (along

with at least one other op= erator) of the need for this.


I think discounting a v6 data plan opti= on at this point is premature and

will be ignoring input f= rom operators which provided use case(s).


We should include it.


Regards,


Victor K



=A0<= /div>
Thanks.
s.




--f46d0438eb6d19653f04e647d07c-- From rraszuk@gmail.com Fri Sep 13 11:14:02 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20C11E81B6 for ; Fri, 13 Sep 2013 11:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7RCSe-APXP4 for ; Fri, 13 Sep 2013 11:14:01 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C5E2811E81B1 for ; Fri, 13 Sep 2013 11:14:01 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so3277973iet.33 for ; Fri, 13 Sep 2013 11:14: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=Ukv8+aCwQU+7krCf0GW9JwR8yHWgPl6urudGYc6Oaf4=; b=nWcitblJo0aIjq4D59HZ8E6XeVyoDRkZndP0x9a4TGZKyGcoGvBshMPeUr2xE0MmTm y98al7x8xAYm2L2WdA9AWB6+prcsaKMeBAEZ9Ds9u/sSlHD7I26MsSsrFeWTjRVg6Pq1 CkWx+XL4Pe+XRZyQn3B1YFXA6b2cwv8fU9dVRRwZ9QBnYXVxQppZ+REBMLpFDf6TbZC8 hbKY25HSiYkVzjtcArx4g9L9I48sZ0vAfgN/itz2XXrDchMWFkmPRKnVqAl0GDHtNVmi K4bSjxW2AiTrB4YGvJJShuIrPEiVUoUOLbfRoDBpAt/jepHBDSFqC18fcLyf6d3pbQAl zbWg== MIME-Version: 1.0 X-Received: by 10.50.114.168 with SMTP id jh8mr1829262igb.6.1379096041385; Fri, 13 Sep 2013 11:14:01 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Fri, 13 Sep 2013 11:14:01 -0700 (PDT) In-Reply-To: <52332E33.1040603@cisco.com> References: <52332E33.1040603@cisco.com> Date: Fri, 13 Sep 2013 20:14:01 +0200 X-Google-Sender-Auth: TctU8Hs4kTr1RECBnPuyF9IAGk0 Message-ID: From: Robert Raszuk To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 18:14:02 -0000 > - yes/no? Yes. Thx, R. From jgs@juniper.net Sun Sep 15 14:10:45 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60E11E81D5 for ; Sun, 15 Sep 2013 14:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=2.970, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoBLsA+P63La for ; Sun, 15 Sep 2013 14:10:39 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB7311E81C6 for ; Sun, 15 Sep 2013 14:10:38 -0700 (PDT) Received: from mail203-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.22; Sun, 15 Sep 2013 21:10:35 +0000 Received: from mail203-co9 (localhost [127.0.0.1]) by mail203-co9-R.bigfish.com (Postfix) with ESMTP id 61B648A00F7; Sun, 15 Sep 2013 21:10:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zz98dI9371I1432I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1de097h8275bhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail203-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(51444003)(189002)(377454003)(199002)(24454002)(51704005)(74662001)(57306001)(65816001)(79102001)(74706001)(76482001)(81342001)(47446002)(82746002)(62966002)(69226001)(77156001)(42186004)(54316002)(53806001)(47776003)(56776001)(74502001)(46406003)(81542001)(74366001)(19580395003)(50466002)(80022001)(77982001)(47736001)(56816003)(66066001)(49866001)(46102001)(31966008)(47976001)(23726002)(59766001)(50986001)(81816001)(83072001)(81686001)(33656001)(76796001)(19580405001)(80976001)(51856001)(74876001)(63696002)(50226001)(4396001)(83322001)(36756003)(77096001)(76786001)(83716001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:[172.28.131.154]; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail203-co9 (localhost.localdomain [127.0.0.1]) by mail203-co9 (MessageSwitch) id 1379279393883206_28230; Sun, 15 Sep 2013 21:09:53 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.251]) by mail203-co9.bigfish.com (Postfix) with ESMTP id D1CCA580042; Sun, 15 Sep 2013 21:09:53 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 15 Sep 2013 21:09:52 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Sun, 15 Sep 2013 21:09:49 +0000 Received: from [172.28.131.154] (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.745.25; Sun, 15 Sep 2013 21:09:46 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <52332E33.1040603@cisco.com> Date: Sun, 15 Sep 2013 17:09:34 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> References: <52332E33.1040603@cisco.com> To: X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: DM2PR07CA003.namprd07.prod.outlook.com (10.141.96.50) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 0970508454 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 21:10:45 -0000 Stewart, I have a number of mostly-editorial comments. They're in line below. = There is one substantive but relatively small change, which is called = out. I've appended a version of the draft charter that consolidates my = proposed edits, at the bottom. Going through the exercise of doing this has reminded me of one = significant concern, though. The first work item for the WG in the = proposed charter is: o Identification of use-cases for the architecture for which there is consensus within the WG. This leads to the simple question: until we've identified use cases, how = can we say we need a new architecture? We are presupposing the outcome. = If the agreed use cases end up being things that are supportable within = the existing MPLS architecture, that is great. Note I'm not saying the = use cases shouldn't be addressed, merely that their solutions may, or = may not, rise to the level of "architecture". I would be interested in = discussion of this question before we close on a charter. The rest is in line below. On Sep 13, 2013, at 11:24 AM, Stewart Bryant wrote: > Thanks to those that have worked on pulling together the > charter text. >=20 > I now need to check whether there is consensus that this > represents the right starting point for the Routing ADs > to engage with the list and polish it to the point where > we are confident that it will gain the approval of the IESG. >=20 > Some notes on timeline are appropriate. In order to meet > as a WG in Vancouver this needs to be approved for > external review at the IESG telechat on 10th October. > This means that we have to add it to the agenda by 26th > September. This means that we (the Routing ADs) need > to have a view that the text of 26th September is likely > to be acceptable to both the community and the IESG. > It also mean an active dialog with members of the IESG > regarding review comments raised in the period up to > 10th October. >=20 > For reference, I am about to put a placeholder for this > on the BOF page, in order for an agenda slot to be > reserved for this work, hopefully to meet as a WG, > but otherwise to meet to finish of the charter. >=20 > So back to the question, is there consensus that text > below is now at the point where the RTG ADs should > actively engage to get it ready for IESG approval > - yes/no? >=20 > Thanks >=20 > Stewart >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Name: >=20 > A number of use cases, including: > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, > o Multi-topology routing (dual planes, disjoint trees), > o Simplification and reduction of signalling, > o Combined application and network-layer path specification. > o Full coverage LFA FRR, > o Topology Aware OAM, > have triggered work on the definition of a new architecture and = protocol extensions, allowing nodes to steer packets through a network, = allowing combination of well-known shortest-path based routing paradigms = with source or explicit routing methods. Some of the extensions allowing = steering of packets in this manner have already been implemented. The foregoing does/did add something to the mailing list discussion, but = I think should be omitted from the charter. After all, the first work = item listed in the charter is exactly to produce a list of "use-cases = ... for which there is consensus". By definition there can't be any = consensus in the WG yet since there is no WG yet. This is an easy edit; = the charter reads just fine starting from the below paragraph and there = are no normative (as it were) changes. (Also, an editorial nit: "use case" is conventionally not hyphenated -- = a search-and-replace will fix this.) > The working group will define an architecture allowing a = node to steer a packet through a network, or set of networks, on any = path without requiring state to be maintained by transited nodes (but = rather at the source device). The source node may send any packet along = a path within the domain through specifying the identifiers = referring to this path. Subsequent downstream nodes along the path = within the domain will forward packets according to the = instructions inserted by the head-end. >=20 > Within the architecture, a node may be of any type - = including routers and appliances. A set of such nodes sharing a common = trust model form a domain. The architecture defined by this = working group will allow steering of packets between any source and = destination node within the domain, which may be formed of = one or more networks, on any path (shortest, non-shortest, explicit, or = based on other resources or characteristics specified by segment = identifiers). The two forgoing paragraphs have a lot of redundancy, probably due to = the multiple revision cycles they've been through. Here is a potential = rewrite merging the two but attempting to maintain all the content: The working group will define an architecture that will allow = a node to steer a packet between any source and destination through a = domain on any path without requiring state to be maintained = by transited nodes, but rather at the source device. A domain = is a network or set of networks comprised of nodes (which may be of any = type, including routers and appliances) that share a common trust model. = The path may be shortest, non-shortest, explicit, or based on other = resources or characteristics specified by segment identifiers. Some comments on this -- - I'm not actually sure what "set of networks" really adds. AFAIK it has = no well-defined meaning distinct from that of "network". - I don't think the final sentence actually adds anything since the = first sentence says "any path" and "any" takes in the entire universe of = possibilities already. The final sentence also uses the term "segment = identifiers" which is not defined in the charter. IMO neither of these actually detracts (other than the undefined term), = but neither do they add, so my preference would be to leave them out (I = generally favor the "perfection is achieved, not when there is nothing = more to add, but when there is nothing left to take away" heuristic). = So: The working group will define an architecture that will allow = a node to steer a packet between any source and destination through a = domain on any path without requiring state to be maintained = by transited nodes, but rather at the source device. A domain = is a network comprised of nodes (which may be of any type, including = routers and appliances) that share a common trust model. I actually think "which may be of any type, including routers and = appliances" is in the same category (it's implicit) but I realize that = others will probably disagree so I haven't proposed eliding it. I'd be = happy to though, if I am mistaken. > The architecture should support both centralised and = distributed path computation - through both existing routing protocols = (IGP, BGP) and new approaches to such path calculation. The architecture = should also support OAM functions. The first sentence is puzzlingly broad, especially when you get to "... = and new approaches to path calculation." The best I can parse it is "we = haven't decided how to do this yet but everything should be on the = table". I think it could be trimmed to "The architecture = should support both centralised and distributed path computation" = without loss of generality. > The architecture has been postulated to be applicable to = multiple data planes (e.g., MPLS, IPv6), and hence=20 The paragraphs preceding this one state that the WG will define the = architecture. This means that by definition there isn't a = architecture yet. As such I don't see how it can be = postulated to be much of anything, and would suggest that the foregoing = clause be cut. I think that again, this can be done without loss of = generality since the following text captures the intent. > the working group should strive to create a single = framework which maintains data plane independence where possible. Where = use cases are documented, care should be taken to define the data plane = requirements for the environment within which they are to be = implemented. The architecture should avoid modifications to = the MPLS data-plane, in order to remain compatible with existing = extensive deployments of MPLS. I suggest adding "It is anticipated the architecture may need = to propose modifications to the IPv6 data plane." (One could use = "extensions" in place of "modifications", though I prefer it as = written.) I also suggest that a work item be added, o Document impact (if any) of any proposed IPv6 data plane = modifications =20 on existing deployment of IPv6. I believe this is the only substantive change I've proposed, the rest = being editorial. > The working group is chartered for the following (ordered) = list of items: > o Identification of use-cases for the architecture for = which > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between = networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve "a new architecture that substantially improves upon" > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. I'm a little confused why all routing protocols would be taken in but = only i2rs among management protocols, and besides isn't it still TBD if = i2rs will even end up defining a protocol? Thus, how about "existing = routing and management protocols"? > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will > be done in conjunction with the responsible IETF working group. = Work > on new protocols may be carried out by the working = group. > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of = extensions > supporting . Finally I have a question, or observation: Where we are talking about = modifying/extending a data plane (IPv6) there may be implications to = inter-domain forwarding. Thus the initial focus on intra-domain = forwarding, above, is a little concerning -- one can easily imagine a = sequence like - Define intra-domain forwarding, - Define new v6 data plane, - Publish specs, - Recharter to include inter-domain,=20 - Define inter-domain forwarding, - Oops, we need to further extend the v6 data plane. Since the cost of extending the v6 data plane may end up being = non-trivial, it seems as though it would be desirable to avoid this kind = of iteration. Do others agree and if so how should we capture this in = the charter? Thanks, --John Consolidated edits below: ------------------ Name: The working group will define an architecture that will allow = a node to steer a packet between any source and destination through a = domain on any path without requiring state to be maintained = by transited nodes, but rather at the source device. A domain = is a network comprised of nodes (which may be of any type, including = routers and appliances) that share a common trust model. The architecture should support both centralised and = distributed path computation. The architecture should also support OAM = functions. The working group should strive to create a single framework = which maintains data plane independence where possible. Where use cases = are documented, care should be taken to define the data plane = requirements for the environment within which they are to be = implemented. The architecture should avoid modifications to = the MPLS data-plane, in order to remain compatible with existing = extensive deployments of MPLS. It is anticipated the = architecture may need to propose modifications to the IPv6 data plane. The working group is chartered for the following (ordered) = list of items: o Identification of use-cases for the architecture for which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between networks forming the domain). o Having identified use-cases, and developed a framework, the WG will work on proposing a new architectures which substantially improve current technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocols. o The working group will then develop solutions - focusing initially on intra-domain forwarding implementations. Where such solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. The working group will develop the following documents: o One or more documents describing use cases, o A architecture, o Document impact (if any) of any proposed IPv6 data plane = modifications =20 on existing deployment of IPv6, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of = extensions supporting . ------------------= From aretana@cisco.com Sun Sep 15 15:51:52 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0FD11E8150 for ; Sun, 15 Sep 2013 15:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAKKbMEJlwJ2 for ; Sun, 15 Sep 2013 15:51:47 -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 0ED8411E810F for ; Sun, 15 Sep 2013 15:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2211; q=dns/txt; s=iport; t=1379285507; x=1380495107; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=K/zgu0+Rc52l94Lkig+SPQ3nwe4xTNmcNCjoqlxqwLM=; b=XsOZJsW/H6ida0/d2mbjWnSsLktAXRztx8yXH/PIkT9AQmK6TUoBNhym IvakT4/1AiSwQl885Do3MPpvZ02WbVG2bOucyJoqIx/j0NGrHkIO3LiH3 eJDRXKL6Owr2IorbsexH5BXEqoC+oibekGEnCzLcK+ZLvcsmfDsrR1sPQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFALE4NlKtJXHB/2dsb2JhbABbgweBCsB1gRgWdIIlAQEBAwE6LQsHBQ0BCBIQFEIXDgIEAQ0FCBOHYga5SY9CMQeDHoEAA5QflVCDJIIq X-IronPort-AV: E=Sophos;i="4.90,911,1371081600"; d="scan'208";a="260037604" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 15 Sep 2013 22:51:46 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8FMpkAL025293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Sep 2013 22:51:46 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.123]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Sun, 15 Sep 2013 17:51:46 -0500 From: "Alvaro Retana (aretana)" To: "Stewart Bryant (stbryant)" , "status@ietf.org" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVoa7hzUcgo6EeudVAw+jQ3xJnHe+SA Date: Sun, 15 Sep 2013 22:51:45 +0000 Message-ID: In-Reply-To: <52332E33.1040603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.61] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 22:51:52 -0000 On 9/13/13 9:24 AM, "Stewart Bryant (stbryant)" wrote: Stewart: Hi! Just a couple of comments: ... >The working group is chartered for the following (ordered) >list of items: What do we mean by "ordered"? I guess that it is just referring to the "natural" order of things: define use cases, architecture, solutions, etc..which is obvious to me. I may have not been paying close attention, but I haven't seen "ordered" mentioned in other WG charters. There was some discussion on the list about the order of events and the milestones between them. I just want to make sure that "ordered" does not have different meanings to different people. > o Identification of use-cases for the architecture for >which > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between >networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this >will > be done in conjunction with the responsible IETF working group. >Work > on new protocols may be carried out by the working >group. > =20 >The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of >extensions > supporting . Comparing the list of items to the documents, I think we're missing an architectural framework document. Thanks! Alvaro. From mark@townsley.net Sun Sep 15 18:00:21 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291F711E80FF for ; Sun, 15 Sep 2013 18:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h25hGZtr2p2P for ; Sun, 15 Sep 2013 18:00:16 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 327D811E8179 for ; Sun, 15 Sep 2013 18:00:15 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id m15so3016697wgh.31 for ; Sun, 15 Sep 2013 18:00:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ve0bnJlYpexEN7qIdSANZvPDj4eUqh7LcH0IRyBVxZ8=; b=gr+z+69CbSx/bcG8tJJvzLOjB5xq/TsQbLZvv8Iq7gOOeSs/dFFpHmQDEr7rhygDjP DJlICIy/6qmUSimMm3mUwsmUruX7X2dxkdwrQJjz0eoJ56NtP/Daghsp7rMDLZZACfqp jrp07gJSK/uv0QOC8MbY+RrCORXEdboDgq6q+M3jgSnaLVRJQVJNMKhRzU2bSnGRY61U rLx1Tm9FOyRYSFTeSv9ftA2yb/fTjvjCE61SwJhHCdi+2S9p/+2kW8DoQuuJXwAqf2D0 TsGV4YE2+iqGiOwHG9RH49ePmkxA8496kDjEA27g4VsEj0jQx6Y+rGjmEk76qNbMyTcx TBjA== X-Gm-Message-State: ALoCoQnnru8zvqi6BT9pTE9ofdovrkJIyEGRGYhXAKNrKif5zeSxOhWATToQW/9qTa4+DrkN3A1h X-Received: by 10.194.20.170 with SMTP id o10mr19858167wje.4.1379293215192; Sun, 15 Sep 2013 18:00:15 -0700 (PDT) Received: from marks-mac-mini.home (AMontsouris-653-1-108-254.w82-123.abo.wanadoo.fr. [82.123.163.254]) by mx.google.com with ESMTPSA id ey4sm19794921wic.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 18:00:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 16 Sep 2013 03:00:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16A45307-2E10-4922-9333-B70EA7C467C3@townsley.net> References: To: Alvaro Retana (aretana) X-Mailer: Apple Mail (2.1283) Cc: Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 01:00:22 -0000 On Sep 16, 2013, at 12:51 AM, Alvaro Retana (aretana) wrote: >>=20 >> The working group will develop the following documents: >> o One or more documents describing use cases, >> o A architecture, >> o A set of one or more protocol extensions requirements documents, >> o Inter-operability reports pertaining to the implementation of >> extensions >> supporting . >=20 > Comparing the list of items to the documents, I think we're missing an > architectural framework document. I hope we are not setting ourselves up for an architectural framework = *and* architecture document though (on top of the obligatory use-case = documents). One architecture document (which itself certainly would need = to provide a solution framework) should suffice. I understand how the = charter as written leads the reader on to think these are separate, = let's fix that instead. - Mark=20 >=20 > Thanks! >=20 > Alvaro. >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From aretana@cisco.com Sun Sep 15 18:07:53 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0B11E817F for ; Sun, 15 Sep 2013 18:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdl97JvWHs79 for ; Sun, 15 Sep 2013 18:07:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4FA11E80FF for ; Sun, 15 Sep 2013 18:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=590; q=dns/txt; s=iport; t=1379293667; x=1380503267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FtiO+bxD7IYDhtGyop5V6wyUdG9zbbPcacIx/1nO258=; b=ffIyoic1Tx3IW0Dbg+CPt+pcvni4rvrqeGH6WLrQttzhnioDgfBWjADS yORIwzaM6rApYfjV3YTyeSHcNxkU8BVkt9aSIRjoIoCLSaGY3cdc0ixzt nArahiFGiAWH3agDWo9B3/NxHekdcbPRVTCgYxDvSrzdh/N84NKem0JSk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAEhZNlKtJXHB/2dsb2JhbABbgweDbb4SgRoWdIIlAQEBAwE6PwULAgEIEiQQMhcOAgQOBRuHYga5UY9AMweDHoEAA5d7kXSDJA X-IronPort-AV: E=Sophos;i="4.90,911,1371081600"; d="scan'208";a="259875455" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 16 Sep 2013 01:07:46 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8G17kvi005990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 01:07:46 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.123]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Sun, 15 Sep 2013 20:07:46 -0500 From: "Alvaro Retana (aretana)" To: Mark Townsley Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVoa7hzUcgo6EeudVAw+jQ3xJnHe+SAgABm84D//65L2g== Date: Mon, 16 Sep 2013 01:07:45 +0000 Message-ID: References: , <16A45307-2E10-4922-9333-B70EA7C467C3@townsley.net> In-Reply-To: <16A45307-2E10-4922-9333-B70EA7C467C3@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 01:07:53 -0000 That works for me. The point was more about pointing at the differences. Thanks! Alvaro. Sent from my iPhone On Sep 15, 2013, at 9:00 PM, "Mark Townsley" wrote: > I hope we are not setting ourselves up for an architectural framework *an= d* architecture document though (on top of the obligatory use-case document= s). One architecture document (which itself certainly would need to provide= a solution framework) should suffice. I understand how the charter as writ= ten leads the reader on to think these are separate, let's fix that instead= . From mark@townsley.net Sun Sep 15 18:23:00 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8911E8189 for ; Sun, 15 Sep 2013 18:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt0P9NSLSOEW for ; Sun, 15 Sep 2013 18:22:55 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D311E8181 for ; Sun, 15 Sep 2013 18:22:54 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so3011176wes.2 for ; Sun, 15 Sep 2013 18:22:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IecHFyCQER7afmlQ2csx0G25PYzXwy+eTqIJnE8Ah0Q=; b=L8VMezGF0Ft1Ya1v/T6JSTp9iK/8BA8IWBqhV7fKcjoadTaIE5kZ59lP8mk6XNYQ/F ia5lE8umKRyo3X6AIF5If48F4hOPMI3Yoy4FJdAxmBvJ9hoxMRSOYVYSSZTuKgpJlAPi fPZAZRfeliuuRDofO6wUbHy7oi2z3q/H4Ux5mFXAjyLEmLANFTP5mlS3IdCNlcBpSfAp lF7EU32LSkdxidttDbjjUVUOeg9kRDq4jhN6DJ+tb4oMlBpefAlVEkmluar++yBtWHqR Vt0PlVa6KbhVGPjzgj0PcLFqWmOIKB8UuDrL+61R7lnvf38J/y0sjn7MNQJNXlml7VRv Ub/Q== X-Gm-Message-State: ALoCoQlI3LWvsm1qyydKTJtAFtkf0QITolX2CsVNblpbvnslhSsQb75P+wSV8uIMUc9BaKaZr4zi X-Received: by 10.180.188.49 with SMTP id fx17mr11281338wic.49.1379294574023; Sun, 15 Sep 2013 18:22:54 -0700 (PDT) Received: from marks-mac-mini.home (AMontsouris-653-1-108-254.w82-123.abo.wanadoo.fr. [82.123.163.254]) by mx.google.com with ESMTPSA id b11sm19857419wik.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 18:22:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> Date: Mon, 16 Sep 2013 03:22:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73658A40-3E2D-4E68-92C7-3AFD9B392078@townsley.net> References: <52332E33.1040603@cisco.com> <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> To: John G. Scudder X-Mailer: Apple Mail (2.1283) Cc: Adrian Farrel , "status@ietf.org" , stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 01:23:00 -0000 On Sep 15, 2013, at 11:09 PM, John G. Scudder wrote: > Stewart, >=20 > I have a number of mostly-editorial comments. They're in line below. = There is one substantive but relatively small change, which is called = out. I've appended a version of the draft charter that consolidates my = proposed edits, at the bottom. >=20 > Going through the exercise of doing this has reminded me of one = significant concern, though. The first work item for the WG in the = proposed charter is: >=20 > o Identification of use-cases for the architecture for = which > there is consensus within the WG. >=20 > This leads to the simple question: until we've identified use cases, = how can we say we need a new architecture? We are presupposing the = outcome. If the agreed use cases end up being things that are = supportable within the existing MPLS architecture, that is great. Note = I'm not saying the use cases shouldn't be addressed, merely that their = solutions may, or may not, rise to the level of "architecture". I would = be interested in discussion of this question before we close on a = charter. Also, there is the suggestion in the current text that "new = architectures" will "substantially improve current technologies" .. I = don't see how an architecture on its own can do a thing to improve = current technology, it only provides a framework to operate in so that = technological improvements can be made. Let me suggest some text to be = completely clear (which also incorporates another suggestion from John = Scudder) OLD: The working group is chartered for the following (ordered) = list of items: o Identification of use-cases for the architecture for = which there is consensus within the WG. o Definition of an architectural framework, which must cover security considerations (including the relationship between = networks forming the domain). o Having identified use-cases, and developed a framework, the WG will work on proposing a new architectures which substantially improve current technologies and define requirements for extensions or new functionality in existing routing protocols and/or I2RS protocols. NEW: The working group is chartered for the following items: o Identification and evaluation of use-cases =20 o Definition of a Architecture, driven by the use cases and = underlying technology=20 o The Architecture must cover security considerations = (including the relationship between networks forming the = domain) and allow for solutions which substantially improve upon current = technologies by defining requirements, extensions, or new functionality = in existing routing, l2rs or other protocols. Thanks, - Mark >=20 > The rest is in line below. >=20 > On Sep 13, 2013, at 11:24 AM, Stewart Bryant = wrote: >=20 >> Thanks to those that have worked on pulling together the >> charter text. >>=20 >> I now need to check whether there is consensus that this >> represents the right starting point for the Routing ADs >> to engage with the list and polish it to the point where >> we are confident that it will gain the approval of the IESG. >>=20 >> Some notes on timeline are appropriate. In order to meet >> as a WG in Vancouver this needs to be approved for >> external review at the IESG telechat on 10th October. >> This means that we have to add it to the agenda by 26th >> September. This means that we (the Routing ADs) need >> to have a view that the text of 26th September is likely >> to be acceptable to both the community and the IESG. >> It also mean an active dialog with members of the IESG >> regarding review comments raised in the period up to >> 10th October. >>=20 >> For reference, I am about to put a placeholder for this >> on the BOF page, in order for an agenda slot to be >> reserved for this work, hopefully to meet as a WG, >> but otherwise to meet to finish of the charter. >>=20 >> So back to the question, is there consensus that text >> below is now at the point where the RTG ADs should >> actively engage to get it ready for IESG approval >> - yes/no? >>=20 >> Thanks >>=20 >> Stewart >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Name: >>=20 >> A number of use cases, including: >> o Path computation based on awareness of utilisation or performance >> data, within both centralised and distributed environments, >> o Multi-topology routing (dual planes, disjoint trees), >> o Simplification and reduction of signalling, >> o Combined application and network-layer path specification. >> o Full coverage LFA FRR, >> o Topology Aware OAM, >> have triggered work on the definition of a new architecture and = protocol extensions, allowing nodes to steer packets through a network, = allowing combination of well-known shortest-path based routing paradigms = with source or explicit routing methods. Some of the extensions allowing = steering of packets in this manner have already been implemented. >=20 > The foregoing does/did add something to the mailing list discussion, = but I think should be omitted from the charter. After all, the first = work item listed in the charter is exactly to produce a list of = "use-cases ... for which there is consensus". By definition there can't = be any consensus in the WG yet since there is no WG yet. This is an easy = edit; the charter reads just fine starting from the below paragraph and = there are no normative (as it were) changes. >=20 > (Also, an editorial nit: "use case" is conventionally not hyphenated = -- a search-and-replace will fix this.) >=20 >> The working group will define an architecture allowing a = node to steer a packet through a network, or set of networks, on any = path without requiring state to be maintained by transited nodes (but = rather at the source device). The source node may send any packet along = a path within the domain through specifying the identifiers = referring to this path. Subsequent downstream nodes along the path = within the domain will forward packets according to the = instructions inserted by the head-end. >>=20 >> Within the architecture, a node may be of any type - = including routers and appliances. A set of such nodes sharing a common = trust model form a domain. The architecture defined by this = working group will allow steering of packets between any source and = destination node within the domain, which may be formed of = one or more networks, on any path (shortest, non-shortest, explicit, or = based on other resources or characteristics specified by segment = identifiers). >=20 > The two forgoing paragraphs have a lot of redundancy, probably due to = the multiple revision cycles they've been through. Here is a potential = rewrite merging the two but attempting to maintain all the content: >=20 > The working group will define an architecture that will = allow a node to steer a packet between any source and destination = through a domain on any path without requiring state to be = maintained by transited nodes, but rather at the source device. A = domain is a network or set of networks comprised of nodes = (which may be of any type, including routers and appliances) that share = a common trust model. The path may be shortest, non-shortest, explicit, = or based on other resources or characteristics specified by segment = identifiers. >=20 > Some comments on this -- >=20 > - I'm not actually sure what "set of networks" really adds. AFAIK it = has no well-defined meaning distinct from that of "network". > - I don't think the final sentence actually adds anything since the = first sentence says "any path" and "any" takes in the entire universe of = possibilities already. The final sentence also uses the term "segment = identifiers" which is not defined in the charter. >=20 > IMO neither of these actually detracts (other than the undefined = term), but neither do they add, so my preference would be to leave them = out (I generally favor the "perfection is achieved, not when there is = nothing more to add, but when there is nothing left to take away" = heuristic). So: >=20 > The working group will define an architecture that will = allow a node to steer a packet between any source and destination = through a domain on any path without requiring state to be = maintained by transited nodes, but rather at the source device. A = domain is a network comprised of nodes (which may be of any = type, including routers and appliances) that share a common trust model. >=20 > I actually think "which may be of any type, including routers and = appliances" is in the same category (it's implicit) but I realize that = others will probably disagree so I haven't proposed eliding it. I'd be = happy to though, if I am mistaken. >=20 >> The architecture should support both centralised and = distributed path computation - through both existing routing protocols = (IGP, BGP) and new approaches to such path calculation. The architecture = should also support OAM functions. >=20 > The first sentence is puzzlingly broad, especially when you get to = "... and new approaches to path calculation." The best I can parse it is = "we haven't decided how to do this yet but everything should be on the = table". I think it could be trimmed to "The architecture = should support both centralised and distributed path computation" = without loss of generality. >=20 >> The architecture has been postulated to be applicable to = multiple data planes (e.g., MPLS, IPv6), and hence=20 >=20 > The paragraphs preceding this one state that the WG will define the = architecture. This means that by definition there isn't a = architecture yet. As such I don't see how it can be = postulated to be much of anything, and would suggest that the foregoing = clause be cut. I think that again, this can be done without loss of = generality since the following text captures the intent. >=20 >> the working group should strive to create a single = framework which maintains data plane independence where possible. Where = use cases are documented, care should be taken to define the data plane = requirements for the environment within which they are to be = implemented. The architecture should avoid modifications to = the MPLS data-plane, in order to remain compatible with existing = extensive deployments of MPLS. >=20 > I suggest adding "It is anticipated the architecture may = need to propose modifications to the IPv6 data plane." (One could use = "extensions" in place of "modifications", though I prefer it as = written.) I also suggest that a work item be added, >=20 > o Document impact (if any) of any proposed IPv6 data plane = modifications =20 > on existing deployment of IPv6. >=20 > I believe this is the only substantive change I've proposed, the rest = being editorial. >=20 >> The working group is chartered for the following (ordered) = list of items: >> o Identification of use-cases for the architecture for = which >> there is consensus within the WG. >> o Definition of an architectural framework, which must cover >> security considerations (including the relationship between = networks >> forming the domain). >> o Having identified use-cases, and developed a framework, the WG will >> work on proposing a new architectures which substantially improve >=20 > "a new architecture that substantially improves upon" >=20 >> current technologies and define requirements for extensions or new >> functionality in existing routing protocols and/or I2RS protocols. >=20 > I'm a little confused why all routing protocols would be taken in but = only i2rs among management protocols, and besides isn't it still TBD if = i2rs will even end up defining a protocol? Thus, how about "existing = routing and management protocols"? >=20 >> o The working group will then develop solutions - focusing >> initially on intra-domain forwarding implementations. Where such >> solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will >> be done in conjunction with the responsible IETF working group. = Work >> on new protocols may be carried out by the working = group. >> The working group will develop the following documents: >> o One or more documents describing use cases, >> o A architecture, >> o A set of one or more protocol extensions requirements documents, >> o Inter-operability reports pertaining to the implementation of = extensions >> supporting . >=20 > Finally I have a question, or observation: Where we are talking about = modifying/extending a data plane (IPv6) there may be implications to = inter-domain forwarding. Thus the initial focus on intra-domain = forwarding, above, is a little concerning -- one can easily imagine a = sequence like >=20 > - Define intra-domain forwarding, > - Define new v6 data plane, > - Publish specs, > - Recharter to include inter-domain,=20 > - Define inter-domain forwarding, > - Oops, we need to further extend the v6 data plane. >=20 > Since the cost of extending the v6 data plane may end up being = non-trivial, it seems as though it would be desirable to avoid this kind = of iteration. Do others agree and if so how should we capture this in = the charter? >=20 > Thanks, >=20 > --John >=20 > Consolidated edits below: >=20 > ------------------ >=20 > Name: >=20 > The working group will define an architecture that will = allow a node to steer a packet between any source and destination = through a domain on any path without requiring state to be = maintained by transited nodes, but rather at the source device. A = domain is a network comprised of nodes (which may be of any = type, including routers and appliances) that share a common trust model. >=20 > The architecture should support both centralised and = distributed path computation. The architecture should also support OAM = functions. >=20 > The working group should strive to create a single = framework which maintains data plane independence where possible. Where = use cases are documented, care should be taken to define the data plane = requirements for the environment within which they are to be = implemented. The architecture should avoid modifications to = the MPLS data-plane, in order to remain compatible with existing = extensive deployments of MPLS. It is anticipated the = architecture may need to propose modifications to the IPv6 data plane. >=20 > The working group is chartered for the following (ordered) = list of items: > o Identification of use-cases for the architecture for = which > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o Document impact (if any) of any proposed IPv6 data plane = modifications =20 > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of = extensions > supporting . >=20 > ------------------ > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From rjs@rob.sh Mon Sep 16 01:32:39 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5646721F846E for ; Mon, 16 Sep 2013 01:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSQR6yP3yELV for ; Mon, 16 Sep 2013 01:31:30 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 73E1211E823A for ; Mon, 16 Sep 2013 01:18:56 -0700 (PDT) Received: from [86.179.200.30] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VLU01-0003lS-OL; Mon, 16 Sep 2013 09:17:37 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> Date: Mon, 16 Sep 2013 09:18:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3FA92354-123C-4748-A929-78B3D468E241@rob.sh> References: <52332E33.1040603@cisco.com> <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> To: John G. Scudder X-Mailer: Apple Mail (2.1508) Cc: Adrian Farrel , "status@ietf.org" , stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 08:32:53 -0000 Hi John, A few comments in-line, marked rjs>. On 15 Sep 2013, at 22:09, John G. Scudder wrote: >> [=85snip=85] >=20 > The two forgoing paragraphs have a lot of redundancy, probably due to = the multiple revision cycles they've been through. Here is a potential = rewrite merging the two but attempting to maintain all the content: >=20 > The working group will define an architecture that will = allow a node to steer a packet between any source and destination = through a domain on any path without requiring state to be = maintained by transited nodes, but rather at the source device. A = domain is a network or set of networks comprised of nodes = (which may be of any type, including routers and appliances) that share = a common trust model. The path may be shortest, non-shortest, explicit, = or based on other resources or characteristics specified by segment = identifiers. >=20 > Some comments on this -- >=20 > - I'm not actually sure what "set of networks" really adds. AFAIK it = has no well-defined meaning distinct from that of "network". rjs> I think that "set of networks" is required here -- if we consider = this from a wider view than purely=20 technical (e.g., operational or administrative separation), then the = overall domain may be made up of multiple different = underlying separate administrative entities ("networks"). The key thing = (for me) is that these networks have a model whereby the source can be = wholly trusted to steer a packet through the domain. > - I don't think the final sentence actually adds anything since the = first sentence says "any path" and "any" takes in the entire universe of = possibilities already. The final sentence also uses the term "segment = identifiers" which is not defined in the charter. >=20 > IMO neither of these actually detracts (other than the undefined = term), but neither do they add, so my preference would be to leave them = out (I generally favor the "perfection is achieved, not when there is = nothing more to add, but when there is nothing left to take away" = heuristic). So: >=20 > The working group will define an architecture that will = allow a node to steer a packet between any source and destination = through a domain on any path without requiring state to be = maintained by transited nodes, but rather at the source device. A = domain is a network comprised of nodes (which may be of any = type, including routers and appliances) that share a common trust model. >=20 > I actually think "which may be of any type, including routers and = appliances" is in the same category (it's implicit) but I realize that = others will probably disagree so I haven't proposed eliding it. I'd be = happy to though, if I am mistaken. rjs> In both these cases, the intention of the wording is to provide = some form of example of the kind of functionality that is required from = the new architecture. rjs> If we lose the first paragraph which gives a set of example = use-cases for this technology, then I think it would be good to include = the types of nodes/paths that are envisaged. I think this helps support = the distinction between a domain-wide protocol to determine the route, = and a head-end being able to pick an arbitrary path without any = knowledge of the transit nodes as to the means by which it was = calculated. >=20 >> The architecture should support both centralised and = distributed path computation - through both existing routing protocols = (IGP, BGP) and new approaches to such path calculation. The architecture = should also support OAM functions. >=20 > The first sentence is puzzlingly broad, especially when you get to = "... and new approaches to path calculation." The best I can parse it is = "we haven't decided how to do this yet but everything should be on the = table". I think it could be trimmed to "The architecture = should support both centralised and distributed path computation" = without loss of generality. rjs> I'm OK with this, the intention was to try and ensure that there is = no direct tie only to today's protocols/approaches to this (so that we = can retain the generality of the data plane instantiation). >=20 >> The architecture has been postulated to be applicable to = multiple data planes (e.g., MPLS, IPv6), and hence=20 >=20 > The paragraphs preceding this one state that the WG will define the = architecture. This means that by definition there isn't a = architecture yet. As such I don't see how it can be = postulated to be much of anything, and would suggest that the foregoing = clause be cut. I think that again, this can be done without loss of = generality since the following text captures the intent. rjs> I don't agree with cutting this sentence in its entirety. rjs> I would suggest: "Mechanisms allowing a source node to steer a packet through an = arbitrary set of nodes/links (without transit modes maintaining state) = have been postulated to be applicable to multiple data planes (e.g., = MPLS, IPv6), and hence=85" rjs> the reason being that we have already had debate (on this list) as = to what data planes are of interest for the drafts which triggered the = BoF. The problem you highlighted is that there is perhaps the jump that = infers that these proposals may form the architecture - which may not be = the case, so I'm happy to remove the "The architecture=85". = However, I would like to ensure that there is something in the charter = that captures that there are operators who are interested in >1 data = plane. >=20 >> the working group should strive to create a single = framework which maintains data plane independence where possible. Where = use cases are documented, care should be taken to define the data plane = requirements for the environment within which they are to be = implemented. The architecture should avoid modifications to = the MPLS data-plane, in order to remain compatible with existing = extensive deployments of MPLS. >=20 > I suggest adding "It is anticipated the architecture may = need to propose modifications to the IPv6 data plane." (One could use = "extensions" in place of "modifications", though I prefer it as = written.) I also suggest that a work item be added, >=20 > o Document impact (if any) of any proposed IPv6 data plane = modifications =20 > on existing deployment of IPv6. >=20 > I believe this is the only substantive change I've proposed, the rest = being editorial. rjs> I don't see an issue with including this. >=20 >> The working group is chartered for the following (ordered) = list of items: >> o Identification of use-cases for the architecture for = which >> there is consensus within the WG. >> o Definition of an architectural framework, which must cover >> security considerations (including the relationship between = networks >> forming the domain). >> o Having identified use-cases, and developed a framework, the WG will >> work on proposing a new architectures which substantially improve >=20 > "a new architecture that substantially improves upon" >=20 >> current technologies and define requirements for extensions or new >> functionality in existing routing protocols and/or I2RS protocols. >=20 > I'm a little confused why all routing protocols would be taken in but = only i2rs among management protocols, and besides isn't it still TBD if = i2rs will even end up defining a protocol? Thus, how about "existing = routing and management protocols"? rjs> Again, I'm OK with this. >=20 >> o The working group will then develop solutions - focusing >> initially on intra-domain forwarding implementations. Where such >> solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will >> be done in conjunction with the responsible IETF working group. = Work >> on new protocols may be carried out by the working = group. >> The working group will develop the following documents: >> o One or more documents describing use cases, >> o A architecture, >> o A set of one or more protocol extensions requirements documents, >> o Inter-operability reports pertaining to the implementation of = extensions >> supporting . >=20 > Finally I have a question, or observation: Where we are talking about = modifying/extending a data plane (IPv6) there may be implications to = inter-domain forwarding. Thus the initial focus on intra-domain = forwarding, above, is a little concerning -- one can easily imagine a = sequence like >=20 > - Define intra-domain forwarding, > - Define new v6 data plane, > - Publish specs, > - Recharter to include inter-domain,=20 > - Define inter-domain forwarding, > - Oops, we need to further extend the v6 data plane. >=20 > Since the cost of extending the v6 data plane may end up being = non-trivial, it seems as though it would be desirable to avoid this kind = of iteration. Do others agree and if so how should we capture this in = the charter? rjs> Is this not down to what the definition of "domain" is (see: = "network" vs. "set of networks" discussion above). Do we envisage that = intra-*-domain* forwarding will really be radically different = to inter-"-domain"? The key difference between the two would = appear to me to be trust model, rather than anything else? rjs> One possible fix is to strike the wording which asks for focus on = intra-domain forwarding -- however, if we look at the use-cases that = triggered this work, there does not appear (to me) to be any that really = asks for inter-domain yet, so I can't support having to address the = plethora of issues that exist when extending source-routing into = environments that do not have a common trust model before we can proceed = with anything to do with intra-domain forwarding (where there are a = number of well-established use-cases). Cheers, r. > Thanks, >=20 > --John >=20 > Consolidated edits below: >=20 > ------------------ >=20 > Name: >=20 > The working group will define an architecture that will = allow a node to steer a packet between any source and destination = through a domain on any path without requiring state to be = maintained by transited nodes, but rather at the source device. A = domain is a network comprised of nodes (which may be of any = type, including routers and appliances) that share a common trust model. >=20 > The architecture should support both centralised and = distributed path computation. The architecture should also support OAM = functions. >=20 > The working group should strive to create a single = framework which maintains data plane independence where possible. Where = use cases are documented, care should be taken to define the data plane = requirements for the environment within which they are to be = implemented. The architecture should avoid modifications to = the MPLS data-plane, in order to remain compatible with existing = extensive deployments of MPLS. It is anticipated the = architecture may need to propose modifications to the IPv6 data plane. >=20 > The working group is chartered for the following (ordered) = list of items: > o Identification of use-cases for the architecture for = which > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this = will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o Document impact (if any) of any proposed IPv6 data plane = modifications =20 > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of = extensions > supporting . >=20 > ------------------ > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From bruno.decraene@orange.com Mon Sep 16 01:59:09 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520921F9981 for ; Mon, 16 Sep 2013 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCTFrbEKRycP for ; Mon, 16 Sep 2013 01:58:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1929C21F89FF for ; Mon, 16 Sep 2013 01:43:57 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 5E81F374178; Mon, 16 Sep 2013 10:41:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3093015803A; Mon, 16 Sep 2013 10:41:20 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 16 Sep 2013 10:41:19 +0200 From: To: "stbryant@cisco.com" , "status@ietf.org" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVoHimsYDaTXkKT2SnKgr9E2ZnIBUYA Date: Mon, 16 Sep 2013 08:41:19 +0000 Message-ID: <16175_1379320880_5236C430_16175_1655_2_53C29892C857584299CBF5D05346208A0705DD28@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <52332E33.1040603@cisco.com> In-Reply-To: <52332E33.1040603@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: Adrian Farrel Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 08:59:14 -0000 Hi, > The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o Document impact (if any) of any proposed IPv6 data plane modifications= on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extensio= ns supporting . There may be a need for a specific MPLS document, to define MPLS specific a= spects, in particular the interworking with existing MPLS signaling protoco= ls (LDP, RSVP-TE) (during the transition period). It's not clear to me where such MPLS specific work will be done: - MPLS WG? But there is no expected protocol extension in the MPLS dataplan= e, MPLS architecture, LDP and RSVP-TE. Hence "A set of one or more protocol= extensions requirements documents" may not apply. - WG? But there is no mention of an MPLS specific document (whil= e during the BOF, "There was overwhelming support for work on MPLS Source R= outing (SR)") Regarding the home of such a document, IMHO I would favor the WG= where there is a priori a better chance for combined MPLS & kno= wledge. Regards, Bruno >-----Original Message----- >From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of >Stewart Bryant >Sent: Friday, September 13, 2013 5:25 PM >To: status@ietf.org >Cc: Adrian Farrel >Subject: [Status] TBD Charter - ready of RTG AD review yes/no > >Thanks to those that have worked on pulling together the >charter text. > >I now need to check whether there is consensus that this >represents the right starting point for the Routing ADs >to engage with the list and polish it to the point where >we are confident that it will gain the approval of the IESG. > >Some notes on timeline are appropriate. In order to meet >as a WG in Vancouver this needs to be approved for >external review at the IESG telechat on 10th October. >This means that we have to add it to the agenda by 26th >September. This means that we (the Routing ADs) need >to have a view that the text of 26th September is likely >to be acceptable to both the community and the IESG. >It also mean an active dialog with members of the IESG >regarding review comments raised in the period up to >10th October. > >For reference, I am about to put a placeholder for this >on the BOF page, in order for an agenda slot to be >reserved for this work, hopefully to meet as a WG, >but otherwise to meet to finish of the charter. > >So back to the question, is there consensus that text >below is now at the point where the RTG ADs should >actively engage to get it ready for IESG approval >- yes/no? > >Thanks > >Stewart > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Name: > >A number of use cases, including: > o Path computation based on awareness of utilisation or performance > data, within both centralised and distributed environments, > o Multi-topology routing (dual planes, disjoint trees), > o Simplification and reduction of signalling, > o Combined application and network-layer path specification. > o Full coverage LFA FRR, > o Topology Aware OAM, >have triggered work on the definition of a new architecture and protocol >extensions, allowing nodes to steer packets through a network, allowing >combination of well-known shortest-path based routing paradigms with source >or explicit routing methods. Some of the extensions allowing steering of >packets in this manner have already been implemented. > >The working group will define an architecture allowing a node to >steer a packet through a network, or set of networks, on any path without >requiring state to be maintained by transited nodes (but rather at the >source device). The source node may send any packet along a path within the > domain through specifying the identifiers referring to this pat= h. >Subsequent downstream nodes along the path within the domain wi= ll >forward packets according to the instructions inserted by the head-end. > >Within the architecture, a node may be of any type - including >routers and appliances. A set of such nodes sharing a common trust model >form a domain. The architecture defined by this working group >will allow steering of packets between any source and destination node >within the domain, which may be formed of one or more networks, >on any path (shortest, non-shortest, explicit, or based on other resources >or characteristics specified by segment identifiers). > >The architecture should support both centralised and distributed >path computation - through both existing routing protocols (IGP, BGP) and >new approaches to such path calculation. The architecture should also >support OAM functions. > >The architecture has been postulated to be applicable to multip= le >data planes (e.g., MPLS, IPv6), and hence the working group should strive = to >create a single framework which maintains data plane independen= ce >where possible. Where use cases are documented, care should be taken to >define the data plane requirements for the environment within which they a= re >to be implemented. The architecture should avoid modifications = to >the MPLS data-plane, in order to remain compatible with existing extensive >deployments of MPLS. > >The working group is chartered for the following (ordered) list >of items: > o Identification of use-cases for the architecture for whi= ch > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this >will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > >The working group will develop the following documents: > o One or more documents describing use cases, > o A architecture, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of >extensions > supporting . > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From aretana@cisco.com Mon Sep 16 06:30:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDF811E8246 for ; Mon, 16 Sep 2013 06:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c7-RgKx5RXm for ; Mon, 16 Sep 2013 06:30:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A65A811E8120 for ; Mon, 16 Sep 2013 06:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2227; q=dns/txt; s=iport; t=1379338218; x=1380547818; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hxUL6ev7DpfMP/hxATUrIrTcTQ+JMBK7Eg/E7Cg3k0o=; b=QYlWijNzhBBqdiz0caPmFH62+TONqlXLcP7WQaR7FpY4PkaBomzkR2B9 gPWl5pDJ3OPcovUnCp+LZaXmbVYWSuArD99LE3aq1U/JyqyYBk06n1FSo KoSm6pjBqnfa64ElV3huGQCvVtrbHSLFroFnmV8YPOtwlF6K6R0FaW4fb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACoHN1KtJV2c/2dsb2JhbABagweBCsB3gRwWdIInAQQ6PxIBCA4EEBRCFw4CBAENBQiHe7lXj0IxB4MegQADqW+DJIIq X-IronPort-AV: E=Sophos;i="4.90,915,1371081600"; d="scan'208";a="260271273" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 16 Sep 2013 13:30:18 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8GDUHD5008893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Sep 2013 13:30:17 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.123]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 16 Sep 2013 08:30:17 -0500 From: "Alvaro Retana (aretana)" To: Rob Shakir , "John G. Scudder" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVoa7hzUcgo6EeudVAw+jQ3xJnHomgAgAC67wCAABQCgA== Date: Mon, 16 Sep 2013 13:30:17 +0000 Message-ID: In-Reply-To: <3FA92354-123C-4748-A929-78B3D468E241@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <227D974BC56BB240A899593A42E43986@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 13:30:24 -0000 On 9/16/13 4:18 AM, "Rob Shakir" wrote: Rob: Hi! >> >>- I don't think the final sentence actually adds anything since the >>first sentence says "any path" and "any" takes in the entire universe of >>possibilities already. The final sentence also uses the term "segment >>identifiers" which is not defined in the charter. >>IMO neither of these actually detracts (other than the undefined term), >>but neither do they add, so my preference would be to leave them out (I >>generally favor the "perfection is achieved, not when there is nothing >>more to add, but when there is nothing left to take away" heuristic). So: >>The working group will define an architecture that will allow >>a node to steer a packet between any source and destination through a >> domain on any path without requiring state to be maintained >>by transited nodes, but rather at the source device. A domain >>is a network comprised of nodes (which may be of any type, including >>routers and appliances) that share a common trust model. >>I actually think "which may be of any type, including routers and >>appliances" is in the same category (it's implicit) but I realize that >>others will probably disagree so I haven't proposed eliding it. I'd be >>happy to though, if I am mistaken. > >rjs> In both these cases, the intention of the wording is to provide some >form of example of the kind of functionality that is required from the >new architecture. > >rjs> If we lose the first paragraph which gives a set of example >use-cases for this technology, then I think it would be good to include >the types of nodes/paths that are envisaged. I think this helps support >the distinction between a domain-wide protocol to determine the route, >and a head-end being able to pick an arbitrary path without any knowledge >of the transit nodes as to the means by which it was calculated. I agree with John on this. While the examples seem to help clarify, that is what the use cases (the complete description, not just the list) are for: to explicitly tell us (the WG) what needs to be solved..and that should be the first chartered step anyway. My 1c. Alvaro. From jdrake@juniper.net Mon Sep 16 07:51:13 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D018011E8274 for ; Mon, 16 Sep 2013 07:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=3.771, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HPJhp+NTXVl for ; Mon, 16 Sep 2013 07:51:07 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 39E6E11E8281 for ; Mon, 16 Sep 2013 07:51:05 -0700 (PDT) Received: from mail132-tx2-R.bigfish.com (10.9.14.226) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Mon, 16 Sep 2013 14:51:04 +0000 Received: from mail132-tx2 (localhost [127.0.0.1]) by mail132-tx2-R.bigfish.com (Postfix) with ESMTP id 6116A3800C4; Mon, 16 Sep 2013 14:51:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I542I1432I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail132-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(164054003)(24454002)(51444003)(189002)(199002)(377454003)(13464003)(54356001)(65816001)(76576001)(76482001)(54316002)(81816001)(79102001)(81686001)(31966008)(56816003)(69226001)(53806001)(33646001)(77096001)(63696002)(56776001)(80022001)(1941001)(81342001)(76796001)(46102001)(83072001)(19580395003)(76786001)(74876001)(77982001)(15975445006)(83322001)(50986001)(74662001)(81542001)(59766001)(19580405001)(47446002)(47976001)(66066001)(47736001)(74706001)(74502001)(4396001)(74316001)(74366001)(49866001)(51856001)(80976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB525; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail132-tx2 (localhost.localdomain [127.0.0.1]) by mail132-tx2 (MessageSwitch) id 1379343061555383_26304; Mon, 16 Sep 2013 14:51:01 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.231]) by mail132-tx2.bigfish.com (Postfix) with ESMTP id 815F3A0083; Mon, 16 Sep 2013 14:51:01 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 16 Sep 2013 14:51:01 +0000 Received: from DM2PR05MB525.namprd05.prod.outlook.com (10.141.99.147) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Mon, 16 Sep 2013 14:51:00 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by DM2PR05MB525.namprd05.prod.outlook.com (10.141.99.147) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 16 Sep 2013 14:50:58 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.132]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.132]) with mapi id 15.00.0775.005; Mon, 16 Sep 2013 14:50:57 +0000 From: John E Drake To: John Scudder , "stbryant@cisco.com" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJV2SmzEKF9T50i0ByGTDLjFy5nHTpYAgAEnfuA= Date: Mon, 16 Sep 2013 14:50:56 +0000 Message-ID: References: <52332E33.1040603@cisco.com> <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> In-Reply-To: <2670D6EF-190E-48CC-8ED5-6F82F0BC7384@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0971922F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 14:51:13 -0000 John, Would it make sense to change the word 'architecture' to the word 'paradigm= ' in your proposed charter text, below? Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of John G. Scudder > Sent: Sunday, September 15, 2013 2:10 PM > To: stbryant@cisco.com > Cc: Adrian Farrel; status@ietf.org > Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >=20 > Stewart, >=20 > I have a number of mostly-editorial comments. They're in line below. Ther= e is > one substantive but relatively small change, which is called out. I've > appended a version of the draft charter that consolidates my proposed edi= ts, > at the bottom. >=20 > Going through the exercise of doing this has reminded me of one significa= nt > concern, though. The first work item for the WG in the proposed charter i= s: >=20 > o Identification of use-cases for the architecture for which > there is consensus within the WG. >=20 > This leads to the simple question: until we've identified use cases, how = can > we say we need a new architecture? We are presupposing the outcome. If > the agreed use cases end up being things that are supportable within the > existing MPLS architecture, that is great. Note I'm not saying the use ca= ses > shouldn't be addressed, merely that their solutions may, or may not, rise= to > the level of "architecture". I would be interested in discussion of this > question before we close on a charter. >=20 > The rest is in line below. >=20 > On Sep 13, 2013, at 11:24 AM, Stewart Bryant wrote: >=20 > > Thanks to those that have worked on pulling together the charter text. > > > > I now need to check whether there is consensus that this represents > > the right starting point for the Routing ADs to engage with the list > > and polish it to the point where we are confident that it will gain > > the approval of the IESG. > > > > Some notes on timeline are appropriate. In order to meet as a WG in > > Vancouver this needs to be approved for external review at the IESG > > telechat on 10th October. > > This means that we have to add it to the agenda by 26th September. > > This means that we (the Routing ADs) need to have a view that the text > > of 26th September is likely to be acceptable to both the community and > > the IESG. > > It also mean an active dialog with members of the IESG regarding > > review comments raised in the period up to 10th October. > > > > For reference, I am about to put a placeholder for this on the BOF > > page, in order for an agenda slot to be reserved for this work, > > hopefully to meet as a WG, but otherwise to meet to finish of the > > charter. > > > > So back to the question, is there consensus that text below is now at > > the point where the RTG ADs should actively engage to get it ready for > > IESG approval > > - yes/no? > > > > Thanks > > > > Stewart > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Name: > > > > A number of use cases, including: > > o Path computation based on awareness of utilisation or performance > > data, within both centralised and distributed environments, o > > Multi-topology routing (dual planes, disjoint trees), o > > Simplification and reduction of signalling, o Combined application > > and network-layer path specification. > > o Full coverage LFA FRR, > > o Topology Aware OAM, > > have triggered work on the definition of a new architecture and protoco= l > extensions, allowing nodes to steer packets through a network, allowing > combination of well-known shortest-path based routing paradigms with > source or explicit routing methods. Some of the extensions allowing steer= ing > of packets in this manner have already been implemented. >=20 > The foregoing does/did add something to the mailing list discussion, but = I > think should be omitted from the charter. After all, the first work item = listed > in the charter is exactly to produce a list of "use-cases ... for which t= here is > consensus". By definition there can't be any consensus in the WG yet sinc= e > there is no WG yet. This is an easy edit; the charter reads just fine sta= rting > from the below paragraph and there are no normative (as it were) changes. >=20 > (Also, an editorial nit: "use case" is conventionally not hyphenated -- a > search-and-replace will fix this.) >=20 > > The working group will define an architecture allowing a nod= e > to steer a packet through a network, or set of networks, on any path with= out > requiring state to be maintained by transited nodes (but rather at the so= urce > device). The source node may send any packet along a path within the > domain through specifying the identifiers referring to this pa= th. > Subsequent downstream nodes along the path within the > domain will forward packets according to the instructions inserted by the > head-end. > > > > Within the architecture, a node may be of any type - > including routers and appliances. A set of such nodes sharing a common tr= ust > model form a domain. The architecture defined by this working > group will allow steering of packets between any source and destination > node within the domain, which may be formed of one or more > networks, on any path (shortest, non-shortest, explicit, or based on othe= r > resources or characteristics specified by segment identifiers). >=20 > The two forgoing paragraphs have a lot of redundancy, probably due to the > multiple revision cycles they've been through. Here is a potential rewrit= e > merging the two but attempting to maintain all the content: >=20 > The working group will define an architecture that will allow = a > node to steer a packet between any source and destination through a > domain on any path without requiring state to be maintained > by transited nodes, but rather at the source device. A domain > is a network or set of networks comprised of nodes (which may be of any > type, including routers and appliances) that share a common trust model. > The path may be shortest, non-shortest, explicit, or based on other > resources or characteristics specified by segment identifiers. >=20 > Some comments on this -- >=20 > - I'm not actually sure what "set of networks" really adds. AFAIK it has = no > well-defined meaning distinct from that of "network". > - I don't think the final sentence actually adds anything since the first > sentence says "any path" and "any" takes in the entire universe of > possibilities already. The final sentence also uses the term "segment > identifiers" which is not defined in the charter. >=20 > IMO neither of these actually detracts (other than the undefined term), b= ut > neither do they add, so my preference would be to leave them out (I > generally favor the "perfection is achieved, not when there is nothing mo= re > to add, but when there is nothing left to take away" heuristic). So: >=20 > The working group will define an architecture that will allow = a > node to steer a packet between any source and destination through a > domain on any path without requiring state to be maintained > by transited nodes, but rather at the source device. A domain > is a network comprised of nodes (which may be of any type, including > routers and appliances) that share a common trust model. >=20 > I actually think "which may be of any type, including routers and applian= ces" > is in the same category (it's implicit) but I realize that others will pr= obably > disagree so I haven't proposed eliding it. I'd be happy to though, if I a= m > mistaken. >=20 > > The architecture should support both centralised and > distributed path computation - through both existing routing protocols (I= GP, > BGP) and new approaches to such path calculation. The architecture should > also support OAM functions. >=20 > The first sentence is puzzlingly broad, especially when you get to "... a= nd new > approaches to path calculation." The best I can parse it is "we haven't > decided how to do this yet but everything should be on the table". I thin= k it > could be trimmed to "The architecture should support both > centralised and distributed path computation" without loss of generality. >=20 > > The architecture has been postulated to be applicable to > > multiple data planes (e.g., MPLS, IPv6), and hence >=20 > The paragraphs preceding this one state that the WG will define the TBD> architecture. This means that by definition there isn't a > architecture yet. As such I don't see how it can be postulated to be much= of > anything, and would suggest that the foregoing clause be cut. I think tha= t > again, this can be done without loss of generality since the following te= xt > captures the intent. >=20 > > the working group should strive to create a single framework > which maintains data plane independence where possible. Where use cases > are documented, care should be taken to define the data plane > requirements for the environment within which they are to be > implemented. The architecture should avoid modifications to > the MPLS data-plane, in order to remain compatible with existing extensiv= e > deployments of MPLS. >=20 > I suggest adding "It is anticipated the architecture may need = to > propose modifications to the IPv6 data plane." (One could use "extensions= " > in place of "modifications", though I prefer it as written.) I also sugge= st that a > work item be added, >=20 > o Document impact (if any) of any proposed IPv6 data plane modification= s > on existing deployment of IPv6. >=20 > I believe this is the only substantive change I've proposed, the rest bei= ng > editorial. >=20 > > The working group is chartered for the following (ordered) > list of items: > > o Identification of use-cases for the architecture for whic= h > > there is consensus within the WG. > > o Definition of an architectural framework, which must cover > > security considerations (including the relationship between networks > > forming the domain). > > o Having identified use-cases, and developed a framework, the WG will > > work on proposing a new architectures which substantially improve >=20 > "a new architecture that substantially improves upon" >=20 > > current technologies and define requirements for extensions or new > > functionality in existing routing protocols and/or I2RS protocols. >=20 > I'm a little confused why all routing protocols would be taken in but onl= y i2rs > among management protocols, and besides isn't it still TBD if i2rs will e= ven > end up defining a protocol? Thus, how about "existing routing and > management protocols"? >=20 > > o The working group will then develop solutions - focusing > > initially on intra-domain forwarding implementations. Where such > > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this wi= ll > > be done in conjunction with the responsible IETF working group. Work > > on new protocols may be carried out by the working group. > > The working group will develop the following documents: > > o One or more documents describing use cases, o A > > architecture, o A set of one or more protocol extensions > > requirements documents, o Inter-operability reports pertaining to the > > implementation of extensions > > supporting . >=20 > Finally I have a question, or observation: Where we are talking about > modifying/extending a data plane (IPv6) there may be implications to inte= r- > domain forwarding. Thus the initial focus on intra-domain forwarding, abo= ve, > is a little concerning -- one can easily imagine a sequence like >=20 > - Define intra-domain forwarding, > - Define new v6 data plane, > - Publish specs, > - Recharter to include inter-domain, > - Define inter-domain forwarding, > - Oops, we need to further extend the v6 data plane. >=20 > Since the cost of extending the v6 data plane may end up being non-trivia= l, it > seems as though it would be desirable to avoid this kind of iteration. Do > others agree and if so how should we capture this in the charter? >=20 > Thanks, >=20 > --John >=20 > Consolidated edits below: >=20 > ------------------ >=20 > Name: >=20 > The working group will define an architecture that will allow = a > node to steer a packet between any source and destination through a > domain on any path without requiring state to be maintained > by transited nodes, but rather at the source device. A domain > is a network comprised of nodes (which may be of any type, including > routers and appliances) that share a common trust model. >=20 > The architecture should support both centralised and > distributed path computation. The architecture should also support OAM > functions. >=20 > The working group should strive to create a single framework > which maintains data plane independence where possible. Where use cases > are documented, care should be taken to define the data plane > requirements for the environment within which they are to be > implemented. The architecture should avoid modifications to > the MPLS data-plane, in order to remain compatible with existing extensiv= e > deployments of MPLS. It is anticipated the architecture may > need to propose modifications to the IPv6 data plane. >=20 > The working group is chartered for the following (ordered) lis= t > of items: > o Identification of use-cases for the architecture for which > there is consensus within the WG. > o Definition of an architectural framework, which must cover > security considerations (including the relationship between networks > forming the domain). > o Having identified use-cases, and developed a framework, the WG will > work on proposing a new architectures which substantially improve > current technologies and define requirements for extensions or new > functionality in existing routing protocols and/or I2RS protocols. > o The working group will then develop solutions - focusing > initially on intra-domain forwarding implementations. Where such > solutions utilise existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > The working group will develop the following documents: > o One or more documents describing use cases, o A TBD> architecture, o Document impact (if any) of any proposed IPv6 data > plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, o > Inter-operability reports pertaining to the implementation of extensions > supporting . >=20 > ------------------ > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 From jgs@juniper.net Tue Sep 17 07:22:15 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF6411E8256 for ; Tue, 17 Sep 2013 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=1.285, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi0lp1JjiRWA for ; Tue, 17 Sep 2013 07:22:08 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59911E825F for ; Tue, 17 Sep 2013 07:21:55 -0700 (PDT) Received: from mail203-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Tue, 17 Sep 2013 14:21:54 +0000 Received: from mail203-ch1 (localhost [127.0.0.1]) by mail203-ch1-R.bigfish.com (Postfix) with ESMTP id BD39618005A; Tue, 17 Sep 2013 14:21:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: VPS7(zzec9Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail203-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(37854004)(199002)(80976001)(83072001)(65816001)(81816001)(59766001)(77982001)(47776003)(51856001)(46102001)(81342001)(81686001)(80022001)(66066001)(69226001)(83322001)(81542001)(79102001)(53806001)(23726002)(36756003)(33656001)(46406003)(42186004)(74706001)(50466002)(63696002)(74366001)(76796001)(62966002)(76786001)(50986001)(4396001)(49866001)(47736001)(47976001)(50226001)(74662001)(31966008)(74502001)(47446002)(56816003)(82746002)(74876001)(77156001)(77096001)(57306001)(76482001)(56776001)(54316002)(83716001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB521; H:[172.28.131.154]; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail203-ch1 (localhost.localdomain [127.0.0.1]) by mail203-ch1 (MessageSwitch) id 1379427712341253_25090; Tue, 17 Sep 2013 14:21:52 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail203-ch1.bigfish.com (Postfix) with ESMTP id 4EF34400BF; Tue, 17 Sep 2013 14:21:52 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 17 Sep 2013 14:21:50 +0000 Received: from CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 17 Sep 2013 14:21:49 +0000 Received: from [172.28.131.154] (66.129.232.2) by CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 17 Sep 2013 14:21:46 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: John G.Scudder In-Reply-To: <52332E33.1040603@cisco.com> Date: Tue, 17 Sep 2013 10:21:36 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> References: <52332E33.1040603@cisco.com> To: X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: CO1PR04CA003.namprd04.prod.outlook.com (10.141.49.13) To CO1PR05MB521.namprd05.prod.outlook.com (10.141.72.13) X-Forefront-PRVS: 0972DEC1D9 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 14:22:15 -0000 All, Here's another attempt. It tries to address the 'architecture' issue I = raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and = Rob Shakir's comments. With luck the change from ' domain' to = ' region' relieves the ambiguity that was present in earlier = versions. --John --------------------------------------------------------- Name: The working group will define procedures that will allow a node to steer a packet between any source and destination through a region on any path without requiring state to be maintained by transited nodes, but rather at the source device. A region is a network comprised of nodes (which may be of any type, including routers and appliances) that share the following trust model: any node in the region is trusted to steer=20 a packet through any of the other nodes within the region. The=20 region may comprise one or more ASes, or even less than a=20 single AS. Although a region may comprise more than one AS, initial=20 work will focus on the intra-domain, that is, single AS, scenario. The procedures should support both centralised and distributed path computation. The procedures should also cover support for OAM functions. Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The procedures should avoid modifications to the MPLS data plane, in order to remain compatible with existing extensive deployments of MPLS. It is anticipated that the procedures may require modifications to the IPv6 data plane. While the initial focus of the WG is on the intra-domain deployment scenarios (see below), the modifications to the IPv6 data plane must support both intra and inter-domain deployment scenarios. The working group is chartered for the following (ordered) list of items: o Identification and evaluation of use cases for which there=20 is consensus within the WG. o Definition of new procedures, driven by the use cases and underlying=20= technology. The new procedures must cover security considerations=20 (including the relationship between networks forming the =20 region) and allow for solutions which substantially improve upon=20 current technologies by defining requirements, extensions, or new functionality in existing routing, management or other protocols. o Determine whether the above mentioned procedures require modification/changes to the existing MPLS architecture, and if so, then document such modifications/changes. o Determine whether the above mentioned procedures require modification/changes to the existing IPv6 architecture, and if so, then document such modifications/changes. o The working group will then develop solutions, focusing initially on intra-domain deployment scenarios. Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. The working group will develop the following documents: o One or more documents describing use cases, o Specification of new procedures to support use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 architecture, if needed o Document interworking and co-existence between the new procedures and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any proposed IPv6 data plane modifications = =20 on existing deployment of IPv6, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of = extensions supporting .= From gregory.mirsky@ericsson.com Tue Sep 17 16:37:40 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B33D11E862E for ; Tue, 17 Sep 2013 16:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxqqUoNDPruz for ; Tue, 17 Sep 2013 16:37:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2FA811E81F3 for ; Tue, 17 Sep 2013 16:37:29 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-94-5238e7b86296 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C1.C8.09414.8B7E8325; Wed, 18 Sep 2013 01:37:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 17 Sep 2013 19:36:32 -0400 From: Gregory Mirsky To: John G.Scudder , "stbryant@cisco.com" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVqcq8gKrlpDEyA0gOT+W9FE5nKRFIAgABWa8A= Date: Tue, 17 Sep 2013 23:36:31 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> In-Reply-To: <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPiO6O5xZBBi/Oilr86LnBbDHzxldW i9fNF5kszj2dw+jA4jHl90ZWjyVLfjJ5XG+6yu6xYvNKxgCWKC6blNSczLLUIn27BK6MTRcy Cq6rVPyb3cbUwLhArouRk0NCwERizoSFbBC2mMSFe+uBbC4OIYGjjBKXL79nhHCWM0psW7SQ CaSKTcBI4sXGHnYQW0QgUOLp5oNAcQ4OZgEfiTWbZUBMYQFHiQ0LdCEqnCT2r5rLCGFbSXxp PwnWySKgKvF++Xw2kHJeAV+J8xtEQcJCArESa94fZwQJcwrYS8x6zgwSZgS67PupNWD7mQXE JW49mc8EcbGAxJI955khbFGJl4//sULYyhJLnuxngajXkViw+xMbhK0tsWzha7B6XgFBiZMz n7BMYBSbhWTsLCQts5C0zELSsoCRZRUjR2lxalluupHBJkZgFB2TYNPdwbjnpeUhRmkOFiVx 3lV6ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLKrqbSslv0z85FVg274h4u3tsfIcfeb qlk8Ox3ZEyMfbLKvcF31K6UvS5h2aRtefj9VcuF98WVp9s6KV01+NhzO+iKaz1vu0fCBv31J 3KzTUsKVETP1vnKUhwseUM+SV/OsmHjcY5X9dTPP0JXrFDKsNL8+qggI5U94Irph9vOd/qtV 79nnKLEUZyQaajEXFScCAMRTwzlwAgAA Cc: Adrian Farrel , "status@ietf.org" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 23:37:41 -0000 Hi John, et. al, I think that because of second paragraph, "... support both centralized and= distributed path computation", a change is needed to specify that state mu= st be maintained not necessarily at the source device but at the path compu= ting device (closing of the first sentence of the first paragraph). Regards, Greg -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= John G.Scudder Sent: Tuesday, September 17, 2013 7:22 AM To: stbryant@cisco.com Cc: Adrian Farrel; status@ietf.org Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no All, Here's another attempt. It tries to address the 'architecture' issue I rais= ed earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob Sh= akir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. --John --------------------------------------------------------- Name: The working group will define procedures that will allow a node = to steer a packet between any source and destination through a r= egion on any path without requiring state to be maintained by transited nod= es, but rather at the source device. A region is a network comp= rised of nodes (which may be of any type, including routers and appliances)= that share the following trust model: any node in the region is= trusted to steer a packet through any of the other nodes within the region= . The region may comprise one or more ASes, or even less than a = single AS. Although a region may comprise more than one AS, initial work wi= ll focus on the intra-domain, that is, single AS, scenario. The procedures should support both centralised and distributed path computa= tion. The procedures should also cover support for OAM functions. Where use cases are documented, care should be taken to define the data pla= ne requirements for the environment within which they are to be implemented= . The procedures should avoid modifications to the MPLS data plane, in orde= r to remain compatible with existing extensive deployments of MPLS. It is a= nticipated that the procedures may require modifications to the IPv6 data p= lane. While the initial focus of the WG is on the intra-domain = deployment scenarios (see below), the modifications to the IPv6 data plane = must support both intra and inter-domain deployment scenarios. The working group is chartered for the following (ordered) list = of items: o Identification and evaluation of use cases for which there is consensus within the WG. o Definition of new procedures, driven by the use cases and underlying technology. The new procedures must cover security considerations (including the relationship between networks forming the region) and allow for solutions which substantially improve upon current technologies by defining requirements, extensions, or new functionality in existing routing, management or other protocols. o Determine whether the above mentioned procedures require modification/changes to the existing MPLS architecture, and if so, then document such modifications/changes. o Determine whether the above mentioned procedures require modification/changes to the existing IPv6 architecture, and if so, then document such modifications/changes. o The working group will then develop solutions, focusing initially on intra-domain deployment scenarios. Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. The working group will develop the following documents: o One or more documents describing use cases, o Specification of= new procedures to support use cases, o Changes to MPLS architec= ture, if needed o Changes to IPv6 architecture, if needed o Document interw= orking and co-existence between the new procedures and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document= impact (if any) of any proposed IPv6 data plane modifications on existing deployment of IPv6, o A set of one or more protocol extensions requirements documents, o Inter-= operability reports pertaining to the implementation of extensions supporting . _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From rraszuk@gmail.com Tue Sep 17 18:03:07 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0062C11E8204 for ; Tue, 17 Sep 2013 18:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztP75euqlu9l for ; Tue, 17 Sep 2013 18:03:06 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 429AC11E8160 for ; Tue, 17 Sep 2013 18:03:06 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so11511433iej.38 for ; Tue, 17 Sep 2013 18:03:03 -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=wC9rIfBQJLqB4xXTAZaPw7F/EatMhRhCC3N0Ao69+ug=; b=ppTVATGw3gpmG8QcafUAzSXB7/0ZYv+yCgmUbFENwdAIsmFwzCNUlxuzQJ2b/ERlXP D3AWqsAlojQSA1E4Ltbt80LhiVP9/FOqgxxVD6x1BZS+z/SVL6xBX8WwrtQHxfol3RDL B5t1FJaJy8i85BVS1lsynfZKqtrnavPOwGYC021llSA5IHB6ZtKDZqjEk5t5WoXPvJnl 4h7ko1b8Ea61CHUVgIKsDJYkHhBxjy3OfE3pOmum+CH4Z1a8chhzYwduW0Yp7BEkkY3r X5VO7zz8/uQw+jGlN8xogerwCrYUqR1IedsNNDaaoU1E4wLxrdUZOZOi9CaKSU1gqP4/ nRrA== MIME-Version: 1.0 X-Received: by 10.50.73.74 with SMTP id j10mr2223057igv.50.1379466183807; Tue, 17 Sep 2013 18:03:03 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Tue, 17 Sep 2013 18:03:03 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> Date: Wed, 18 Sep 2013 03:03:03 +0200 X-Google-Sender-Auth: HiV3hSUrq34TArPX-maaB8ZPkq0 Message-ID: From: Robert Raszuk To: Gregory Mirsky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "John G.Scudder" , Adrian Farrel , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 01:03:07 -0000 Hi Gregory, Wouldn't it be simpler to say that state is not kept in those network elements which are acting as transit nodes rather then enumerating all elements which may impose headers or compute paths ? Thx, R. On Wed, Sep 18, 2013 at 1:36 AM, Gregory Mirsky wrote: > Hi John, et. al, > I think that because of second paragraph, "... support both centralized a= nd distributed path computation", a change is needed to specify that state = must be maintained not necessarily at the source device but at the path com= puting device (closing of the first sentence of the first paragraph). > > Regards, > Greg > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of John G.Scudder > Sent: Tuesday, September 17, 2013 7:22 AM > To: stbryant@cisco.com > Cc: Adrian Farrel; status@ietf.org > Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no > > All, > > Here's another attempt. It tries to address the 'architecture' issue I ra= ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob = Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. > > --John > > --------------------------------------------------------- > Name: > > The working group will define procedures that will allow a nod= e to steer a packet between any source and destination through a = region on any path without requiring state to be maintained by transited n= odes, but rather at the source device. A region is a network co= mprised of nodes (which may be of any type, including routers and appliance= s) that share the following trust model: any node in the region = is trusted to steer a packet through any of the other nodes within the regi= on. The region may comprise one or more ASes, or even less than = a single AS. Although a region may comprise more than one AS, initial work = will focus on the intra-domain, that is, single AS, scenario. > > The procedures should support both centralised and distributed path compu= tation. The procedures should also cover support for OAM functions. > > Where use cases are documented, care should be taken to define the data p= lane requirements for the environment within which they are to be implement= ed. The procedures should avoid modifications to the MPLS data plane, in or= der to remain compatible with existing extensive deployments of MPLS. It is= anticipated that the procedures may require modifications to the IPv6 data= plane. While the initial focus of the WG is on the intra-domai= n deployment scenarios (see below), the modifications to the IPv6 data plan= e must support both intra and inter-domain deployment scenarios. > > The working group is chartered for the following (ordered) lis= t of items: > > o Identification and evaluation of use cases for which there > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying > technology. The new procedures must cover security considerations > (including the relationship between networks forming the > region) and allow for solutions which substantially improve upon > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > > The working group will develop the following documents: > > o One or more documents describing use cases, o Specification = of new procedures to support use cases, o Changes to MPLS archit= ecture, if needed o Changes to IPv6 architecture, if needed o Document inte= rworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume= nt impact (if any) of any proposed IPv6 data plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, o Inte= r-operability reports pertaining to the implementation of extensions > supporting . > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From Ruediger.Geib@telekom.de Wed Sep 18 01:35:57 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C5711E81EC for ; Wed, 18 Sep 2013 01:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7lmiJPgzkm3 for ; Wed, 18 Sep 2013 01:35:53 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4011811E81E8 for ; Wed, 18 Sep 2013 01:35:51 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 18 Sep 2013 10:13:16 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.193]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 18 Sep 2013 10:13:15 +0200 From: To: , , Date: Wed, 18 Sep 2013 10:13:14 +0200 Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: Ac60CuAOS19GPQHlQY6R8dmkMOdC0wAOghCQ Message-ID: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: adrian@olddog.co.uk, status@ietf.org, stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 08:35:58 -0000 Hello John, Greg and Rob, John, thanks for your draft, which I support. I recognise the point raised by Greg, but currently have no preference whether to pick Gregs or Robs proposed text. I'd prefer something short and generic maintaining the spirit that the source node maintains at least standard routing state and additional routing state may be present locally or in other path computation systems outside of the region (as no packets are steered through centralised or distributed path computation elements, that statement shouldn't be wrong). Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Robert Raszuk Sent: Wednesday, September 18, 2013 3:03 AM To: Gregory Mirsky Cc: John G.Scudder; Adrian Farrel; status@ietf.org; stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no Hi Gregory, Wouldn't it be simpler to say that state is not kept in those network elements which are acting as transit nodes rather then enumerating all elements which may impose headers or compute paths ? Thx, R. On Wed, Sep 18, 2013 at 1:36 AM, Gregory Mirsky wrote: > Hi John, et. al, > I think that because of second paragraph, "... support both centralized a= nd distributed path computation", a change is needed to specify that state = must be maintained not necessarily at the source device but at the path com= puting device (closing of the first sentence of the first paragraph). > > Regards, > Greg > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf = Of John G.Scudder > Sent: Tuesday, September 17, 2013 7:22 AM > To: stbryant@cisco.com > Cc: Adrian Farrel; status@ietf.org > Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no > > All, > > Here's another attempt. It tries to address the 'architecture' issue I ra= ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob = Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. > > --John > > --------------------------------------------------------- > Name: > > The working group will define procedures that will allow a nod= e to steer a packet between any source and destination through a = region on any path without requiring state to be maintained by transited n= odes, but rather at the source device. A region is a network co= mprised of nodes (which may be of any type, including routers and appliance= s) that share the following trust model: any node in the region = is trusted to steer a packet through any of the other nodes within the regi= on. The region may comprise one or more ASes, or even less than = a single AS. Although a region may comprise more than one AS, initial work = will focus on the intra-domain, that is, single AS, scenario. > > The procedures should support both centralised and distributed path compu= tation. The procedures should also cover support for OAM functions. > > Where use cases are documented, care should be taken to define the data p= lane requirements for the environment within which they are to be implement= ed. The procedures should avoid modifications to the MPLS data plane, in or= der to remain compatible with existing extensive deployments of MPLS. It is= anticipated that the procedures may require modifications to the IPv6 data= plane. While the initial focus of the WG is on the intra-domai= n deployment scenarios (see below), the modifications to the IPv6 data plan= e must support both intra and inter-domain deployment scenarios. > > The working group is chartered for the following (ordered) lis= t of items: > > o Identification and evaluation of use cases for which there > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying > technology. The new procedures must cover security considerations > (including the relationship between networks forming the > region) and allow for solutions which substantially improve upon > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > > The working group will develop the following documents: > > o One or more documents describing use cases, o Specification = of new procedures to support use cases, o Changes to MPLS archit= ecture, if needed o Changes to IPv6 architecture, if needed o Document inte= rworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume= nt impact (if any) of any proposed IPv6 data plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, o Inte= r-operability reports pertaining to the implementation of extensions > supporting . > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From rjs@rob.sh Wed Sep 18 02:49:13 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164AB11E821C for ; Wed, 18 Sep 2013 02:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeIFkkDYoFsr for ; Wed, 18 Sep 2013 02:49:12 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 146EF11E81C1 for ; Wed, 18 Sep 2013 02:49:10 -0700 (PDT) Received: from [109.144.252.200] (helo=[10.210.12.79]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VMEMg-0007Nj-OV; Wed, 18 Sep 2013 10:48:06 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Rob Shakir In-Reply-To: <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> Date: Wed, 18 Sep 2013 10:49:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> To: John G.Scudder X-Mailer: Apple Mail (2.1503) Cc: Adrian Farrel , "status@ietf.org" , stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:49:13 -0000 Hi John, STATUS, I'd just like to voice my support for this revised wording - I think it = addresses my previous comments. I would agree with Robert - that we should not attempt to enumerate = where state might need to be held within this charter. The fundamental = here is that it is not on the mid-point. For some cases, the only state = that will be held is at the head-end (where the forwarding state is the = set of segment identifiers that it has calculated itself, or has been = provided to it by a PCE), in other cases, such as where CAC/co-routing = is being performed by a centralised entity (such as stateful PCE) then = we will need the head-end to have the forwarding state, and the PCE will = need to hold some state. Given there are a number of combinations of = such cases, we should leave use-case documents to describe exactly the = deployment which is envisaged.=20 Thanks, r. On 17 Sep 2013, at 15:21, John G.Scudder wrote: > All, >=20 > Here's another attempt. It tries to address the 'architecture' issue I = raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and = Rob Shakir's comments. With luck the change from ' domain' to = ' region' relieves the ambiguity that was present in earlier = versions. >=20 > --John >=20 > --------------------------------------------------------- > Name: >=20 > The working group will define procedures that will allow > a node to steer a packet between any source and destination through > a region on any path without requiring state to be > maintained by transited nodes, but rather at the source device. A > region is a network comprised of nodes (which may be of > any type, including routers and appliances) that share the following > trust model: any node in the region is trusted to steer=20 > a packet through any of the other nodes within the region. The=20 > region may comprise one or more ASes, or even less than a=20= > single AS. Although a region may comprise more than one AS, initial=20 > work will focus on the intra-domain, that is, single AS, scenario. >=20 > The procedures should support both centralised and distributed path > computation. The procedures should also cover support for OAM > functions. >=20 > Where use cases are documented, care should be taken to define the > data plane requirements for the environment within which they are > to be implemented. The procedures should avoid modifications to > the MPLS data plane, in order to remain compatible with existing > extensive deployments of MPLS. It is anticipated that the procedures > may require modifications to the IPv6 data plane. While the initial > focus of the WG is on the intra-domain deployment scenarios > (see below), the modifications to the IPv6 data plane must support > both intra and inter-domain deployment scenarios. >=20 > The working group is chartered for the following (ordered) > list of items: >=20 > o Identification and evaluation of use cases for which there=20 > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying=20= > technology. The new procedures must cover security considerations=20 > (including the relationship between networks forming the =20= > region) and allow for solutions which substantially improve upon=20 > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this = will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. >=20 > The working group will develop the following documents: >=20 > o One or more documents describing use cases, > o Specification of new procedures to support use cases, > o Changes to MPLS architecture, if needed > o Changes to IPv6 architecture, if needed > o Document interworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), > o Document impact (if any) of any proposed IPv6 data plane = modifications =20 > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of = extensions > supporting . > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From gregory.mirsky@ericsson.com Wed Sep 18 11:00:28 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5A11E80E4 for ; Wed, 18 Sep 2013 11:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiFpllV8Ih4m for ; Wed, 18 Sep 2013 11:00:22 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5D3611E80A2 for ; Wed, 18 Sep 2013 11:00:22 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-dc-5239ea35f02f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 93.26.09414.53AE9325; Wed, 18 Sep 2013 20:00:22 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Wed, 18 Sep 2013 14:00:21 -0400 From: Gregory Mirsky To: Robert Raszuk Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVqcq8gKrlpDEyA0gOT+W9FE5nKRFIAgABWa8CAAFzNgIAA11sA Date: Wed, 18 Sep 2013 18:00:20 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@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.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXSPt67ZK8sgg+VFFj96bjBbzLzxldWi aWETs8Xr5otMFueezmF0YPWY8nsjq8eSJT+ZPK43XWX3WLF5JaPH7o0LmAJYo7hsUlJzMstS i/TtErgyJjzdwVxwTr/i5Yrn7A2Mr9S6GDk4JARMJOZM8u1i5AQyxSQu3FvP1sXIxSEkcJRR YnLjSlYIZzmjxKvpO9hBqtgEjCRebOwBs0UEVCU6TzxiBiliFpjLKLF56hFmkKnCAo4SGxbo QtQ4SexfNZcRJCwi4Cbx5IAuiMkC1Hp8I9gUXgFfiYat3WwgtpDAC0aJv9NDQWxOgUCJD+9e gsUZgW77fmoNE4jNLCAucevJfCaImwUkluw5zwxhi0q8fPyPFcJWlvg+5xELRL2OxILdn9gg bG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBMbWMQk2 3R2Me15aHmKU5mBREuddpXcmUEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjwpqtHq/K1koV Bs//9OLlfNXpVxarhHWZOzbrqK5bsFLv7syajyoBa7WYvxpazFi9ed51kaJVnyLVGiviROtW vF74369FM//A5FiPyRPuKrru3pjGWjPpYNL0mNqpB4U4Fp2Z/uvWnLXHvWeeVt01wXGx6L5z NnvKdUU4N5gvkll5ZMbsOdL+XkosxRmJhlrMRcWJAJAq6UJ7AgAA Cc: "John G.Scudder" , Adrian Farrel , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 18:00:28 -0000 Hi Robert, I think that intuitively we all understand what and who the transit nodes o= f region are. But I wonder if this understanding is common. And = I think that "transit node" characterization is more in path scope rather t= han on regional scale. If that is not the case and there is clear distincti= on between edge of head nodes and core or transit nodes, then, I think, we'= ll need to capture that and then put into architectural document. Regards, Greg -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Tuesday, September 17, 2013 6:03 PM To: Gregory Mirsky Cc: John G.Scudder; stbryant@cisco.com; Adrian Farrel; status@ietf.org Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no Hi Gregory, Wouldn't it be simpler to say that state is not kept in those network eleme= nts which are acting as transit nodes rather then enumerating all elements = which may impose headers or compute paths ? Thx, R. On Wed, Sep 18, 2013 at 1:36 AM, Gregory Mirsky wrote: > Hi John, et. al, > I think that because of second paragraph, "... support both centralized a= nd distributed path computation", a change is needed to specify that state = must be maintained not necessarily at the source device but at the path com= puting device (closing of the first sentence of the first paragraph). > > Regards, > Greg > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On=20 > Behalf Of John G.Scudder > Sent: Tuesday, September 17, 2013 7:22 AM > To: stbryant@cisco.com > Cc: Adrian Farrel; status@ietf.org > Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no > > All, > > Here's another attempt. It tries to address the 'architecture' issue I ra= ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob = Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. > > --John > > --------------------------------------------------------- > Name: > > The working group will define procedures that will allow a nod= e to steer a packet between any source and destination through a = region on any path without requiring state to be maintained by transited n= odes, but rather at the source device. A region is a network co= mprised of nodes (which may be of any type, including routers and appliance= s) that share the following trust model: any node in the region = is trusted to steer a packet through any of the other nodes within the regi= on. The region may comprise one or more ASes, or even less than = a single AS. Although a region may comprise more than one AS, initial work = will focus on the intra-domain, that is, single AS, scenario. > > The procedures should support both centralised and distributed path compu= tation. The procedures should also cover support for OAM functions. > > Where use cases are documented, care should be taken to define the data p= lane requirements for the environment within which they are to be implement= ed. The procedures should avoid modifications to the MPLS data plane, in or= der to remain compatible with existing extensive deployments of MPLS. It is= anticipated that the procedures may require modifications to the IPv6 data= plane. While the initial focus of the WG is on the intra-domai= n deployment scenarios (see below), the modifications to the IPv6 data plan= e must support both intra and inter-domain deployment scenarios. > > The working group is chartered for the following (ordered) lis= t of items: > > o Identification and evaluation of use cases for which there > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying > technology. The new procedures must cover security considerations > (including the relationship between networks forming the > region) and allow for solutions which substantially improve upon > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > > The working group will develop the following documents: > > o One or more documents describing use cases, o Specification = of new procedures to support use cases, o Changes to MPLS archit= ecture, if needed o Changes to IPv6 architecture, if needed o Document inte= rworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume= nt impact (if any) of any proposed IPv6 data plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, o Inte= r-operability reports pertaining to the implementation of extensions > supporting . > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From Ruediger.Geib@telekom.de Wed Sep 18 23:34:03 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD8521F941F for ; Wed, 18 Sep 2013 23:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n85QuP7Vx0a3 for ; Wed, 18 Sep 2013 23:33:59 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id DB42421F9BB5 for ; Wed, 18 Sep 2013 23:33:58 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 19 Sep 2013 08:33:55 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.193]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 Sep 2013 08:33:53 +0200 From: To: Date: Thu, 19 Sep 2013 08:33:52 +0200 Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVqcq8gKrlpDEyA0gOT+W9FE5nKRFIAgABWa8CAAFzNgIAA11sAgADRQzA= Message-ID: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: adrian@olddog.co.uk, status@ietf.org, stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 06:34:03 -0000 John, there's another detail which should be clarified: > The working group is chartered for the following (ordered) lis= t of items: .... I'd expect work related to MPLS based SR to start relatively soon, while wo= rk on IPv6 based SR may require a more thorough analysis. The "(ordered)" t= herefore should be removed or the order should be adapted to express that: o Determine whether the above mentioned procedures require modification/changes to the existing MPLS architecture, and if so, then document such modifications/changes. o Determine whether the above mentioned procedures require modification/changes to the existing IPv6 architecture, and if so, then document such modifications/changes. In parallel, the working group will develop solutions for a MPLS architecture, focusing initially on intra-domain deployment scenarios. Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the working group. o The working group will then develop solutions for an IPv6 architecture, focusing initially on intra-domain deployment scenarios. Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working grou= p. Work on new protocols may be carried out by the working grou= p. Regards, Ruediger > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > Behalf Of John G.Scudder > Sent: Tuesday, September 17, 2013 7:22 AM > To: stbryant@cisco.com > Cc: Adrian Farrel; status@ietf.org > Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no > > All, > > Here's another attempt. It tries to address the 'architecture' issue I ra= ised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob = Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. > > --John > > --------------------------------------------------------- > Name: > > The working group will define procedures that will allow a nod= e to steer a packet between any source and destination through a = region on any path without requiring state to be maintained by transited n= odes, but rather at the source device. A region is a network co= mprised of nodes (which may be of any type, including routers and appliance= s) that share the following trust model: any node in the region = is trusted to steer a packet through any of the other nodes within the regi= on. The region may comprise one or more ASes, or even less than = a single AS. Although a region may comprise more than one AS, initial work = will focus on the intra-domain, that is, single AS, scenario. > > The procedures should support both centralised and distributed path compu= tation. The procedures should also cover support for OAM functions. > > Where use cases are documented, care should be taken to define the data p= lane requirements for the environment within which they are to be implement= ed. The procedures should avoid modifications to the MPLS data plane, in or= der to remain compatible with existing extensive deployments of MPLS. It is= anticipated that the procedures may require modifications to the IPv6 data= plane. While the initial focus of the WG is on the intra-domai= n deployment scenarios (see below), the modifications to the IPv6 data plan= e must support both intra and inter-domain deployment scenarios. > > The working group is chartered for the following (ordered) lis= t of items: > > o Identification and evaluation of use cases for which there > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying > technology. The new procedures must cover security considerations > (including the relationship between networks forming the > region) and allow for solutions which substantially improve upon > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > > The working group will develop the following documents: > > o One or more documents describing use cases, o Specification = of new procedures to support use cases, o Changes to MPLS archit= ecture, if needed o Changes to IPv6 architecture, if needed o Document inte= rworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume= nt impact (if any) of any proposed IPv6 data plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, o Inte= r-operability reports pertaining to the implementation of extensions > supporting . > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From sprevidi@cisco.com Wed Sep 18 23:47:37 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EDD21F9B86 for ; Wed, 18 Sep 2013 23:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.576 X-Spam-Level: X-Spam-Status: No, score=-109.576 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIVpkIUnDizx for ; Wed, 18 Sep 2013 23:47:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EA2E321F9B66 for ; Wed, 18 Sep 2013 23:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7091; q=dns/txt; s=iport; t=1379573251; x=1380782851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1PWPLZTkVTiNvb43F8rPhS3s0R9SGuhpuOAM/O1xGbE=; b=MOocOtONzqMi7vJJDshoHoRJhnhJMoIt8b1RJpaRctVzkkjh6lY7nfOy 6XgsEuPPIEk3UMZO2JnKEJHaicr/NyoL6mBNsoJRdQMvH/3TBErSYXHaL njr1VZ3/vMQb+9ZHnSjYCuDoe6LS7kaQE4+/BG9aadVuWXaPFO/TJTQmI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALedOlKtJXHA/2dsb2JhbABagwc4UsBjSoEhFnSCJQEBAQMBAQEBNy0HBAcFBwQCAQgRAQMBAQEKFAkHJwsUAwYIAgQBDQUIE4diBgyrdI1/BI80AgYrBwaDGIEAA5QflVCDJIIq X-IronPort-AV: E=Sophos;i="4.90,935,1371081600"; d="scan'208";a="261552201" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 19 Sep 2013 06:47:30 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8J6lU98022878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 06:47:30 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 01:47:29 -0500 From: "Stefano Previdi (sprevidi)" To: Ruediger Geib , "John G. Scudder" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVoHimsYDaTXkKT2SnKgr9E2ZnKVRUAgACbC4CAABgtgIABHDoAgADSiQCAAAPKAA== Date: Thu, 19 Sep 2013 06:47:29 +0000 Message-ID: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@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: [10.147.74.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Farrel , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 06:47:37 -0000 Hi Ruediger, John, On Sep 19, 2013, at 8:33 AM, wrote: > John, >=20 > there's another detail which should be clarified: >=20 >> The working group is chartered for the following (ordered) li= st of items: > .... >=20 > I'd expect work related to MPLS based SR to start relatively soon, while = work on IPv6 based SR may require a more thorough analysis. I agree. We already have use-cases, architecture and protocol extensions=20 drafts (ISIS/OSPF) that have been submitted a while ago and we=20 should not defer the work on these just because we mandate an=20 ordered list. > The "(ordered)" therefore should be removed or the order should be adapt= ed to express that: yes, I'd just remove the "ordered" term. I believe the WG audience=20 will figure out what work can proceed without having to mandate any=20 "order". Thanks. s. >=20 > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > In parallel, the working group will develop > solutions for a MPLS architecture, focusing initially on > intra-domain deployment scenarios. Where such solutions > utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > o The working group will then develop solutions for an IPv6 > architecture, focusing initially on intra-domain deployment scenarios. > Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE= ) > this will be done in conjunction with the responsible IETF working gro= up. > Work on new protocols may be carried out by the working gro= up. >=20 > Regards, >=20 > Ruediger >=20 >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of John G.Scudder >> Sent: Tuesday, September 17, 2013 7:22 AM >> To: stbryant@cisco.com >> Cc: Adrian Farrel; status@ietf.org >> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >>=20 >> All, >>=20 >> Here's another attempt. It tries to address the 'architecture' issue I r= aised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob= Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. >>=20 >> --John >>=20 >> --------------------------------------------------------- >> Name: >>=20 >> The working group will define procedures that will allow a no= de to steer a packet between any source and destination through a region on any path without requiring state to be maintained by transited = nodes, but rather at the source device. A region is a network c= omprised of nodes (which may be of any type, including routers and applianc= es) that share the following trust model: any node in the region= is trusted to steer a packet through any of the other nodes within the reg= ion. The region may comprise one or more ASes, or even less than= a single AS. Although a region may comprise more than one AS, initial work= will focus on the intra-domain, that is, single AS, scenario. >>=20 >> The procedures should support both centralised and distributed path comp= utation. The procedures should also cover support for OAM functions. >>=20 >> Where use cases are documented, care should be taken to define the data = plane requirements for the environment within which they are to be implemen= ted. The procedures should avoid modifications to the MPLS data plane, in o= rder to remain compatible with existing extensive deployments of MPLS. It i= s anticipated that the procedures may require modifications to the IPv6 dat= a plane. While the initial focus of the WG is on the intra-doma= in deployment scenarios (see below), the modifications to the IPv6 data pla= ne must support both intra and inter-domain deployment scenarios. >>=20 >> The working group is chartered for the following (ordered) li= st of items: >>=20 >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the working group. >>=20 >> The working group will develop the following documents: >>=20 >> o One or more documents describing use cases, o Specification= of new procedures to support use cases, o Changes to MPLS archi= tecture, if needed o Changes to IPv6 architecture, if needed o Document int= erworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume= nt impact (if any) of any proposed IPv6 data plane modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, o Int= er-operability reports pertaining to the implementation of extensions >> supporting . >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From jeff.tantsura@ericsson.com Wed Sep 18 23:52:47 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDEE21F9BFA for ; Wed, 18 Sep 2013 23:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK52+GRXXjOA for ; Wed, 18 Sep 2013 23:52:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E5C1621F9C12 for ; Wed, 18 Sep 2013 23:52:41 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-51-523a9f387264 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 05.ED.09414.83F9A325; Thu, 19 Sep 2013 08:52:40 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 02:52:39 -0400 From: Jeff Tantsura To: "Ruediger.Geib@telekom.de" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVq7lK1J/GgikaEpzsiQxZ1+5nKRFIAgACbCoCAABgugIABHDkAgADSiQD//8IyVQ== Date: Thu, 19 Sep 2013 06:52:39 +0000 Message-ID: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPrK7FfKsgg2fzFSx+9Nxgtph54yur xYdpHBavmy8yWZx7OofRgdVjyu+NrB5Llvxk8rjedJXdY8XmlYwebS8VAlijuGxSUnMyy1KL 9O0SuDLmPLUu+GBS8WjLW6YGxuPaXYycHBICJhLzj/5mhLDFJC7cW8/WxcjFISRwlFFiwYQz 7BDOckaJsyf+g1WxCRhI/P92nAXEFhGwlNgzaylYEbPACkaJOW2Tgdo5OIQFHCUOPfSBqHGS 2L9qLiOEHSbxd8lSsF4WAVWJC61LwOK8AvYSP0/fgVr2m0ni1uGdrCBzOAWiJd59MQWpYQS6 7vupNUwgNrOAuMStJ/OZIK4WkFiy5zwzhC0q8fLxP1aIGh2JBbs/sUHY2hLLFr5mhtglKHFy 5hOWCYyis5CMmoWkZRaSlllIWhYwsqxi5CgtTi3LTTcy2MQIjKJjEmy6Oxj3vLQ8xCjNwaIk zrtK70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaHkvCLKvMqPzmIaDK1Tzfer2i14KS1 RC//EZPEpQtWcPhsqVB5JyX8PcTJtyI0/jHDnsLDxjkmmtbN/6LXl8ndr8/IjVy6oS6S8bGK 0t2YybdOn5i0oXTrB4vPU0JvHjX5fqlS8LLwnK/bA9e/n/v3kO2zteue7/xxNnSCcXuk0dlN fslpDhxKLMUZiYZazEXFiQBug5j8cAIAAA== Cc: "jgs@juniper.net" , "stbryant@cisco.com" , "status@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 06:52:47 -0000 Agree with Ruediger, also the order put looks about right. Regards, Jeff On Sep 18, 2013, at 11:34 PM, "Ruediger.Geib@telekom.de" wrote: > John, >=20 > there's another detail which should be clarified: >=20 >> The working group is chartered for the following (ordered) li= st of items: > .... >=20 > I'd expect work related to MPLS based SR to start relatively soon, while = work on IPv6 based SR may require a more thorough analysis. The "(ordered)"= therefore should be removed or the order should be adapted to express tha= t: >=20 > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > In parallel, the working group will develop > solutions for a MPLS architecture, focusing initially on > intra-domain deployment scenarios. Where such solutions > utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > o The working group will then develop solutions for an IPv6 > architecture, focusing initially on intra-domain deployment scenarios. > Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE= ) > this will be done in conjunction with the responsible IETF working gro= up. > Work on new protocols may be carried out by the working gro= up. >=20 > Regards, >=20 > Ruediger >=20 >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of John G.Scudder >> Sent: Tuesday, September 17, 2013 7:22 AM >> To: stbryant@cisco.com >> Cc: Adrian Farrel; status@ietf.org >> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >>=20 >> All, >>=20 >> Here's another attempt. It tries to address the 'architecture' issue I r= aised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob= Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. >>=20 >> --John >>=20 >> --------------------------------------------------------- >> Name: >>=20 >> The working group will define procedures that will allow a no= de to steer a packet between any source and destination through a region on any path without requiring state to be maintained by transited = nodes, but rather at the source device. A region is a network c= omprised of nodes (which may be of any type, including routers and applianc= es) that share the following trust model: any node in the region= is trusted to steer a packet through any of the other nodes within the reg= ion. The region may comprise one or more ASes, or even less than= a single AS. Although a region may comprise more than one AS, initial work= will focus on the intra-domain, that is, single AS, scenario. >>=20 >> The procedures should support both centralised and distributed path comp= utation. The procedures should also cover support for OAM functions. >>=20 >> Where use cases are documented, care should be taken to define the data = plane requirements for the environment within which they are to be implemen= ted. The procedures should avoid modifications to the MPLS data plane, in o= rder to remain compatible with existing extensive deployments of MPLS. It i= s anticipated that the procedures may require modifications to the IPv6 dat= a plane. While the initial focus of the WG is on the intra-doma= in deployment scenarios (see below), the modifications to the IPv6 data pla= ne must support both intra and inter-domain deployment scenarios. >>=20 >> The working group is chartered for the following (ordered) li= st of items: >>=20 >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the working group. >>=20 >> The working group will develop the following documents: >>=20 >> o One or more documents describing use cases, o Specification= of new procedures to support use cases, o Changes to MPLS archi= tecture, if needed o Changes to IPv6 architecture, if needed o Document int= erworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docume= nt impact (if any) of any proposed IPv6 data plane modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, o Int= er-operability reports pertaining to the implementation of extensions >> supporting . >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From mark@townsley.net Thu Sep 19 00:17:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E535C21F9B03 for ; Thu, 19 Sep 2013 00:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tXdDx9zEnjc for ; Thu, 19 Sep 2013 00:17:47 -0700 (PDT) Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id C260C21F9AD5 for ; Thu, 19 Sep 2013 00:17:46 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so3917421eaj.6 for ; Thu, 19 Sep 2013 00:17:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8RACso4aFm3s5rOpvmBMR/+3iyixwVnrwGONA8rb42w=; b=H4/jt7qTSAz7SLvaVTrf28DMpC+dzM4l20TmXMWunFoS5xlHwfgBWMCkdf/EBA8pwX xAUv2wWCAPysPPyAvAPavEawj2HAAxm6OwdL/rHHiuzNxI0n6eZGHjXNMheh6E6LQ17N yFdU0peSX6e+PFxevAx8URHt7YLwLSUshGaF+SbJSNqXeOVn8rt9AF8UjRLU1ybQ76HY Sif4NWPLFxIdhcMU3CyLkBq+RK0Mv0Hm/wtkpvx0EVEDwO5QhjfB3OmqNAX3BGolqREz 2RYn+h4rh3z2o9NkfpgKpu4MqVCbI5ckuf8a4loaZUZiYx+1t2cepDV1Jfb6sioB0nEe Vbpg== X-Gm-Message-State: ALoCoQl1GVSAVluQ8ymmLi41mqu9b4Q68KROLVafDaCW9WmjiFivy4cJyurq9Z58pP5Gxso6s2lz X-Received: by 10.14.88.65 with SMTP id z41mr236922eee.38.1379575065728; Thu, 19 Sep 2013 00:17:45 -0700 (PDT) Received: from ams-townsley-8915.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id r48sm8885070eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 00:17:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Thu, 19 Sep 2013 09:17:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se>, To: Jeff Tantsura X-Mailer: Apple Mail (2.1283) Cc: "jgs@juniper.net" , "Ruediger.Geib@telekom.de" , "adrian@olddog.co.uk" , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 07:17:52 -0000 +1.=20 Also, any expected ordering can be reflected in the WG milestones that = can be updated based on the pace and output of the WG without going = through the entire IETF consensus process the charter text must go = through.=20 - Mark On Sep 19, 2013, at 8:52 AM, Jeff Tantsura wrote: > Agree with Ruediger, also the order put looks about right. >=20 > Regards, > Jeff >=20 > On Sep 18, 2013, at 11:34 PM, "Ruediger.Geib@telekom.de" = wrote: >=20 >> John, >>=20 >> there's another detail which should be clarified: >>=20 >>> The working group is chartered for the following = (ordered) list of items: >> .... >>=20 >> I'd expect work related to MPLS based SR to start relatively soon, = while work on IPv6 based SR may require a more thorough analysis. The = "(ordered)" therefore should be removed or the order should be adapted = to express that: >>=20 >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> In parallel, the working group will develop >> solutions for a MPLS architecture, focusing initially on >> intra-domain deployment scenarios. Where such solutions >> utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. = Work >> on new protocols may be carried out by the working = group. >> o The working group will then develop solutions for an = IPv6 >> architecture, focusing initially on intra-domain deployment = scenarios. >> Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, = PCE) >> this will be done in conjunction with the responsible IETF working = group. >> Work on new protocols may be carried out by the working = group. >>=20 >> Regards, >>=20 >> Ruediger >>=20 >>=20 >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of John G.Scudder >>> Sent: Tuesday, September 17, 2013 7:22 AM >>> To: stbryant@cisco.com >>> Cc: Adrian Farrel; status@ietf.org >>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >>>=20 >>> All, >>>=20 >>> Here's another attempt. It tries to address the 'architecture' issue = I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene = and Rob Shakir's comments. With luck the change from ' domain' = to ' region' relieves the ambiguity that was present in = earlier versions. >>>=20 >>> --John >>>=20 >>> --------------------------------------------------------- >>> Name: >>>=20 >>> The working group will define procedures that will allow = a node to steer a packet between any source and destination through a = region on any path without requiring state to be maintained = by transited nodes, but rather at the source device. A = region is a network comprised of nodes (which may be of any type, = including routers and appliances) that share the following trust model: = any node in the region is trusted to steer a packet through = any of the other nodes within the region. The region may = comprise one or more ASes, or even less than a single AS. Although a = region may comprise more than one AS, initial work will focus on the = intra-domain, that is, single AS, scenario. >>>=20 >>> The procedures should support both centralised and distributed path = computation. The procedures should also cover support for OAM functions. >>>=20 >>> Where use cases are documented, care should be taken to define the = data plane requirements for the environment within which they are to be = implemented. The procedures should avoid modifications to the MPLS data = plane, in order to remain compatible with existing extensive deployments = of MPLS. It is anticipated that the procedures may require modifications = to the IPv6 data plane. While the initial focus of the WG is = on the intra-domain deployment scenarios (see below), the modifications = to the IPv6 data plane must support both intra and inter-domain = deployment scenarios. >>>=20 >>> The working group is chartered for the following = (ordered) list of items: >>>=20 >>> o Identification and evaluation of use cases for which there >>> is consensus within the WG. >>> o Definition of new procedures, driven by the use cases and = underlying >>> technology. The new procedures must cover security considerations >>> (including the relationship between networks forming the >>> region) and allow for solutions which substantially improve upon >>> current technologies by defining requirements, extensions, or new >>> functionality in existing routing, management or other protocols. >>> o Determine whether the above mentioned procedures require >>> modification/changes to the existing MPLS architecture, and >>> if so, then document such modifications/changes. >>> o Determine whether the above mentioned procedures require >>> modification/changes to the existing IPv6 architecture, and >>> if so, then document such modifications/changes. >>> o The working group will then develop solutions, focusing >>> initially on intra-domain deployment scenarios. Where such >>> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this = will >>> be done in conjunction with the responsible IETF working group. Work >>> on new protocols may be carried out by the working group. >>>=20 >>> The working group will develop the following documents: >>>=20 >>> o One or more documents describing use cases, o = Specification of new procedures to support use cases, o = Changes to MPLS architecture, if needed o Changes to IPv6 architecture, = if needed o Document interworking and co-existence between the new = procedures >>> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o = Document impact (if any) of any proposed IPv6 data plane modifications >>> on existing deployment of IPv6, >>> o A set of one or more protocol extensions requirements documents, o = Inter-operability reports pertaining to the implementation of extensions >>> supporting . >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From bruno.decraene@orange.com Thu Sep 19 00:49:46 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B2221F9AA1 for ; Thu, 19 Sep 2013 00:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptMFz721lZCT for ; Thu, 19 Sep 2013 00:49:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id F11A021F9AA7 for ; Thu, 19 Sep 2013 00:49:40 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 69B002AC7A0; Thu, 19 Sep 2013 09:49:39 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 40CBF1580A2; Thu, 19 Sep 2013 09:49:39 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 09:49:38 +0200 From: To: "Ruediger.Geib@telekom.de" , "jgs@juniper.net" Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: AQHOsJVqHimsYDaTXkKT2SnKgr9E2ZnKRFIAgABWa8CAAFzNgIAA11sAgADRQzCAABEBwA== Date: Thu, 19 Sep 2013 07:49:38 +0000 Message-ID: <12616_1379576979_523AAC93_12616_1380_1_53C29892C857584299CBF5D05346208A0705EB99@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "adrian@olddog.co.uk" , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 07:49:47 -0000 John, Thank you for the proposed charter which looks fine to me. Nonetheless, +1 to Ruediger's comment: the last 3 points (MPLS forwarding p= lane, IPv6 forwarding plane, generic control plane) may be done in no parti= cular order, including in parallel. (and at the very least, if an order is mandatory, it would ease the WG life= /work to favor an order based on maturity & consensus, i.e. starting with M= PLS and not putting IPv6 forwarding plane extension on the critical path) Regards, Bruno >From: Ruediger.Geib@telekom.de > >John, > >there's another detail which should be clarified: > >> The working group is chartered for the following (ordered) li= st >of items: >.... > >I'd expect work related to MPLS based SR to start relatively soon, while >work on IPv6 based SR may require a more thorough analysis. The "(ordered)" >therefore should be removed or the order should be adapted to express tha= t: > > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > In parallel, the working group will develop > solutions for a MPLS architecture, focusing initially on > intra-domain deployment scenarios. Where such solutions > utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > o The working group will then develop solutions for an IPv6 > architecture, focusing initially on intra-domain deployment scenarios. > Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) > this will be done in conjunction with the responsible IETF working >group. > Work on new protocols may be carried out by the working >group. > >Regards, > >Ruediger > > >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of John G.Scudder >> Sent: Tuesday, September 17, 2013 7:22 AM >> To: stbryant@cisco.com >> Cc: Adrian Farrel; status@ietf.org >> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >> >> All, >> >> Here's another attempt. It tries to address the 'architecture' issue I >raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and R= ob >Shakir's comments. With luck the change from ' domain' to 'TBD> region' relieves the ambiguity that was present in earlier versions. >> >> --John >> >> --------------------------------------------------------- >> Name: >> >> The working group will define procedures that will allow a no= de >to steer a packet between any source and destination through a >region on any path without requiring state to be maintained by transited >nodes, but rather at the source device. A region is a network >comprised of nodes (which may be of any type, including routers and >appliances) that share the following trust model: any node in the >region is trusted to steer a packet through any of the other nodes within >the region. The region may comprise one or more ASes, or even >less than a single AS. Although a region may comprise more than one AS, >initial work will focus on the intra-domain, that is, single AS, scenario. >> >> The procedures should support both centralised and distributed path >computation. The procedures should also cover support for OAM functions. >> >> Where use cases are documented, care should be taken to define the data >plane requirements for the environment within which they are to be >implemented. The procedures should avoid modifications to the MPLS data >plane, in order to remain compatible with existing extensive deployments of >MPLS. It is anticipated that the procedures may require modifications to t= he >IPv6 data plane. While the initial focus of the WG is on the >intra-domain deployment scenarios (see below), the modifications to the IP= v6 >data plane must support both intra and inter-domain deployment scenarios. >> >> The working group is chartered for the following (ordered) li= st >of items: >> >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the working group. >> >> The working group will develop the following documents: >> >> o One or more documents describing use cases, o Specification >of new procedures to support use cases, o Changes to MPLS >architecture, if needed o Changes to IPv6 architecture, if needed o Docume= nt >interworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o >Document impact (if any) of any proposed IPv6 data plane modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, o >Inter-operability reports pertaining to the implementation of extensions >> supporting . >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jgs@juniper.net Thu Sep 19 06:47:21 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B4B21F9302 for ; Thu, 19 Sep 2013 06:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.382 X-Spam-Level: X-Spam-Status: No, score=-4.382 tagged_above=-999 required=5 tests=[AWL=2.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeMnaWrCpZqA for ; Thu, 19 Sep 2013 06:47:15 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0C85021F92B9 for ; Thu, 19 Sep 2013 06:47:14 -0700 (PDT) Received: from mail226-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Thu, 19 Sep 2013 13:47:11 +0000 Received: from mail226-tx2 (localhost [127.0.0.1]) by mail226-tx2-R.bigfish.com (Postfix) with ESMTP id A0B09540064; Thu, 19 Sep 2013 13:47:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 6 X-BigFish: VPS6(zz98dI9371Ida00hdc73hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail226-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(24454002)(50226001)(49866001)(36756003)(47976001)(50986001)(76796001)(558084003)(47736001)(81342001)(81816001)(69226001)(81686001)(56816003)(33656001)(77156001)(81542001)(51856001)(23726002)(82746002)(77096001)(53416003)(53806001)(74706001)(46102001)(74662001)(31966008)(42186004)(77982001)(79102001)(65816001)(74876001)(66066001)(76786001)(80022001)(74366001)(4396001)(74502001)(57306001)(47446002)(46406003)(63696002)(80976001)(83072001)(76482001)(54316002)(50466002)(62966002)(59766001)(83322001)(19580395003)(19580405001)(47776003)(56776001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail226-tx2 (localhost.localdomain [127.0.0.1]) by mail226-tx2 (MessageSwitch) id 137959836536613_11873; Thu, 19 Sep 2013 13:46:05 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.241]) by mail226-tx2.bigfish.com (Postfix) with ESMTP id 4C40A8000A7; Thu, 19 Sep 2013 13:45:56 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 19 Sep 2013 13:45:54 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 19 Sep 2013 13:45:49 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 19 Sep 2013 13:45:48 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: Date: Thu, 19 Sep 2013 09:45:37 -0400 Content-Transfer-Encoding: 7bit Message-ID: <63625F62-3C20-4F4D-A63B-1CE1F1C2933D@juniper.net> References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> To: X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: BN1PR06CA004.namprd06.prod.outlook.com (10.242.217.142) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 09749A275C X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: adrian@olddog.co.uk, status@ietf.org, stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 13:47:21 -0000 On Sep 19, 2013, at 2:33 AM, Ruediger.Geib@telekom.de wrote: > The "(ordered)" therefore should be removed or the order should be adapted That would be just fine with me. --John From loa@pi.nu Thu Sep 19 08:48:44 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83E21F960E for ; Thu, 19 Sep 2013 08:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN+eMRv3rB4o for ; Thu, 19 Sep 2013 08:48:39 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 52D9721F9399 for ; Thu, 19 Sep 2013 08:48:39 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2A69F1802038; Thu, 19 Sep 2013 17:48:38 +0200 (CEST) Message-ID: <523B1CD5.2030208@pi.nu> Date: Thu, 19 Sep 2013 17:48:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: adrian@olddog.co.uk, status@ietf.org, stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:48:44 -0000 Ruediger, it depends on what you mean with "document such modifications/changes". Almost everything we do in the IETF is documents - we are documenting. In this case I assume you mean "document the requirements for such changes" and then let the the working group that owns the particular data plane specify the actual changes. Otherwise this look pretty good. /Loa On 2013-09-19 08:33, Ruediger.Geib@telekom.de wrote: > John, > > there's another detail which should be clarified: > >> The working group is chartered for the following (ordered) list of items: > .... > > I'd expect work related to MPLS based SR to start relatively soon, while work on IPv6 based SR may require a more thorough analysis. The "(ordered)" therefore should be removed or the order should be adapted to express that: > > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > In parallel, the working group will develop > solutions for a MPLS architecture, focusing initially on > intra-domain deployment scenarios. Where such solutions > utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > o The working group will then develop solutions for an IPv6 > architecture, focusing initially on intra-domain deployment scenarios. > Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) > this will be done in conjunction with the responsible IETF working group. > Work on new protocols may be carried out by the working group. > > Regards, > > Ruediger > > >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of John G.Scudder >> Sent: Tuesday, September 17, 2013 7:22 AM >> To: stbryant@cisco.com >> Cc: Adrian Farrel; status@ietf.org >> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >> >> All, >> >> Here's another attempt. It tries to address the 'architecture' issue I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. >> >> --John >> >> --------------------------------------------------------- >> Name: >> >> The working group will define procedures that will allow a node to steer a packet between any source and destination through a region on any path without requiring state to be maintained by transited nodes, but rather at the source device. A region is a network comprised of nodes (which may be of any type, including routers and appliances) that share the following trust model: any node in the region is trusted to steer a packet through any of the other nodes within the region. The region may comprise one or more ASes, or even less than a single AS. Although a region may comprise more than one AS, initial work will focus on the intra-domain, that is, single AS, scenario. >> >> The procedures should support both centralised and distributed path computation. The procedures should also cover support for OAM functions. >> >> Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The procedures should avoid modifications to the MPLS data plane, in order to remain compatible with existing extensive deployments of MPLS. It is anticipated that the procedures may require modifications to the IPv6 data plane. While the initial focus of the WG is on the intra-domain deployment scenarios (see below), the modifications to the IPv6 data plane must support both intra and inter-domain deployment scenarios. >> >> The working group is chartered for the following (ordered) list of items: >> >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the working group. >> >> The working group will develop the following documents: >> >> o One or more documents describing use cases, o Specification of new procedures to support use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 architecture, if needed o Document interworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any proposed IPv6 data plane modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensions >> supporting . >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From Ruediger.Geib@telekom.de Thu Sep 19 23:31:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7BA21F85E6 for ; Thu, 19 Sep 2013 23:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31vbC3OQjFee for ; Thu, 19 Sep 2013 23:31:37 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id A54AA21F84B1 for ; Thu, 19 Sep 2013 23:31:36 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 20 Sep 2013 08:31:33 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.193]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 20 Sep 2013 08:31:33 +0200 From: To: Date: Fri, 20 Sep 2013 08:31:33 +0200 Thread-Topic: [Status] TBD Charter - ready of RTG AD review yes/no Thread-Index: Ac61T8Cp/svLsAuBTiWG1TaWDfu+VwAetz4Q Message-ID: References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> <523B1CD5.2030208@pi.nu> In-Reply-To: <523B1CD5.2030208@pi.nu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: adrian@olddog.co.uk, loa@pi.nu, status@ietf.org, stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 06:31:41 -0000 Hi John, Loa's comment below refers to a piece of text of your draft charter which I didn't change. So I think you should pick up his comment. Regards, Ruediger -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Thursday, September 19, 2013 5:49 PM To: Geib, R=FCdiger Cc: adrian@olddog.co.uk; status@ietf.org; stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no Ruediger, it depends on what you mean with "document such modifications/changes". Almost everything we do in the IETF is documents - we are documenting. In this case I assume you mean "document the requirements for such changes" and then let the the working group that owns the particular data plane specify the actual changes. Otherwise this look pretty good. /Loa On 2013-09-19 08:33, Ruediger.Geib@telekom.de wrote: > John, > > there's another detail which should be clarified: > >> The working group is chartered for the following (ordered) li= st of items: > .... > > I'd expect work related to MPLS based SR to start relatively soon, while = work on IPv6 based SR may require a more thorough analysis. The "(ordered)"= therefore should be removed or the order should be adapted to express tha= t: > > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > In parallel, the working group will develop > solutions for a MPLS architecture, focusing initially on > intra-domain deployment scenarios. Where such solutions > utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the working group. > o The working group will then develop solutions for an IPv6 > architecture, focusing initially on intra-domain deployment scenario= s. > Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, P= CE) > this will be done in conjunction with the responsible IETF working g= roup. > Work on new protocols may be carried out by the working g= roup. > > Regards, > > Ruediger > > >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >> Behalf Of John G.Scudder >> Sent: Tuesday, September 17, 2013 7:22 AM >> To: stbryant@cisco.com >> Cc: Adrian Farrel; status@ietf.org >> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >> >> All, >> >> Here's another attempt. It tries to address the 'architecture' issue I r= aised earlier, as well as incorporate Mark Townsley, Bruno Decraene and Rob= Shakir's comments. With luck the change from ' domain' to ' region' relieves the ambiguity that was present in earlier versions. >> >> --John >> >> --------------------------------------------------------- >> Name: >> >> The working group will define procedures that will allow a no= de to steer a packet between any source and destination through a region on any path without requiring state to be maintained by transited = nodes, but rather at the source device. A region is a network c= omprised of nodes (which may be of any type, including routers and applianc= es) that share the following trust model: any node in the region= is trusted to steer a packet through any of the other nodes within the reg= ion. The region may comprise one or more ASes, or even less than= a single AS. Although a region may comprise more than one AS, initial work= will focus on the intra-domain, that is, single AS, scenario. >> >> The procedures should support both centralised and distributed path comp= utation. The procedures should also cover support for OAM functions. >> >> Where use cases are documented, care should be taken to define the data = plane requirements for the environment within which they are to be implemen= ted. The procedures should avoid modifications to the MPLS data plane, in o= rder to remain compatible with existing extensive deployments of MPLS. It i= s anticipated that the procedures may require modifications to the IPv6 dat= a plane. While the initial focus of the WG is on the intra-doma= in deployment scenarios (see below), the modifications to the IPv6 data pla= ne must support both intra and inter-domain deployment scenarios. >> >> The working group is chartered for the following (ordered) li= st of items: >> >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this wil= l >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the working group. >> >> The working group will develop the following documents: >> >> o One or more documents describing use cases, o Specification= of new procedures to support use cases, o Changes to MPLS archi= tecture, if needed o Changes to IPv6 architecture, if needed o Document int= erworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Docu= ment impact (if any) of any proposed IPv6 data plane modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, o Int= er-operability reports pertaining to the implementation of extensions >> supporting . >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stbryant@cisco.com Fri Sep 20 02:28:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8690721F8E85 for ; Fri, 20 Sep 2013 02:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaxcNKOSC2vb for ; Fri, 20 Sep 2013 02:28:30 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1E78C21F8EC3 for ; Fri, 20 Sep 2013 02:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5053; q=dns/txt; s=iport; t=1379669310; x=1380878910; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=SLJSjZdm3i4bsqfNav41YMAJ2fjqeCbFZyha4qo6E4A=; b=hxZZnYdJ+vfQtp5qt1ITD/52v5IAUrOuPSvFoYeBSGyE7+h8pw6IFvpK FGYM+4haAEYeOItDLzjNCjgEQ1lb+zNh/jtkZn6y1mYx62eQ6+7okCD03 yQgHDkma14wulbO0HzGdgnpvd1Ncp1RRu3C0DKWsqqXUFb0uLeraGV15j Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAEQUPFKQ/khM/2dsb2JhbABbgwc4wgqBGRZtB4JkLwsGAS0PFhgDAgECATcUDQEHAQEXh2oMoDmaPASPZYQlA5Qfg12RdoMl X-IronPort-AV: E=Sophos;i="4.90,943,1371081600"; d="scan'208";a="18152075" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 20 Sep 2013 09:28:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8K9SQBK029027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 09:28:27 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8K9SO1H017645; Fri, 20 Sep 2013 10:28:26 +0100 (BST) Message-ID: <523C1538.1030701@cisco.com> Date: Fri, 20 Sep 2013 10:28:24 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "status@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-ads@tools.ietf.org" Subject: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 20 Sep 2013 09:28:35 -0000 This note is a summary of where we are with chartering the work that we are discussing on the STATUS list and the next steps. Firstly, as you know we (the ADs) had concerns with the name "STATUS" being confusing. Having considered quite a lot of possibilities, and not wanting the discussion to bog down on a name, Adrian and I have decided that the name Source Packet Routing in NetworkinG is as good as any. Thus SPRING is name that we are using in the charter process and is that I am putting in the data-tracker for formal processing. Propose to start with the charter text that John Scudder posted on 17/Sept with the following changes: s//SPRING/ I removed "ordered" from ordered list, as I think there was a consensus to do so in the following emails in the thread. I have not changed the state text, as I could not see a consensus on what if any change I should make. The charter is uploaded at https://datatracker.ietf.org/doc/charter-ietf-spring/ What we now need the list members to do is to propose any necessary changes to the text, and I will reflect the consensus of the group in revised charter text. The differences in the version of the charter text will be visible through the datatracker charter diff tool. For continuity, discussion will continue on the STATUS list until we have a chartered WG, at which point the Secretariat will switch us over. For reference the text I uploaded is as follows: Name: Source Packet Routing in Networking (SPRING) The SPRING working group will define procedures that will allow a node to steer a packet between any source and destination through a SPRING region on any path without requiring state to be maintained by transited nodes, but rather at the source device. A SPRING region is a network comprised of nodes (which may be of any type, including routers and appliances) that share the following trust model: any node in the SPRING region is trusted to steer a packet through any of the other nodes within the region. The SPRING region may comprise one or more ASes, or even less than a single AS. Although a region may comprise more than one AS, initial work will focus on the intra-domain, that is, single AS, scenario. The procedures should support both centralised and distributed path computation. The procedures should also cover support for OAM functions. Where use cases are documented, care should be taken to define the data plane requirements for the environment within which they are to be implemented. The procedures should avoid modifications to the MPLS data plane, in order to remain compatible with existing extensive deployments of MPLS. It is anticipated that the procedures may require modifications to the IPv6 data plane. While the initial focus of the SPRING WG is on the intra-domain deployment scenarios (see below), the modifications to the IPv6 data plane must support both intra and inter-domain deployment scenarios. The SPRING working group is chartered for the following list of items: o Identification and evaluation of use cases for which there is consensus within the WG. o Definition of new procedures, driven by the use cases and underlying technology. The new procedures must cover security considerations (including the relationship between networks forming the SPRING region) and allow for solutions which substantially improve upon current technologies by defining requirements, extensions, or new functionality in existing routing, management or other protocols. o Determine whether the above mentioned procedures require modification/changes to the existing MPLS architecture, and if so, then document such modifications/changes. o Determine whether the above mentioned procedures require modification/changes to the existing IPv6 architecture, and if so, then document such modifications/changes. o The SPRING working group will then develop solutions, focusing initially on intra-domain deployment scenarios. Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the SPRING working group. The working group will develop the following documents: o One or more documents describing SPRING use cases, o Specification of new procedures to support SPRING use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 architecture, if needed o Document interworking and co-existence between the new procedures and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any proposed IPv6 data plane modifications on existing deployment of IPv6, o A set of one or more protocol extensions requirements documents, o Inter-operability reports pertaining to the implementation of extensions supporting SPRING. Please review and propose changes you think are necessary to the list. - Stewart From loa@pi.nu Fri Sep 20 04:29:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2321F943C for ; Fri, 20 Sep 2013 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMzVegwQRvmI for ; Fri, 20 Sep 2013 04:29:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 659C221F8E70 for ; Fri, 20 Sep 2013 04:29:46 -0700 (PDT) Received: from [10.130.0.12] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C3EF11802038; Fri, 20 Sep 2013 13:29:44 +0200 (CEST) Message-ID: <523C31A6.50209@pi.nu> Date: Fri, 20 Sep 2013 13:29:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: status@ietf.org, "stbryant@cisco.com" References: <523C1538.1030701@cisco.com> In-Reply-To: <523C1538.1030701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 11:29:51 -0000 Stewart, SPRING is a nice name :). The only thing that I don't find clear in this charter is whether to specify modifications to the data planes and architectures or if the group is supposed to act as a source for requirements for such changes. I hope we can agree to see SPRING as source for requirements for modification where the data plane and architecture has been developed by another active working group. /Loa On 2013-09-20 11:28, Stewart Bryant wrote: > This note is a summary of where we are with chartering the > work that we are discussing on the STATUS list and > the next steps. > > Firstly, as you know we (the ADs) had concerns with the > name "STATUS" being confusing. Having considered quite > a lot of possibilities, and not wanting the discussion > to bog down on a name, Adrian and I have decided > that the name Source Packet Routing in NetworkinG is > as good as any. Thus SPRING is name that we are using > in the charter process and is that I am putting in the > data-tracker for formal processing. > > Propose to start with the charter text that John Scudder > posted on 17/Sept with the following changes: > > s//SPRING/ > > I removed "ordered" from ordered list, as I think there > was a consensus to do so in the following emails in > the thread. > > I have not changed the state text, as I could not see > a consensus on what if any change I should make. > > The charter is uploaded at > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > What we now need the list members to do is to propose > any necessary changes to the text, and I will reflect > the consensus of the group in revised charter text. > The differences in the version of the charter text will > be visible through the datatracker charter diff tool. > > For continuity, discussion will continue on the STATUS > list until we have a chartered WG, at which point the > Secretariat will switch us over. > > For reference the text I uploaded is as follows: > > Name: Source Packet Routing in Networking (SPRING) > > The SPRING working group will define procedures that will allow > a node to steer a packet between any source and destination through > a SPRING region on any path without requiring state to be > maintained by transited nodes, but rather at the source device. A > SPRING region is a network comprised of nodes (which may be of > any type, including routers and appliances) that share the following > trust model: any node in the SPRING region is trusted to steer > a packet through any of the other nodes within the region. The > SPRING region may comprise one or more ASes, or even less than a > single AS. Although a region may comprise more than one AS, initial > work will focus on the intra-domain, that is, single AS, scenario. > > The procedures should support both centralised and distributed path > computation. The procedures should also cover support for OAM > functions. > > Where use cases are documented, care should be taken to define the > data plane requirements for the environment within which they are > to be implemented. The procedures should avoid modifications to > the MPLS data plane, in order to remain compatible with existing > extensive deployments of MPLS. It is anticipated that the procedures > may require modifications to the IPv6 data plane. While the initial > focus of the SPRING WG is on the intra-domain deployment scenarios > (see below), the modifications to the IPv6 data plane must support > both intra and inter-domain deployment scenarios. > > The SPRING working group is chartered for the following list of > items: > > o Identification and evaluation of use cases for which there > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying > technology. The new procedures must cover security considerations > (including the relationship between networks forming the SPRING > region) and allow for solutions which substantially improve upon > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The SPRING working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the SPRING working group. > > The working group will develop the following documents: > > o One or more documents describing SPRING use cases, > o Specification of new procedures to support SPRING use cases, > o Changes to MPLS architecture, if needed > o Changes to IPv6 architecture, if needed > o Document interworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), > o Document impact (if any) of any proposed IPv6 data plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extensions > supporting SPRING. > > Please review and propose changes you think are necessary to the > list. > > - Stewart > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stbryant@cisco.com Fri Sep 20 05:39:23 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51EF21F8B35 for ; Fri, 20 Sep 2013 05:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xKQAWFh2L2x for ; Fri, 20 Sep 2013 05:39:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7DF21F8B04 for ; Fri, 20 Sep 2013 05:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38433; q=dns/txt; s=iport; t=1379680757; x=1380890357; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=21NGk9LyhxPI6Lyp/FusrhKh7xM5WrclEnsgZw5QdSo=; b=TVaJlgGGhxDAOJaEI6wwBxYsqts4jX4Y3R4N5wBqUc5ClBB3gU+zV6MU Nm3xpQa2vTZBFmm3jINmrlhi/AarX8eIwMJMwbfA/VkBiP/A9AGvYy5mo yCBbUiPyItNMQyY+RrhGZqVgyQwkhxhtw8B+FsO2epCJNNV8q6/KKSULD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEZBPFKQ/khL/2dsb2JhbABagkNEOIlYt2lKgRwWdIIlAQEBBAEBASo6BwQGARALEgYJFgEBDQkDAgECARUiDgYNAQUCAQEXh2oMumGPZQeEHgOUH4NdkXaDJQ X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208,217";a="86806471" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Sep 2013 12:39:12 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8KCdAjd005683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 12:39:10 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8KCd9WE028447; Fri, 20 Sep 2013 13:39:10 +0100 (BST) Message-ID: <523C41ED.3020102@cisco.com> Date: Fri, 20 Sep 2013 13:39:09 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Loa Andersson References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> In-Reply-To: <523C31A6.50209@pi.nu> Content-Type: multipart/alternative; boundary="------------030101040306090307030501" Cc: status@ietf.org Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 20 Sep 2013 12:39:24 -0000 This is a multi-part message in MIME format. --------------030101040306090307030501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Loa, That is a good point, here is some text that might be considered for inclusion: "Where possible, existing protocols must be used to implement the SPRING function. Any modification or extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs." A good place to put this would be before: "The SPRING working group is chartered for the following list of items: " Would this address your concern? Stewart On 20/09/2013 12:29, Loa Andersson wrote: > Stewart, > > SPRING is a nice name :). > > The only thing that I don't find clear in this charter is > whether to specify modifications to the data planes and architectures > or if the group is supposed to act as a source for requirements for > such changes. > > I hope we can agree to see SPRING as source for requirements for > modification where the data plane and architecture has been developed > by another active working group. > > /Loa > > > On 2013-09-20 11:28, Stewart Bryant wrote: >> This note is a summary of where we are with chartering the >> work that we are discussing on the STATUS list and >> the next steps. >> >> Firstly, as you know we (the ADs) had concerns with the >> name "STATUS" being confusing. Having considered quite >> a lot of possibilities, and not wanting the discussion >> to bog down on a name, Adrian and I have decided >> that the name Source Packet Routing in NetworkinG is >> as good as any. Thus SPRING is name that we are using >> in the charter process and is that I am putting in the >> data-tracker for formal processing. >> >> Propose to start with the charter text that John Scudder >> posted on 17/Sept with the following changes: >> >> s//SPRING/ >> >> I removed "ordered" from ordered list, as I think there >> was a consensus to do so in the following emails in >> the thread. >> >> I have not changed the state text, as I could not see >> a consensus on what if any change I should make. >> >> The charter is uploaded at >> >> https://datatracker.ietf.org/doc/charter-ietf-spring/ >> >> What we now need the list members to do is to propose >> any necessary changes to the text, and I will reflect >> the consensus of the group in revised charter text. >> The differences in the version of the charter text will >> be visible through the datatracker charter diff tool. >> >> For continuity, discussion will continue on the STATUS >> list until we have a chartered WG, at which point the >> Secretariat will switch us over. >> >> For reference the text I uploaded is as follows: >> >> Name: Source Packet Routing in Networking (SPRING) >> >> The SPRING working group will define procedures that will allow >> a node to steer a packet between any source and destination through >> a SPRING region on any path without requiring state to be >> maintained by transited nodes, but rather at the source device. A >> SPRING region is a network comprised of nodes (which may be of >> any type, including routers and appliances) that share the following >> trust model: any node in the SPRING region is trusted to steer >> a packet through any of the other nodes within the region. The >> SPRING region may comprise one or more ASes, or even less than a >> single AS. Although a region may comprise more than one AS, initial >> work will focus on the intra-domain, that is, single AS, scenario. >> >> The procedures should support both centralised and distributed path >> computation. The procedures should also cover support for OAM >> functions. >> >> Where use cases are documented, care should be taken to define the >> data plane requirements for the environment within which they are >> to be implemented. The procedures should avoid modifications to >> the MPLS data plane, in order to remain compatible with existing >> extensive deployments of MPLS. It is anticipated that the procedures >> may require modifications to the IPv6 data plane. While the initial >> focus of the SPRING WG is on the intra-domain deployment scenarios >> (see below), the modifications to the IPv6 data plane must support >> both intra and inter-domain deployment scenarios. >> >> The SPRING working group is chartered for the following list of >> items: >> >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the SPRING >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The SPRING working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this >> will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the SPRING working group. >> >> The working group will develop the following documents: >> >> o One or more documents describing SPRING use cases, >> o Specification of new procedures to support SPRING use cases, >> o Changes to MPLS architecture, if needed >> o Changes to IPv6 architecture, if needed >> o Document interworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), >> o Document impact (if any) of any proposed IPv6 data plane modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, >> o Inter-operability reports pertaining to the implementation of >> extensions >> supporting SPRING. >> >> Please review and propose changes you think are necessary to the >> list. >> >> - Stewart >> >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------030101040306090307030501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Loa,

That is a good point, here is some text that might be considered for inclusion:

"Where possible, existing protocols must be used to implement the SPRING function. Any modification or extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs."

A good place to put this would be before: "The SPRING working group is chartered for the following list of items: "

Would this address your concern?

Stewart


On 20/09/2013 12:29, Loa Andersson wrote:
Stewart,

SPRING is a nice name :).

The only thing that I don't find clear in this charter is
whether to specify modifications to the data planes and architectures
or if the group is supposed to act as a source for requirements for
such changes.

I hope we can agree to see SPRING as source for requirements for
modification where the data plane and architecture has been developed
by another active working group.

/Loa


On 2013-09-20 11:28, Stewart Bryant wrote:
This note is a summary of where we are with chartering the
work that we are discussing on the STATUS list and
the next steps.

Firstly, as you know we (the ADs) had concerns with the
name "STATUS" being confusing. Having considered quite
a lot of possibilities, and not wanting the discussion
to bog down on a name,  Adrian and I have decided
that the name Source Packet Routing in NetworkinG is
as good as any. Thus SPRING is name that we are using
in the charter process and is that I am putting in the
data-tracker for formal processing.

Propose to start with the charter text that John Scudder
posted on 17/Sept with the following changes:

s/<TBD>/SPRING/

I removed "ordered" from ordered list, as I think there
was a consensus to do so in the following emails in
the thread.

I have not changed the state text, as I could not see
a consensus on what if any change I should make.

The charter is uploaded at

https://datatracker.ietf.org/doc/charter-ietf-spring/

What we now need the list members to do is to propose
any necessary changes to the text, and I will reflect
the consensus of the group in revised charter text.
The differences in the version of the charter text will
be visible through the datatracker charter diff tool.

For continuity, discussion will continue on the STATUS
list until we have a chartered WG, at which point the
Secretariat will switch us over.

For reference the text I uploaded is as follows:

Name: Source Packet Routing in Networking (SPRING)

The SPRING working group will define procedures that will allow
a node to steer a packet between any source and destination through
a SPRING region on any path without requiring state to be
maintained by transited nodes, but rather at the source device.  A
SPRING region is a network comprised of nodes (which may be of
any type, including routers and appliances) that share the following
trust model: any node in the SPRING region is trusted to steer
a packet through any of the other nodes within the region. The
SPRING region may comprise one or more ASes, or even less than a
single AS. Although a region may comprise more than one AS, initial
work will focus on the intra-domain, that is, single AS, scenario.

The procedures should support both centralised and distributed path
computation. The procedures should also cover support for OAM
functions.

Where use cases are documented, care should be taken to define the
data plane requirements for the environment within which they are
to be implemented. The procedures should avoid modifications to
the MPLS data plane, in order to remain compatible with existing
extensive deployments of MPLS. It is anticipated that the procedures
may require modifications to the IPv6 data plane.  While the initial
focus of the SPRING WG is on the intra-domain deployment scenarios
(see below), the modifications to the IPv6 data plane must support
both intra and inter-domain deployment scenarios.

The SPRING working group is chartered for the following list of
items:

o Identification and evaluation of use cases for which there
   is consensus within the WG.
o Definition of new procedures, driven by the use cases and underlying
   technology. The new procedures must cover security considerations
   (including the relationship between networks forming the SPRING
   region) and allow for solutions which substantially improve upon
   current technologies by defining requirements, extensions, or new
   functionality in existing routing, management or other protocols.
o Determine whether the above mentioned procedures require
   modification/changes to the existing MPLS architecture, and
   if so, then document such modifications/changes.
o Determine whether the above mentioned procedures require
   modification/changes to the existing IPv6 architecture, and
   if so, then document such modifications/changes.
o The SPRING working group will then develop solutions, focusing
   initially on intra-domain deployment scenarios. Where such
   solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will
   be done in conjunction with the responsible IETF working group. Work
   on new protocols may be carried out by the SPRING working group.

The working group will develop the following documents:

o One or more documents describing SPRING use cases,
o Specification of new procedures to support SPRING use cases,
o Changes to MPLS architecture, if needed
o Changes to IPv6 architecture, if needed
o Document interworking and co-existence between the new procedures
   and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),
o Document impact (if any) of any proposed IPv6 data plane modifications
   on existing deployment of IPv6,
o A set of one or more protocol extensions requirements documents,
o Inter-operability reports pertaining to the implementation of extensions
   supporting SPRING.

Please review and propose changes you think are necessary to the
list.

- Stewart



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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------030101040306090307030501-- From pierre.francois@imdea.org Fri Sep 20 05:53:35 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE2021F9946 for ; Fri, 20 Sep 2013 05:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy4B0w6iA+AB for ; Fri, 20 Sep 2013 05:53:30 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id A70A221F9935 for ; Fri, 20 Sep 2013 05:53:29 -0700 (PDT) Received: from localhost (estafeta22.imdea.org [172.17.99.146]) by estafeta22.imdea.org (Postfix) with ESMTP id 46FA725E9F7; Fri, 20 Sep 2013 14:53:28 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.146]) by localhost (estafeta22.imdea.org [172.17.99.146]) (amavisd-new, port 10024) with ESMTP id YhjrGVuPRKA0; Fri, 20 Sep 2013 14:53:28 +0200 (CEST) Received: from [10.113.117.77] (121.Red-176-83-93.dynamicIP.rima-tde.net [176.83.93.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta22.imdea.org (Postfix) with ESMTP id BD2F425E9F6; Fri, 20 Sep 2013 14:53:27 +0200 (CEST) References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <523C41ED.3020102@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> X-Mailer: iPhone Mail (10B350) From: Pierre Francois Date: Fri, 20 Sep 2013 14:53:26 +0200 To: "stbryant@cisco.com" Cc: "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 12:53:35 -0000 Stewart, It is already in John's text. At the end he writes that the work impacting p= rotocols will be carried out in their respective working groups. Cheers, Pierre. Sent from my iPhone On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote: > Hi Loa, >=20 > That is a good point, here is some text that might be considered for inclu= sion: >=20 > "Where possible, existing protocols must be used to implement the SPRING f= unction. Any modification or extension of existing architectures or pr= otocols must be carried out in the working groups responsible for the archit= ectures or protocols being modified in co-ordination with this working group= , but may be done in this working group after agreement with all the relevan= t WG chairs and responsible ADs." >=20 > A good place to put this would be before: "The SPRING working group is cha= rtered for the following list of items: " >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From stbryant@cisco.com Fri Sep 20 06:17:58 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01CC21F9A4A for ; Fri, 20 Sep 2013 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j7Mpunqb7+f for ; Fri, 20 Sep 2013 06:17:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4C21F9A40 for ; Fri, 20 Sep 2013 06:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1701; q=dns/txt; s=iport; t=1379683067; x=1380892667; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6zpquTuTQVNbCvAFJJ4hKiSuElEsemaTfNtYO3dr/pE=; b=bnSObf/xXk11zUEtYpiYnNWgWQ/3WCMctN4TSlzeh0TwQViUdnPE/U2Z SBLwFvGFcLRKdQChr/VN7tAJSk5huBnuDZ/yqLJVcwklVQjwOREVYNcF2 SjCLgl6wkfWkKnv7YNyzcFIj1v7jkp1YY+6dTKHPy9FwxCix1zVoJZjiu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOlJPFKQ/khN/2dsb2JhbABagwc4wUFKgRoWdIIlAQEBBAEBATUvBwoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBF4dqDLptj2UHhB4Dl3yRdoMl X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="159826242" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Sep 2013 13:17:46 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8KDHiCG014664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 13:17:44 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8KDHgca000772; Fri, 20 Sep 2013 14:17:43 +0100 (BST) Message-ID: <523C4AF6.3050802@cisco.com> Date: Fri, 20 Sep 2013 14:17:42 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pierre Francois References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> In-Reply-To: <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 20 Sep 2013 13:17:59 -0000 Pierre The last version of the charter that I pulled from the list says: Where such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will be done in conjunction with the responsible IETF working group. Work on new protocols may be carried out by the SPRING working group. That is not as prescriptive as either your snippet, or mine, and Loa raised a concern. What do others think? Stewart On 20/09/2013 13:53, Pierre Francois wrote: > Stewart, > > It is already in John's text. At the end he writes that the work impacting protocols will be carried out in their respective working groups. > > Cheers, > > Pierre. > > Sent from my iPhone > > On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote: > >> Hi Loa, >> >> That is a good point, here is some text that might be considered for inclusion: >> >> "Where possible, existing protocols must be used to implement the SPRING function. Any modification or extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs." >> >> A good place to put this would be before: "The SPRING working group is chartered for the following list of items: " >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From sprevidi@cisco.com Fri Sep 20 06:38:20 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E4A21F9A3D for ; Fri, 20 Sep 2013 06:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6FARs1QoVCq for ; Fri, 20 Sep 2013 06:38:15 -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 AE4C121F89EB for ; Fri, 20 Sep 2013 06:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2647; q=dns/txt; s=iport; t=1379684294; x=1380893894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fzCHYvWJF9Sq2CtVYfgBm8xVr1+FQ4bHpnb+QFrsbwc=; b=Yy0sWF1Dki1732xC7nH7KJ/YF8zWK8dj5hiDv/t/0v8pSMpwlm3d40+B 4gsJXPu1xI5K+f9pUK1UGxhB+fRYGBZrDL/eu/2sLT01pZT9lWl3WK04V lufz4K+yXzLvo0mt8OJRnNB7981YfPk9/ndrdz+pDazBHsbwyzOSlTo7C o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAGFPPFKtJV2d/2dsb2JhbABagwc4RgzAb0qBGhZ0giUBAQEDAQEBATctBwsFCwIBCBIGChQQJwsXDgIEDgUIE4dkBgy6dY8yAjECBYMegQADqXKDJIIq X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="262472633" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 20 Sep 2013 13:38:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8KDcEDN002884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 13:38:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 08:38:14 -0500 From: "Stefano Previdi (sprevidi)" To: "Stewart Bryant (stbryant)" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePSFVsDXVUUdkWPopncgaog/5nO0XAAgAATZ4CAAAP+AIAABscAgAAFuAA= Date: Fri, 20 Sep 2013 13:38:13 +0000 Message-ID: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> <523C4AF6.3050802@cisco.com> In-Reply-To: <523C4AF6.3050802@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <73E4B8FA22F7D94280B4B6FCE82E1A96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pierre Francois , "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 13:38:20 -0000 This is the text from my originally proposed charter: . The WG will work on the definition of the architecture and protocol=20 extensions. No new protocol specification is expected within this WG.=20 No MPLS data-plane changes are expected either. . Instead the standardization work should consist in extensions in well=20 established protocols (ISIS, OSPF, BGP, PCEP, ...). . It is expected that the SEGROUTE WG will help in the orchestration=20 of protocol extensions specification with the existing IETF Working=20 Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). s. On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote: > Pierre >=20 > The last version of the charter that I pulled from the list > says: >=20 > Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the SPRING working group. >=20 > That is not as prescriptive as either your snippet, or mine, and Loa rais= ed a concern. >=20 > What do others think? >=20 > Stewart >=20 > On 20/09/2013 13:53, Pierre Francois wrote: >> Stewart, >>=20 >> It is already in John's text. At the end he writes that the work impacti= ng protocols will be carried out in their respective working groups. >>=20 >> Cheers, >>=20 >> Pierre. >>=20 >> Sent from my iPhone >>=20 >> On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote: >>=20 >>> Hi Loa, >>>=20 >>> That is a good point, here is some text that might be considered for in= clusion: >>>=20 >>> "Where possible, existing protocols must be used to implement the SPRIN= G function. Any modification or extension of existing architectures o= r protocols must be carried out in the working groups responsible for the a= rchitectures or protocols being modified in co-ordination with this working= group, but may be done in this working group after agreement with all the = relevant WG chairs and responsible ADs." >>>=20 >>> A good place to put this would be before: "The SPRING working group is = chartered for the following list of items: " >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> . >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From jdrake@juniper.net Fri Sep 20 06:42:43 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071D421F98EE for ; Fri, 20 Sep 2013 06:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9wQYbRLJN7z for ; Fri, 20 Sep 2013 06:42:38 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 13A5B21F856A for ; Fri, 20 Sep 2013 06:42:37 -0700 (PDT) Received: from mail118-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.22; Fri, 20 Sep 2013 13:42:37 +0000 Received: from mail118-co1 (localhost [127.0.0.1]) by mail118-co1-R.bigfish.com (Postfix) with ESMTP id 3AE2B140135; Fri, 20 Sep 2013 13:42:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail118-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(24454002)(479174003)(377454003)(13464003)(51704005)(74366001)(74706001)(56816003)(74316001)(81342001)(59766001)(77096001)(54356001)(83072001)(81816001)(81542001)(56776001)(83322001)(19580405001)(51856001)(54316002)(77982001)(76482001)(63696002)(74876001)(76786001)(76796001)(66066001)(47446002)(69226001)(53806001)(74662001)(76576001)(74502001)(80976001)(65816001)(15975445006)(80022001)(15202345003)(46102001)(19580395003)(81686001)(50986001)(79102001)(4396001)(47976001)(31966008)(47736001)(49866001)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail118-co1 (localhost.localdomain [127.0.0.1]) by mail118-co1 (MessageSwitch) id 1379684555121830_15285; Fri, 20 Sep 2013 13:42:35 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.242]) by mail118-co1.bigfish.com (Postfix) with ESMTP id 17AA5640041; Fri, 20 Sep 2013 13:42:35 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 20 Sep 2013 13:42:30 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Fri, 20 Sep 2013 13:42:25 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 20 Sep 2013 13:42:23 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.132]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Fri, 20 Sep 2013 13:42:23 +0000 From: John E Drake To: "Stefano Previdi (sprevidi)" , "Stewart Bryant (stbryant)" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CAAAP+AIAABsgAgAAFu4CAAAER4A== Date: Fri, 20 Sep 2013 13:42:22 +0000 Message-ID: <4fdcfe02c67847eabf95c2e8417ff3ce@BY2PR05MB142.namprd05.prod.outlook.com> References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> <523C4AF6.3050802@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09752BC779 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Pierre Francois , "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 13:42:43 -0000 Hi, I prefer Stewart's text. Yours Irrespectively, John > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf > Of Stefano Previdi (sprevidi) > Sent: Friday, September 20, 2013 6:38 AM > To: Stewart Bryant (stbryant) > Cc: Pierre Francois; status@ietf.org; Loa Andersson > Subject: Re: [Status] Chartering next steps >=20 > This is the text from my originally proposed charter: >=20 > . The WG will work on the definition of the architecture and protocol > extensions. No new protocol specification is expected within this WG. > No MPLS data-plane changes are expected either. >=20 > . Instead the standardization work should consist in extensions in well > established protocols (ISIS, OSPF, BGP, PCEP, ...). >=20 > . It is expected that the SEGROUTE WG will help in the orchestration > of protocol extensions specification with the existing IETF Working > Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). >=20 > s. >=20 >=20 >=20 > On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote: >=20 > > Pierre > > > > The last version of the charter that I pulled from the list > > says: > > > > Where such > > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this > > will be done in conjunction with the responsible IETF working group. > > Work on new protocols may be carried out by the SPRING working group. > > > > That is not as prescriptive as either your snippet, or mine, and Loa ra= ised a > concern. > > > > What do others think? > > > > Stewart > > > > On 20/09/2013 13:53, Pierre Francois wrote: > >> Stewart, > >> > >> It is already in John's text. At the end he writes that the work impac= ting > protocols will be carried out in their respective working groups. > >> > >> Cheers, > >> > >> Pierre. > >> > >> Sent from my iPhone > >> > >> On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote= : > >> > >>> Hi Loa, > >>> > >>> That is a good point, here is some text that might be considered for > inclusion: > >>> > >>> "Where possible, existing protocols must be used to implement the > SPRING function. Any modification or extension of existing architec= tures > or protocols must be carried out in the working groups responsible for th= e > architectures or protocols being modified in co-ordination with this work= ing > group, but may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs." > >>> > >>> A good place to put this would be before: "The SPRING working group i= s > chartered for the following list of items: " > >>> > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >> . > >> > > > > > > -- > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 From stbryant@cisco.com Fri Sep 20 06:50:38 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7599D21F943C for ; Fri, 20 Sep 2013 06:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WPFcPlt5xbX for ; Fri, 20 Sep 2013 06:50:32 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8963421F979E for ; Fri, 20 Sep 2013 06:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3166; q=dns/txt; s=iport; t=1379685031; x=1380894631; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QX8n3rJ9Sba0Iajqvixk2/CVIsUpFUcR22Ts2eg4Ylg=; b=g0sIuYkPu285hcdcSJ4DLEO/l/7zhiJ3ct1YxD4KmNRgvwr+aLScFkxg 8KqyuhZ/2kyL4cN4/w31RrDojva5tewvyfERxbgBpyMeDHek1dyHukeQi 7PPBlHhUzWZnqKxFRP5G7XH91OzCojezA/RLt2p1hzq09h6aIGz8GdLPJ k=; X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="86808076" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Sep 2013 13:50:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8KDoRMr032478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 13:50:27 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8KDoQS6003239; Fri, 20 Sep 2013 14:50:26 +0100 (BST) Message-ID: <523C52A2.3060202@cisco.com> Date: Fri, 20 Sep 2013 14:50:26 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Stefano Previdi (sprevidi)" References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> <523C4AF6.3050802@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pierre Francois , "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 20 Sep 2013 13:50:38 -0000 Stef Specification by partial list always gives problems. WGs come and go, new protocols are noticed that need changing. Much better for a charter to state a principle that is likely to be true regardless of the IETF structure. So, if you compare your text to mine, what operational issue do you see arising that yours catches? - Stewart On 20/09/2013 14:38, Stefano Previdi (sprevidi) wrote: > This is the text from my originally proposed charter: > > . The WG will work on the definition of the architecture and protocol > extensions. No new protocol specification is expected within this WG. > No MPLS data-plane changes are expected either. > > . Instead the standardization work should consist in extensions in well > established protocols (ISIS, OSPF, BGP, PCEP, ...). > > . It is expected that the SEGROUTE WG will help in the orchestration > of protocol extensions specification with the existing IETF Working > Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). > > s. > > > > On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote: > >> Pierre >> >> The last version of the charter that I pulled from the list >> says: >> >> Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the SPRING working group. >> >> That is not as prescriptive as either your snippet, or mine, and Loa raised a concern. >> >> What do others think? >> >> Stewart >> >> On 20/09/2013 13:53, Pierre Francois wrote: >>> Stewart, >>> >>> It is already in John's text. At the end he writes that the work impacting protocols will be carried out in their respective working groups. >>> >>> Cheers, >>> >>> Pierre. >>> >>> Sent from my iPhone >>> >>> On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote: >>> >>>> Hi Loa, >>>> >>>> That is a good point, here is some text that might be considered for inclusion: >>>> >>>> "Where possible, existing protocols must be used to implement the SPRING function. Any modification or extension of existing architectures or protocols must be carried out in the working groups responsible for the architectures or protocols being modified in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs." >>>> >>>> A good place to put this would be before: "The SPRING working group is chartered for the following list of items: " >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>> . >>> >> >> -- >> For corporate legal information go to: >> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From aretana@cisco.com Fri Sep 20 06:56:54 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5C221F9A44 for ; Fri, 20 Sep 2013 06:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUPJryWK7ML9 for ; Fri, 20 Sep 2013 06:56:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 045D621F9A40 for ; Fri, 20 Sep 2013 06:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=959; q=dns/txt; s=iport; t=1379685409; x=1380895009; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9yFqSs5dz6UcuNsGlM9LHNyWwS96oj+J5fW4cHh4A58=; b=VT1yaCfwPREMk3WMcYbP3V71RFehzPiHnLj3ktrk14Al+qk3UKX0F7WT DA1IIQ7JBLDG5gTHw3tmHvKaTw9lSbgdMDPa1LDstcuop61ZgvuMwBpjM PdN8BlA9hKlnm0BAtNn5JGDoFHJSVRsgc8bstFmf7s51LaS3MUgSdq3Ir 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIhTPFKtJV2Y/2dsb2JhbABagweBCsE5gRoWdIIlAQEBBDotEhIBCBgKFEIlAgQBDQUIh327AY80MQeDHoEAA6lygySCKg X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="262363673" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 20 Sep 2013 13:56:48 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8KDumtv025584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 13:56:48 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.123]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 08:56:47 -0500 From: "Alvaro Retana (aretana)" To: "Stewart Bryant (stbryant)" , Pierre Francois Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePSaYof9NxI1UC9bQkLAqxxYJnO0XAAgAATZ4CAAAP+AIAABscA///H3AA= Date: Fri, 20 Sep 2013 13:56:47 +0000 Message-ID: In-Reply-To: <523C4AF6.3050802@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <240F418FF7A6E64F9C99C19BD8E9EE4B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 13:56:54 -0000 On 9/20/13 9:17 AM, "Stewart Bryant (stbryant)" wrote: >What do others think? FWIW, I like the prescriptive nature of the text you proposed. Thanks! Alvaro. >>On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote: >> >>> Hi Loa, >>> >>> That is a good point, here is some text that might be considered for >>>inclusion: >>> >>> "Where possible, existing protocols must be used to implement the >>>SPRING function. Any modification or extension of existing >>>architectures or protocols must be carried out in the working groups >>>responsible for the architectures or protocols being modified in >>>co-ordination with this working group, but may be done in this working >>>group after agreement with all the relevant WG chairs and responsible >>>ADs." >>> >>> A good place to put this would be before: "The SPRING working group is >>>chartered for the following list of items: " From sprevidi@cisco.com Fri Sep 20 06:58:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2D21F9A3D for ; Fri, 20 Sep 2013 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.704 X-Spam-Level: X-Spam-Status: No, score=-109.704 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYLLQxYL3fKR for ; Fri, 20 Sep 2013 06:58:46 -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 B9BAE21F9A43 for ; Fri, 20 Sep 2013 06:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3619; q=dns/txt; s=iport; t=1379685526; x=1380895126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uWU3196Mb7H6YcS8qwkUxptU/+uSvP8KkaXZEJ3LxLs=; b=TDLwCRO+o+ASx0wGEg9H6pQAmtzjS3p6WaoYTyInsxqw/t8nkHt6W2LT FNWl4mQN5J/wODdnmZ19dlFyq91N7jwpgJbMXnlkPNyAfoKlyksm9RynY 21Gu7DKfdVq2F+syeP3z0M9iNhW3YX1ndN5fZeX2uY4V574bJR7GhQQ71 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIhTPFKtJV2d/2dsb2JhbABagwc4RgzAb0qBGhZ0giUBAQEDAQEBAWQHCwULAgEIEgYKJCcLFw4CBA4FCBOHZAYMunWPMgIxAgWDHoEAA4kAix+VU4Mkgio X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="262381097" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 20 Sep 2013 13:58:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8KDwjkw027987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 13:58:45 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.02.0318.004; Fri, 20 Sep 2013 08:58:44 -0500 From: "Stefano Previdi (sprevidi)" To: "Stewart Bryant (stbryant)" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePSFVsDXVUUdkWPopncgaog/5nO0XAAgAATZ4CAAAP+AIAABscAgAAFuACAAANuAIAAAk8A Date: Fri, 20 Sep 2013 13:58:44 +0000 Message-ID: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <45B193F9-D1A9-443F-9327-F42E4FA7357F@imdea.org> <523C4AF6.3050802@cisco.com> <523C52A2.3060202@cisco.com> In-Reply-To: <523C52A2.3060202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pierre Francois , "status@ietf.org" , Loa Andersson Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 13:58:51 -0000 On Sep 20, 2013, at 3:50 PM, Stewart Bryant wrote: > Stef >=20 > Specification by partial list always gives problems. WGs > come and go, new protocols are noticed that need > changing. Much better for a charter to state a principle > that is likely to be true regardless of the IETF structure. yes, the name of the WG was just as example (and not exhaustive)=20 but in order not to hurt anyone sensibility, I'd agree with your=20 text. s. > So, if you compare your text to mine, what operational > issue do you see arising that yours catches? >=20 > - Stewart >=20 > On 20/09/2013 14:38, Stefano Previdi (sprevidi) wrote: >> This is the text from my originally proposed charter: >>=20 >> . The WG will work on the definition of the architecture and protocol >> extensions. No new protocol specification is expected within this WG. >> No MPLS data-plane changes are expected either. >>=20 >> . Instead the standardization work should consist in extensions in well >> established protocols (ISIS, OSPF, BGP, PCEP, ...). >>=20 >> . It is expected that the SEGROUTE WG will help in the orchestration >> of protocol extensions specification with the existing IETF Working >> Groups (ISIS, OSPF, IDR, PCE, 6MAN, MPLS, ...). >>=20 >> s. >>=20 >>=20 >>=20 >> On Sep 20, 2013, at 3:17 PM, Stewart Bryant wrote: >>=20 >>> Pierre >>>=20 >>> The last version of the charter that I pulled from the list >>> says: >>>=20 >>> Where such >>> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >>> be done in conjunction with the responsible IETF working group. Work >>> on new protocols may be carried out by the SPRING working group. >>>=20 >>> That is not as prescriptive as either your snippet, or mine, and Loa ra= ised a concern. >>>=20 >>> What do others think? >>>=20 >>> Stewart >>>=20 >>> On 20/09/2013 13:53, Pierre Francois wrote: >>>> Stewart, >>>>=20 >>>> It is already in John's text. At the end he writes that the work impac= ting protocols will be carried out in their respective working groups. >>>>=20 >>>> Cheers, >>>>=20 >>>> Pierre. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Sep 20, 2013, at 2:39 PM, Stewart Bryant wrote= : >>>>=20 >>>>> Hi Loa, >>>>>=20 >>>>> That is a good point, here is some text that might be considered for = inclusion: >>>>>=20 >>>>> "Where possible, existing protocols must be used to implement the SPR= ING function. Any modification or extension of existing architectures= or protocols must be carried out in the working groups responsible for the= architectures or protocols being modified in co-ordination with this worki= ng group, but may be done in this working group after agreement with all th= e relevant WG chairs and responsible ADs." >>>>>=20 >>>>> A good place to put this would be before: "The SPRING working group i= s chartered for the following list of items: " >>>>>=20 >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>> . >>>>=20 >>>=20 >>> --=20 >>> For corporate legal information go to: >>>=20 >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> . >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From lberger@labn.net Fri Sep 20 07:01:21 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7422E21F9A43 for ; Fri, 20 Sep 2013 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.41 X-Spam-Level: X-Spam-Status: No, score=-101.41 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4S2Sjvk3eg8 for ; Fri, 20 Sep 2013 07:01:17 -0700 (PDT) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 8444221F97C7 for ; Fri, 20 Sep 2013 07:01:16 -0700 (PDT) Received: (qmail 18242 invoked by uid 0); 20 Sep 2013 14:00:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.mail.unifiedlayer.com with SMTP; 20 Sep 2013 14:00:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=FMy+4TF6pme/gbdftI7jaP93U7NF7lQJjIOg0gv6pwY=; b=Q74Yd4PzwCZJqBd8vLvEPLW1VWbNiCwH2vhKb0lKE7YYfXlmHgSQR9pVeoGBOPkPoA4OPqmfOcA9KbPzl0LoraCHd+eb0du/vyY+aexMRKxgzAPWEvwNmO8UbtgALPQC; Received: from box313.bluehost.com ([69.89.31.113]:39520 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VN1GO-00007Y-Qb; Fri, 20 Sep 2013 08:00:52 -0600 Message-ID: <523C5514.8060700@labn.net> Date: Fri, 20 Sep 2013 10:00:52 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stbryant@cisco.com References: <523C1538.1030701@cisco.com> In-Reply-To: <523C1538.1030701@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "status@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 14:01:21 -0000 Stewart, A comment and a question: - You say: any path without requiring state to be maintained by transited nodes I think it would be worth clarifying that no "per-path state" is required to be maintained. The extensions eluded to below will certainly control/install state per node, just not per path. - You say: any node in the SPRING region is trusted to steer a packet through any of the other nodes within the region. To me this limits "steering", and perhaps steering identifiers, to the node level. Is steering at the interface/link level now excluded? The text should be clear that this is in scope. Thanks, Lou On 09/20/2013 05:28 AM, Stewart Bryant wrote: > This note is a summary of where we are with chartering the > work that we are discussing on the STATUS list and > the next steps. > > Firstly, as you know we (the ADs) had concerns with the > name "STATUS" being confusing. Having considered quite > a lot of possibilities, and not wanting the discussion > to bog down on a name, Adrian and I have decided > that the name Source Packet Routing in NetworkinG is > as good as any. Thus SPRING is name that we are using > in the charter process and is that I am putting in the > data-tracker for formal processing. > > Propose to start with the charter text that John Scudder > posted on 17/Sept with the following changes: > > s//SPRING/ > > I removed "ordered" from ordered list, as I think there > was a consensus to do so in the following emails in > the thread. > > I have not changed the state text, as I could not see > a consensus on what if any change I should make. > > The charter is uploaded at > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > What we now need the list members to do is to propose > any necessary changes to the text, and I will reflect > the consensus of the group in revised charter text. > The differences in the version of the charter text will > be visible through the datatracker charter diff tool. > > For continuity, discussion will continue on the STATUS > list until we have a chartered WG, at which point the > Secretariat will switch us over. > > For reference the text I uploaded is as follows: > > Name: Source Packet Routing in Networking (SPRING) > > The SPRING working group will define procedures that will allow > a node to steer a packet between any source and destination through > a SPRING region on any path without requiring state to be > maintained by transited nodes, but rather at the source device. A > SPRING region is a network comprised of nodes (which may be of > any type, including routers and appliances) that share the following > trust model: any node in the SPRING region is trusted to steer > a packet through any of the other nodes within the region. The > SPRING region may comprise one or more ASes, or even less than a > single AS. Although a region may comprise more than one AS, initial > work will focus on the intra-domain, that is, single AS, scenario. > > The procedures should support both centralised and distributed path > computation. The procedures should also cover support for OAM > functions. > > Where use cases are documented, care should be taken to define the > data plane requirements for the environment within which they are > to be implemented. The procedures should avoid modifications to > the MPLS data plane, in order to remain compatible with existing > extensive deployments of MPLS. It is anticipated that the procedures > may require modifications to the IPv6 data plane. While the initial > focus of the SPRING WG is on the intra-domain deployment scenarios > (see below), the modifications to the IPv6 data plane must support > both intra and inter-domain deployment scenarios. > > The SPRING working group is chartered for the following list of > items: > > o Identification and evaluation of use cases for which there > is consensus within the WG. > o Definition of new procedures, driven by the use cases and underlying > technology. The new procedures must cover security considerations > (including the relationship between networks forming the SPRING > region) and allow for solutions which substantially improve upon > current technologies by defining requirements, extensions, or new > functionality in existing routing, management or other protocols. > o Determine whether the above mentioned procedures require > modification/changes to the existing MPLS architecture, and > if so, then document such modifications/changes. > o Determine whether the above mentioned procedures require > modification/changes to the existing IPv6 architecture, and > if so, then document such modifications/changes. > o The SPRING working group will then develop solutions, focusing > initially on intra-domain deployment scenarios. Where such > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > be done in conjunction with the responsible IETF working group. Work > on new protocols may be carried out by the SPRING working group. > > The working group will develop the following documents: > > o One or more documents describing SPRING use cases, > o Specification of new procedures to support SPRING use cases, > o Changes to MPLS architecture, if needed > o Changes to IPv6 architecture, if needed > o Document interworking and co-existence between the new procedures > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), > o Document impact (if any) of any proposed IPv6 data plane modifications > on existing deployment of IPv6, > o A set of one or more protocol extensions requirements documents, > o Inter-operability reports pertaining to the implementation of extensions > supporting SPRING. > > Please review and propose changes you think are necessary to the > list. > > - Stewart > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > From rjs@rob.sh Fri Sep 20 08:47:56 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB621F99DD for ; Fri, 20 Sep 2013 08:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIahJBZRw+L1 for ; Fri, 20 Sep 2013 08:47:55 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5CE21F9B4B for ; Fri, 20 Sep 2013 08:47:53 -0700 (PDT) Received: from [31.55.10.53] (helo=[10.210.4.201]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VN2uu-0003fS-Vy; Fri, 20 Sep 2013 16:46:49 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Rob Shakir In-Reply-To: <523C5514.8060700@labn.net> Date: Fri, 20 Sep 2013 16:47:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <523C1538.1030701@cisco.com> <523C5514.8060700@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1503) Cc: "rtg-ads@tools.ietf.org" , "status@ietf.org" , stbryant@cisco.com Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 15:47:56 -0000 Hi Lou, On 20 Sep 2013, at 15:00, Lou Berger wrote: > Stewart, > A comment and a question: > - You say: > any path without requiring state to be maintained by transited nodes >=20 > I think it would be worth clarifying that no "per-path state" is > required to be maintained. The extensions eluded to below will = certainly > control/install state per node, just not per path. I think this is correct :-) >=20 > - You say: > any node in the SPRING region is trusted to steer a packet > through any of the other nodes within the region. >=20 > To me this limits "steering", and perhaps steering identifiers, to the > node level. Is steering at the interface/link level now excluded? The > text should be clear that this is in scope. The previous wording that we had here is quoted below: "The architecture defined by this working group will allow steering of = packets between any source and destination node within the = domain, which may be formed of one or more networks, on any path = (shortest, non-shortest, explicit, or based on other resources or = characteristics specified by segment identifiers)." Thanks for picking up that this has changed somewhat -- I would suggest = that we amend the wording to "Any node in the SPRING region is trusted = to steer a packet along any path within the region" -- which allows for = the possibility of the path being of identifiers which refer to = nodes/links/subtopologies etc. Kind regards, r. >=20 > Thanks, > Lou >=20 > On 09/20/2013 05:28 AM, Stewart Bryant wrote: >> This note is a summary of where we are with chartering the >> work that we are discussing on the STATUS list and >> the next steps. >>=20 >> Firstly, as you know we (the ADs) had concerns with the >> name "STATUS" being confusing. Having considered quite >> a lot of possibilities, and not wanting the discussion >> to bog down on a name, Adrian and I have decided >> that the name Source Packet Routing in NetworkinG is >> as good as any. Thus SPRING is name that we are using >> in the charter process and is that I am putting in the >> data-tracker for formal processing. >>=20 >> Propose to start with the charter text that John Scudder >> posted on 17/Sept with the following changes: >>=20 >> s//SPRING/ >>=20 >> I removed "ordered" from ordered list, as I think there >> was a consensus to do so in the following emails in >> the thread. >>=20 >> I have not changed the state text, as I could not see >> a consensus on what if any change I should make. >>=20 >> The charter is uploaded at >>=20 >> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>=20 >> What we now need the list members to do is to propose >> any necessary changes to the text, and I will reflect >> the consensus of the group in revised charter text. >> The differences in the version of the charter text will >> be visible through the datatracker charter diff tool. >>=20 >> For continuity, discussion will continue on the STATUS >> list until we have a chartered WG, at which point the >> Secretariat will switch us over. >>=20 >> For reference the text I uploaded is as follows: >>=20 >> Name: Source Packet Routing in Networking (SPRING) >>=20 >> The SPRING working group will define procedures that will allow >> a node to steer a packet between any source and destination through >> a SPRING region on any path without requiring state to be >> maintained by transited nodes, but rather at the source device. A >> SPRING region is a network comprised of nodes (which may be of >> any type, including routers and appliances) that share the following >> trust model: any node in the SPRING region is trusted to steer >> a packet through any of the other nodes within the region. The >> SPRING region may comprise one or more ASes, or even less than a >> single AS. Although a region may comprise more than one AS, initial >> work will focus on the intra-domain, that is, single AS, scenario. >>=20 >> The procedures should support both centralised and distributed path >> computation. The procedures should also cover support for OAM >> functions. >>=20 >> Where use cases are documented, care should be taken to define the >> data plane requirements for the environment within which they are >> to be implemented. The procedures should avoid modifications to >> the MPLS data plane, in order to remain compatible with existing >> extensive deployments of MPLS. It is anticipated that the procedures >> may require modifications to the IPv6 data plane. While the initial >> focus of the SPRING WG is on the intra-domain deployment scenarios >> (see below), the modifications to the IPv6 data plane must support >> both intra and inter-domain deployment scenarios. >>=20 >> The SPRING working group is chartered for the following list of >> items: >>=20 >> o Identification and evaluation of use cases for which there >> is consensus within the WG. >> o Definition of new procedures, driven by the use cases and = underlying >> technology. The new procedures must cover security considerations >> (including the relationship between networks forming the SPRING >> region) and allow for solutions which substantially improve upon >> current technologies by defining requirements, extensions, or new >> functionality in existing routing, management or other protocols. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> o The SPRING working group will then develop solutions, focusing >> initially on intra-domain deployment scenarios. Where such >> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this = will >> be done in conjunction with the responsible IETF working group. Work >> on new protocols may be carried out by the SPRING working group. >>=20 >> The working group will develop the following documents: >>=20 >> o One or more documents describing SPRING use cases, >> o Specification of new procedures to support SPRING use cases, >> o Changes to MPLS architecture, if needed >> o Changes to IPv6 architecture, if needed >> o Document interworking and co-existence between the new procedures >> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), >> o Document impact (if any) of any proposed IPv6 data plane = modifications >> on existing deployment of IPv6, >> o A set of one or more protocol extensions requirements documents, >> o Inter-operability reports pertaining to the implementation of = extensions >> supporting SPRING. >>=20 >> Please review and propose changes you think are necessary to the >> list. >>=20 >> - Stewart >>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From sriganeshkini@gmail.com Fri Sep 20 12:02:04 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4E921F9DF3 for ; Fri, 20 Sep 2013 12:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD71UXe6K3No for ; Fri, 20 Sep 2013 12:02:03 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8035121F9DE9 for ; Fri, 20 Sep 2013 12:01:57 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so1063079pab.41 for ; Fri, 20 Sep 2013 12:01:57 -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:from:date:message-id :subject:to:cc:content-type; bh=JiOxdUdaR6S9IVjnF6z8tcuYE4RHT6Ykg5woHv/W6Ls=; b=xyhkdKYf7jJ5v5qSHEiUi/evx6XwW4fH+pwZWtvCDXmSqXmLdLdrHDRnNV90/Q7A4z 76Nc+wRu9ffbCt24nXHfefb4GVxbjYSrWcFR2LlmR+Ui0j/KyWO8mDThRi30YY19n3F8 GxireqmIlyxnMhe1TbnnI7Pmj4xsNtU0DE89gwJj4a3n9LMWTsjHpBeQo87Sa4ZM3+BB dgVSxvHlRhh7b+6wFQKa1ygytJJ1L5HtmUNMvlRdDU6zTNkmRBskNvkN3IBs2Hk6Hn3C nVWGPATiX0nhzYlGf/f3OeoXxqM054z7BODEN0Wuj3AXW6QiPc4ayzhb7ncyXDl9W0fB LaHA== X-Received: by 10.66.227.39 with SMTP id rx7mr10720644pac.44.1379703717190; Fri, 20 Sep 2013 12:01:57 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.225 with HTTP; Fri, 20 Sep 2013 12:01:27 -0700 (PDT) In-Reply-To: <523C5514.8060700@labn.net> References: <523C1538.1030701@cisco.com> <523C5514.8060700@labn.net> From: Sriganesh Kini Date: Fri, 20 Sep 2013 12:01:27 -0700 X-Google-Sender-Auth: ApXtO7WWjCuRSNzInMe8JEsWKEw Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=047d7b111f3ff5614d04e6d54d38 Cc: "rtg-ads@tools.ietf.org" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 19:02:04 -0000 --047d7b111f3ff5614d04e6d54d38 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger wrote: > Stewart, > A comment and a question: > - You say: > any path without requiring state to be maintained by transited nodes > > I think it would be worth clarifying that no "per-path state" is > required to be maintained. The extensions eluded to below will certainly > control/install state per node, just not per path. > That is an important distinction. Maybe worthwhile to be explicit that this is applicable both to control and data plane state. > > - You say: > any node in the SPRING region is trusted to steer a packet > through any of the other nodes within the region. > > To me this limits "steering", and perhaps steering identifiers, to the > node level. Is steering at the interface/link level now excluded? The > text should be clear that this is in scope. > This could be worded as "steer a packet along an explicit path". That should cover both. > > Thanks, > Lou > > On 09/20/2013 05:28 AM, Stewart Bryant wrote: > > This note is a summary of where we are with chartering the > > work that we are discussing on the STATUS list and > > the next steps. > > > > Firstly, as you know we (the ADs) had concerns with the > > name "STATUS" being confusing. Having considered quite > > a lot of possibilities, and not wanting the discussion > > to bog down on a name, Adrian and I have decided > > that the name Source Packet Routing in NetworkinG is > > as good as any. Thus SPRING is name that we are using > > in the charter process and is that I am putting in the > > data-tracker for formal processing. > > > > Propose to start with the charter text that John Scudder > > posted on 17/Sept with the following changes: > > > > s//SPRING/ > > > > I removed "ordered" from ordered list, as I think there > > was a consensus to do so in the following emails in > > the thread. > > > > I have not changed the state text, as I could not see > > a consensus on what if any change I should make. > > > > The charter is uploaded at > > > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > What we now need the list members to do is to propose > > any necessary changes to the text, and I will reflect > > the consensus of the group in revised charter text. > > The differences in the version of the charter text will > > be visible through the datatracker charter diff tool. > > > > For continuity, discussion will continue on the STATUS > > list until we have a chartered WG, at which point the > > Secretariat will switch us over. > > > > For reference the text I uploaded is as follows: > > > > Name: Source Packet Routing in Networking (SPRING) > > > > The SPRING working group will define procedures that will allow > > a node to steer a packet between any source and destination through > > a SPRING region on any path without requiring state to be > > maintained by transited nodes, but rather at the source device. A > > SPRING region is a network comprised of nodes (which may be of > > any type, including routers and appliances) that share the following > > trust model: any node in the SPRING region is trusted to steer > > a packet through any of the other nodes within the region. The > > SPRING region may comprise one or more ASes, or even less than a > > single AS. Although a region may comprise more than one AS, initial > > work will focus on the intra-domain, that is, single AS, scenario. > > > > The procedures should support both centralised and distributed path > > computation. The procedures should also cover support for OAM > > functions. > > > > Where use cases are documented, care should be taken to define the > > data plane requirements for the environment within which they are > > to be implemented. The procedures should avoid modifications to > > the MPLS data plane, in order to remain compatible with existing > > extensive deployments of MPLS. It is anticipated that the procedures > > may require modifications to the IPv6 data plane. While the initial > > focus of the SPRING WG is on the intra-domain deployment scenarios > > (see below), the modifications to the IPv6 data plane must support > > both intra and inter-domain deployment scenarios. > > > > The SPRING working group is chartered for the following list of > > items: > > > > o Identification and evaluation of use cases for which there > > is consensus within the WG. > > o Definition of new procedures, driven by the use cases and underlying > > technology. The new procedures must cover security considerations > > (including the relationship between networks forming the SPRING > > region) and allow for solutions which substantially improve upon > > current technologies by defining requirements, extensions, or new > > functionality in existing routing, management or other protocols. > > o Determine whether the above mentioned procedures require > > modification/changes to the existing MPLS architecture, and > > if so, then document such modifications/changes. > > o Determine whether the above mentioned procedures require > > modification/changes to the existing IPv6 architecture, and > > if so, then document such modifications/changes. > > o The SPRING working group will then develop solutions, focusing > > initially on intra-domain deployment scenarios. Where such > > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will > > be done in conjunction with the responsible IETF working group. Work > > on new protocols may be carried out by the SPRING working group. > > > > The working group will develop the following documents: > > > > o One or more documents describing SPRING use cases, > > o Specification of new procedures to support SPRING use cases, > > o Changes to MPLS architecture, if needed > > o Changes to IPv6 architecture, if needed > > o Document interworking and co-existence between the new procedures > > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), > > o Document impact (if any) of any proposed IPv6 data plane modifications > > on existing deployment of IPv6, > > o A set of one or more protocol extensions requirements documents, > > o Inter-operability reports pertaining to the implementation of > extensions > > supporting SPRING. > > > > Please review and propose changes you think are necessary to the > > list. > > > > - Stewart > > > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --047d7b111f3ff5614d04e6d54d38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <<= a href=3D"mailto:lberger@labn.net" target=3D"_blank">lberger@labn.net&g= t; wrote:
Stewart,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A comment and a question:
- You say:
=C2=A0 any path without requiring state to be maintained = by transited nodes

I think it would be worth clarifying that no "per-path state&quo= t; is
required to be maintained. The extensions eluded to below will certainly control/install state per node, just not per path.
That is an important distinction. Maybe worthwhile to be explic= it that this is applicable both to control and data plane state.
=C2=A0

- You say:
=C2=A0 any node in the SPRING region is trusted to steer = a packet
=C2=A0 through any of the other nodes within the region.

To me this limits "steering", and perhaps steering identifi= ers, to the
node level. Is steering at the interface/link level now excluded? =C2=A0The=
text should be clear that this is in scope.

=
This could be worded as "steer a packet along an explicit path&qu= ot;. That should cover both.
=C2=A0

Thanks,
Lou

On 09/20/2013 05:28 AM, Stewart Bryant wrote:
> This note is a summary of where we are with chartering the
> work that we are discussing on the STATUS list and
> the next steps.
>
> Firstly, as you know we (the ADs) had concerns with the
> name "STATUS" being confusing. Having considered quite
> a lot of possibilities, and not wanting the discussion
> to bog down on a name, =C2=A0Adrian and I have decided
> that the name Source Packet Routing in NetworkinG is
> as good as any. Thus SPRING is name that we are using
> in the charter process and is that I am putting in the
> data-tracker for formal processing.
>
> Propose to start with the charter text that John Scudder
> posted on 17/Sept with the following changes:
>
> s/<TBD>/SPRING/
>
> I removed "ordered" from ordered list, as I think there
> was a consensus to do so in the following emails in
> the thread.
>
> I have not changed the state text, as I could not see
> a consensus on what if any change I should make.
>
> The charter is uploaded at
>
> https://datatracker.ietf.org/doc/charter-ietf-spring/
>
> What we now need the list members to do is to propose
> any necessary changes to the text, and I will reflect
> the consensus of the group in revised charter text.
> The differences in the version of the charter text will
> be visible through the datatracker charter diff tool.
>
> For continuity, discussion will continue on the STATUS
> list until we have a chartered WG, at which point the
> Secretariat will switch us over.
>
> For reference the text I uploaded is as follows:
>
> Name: Source Packet Routing in Networking (SPRING)
>
> The SPRING working group will define procedures that will allow
> a node to steer a packet between any source and destination through > a SPRING region on any path without requiring state to be
> maintained by transited nodes, but rather at the source device. =C2=A0= A
> SPRING region is a network comprised of nodes (which may be of
> any type, including routers and appliances) that share the following > trust model: any node in the SPRING region is trusted to steer
> a packet through any of the other nodes within the region. The
> SPRING region may comprise one or more ASes, or even less than a
> single AS. Although a region may comprise more than one AS, initial > work will focus on the intra-domain, that is, single AS, scenario.
>
> The procedures should support both centralised and distributed path > computation. The procedures should also cover support for OAM
> functions.
>
> Where use cases are documented, care should be taken to define the
> data plane requirements for the environment within which they are
> to be implemented. The procedures should avoid modifications to
> the MPLS data plane, in order to remain compatible with existing
> extensive deployments of MPLS. It is anticipated that the procedures > may require modifications to the IPv6 data plane. =C2=A0While the init= ial
> focus of the SPRING WG is on the intra-domain deployment scenarios
> (see below), the modifications to the IPv6 data plane must support
> both intra and inter-domain deployment scenarios.
>
> The SPRING working group is chartered for the following list of
> items:
>
> o Identification and evaluation of use cases for which there
> =C2=A0 is consensus within the WG.
> o Definition of new procedures, driven by the use cases and underlying=
> =C2=A0 technology. The new procedures must cover security consideratio= ns
> =C2=A0 (including the relationship between networks forming the SPRING=
> =C2=A0 region) and allow for solutions which substantially improve upo= n
> =C2=A0 current technologies by defining requirements, extensions, or n= ew
> =C2=A0 functionality in existing routing, management or other protocol= s.
> o Determine whether the above mentioned procedures require
> =C2=A0 modification/changes to the existing MPLS architecture, and
> =C2=A0 if so, then document such modifications/changes.
> o Determine whether the above mentioned procedures require
> =C2=A0 modification/changes to the existing IPv6 architecture, and
> =C2=A0 if so, then document such modifications/changes.
> o The SPRING working group will then develop solutions, focusing
> =C2=A0 initially on intra-domain deployment scenarios. Where such
> =C2=A0 solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) th= is will
> =C2=A0 be done in conjunction with the responsible IETF working group.= Work
> =C2=A0 on new protocols may be carried out by the SPRING working group= .
>
> The working group will develop the following documents:
>
> o One or more documents describing SPRING use cases,
> o Specification of new procedures to support SPRING use cases,
> o Changes to MPLS architecture, if needed
> o Changes to IPv6 architecture, if needed
> o Document interworking and co-existence between the new procedures > =C2=A0 and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP),<= br> > o Document impact (if any) of any proposed IPv6 data plane modificatio= ns
> =C2=A0 on existing deployment of IPv6,
> o A set of one or more protocol extensions requirements documents,
> o Inter-operability reports pertaining to the implementation of extens= ions
> =C2=A0 supporting SPRING.
>
> Please review and propose changes you think are necessary to the
> list.
>
> - Stewart
>
>
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status
>

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

--047d7b111f3ff5614d04e6d54d38-- From jgs@juniper.net Fri Sep 20 12:19:11 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF521F942D for ; Fri, 20 Sep 2013 12:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.825 X-Spam-Level: X-Spam-Status: No, score=-4.825 tagged_above=-999 required=5 tests=[AWL=1.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMCP8OO8-Evb for ; Fri, 20 Sep 2013 12:19:06 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1953A21F8C93 for ; Fri, 20 Sep 2013 12:19:05 -0700 (PDT) Received: from mail137-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 20 Sep 2013 19:19:04 +0000 Received: from mail137-tx2 (localhost [127.0.0.1]) by mail137-tx2-R.bigfish.com (Postfix) with ESMTP id 7676A3201E8; Fri, 20 Sep 2013 19:19:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz62a3I98dI9371I936eIc85fh542Iec9I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1e64h1fe8h1ff5h2052h20f0h20b3m1155h) Received-SPF: pass (mail137-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(37854004)(189002)(13464003)(199002)(24454002)(252514010)(164054003)(377424004)(51704005)(50226001)(15975445006)(36756003)(47976001)(81542001)(33656001)(50986001)(81342001)(82746002)(49866001)(47736001)(69226001)(81816001)(81686001)(84326001)(56816003)(69556001)(77096001)(77156001)(53416003)(51856001)(74706001)(76796001)(512954002)(74662001)(31966008)(63696002)(76786001)(46102001)(53806001)(74366001)(42186004)(77982001)(79102001)(65816001)(74876001)(71186001)(54316002)(83072001)(4396001)(47446002)(80976001)(80022001)(66066001)(19580405001)(19580395003)(62966002)(56776001)(83322001)(76482001)(59766001)(74502001)(57306001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail137-tx2 (localhost.localdomain [127.0.0.1]) by mail137-tx2 (MessageSwitch) id 1379704737603724_844; Fri, 20 Sep 2013 19:18:57 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.227]) by mail137-tx2.bigfish.com (Postfix) with ESMTP id 7E5EA8004D; Fri, 20 Sep 2013 19:18:57 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 20 Sep 2013 19:18:57 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Fri, 20 Sep 2013 19:18:53 +0000 Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 20 Sep 2013 19:18:51 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "John G. Scudder" In-Reply-To: <523B1CD5.2030208@pi.nu> Date: Fri, 20 Sep 2013 15:18:42 -0400 Message-ID: <4406CC21-3B5A-4054-ADB2-D9ACEC3C330A@juniper.net> References: <52332E33.1040603@cisco.com> <0F365669-2A41-4C15-BD97-A08C26276BEE@juniper.net> <7347100B5761DC41A166AC17F22DF1121B6EB70E@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B6EBD5D@eusaamb103.ericsson.se> <523B1CD5.2030208@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1510) X-Originating-IP: [66.129.232.2] X-ClientProxiedBy: DM2PR03CA010.namprd03.prod.outlook.com (10.141.52.158) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 09752BC779 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: adrian@olddog.co.uk, Ruediger.Geib@telekom.de, status@ietf.org, stbryant@cisco.com Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 19:19:11 -0000 --Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" [Thanks, Ruediger, for reminding me of this] Loa, I think your proposed change is good. Thanks, --John On Sep 19, 2013, at 11:48 AM, Loa Andersson wrote: > Ruediger, >=20 > it depends on what you mean with "document such = modifications/changes". > Almost everything we do in the IETF is documents - we are documenting. >=20 > In this case I assume you mean "document the requirements for such > changes" and then let the the working group that owns the particular > data plane specify the actual changes. >=20 > Otherwise this look pretty good. >=20 > /Loa >=20 > On 2013-09-19 08:33, Ruediger.Geib@telekom.de wrote: >> John, >>=20 >> there's another detail which should be clarified: >>=20 >>> The working group is chartered for the following = (ordered) list of items: >> .... >>=20 >> I'd expect work related to MPLS based SR to start relatively soon, = while work on IPv6 based SR may require a more thorough analysis. The = "(ordered)" therefore should be removed or the order should be adapted = to express that: >>=20 >> o Determine whether the above mentioned procedures require >> modification/changes to the existing MPLS architecture, and >> if so, then document such modifications/changes. >> o Determine whether the above mentioned procedures require >> modification/changes to the existing IPv6 architecture, and >> if so, then document such modifications/changes. >> In parallel, the working group will develop >> solutions for a MPLS architecture, focusing initially on >> intra-domain deployment scenarios. Where such solutions >> utilize existing protocols (IS-IS, OSPF, BGP, PCE) this will >> be done in conjunction with the responsible IETF working group. = Work >> on new protocols may be carried out by the working = group. >> o The working group will then develop solutions for an = IPv6 >> architecture, focusing initially on intra-domain deployment = scenarios. >> Where such solutions utilize existing protocols (IS-IS, OSPF, = BGP, PCE) >> this will be done in conjunction with the responsible IETF = working group. >> Work on new protocols may be carried out by the = working group. >>=20 >> Regards, >>=20 >> Ruediger >>=20 >>=20 >>> -----Original Message----- >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>> Behalf Of John G.Scudder >>> Sent: Tuesday, September 17, 2013 7:22 AM >>> To: stbryant@cisco.com >>> Cc: Adrian Farrel; status@ietf.org >>> Subject: Re: [Status] TBD Charter - ready of RTG AD review yes/no >>>=20 >>> All, >>>=20 >>> Here's another attempt. It tries to address the 'architecture' issue = I raised earlier, as well as incorporate Mark Townsley, Bruno Decraene = and Rob Shakir's comments. With luck the change from ' domain' = to ' region' relieves the ambiguity that was present in = earlier versions. >>>=20 >>> --John >>>=20 >>> --------------------------------------------------------- >>> Name: >>>=20 >>> The working group will define procedures that will allow = a node to steer a packet between any source and destination through a = region on any path without requiring state to be maintained = by transited nodes, but rather at the source device. A = region is a network comprised of nodes (which may be of any type, = including routers and appliances) that share the following trust model: = any node in the region is trusted to steer a packet through = any of the other nodes within the region. The region may = comprise one or more ASes, or even less than a single AS. Although a = region may comprise more than one AS, initial work will focus on the = intra-domain, that is, single AS, scenario. >>>=20 >>> The procedures should support both centralised and distributed path = computation. The procedures should also cover support for OAM functions. >>>=20 >>> Where use cases are documented, care should be taken to define the = data plane requirements for the environment within which they are to be = implemented. The procedures should avoid modifications to the MPLS data = plane, in order to remain compatible with existing extensive deployments = of MPLS. It is anticipated that the procedures may require modifications = to the IPv6 data plane. While the initial focus of the WG is = on the intra-domain deployment scenarios (see below), the modifications = to the IPv6 data plane must support both intra and inter-domain = deployment scenarios. >>>=20 >>> The working group is chartered for the following = (ordered) list of items: >>>=20 >>> o Identification and evaluation of use cases for which there >>> is consensus within the WG. >>> o Definition of new procedures, driven by the use cases and = underlying >>> technology. The new procedures must cover security considerations >>> (including the relationship between networks forming the = >>> region) and allow for solutions which substantially improve upon >>> current technologies by defining requirements, extensions, or new >>> functionality in existing routing, management or other protocols. >>> o Determine whether the above mentioned procedures require >>> modification/changes to the existing MPLS architecture, and >>> if so, then document such modifications/changes. >>> o Determine whether the above mentioned procedures require >>> modification/changes to the existing IPv6 architecture, and >>> if so, then document such modifications/changes. >>> o The working group will then develop solutions, focusing >>> initially on intra-domain deployment scenarios. Where such >>> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this = will >>> be done in conjunction with the responsible IETF working group. = Work >>> on new protocols may be carried out by the working = group. >>>=20 >>> The working group will develop the following documents: >>>=20 >>> o One or more documents describing use cases, o = Specification of new procedures to support use cases, o = Changes to MPLS architecture, if needed o Changes to IPv6 architecture, = if needed o Document interworking and co-existence between the new = procedures >>> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), o = Document impact (if any) of any proposed IPv6 data plane modifications >>> on existing deployment of IPv6, >>> o A set of one or more protocol extensions requirements documents, o = Inter-operability reports pertaining to the implementation of extensions >>> supporting . >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status >=20 >=20 --Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" loa@pi.nu> wrote:

Ruediger,

it depends on what you mean with = "document such modifications/changes".
Almost everything we do in the = IETF is documents - we are documenting.

In this case I assume you = mean "document the requirements for such
changes" and then let the = the working group that owns the particular
data plane specify the = actual changes.

Otherwise this look pretty = good.

/Loa

On 2013-09-19 08:33, Ruediger.Geib@telekom.de = wrote:
John,

there's another detail = which should be clarified:

The = <Name-TBD> working group is chartered for the following (ordered) = list of items:
....

I'd expect work related to = MPLS based SR to start relatively soon, while work on IPv6 based SR may = require a more thorough analysis. The "(ordered)" therefore should be = removed or the  order should be adapted to express that:

=   o Determine whether the above mentioned procedures = require
    modification/changes to the existing = MPLS architecture, and
    if so, then document = such modifications/changes.
  o Determine whether the = above mentioned procedures require
=     modification/changes to the existing IPv6 = architecture, and
    if so, then document such = modifications/changes.
    In parallel, the = <Name-TBD> working group will develop
=     solutions for a MPLS architecture, focusing = initially on
    intra-domain deployment = scenarios. Where such solutions
    utilize = existing protocols (IS-IS, OSPF, BGP, PCE) this will
=     be done in conjunction with the responsible IETF = working group. Work
    on new protocols may be = carried out by the <Name-TBD> working group.
  o The = <Name-TBD> working group will then develop solutions for an = IPv6
    architecture, focusing initially on = intra-domain deployment scenarios.
    Where = such solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE)
=     this will be done in conjunction with the = responsible IETF working group.
    Work on new = protocols may be carried out by the <Name-TBD> working = group.

Regards,

Ruediger


-----Original Message-----
From: status-bounces@ietf.org = [mailto:status-bounces@ietf.org] = On
Behalf Of John G.Scudder
Sent: Tuesday, September 17, 2013 7:22 = AM
To: stbryant@cisco.com
Cc: Adrian = Farrel; status@ietf.org
Subject:= Re: [Status] TBD Charter - ready of RTG AD review = yes/no

All,

Here's another attempt. It tries to address = the 'architecture' issue I raised earlier, as well as incorporate Mark = Townsley, Bruno Decraene and Rob Shakir's comments. With luck the change = from '<Name-TBD> domain' to '<Name-TBD> region' relieves the = ambiguity that was present in earlier = versions.

--John

-------------------------------------------= --------------
Name: <TBD>

The <Name-TBD> working = group will define procedures that will allow a node to steer a packet = between any source and destination through a <Name-TBD> region on = any path without requiring state to be maintained by transited nodes, = but rather at the source device.  A <Name-TBD> region is a = network comprised of nodes (which may be of any type, including routers = and appliances) that share the following trust model: any node in the = <Name-TBD> region is trusted to steer a packet through any of the = other nodes within the region. The <Name-TBD> region may comprise = one or more ASes, or even less than a single AS. Although a region may = comprise more than one AS, initial work will focus on the intra-domain, = that is, single AS, scenario.

The procedures should support both = centralised and distributed path computation. The procedures should also = cover support for OAM functions.

Where use cases are documented, = care should be taken to define the data plane requirements for the = environment within which they are to be implemented. The procedures = should avoid modifications to the MPLS data plane, in order to remain = compatible with existing extensive deployments of MPLS. It is = anticipated that the procedures may require modifications to the IPv6 = data plane.  While the initial focus of the <Name-TBD> WG is = on the intra-domain deployment scenarios (see below), the modifications = to the IPv6 data plane must support both intra and inter-domain = deployment scenarios.

The <Name-TBD> working group is = chartered for the following (ordered) list of items:

o = Identification and evaluation of use cases for which there
=   is consensus within the WG.
o Definition of new = procedures, driven by the use cases and underlying
=   technology. The new procedures must cover security = considerations
  (including the relationship between = networks forming the <Name-TBD>
  region) and allow = for solutions which substantially improve upon
  current = technologies by defining requirements, extensions, or new
=   functionality in existing routing, management or other = protocols.
o Determine whether the above mentioned procedures = require
  modification/changes to the existing MPLS = architecture, and
  if so, then document such = modifications/changes.
o Determine whether the above mentioned = procedures require
  modification/changes to the existing = IPv6 architecture, and
  if so, then document such = modifications/changes.
o The <Name-TBD> working group will then = develop solutions, focusing
  initially on intra-domain = deployment scenarios. Where such
  solutions utilize = existing protocols (IS-IS, OSPF, BGP, PCE) this will
  be = done in conjunction with the responsible IETF working group. Work
=   on new protocols may be carried out by the <Name-TBD> = working group.

The working group will develop the following = documents:

o One or more documents describing <Name-TBD> = use cases, o Specification of new procedures to support <Name-TBD> = use cases, o Changes to MPLS architecture, if needed o Changes to IPv6 = architecture, if needed o Document interworking and co-existence between = the new procedures
  and the existing MPLS signaling = protocols (LDP, RSVP-TE, BGP), o Document impact (if any) of any = proposed IPv6 data plane modifications
  on existing = deployment of IPv6,
o A set of one or more protocol extensions = requirements documents, o Inter-operability reports pertaining to the = implementation of extensions
  supporting = <Name-TBD>.
_______________________________________________
st= atus mailing list
status@ietf.org
https://www.ietf.or= g/mailman/listinfo/status
_____________________________________________= __
status mailing = list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status
_______________________________________________
status = mailing list
status@ietf.org
https://www.ietf.or= g/mailman/listinfo/status
_____________________________________________= __
status mailing = list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status

--


Loa Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior = MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu
Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64
_______________________________________________
status mailing = list
status@ietf.org
https://www.ietf.or= g/mailman/listinfo/status



<= /html>= --Apple-Mail=_83F36047-5D32-44B9-90F3-285AC42EDB18-- From lberger@labn.net Fri Sep 20 12:43:10 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CFE21F9DA3 for ; Fri, 20 Sep 2013 12:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOJ5B4xxi8dB for ; Fri, 20 Sep 2013 12:43:05 -0700 (PDT) Received: from oproxy9-pub.mail.unifiedlayer.com (oproxy9-pub.mail.unifiedlayer.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 9972121F9D3A for ; Fri, 20 Sep 2013 12:43:05 -0700 (PDT) Received: (qmail 4810 invoked by uid 0); 20 Sep 2013 19:42:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 20 Sep 2013 19:42:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+rBlCNvdO+C0wDvW5dKwh4V9ehrrWfBc1BqPu/69L7A=; b=Mcr6dhozJl2spdjXCdNq+zvnXZtqTHiOqfWr9s1CdjZOPlRFFo/HuQhyuKfxwV9IAchH+FPtmnEHfL/oZAKOF9APi50jqhElURJnJI7GTrkc72/ObRnudxbFplax80yR; Received: from box313.bluehost.com ([69.89.31.113]:44666 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VN6bB-0006t8-ME; Fri, 20 Sep 2013 13:42:41 -0600 Message-ID: <523CA523.9090605@labn.net> Date: Fri, 20 Sep 2013 15:42:27 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sriganesh Kini References: <523C1538.1030701@cisco.com> <523C5514.8060700@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "Stewart Bryant \(stbryant\)" , "status@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 19:43:10 -0000 Sriganesh, See below. On 9/20/2013 3:01 PM, Sriganesh Kini wrote: > > > > On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger > wrote: > > Stewart, > A comment and a question: > - You say: > any path without requiring state to be maintained by transited nodes > > I think it would be worth clarifying that no "per-path state" is > required to be maintained. The extensions eluded to below will certainly > control/install state per node, just not per path. > > > That is an important distinction. Maybe worthwhile to be explicit that > this is applicable both to control and data plane state. > > > > - You say: > any node in the SPRING region is trusted to steer a packet > through any of the other nodes within the region. > > To me this limits "steering", and perhaps steering identifiers, to the > node level. Is steering at the interface/link level now excluded? The > text should be clear that this is in scope. > > > This could be worded as "steer a packet along an explicit path". That > should cover both. I think this overloads path by having it refer to an end-to-end construct (e.g., shortest, non-shortest, explicit, ... ) and an interface/segment construct. How about "along an explicit route"? Lou > > > Thanks, > Lou > > On 09/20/2013 05:28 AM, Stewart Bryant wrote: > > This note is a summary of where we are with chartering the > > work that we are discussing on the STATUS list and > > the next steps. > > > > Firstly, as you know we (the ADs) had concerns with the > > name "STATUS" being confusing. Having considered quite > > a lot of possibilities, and not wanting the discussion > > to bog down on a name, Adrian and I have decided > > that the name Source Packet Routing in NetworkinG is > > as good as any. Thus SPRING is name that we are using > > in the charter process and is that I am putting in the > > data-tracker for formal processing. > > > > Propose to start with the charter text that John Scudder > > posted on 17/Sept with the following changes: > > > > s//SPRING/ > > > > I removed "ordered" from ordered list, as I think there > > was a consensus to do so in the following emails in > > the thread. > > > > I have not changed the state text, as I could not see > > a consensus on what if any change I should make. > > > > The charter is uploaded at > > > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > What we now need the list members to do is to propose > > any necessary changes to the text, and I will reflect > > the consensus of the group in revised charter text. > > The differences in the version of the charter text will > > be visible through the datatracker charter diff tool. > > > > For continuity, discussion will continue on the STATUS > > list until we have a chartered WG, at which point the > > Secretariat will switch us over. > > > > For reference the text I uploaded is as follows: > > > > Name: Source Packet Routing in Networking (SPRING) > > > > The SPRING working group will define procedures that will allow > > a node to steer a packet between any source and destination through > > a SPRING region on any path without requiring state to be > > maintained by transited nodes, but rather at the source device. A > > SPRING region is a network comprised of nodes (which may be of > > any type, including routers and appliances) that share the following > > trust model: any node in the SPRING region is trusted to steer > > a packet through any of the other nodes within the region. The > > SPRING region may comprise one or more ASes, or even less than a > > single AS. Although a region may comprise more than one AS, initial > > work will focus on the intra-domain, that is, single AS, scenario. > > > > The procedures should support both centralised and distributed path > > computation. The procedures should also cover support for OAM > > functions. > > > > Where use cases are documented, care should be taken to define the > > data plane requirements for the environment within which they are > > to be implemented. The procedures should avoid modifications to > > the MPLS data plane, in order to remain compatible with existing > > extensive deployments of MPLS. It is anticipated that the procedures > > may require modifications to the IPv6 data plane. While the initial > > focus of the SPRING WG is on the intra-domain deployment scenarios > > (see below), the modifications to the IPv6 data plane must support > > both intra and inter-domain deployment scenarios. > > > > The SPRING working group is chartered for the following list of > > items: > > > > o Identification and evaluation of use cases for which there > > is consensus within the WG. > > o Definition of new procedures, driven by the use cases and underlying > > technology. The new procedures must cover security considerations > > (including the relationship between networks forming the SPRING > > region) and allow for solutions which substantially improve upon > > current technologies by defining requirements, extensions, or new > > functionality in existing routing, management or other protocols. > > o Determine whether the above mentioned procedures require > > modification/changes to the existing MPLS architecture, and > > if so, then document such modifications/changes. > > o Determine whether the above mentioned procedures require > > modification/changes to the existing IPv6 architecture, and > > if so, then document such modifications/changes. > > o The SPRING working group will then develop solutions, focusing > > initially on intra-domain deployment scenarios. Where such > > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) > this will > > be done in conjunction with the responsible IETF working group. Work > > on new protocols may be carried out by the SPRING working group. > > > > The working group will develop the following documents: > > > > o One or more documents describing SPRING use cases, > > o Specification of new procedures to support SPRING use cases, > > o Changes to MPLS architecture, if needed > > o Changes to IPv6 architecture, if needed > > o Document interworking and co-existence between the new procedures > > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), > > o Document impact (if any) of any proposed IPv6 data plane > modifications > > on existing deployment of IPv6, > > o A set of one or more protocol extensions requirements documents, > > o Inter-operability reports pertaining to the implementation of > extensions > > supporting SPRING. > > > > Please review and propose changes you think are necessary to the > > list. > > > > - Stewart > > > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > From sriganeshkini@gmail.com Fri Sep 20 13:06:27 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC8021F9E5B for ; Fri, 20 Sep 2013 13:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5cUYONRumXf for ; Fri, 20 Sep 2013 13:06:26 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 740E921F99E9 for ; Fri, 20 Sep 2013 13:06:16 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so1116577pad.30 for ; Fri, 20 Sep 2013 13:06:16 -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:from:date:message-id :subject:to:cc:content-type; bh=VaABdludwek9EnGxna5f49cII7K1/2qzCrbMpC8I2bY=; b=WMZayFlQcqZZRnptP47v98PfYtYvVo+KkGsOjztj374LRUhK8LAm/5LG3JS8Jdn6sY hiGU1+eFOwAlWsp4FfZkMkQGtifRgUiK0eKlnc+/3o/7JmzCw8LgtOIrEVIxYoT1He3k 1QYFQTd5Xo3VE/JgqFDoZ7OGF8x5r5Z9jELNyNIhHgMGGuvaXfXrL6b1ULCECFSeSFxs MQ59o2YjndbpBU3ztbvywHMsxojyRzkS0Kf3JzB/WhXwzqVQczrey9lMNpw4yYWPzxQS Pn/pDfOp1hDzmksTi/Iua8KM8NbSTNX9UwZOpPNvsParKTZbZS+ai92EGoKcGH4MlRqW u2Fw== X-Received: by 10.66.196.110 with SMTP id il14mr10842912pac.130.1379707576077; Fri, 20 Sep 2013 13:06:16 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.225 with HTTP; Fri, 20 Sep 2013 13:05:46 -0700 (PDT) In-Reply-To: <523CA523.9090605@labn.net> References: <523C1538.1030701@cisco.com> <523C5514.8060700@labn.net> <523CA523.9090605@labn.net> From: Sriganesh Kini Date: Fri, 20 Sep 2013 13:05:46 -0700 X-Google-Sender-Auth: xHHZiuPn7kKUeXyeY_N4clqUWQs Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=047d7bf16572f753cd04e6d633fa Cc: "rtg-ads@tools.ietf.org" , "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 20:06:27 -0000 --047d7bf16572f753cd04e6d633fa Content-Type: text/plain; charset=UTF-8 I agree Lou. Your wording seems fine to me. On Fri, Sep 20, 2013 at 12:42 PM, Lou Berger wrote: > Sriganesh, > > See below. > > On 9/20/2013 3:01 PM, Sriganesh Kini wrote: > > > > > > > > On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger > > wrote: > > > > Stewart, > > A comment and a question: > > - You say: > > any path without requiring state to be maintained by transited > nodes > > > > I think it would be worth clarifying that no "per-path state" is > > required to be maintained. The extensions eluded to below will > certainly > > control/install state per node, just not per path. > > > > > > That is an important distinction. Maybe worthwhile to be explicit that > > this is applicable both to control and data plane state. > > > > > > > > - You say: > > any node in the SPRING region is trusted to steer a packet > > through any of the other nodes within the region. > > > > To me this limits "steering", and perhaps steering identifiers, to > the > > node level. Is steering at the interface/link level now excluded? > The > > text should be clear that this is in scope. > > > > > > This could be worded as "steer a packet along an explicit path". That > > should cover both. > > I think this overloads path by having it refer to an end-to-end > construct (e.g., shortest, non-shortest, explicit, ... ) and an > interface/segment construct. > > How about "along an explicit route"? > > Lou > > > > > > > Thanks, > > Lou > > > > On 09/20/2013 05:28 AM, Stewart Bryant wrote: > > > This note is a summary of where we are with chartering the > > > work that we are discussing on the STATUS list and > > > the next steps. > > > > > > Firstly, as you know we (the ADs) had concerns with the > > > name "STATUS" being confusing. Having considered quite > > > a lot of possibilities, and not wanting the discussion > > > to bog down on a name, Adrian and I have decided > > > that the name Source Packet Routing in NetworkinG is > > > as good as any. Thus SPRING is name that we are using > > > in the charter process and is that I am putting in the > > > data-tracker for formal processing. > > > > > > Propose to start with the charter text that John Scudder > > > posted on 17/Sept with the following changes: > > > > > > s//SPRING/ > > > > > > I removed "ordered" from ordered list, as I think there > > > was a consensus to do so in the following emails in > > > the thread. > > > > > > I have not changed the state text, as I could not see > > > a consensus on what if any change I should make. > > > > > > The charter is uploaded at > > > > > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > > > What we now need the list members to do is to propose > > > any necessary changes to the text, and I will reflect > > > the consensus of the group in revised charter text. > > > The differences in the version of the charter text will > > > be visible through the datatracker charter diff tool. > > > > > > For continuity, discussion will continue on the STATUS > > > list until we have a chartered WG, at which point the > > > Secretariat will switch us over. > > > > > > For reference the text I uploaded is as follows: > > > > > > Name: Source Packet Routing in Networking (SPRING) > > > > > > The SPRING working group will define procedures that will allow > > > a node to steer a packet between any source and destination through > > > a SPRING region on any path without requiring state to be > > > maintained by transited nodes, but rather at the source device. A > > > SPRING region is a network comprised of nodes (which may be of > > > any type, including routers and appliances) that share the > following > > > trust model: any node in the SPRING region is trusted to steer > > > a packet through any of the other nodes within the region. The > > > SPRING region may comprise one or more ASes, or even less than a > > > single AS. Although a region may comprise more than one AS, initial > > > work will focus on the intra-domain, that is, single AS, scenario. > > > > > > The procedures should support both centralised and distributed path > > > computation. The procedures should also cover support for OAM > > > functions. > > > > > > Where use cases are documented, care should be taken to define the > > > data plane requirements for the environment within which they are > > > to be implemented. The procedures should avoid modifications to > > > the MPLS data plane, in order to remain compatible with existing > > > extensive deployments of MPLS. It is anticipated that the > procedures > > > may require modifications to the IPv6 data plane. While the > initial > > > focus of the SPRING WG is on the intra-domain deployment scenarios > > > (see below), the modifications to the IPv6 data plane must support > > > both intra and inter-domain deployment scenarios. > > > > > > The SPRING working group is chartered for the following list of > > > items: > > > > > > o Identification and evaluation of use cases for which there > > > is consensus within the WG. > > > o Definition of new procedures, driven by the use cases and > underlying > > > technology. The new procedures must cover security considerations > > > (including the relationship between networks forming the SPRING > > > region) and allow for solutions which substantially improve upon > > > current technologies by defining requirements, extensions, or new > > > functionality in existing routing, management or other protocols. > > > o Determine whether the above mentioned procedures require > > > modification/changes to the existing MPLS architecture, and > > > if so, then document such modifications/changes. > > > o Determine whether the above mentioned procedures require > > > modification/changes to the existing IPv6 architecture, and > > > if so, then document such modifications/changes. > > > o The SPRING working group will then develop solutions, focusing > > > initially on intra-domain deployment scenarios. Where such > > > solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) > > this will > > > be done in conjunction with the responsible IETF working group. > Work > > > on new protocols may be carried out by the SPRING working group. > > > > > > The working group will develop the following documents: > > > > > > o One or more documents describing SPRING use cases, > > > o Specification of new procedures to support SPRING use cases, > > > o Changes to MPLS architecture, if needed > > > o Changes to IPv6 architecture, if needed > > > o Document interworking and co-existence between the new procedures > > > and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), > > > o Document impact (if any) of any proposed IPv6 data plane > > modifications > > > on existing deployment of IPv6, > > > o A set of one or more protocol extensions requirements documents, > > > o Inter-operability reports pertaining to the implementation of > > extensions > > > supporting SPRING. > > > > > > Please review and propose changes you think are necessary to the > > > list. > > > > > > - Stewart > > > > > > > > > > > > _______________________________________________ > > > status mailing list > > > status@ietf.org > > > https://www.ietf.org/mailman/listinfo/status > > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > > > > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --047d7bf16572f753cd04e6d633fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree Lou. Your wording seems fine to me.


On Fri, Sep 20, 2013 a= t 12:42 PM, Lou Berger <lberger@labn.net> wrote:
Sriganesh,

See below.

On 9/20/2013 3:01 PM, Sriganesh Kini wrote:
>
>
>
> On Fri, Sep 20, 2013 at 7:00 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
> =C2=A0 =C2=A0 Stewart,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A comment and a question: > =C2=A0 =C2=A0 - You say:
> =C2=A0 =C2=A0 =C2=A0 any path without requiring state to be maintained= by transited nodes
>
> =C2=A0 =C2=A0 I think it would be worth clarifying that no "per-p= ath state" is
> =C2=A0 =C2=A0 required to be maintained. The extensions eluded to belo= w will certainly
> =C2=A0 =C2=A0 control/install state per node, just not per path.
>
>
> That is an important distinction. Maybe worthwhile to be explicit that=
> this is applicable both to control and data plane state.
>
>
>
> =C2=A0 =C2=A0 - You say:
> =C2=A0 =C2=A0 =C2=A0 any node in the SPRING region is trusted to steer= a packet
> =C2=A0 =C2=A0 =C2=A0 through any of the other nodes within the region.=
>
> =C2=A0 =C2=A0 To me this limits "steering", and perhaps stee= ring identifiers, to the
> =C2=A0 =C2=A0 node level. Is steering at the interface/link level now = excluded? =C2=A0The
> =C2=A0 =C2=A0 text should be clear that this is in scope.
>
>
> This could be worded as "steer a packet along an explicit path&qu= ot;. That
> should cover both.

I think this overloads path by having it refer to an end-to-end
construct (e.g., shortest, non-shortest, explicit, ... ) and an
interface/segment construct.

How about "along an explicit route"?

Lou

>
>
> =C2=A0 =C2=A0 Thanks,
> =C2=A0 =C2=A0 Lou
>
> =C2=A0 =C2=A0 On 09/20/2013 05:28 AM, Stewart Bryant wrote:
> =C2=A0 =C2=A0 > This note is a summary of where we are with charter= ing the
> =C2=A0 =C2=A0 > work that we are discussing on the STATUS list and<= br> > =C2=A0 =C2=A0 > the next steps.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Firstly, as you know we (the ADs) had concerns with= the
> =C2=A0 =C2=A0 > name "STATUS" being confusing. Having con= sidered quite
> =C2=A0 =C2=A0 > a lot of possibilities, and not wanting the discuss= ion
> =C2=A0 =C2=A0 > to bog down on a name, =C2=A0Adrian and I have deci= ded
> =C2=A0 =C2=A0 > that the name Source Packet Routing in NetworkinG i= s
> =C2=A0 =C2=A0 > as good as any. Thus SPRING is name that we are usi= ng
> =C2=A0 =C2=A0 > in the charter process and is that I am putting in = the
> =C2=A0 =C2=A0 > data-tracker for formal processing.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Propose to start with the charter text that John Sc= udder
> =C2=A0 =C2=A0 > posted on 17/Sept with the following changes:
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > s/<TBD>/SPRING/
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > I removed "ordered" from ordered list, as= I think there
> =C2=A0 =C2=A0 > was a consensus to do so in the following emails in=
> =C2=A0 =C2=A0 > the thread.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > I have not changed the state text, as I could not s= ee
> =C2=A0 =C2=A0 > a consensus on what if any change I should make. > =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > The charter is uploaded at
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > https://datatracker.ietf.org/doc/charter-i= etf-spring/
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > What we now need the list members to do is to propo= se
> =C2=A0 =C2=A0 > any necessary changes to the text, and I will refle= ct
> =C2=A0 =C2=A0 > the consensus of the group in revised charter text.=
> =C2=A0 =C2=A0 > The differences in the version of the charter text = will
> =C2=A0 =C2=A0 > be visible through the datatracker charter diff too= l.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > For continuity, discussion will continue on the STA= TUS
> =C2=A0 =C2=A0 > list until we have a chartered WG, at which point t= he
> =C2=A0 =C2=A0 > Secretariat will switch us over.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > For reference the text I uploaded is as follows: > =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Name: Source Packet Routing in Networking (SPRING)<= br> > =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > The SPRING working group will define procedures tha= t will allow
> =C2=A0 =C2=A0 > a node to steer a packet between any source and des= tination through
> =C2=A0 =C2=A0 > a SPRING region on any path without requiring state= to be
> =C2=A0 =C2=A0 > maintained by transited nodes, but rather at the so= urce device. =C2=A0A
> =C2=A0 =C2=A0 > SPRING region is a network comprised of nodes (whic= h may be of
> =C2=A0 =C2=A0 > any type, including routers and appliances) that sh= are the following
> =C2=A0 =C2=A0 > trust model: any node in the SPRING region is trust= ed to steer
> =C2=A0 =C2=A0 > a packet through any of the other nodes within the = region. The
> =C2=A0 =C2=A0 > SPRING region may comprise one or more ASes, or eve= n less than a
> =C2=A0 =C2=A0 > single AS. Although a region may comprise more than= one AS, initial
> =C2=A0 =C2=A0 > work will focus on the intra-domain, that is, singl= e AS, scenario.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > The procedures should support both centralised and = distributed path
> =C2=A0 =C2=A0 > computation. The procedures should also cover suppo= rt for OAM
> =C2=A0 =C2=A0 > functions.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Where use cases are documented, care should be take= n to define the
> =C2=A0 =C2=A0 > data plane requirements for the environment within = which they are
> =C2=A0 =C2=A0 > to be implemented. The procedures should avoid modi= fications to
> =C2=A0 =C2=A0 > the MPLS data plane, in order to remain compatible = with existing
> =C2=A0 =C2=A0 > extensive deployments of MPLS. It is anticipated th= at the procedures
> =C2=A0 =C2=A0 > may require modifications to the IPv6 data plane. = =C2=A0While the initial
> =C2=A0 =C2=A0 > focus of the SPRING WG is on the intra-domain deplo= yment scenarios
> =C2=A0 =C2=A0 > (see below), the modifications to the IPv6 data pla= ne must support
> =C2=A0 =C2=A0 > both intra and inter-domain deployment scenarios. > =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > The SPRING working group is chartered for the follo= wing list of
> =C2=A0 =C2=A0 > items:
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > o Identification and evaluation of use cases for wh= ich there
> =C2=A0 =C2=A0 > =C2=A0 is consensus within the WG.
> =C2=A0 =C2=A0 > o Definition of new procedures, driven by the use c= ases and underlying
> =C2=A0 =C2=A0 > =C2=A0 technology. The new procedures must cover se= curity considerations
> =C2=A0 =C2=A0 > =C2=A0 (including the relationship between networks= forming the SPRING
> =C2=A0 =C2=A0 > =C2=A0 region) and allow for solutions which substa= ntially improve upon
> =C2=A0 =C2=A0 > =C2=A0 current technologies by defining requirement= s, extensions, or new
> =C2=A0 =C2=A0 > =C2=A0 functionality in existing routing, managemen= t or other protocols.
> =C2=A0 =C2=A0 > o Determine whether the above mentioned procedures = require
> =C2=A0 =C2=A0 > =C2=A0 modification/changes to the existing MPLS ar= chitecture, and
> =C2=A0 =C2=A0 > =C2=A0 if so, then document such modifications/chan= ges.
> =C2=A0 =C2=A0 > o Determine whether the above mentioned procedures = require
> =C2=A0 =C2=A0 > =C2=A0 modification/changes to the existing IPv6 ar= chitecture, and
> =C2=A0 =C2=A0 > =C2=A0 if so, then document such modifications/chan= ges.
> =C2=A0 =C2=A0 > o The SPRING working group will then develop soluti= ons, focusing
> =C2=A0 =C2=A0 > =C2=A0 initially on intra-domain deployment scenari= os. Where such
> =C2=A0 =C2=A0 > =C2=A0 solutions utilize existing protocols (IS-IS,= OSPF, BGP, PCE)
> =C2=A0 =C2=A0 this will
> =C2=A0 =C2=A0 > =C2=A0 be done in conjunction with the responsible = IETF working group. Work
> =C2=A0 =C2=A0 > =C2=A0 on new protocols may be carried out by the S= PRING working group.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > The working group will develop the following docume= nts:
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > o One or more documents describing SPRING use cases= ,
> =C2=A0 =C2=A0 > o Specification of new procedures to support SPRING= use cases,
> =C2=A0 =C2=A0 > o Changes to MPLS architecture, if needed
> =C2=A0 =C2=A0 > o Changes to IPv6 architecture, if needed
> =C2=A0 =C2=A0 > o Document interworking and co-existence between th= e new procedures
> =C2=A0 =C2=A0 > =C2=A0 and the existing MPLS signaling protocols (L= DP, RSVP-TE, BGP),
> =C2=A0 =C2=A0 > o Document impact (if any) of any proposed IPv6 dat= a plane
> =C2=A0 =C2=A0 modifications
> =C2=A0 =C2=A0 > =C2=A0 on existing deployment of IPv6,
> =C2=A0 =C2=A0 > o A set of one or more protocol extensions requirem= ents documents,
> =C2=A0 =C2=A0 > o Inter-operability reports pertaining to the imple= mentation of
> =C2=A0 =C2=A0 extensions
> =C2=A0 =C2=A0 > =C2=A0 supporting SPRING.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > Please review and propose changes you think are nec= essary to the
> =C2=A0 =C2=A0 > list.
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > - Stewart
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 > _______________________________________________
> =C2=A0 =C2=A0 > status mailing list
> =C2=A0 =C2=A0 > stat= us@ietf.org <mailto:status@ietf.o= rg>
> =C2=A0 =C2=A0 > https://www.ietf.org/mailman/list= info/status
> =C2=A0 =C2=A0 >
>
> =C2=A0 =C2=A0 _______________________________________________
> =C2=A0 =C2=A0 status mailing list
> =C2=A0 =C2=A0 status@ietf.org= <mailto:status@ietf.org><= br>
> =C2=A0 =C2=A0 https://www.ietf= .org/mailman/listinfo/status
>
>
>
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status
>
_______________________________________________
status mailing list
status@ietf.org
= https://www.ietf.org/mailman/listinfo/status

--047d7bf16572f753cd04e6d633fa-- From jdrake@juniper.net Fri Sep 20 13:18:38 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5621F9E43 for ; Fri, 20 Sep 2013 13:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXavI7f9HRkf for ; Fri, 20 Sep 2013 13:18:31 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 404B321F9E3B for ; Fri, 20 Sep 2013 13:18:30 -0700 (PDT) Received: from mail177-db9-R.bigfish.com (10.174.16.249) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Fri, 20 Sep 2013 20:18:29 +0000 Received: from mail177-db9 (localhost [127.0.0.1]) by mail177-db9-R.bigfish.com (Postfix) with ESMTP id B055B440247; Fri, 20 Sep 2013 20:18:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz98dI9371Ic89bhc857h4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h1033IL17326ah18c673h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail177-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(24454002)(189002)(199002)(164054003)(15202345003)(76796001)(76786001)(76576001)(56816003)(77096001)(33646001)(15975445006)(19580405001)(83322001)(19580395003)(74366001)(56776001)(4396001)(53806001)(65816001)(80022001)(46102001)(51856001)(76482001)(54316002)(54356001)(16236675002)(50986001)(47976001)(47736001)(49866001)(63696002)(81342001)(19609705001)(79102001)(77982001)(59766001)(69226001)(19300405004)(74502001)(47446002)(80976001)(31966008)(81816001)(74316001)(81686001)(74876001)(83072001)(74662001)(66066001)(81542001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail177-db9 (localhost.localdomain [127.0.0.1]) by mail177-db9 (MessageSwitch) id 1379708260592136_5923; Fri, 20 Sep 2013 20:17:40 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.243]) by mail177-db9.bigfish.com (Postfix) with ESMTP id 8A8EF40287; Fri, 20 Sep 2013 20:17:40 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 20 Sep 2013 20:17:40 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Fri, 20 Sep 2013 20:17:38 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 20 Sep 2013 20:17:36 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.132]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Fri, 20 Sep 2013 20:17:36 +0000 From: John E Drake To: Sriganesh Kini , Lou Berger Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOp9oAgABT+4CAABQL8A== Date: Fri, 20 Sep 2013 20:17:35 +0000 Message-ID: References: <523C1538.1030701@cisco.com> <523C5514.8060700@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09752BC779 Content-Type: multipart/alternative; boundary="_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Stewart Bryant \(stbryant\)" , "status@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 20 Sep 2013 20:18:38 -0000 --_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U25pcHBlZCwgY29tbWVudCBpbmxpbmUuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2hu DQoNCkZyb206IHN0YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmlnYW5lc2ggS2luaQ0KU2VudDogRnJpZGF5LCBTZXB0 ZW1iZXIgMjAsIDIwMTMgMTI6MDEgUE0NClRvOiBMb3UgQmVyZ2VyDQpDYzogcnRnLWFkc0B0b29s cy5pZXRmLm9yZzsgc3RhdHVzQGlldGYub3JnOyBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpDQpT dWJqZWN0OiBSZTogW1N0YXR1c10gQ2hhcnRlcmluZyBuZXh0IHN0ZXBzDQoNCg0KDQpPbiBGcmks IFNlcCAyMCwgMjAxMyBhdCA3OjAwIEFNLCBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PG1h aWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4gd3JvdGU6DQpTdGV3YXJ0LA0KICAgICAgICBBIGNvbW1l bnQgYW5kIGEgcXVlc3Rpb246DQotIFlvdSBzYXk6DQogIGFueSBwYXRoIHdpdGhvdXQgcmVxdWly aW5nIHN0YXRlIHRvIGJlIG1haW50YWluZWQgYnkgdHJhbnNpdGVkIG5vZGVzDQpJIHRoaW5rIGl0 IHdvdWxkIGJlIHdvcnRoIGNsYXJpZnlpbmcgdGhhdCBubyAicGVyLXBhdGggc3RhdGUiIGlzDQpy ZXF1aXJlZCB0byBiZSBtYWludGFpbmVkLiBUaGUgZXh0ZW5zaW9ucyBlbHVkZWQgdG8gYmVsb3cg d2lsbCBjZXJ0YWlubHkNCmNvbnRyb2wvaW5zdGFsbCBzdGF0ZSBwZXIgbm9kZSwganVzdCBub3Qg cGVyIHBhdGguDQoNClRoYXQgaXMgYW4gaW1wb3J0YW50IGRpc3RpbmN0aW9uLiBNYXliZSB3b3J0 aHdoaWxlIHRvIGJlIGV4cGxpY2l0IHRoYXQgdGhpcyBpcyBhcHBsaWNhYmxlIGJvdGggdG8gY29u dHJvbCBhbmQgZGF0YSBwbGFuZSBzdGF0ZS4NCg0KDQotIFlvdSBzYXk6DQogIGFueSBub2RlIGlu IHRoZSBTUFJJTkcgcmVnaW9uIGlzIHRydXN0ZWQgdG8gc3RlZXIgYSBwYWNrZXQNCiAgdGhyb3Vn aCBhbnkgb2YgdGhlIG90aGVyIG5vZGVzIHdpdGhpbiB0aGUgcmVnaW9uLg0KVG8gbWUgdGhpcyBs aW1pdHMgInN0ZWVyaW5nIiwgYW5kIHBlcmhhcHMgc3RlZXJpbmcgaWRlbnRpZmllcnMsIHRvIHRo ZQ0Kbm9kZSBsZXZlbC4gSXMgc3RlZXJpbmcgYXQgdGhlIGludGVyZmFjZS9saW5rIGxldmVsIG5v dyBleGNsdWRlZD8gIFRoZQ0KdGV4dCBzaG91bGQgYmUgY2xlYXIgdGhhdCB0aGlzIGlzIGluIHNj b3BlLg0KDQpUaGlzIGNvdWxkIGJlIHdvcmRlZCBhcyAic3RlZXIgYSBwYWNrZXQgYWxvbmcgYW4g ZXhwbGljaXQgcGF0aCIuIFRoYXQgc2hvdWxkIGNvdmVyIGJvdGguDQoNCg0KW0pEXSAgV2Ugc2hv dWxkIHByb2JhYmx5IHVzZSB0aGUgUkZDIDMwMzEgdGVybWlub2xvZ3kgc28gd2Ugc2hvdWxkIHNh eSDigJxzdGVlciBhIHBhY2tldCBhbG9uZyBhbiBleHBsaWNpdCByb3V0ZSB0aHJvdWdoIHRoZSBT UFJJTkcgcmVnaW9u4oCdLg0KDQoNCg0KVGhhbmtzLA0KTG91DQoNCg0KDQo= --_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNuaXBwZWQs IGNvbW1lbnQgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91cnMgSXJyZXNwZWN0aXZlbHksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc3Rh dHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+U3JpZ2FuZXNoIEtpbmk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBTZXB0ZW1iZXIgMjAsIDIwMTMgMTI6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IExvdSBCZXJnZXI8 YnI+DQo8Yj5DYzo8L2I+IHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc7IHN0YXR1c0BpZXRmLm9yZzsg U3Rld2FydCBCcnlhbnQgKHN0YnJ5YW50KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1N0YXR1 c10gQ2hhcnRlcmluZyBuZXh0IHN0ZXBzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMjAsIDIw MTMgYXQgNzowMCBBTSwgTG91IEJlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFi bi5uZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Rld2FydCw8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQSBjb21tZW50IGFuZCBhIHF1ZXN0aW9u Ojxicj4NCi0gWW91IHNheTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyBhbnkgcGF0aCB3aXRob3V0 IHJlcXVpcmluZyBzdGF0ZSB0byBiZSBtYWludGFpbmVkIGJ5IHRyYW5zaXRlZCBub2RlczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IHdvdWxk IGJlIHdvcnRoIGNsYXJpZnlpbmcgdGhhdCBubyAmcXVvdDtwZXItcGF0aCBzdGF0ZSZxdW90OyBp czxicj4NCnJlcXVpcmVkIHRvIGJlIG1haW50YWluZWQuIFRoZSBleHRlbnNpb25zIGVsdWRlZCB0 byBiZWxvdyB3aWxsIGNlcnRhaW5seTxicj4NCmNvbnRyb2wvaW5zdGFsbCBzdGF0ZSBwZXIgbm9k ZSwganVzdCBub3QgcGVyIHBhdGguPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIGFuIGltcG9ydGFudCBkaXN0aW5jdGlv bi4gTWF5YmUgd29ydGh3aGlsZSB0byBiZSBleHBsaWNpdCB0aGF0IHRoaXMgaXMgYXBwbGljYWJs ZSBib3RoIHRvIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmUgc3RhdGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gWW91IHNh eTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyBhbnkgbm9kZSBpbiB0aGUgU1BSSU5HIHJlZ2lvbiBp cyB0cnVzdGVkIHRvIHN0ZWVyIGEgcGFja2V0PGJyPg0KJm5ic3A7IHRocm91Z2ggYW55IG9mIHRo ZSBvdGhlciBub2RlcyB3aXRoaW4gdGhlIHJlZ2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbWUgdGhpcyBsaW1pdHMgJnF1b3Q7c3RlZXJpbmcmcXVv dDssIGFuZCBwZXJoYXBzIHN0ZWVyaW5nIGlkZW50aWZpZXJzLCB0byB0aGU8YnI+DQpub2RlIGxl dmVsLiBJcyBzdGVlcmluZyBhdCB0aGUgaW50ZXJmYWNlL2xpbmsgbGV2ZWwgbm93IGV4Y2x1ZGVk PyAmbmJzcDtUaGU8YnI+DQp0ZXh0IHNob3VsZCBiZSBjbGVhciB0aGF0IHRoaXMgaXMgaW4gc2Nv cGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIGNvdWxkIGJlIHdvcmRlZCBhcyAmcXVvdDtzdGVlciBhIHBhY2tldCBhbG9u ZyBhbiBleHBsaWNpdCBwYXRoJnF1b3Q7LiBUaGF0IHNob3VsZCBjb3ZlciBib3RoLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltKRF0mbmJzcDsgV2Ugc2hvdWxkIHByb2JhYmx5IHVzZSB0aGUgUkZDIDMwMzEg dGVybWlub2xvZ3kgc28gd2Ugc2hvdWxkIHNheSDigJxzdGVlciBhIHBhY2tldCBhbG9uZyBhbiBl eHBsaWNpdCByb3V0ZSB0aHJvdWdoIHRoZSBTUFJJTkcgcmVnaW9u4oCdLiAmbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRo YW5rcyw8YnI+DQpMb3U8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_aa748c6b240642b9bdfecf836e918a48BY2PR05MB142namprd05pro_-- From loa@pi.nu Sun Sep 22 21:03:02 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0D011E80D9 for ; Sun, 22 Sep 2013 21:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDhevy5GL084 for ; Sun, 22 Sep 2013 21:02:58 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF021F9CEA for ; Sun, 22 Sep 2013 21:02:58 -0700 (PDT) Received: from [192.168.1.6] (unknown [112.208.59.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DD0781802038; Mon, 23 Sep 2013 06:02:55 +0200 (CEST) Message-ID: <523FBD6E.6090004@pi.nu> Date: Mon, 23 Sep 2013 12:02:54 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: stbryant@cisco.com References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> In-Reply-To: <523C41ED.3020102@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: status@ietf.org Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 04:03:03 -0000 Stewart, I think the proposed text is fine and would be a nice addition. However, .... What really concerns me is that there is a slight ambiguity in the list that the SPRIBNG working group will be chartered for. Propose that we change: OLD o Determine whether the above mentioned procedures require modification/changes to the existing MPLS architecture, and if so, then document such modifications/changes. o Determine whether the above mentioned procedures require modification/changes to the existing IPv6 architecture, and if so, then document such modifications/changes. NEW o Determine whether the above mentioned procedures require modification/changes to the existing MPLS architecture, and if so, then document requirements for such modifications/changes. o Determine whether the above mentioned procedures require modification/changes to the existing IPv6 architecture, and if so, then document requirements for such modifications/changes. OLD o Changes to MPLS architecture, if needed o Changes to IPv6 architecture, if needed NEW o Requirements for changes to MPLS architecture, if needed o Requirements for changes to IPv6 architecture, if needed /Loa On 2013-09-20 20:39, Stewart Bryant wrote: > Hi Loa, > > That is a good point, here is some text that might be considered for > inclusion: > > "Where possible, existing protocols must be used to implement the SPRING > function. Any modification or extension of existing architectures or > protocols must be carried out in the working groups responsible for the > architectures or protocols being modified in co-ordination with this > working group, but may be done in this working group after agreement > with all the relevant WG chairs and responsible ADs." > > A good place to put this would be before: "The SPRING working group is > chartered for the following list of items: " > > Would this address your concern? > > Stewart > > > On 20/09/2013 12:29, Loa Andersson wrote: >> Stewart, >> >> SPRING is a nice name :). >> >> The only thing that I don't find clear in this charter is >> whether to specify modifications to the data planes and architectures >> or if the group is supposed to act as a source for requirements for >> such changes. >> >> I hope we can agree to see SPRING as source for requirements for >> modification where the data plane and architecture has been developed >> by another active working group. >> >> /Loa >> >> >> On 2013-09-20 11:28, Stewart Bryant wrote: >>> This note is a summary of where we are with chartering the >>> work that we are discussing on the STATUS list and >>> the next steps. >>> >>> Firstly, as you know we (the ADs) had concerns with the >>> name "STATUS" being confusing. Having considered quite >>> a lot of possibilities, and not wanting the discussion >>> to bog down on a name, Adrian and I have decided >>> that the name Source Packet Routing in NetworkinG is >>> as good as any. Thus SPRING is name that we are using >>> in the charter process and is that I am putting in the >>> data-tracker for formal processing. >>> >>> Propose to start with the charter text that John Scudder >>> posted on 17/Sept with the following changes: >>> >>> s//SPRING/ >>> >>> I removed "ordered" from ordered list, as I think there >>> was a consensus to do so in the following emails in >>> the thread. >>> >>> I have not changed the state text, as I could not see >>> a consensus on what if any change I should make. >>> >>> The charter is uploaded at >>> >>> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>> >>> What we now need the list members to do is to propose >>> any necessary changes to the text, and I will reflect >>> the consensus of the group in revised charter text. >>> The differences in the version of the charter text will >>> be visible through the datatracker charter diff tool. >>> >>> For continuity, discussion will continue on the STATUS >>> list until we have a chartered WG, at which point the >>> Secretariat will switch us over. >>> >>> For reference the text I uploaded is as follows: >>> >>> Name: Source Packet Routing in Networking (SPRING) >>> >>> The SPRING working group will define procedures that will allow >>> a node to steer a packet between any source and destination through >>> a SPRING region on any path without requiring state to be >>> maintained by transited nodes, but rather at the source device. A >>> SPRING region is a network comprised of nodes (which may be of >>> any type, including routers and appliances) that share the following >>> trust model: any node in the SPRING region is trusted to steer >>> a packet through any of the other nodes within the region. The >>> SPRING region may comprise one or more ASes, or even less than a >>> single AS. Although a region may comprise more than one AS, initial >>> work will focus on the intra-domain, that is, single AS, scenario. >>> >>> The procedures should support both centralised and distributed path >>> computation. The procedures should also cover support for OAM >>> functions. >>> >>> Where use cases are documented, care should be taken to define the >>> data plane requirements for the environment within which they are >>> to be implemented. The procedures should avoid modifications to >>> the MPLS data plane, in order to remain compatible with existing >>> extensive deployments of MPLS. It is anticipated that the procedures >>> may require modifications to the IPv6 data plane. While the initial >>> focus of the SPRING WG is on the intra-domain deployment scenarios >>> (see below), the modifications to the IPv6 data plane must support >>> both intra and inter-domain deployment scenarios. >>> >>> The SPRING working group is chartered for the following list of >>> items: >>> >>> o Identification and evaluation of use cases for which there >>> is consensus within the WG. >>> o Definition of new procedures, driven by the use cases and underlying >>> technology. The new procedures must cover security considerations >>> (including the relationship between networks forming the SPRING >>> region) and allow for solutions which substantially improve upon >>> current technologies by defining requirements, extensions, or new >>> functionality in existing routing, management or other protocols. >>> o Determine whether the above mentioned procedures require >>> modification/changes to the existing MPLS architecture, and >>> if so, then document such modifications/changes. >>> o Determine whether the above mentioned procedures require >>> modification/changes to the existing IPv6 architecture, and >>> if so, then document such modifications/changes. >>> o The SPRING working group will then develop solutions, focusing >>> initially on intra-domain deployment scenarios. Where such >>> solutions utilize existing protocols (IS-IS, OSPF, BGP, PCE) this >>> will >>> be done in conjunction with the responsible IETF working group. Work >>> on new protocols may be carried out by the SPRING working group. >>> >>> The working group will develop the following documents: >>> >>> o One or more documents describing SPRING use cases, >>> o Specification of new procedures to support SPRING use cases, >>> o Changes to MPLS architecture, if needed >>> o Changes to IPv6 architecture, if needed >>> o Document interworking and co-existence between the new procedures >>> and the existing MPLS signaling protocols (LDP, RSVP-TE, BGP), >>> o Document impact (if any) of any proposed IPv6 data plane modifications >>> on existing deployment of IPv6, >>> o A set of one or more protocol extensions requirements documents, >>> o Inter-operability reports pertaining to the implementation of >>> extensions >>> supporting SPRING. >>> >>> Please review and propose changes you think are necessary to the >>> list. >>> >>> - Stewart >>> >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stbryant@cisco.com Mon Sep 23 06:13:08 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E00621F9EE1 for ; Mon, 23 Sep 2013 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwEFac-KsjSG for ; Mon, 23 Sep 2013 06:13:02 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB8D21F9E26 for ; Mon, 23 Sep 2013 06:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2777; q=dns/txt; s=iport; t=1379941982; x=1381151582; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=PGNfnq0R5xaU0amNoQHeKE7YcUh+c5anObQ+ShBd0wk=; b=FNyJLEndnogo14o24mtIgiDAA03ZaRxfO2TSvY0F+Oq+EiNeKJ6CJSp8 KRjNRXoPfQAjCAHvVAwqTY3BxjEY2/RF0OgcnVStheEEXt/F8Ij2Btr5g OnIyNHD1PGL/5rmA9OFQG6PLVPhgqBmcwoQiBL/y8rV5hIuZ9Ndyrsz6+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowYAPU9QFKQ/khN/2dsb2JhbABZgwc4BAECRYkMuCuBHxZ0giYBAQR4EQsEHRYPCQMCAQIBRRMIAQGIAQcFu1uMbYJ/FoQIA5d8gS+LGIUwgyVxAQ X-IronPort-AV: E=Sophos;i="4.90,962,1371081600"; d="scan'208,217";a="18216671" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 23 Sep 2013 13:12:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8NDCu29023583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Sep 2013 13:12:56 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8NDCt58026450; Mon, 23 Sep 2013 14:12:56 +0100 (BST) Message-ID: <52403E57.8060104@cisco.com> Date: Mon, 23 Sep 2013 14:12:55 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: status@ietf.org References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> In-Reply-To: <523FBD6E.6090004@pi.nu> Content-Type: multipart/alternative; boundary="------------030209000301020108010408" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 23 Sep 2013 13:13:08 -0000 This is a multi-part message in MIME format. --------------030209000301020108010408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt or if you prefer: *http://tinyurl.com/o24a9lz* The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart --------------030209000301020108010408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart
--------------030209000301020108010408-- From sprevidi@cisco.com Mon Sep 23 06:16:46 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7EC21F9F97 for ; Mon, 23 Sep 2013 06:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ+7JIhQC8rk for ; Mon, 23 Sep 2013 06:16:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0CABF21F9F5B for ; Mon, 23 Sep 2013 06:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3622; q=dns/txt; s=iport; t=1379942190; x=1381151790; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Fkp+cc2hDfG25qAXQcW9OQPOU/xE5yYDMGPtG6uOlWw=; b=eraavnXiLJAEVwXt/41qebVcq5E6iSVASQkuliX19wyf6oTUWCsucJx4 2qE4fH5XAiz3BF02eichIRkeBNQrg1hkgJdHHAMTjmCKj/eay3nIbQzTR 9yHhvo0oE/+cwe7X4VMZII+z4l3TFZnpRJia1/sir393Ns2RiuhGe0AG4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsZAKM+QFKtJV2d/2dsb2JhbABZgkNEOAQBAkXBN4EfFnSCJQEBAQSBBQQCAQgEEQILJDIdCAIEARIIE4dqBwW7Yoxtgkc4BoMYgQADiQCQK4sYhTCDJHIB X-IronPort-AV: E=Sophos;i="4.90,962,1371081600"; d="scan'208,217";a="263236784" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 23 Sep 2013 13:16:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8NDGT9R025932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Sep 2013 13:16:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 08:16:29 -0500 From: "Stefano Previdi (sprevidi)" To: "status@ietf.org" , "Stewart Bryant (stbryant)" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePSFVsDXVUUdkWPopncgaog/5nO0XAAgAATZ4CABCbBAIAAma2A//+tLBg= Date: Mon, 23 Sep 2013 13:16:28 +0000 Message-ID: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu>,<52403E57.8060104@cisco.com> In-Reply-To: <52403E57.8060104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:16:46 -0000 --_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we go deeper in the charter text discussion we'll end up defining the de= tails of the solution... s. Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Stewart Bryant (stbryant) [stbryant@cisco.com] Received: Monday, 23 Sep 2013, 15:13 To: status@ietf.org [status@ietf.org] Subject: Re: [Status] Chartering next steps I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit= =3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin= g%2Fwithmilestones-00-01.txt or if you prefer: http://tinyurl.com/o24a9lz The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart --_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we go deeper in the charter text discussion we'll end u= p defining the details of the solution...

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Stewart Bryant (stbryant) [stbryant@cisco.com]
Received: Monday, 23 Sep 2013, 15:13
To: status@ietf.org [status@ietf.org]
Subject: Re: [Status] Chartering next steps
I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring= /

The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.iet= f.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype= =3D--html&submit=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F= doc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

h= ttp://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart
--_000_E0A1DE675FEC854ABF07D319E556FE643F530655xmbrcdx01ciscoc_-- From stbryant@cisco.com Mon Sep 23 06:36:42 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0321F9F77 for ; Mon, 23 Sep 2013 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpYPvOtvMemv for ; Mon, 23 Sep 2013 06:36:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 70D9021F9F3D for ; Mon, 23 Sep 2013 06:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6636; q=dns/txt; s=iport; t=1379943396; x=1381152996; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=4IP1hXMCMu1UaCtzXQTJdwBVnfOI3Z6AZ1rwuGpWsYE=; b=JH7r70V0xu4fv0OGT7RXO/jwas/bQomJGUaSlwiTqesGvE5Ik/QA+m5f y0tMOLlF/aR9l5G4wZejdp65Zyl4WmNKtMXOyq0+odeauvwiWv5xb/IvC KTKd03ozY96CuAyJjRQsMRocX6G+BaReaDdqS6ST83a2W+8BKIBOZSPdQ E=; X-IronPort-AV: E=Sophos;i="4.90,962,1371081600"; d="scan'208,217";a="159909345" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 23 Sep 2013 13:36:35 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8NDaY2F018850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 13:36:34 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8NDaXlE028102; Mon, 23 Sep 2013 14:36:33 +0100 (BST) Message-ID: <524043E1.2070209@cisco.com> Date: Mon, 23 Sep 2013 14:36:33 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "status@ietf.org" References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu>, <52403E57.8060104@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000009000908070708090008" Cc: "Stefano Previdi \(sprevidi\)" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 23 Sep 2013 13:36:42 -0000 This is a multi-part message in MIME format. --------------000009000908070708090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I can take that text out if people wish. One purpose that it serves is to educate those reviewing the charter that have not been following the detail. I have also updated the BoF placeholder, and this can be found at: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart Note that the purpose of the draft list is partially to educate people about the subject area and partially to demonstrate that the IETF has the energy work on this. I thus hoovered up all the relevant drafts, and make no comment about order, or priority, or which will be pursued and which will be dropped. If I missed any that was accidental. - Stewart On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote: > If we go deeper in the charter text discussion we'll end up defining > the details of the solution... > > s. > > Sent from my Android phone using TouchDown (www.nitrodesk.com) > > -----Original Message----- > *From:* Stewart Bryant (stbryant) [stbryant@cisco.com] > *Received:* Monday, 23 Sep 2013, 15:13 > *To:* status@ietf.org [status@ietf.org] > *Subject:* Re: [Status] Chartering next steps > > I have included the proposed changes and some text that > clarifies the link-node discussion. > > The current charter text is at > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > The diffs are at > > https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt > > or if you prefer: > > *http://tinyurl.com/o24a9lz* > > The link node text I added was > > "Steering is achieved by specifying in the packet an ordered > set of nodes and/or links and/or shortest-path-next-hops > to be traversed by the packet." > > - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000009000908070708090008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I can take that text out if people wish.

One purpose that it serves is to educate those reviewing the charter that have not been following the detail.

I have also updated the BoF placeholder, and this can be found at:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Note that the purpose of the draft list is partially to educate people about the subject area and partially to demonstrate that the IETF has the energy work on this. I thus hoovered up all the relevant drafts, and make no comment about order, or priority, or which will be pursued and which will be dropped. If I missed any that was accidental.

- Stewart


On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:
If we go deeper in the charter text discussion we'll end up defining the details of the solution...

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Stewart Bryant (stbryant) [stbryant@cisco.com]
Received: Monday, 23 Sep 2013, 15:13
To: status@ietf.org [status@ietf.org]
Subject: Re: [Status] Chartering next steps
I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000009000908070708090008-- From jdrake@juniper.net Mon Sep 23 06:36:55 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEC121F9F0E for ; Mon, 23 Sep 2013 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmxXsySEqGGr for ; Mon, 23 Sep 2013 06:36:50 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0E46221F9F03 for ; Mon, 23 Sep 2013 06:36:50 -0700 (PDT) Received: from mail17-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 13:36:49 +0000 Received: from mail17-am1 (localhost [127.0.0.1]) by mail17-am1-R.bigfish.com (Postfix) with ESMTP id DED044A00C4; Mon, 23 Sep 2013 13:36:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz9371Ic85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL177df4h17326ah18c673h189882h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail17-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(53806001)(33646001)(76786001)(65816001)(80022001)(16236675002)(19580405001)(79102001)(63696002)(77096001)(74876001)(54356001)(74366001)(81342001)(46102001)(15395725003)(4396001)(74706001)(47976001)(49866001)(54316002)(31966008)(56816003)(15975445006)(76576001)(15202345003)(50986001)(47736001)(74662001)(59766001)(47446002)(66066001)(83322001)(80976001)(16119065003)(56776001)(81686001)(83072001)(19300405004)(69226001)(77982001)(74502001)(51856001)(81542001)(74316001)(19580395003)(81816001)(76482001)(76796001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 1379943406247520_6950; Mon, 23 Sep 2013 13:36:46 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.248]) by mail17-am1.bigfish.com (Postfix) with ESMTP id 2EF304E0056; Mon, 23 Sep 2013 13:36:46 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 13:36:45 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 13:36:44 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 13:36:41 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 13:36:41 +0000 From: John E Drake To: "stbryant@cisco.com" , "status@ietf.org" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAGjkA= Date: Mon, 23 Sep 2013 13:36:40 +0000 Message-ID: <195ac307b7714864b8c358b5f425f5a0@BY2PR05MB142.namprd05.prod.outlook.com> References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com> In-Reply-To: <52403E57.8060104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09781D4C35 Content-Type: multipart/alternative; boundary="_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:36:56 -0000 --_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, This looks fine. Yours Irrespectively, John From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Monday, September 23, 2013 6:13 AM To: status@ietf.org Subject: Re: [Status] Chartering next steps I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit= =3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin= g%2Fwithmilestones-00-01.txt or if you prefer: http://tinyurl.com/o24a9lz The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart --_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

This looks fine.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@= ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: status@ietf.org
Subject: Re: [Status] Chartering next steps

 

I have included the proposed changes and some text t= hat
clarifies the link-node discussion.

The current charter text is at

https://d= atatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/= rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri= ng%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=3DGo!&ur= l2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithm= ilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_195ac307b7714864b8c358b5f425f5a0BY2PR05MB142namprd05pro_-- From Peter.AshwoodSmith@huawei.com Mon Sep 23 06:53:25 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358821F9FA3 for ; Mon, 23 Sep 2013 06:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.463 X-Spam-Level: X-Spam-Status: No, score=-5.463 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pRcSfU896sX for ; Mon, 23 Sep 2013 06:53:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C063721F9F8E for ; Mon, 23 Sep 2013 06:53:20 -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.5-GA FastPath queued) with ESMTP id AVT78129; Mon, 23 Sep 2013 13:53:13 +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.146.0; Mon, 23 Sep 2013 14:52:19 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 23 Sep 2013 14:53:05 +0100 Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0146.000; Mon, 23 Sep 2013 06:53:02 -0700 From: AshwoodsmithPeter To: "status@ietf.org" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePN/T6k2Z6sxUigh3eb0yczgpnO8vcAgAATZ4CABCbBAIAAma2AgAAA/gCAAAWcgP//jvxw Date: Mon, 23 Sep 2013 13:53:01 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2099078CB@dfweml513-mbb.china.huawei.com> References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu>, <52403E57.8060104@cisco.com> <524043E1.2070209@cisco.com> In-Reply-To: <524043E1.2070209@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.88] Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:53:25 -0000 --_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems reasonable to me too. Peter From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Monday, September 23, 2013 9:37 AM To: status@ietf.org Cc: Stefano Previdi (sprevidi) Subject: Re: [Status] Chartering next steps I can take that text out if people wish. One purpose that it serves is to educate those reviewing the charter that h= ave not been following the detail. I have also updated the BoF placeholder, and this can be found at: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart Note that the purpose of the draft list is partially to educate people abou= t the subject area and partially to demonstrate that the IETF has the energ= y work on this. I thus hoovered up all the relevant drafts, and make no com= ment about order, or priority, or which will be pursued and which will be d= ropped. If I missed any that was accidental. - Stewart On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote: If we go deeper in the charter text discussion we'll end up defining the de= tails of the solution... s. Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: Stewart Bryant (stbryant) [stbryant@cisco.com] Received: Monday, 23 Sep 2013, 15:13 To: status@ietf.org [status@ietf.org] Subject: Re: [Status] Chartering next steps I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit= =3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin= g%2Fwithmilestones-00-01.txt or if you prefer: http://tinyurl.com/o24a9lz The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems reasonable to me to= o.

 <= /p>

Peter

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@ie= tf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 9:37 AM
To: status@ietf.org
Cc: Stefano Previdi (sprevidi)
Subject: Re: [Status] Chartering next steps

 

I can take that text out if people wish.

One purpose that it serves is to educate those reviewing the charter that h= ave not been following the detail.

I have also updated the BoF placeholder, and this can be found at:

http://trac.= tools.ietf.org/bof/trac/wiki/WikiStart

Note that the purpose of the draft list is partially to educate people abou= t the subject area and partially to demonstrate that the IETF has the energ= y work on this. I thus hoovered up all the relevant drafts, and make no com= ment about order, or priority, or which will be pursued and which will be dropped. If I missed any that was = accidental.

- Stewart


On 23/09/2013 14:16, Stefano Previdi (sprevidi) wrote:

If we go= deeper in the charter text discussion we'll end up defining the details of= the solution...

s.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Stewart Bryant (stbryant) [stbryant@cisco.com]
Received: Monday, 23 Sep 2013, 15:13
To: status@ietf.org [status@ietf.org]
Subject: Re: [Status] Chartering next steps

I have included the proposed changes and some text t= hat
clarifies the link-node discussion.

The current charter text is at

https://d= atatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.or= g/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sp= ring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=3DGo!&= url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwit= hmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart




-- 
For corporate legal information go to:
 
http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 
--_000_7AE6A4247B044C4ABE0A5B6BF427F8E2099078CBdfweml513mbbchi_-- From jdrake@juniper.net Mon Sep 23 08:02:08 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBE721F9EA8 for ; Mon, 23 Sep 2013 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1QofkpsYVos for ; Mon, 23 Sep 2013 08:02:03 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82521F995E for ; Mon, 23 Sep 2013 08:02:02 -0700 (PDT) Received: from mail38-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE034.bigfish.com (10.174.14.97) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 15:02:01 +0000 Received: from mail38-db9 (localhost [127.0.0.1]) by mail38-db9-R.bigfish.com (Postfix) with ESMTP id 3996C601E3; Mon, 23 Sep 2013 15:02:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zz9371Ic85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL177df4h17326ah18c673h189882h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h9a9j1155h) Received-SPF: pass (mail38-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(189002)(199002)(54316002)(81816001)(81542001)(56776001)(74662001)(81342001)(15975445006)(83072001)(76482001)(77982001)(59766001)(31966008)(47446002)(66066001)(69226001)(16119065003)(80976001)(83322001)(74502001)(81686001)(19580405001)(19580395003)(19300405004)(74316001)(16236675002)(76796001)(76786001)(15202345003)(76576001)(54356001)(63696002)(15395725003)(74366001)(79102001)(65816001)(74706001)(53806001)(74876001)(46102001)(47976001)(80022001)(56816003)(51856001)(77096001)(50986001)(47736001)(49866001)(33646001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail38-db9 (localhost.localdomain [127.0.0.1]) by mail38-db9 (MessageSwitch) id 1379948512834627_21487; Mon, 23 Sep 2013 15:01:52 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.251]) by mail38-db9.bigfish.com (Postfix) with ESMTP id A49614600E7; Mon, 23 Sep 2013 15:01:52 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 15:01:51 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 15:01:45 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 15:01:42 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 15:01:42 +0000 From: John E Drake To: "stbryant@cisco.com" , "status@ietf.org" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAdwJA= Date: Mon, 23 Sep 2013 15:01:41 +0000 Message-ID: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com> In-Reply-To: <52403E57.8060104@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09781D4C35 Content-Type: multipart/alternative; boundary="_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:02:08 -0000 --_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Upon reflection, I spoke too soon. The use of the term 'explicit route' as= suggested by Lou and myself is fine, but the sentence you added: "Steering is achieved by specifying in the packet an ordered set of nodes a= nd/or links and/or shortest-path-next-hops to be traversed by the packet." has issues. A packet *will not* have contain an ordered set of nodes and/o= r links and/or shortest-path-next-hops to be traversed by the packet, rathe= r it will have a set of identifiers specifying resources within a SPRING re= gion, and these specified resources *are not* limited to "nodes and/or link= s and/or shortest-path-next-hops"; they may also include, for example, forw= arding adjacencies and services. I suggest that we strike the sentence. As Stefano points out, a charter is= not a design specification. Yours Irrespectively, John From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Monday, September 23, 2013 6:13 AM To: status@ietf.org Subject: Re: [Status] Chartering next steps I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit= =3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin= g%2Fwithmilestones-00-01.txt or if you prefer: http://tinyurl.com/o24a9lz The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart --_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart,

 <= /p>

Upon reflection, I spoke = too soon.  The use of the term ‘explicit route’ as suggest= ed by Lou and myself is fine, but the sentence you added:=

 <= /p>

“Steering is achiev= ed by specifying in the packet an ordered set of nodes and/or links and/or = shortest-path-next-hops to be traversed by the packet.”

 <= /p>

has issues.  A packe= t *will not* have contain an ordered set of nodes and/or links and/o= r shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING reg= ion, and these specified resources *are not* limited to “nodes= and/or links and/or shortest-path-next-hops”; they may also include,= for example, forwarding adjacencies and services.

 <= /p>

I suggest that we strike = the sentence.  As Stefano points out, a charter is not a design specif= ication.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@= ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: status@ietf.org
Subject: Re: [Status] Chartering next steps

 

I have included the proposed changes and some text t= hat
clarifies the link-node discussion.

The current charter text is at

https://d= atatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/= rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri= ng%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=3DGo!&ur= l2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithm= ilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_d382f78d4a2f4ee4a65b0814e76ef373BY2PR05MB142namprd05pro_-- From sprevidi@cisco.com Mon Sep 23 08:09:18 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5010221F9FC3 for ; Mon, 23 Sep 2013 08:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.803 X-Spam-Level: X-Spam-Status: No, score=-109.803 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wMvNN4nZbym for ; Mon, 23 Sep 2013 08:09:13 -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 78D2C21F9F70 for ; Mon, 23 Sep 2013 08:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9197; q=dns/txt; s=iport; t=1379948949; x=1381158549; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=45FRSVgenLuetcTojgEEKUXaAE2LgHgQx1v+c+kuG+w=; b=OesbG/zS8eoRYWMmRG+npCxS8ZTVBBD1Gx68F56JWKbvE5SUxe1Bws91 tbBO78O+gPXvhblQpEdpzf0Q4XVRr3F7T3e5hAxHEGH5WC5I/iIyEU5kK 5S+nOg7kwdqLN3HJ5ZKbeB4070na4h5WLdtAdFJYw3Wr84bg9eCHxwt39 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFACFZQFKtJV2Z/2dsb2JhbABZgkNEOEzBN4EhFnSCJQEBAQSBBQQCAQgRBAEBCx0HMhQJCAIEARIIh30HBbsXjG2BLwqBDi0KAQaDGIEAA5krixiFMIMkcgF1CRc X-IronPort-AV: E=Sophos;i="4.90,963,1371081600"; d="scan'208,217";a="263319906" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 23 Sep 2013 15:08:52 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8NF8qlY006956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 15:08:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 10:08:51 -0500 From: "Stefano Previdi (sprevidi)" To: "Stewart Bryant (stbryant)" , "status@ietf.org" , "jdrake@juniper.net" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePSFVsDXVUUdkWPopncgaog/5nO0XAAgAATZ4CABCbBAIAAma2AgAAeY4D//64vnA== Date: Mon, 23 Sep 2013 15:08:51 +0000 Message-ID: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:09:18 -0000 --_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable John, To me, the text is ok as proposed in last email from Stewart. My comment ap= plies more on your last comment. s. -- Sent from a device pretending to be smart. -----Original Message----- From: John E Drake [jdrake@juniper.net] Received: Monday, 23 Sep 2013, 17:02 To: Stewart Bryant (stbryant) [stbryant@cisco.com]; status@ietf.org [status= @ietf.org] Subject: Re: [Status] Chartering next steps Stewart, Upon reflection, I spoke too soon. The use of the term =91explicit route= =92 as suggested by Lou and myself is fine, but the sentence you added: =93Steering is achieved by specifying in the packet an ordered set of nodes= and/or links and/or shortest-path-next-hops to be traversed by the packet.= =94 has issues. A packet *will not* have contain an ordered set of nodes and/o= r links and/or shortest-path-next-hops to be traversed by the packet, rathe= r it will have a set of identifiers specifying resources within a SPRING re= gion, and these specified resources *are not* limited to =93nodes and/or li= nks and/or shortest-path-next-hops=94; they may also include, for example, = forwarding adjacencies and services. I suggest that we strike the sentence. As Stefano points out, a charter is= not a design specification. Yours Irrespectively, John From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Monday, September 23, 2013 6:13 AM To: status@ietf.org Subject: Re: [Status] Chartering next steps I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit= =3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin= g%2Fwithmilestones-00-01.txt or if you prefer: http://tinyurl.com/o24a9lz The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart --_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable John,

To me, the text is ok as proposed in last email from Stewart. My comment ap= plies more on your last comment.

s.



--
Sent from a device pretending to be smart.

-----Original Message-----
From: John E Drake [jdrake@juniper.net]
Received: Monday, 23 Sep 2013, 17:02
To: Stewart Bryant (stbryant) [stbryant@cisco.com]; status@ietf.org = [status@ietf.org]
Subject: Re: [Status] Chartering next steps

Stewart,

 

Upon reflection, I spok= e too soon.  The use of the term =91explicit route=92 as suggested by = Lou and myself is fine, but the sentence you added:

 

=93Steering is achieved= by specifying in the packet an ordered set of nodes and/or links and/or sh= ortest-path-next-hops to be traversed by the packet.=94

 

has issues.  A pac= ket *will not* have contain an ordered set of nodes and/or links and= /or shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING reg= ion, and these specified resources *are not* limited to =93nodes and= /or links and/or shortest-path-next-hops=94; they may also include, for exa= mple, forwarding adjacencies and services.

 

I suggest that we strik= e the sentence.  As Stefano points out, a charter is not a design spec= ification.

 

Yours Irrespectively,

 

John

 

From:<= span style=3D"font-size:11.0pt; font-family:"Calibri","sans-= serif"; color:windowtext"> status-bounces@ietf.org [mailto:status-boun= ces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: status@ietf.org
Subject: Re: [Status] Chartering next steps

 

I have included the proposed changes and some text t= hat
clarifies the link-node discussion.

The current charter text is at

https://d= atatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/= rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri= ng%2Fwithmilestones-00-00.txt&difftype=3D--html&submit=3DGo!&ur= l2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithm= ilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart

--_000_E0A1DE675FEC854ABF07D319E556FE643F53091Bxmbrcdx01ciscoc_-- From stbryant@cisco.com Mon Sep 23 09:26:23 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7D921F8BFD for ; Mon, 23 Sep 2013 09:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4G0eeaV-IZ7 for ; Mon, 23 Sep 2013 09:26:18 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CEAD421F8AD5 for ; Mon, 23 Sep 2013 09:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12245; q=dns/txt; s=iport; t=1379953578; x=1381163178; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=yz8GPRLm9DV/fbItko2eG+rM2QUImZ+V/nqw/8A9Hy0=; b=R60utY8y61YawiEGvRGS3jrIZBJPk23EIEt1a1sa4WjkQaYKZSZl8sWw qo7sOKsmvny/unN7u6rj/ehBb9C6xZRXOrx4XHRcmHh3QxFQKFmOf2RwX jf5Pl5XuAuW+JN3C04LIlNgCkF4PcSPIzj5u138e9VCCjDd/HRTYyGsS3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAD9qQFKQ/khN/2dsb2JhbABZgkNEOEyJDLdhSoEiFnSCJQEBAQQBAQEqQQoBEAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAYgBBwW7RYxtgTmBPwYBhB4Dl3yBL4sYhTCDJXEBdQ X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208,217";a="17746163" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 23 Sep 2013 16:26:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8NGQCIl006875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 16:26:12 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8NGQA2j011665; Mon, 23 Sep 2013 17:26:11 +0100 (BST) Message-ID: <52406BA2.9010607@cisco.com> Date: Mon, 23 Sep 2013 17:26:10 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John E Drake References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080200020501080809040204" Cc: "status@ietf.org" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 23 Sep 2013 16:26:23 -0000 This is a multi-part message in MIME format. --------------080200020501080809040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Maybe I will take the sentence out, because there is more to identifiers than next hops. For example, a PW label, which we may find on the stack, is an instruction (decap, munge and sent to an interface), so the concern is that the text might be unnecessarily constraining which would outweigh its utility as tutorial material. Stewart On 23/09/2013 16:01, John E Drake wrote: > > Stewart, > > Upon reflection, I spoke too soon. The use of the term 'explicit > route' as suggested by Lou and myself is fine, but the sentence you added: > > "Steering is achieved by specifying in the packet an ordered set of > nodes and/or links and/or shortest-path-next-hops to be traversed by > the packet." > > has issues. A packet **will not** have contain an ordered set of > nodes and/or links and/or shortest-path-next-hops to be traversed by > the packet, rather it will have a set of identifiers specifying > resources within a SPRING region, and these specified resources **are > not** limited to "nodes and/or links and/or shortest-path-next-hops"; > they may also include, for example, forwarding adjacencies and services. > > I suggest that we strike the sentence. As Stefano points out, a > charter is not a design specification. > > Yours Irrespectively, > > John > > *From:*status-bounces@ietf.org [mailto:status-bounces@ietf.org] *On > Behalf Of *Stewart Bryant > *Sent:* Monday, September 23, 2013 6:13 AM > *To:* status@ietf.org > *Subject:* Re: [Status] Chartering next steps > > I have included the proposed changes and some text that > clarifies the link-node discussion. > > The current charter text is at > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > The diffs are at > > https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt > > > or if you prefer: > > *http://tinyurl.com/o24a9lz* > > The link node text I added was > > "Steering is achieved by specifying in the packet an ordered > set of nodes and/or links and/or shortest-path-next-hops > to be traversed by the packet." > > - Stewart > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------080200020501080809040204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Maybe I will take the sentence out, because there
is more to identifiers than next hops. For example,
a PW label, which we may find on the stack, is an
instruction (decap, munge and sent to an interface),
so the concern is that the text might be unnecessarily
constraining which would outweigh its utility as
tutorial material.

Stewart



On 23/09/2013 16:01, John E Drake wrote:

Stewart,

 

Upon reflection, I spoke too soon.  The use of the term ‘explicit route’ as suggested by Lou and myself is fine, but the sentence you added:

 

“Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet.”

 

has issues.  A packet *will not* have contain an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING region, and these specified resources *are not* limited to “nodes and/or links and/or shortest-path-next-hops”; they may also include, for example, forwarding adjacencies and services.

 

I suggest that we strike the sentence.  As Stefano points out, a charter is not a design specification.

 

Yours Irrespectively,

 

John

 

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: status@ietf.org
Subject: Re: [Status] Chartering next steps

 

I have included the proposed changes and some text that
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart



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



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------080200020501080809040204-- From jdrake@juniper.net Mon Sep 23 10:43:56 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019B421F9F9E for ; Mon, 23 Sep 2013 10:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFfO1fJmg-QZ for ; Mon, 23 Sep 2013 10:43:51 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1507C21F9F80 for ; Mon, 23 Sep 2013 10:43:38 -0700 (PDT) Received: from mail184-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE036.bigfish.com (10.243.66.101) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 17:43:38 +0000 Received: from mail184-co1 (localhost [127.0.0.1]) by mail184-co1-R.bigfish.com (Postfix) with ESMTP id 420B94800D8; Mon, 23 Sep 2013 17:43:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: VPS-17(zzbb2dI98dI9371Ic85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz31iz1de098h1033IL177df4h17326ah18c673h189882h1de097h186068h8275bh8275dhz2fh2a8h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20f0h20b3m1155h) Received-SPF: pass (mail184-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(377454003)(479174003)(189002)(199002)(65816001)(76786001)(53806001)(80022001)(16236675002)(19580405001)(79102001)(63696002)(77096001)(74876001)(54356001)(74366001)(81342001)(46102001)(47976001)(74706001)(15395725003)(4396001)(49866001)(54316002)(31966008)(56816003)(15975445006)(15202345003)(36756003)(33656001)(50986001)(47736001)(74662001)(82746002)(47446002)(66066001)(83322001)(59766001)(80976001)(16119065003)(56776001)(69226001)(81686001)(83072001)(77982001)(74502001)(51856001)(81542001)(19580395003)(81816001)(76482001)(76796001)(83716002)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:166.147.96.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail184-co1 (localhost.localdomain [127.0.0.1]) by mail184-co1 (MessageSwitch) id 1379958215895851_32501; Mon, 23 Sep 2013 17:43:35 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.253]) by mail184-co1.bigfish.com (Postfix) with ESMTP id D66FF100049; Mon, 23 Sep 2013 17:43:35 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 17:43:35 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 17:43:33 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 17:43:31 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 17:43:31 +0000 From: John E Drake To: "" Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAdwJCAABg+AIAAFZ3x Date: Mon, 23 Sep 2013 17:43:31 +0000 Message-ID: <9831C148-9C79-4648-896A-383E9B791BE7@juniper.net> References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com> , <52406BA2.9010607@cisco.com> In-Reply-To: <52406BA2.9010607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.96.19] x-forefront-prvs: 09781D4C35 Content-Type: multipart/alternative; boundary="_000_9831C1489C794648896A383E9B791BE7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:43:56 -0000 --_000_9831C1489C794648896A383E9B791BE7junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sent from my iPhone On Sep 23, 2013, at 12:27 PM, "Stewart Bryant" > wrote: Maybe I will take the sentence out, because there is more to identifiers than next hops. For example, a PW label, which we may find on the stack, is an instruction (decap, munge and sent to an interface), so the concern is that the text might be unnecessarily constraining which would outweigh its utility as tutorial material. Stewart On 23/09/2013 16:01, John E Drake wrote: Stewart, Upon reflection, I spoke too soon. The use of the term 'explicit route' as= suggested by Lou and myself is fine, but the sentence you added: "Steering is achieved by specifying in the packet an ordered set of nodes a= nd/or links and/or shortest-path-next-hops to be traversed by the packet." has issues. A packet *will not* have contain an ordered set of nodes and/o= r links and/or shortest-path-next-hops to be traversed by the packet, rathe= r it will have a set of identifiers specifying resources within a SPRING re= gion, and these specified resources *are not* limited to "nodes and/or link= s and/or shortest-path-next-hops"; they may also include, for example, forw= arding adjacencies and services. I suggest that we strike the sentence. As Stefano points out, a charter is= not a design specification. Yours Irrespectively, John From: status-bounces@ietf.org [mailto:statu= s-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Monday, September 23, 2013 6:13 AM To: status@ietf.org Subject: Re: [Status] Chartering next steps I have included the proposed changes and some text that clarifies the link-node discussion. The current charter text is at https://datatracker.ietf.org/doc/charter-ietf-spring/ The diffs are at https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdo= c%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&submit= =3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sprin= g%2Fwithmilestones-00-01.txt or if you prefer: http://tinyurl.com/o24a9lz The link node text I added was "Steering is achieved by specifying in the packet an ordered set of nodes and/or links and/or shortest-path-next-hops to be traversed by the packet." - Stewart _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_9831C1489C794648896A383E9B791BE7junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Sent from my iPhone

On Sep 23, 2013, at 12:27 PM, "Stewart Bryant" <stbryant@cisco.com> wrote:

Maybe I will take the sentence out, because = there
is more to identifiers than next hops. For example,
a PW label, which we may find on the stack, is an
instruction (decap, munge and sent to an interface),
so the concern is that the text might be unnecessarily
constraining which would outweigh its utility as
tutorial material.

Stewart



On 23/09/2013 16:01, John E Drake wrote:

Stewart,

 <= /p>

Upon reflection, I spoke = too soon.  The use of the term ‘explicit route’ as suggest= ed by Lou and myself is fine, but the sentence you added:=

 <= /p>

“Steering is achiev= ed by specifying in the packet an ordered set of nodes and/or links and/or = shortest-path-next-hops to be traversed by the packet.”

 <= /p>

has issues.  A packe= t *will not* have contain an ordered set of nodes and/or links and/o= r shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING reg= ion, and these specified resources *are not* limited to “nodes= and/or links and/or shortest-path-next-hops”; they may also include,= for example, forwarding adjacencies and services.

 <= /p>

I suggest that we strike = the sentence.  As Stefano points out, a charter is not a design specif= ication.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: status@ietf.org
Subject: Re: [Status] Chartering next steps

 

I have included the proposed changes and some text t= hat
clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/
The diffs are at

https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org= %2Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--ht= ml&submit=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fc= harter-ietf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

http://t= inyurl.com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart



_______________________________________________
status mailing list
statu=
s@ietf.org
https://www.ietf.org/mailman/listinfo/status



--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_bu=
siness/legal/cri/index.html
--_000_9831C1489C794648896A383E9B791BE7junipernet_-- From sriganeshkini@gmail.com Mon Sep 23 10:44:42 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F721F9FA4 for ; Mon, 23 Sep 2013 10:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzkgYWxefZ1R for ; Mon, 23 Sep 2013 10:44:41 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C94B321F9F80 for ; Mon, 23 Sep 2013 10:44:41 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz1so2587369pad.16 for ; Mon, 23 Sep 2013 10:44:41 -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:from:date:message-id :subject:to:cc:content-type; bh=+mTX1oae8fic4PxHmZzht1aw5n0EEcrKZN3ixUI7SnU=; b=o4CA38vCyQcpa6HsdHwkQs5+nT2kNU8J6ah1v1qHhWbxgXxV5JGPsM2QG9nEmL6kFZ VkLfrs09jRGCNVtJ2L6SwW3EKlEyPFmNmNXwEXBB0ret0kw5aKG9G5bR/5rVLEWcE4FV RFQMokhtXJx5Y+I92/CakUMYdRUB/pub93gHzhbo0xvk9jMSreVFMlMrhb0l1cG1PcyC nVh6BaXvpNd6Vrql04Mqg4pWWN2N90xvIf1DgQzTDxryJnHmkhFESQ9J/7tagFXN3KRf s3cX/WKZ7qQ5419SpvuaMJImrHqjdnRu2yNxat0TmGfteyEOeP0znhnYUzx3w63kKznT gh0w== X-Received: by 10.66.227.39 with SMTP id rx7mr26438267pac.44.1379958273071; Mon, 23 Sep 2013 10:44:33 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.225 with HTTP; Mon, 23 Sep 2013 10:44:03 -0700 (PDT) In-Reply-To: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com> From: Sriganesh Kini Date: Mon, 23 Sep 2013 10:44:03 -0700 X-Google-Sender-Auth: FEjtHpzLgTvfwxExyEKi2WEsc5s Message-ID: To: John E Drake Content-Type: multipart/alternative; boundary=047d7b111f3fabe2c304e71092ec Cc: "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:44:42 -0000 --047d7b111f3fabe2c304e71092ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >From RFC 3031, sec 3.21 Explicit routing may be useful for a number of purposes, such as policy routing or traffic engineering. In MPLS, the explicit route needs to be specified at the time that labels are assigned, but the explicit route does not have to be specified with each IP packet. This makes MPLS explicit routing much more efficient than the alternative of IP source routing. If the "explicit-route" in SPRING is the same as explicit-route in RFC3031 then we are ruling out source-routing ! IMO we should call it explicit-route but re-define it for SPRING. The definition could be "a set of identifiers in the packet that allow it to be steered through the network without having per flow information at each intermediate node". However this re-definition need not be in the charter but could go in another document (architecture document). - Sri On Mon, Sep 23, 2013 at 8:01 AM, John E Drake wrote: > Stewart,**** > > ** ** > > Upon reflection, I spoke too soon. The use of the term =E2=80=98explicit= route=E2=80=99 > as suggested by Lou and myself is fine, but the sentence you added:**** > > ** ** > > =E2=80=9CSteering is achieved by specifying in the packet an ordered set = of nodes > and/or links and/or shortest-path-next-hops to be traversed by the packet= .=E2=80=9D > **** > > ** ** > > has issues. A packet **will not** have contain an ordered set of nodes > and/or links and/or shortest-path-next-hops to be traversed by the packet= , > rather it will have a set of identifiers specifying resources within a > SPRING region, and these specified resources **are not** limited to > =E2=80=9Cnodes and/or links and/or shortest-path-next-hops=E2=80=9D; they= may also include, > for example, forwarding adjacencies and services.**** > > ** ** > > I suggest that we strike the sentence. As Stefano points out, a charter > is not a design specification. **** > > ** ** > > Yours Irrespectively,**** > > ** ** > > John**** > > ** ** > > *From:* status-bounces@ietf.org [mailto:status-bounces@ietf.org] *On > Behalf Of *Stewart Bryant > *Sent:* Monday, September 23, 2013 6:13 AM > *To:* status@ietf.org > > *Subject:* Re: [Status] Chartering next steps**** > > ** ** > > I have included the proposed changes and some text that > > clarifies the link-node discussion. > > The current charter text is at > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > The diffs are at > > > https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2F= doc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&subm= it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spr= ing%2Fwithmilestones-00-01.txt > > or if you prefer: > > *http://tinyurl.com/o24a9lz* > > The link node text I added was > > "Steering is achieved by specifying in the packet an ordered > set of nodes and/or links and/or shortest-path-next-hops > to be traversed by the packet." > > - Stewart**** > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > > --047d7b111f3fabe2c304e71092ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From RFC 3031, sec 3.21

=
   Explicit routing may be useful for a number of purposes, such as
   policy routing or traffic engineering.  In MPLS, the explicit route
   needs to be specified at the time that labels are assigned, but the
   explicit route does not have to be specified with each IP packet.
   This makes MPLS explicit routing much more efficient than the
   alternative of IP source routing.

If the = "explicit-route" in SPRING is the same as explicit-route in RFC30= 31 then we are ruling out source-routing ! IMO we should call it explicit-r= oute but re-define it for SPRING. The definition could be "a set of id= entifiers in the packet that allow it to be steered through the network wit= hout having per flow information at each intermediate node". However t= his re-definition need not be in the charter but could go in another docume= nt (architecture document).

- Sri
=C2=A0
=

On Mon, Sep 23, 2013 at 8:01 AM, John E = Drake <jdrake@juniper.net> wrote:

Stewart,

=C2=A0

Upon reflection, I spoke = too soon.=C2=A0 The use of the term =E2=80=98explicit route=E2=80=99 as sug= gested by Lou and myself is fine, but the sentence you added:=

=C2=A0

=E2=80=9CSteering is achi= eved by specifying in the packet an ordered set of nodes and/or links and/o= r shortest-path-next-hops to be traversed by the packet.=E2=80=9D=

=C2=A0

has issues.=C2=A0 A packe= t *will not* have contain an ordered set of nodes and/or links and/o= r shortest-path-next-hops to be traversed by the packet, rather it will have a set of identifiers specifying resources within a SPRING reg= ion, and these specified resources *are not* limited to =E2=80=9Cnod= es and/or links and/or shortest-path-next-hops=E2=80=9D; they may also incl= ude, for example, forwarding adjacencies and services.=

=C2=A0

I suggest that we strike = the sentence.=C2=A0 As Stefano points out, a charter is not a design specif= ication.

=C2=A0

Yours Irrespectively,<= /u>

=C2=A0

John=

=C2=A0

From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Monday, September 23, 2013 6:13 AM
To: status@ietf= .org


Subject: Re: [Status] Chartering next steps

=C2=A0

I have included the proposed changes and some text t= hat


clarifies the link-node discussion.

The current charter text is at

https://datatracker.ietf.org/doc/charter-ietf-spring/

The diffs are at

htt= ps://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2= Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&s= ubmit=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-i= etf-spring%2Fwithmilestones-00-01.txt

or if you prefer:

http://tinyurl.= com/o24a9lz

The link node text I added was

"Steering is achieved by specifying in the packet an ordered
set of nodes and/or links and/or shortest-path-next-hops
to be traversed by the packet."

- Stewart


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


--047d7b111f3fabe2c304e71092ec-- From rraszuk@gmail.com Mon Sep 23 10:50:36 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90221F8D0B for ; Mon, 23 Sep 2013 10:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpzJPAL0f04Q for ; Mon, 23 Sep 2013 10:50:35 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 45DF221F90AF for ; Mon, 23 Sep 2013 10:50:22 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so6747109ieb.26 for ; Mon, 23 Sep 2013 10:50:22 -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=QhpmYbuQ86zIQ9yAL5ul4mieaw2zOwI+UKZhsUZkGRw=; b=0f8s/BaH/Gt8aLYOH3orJ5GFs5C7qMBh3A++tOG7S1Pnv/a/fSuYihDtdrnmzkYDqF 3QFT2+swQBYuRIX1RAQInD83EBirwoWgFcx5po3rzLskHzIrPYE9R5mfxQ93Ayu4aDx7 mlUu3k9YFUY90NQr9l4Vwy9ZfUGZnSaD3SfvvY2er+K8lhjkbUa/h3MfHdd+qs7ObFX8 xPJbIRGAI1YbmdbnlEJFNct4jVqumiucl+1ZdupviGKwGZ5wAFlpSDx1FEolvz1sOM6n EXi+iiuAtCJtWH0QQPfE1e/fTTQsrScadArOxKmGRyIP6HHDcqmhYKyoDOE8t9aIKWx3 TPGg== MIME-Version: 1.0 X-Received: by 10.43.8.134 with SMTP id os6mr796016icb.107.1379958622421; Mon, 23 Sep 2013 10:50:22 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 23 Sep 2013 10:50:22 -0700 (PDT) In-Reply-To: References: <523C1538.1030701@cisco.com> <523C31A6.50209@pi.nu> <523C41ED.3020102@cisco.com> <523FBD6E.6090004@pi.nu> <52403E57.8060104@cisco.com> Date: Mon, 23 Sep 2013 19:50:22 +0200 X-Google-Sender-Auth: cj_q12kiQiCNw8NmpTNqsZjp8Zg Message-ID: From: Robert Raszuk To: Sriganesh Kini Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: John E Drake , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:50:36 -0000 The observation is that SR may not require explicit-route in all scenarios. I can see cases of loose-routes yet based on segment based routing paradigm. Besides explicit route may be interpreted as hop-by-hop path which is clearly not the case. I would recommend to s/explicit route/defined path/ r. On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini wrote: > From RFC 3031, sec 3.21 > > Explicit routing may be useful for a number of purposes, such as > policy routing or traffic engineering. In MPLS, the explicit route > needs to be specified at the time that labels are assigned, but the > explicit route does not have to be specified with each IP packet. > This makes MPLS explicit routing much more efficient than the > alternative of IP source routing. > > > If the "explicit-route" in SPRING is the same as explicit-route in RFC303= 1 > then we are ruling out source-routing ! IMO we should call it explicit-ro= ute > but re-define it for SPRING. The definition could be "a set of identifier= s > in the packet that allow it to be steered through the network without hav= ing > per flow information at each intermediate node". However this re-definiti= on > need not be in the charter but could go in another document (architecture > document). > > - Sri > > > > On Mon, Sep 23, 2013 at 8:01 AM, John E Drake wrote: >> >> Stewart, >> >> >> >> Upon reflection, I spoke too soon. The use of the term =91explicit rout= e=92 >> as suggested by Lou and myself is fine, but the sentence you added: >> >> >> >> =93Steering is achieved by specifying in the packet an ordered set of no= des >> and/or links and/or shortest-path-next-hops to be traversed by the packe= t.=94 >> >> >> >> has issues. A packet *will not* have contain an ordered set of nodes >> and/or links and/or shortest-path-next-hops to be traversed by the packe= t, >> rather it will have a set of identifiers specifying resources within a >> SPRING region, and these specified resources *are not* limited to =93nod= es >> and/or links and/or shortest-path-next-hops=94; they may also include, f= or >> example, forwarding adjacencies and services. >> >> >> >> I suggest that we strike the sentence. As Stefano points out, a charter >> is not a design specification. >> >> >> >> Yours Irrespectively, >> >> >> >> John >> >> >> >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf >> Of Stewart Bryant >> Sent: Monday, September 23, 2013 6:13 AM >> To: status@ietf.org >> >> >> Subject: Re: [Status] Chartering next steps >> >> >> >> I have included the proposed changes and some text that >> >> >> clarifies the link-node discussion. >> >> The current charter text is at >> >> https://datatracker.ietf.org/doc/charter-ietf-spring/ >> >> The diffs are at >> >> >> https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2= Fdoc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&sub= mit=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-sp= ring%2Fwithmilestones-00-01.txt >> >> or if you prefer: >> >> http://tinyurl.com/o24a9lz >> >> The link node text I added was >> >> "Steering is achieved by specifying in the packet an ordered >> set of nodes and/or links and/or shortest-path-next-hops >> to be traversed by the packet." >> >> - Stewart >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > From sriganesh.kini@ericsson.com Mon Sep 23 11:02:34 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9171221F9FC3 for ; Mon, 23 Sep 2013 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5Pqi+WqmPYY for ; Mon, 23 Sep 2013 11:02:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 16D3421F9F80 for ; Mon, 23 Sep 2013 11:02:22 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-66-5240822deac0 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FF.60.03458.D2280425; Mon, 23 Sep 2013 20:02:22 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 23 Sep 2013 14:02:20 -0400 From: Sriganesh Kini To: Robert Raszuk Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePKJ5S7NF25oEiLN/tcVGzIy5nOwKwAgAATZ4CABCbCAIAAmayAgAAeZICAAC1dgIAAAcQA//+OBYA= Date: Mon, 23 Sep 2013 18:02:19 +0000 Message-ID: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPrK5ek0OQwft9XBZz7jpbNC1sYrZ4 3XyRyeLc0zmMDiweU35vZPVYsuQnk8f1pqvsHrs3LmAKYInisklJzcksSy3St0vgyjj09DVL QYdSxc6fp1gbGC9JdzFyckgImEg8uTmfDcIWk7hwbz2QzcUhJHCUUeLO/i5GCGc5o0RXzyew KjYBI4kLd+ezgNgiAqoSnSceMYPYzALlEvfWd7GC2MIC2hLvprUyQdToSBz7c5cZwk6S2N50 FqyXBah386WzjCA2r4CvxP6/84F6OTg4BQIlLjYogYQZgQ76fmoNE8R4cYlbT+YzQRwqILFk z3lmCFtU4uXjf2BrRQX0JNqOnWGHiCtLLHmynwWi10Di/bn5UGdaS1w4fhVqprbEsoWvmSFO EJQ4OfMJywRG8VlI1s1C0j4LSfssJO2zkLQvYGRdxchRWpxalptuZLiJERh7xyTYHHcwLvhk eYhRmoNFSZx3g96ZQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MMQr5/AFbf7h0turo26vN n/zNiHPv8WsJrnrmQjsish7fDD87y+vk/PVtIRXv0rr2NDskth78dVTwWdf0vfOWvmjmqjpp P3FbbGxqp2+SYujzes7Jb+wZF66U/nim71ZPx3XHzdc5o7cECDHNFjB9fFSoc6vDo04LY6ne xb/3Trr+QvD81x8hSizFGYmGWsxFxYkAgPcC/4sCAAA= Cc: John E Drake , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:02:34 -0000 Robert, MPLS has defined "strict", "loose" and combinations of those in the context of "explicit-routes". SPRING should be able to re-use/re-define it as necessary. Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. I don't see a strong reason for yet another term "defined path". -- Sri On 9/23/13 10:50 AM, "Robert Raszuk" wrote: >The observation is that SR may not require explicit-route in all >scenarios. I can see cases of loose-routes yet based on segment based >routing paradigm. > >Besides explicit route may be interpreted as hop-by-hop path which is >clearly not the case. > >I would recommend to s/explicit route/defined path/ > >r. > > > >On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini > wrote: >> From RFC 3031, sec 3.21 >> >> Explicit routing may be useful for a number of purposes, such as >> policy routing or traffic engineering. In MPLS, the explicit route >> needs to be specified at the time that labels are assigned, but the >> explicit route does not have to be specified with each IP packet. >> This makes MPLS explicit routing much more efficient than the >> alternative of IP source routing. >> >> >> If the "explicit-route" in SPRING is the same as explicit-route in >>RFC3031 >> then we are ruling out source-routing ! IMO we should call it >>explicit-route >> but re-define it for SPRING. The definition could be "a set of >>identifiers >> in the packet that allow it to be steered through the network without >>having >> per flow information at each intermediate node". However this >>re-definition >> need not be in the charter but could go in another document >>(architecture >> document). >> >> - Sri >> >> >> >> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake >>wrote: >>> >>> Stewart, >>> >>> >>> >>> Upon reflection, I spoke too soon. The use of the term =8Cexplicit >>>route=B9 >>> as suggested by Lou and myself is fine, but the sentence you added: >>> >>> >>> >>> =B3Steering is achieved by specifying in the packet an ordered set of >>>nodes >>> and/or links and/or shortest-path-next-hops to be traversed by the >>>packet.=B2 >>> >>> >>> >>> has issues. A packet *will not* have contain an ordered set of nodes >>> and/or links and/or shortest-path-next-hops to be traversed by the >>>packet, >>> rather it will have a set of identifiers specifying resources within a >>> SPRING region, and these specified resources *are not* limited to >>>=B3nodes >>> and/or links and/or shortest-path-next-hops=B2; they may also include, >>>for >>> example, forwarding adjacencies and services. >>> >>> >>> >>> I suggest that we strike the sentence. As Stefano points out, a >>>charter >>> is not a design specification. >>> >>> >>> >>> Yours Irrespectively, >>> >>> >>> >>> John >>> >>> >>> >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>Behalf >>> Of Stewart Bryant >>> Sent: Monday, September 23, 2013 6:13 AM >>> To: status@ietf.org >>> >>> >>> Subject: Re: [Status] Chartering next steps >>> >>> >>> >>> I have included the proposed changes and some text that >>> >>> >>> clarifies the link-node discussion. >>> >>> The current charter text is at >>> >>> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>> >>> The diffs are at >>> >>> >>>=20 >>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2= Fd >>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&su= bm >>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-= spri >>>ng%2Fwithmilestones-00-01.txt >>> >>> or if you prefer: >>> >>> http://tinyurl.com/o24a9lz >>> >>> The link node text I added was >>> >>> "Steering is achieved by specifying in the packet an ordered >>> set of nodes and/or links and/or shortest-path-next-hops >>> to be traversed by the packet." >>> >>> - Stewart >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> >> >> >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >> From rraszuk@gmail.com Mon Sep 23 11:04:39 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BA121F9FA7 for ; Mon, 23 Sep 2013 11:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3p0KDR29Qqt for ; Mon, 23 Sep 2013 11:04:38 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36821F9F0E for ; Mon, 23 Sep 2013 11:04:38 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so7187487iec.16 for ; Mon, 23 Sep 2013 11:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JRPjKRf1cdDSklA9c+tu6fTIAFrj9959fdp1SOHjPKs=; b=Kadq+mvSj0Vw2nskfH8eA8yCZ6lPvSiupvV//3IROpAjvfARdJ2Jg89EZU8EW3KuG6 rF4DBfQXP36uZuGFu3+nBWWg19Zwq737nB4po2v/TmbJkkME3OEGKR3TG1bGBMmpqoFN jxvpUkiT924K08Gy3eiIWU+VQKyTnv81LEB3R/dreSUpxr74B7cswhAiU2bE9wQVlzW7 SSUQQ4qtgchETiUjub3YDS21T/LNLEZjNP1NJz2XOQaV44amGUAVwMWUxzAzv66MV+G8 lQJvBo69fhjxjo6mcva6xyFtGg3ddwTT7CApgKQ1VZ5kYgT0l+mwoN+nPVvOChNFLGoU QaIA== MIME-Version: 1.0 X-Received: by 10.43.57.7 with SMTP id we7mr891338icb.105.1379959477854; Mon, 23 Sep 2013 11:04:37 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 23 Sep 2013 11:04:37 -0700 (PDT) In-Reply-To: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> Date: Mon, 23 Sep 2013 20:04:37 +0200 X-Google-Sender-Auth: bW6gs9wJRFgZhwnVOz8slqNMDgE Message-ID: From: Robert Raszuk To: Sriganesh Kini Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: John E Drake , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:04:39 -0000 But SPRING is not only about MPLS encapsulation .. r. On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini wrote: > Robert, > > MPLS has defined "strict", "loose" and combinations of those in the > context of "explicit-routes". SPRING should be able to re-use/re-define i= t > as necessary. > > Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. > > I don't see a strong reason for yet another term "defined path". > > -- Sri > > > > > > > On 9/23/13 10:50 AM, "Robert Raszuk" wrote: > >>The observation is that SR may not require explicit-route in all >>scenarios. I can see cases of loose-routes yet based on segment based >>routing paradigm. >> >>Besides explicit route may be interpreted as hop-by-hop path which is >>clearly not the case. >> >>I would recommend to s/explicit route/defined path/ >> >>r. >> >> >> >>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini >> wrote: >>> From RFC 3031, sec 3.21 >>> >>> Explicit routing may be useful for a number of purposes, such as >>> policy routing or traffic engineering. In MPLS, the explicit route >>> needs to be specified at the time that labels are assigned, but the >>> explicit route does not have to be specified with each IP packet. >>> This makes MPLS explicit routing much more efficient than the >>> alternative of IP source routing. >>> >>> >>> If the "explicit-route" in SPRING is the same as explicit-route in >>>RFC3031 >>> then we are ruling out source-routing ! IMO we should call it >>>explicit-route >>> but re-define it for SPRING. The definition could be "a set of >>>identifiers >>> in the packet that allow it to be steered through the network without >>>having >>> per flow information at each intermediate node". However this >>>re-definition >>> need not be in the charter but could go in another document >>>(architecture >>> document). >>> >>> - Sri >>> >>> >>> >>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake >>>wrote: >>>> >>>> Stewart, >>>> >>>> >>>> >>>> Upon reflection, I spoke too soon. The use of the term =8Cexplicit >>>>route=B9 >>>> as suggested by Lou and myself is fine, but the sentence you added: >>>> >>>> >>>> >>>> =B3Steering is achieved by specifying in the packet an ordered set of >>>>nodes >>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>packet.=B2 >>>> >>>> >>>> >>>> has issues. A packet *will not* have contain an ordered set of nodes >>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>packet, >>>> rather it will have a set of identifiers specifying resources within a >>>> SPRING region, and these specified resources *are not* limited to >>>>=B3nodes >>>> and/or links and/or shortest-path-next-hops=B2; they may also include, >>>>for >>>> example, forwarding adjacencies and services. >>>> >>>> >>>> >>>> I suggest that we strike the sentence. As Stefano points out, a >>>>charter >>>> is not a design specification. >>>> >>>> >>>> >>>> Yours Irrespectively, >>>> >>>> >>>> >>>> John >>>> >>>> >>>> >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>Behalf >>>> Of Stewart Bryant >>>> Sent: Monday, September 23, 2013 6:13 AM >>>> To: status@ietf.org >>>> >>>> >>>> Subject: Re: [Status] Chartering next steps >>>> >>>> >>>> >>>> I have included the proposed changes and some text that >>>> >>>> >>>> clarifies the link-node discussion. >>>> >>>> The current charter text is at >>>> >>>> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>>> >>>> The diffs are at >>>> >>>> >>>> >>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%= 2Fd >>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&s= ubm >>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf= -spri >>>>ng%2Fwithmilestones-00-01.txt >>>> >>>> or if you prefer: >>>> >>>> http://tinyurl.com/o24a9lz >>>> >>>> The link node text I added was >>>> >>>> "Steering is achieved by specifying in the packet an ordered >>>> set of nodes and/or links and/or shortest-path-next-hops >>>> to be traversed by the packet." >>>> >>>> - Stewart >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >>> >>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>> > From jeff.tantsura@ericsson.com Mon Sep 23 11:05:50 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89821F9CC8 for ; Mon, 23 Sep 2013 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5MvnSIVFumd for ; Mon, 23 Sep 2013 11:05:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0119621F9301 for ; Mon, 23 Sep 2013 11:05:34 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-5a-524082ee05dd Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 64.A0.03458.EE280425; Mon, 23 Sep 2013 20:05:34 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 23 Sep 2013 14:05:24 -0400 From: Jeff Tantsura To: Sriganesh Kini , Robert Raszuk Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePKGu5/T5ET3kWR+370ZmZD15nOwKwAgAATZ4CABCbCAIAAmayAgAAeZICAAC1dgIAAAcQAgAADV4D//4uFgA== Date: Mon, 23 Sep 2013 18:05:24 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> In-Reply-To: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-ID: <5B482BB7ECF7B34B96BBEBE5A2F6806C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPt+67Jocgg019uhZz7jpbNC1sYrZ4 3XyRyeLc0zmMDiweU35vZPVYsuQnk8f1pqvsHrs3LmAKYInisklJzcksSy3St0vgyth7/hxb wRGzitWLVjM3ME4w7WLk5JAQMJH4sXk6I4QtJnHh3nq2LkYuDiGBo4wSN96vYYFwljNKnPz+ mAmkik3AQOL/t+MsILaIQKjEkwlHwOLMAuUS99Z3sYLYwgLaEu+mtTJB1OhIHPtzlxnCzpI4 uauLHcRmEVCVmLH5Llg9r4C3RMuZQ2wgNqeAn8Tro0fBbEagi76fWgM1X1zi1pP5TBCXCkgs 2XOeGcIWlXj5+B/YHFEBPYm2Y2fYIeLKEkue7Ae6kwOoV1Ni/S59iDHWEkemXmeBsBUlpnQ/ ZIc4QVDi5MwnLBMYxWch2TYLoXsWku5ZSLpnIelewMi6ipGjtDi1LDfdyHATIzDyjkmwOe5g XPDJ8hCjNAeLkjjvBr0zgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYPZ0Nbn2sn23evF/w q/QZ/z1WU7dHfH9ScCPUN+2T06mO9ZJMBXNCuv+kHK/hmLpyx9+IBT+7bM7nu8wTrmyd1sqb c3pKU531gke/GQQLr/YdP8N4gGFX8emJX+qdLr+63PXkrpeLxpvljrPLXtWtNn6mUPHlk2f4 JwaxXxsfn6jev0C+dtGLIiWW4oxEQy3mouJEAJt4XXiKAgAA Cc: John E Drake , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:05:51 -0000 QWdyZWUgd2l0aCBTcmkuDQpTdHJpY3QgYW5kIGxvb3NlIGV4cGxpY2l0IHJvdXRlcyBkZWZpbmUg cHJldHR5IHdlbGwgd2hhdCBTUFJJTkcgZG9lcw0KDQpDaGVlcnMsDQpKZWZmDQoNCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmlnYW5lc2ggS2luaSA8c3JpZ2FuZXNo LmtpbmlAZXJpY3Nzb24uY29tPg0KRGF0ZTogTW9uZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMTMgMTE6 MDIgQU0NClRvOiAicm9iZXJ0QHJhc3p1ay5uZXQiIDxyb2JlcnRAcmFzenVrLm5ldD4NCkNjOiBK b2huIERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+LCAic3RhdHVzQGlldGYub3JnIiA8c3RhdHVz QGlldGYub3JnPiwNCiJzdGJyeWFudEBjaXNjby5jb20iIDxzdGJyeWFudEBjaXNjby5jb20+DQpT dWJqZWN0OiBSZTogW1N0YXR1c10gQ2hhcnRlcmluZyBuZXh0IHN0ZXBzDQoNCj5Sb2JlcnQsDQo+ DQo+TVBMUyBoYXMgZGVmaW5lZCAic3RyaWN0IiwgImxvb3NlIiBhbmQgY29tYmluYXRpb25zIG9m IHRob3NlIGluIHRoZQ0KPmNvbnRleHQgb2YgImV4cGxpY2l0LXJvdXRlcyIuIFNQUklORyBzaG91 bGQgYmUgYWJsZSB0byByZS11c2UvcmUtZGVmaW5lIGl0DQo+YXMgbmVjZXNzYXJ5Lg0KPg0KPklu dGVycHJldGluZyAiZXhwbGljaXQtcm91dGUiIGFzICJob3AtYnktaG9wIiBzZWVtcyBsaWtlIGEg c3RyZXRjaC4NCj4NCj5JIGRvbid0IHNlZSBhIHN0cm9uZyByZWFzb24gZm9yIHlldCBhbm90aGVy IHRlcm0gImRlZmluZWQgcGF0aCIuDQo+DQo+LS0gU3JpDQo+DQo+DQo+DQo+DQo+DQo+DQo+T24g OS8yMy8xMyAxMDo1MCBBTSwgIlJvYmVydCBSYXN6dWsiIDxyb2JlcnRAcmFzenVrLm5ldD4gd3Jv dGU6DQo+DQo+PlRoZSBvYnNlcnZhdGlvbiBpcyB0aGF0IFNSIG1heSBub3QgcmVxdWlyZSBleHBs aWNpdC1yb3V0ZSBpbiBhbGwNCj4+c2NlbmFyaW9zLiBJIGNhbiBzZWUgY2FzZXMgb2YgbG9vc2Ut cm91dGVzIHlldCBiYXNlZCBvbiBzZWdtZW50IGJhc2VkDQo+PnJvdXRpbmcgcGFyYWRpZ20uDQo+ Pg0KPj5CZXNpZGVzIGV4cGxpY2l0IHJvdXRlIG1heSBiZSBpbnRlcnByZXRlZCBhcyBob3AtYnkt aG9wIHBhdGggd2hpY2ggaXMNCj4+Y2xlYXJseSBub3QgdGhlIGNhc2UuDQo+Pg0KPj5JIHdvdWxk IHJlY29tbWVuZCB0byBzL2V4cGxpY2l0IHJvdXRlL2RlZmluZWQgcGF0aC8NCj4+DQo+PnIuDQo+ Pg0KPj4NCj4+DQo+Pk9uIE1vbiwgU2VwIDIzLCAyMDEzIGF0IDc6NDQgUE0sIFNyaWdhbmVzaCBL aW5pDQo+PjxzcmlnYW5lc2gua2luaUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+IEZyb20gUkZD IDMwMzEsIHNlYyAzLjIxDQo+Pj4NCj4+PiAgICBFeHBsaWNpdCByb3V0aW5nIG1heSBiZSB1c2Vm dWwgZm9yIGEgbnVtYmVyIG9mIHB1cnBvc2VzLCBzdWNoIGFzDQo+Pj4gICAgcG9saWN5IHJvdXRp bmcgb3IgdHJhZmZpYyBlbmdpbmVlcmluZy4gIEluIE1QTFMsIHRoZSBleHBsaWNpdCByb3V0ZQ0K Pj4+ICAgIG5lZWRzIHRvIGJlIHNwZWNpZmllZCBhdCB0aGUgdGltZSB0aGF0IGxhYmVscyBhcmUg YXNzaWduZWQsIGJ1dCB0aGUNCj4+PiAgICBleHBsaWNpdCByb3V0ZSBkb2VzIG5vdCBoYXZlIHRv IGJlIHNwZWNpZmllZCB3aXRoIGVhY2ggSVAgcGFja2V0Lg0KPj4+ICAgIFRoaXMgbWFrZXMgTVBM UyBleHBsaWNpdCByb3V0aW5nIG11Y2ggbW9yZSBlZmZpY2llbnQgdGhhbiB0aGUNCj4+PiAgICBh bHRlcm5hdGl2ZSBvZiBJUCBzb3VyY2Ugcm91dGluZy4NCj4+Pg0KPj4+DQo+Pj4gSWYgdGhlICJl eHBsaWNpdC1yb3V0ZSIgaW4gU1BSSU5HIGlzIHRoZSBzYW1lIGFzIGV4cGxpY2l0LXJvdXRlIGlu DQo+Pj5SRkMzMDMxDQo+Pj4gdGhlbiB3ZSBhcmUgcnVsaW5nIG91dCBzb3VyY2Utcm91dGluZyAh IElNTyB3ZSBzaG91bGQgY2FsbCBpdA0KPj4+ZXhwbGljaXQtcm91dGUNCj4+PiBidXQgcmUtZGVm aW5lIGl0IGZvciBTUFJJTkcuIFRoZSBkZWZpbml0aW9uIGNvdWxkIGJlICJhIHNldCBvZg0KPj4+ aWRlbnRpZmllcnMNCj4+PiBpbiB0aGUgcGFja2V0IHRoYXQgYWxsb3cgaXQgdG8gYmUgc3RlZXJl ZCB0aHJvdWdoIHRoZSBuZXR3b3JrIHdpdGhvdXQNCj4+PmhhdmluZw0KPj4+IHBlciBmbG93IGlu Zm9ybWF0aW9uIGF0IGVhY2ggaW50ZXJtZWRpYXRlIG5vZGUiLiBIb3dldmVyIHRoaXMNCj4+PnJl LWRlZmluaXRpb24NCj4+PiBuZWVkIG5vdCBiZSBpbiB0aGUgY2hhcnRlciBidXQgY291bGQgZ28g aW4gYW5vdGhlciBkb2N1bWVudA0KPj4+KGFyY2hpdGVjdHVyZQ0KPj4+IGRvY3VtZW50KS4NCj4+ Pg0KPj4+IC0gU3JpDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gTW9uLCBTZXAgMjMsIDIwMTMgYXQg ODowMSBBTSwgSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+DQo+Pj53cm90ZToNCj4+ Pj4NCj4+Pj4gU3Rld2FydCwNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVXBvbiByZWZsZWN0aW9u LCBJIHNwb2tlIHRvbyBzb29uLiAgVGhlIHVzZSBvZiB0aGUgdGVybSDFkmV4cGxpY2l0DQo+Pj4+ cm91dGXCuQ0KPj4+PiBhcyBzdWdnZXN0ZWQgYnkgTG91IGFuZCBteXNlbGYgaXMgZmluZSwgYnV0 IHRoZSBzZW50ZW5jZSB5b3UgYWRkZWQ6DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IMKzU3RlZXJp bmcgaXMgYWNoaWV2ZWQgYnkgc3BlY2lmeWluZyBpbiB0aGUgcGFja2V0IGFuIG9yZGVyZWQgc2V0 IG9mDQo+Pj4+bm9kZXMNCj4+Pj4gYW5kL29yIGxpbmtzIGFuZC9vciBzaG9ydGVzdC1wYXRoLW5l eHQtaG9wcyB0byBiZSB0cmF2ZXJzZWQgYnkgdGhlDQo+Pj4+cGFja2V0LsKyDQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+IGhhcyBpc3N1ZXMuICBBIHBhY2tldCAqd2lsbCBub3QqIGhhdmUgY29udGFp biBhbiBvcmRlcmVkIHNldCBvZiBub2Rlcw0KPj4+PiBhbmQvb3IgbGlua3MgYW5kL29yIHNob3J0 ZXN0LXBhdGgtbmV4dC1ob3BzIHRvIGJlIHRyYXZlcnNlZCBieSB0aGUNCj4+Pj5wYWNrZXQsDQo+ Pj4+IHJhdGhlciBpdCB3aWxsIGhhdmUgYSBzZXQgb2YgaWRlbnRpZmllcnMgc3BlY2lmeWluZyBy ZXNvdXJjZXMgd2l0aGluIGENCj4+Pj4gU1BSSU5HIHJlZ2lvbiwgYW5kIHRoZXNlIHNwZWNpZmll ZCByZXNvdXJjZXMgKmFyZSBub3QqIGxpbWl0ZWQgdG8NCj4+Pj7Cs25vZGVzDQo+Pj4+IGFuZC9v ciBsaW5rcyBhbmQvb3Igc2hvcnRlc3QtcGF0aC1uZXh0LWhvcHPCsjsgdGhleSBtYXkgYWxzbyBp bmNsdWRlLA0KPj4+PmZvcg0KPj4+PiBleGFtcGxlLCBmb3J3YXJkaW5nIGFkamFjZW5jaWVzIGFu ZCBzZXJ2aWNlcy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gSSBzdWdnZXN0IHRoYXQgd2Ugc3Ry aWtlIHRoZSBzZW50ZW5jZS4gIEFzIFN0ZWZhbm8gcG9pbnRzIG91dCwgYQ0KPj4+PmNoYXJ0ZXIN Cj4+Pj4gaXMgbm90IGEgZGVzaWduIHNwZWNpZmljYXRpb24uDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+ Pj4+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBKb2huDQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEZyb206IHN0YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+Pj4+QmVoYWxmDQo+Pj4+IE9mIFN0ZXdh cnQgQnJ5YW50DQo+Pj4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIzLCAyMDEzIDY6MTMgQU0N Cj4+Pj4gVG86IHN0YXR1c0BpZXRmLm9yZw0KPj4+Pg0KPj4+Pg0KPj4+PiBTdWJqZWN0OiBSZTog W1N0YXR1c10gQ2hhcnRlcmluZyBuZXh0IHN0ZXBzDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IEkg aGF2ZSBpbmNsdWRlZCB0aGUgcHJvcG9zZWQgY2hhbmdlcyBhbmQgc29tZSB0ZXh0IHRoYXQNCj4+ Pj4NCj4+Pj4NCj4+Pj4gY2xhcmlmaWVzIHRoZSBsaW5rLW5vZGUgZGlzY3Vzc2lvbi4NCj4+Pj4N Cj4+Pj4gVGhlIGN1cnJlbnQgY2hhcnRlciB0ZXh0IGlzIGF0DQo+Pj4+DQo+Pj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zcHJpbmcvDQo+Pj4+DQo+Pj4+ IFRoZSBkaWZmcyBhcmUgYXQNCj4+Pj4NCj4+Pj4NCj4+Pj4gDQo+Pj4+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwxPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkYN Cj4+Pj5kDQo+Pj4+b2MlMkZjaGFydGVyLWlldGYtc3ByaW5nJTJGd2l0aG1pbGVzdG9uZXMtMDAt MDAudHh0JmRpZmZ0eXBlPS0taHRtbCZzdWINCj4+Pj5tDQo+Pj4+aXQ9R28hJnVybDI9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmNoYXJ0ZXItaWV0Zi1zcHINCj4+ Pj5pDQo+Pj4+bmclMkZ3aXRobWlsZXN0b25lcy0wMC0wMS50eHQNCj4+Pj4NCj4+Pj4gb3IgaWYg eW91IHByZWZlcjoNCj4+Pj4NCj4+Pj4gaHR0cDovL3Rpbnl1cmwuY29tL28yNGE5bHoNCj4+Pj4N Cj4+Pj4gVGhlIGxpbmsgbm9kZSB0ZXh0IEkgYWRkZWQgd2FzDQo+Pj4+DQo+Pj4+ICJTdGVlcmlu ZyBpcyBhY2hpZXZlZCBieSBzcGVjaWZ5aW5nIGluIHRoZSBwYWNrZXQgYW4gb3JkZXJlZA0KPj4+ PiBzZXQgb2Ygbm9kZXMgYW5kL29yIGxpbmtzIGFuZC9vciBzaG9ydGVzdC1wYXRoLW5leHQtaG9w cw0KPj4+PiB0byBiZSB0cmF2ZXJzZWQgYnkgdGhlIHBhY2tldC4iDQo+Pj4+DQo+Pj4+IC0gU3Rl d2FydA0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+PiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+Pj4+IHN0YXR1c0BpZXRm Lm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0K Pj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IHN0YXR1cyBtYWlsaW5nIGxpc3QNCj4+PiBzdGF0dXNAaWV0Zi5vcmcN Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KPj4+DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zdGF0 dXMgbWFpbGluZyBsaXN0DQo+c3RhdHVzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCg0K From lberger@labn.net Mon Sep 23 11:08:14 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBEF21F9FED for ; Mon, 23 Sep 2013 11:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pdgM2IpBm3b for ; Mon, 23 Sep 2013 11:08:09 -0700 (PDT) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id D661221F9D42 for ; Mon, 23 Sep 2013 11:08:08 -0700 (PDT) Received: (qmail 13377 invoked by uid 0); 23 Sep 2013 18:07:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 23 Sep 2013 18:07:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ToPcKIEtdV0VS9Iz+2z4rOgyVMGBXB/LcXAtGunal/0=; b=lxYDcwDZ27Nwc1d04elLaSjV1Qg8MIKRpKKlqoVy/G51FR/wn5jbwPdoioZCJqYQSCT3ep0QCC0lOecTEHOeleAu9pMdd0xGCWogeupvbGAKjcQy5ybeJ0bw4ZyT+xf5; Received: from box313.bluehost.com ([69.89.31.113]:45620 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VOAXw-000512-Jc; Mon, 23 Sep 2013 12:07:44 -0600 Message-ID: <5240836F.3050102@labn.net> Date: Mon, 23 Sep 2013 14:07:43 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Robert Raszuk , Sriganesh Kini References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: John E Drake , "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:08:14 -0000 Right. And RFC3031 isn't listed in the charter. So I agree with Sri. Lou On 09/23/2013 02:04 PM, Robert Raszuk wrote: > But SPRING is not only about MPLS encapsulation .. > > r. > > On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini > wrote: >> Robert, >> >> MPLS has defined "strict", "loose" and combinations of those in the >> context of "explicit-routes". SPRING should be able to re-use/re-define it >> as necessary. >> >> Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. >> >> I don't see a strong reason for yet another term "defined path". >> >> -- Sri >> >> >> >> >> >> >> On 9/23/13 10:50 AM, "Robert Raszuk" wrote: >> >>> The observation is that SR may not require explicit-route in all >>> scenarios. I can see cases of loose-routes yet based on segment based >>> routing paradigm. >>> >>> Besides explicit route may be interpreted as hop-by-hop path which is >>> clearly not the case. >>> >>> I would recommend to s/explicit route/defined path/ >>> >>> r. >>> >>> >>> >>> On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini >>> wrote: >>>> From RFC 3031, sec 3.21 >>>> >>>> Explicit routing may be useful for a number of purposes, such as >>>> policy routing or traffic engineering. In MPLS, the explicit route >>>> needs to be specified at the time that labels are assigned, but the >>>> explicit route does not have to be specified with each IP packet. >>>> This makes MPLS explicit routing much more efficient than the >>>> alternative of IP source routing. >>>> >>>> >>>> If the "explicit-route" in SPRING is the same as explicit-route in >>>> RFC3031 >>>> then we are ruling out source-routing ! IMO we should call it >>>> explicit-route >>>> but re-define it for SPRING. The definition could be "a set of >>>> identifiers >>>> in the packet that allow it to be steered through the network without >>>> having >>>> per flow information at each intermediate node". However this >>>> re-definition >>>> need not be in the charter but could go in another document >>>> (architecture >>>> document). >>>> >>>> - Sri >>>> >>>> >>>> >>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake >>>> wrote: >>>>> >>>>> Stewart, >>>>> >>>>> >>>>> >>>>> Upon reflection, I spoke too soon. The use of the term Œexplicit >>>>> route¹ >>>>> as suggested by Lou and myself is fine, but the sentence you added: >>>>> >>>>> >>>>> >>>>> ³Steering is achieved by specifying in the packet an ordered set of >>>>> nodes >>>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>> packet.² >>>>> >>>>> >>>>> >>>>> has issues. A packet *will not* have contain an ordered set of nodes >>>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>> packet, >>>>> rather it will have a set of identifiers specifying resources within a >>>>> SPRING region, and these specified resources *are not* limited to >>>>> ³nodes >>>>> and/or links and/or shortest-path-next-hops²; they may also include, >>>>> for >>>>> example, forwarding adjacencies and services. >>>>> >>>>> >>>>> >>>>> I suggest that we strike the sentence. As Stefano points out, a >>>>> charter >>>>> is not a design specification. >>>>> >>>>> >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>> Behalf >>>>> Of Stewart Bryant >>>>> Sent: Monday, September 23, 2013 6:13 AM >>>>> To: status@ietf.org >>>>> >>>>> >>>>> Subject: Re: [Status] Chartering next steps >>>>> >>>>> >>>>> >>>>> I have included the proposed changes and some text that >>>>> >>>>> >>>>> clarifies the link-node discussion. >>>>> >>>>> The current charter text is at >>>>> >>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>>>> >>>>> The diffs are at >>>>> >>>>> >>>>> >>>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fd >>>>> oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&subm >>>>> it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spri >>>>> ng%2Fwithmilestones-00-01.txt >>>>> >>>>> or if you prefer: >>>>> >>>>> http://tinyurl.com/o24a9lz >>>>> >>>>> The link node text I added was >>>>> >>>>> "Steering is achieved by specifying in the packet an ordered >>>>> set of nodes and/or links and/or shortest-path-next-hops >>>>> to be traversed by the packet." >>>>> >>>>> - Stewart >>>>> >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >> > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > From rraszuk@gmail.com Mon Sep 23 11:08:48 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3973C21F9D04 for ; Mon, 23 Sep 2013 11:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu2lj+Cmu18P for ; Mon, 23 Sep 2013 11:08:47 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DD27D21F9FE5 for ; Mon, 23 Sep 2013 11:08:45 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so6860212iej.24 for ; Mon, 23 Sep 2013 11:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LgmXgAXW7Lo/shuPM2n2x2ofH4cgYMjQXk1QMLbrPok=; b=FJHnnCr1N4xOJxVYEH9EUBi6YJA6XzRfA2lbI1ciKLnTJfSBXa4eQR7MD2cOPqh5VY 1WJ4rDQdTClvKIrZuo24gkF+31zUQD/rWFzWbcGLIFGtHZ6DRb72zaJ9YOltVz73LLWi 1Cgo/lygThwc+rCjKY1FQSePe2foGdySD7utOrOMFA5sBUUYlI1VKkZWuoDZTF0Kc+Xi JeCdlLF3gX4zYnNYUK/sXlpdMvL4TOL34+YxlVXGmp4Xnpl06eXZt2CYdaR0XqDcZSAv 0DbMi1jOp7F3tmvr9ofDTNvOwz0Lky9Yv3bAAV4zRpg+7O8cvYVe/4+1rxRIHQZNKjd0 5eWw== MIME-Version: 1.0 X-Received: by 10.43.169.130 with SMTP id nm2mr1774948icc.61.1379959725272; Mon, 23 Sep 2013 11:08:45 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 23 Sep 2013 11:08:45 -0700 (PDT) In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> Date: Mon, 23 Sep 2013 20:08:45 +0200 X-Google-Sender-Auth: isVkBCv9FU8-Hn55FyEFP6qQTGw Message-ID: From: Robert Raszuk To: Jeff Tantsura Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: John E Drake , "stbryant@cisco.com" , "status@ietf.org" , Sriganesh Kini Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:08:48 -0000 Hi Jeff, If I want to use SPRING to get rid of LDP between my ingress and egress PEs what is my "explicit-route" in that case ? r. On Mon, Sep 23, 2013 at 8:05 PM, Jeff Tantsura wrote: > Agree with Sri. > Strict and loose explicit routes define pretty well what SPRING does > > Cheers, > Jeff > > > > > -----Original Message----- > From: Sriganesh Kini > Date: Monday, September 23, 2013 11:02 AM > To: "robert@raszuk.net" > Cc: John Drake , "status@ietf.org" , > "stbryant@cisco.com" > Subject: Re: [Status] Chartering next steps > >>Robert, >> >>MPLS has defined "strict", "loose" and combinations of those in the >>context of "explicit-routes". SPRING should be able to re-use/re-define i= t >>as necessary. >> >>Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. >> >>I don't see a strong reason for yet another term "defined path". >> >>-- Sri >> >> >> >> >> >> >>On 9/23/13 10:50 AM, "Robert Raszuk" wrote: >> >>>The observation is that SR may not require explicit-route in all >>>scenarios. I can see cases of loose-routes yet based on segment based >>>routing paradigm. >>> >>>Besides explicit route may be interpreted as hop-by-hop path which is >>>clearly not the case. >>> >>>I would recommend to s/explicit route/defined path/ >>> >>>r. >>> >>> >>> >>>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini >>> wrote: >>>> From RFC 3031, sec 3.21 >>>> >>>> Explicit routing may be useful for a number of purposes, such as >>>> policy routing or traffic engineering. In MPLS, the explicit route >>>> needs to be specified at the time that labels are assigned, but the >>>> explicit route does not have to be specified with each IP packet. >>>> This makes MPLS explicit routing much more efficient than the >>>> alternative of IP source routing. >>>> >>>> >>>> If the "explicit-route" in SPRING is the same as explicit-route in >>>>RFC3031 >>>> then we are ruling out source-routing ! IMO we should call it >>>>explicit-route >>>> but re-define it for SPRING. The definition could be "a set of >>>>identifiers >>>> in the packet that allow it to be steered through the network without >>>>having >>>> per flow information at each intermediate node". However this >>>>re-definition >>>> need not be in the charter but could go in another document >>>>(architecture >>>> document). >>>> >>>> - Sri >>>> >>>> >>>> >>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake >>>>wrote: >>>>> >>>>> Stewart, >>>>> >>>>> >>>>> >>>>> Upon reflection, I spoke too soon. The use of the term =8Cexplicit >>>>>route=B9 >>>>> as suggested by Lou and myself is fine, but the sentence you added: >>>>> >>>>> >>>>> >>>>> =B3Steering is achieved by specifying in the packet an ordered set of >>>>>nodes >>>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>>packet.=B2 >>>>> >>>>> >>>>> >>>>> has issues. A packet *will not* have contain an ordered set of nodes >>>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>>packet, >>>>> rather it will have a set of identifiers specifying resources within = a >>>>> SPRING region, and these specified resources *are not* limited to >>>>>=B3nodes >>>>> and/or links and/or shortest-path-next-hops=B2; they may also include= , >>>>>for >>>>> example, forwarding adjacencies and services. >>>>> >>>>> >>>>> >>>>> I suggest that we strike the sentence. As Stefano points out, a >>>>>charter >>>>> is not a design specification. >>>>> >>>>> >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>Behalf >>>>> Of Stewart Bryant >>>>> Sent: Monday, September 23, 2013 6:13 AM >>>>> To: status@ietf.org >>>>> >>>>> >>>>> Subject: Re: [Status] Chartering next steps >>>>> >>>>> >>>>> >>>>> I have included the proposed changes and some text that >>>>> >>>>> >>>>> clarifies the link-node discussion. >>>>> >>>>> The current charter text is at >>>>> >>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>>>> >>>>> The diffs are at >>>>> >>>>> >>>>> >>>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org= %2F >>>>>d >>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D--html&= sub >>>>>m >>>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-iet= f-spr >>>>>i >>>>>ng%2Fwithmilestones-00-01.txt >>>>> >>>>> or if you prefer: >>>>> >>>>> http://tinyurl.com/o24a9lz >>>>> >>>>> The link node text I added was >>>>> >>>>> "Steering is achieved by specifying in the packet an ordered >>>>> set of nodes and/or links and/or shortest-path-next-hops >>>>> to be traversed by the packet." >>>>> >>>>> - Stewart >>>>> >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>>> >>>> >>>> _______________________________________________ >>>> status mailing list >>>> status@ietf.org >>>> https://www.ietf.org/mailman/listinfo/status >>>> >> >>_______________________________________________ >>status mailing list >>status@ietf.org >>https://www.ietf.org/mailman/listinfo/status > From jeff.tantsura@ericsson.com Mon Sep 23 11:29:29 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1574921F9A6D for ; Mon, 23 Sep 2013 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQS0NJcf9mgT for ; Mon, 23 Sep 2013 11:29:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D8D4321F9A4A for ; Mon, 23 Sep 2013 11:29:11 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-f1-524088737ea9 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.43.09414.37880425; Mon, 23 Sep 2013 20:29:07 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Mon, 23 Sep 2013 14:28:39 -0400 From: Jeff Tantsura To: Robert Raszuk Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePKGu5/T5ET3kWR+370ZmZD15nOwKwAgAATZ4CABCbCAIAAmayAgAAeZICAAC1dgIAAAcQAgAADV4D//4uFgIAAdkeA//+QNIA= Date: Mon, 23 Sep 2013 18:28:38 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839934C9F@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPoG5xh0OQwY7P4hZz7jpbNC1sYrZ4 3XyRyeLc0zmMDiweU35vZPVYsuQnk8f1pqvsHrs3LmAKYInisklJzcksSy3St0vgymh6/IOt 4I1TxdHD+5gaGCc4djFyckgImEh82befCcIWk7hwbz0biC0kcJRR4tde6S5GLiB7OaPEuRvd 7CAJNgEDif/fjrOA2CICqhKdJx4xg9jMIEWLD6eC2MIC2hLvprUyQdToSBz7c5cZwi6TaHg1 G2wOC1DvgUWvwGp4BbwlDvWdYwWxOQUCJS5sbQebzwh00PdTa5gg5otL3HoyH+pQAYkle84z Q9iiEi8f/wPrFRXQk2g7doYdIq4sseTJfqA5HEC9mhLrd+lDjLGWuPBvAdRIRYkp3Q/ZIU4Q lDg58wnLBEbxWUi2zULonoWkexaS7llIuhcwsq5i5CgtTi3LTTcy2MQIjLtjEmy6Oxj3vLQ8 xCjNwaIkzrtK70ygkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZOFYF5Cun7N+V77X/899XD 0B3m3c4rtNmWMDb8Khfjn+zt/ilbLj5padpbx+aV6z3N7euSbL6mlSUYWr+KLOz8/O2D2MyS Gz2GX9/M0upQcL0l/FN5cua+Cs03dTdbpxrmXNCTSfZbek/vreu7+SZrTs5LOB5dZLx17gH9 5SpSO0Nmn2mLv6fEUpyRaKjFXFScCAAVWO2GiQIAAA== Cc: John E Drake , "stbryant@cisco.com" , "status@ietf.org" , Sriganesh Kini Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:29:29 -0000 SGkgUm9iZXJ0LA0KDQpMaXN0IG9mIE5vZGUtU0lEJ3MgKGxvb3NlKSwgQWRqLVNJRCdzIG9wdGlv bmFsbHkgKHN0cmljdCkNCg0KQ2hlZXJzLA0KSmVmZg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogInJvYmVydEByYXN6dWsubmV0IiA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQpEYXRl OiBNb25kYXksIFNlcHRlbWJlciAyMywgMjAxMyAxMTowOCBBTQ0KVG86IEplZmYgVGFudHN1cmEg PGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPg0KQ2M6IFNyaWdhbmVzaCBLaW5pIDxzcmlnYW5l c2gua2luaUBlcmljc3Nvbi5jb20+LCBKb2huIERyYWtlDQo8amRyYWtlQGp1bmlwZXIubmV0Piwg InN0YXR1c0BpZXRmLm9yZyIgPHN0YXR1c0BpZXRmLm9yZz4sDQoic3RicnlhbnRAY2lzY28uY29t IiA8c3RicnlhbnRAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFtTdGF0dXNdIENoYXJ0ZXJpbmcg bmV4dCBzdGVwcw0KDQo+SGkgSmVmZiwNCj4NCj5JZiBJIHdhbnQgdG8gdXNlIFNQUklORyB0byBn ZXQgcmlkIG9mIExEUCBiZXR3ZWVuIG15IGluZ3Jlc3MgYW5kDQo+ZWdyZXNzIFBFcyB3aGF0IGlz IG15ICJleHBsaWNpdC1yb3V0ZSIgaW4gdGhhdCBjYXNlID8NCj4NCj5yLg0KPg0KPk9uIE1vbiwg U2VwIDIzLCAyMDEzIGF0IDg6MDUgUE0sIEplZmYgVGFudHN1cmENCj48amVmZi50YW50c3VyYUBl cmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gQWdyZWUgd2l0aCBTcmkuDQo+PiBTdHJpY3QgYW5kIGxv b3NlIGV4cGxpY2l0IHJvdXRlcyBkZWZpbmUgcHJldHR5IHdlbGwgd2hhdCBTUFJJTkcgZG9lcw0K Pj4NCj4+IENoZWVycywNCj4+IEplZmYNCj4+DQo+Pg0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogU3JpZ2FuZXNoIEtpbmkgPHNyaWdhbmVzaC5raW5pQGVy aWNzc29uLmNvbT4NCj4+IERhdGU6IE1vbmRheSwgU2VwdGVtYmVyIDIzLCAyMDEzIDExOjAyIEFN DQo+PiBUbzogInJvYmVydEByYXN6dWsubmV0IiA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQo+PiBDYzog Sm9obiBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PiwgInN0YXR1c0BpZXRmLm9yZyINCj4+PHN0 YXR1c0BpZXRmLm9yZz4sDQo+PiAic3RicnlhbnRAY2lzY28uY29tIiA8c3RicnlhbnRAY2lzY28u Y29tPg0KPj4gU3ViamVjdDogUmU6IFtTdGF0dXNdIENoYXJ0ZXJpbmcgbmV4dCBzdGVwcw0KPj4N Cj4+PlJvYmVydCwNCj4+Pg0KPj4+TVBMUyBoYXMgZGVmaW5lZCAic3RyaWN0IiwgImxvb3NlIiBh bmQgY29tYmluYXRpb25zIG9mIHRob3NlIGluIHRoZQ0KPj4+Y29udGV4dCBvZiAiZXhwbGljaXQt cm91dGVzIi4gU1BSSU5HIHNob3VsZCBiZSBhYmxlIHRvIHJlLXVzZS9yZS1kZWZpbmUNCj4+Pml0 DQo+Pj5hcyBuZWNlc3NhcnkuDQo+Pj4NCj4+PkludGVycHJldGluZyAiZXhwbGljaXQtcm91dGUi IGFzICJob3AtYnktaG9wIiBzZWVtcyBsaWtlIGEgc3RyZXRjaC4NCj4+Pg0KPj4+SSBkb24ndCBz ZWUgYSBzdHJvbmcgcmVhc29uIGZvciB5ZXQgYW5vdGhlciB0ZXJtICJkZWZpbmVkIHBhdGgiLg0K Pj4+DQo+Pj4tLSBTcmkNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pk9uIDkvMjMv MTMgMTA6NTAgQU0sICJSb2JlcnQgUmFzenVrIiA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0K Pj4+DQo+Pj4+VGhlIG9ic2VydmF0aW9uIGlzIHRoYXQgU1IgbWF5IG5vdCByZXF1aXJlIGV4cGxp Y2l0LXJvdXRlIGluIGFsbA0KPj4+PnNjZW5hcmlvcy4gSSBjYW4gc2VlIGNhc2VzIG9mIGxvb3Nl LXJvdXRlcyB5ZXQgYmFzZWQgb24gc2VnbWVudCBiYXNlZA0KPj4+PnJvdXRpbmcgcGFyYWRpZ20u DQo+Pj4+DQo+Pj4+QmVzaWRlcyBleHBsaWNpdCByb3V0ZSBtYXkgYmUgaW50ZXJwcmV0ZWQgYXMg aG9wLWJ5LWhvcCBwYXRoIHdoaWNoIGlzDQo+Pj4+Y2xlYXJseSBub3QgdGhlIGNhc2UuDQo+Pj4+ DQo+Pj4+SSB3b3VsZCByZWNvbW1lbmQgdG8gcy9leHBsaWNpdCByb3V0ZS9kZWZpbmVkIHBhdGgv DQo+Pj4+DQo+Pj4+ci4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj5PbiBNb24sIFNlcCAyMywgMjAx MyBhdCA3OjQ0IFBNLCBTcmlnYW5lc2ggS2luaQ0KPj4+PjxzcmlnYW5lc2gua2luaUBlcmljc3Nv bi5jb20+IHdyb3RlOg0KPj4+Pj4gRnJvbSBSRkMgMzAzMSwgc2VjIDMuMjENCj4+Pj4+DQo+Pj4+ PiAgICBFeHBsaWNpdCByb3V0aW5nIG1heSBiZSB1c2VmdWwgZm9yIGEgbnVtYmVyIG9mIHB1cnBv c2VzLCBzdWNoIGFzDQo+Pj4+PiAgICBwb2xpY3kgcm91dGluZyBvciB0cmFmZmljIGVuZ2luZWVy aW5nLiAgSW4gTVBMUywgdGhlIGV4cGxpY2l0DQo+Pj4+PnJvdXRlDQo+Pj4+PiAgICBuZWVkcyB0 byBiZSBzcGVjaWZpZWQgYXQgdGhlIHRpbWUgdGhhdCBsYWJlbHMgYXJlIGFzc2lnbmVkLCBidXQN Cj4+Pj4+dGhlDQo+Pj4+PiAgICBleHBsaWNpdCByb3V0ZSBkb2VzIG5vdCBoYXZlIHRvIGJlIHNw ZWNpZmllZCB3aXRoIGVhY2ggSVAgcGFja2V0Lg0KPj4+Pj4gICAgVGhpcyBtYWtlcyBNUExTIGV4 cGxpY2l0IHJvdXRpbmcgbXVjaCBtb3JlIGVmZmljaWVudCB0aGFuIHRoZQ0KPj4+Pj4gICAgYWx0 ZXJuYXRpdmUgb2YgSVAgc291cmNlIHJvdXRpbmcuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IElmIHRo ZSAiZXhwbGljaXQtcm91dGUiIGluIFNQUklORyBpcyB0aGUgc2FtZSBhcyBleHBsaWNpdC1yb3V0 ZSBpbg0KPj4+Pj5SRkMzMDMxDQo+Pj4+PiB0aGVuIHdlIGFyZSBydWxpbmcgb3V0IHNvdXJjZS1y b3V0aW5nICEgSU1PIHdlIHNob3VsZCBjYWxsIGl0DQo+Pj4+PmV4cGxpY2l0LXJvdXRlDQo+Pj4+ PiBidXQgcmUtZGVmaW5lIGl0IGZvciBTUFJJTkcuIFRoZSBkZWZpbml0aW9uIGNvdWxkIGJlICJh IHNldCBvZg0KPj4+Pj5pZGVudGlmaWVycw0KPj4+Pj4gaW4gdGhlIHBhY2tldCB0aGF0IGFsbG93 IGl0IHRvIGJlIHN0ZWVyZWQgdGhyb3VnaCB0aGUgbmV0d29yayB3aXRob3V0DQo+Pj4+Pmhhdmlu Zw0KPj4+Pj4gcGVyIGZsb3cgaW5mb3JtYXRpb24gYXQgZWFjaCBpbnRlcm1lZGlhdGUgbm9kZSIu IEhvd2V2ZXIgdGhpcw0KPj4+Pj5yZS1kZWZpbml0aW9uDQo+Pj4+PiBuZWVkIG5vdCBiZSBpbiB0 aGUgY2hhcnRlciBidXQgY291bGQgZ28gaW4gYW5vdGhlciBkb2N1bWVudA0KPj4+Pj4oYXJjaGl0 ZWN0dXJlDQo+Pj4+PiBkb2N1bWVudCkuDQo+Pj4+Pg0KPj4+Pj4gLSBTcmkNCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IE9uIE1vbiwgU2VwIDIzLCAyMDEzIGF0IDg6MDEgQU0sIEpvaG4gRSBE cmFrZSA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFN0 ZXdhcnQsDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gVXBvbiByZWZsZWN0aW9uLCBJ IHNwb2tlIHRvbyBzb29uLiAgVGhlIHVzZSBvZiB0aGUgdGVybSDFkmV4cGxpY2l0DQo+Pj4+Pj5y b3V0ZcK5DQo+Pj4+Pj4gYXMgc3VnZ2VzdGVkIGJ5IExvdSBhbmQgbXlzZWxmIGlzIGZpbmUsIGJ1 dCB0aGUgc2VudGVuY2UgeW91IGFkZGVkOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ IMKzU3RlZXJpbmcgaXMgYWNoaWV2ZWQgYnkgc3BlY2lmeWluZyBpbiB0aGUgcGFja2V0IGFuIG9y ZGVyZWQgc2V0IG9mDQo+Pj4+Pj5ub2Rlcw0KPj4+Pj4+IGFuZC9vciBsaW5rcyBhbmQvb3Igc2hv cnRlc3QtcGF0aC1uZXh0LWhvcHMgdG8gYmUgdHJhdmVyc2VkIGJ5IHRoZQ0KPj4+Pj4+cGFja2V0 LsKyDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gaGFzIGlzc3Vlcy4gIEEgcGFja2V0 ICp3aWxsIG5vdCogaGF2ZSBjb250YWluIGFuIG9yZGVyZWQgc2V0IG9mDQo+Pj4+Pj5ub2Rlcw0K Pj4+Pj4+IGFuZC9vciBsaW5rcyBhbmQvb3Igc2hvcnRlc3QtcGF0aC1uZXh0LWhvcHMgdG8gYmUg dHJhdmVyc2VkIGJ5IHRoZQ0KPj4+Pj4+cGFja2V0LA0KPj4+Pj4+IHJhdGhlciBpdCB3aWxsIGhh dmUgYSBzZXQgb2YgaWRlbnRpZmllcnMgc3BlY2lmeWluZyByZXNvdXJjZXMNCj4+Pj4+PndpdGhp biBhDQo+Pj4+Pj4gU1BSSU5HIHJlZ2lvbiwgYW5kIHRoZXNlIHNwZWNpZmllZCByZXNvdXJjZXMg KmFyZSBub3QqIGxpbWl0ZWQgdG8NCj4+Pj4+PsKzbm9kZXMNCj4+Pj4+PiBhbmQvb3IgbGlua3Mg YW5kL29yIHNob3J0ZXN0LXBhdGgtbmV4dC1ob3BzwrI7IHRoZXkgbWF5IGFsc28gaW5jbHVkZSwN Cj4+Pj4+PmZvcg0KPj4+Pj4+IGV4YW1wbGUsIGZvcndhcmRpbmcgYWRqYWNlbmNpZXMgYW5kIHNl cnZpY2VzLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEkgc3VnZ2VzdCB0aGF0IHdl IHN0cmlrZSB0aGUgc2VudGVuY2UuICBBcyBTdGVmYW5vIHBvaW50cyBvdXQsIGENCj4+Pj4+PmNo YXJ0ZXINCj4+Pj4+PiBpcyBub3QgYSBkZXNpZ24gc3BlY2lmaWNhdGlvbi4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBZb3VycyBJcnJlc3BlY3RpdmVseSwNCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+PiBKb2huDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gRnJv bTogc3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9y Z10gT24NCj4+Pj4+PkJlaGFsZg0KPj4+Pj4+IE9mIFN0ZXdhcnQgQnJ5YW50DQo+Pj4+Pj4gU2Vu dDogTW9uZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMTMgNjoxMyBBTQ0KPj4+Pj4+IFRvOiBzdGF0dXNA aWV0Zi5vcmcNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtTdGF0dXNdIENo YXJ0ZXJpbmcgbmV4dCBzdGVwcw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEkgaGF2 ZSBpbmNsdWRlZCB0aGUgcHJvcG9zZWQgY2hhbmdlcyBhbmQgc29tZSB0ZXh0IHRoYXQNCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gY2xhcmlmaWVzIHRoZSBsaW5rLW5vZGUgZGlzY3Vzc2lvbi4NCj4+ Pj4+Pg0KPj4+Pj4+IFRoZSBjdXJyZW50IGNoYXJ0ZXIgdGV4dCBpcyBhdA0KPj4+Pj4+DQo+Pj4+ Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLXNwcmluZy8N Cj4+Pj4+Pg0KPj4+Pj4+IFRoZSBkaWZmcyBhcmUgYXQNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1odHRwcyUzQSUyRiUyRmRh dGF0cmFja2VyLmlldGYub3JnJQ0KPj4+Pj4+MkYNCj4+Pj4+PmQNCj4+Pj4+Pm9jJTJGY2hhcnRl ci1pZXRmLXNwcmluZyUyRndpdGhtaWxlc3RvbmVzLTAwLTAwLnR4dCZkaWZmdHlwZT0tLWh0bWwm cw0KPj4+Pj4+dWINCj4+Pj4+Pm0NCj4+Pj4+Pml0PUdvISZ1cmwyPWh0dHBzJTNBJTJGJTJGZGF0 YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZjaGFydGVyLWlldGYtcw0KPj4+Pj4+cHINCj4+Pj4+ PmkNCj4+Pj4+Pm5nJTJGd2l0aG1pbGVzdG9uZXMtMDAtMDEudHh0DQo+Pj4+Pj4NCj4+Pj4+PiBv ciBpZiB5b3UgcHJlZmVyOg0KPj4+Pj4+DQo+Pj4+Pj4gaHR0cDovL3Rpbnl1cmwuY29tL28yNGE5 bHoNCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBsaW5rIG5vZGUgdGV4dCBJIGFkZGVkIHdhcw0KPj4+Pj4+ DQo+Pj4+Pj4gIlN0ZWVyaW5nIGlzIGFjaGlldmVkIGJ5IHNwZWNpZnlpbmcgaW4gdGhlIHBhY2tl dCBhbiBvcmRlcmVkDQo+Pj4+Pj4gc2V0IG9mIG5vZGVzIGFuZC9vciBsaW5rcyBhbmQvb3Igc2hv cnRlc3QtcGF0aC1uZXh0LWhvcHMNCj4+Pj4+PiB0byBiZSB0cmF2ZXJzZWQgYnkgdGhlIHBhY2tl dC4iDQo+Pj4+Pj4NCj4+Pj4+PiAtIFN0ZXdhcnQNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBzdGF0 dXMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc3RhdHVzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPj4+Pj4gc3RhdHVzQGlldGYub3JnDQo+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KPj4+Pj4NCj4+Pg0K Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PnN0 YXR1cyBtYWlsaW5nIGxpc3QNCj4+PnN0YXR1c0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCj4+DQoNCg== From jdrake@juniper.net Mon Sep 23 12:14:40 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D111121F9C4A for ; Mon, 23 Sep 2013 12:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnYzDrpoETNS for ; Mon, 23 Sep 2013 12:14:28 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5175421F9BF1 for ; Mon, 23 Sep 2013 12:14:28 -0700 (PDT) Received: from mail38-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE025.bigfish.com (10.3.207.147) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 19:14:26 +0000 Received: from mail38-am1 (localhost [127.0.0.1]) by mail38-am1-R.bigfish.com (Postfix) with ESMTP id BF176320311; Mon, 23 Sep 2013 19:14:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL177df4h17326ah189882h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail38-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(377454003)(479174003)(13464003)(189002)(199002)(33646001)(65816001)(76786001)(53806001)(80022001)(19580405001)(63696002)(79102001)(77096001)(74876001)(54356001)(74366001)(81342001)(46102001)(49866001)(47976001)(4396001)(74706001)(15395725003)(54316002)(31966008)(56816003)(76576001)(15975445006)(15202345003)(47736001)(50986001)(74662001)(47446002)(66066001)(83322001)(59766001)(16119065003)(56776001)(69226001)(81686001)(80976001)(83072001)(77982001)(74502001)(51856001)(81542001)(74316001)(19580395003)(81816001)(76482001)(76796001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail38-am1 (localhost.localdomain [127.0.0.1]) by mail38-am1 (MessageSwitch) id 1379963664698159_5854; Mon, 23 Sep 2013 19:14:24 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.238]) by mail38-am1.bigfish.com (Postfix) with ESMTP id A5DFFA004F; Mon, 23 Sep 2013 19:14:24 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 19:14:24 +0000 Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 19:14:23 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 19:14:21 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 19:14:21 +0000 From: John E Drake To: Sriganesh Kini , Robert Raszuk Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAdwJCAAC4BgIAAAcQAgAADVoCAABP4kA== Date: Mon, 23 Sep 2013 19:14:20 +0000 Message-ID: <03a54f7b10e94a5eb7b92c79950a8b34@BY2PR05MB142.namprd05.prod.outlook.com> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> In-Reply-To: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09781D4C35 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 19:14:41 -0000 Sri, I completely agree. Yours Irrespectively, John > -----Original Message----- > From: Sriganesh Kini [mailto:sriganesh.kini@ericsson.com] > Sent: Monday, September 23, 2013 11:02 AM > To: Robert Raszuk > Cc: John E Drake; status@ietf.org; stbryant@cisco.com > Subject: Re: [Status] Chartering next steps >=20 > Robert, >=20 > MPLS has defined "strict", "loose" and combinations of those in the conte= xt > of "explicit-routes". SPRING should be able to re-use/re-define it as > necessary. >=20 > Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. >=20 > I don't see a strong reason for yet another term "defined path". >=20 > -- Sri >=20 >=20 >=20 >=20 >=20 >=20 > On 9/23/13 10:50 AM, "Robert Raszuk" wrote: >=20 > >The observation is that SR may not require explicit-route in all > >scenarios. I can see cases of loose-routes yet based on segment based > >routing paradigm. > > > >Besides explicit route may be interpreted as hop-by-hop path which is > >clearly not the case. > > > >I would recommend to s/explicit route/defined path/ > > > >r. > > > > > > > >On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini > > wrote: > >> From RFC 3031, sec 3.21 > >> > >> Explicit routing may be useful for a number of purposes, such as > >> policy routing or traffic engineering. In MPLS, the explicit route > >> needs to be specified at the time that labels are assigned, but the > >> explicit route does not have to be specified with each IP packet. > >> This makes MPLS explicit routing much more efficient than the > >> alternative of IP source routing. > >> > >> > >> If the "explicit-route" in SPRING is the same as explicit-route in > >>RFC3031 > >> then we are ruling out source-routing ! IMO we should call it > >>explicit-route but re-define it for SPRING. The definition could be > >>"a set of identifiers in the packet that allow it to be steered > >>through the network without having per flow information at each > >>intermediate node". However this re-definition need not be in the > >>charter but could go in another document (architecture document). > >> > >> - Sri > >> > >> > >> > >> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake > >>wrote: > >>> > >>> Stewart, > >>> > >>> > >>> > >>> Upon reflection, I spoke too soon. The use of the term =8Cexplicit > >>>route=B9 as suggested by Lou and myself is fine, but the sentence you > >>>added: > >>> > >>> > >>> > >>> =B3Steering is achieved by specifying in the packet an ordered set of > >>>nodes and/or links and/or shortest-path-next-hops to be traversed by > >>>the packet.=B2 > >>> > >>> > >>> > >>> has issues. A packet *will not* have contain an ordered set of > >>>nodes and/or links and/or shortest-path-next-hops to be traversed by > >>>the packet, rather it will have a set of identifiers specifying > >>>resources within a SPRING region, and these specified resources *are > >>>not* limited to =B3nodes and/or links and/or shortest-path-next-hops= =B2; > >>>they may also include, for example, forwarding adjacencies and > >>>services. > >>> > >>> > >>> > >>> I suggest that we strike the sentence. As Stefano points out, a > >>>charter is not a design specification. > >>> > >>> > >>> > >>> Yours Irrespectively, > >>> > >>> > >>> > >>> John > >>> > >>> > >>> > >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > >>>Behalf Of Stewart Bryant > >>> Sent: Monday, September 23, 2013 6:13 AM > >>> To: status@ietf.org > >>> > >>> > >>> Subject: Re: [Status] Chartering next steps > >>> > >>> > >>> > >>> I have included the proposed changes and some text that > >>> > >>> > >>> clarifies the link-node discussion. > >>> > >>> The current charter text is at > >>> > >>> https://datatracker.ietf.org/doc/charter-ietf-spring/ > >>> > >>> The diffs are at > >>> > >>> > >>> > >>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org > % > >>>2Fd > >>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D-- > html&s > >>>ubm > >>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter- > ietf-s > >>>pri > >>>ng%2Fwithmilestones-00-01.txt > >>> > >>> or if you prefer: > >>> > >>> http://tinyurl.com/o24a9lz > >>> > >>> The link node text I added was > >>> > >>> "Steering is achieved by specifying in the packet an ordered set of > >>> nodes and/or links and/or shortest-path-next-hops to be traversed by > >>> the packet." > >>> > >>> - Stewart > >>> > >>> > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >>> > >> > >> > >> _______________________________________________ > >> status mailing list > >> status@ietf.org > >> https://www.ietf.org/mailman/listinfo/status > >> >=20 >=20 From jdrake@juniper.net Mon Sep 23 12:14:53 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C78021F9C00 for ; Mon, 23 Sep 2013 12:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.465 X-Spam-Level: X-Spam-Status: No, score=-4.465 tagged_above=-999 required=5 tests=[AWL=1.401, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86xtZkxTe3Fa for ; Mon, 23 Sep 2013 12:14:48 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2C09321F9BF1 for ; Mon, 23 Sep 2013 12:14:48 -0700 (PDT) Received: from mail65-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 19:14:47 +0000 Received: from mail65-tx2 (localhost [127.0.0.1]) by mail65-tx2-R.bigfish.com (Postfix) with ESMTP id 727E93400DF; Mon, 23 Sep 2013 19:14:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL177df4h17326ah189882h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail65-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(24454002)(13464003)(479174003)(377454003)(51704005)(83322001)(56776001)(19580405001)(77982001)(51856001)(76482001)(59766001)(74366001)(74316001)(74706001)(56816003)(81816001)(81342001)(66066001)(76786001)(47446002)(74876001)(63696002)(54316002)(76796001)(69226001)(74502001)(74662001)(83072001)(54356001)(76576001)(77096001)(53806001)(81542001)(15202345003)(46102001)(15395725003)(80976001)(47736001)(33646001)(19580395003)(49866001)(16119065003)(65816001)(15975445006)(80022001)(81686001)(50986001)(47976001)(79102001)(31966008)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB141; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail65-tx2 (localhost.localdomain [127.0.0.1]) by mail65-tx2 (MessageSwitch) id 1379963685906236_7116; Mon, 23 Sep 2013 19:14:45 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.253]) by mail65-tx2.bigfish.com (Postfix) with ESMTP id D439B14005C; Mon, 23 Sep 2013 19:14:45 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 19:14:44 +0000 Received: from BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 19:14:43 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB141.namprd05.prod.outlook.com (10.242.39.148) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 19:14:40 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 19:14:40 +0000 From: John E Drake To: Robert Raszuk , Sriganesh Kini Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAdwJCAAC4BgIAAAcQAgAADVoCAAAClgIAAE4Ug Date: Mon, 23 Sep 2013 19:14:40 +0000 Message-ID: <308488ecb3ad4edd98a3273cff099e4c@BY2PR05MB142.namprd05.prod.outlook.com> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09781D4C35 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "status@ietf.org" , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 19:14:53 -0000 And your point is? Yours Irrespectively, John > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, September 23, 2013 11:05 AM > To: Sriganesh Kini > Cc: John E Drake; status@ietf.org; stbryant@cisco.com > Subject: Re: [Status] Chartering next steps >=20 > But SPRING is not only about MPLS encapsulation .. >=20 > r. >=20 > On Mon, Sep 23, 2013 at 8:02 PM, Sriganesh Kini > wrote: > > Robert, > > > > MPLS has defined "strict", "loose" and combinations of those in the > > context of "explicit-routes". SPRING should be able to > > re-use/re-define it as necessary. > > > > Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. > > > > I don't see a strong reason for yet another term "defined path". > > > > -- Sri > > > > > > > > > > > > > > On 9/23/13 10:50 AM, "Robert Raszuk" wrote: > > > >>The observation is that SR may not require explicit-route in all > >>scenarios. I can see cases of loose-routes yet based on segment based > >>routing paradigm. > >> > >>Besides explicit route may be interpreted as hop-by-hop path which is > >>clearly not the case. > >> > >>I would recommend to s/explicit route/defined path/ > >> > >>r. > >> > >> > >> > >>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini > >> wrote: > >>> From RFC 3031, sec 3.21 > >>> > >>> Explicit routing may be useful for a number of purposes, such as > >>> policy routing or traffic engineering. In MPLS, the explicit rout= e > >>> needs to be specified at the time that labels are assigned, but th= e > >>> explicit route does not have to be specified with each IP packet. > >>> This makes MPLS explicit routing much more efficient than the > >>> alternative of IP source routing. > >>> > >>> > >>> If the "explicit-route" in SPRING is the same as explicit-route in > >>>RFC3031 > >>> then we are ruling out source-routing ! IMO we should call it > >>>explicit-route but re-define it for SPRING. The definition could be > >>>"a set of identifiers in the packet that allow it to be steered > >>>through the network without having per flow information at each > >>>intermediate node". However this re-definition need not be in the > >>>charter but could go in another document (architecture document). > >>> > >>> - Sri > >>> > >>> > >>> > >>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake > >>>wrote: > >>>> > >>>> Stewart, > >>>> > >>>> > >>>> > >>>> Upon reflection, I spoke too soon. The use of the term =8Cexplicit > >>>>route=B9 > >>>> as suggested by Lou and myself is fine, but the sentence you added: > >>>> > >>>> > >>>> > >>>> =B3Steering is achieved by specifying in the packet an ordered set o= f > >>>>nodes > >>>> and/or links and/or shortest-path-next-hops to be traversed by the > >>>>packet.=B2 > >>>> > >>>> > >>>> > >>>> has issues. A packet *will not* have contain an ordered set of node= s > >>>> and/or links and/or shortest-path-next-hops to be traversed by the > >>>>packet, > >>>> rather it will have a set of identifiers specifying resources within= a > >>>> SPRING region, and these specified resources *are not* limited to > >>>>=B3nodes > >>>> and/or links and/or shortest-path-next-hops=B2; they may also includ= e, > >>>>for > >>>> example, forwarding adjacencies and services. > >>>> > >>>> > >>>> > >>>> I suggest that we strike the sentence. As Stefano points out, a > >>>>charter > >>>> is not a design specification. > >>>> > >>>> > >>>> > >>>> Yours Irrespectively, > >>>> > >>>> > >>>> > >>>> John > >>>> > >>>> > >>>> > >>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > >>>>Behalf > >>>> Of Stewart Bryant > >>>> Sent: Monday, September 23, 2013 6:13 AM > >>>> To: status@ietf.org > >>>> > >>>> > >>>> Subject: Re: [Status] Chartering next steps > >>>> > >>>> > >>>> > >>>> I have included the proposed changes and some text that > >>>> > >>>> > >>>> clarifies the link-node discussion. > >>>> > >>>> The current charter text is at > >>>> > >>>> https://datatracker.ietf.org/doc/charter-ietf-spring/ > >>>> > >>>> The diffs are at > >>>> > >>>> > >>>> > >>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.or > g%2Fd > >>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D-- > html&subm > >>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter- > ietf-spri > >>>>ng%2Fwithmilestones-00-01.txt > >>>> > >>>> or if you prefer: > >>>> > >>>> http://tinyurl.com/o24a9lz > >>>> > >>>> The link node text I added was > >>>> > >>>> "Steering is achieved by specifying in the packet an ordered > >>>> set of nodes and/or links and/or shortest-path-next-hops > >>>> to be traversed by the packet." > >>>> > >>>> - Stewart > >>>> > >>>> > >>>> _______________________________________________ > >>>> status mailing list > >>>> status@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/status > >>>> > >>> > >>> > >>> _______________________________________________ > >>> status mailing list > >>> status@ietf.org > >>> https://www.ietf.org/mailman/listinfo/status > >>> > > >=20 From jdrake@juniper.net Mon Sep 23 12:18:09 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C657021F9D7A for ; Mon, 23 Sep 2013 12:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQmO9bHthbJn for ; Mon, 23 Sep 2013 12:18:04 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8A21F9D5D for ; Mon, 23 Sep 2013 12:18:03 -0700 (PDT) Received: from mail157-db9-R.bigfish.com (10.174.16.254) by DB9EHSOBE012.bigfish.com (10.174.14.75) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 19:18:02 +0000 Received: from mail157-db9 (localhost [127.0.0.1]) by mail157-db9-R.bigfish.com (Postfix) with ESMTP id F028342015E; Mon, 23 Sep 2013 19:18:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL177df4h17326ah189882h1de097h186068h8275bh8275dhz2fh2a8h839hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail157-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(51704005)(189002)(199002)(13464003)(4396001)(65816001)(77096001)(46102001)(53806001)(80022001)(51856001)(56816003)(76576001)(15975445006)(56776001)(76796001)(76786001)(33646001)(16119065003)(15202345003)(76482001)(54316002)(54356001)(50986001)(15395725003)(47736001)(63696002)(47976001)(19580395003)(83322001)(49866001)(19580405001)(74366001)(79102001)(77982001)(59766001)(69226001)(74876001)(81542001)(66066001)(74706001)(81816001)(81342001)(31966008)(83072001)(74662001)(47446002)(74502001)(80976001)(74316001)(81686001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB142; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail157-db9 (localhost.localdomain [127.0.0.1]) by mail157-db9 (MessageSwitch) id 1379963881148093_30740; Mon, 23 Sep 2013 19:18:01 +0000 (UTC) Received: from DB9EHSMHS003.bigfish.com (unknown [10.174.16.234]) by mail157-db9.bigfish.com (Postfix) with ESMTP id 152121E00B3; Mon, 23 Sep 2013 19:18:01 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS003.bigfish.com (10.174.14.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 19:17:55 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 19:17:53 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 19:17:51 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 19:17:51 +0000 From: John E Drake To: Robert Raszuk , Jeff Tantsura Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAdwJCAAC4BgIAAAcQAgAADVoCAAADdAIAAAPCAgAASktA= Date: Mon, 23 Sep 2013 19:17:50 +0000 Message-ID: <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 09781D4C35 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "stbryant@cisco.com" , "status@ietf.org" , Sriganesh Kini Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 19:18:09 -0000 Directions, at a given level of detail, for getting from the ingress node t= o the egress node.=20 Yours Irrespectively, John > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, September 23, 2013 11:09 AM > To: Jeff Tantsura > Cc: Sriganesh Kini; John E Drake; status@ietf.org; stbryant@cisco.com > Subject: Re: [Status] Chartering next steps >=20 > Hi Jeff, >=20 > If I want to use SPRING to get rid of LDP between my ingress and egress P= Es > what is my "explicit-route" in that case ? >=20 > r. >=20 > On Mon, Sep 23, 2013 at 8:05 PM, Jeff Tantsura > wrote: > > Agree with Sri. > > Strict and loose explicit routes define pretty well what SPRING does > > > > Cheers, > > Jeff > > > > > > > > > > -----Original Message----- > > From: Sriganesh Kini > > Date: Monday, September 23, 2013 11:02 AM > > To: "robert@raszuk.net" > > Cc: John Drake , "status@ietf.org" > > , "stbryant@cisco.com" > > Subject: Re: [Status] Chartering next steps > > > >>Robert, > >> > >>MPLS has defined "strict", "loose" and combinations of those in the > >>context of "explicit-routes". SPRING should be able to > >>re-use/re-define it as necessary. > >> > >>Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. > >> > >>I don't see a strong reason for yet another term "defined path". > >> > >>-- Sri > >> > >> > >> > >> > >> > >> > >>On 9/23/13 10:50 AM, "Robert Raszuk" wrote: > >> > >>>The observation is that SR may not require explicit-route in all > >>>scenarios. I can see cases of loose-routes yet based on segment based > >>>routing paradigm. > >>> > >>>Besides explicit route may be interpreted as hop-by-hop path which is > >>>clearly not the case. > >>> > >>>I would recommend to s/explicit route/defined path/ > >>> > >>>r. > >>> > >>> > >>> > >>>On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini > >>> wrote: > >>>> From RFC 3031, sec 3.21 > >>>> > >>>> Explicit routing may be useful for a number of purposes, such as > >>>> policy routing or traffic engineering. In MPLS, the explicit rou= te > >>>> needs to be specified at the time that labels are assigned, but t= he > >>>> explicit route does not have to be specified with each IP packet. > >>>> This makes MPLS explicit routing much more efficient than the > >>>> alternative of IP source routing. > >>>> > >>>> > >>>> If the "explicit-route" in SPRING is the same as explicit-route in > >>>>RFC3031 > >>>> then we are ruling out source-routing ! IMO we should call it > >>>>explicit-route but re-define it for SPRING. The definition could be > >>>>"a set of identifiers in the packet that allow it to be steered > >>>>through the network without having per flow information at each > >>>>intermediate node". However this re-definition need not be in the > >>>>charter but could go in another document (architecture document). > >>>> > >>>> - Sri > >>>> > >>>> > >>>> > >>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake > >>>>wrote: > >>>>> > >>>>> Stewart, > >>>>> > >>>>> > >>>>> > >>>>> Upon reflection, I spoke too soon. The use of the term =8Cexplicit > >>>>>route=B9 as suggested by Lou and myself is fine, but the sentence > >>>>>you added: > >>>>> > >>>>> > >>>>> > >>>>> =B3Steering is achieved by specifying in the packet an ordered set > >>>>>of nodes and/or links and/or shortest-path-next-hops to be > >>>>>traversed by the packet.=B2 > >>>>> > >>>>> > >>>>> > >>>>> has issues. A packet *will not* have contain an ordered set of > >>>>>nodes and/or links and/or shortest-path-next-hops to be traversed > >>>>>by the packet, rather it will have a set of identifiers specifying > >>>>>resources within a SPRING region, and these specified resources > >>>>>*are not* limited to =B3nodes and/or links and/or > >>>>>shortest-path-next-hops=B2; they may also include, for example, > >>>>>forwarding adjacencies and services. > >>>>> > >>>>> > >>>>> > >>>>> I suggest that we strike the sentence. As Stefano points out, a > >>>>>charter is not a design specification. > >>>>> > >>>>> > >>>>> > >>>>> Yours Irrespectively, > >>>>> > >>>>> > >>>>> > >>>>> John > >>>>> > >>>>> > >>>>> > >>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On > >>>>>Behalf Of Stewart Bryant > >>>>> Sent: Monday, September 23, 2013 6:13 AM > >>>>> To: status@ietf.org > >>>>> > >>>>> > >>>>> Subject: Re: [Status] Chartering next steps > >>>>> > >>>>> > >>>>> > >>>>> I have included the proposed changes and some text that > >>>>> > >>>>> > >>>>> clarifies the link-node discussion. > >>>>> > >>>>> The current charter text is at > >>>>> > >>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/ > >>>>> > >>>>> The diffs are at > >>>>> > >>>>> > >>>>> > >>>>>https://www.ietf.org/rfcdiff?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.o > r > >>>>>g%2F > >>>>>d > >>>>>oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=3D-- > html > >>>>>&sub > >>>>>m > >>>>>it=3DGo!&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter- > ietf > >>>>>-spr > >>>>>i > >>>>>ng%2Fwithmilestones-00-01.txt > >>>>> > >>>>> or if you prefer: > >>>>> > >>>>> http://tinyurl.com/o24a9lz > >>>>> > >>>>> The link node text I added was > >>>>> > >>>>> "Steering is achieved by specifying in the packet an ordered set > >>>>> of nodes and/or links and/or shortest-path-next-hops to be > >>>>> traversed by the packet." > >>>>> > >>>>> - Stewart > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> status mailing list > >>>>> status@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/status > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> status mailing list > >>>> status@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/status > >>>> > >> > >>_______________________________________________ > >>status mailing list > >>status@ietf.org > >>https://www.ietf.org/mailman/listinfo/status > > >=20 From rraszuk@gmail.com Mon Sep 23 12:43:19 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2283C21F9E6C for ; Mon, 23 Sep 2013 12:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUJkCqatiPPa for ; Mon, 23 Sep 2013 12:43:18 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B0EED21F9A3D for ; Mon, 23 Sep 2013 12:43:18 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so7293787ieb.14 for ; Mon, 23 Sep 2013 12:43:18 -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=BWGtafwCsX0+EPNIh+nmxIqM0X+hGLTIcK+/vW1Pj7c=; b=RYEmZsqEg0Sh9JKG5qd+lsXKHubVqtrn3OiNm181OKZVUzHFGzD8zDrpynRW7FB3Ru gncyrAHEj39GYJHExy4V5eO9i1lke0fLXySyOWGEBT7vPJ1JF7+mCid/hMVm54mWdB8x 7Td+WbZl9c2G4BvyDacEPSp4sSncaodeUPS3XrAWXyOMjlzMTF2MLn8U27y61ldmWWaW yw2gvTzqQ34P37LyMFIBfFYkue8XhRdBAJfmZoYQFj7WODlkwzeXTqJcFKaT5Qz3obWi wLTvnevFV57bCgac0NDKVzziLtOUzbYsbY9mOtVOX4ZeVSDsVTOs6I58UyOVtjmRBDpo 6ypg== MIME-Version: 1.0 X-Received: by 10.42.250.148 with SMTP id mo20mr6116723icb.34.1379965397507; Mon, 23 Sep 2013 12:43:17 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 23 Sep 2013 12:43:17 -0700 (PDT) In-Reply-To: <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> Date: Mon, 23 Sep 2013 21:43:17 +0200 X-Google-Sender-Auth: Fgw5V1XnPLMOFGAKq_y0nr-wGFA Message-ID: From: Robert Raszuk To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Cc: Sriganesh Kini , "status@ietf.org" , Jeff Tantsura , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 19:43:19 -0000 Such "directions" in the application of removing need for LDP for unicast traffic are computed by OSPF/ISIS SPF. Rgs, R. > Directions, at a given level of detail, for getting from the ingress node to the egress node. > > Yours Irrespectively, From sriganeshkini@gmail.com Mon Sep 23 13:08:30 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9EF21F9FC3 for ; Mon, 23 Sep 2013 13:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+WmSPcKKF-w for ; Mon, 23 Sep 2013 13:08:30 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7621F9FAE for ; Mon, 23 Sep 2013 13:08:29 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so3646649pdj.32 for ; Mon, 23 Sep 2013 13:08:29 -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:from:date:message-id :subject:to:cc:content-type; bh=OfnC2vy2+wVd41SGyDxCwnNiRVG7kCQrE635T6RHY48=; b=Jv6f5OcyeaFcD6ADHsYemRPFa/y28CnDi3+PkzTbZkc81RffyMslbxR0eOgTfctQZF 3VXwT5duOSMhwi0kIzIENjBAsg3ZA3J3SM+Xrw98itGDhLPKBvRGa4PMgxnSctYU/v90 BHAiuCGX4ZnxLUSRqYw1Q8rv/bvVn/V4EuXunxxiXBONKU5NRxgOyXghXkwnt8cVFkz5 x5UmfnBXw+PWHgZsl04KR+Q5luBm4htghS/Azll0bOxvpveyrYKvHT8x4A5+KJpu4Ijv aykEZi4eboGV6tg3GVTKXE/4s/oF2xn2VrfExEYFNIu4HhQ5WpK2EYW47GsFzxKApUvZ oJ1w== X-Received: by 10.68.182.3 with SMTP id ea3mr9510203pbc.124.1379966909731; Mon, 23 Sep 2013 13:08:29 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.225 with HTTP; Mon, 23 Sep 2013 13:07:53 -0700 (PDT) In-Reply-To: References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> From: Sriganesh Kini Date: Mon, 23 Sep 2013 13:07:53 -0700 X-Google-Sender-Auth: Jx5l2uqJat-9VfPDsxGK3d0Y-Ak Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=047d7bae45ac74ddad04e7129516 Cc: John E Drake , "status@ietf.org" , Jeff Tantsura , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:08:30 -0000 --047d7bae45ac74ddad04e7129516 Content-Type: text/plain; charset=UTF-8 If that is your application, then the (loose) explicit-route is the shortest-path. In case of MPLS-SPRING the source will push a label that results in the packet going along the shortest-path. On Mon, Sep 23, 2013 at 12:43 PM, Robert Raszuk wrote: > Such "directions" in the application of removing need for LDP for > unicast traffic are computed by OSPF/ISIS SPF. > > Rgs, > R. > > > Directions, at a given level of detail, for getting from the ingress > node to the egress node. > > > > Yours Irrespectively, > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --047d7bae45ac74ddad04e7129516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If that is your application, then the (loose) explicit-rou= te is the shortest-path. In case of MPLS-SPRING the source will push a labe= l that results in the packet going along the shortest-path.


On Mon, Sep 23, 2013 at 12:43 PM, Robert= Raszuk <robert@raszuk.net> wrote:
Such "directions" in the application of removing need for LDP for=
unicast traffic are computed by OSPF/ISIS SPF.

Rgs,
R.

> Directions, at a given level of detail, for getting from the ingress n= ode to the egress node.
>
> Yours Irrespectively,
_______________________________________________
status mailing list
status@ietf.org = https://www.ietf.org/mailman/listinfo/status

--047d7bae45ac74ddad04e7129516-- From jdrake@juniper.net Mon Sep 23 13:54:00 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699B121F9E28 for ; Mon, 23 Sep 2013 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA9WlIrQHst6 for ; Mon, 23 Sep 2013 13:53:54 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id BA90921F9DB0 for ; Mon, 23 Sep 2013 13:53:53 -0700 (PDT) Received: from mail33-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE014.bigfish.com (10.3.207.136) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 20:53:52 +0000 Received: from mail33-am1 (localhost [127.0.0.1]) by mail33-am1-R.bigfish.com (Postfix) with ESMTP id BC2451E012C; Mon, 23 Sep 2013 20:53:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail33-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(24454002)(377454003)(199002)(189002)(74366001)(79102001)(76796001)(76786001)(63696002)(54356001)(47736001)(36756003)(4396001)(49866001)(74706001)(82746002)(74876001)(53806001)(65816001)(33656001)(50986001)(77096001)(51856001)(46102001)(80022001)(56816003)(47976001)(77982001)(59766001)(31966008)(47446002)(56776001)(74662001)(54316002)(81816001)(81542001)(81342001)(83072001)(76482001)(83322001)(80976001)(19580395003)(74502001)(19580405001)(81686001)(66066001)(69226001)(83716002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB143; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:166.137.81.228; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail33-am1 (localhost.localdomain [127.0.0.1]) by mail33-am1 (MessageSwitch) id 1379969630976625_7372; Mon, 23 Sep 2013 20:53:50 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.250]) by mail33-am1.bigfish.com (Postfix) with ESMTP id E48E33C0083; Mon, 23 Sep 2013 20:53:50 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 20:53:50 +0000 Received: from BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 20:53:45 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB143.namprd05.prod.outlook.com (10.242.39.153) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 20:53:43 +0000 Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.190]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 20:53:42 +0000 From: John E Drake To: Robert Raszuk Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePWSMVrThVEyk6+j+CSjXdeu5nOfZ4AgAATZ4CABCbCAIAAmayAgAAdwJCAAC4BgIAAAcQAgAADVoCAAADdAIAAAPCAgAASktCAAAfXgIAAE60x Date: Mon, 23 Sep 2013 20:53:42 +0000 Message-ID: <8F783949-5E67-4AE0-90F3-65CFD6A266E9@juniper.net> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.81.228] x-forefront-prvs: 09781D4C35 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Sriganesh Kini , "status@ietf.org" , Jeff Tantsura , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:54:00 -0000 You're getting the hang of this. Sent from my iPhone > On Sep 23, 2013, at 3:43 PM, "Robert Raszuk" wrote: >=20 > Such "directions" in the application of removing need for LDP for > unicast traffic are computed by OSPF/ISIS SPF. >=20 > Rgs, > R. >=20 >> Directions, at a given level of detail, for getting from the ingress nod= e to the egress node. >>=20 >> Yours Irrespectively, >=20 >=20 From rraszuk@gmail.com Mon Sep 23 13:54:00 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C1C21F9DB0 for ; Mon, 23 Sep 2013 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM9XyBHb697n for ; Mon, 23 Sep 2013 13:54:00 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C921D21F9DC9 for ; Mon, 23 Sep 2013 13:53:59 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so7322056iet.19 for ; Mon, 23 Sep 2013 13:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9UIhKkaZ4hlunIm1hzgdQ7O/AL1RvWjJQRDWf9DegpY=; b=JESBApybDVYQoWllwKpw4aQGey4bN+YI8yAxmwCTxJHH/B+EBnLv1n6MUdNYpDyEg9 kgd6nUQPXz07nV/rpjAxfKpFppbDNsM6y2qx2N4AuskhJ/vOVL5NohwVqdQtTBrYqDfD y+eFGfOitpPKIW0VzoeESlSgqX8QnBNulDsjSqyOrMyQbWj9s+VeUFuu/Hqo7sV9A+c3 TzDsD2bOBy5beLoE0To5jtJuRY/868eZ2mxNurLpSUFxIa5vFZEI++8DYWO+veEvW/ZP 6prOsoCdxuhUN8yPAOhhZR7LRu2msIJ5xovJoXDlVz8BWbXM4i3TLSOHxGxk1EznOCL9 i5tQ== MIME-Version: 1.0 X-Received: by 10.43.169.130 with SMTP id nm2mr2998535icc.61.1379969639176; Mon, 23 Sep 2013 13:53:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.17.195 with HTTP; Mon, 23 Sep 2013 13:53:59 -0700 (PDT) In-Reply-To: References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> Date: Mon, 23 Sep 2013 22:53:59 +0200 X-Google-Sender-Auth: _qM3d_nsJ1_53bkWQFeNT7jKKxg Message-ID: From: Robert Raszuk To: Sriganesh Kini Content-Type: text/plain; charset=ISO-8859-1 Cc: John E Drake , "status@ietf.org" , Jeff Tantsura , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:54:01 -0000 Last email on this ... rfc3031 says: - Sometimes it is desirable to force a packet to follow a particular route which is explicitly chosen at or before the time the packet enters the network, rather than being chosen by the normal dynamic routing algorithm as the packet travels through the network. My example application is to use normal dynamic routing algorithm which based on the above text does not fall under term of "explicit" it is neither loose ERO or strict ERO - there is no ERO. Best, R. On Mon, Sep 23, 2013 at 10:07 PM, Sriganesh Kini wrote: > If that is your application, then the (loose) explicit-route is the > shortest-path. In case of MPLS-SPRING the source will push a label that > results in the packet going along the shortest-path. > > > On Mon, Sep 23, 2013 at 12:43 PM, Robert Raszuk wrote: >> >> Such "directions" in the application of removing need for LDP for >> unicast traffic are computed by OSPF/ISIS SPF. >> >> Rgs, >> R. >> >> > Directions, at a given level of detail, for getting from the ingress >> > node to the egress node. >> > >> > Yours Irrespectively, >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > > From sriganesh.kini@ericsson.com Mon Sep 23 14:06:56 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68A821F9E0D for ; Mon, 23 Sep 2013 14:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T68MMwdyLLYJ for ; Mon, 23 Sep 2013 14:06:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 61C0421F9D3B for ; Mon, 23 Sep 2013 14:06:49 -0700 (PDT) X-AuditID: c6180641-b7fe28e000000d82-ab-5240ad68b0c1 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 84.5D.03458.86DA0425; Mon, 23 Sep 2013 23:06:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 23 Sep 2013 17:06:16 -0400 From: Sriganesh Kini To: Robert Raszuk Thread-Topic: [Status] Chartering next steps Thread-Index: AQHOtePKJ5S7NF25oEiLN/tcVGzIy5nOwKwAgAATZ4CABCbCAIAAmayAgAAeZICAAC1dgIAAAcQA//+OBYCAAHYuAIAAAPCAgAATTQCAAAccgIAABuCAgAAM4YD//44WAA== Date: Mon, 23 Sep 2013 21:06:16 +0000 Message-ID: <95453A37E413464E93B5ABC0F8164C4D02E78E56@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <0246F958875AF54FBD2088C43BD48B1A@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPlG7GWocggwWXFSzm3HW2aFrYxGzx uvkik8W5p3MYHVg8pvzeyOqxZMlPJo/rTVfZPXZvXMAUwBLFZZOSmpNZllqkb5fAlXF063KW ggV8Fc/+7mJuYJzH3cXIySEhYCKx6eImVghbTOLCvfVsXYxcHEICRxkl1ry5C+UsZ5To/9nP BlLFJmAkceHufBYQW0RAVaLzxCNmkCJmgaWMElevnAEbJSygLfFuWisTRJGOxLE/d8GKRAQm MUr8+XKUGSTBAtT98k4vI4jNK+Arsav7BTuIzSkQKHHu/wawDYxAN30/tQZsELOAuMStJ/OZ IG4VkFiy5zwzhC0q8fLxP7DFogJ6Em3HzrBDxJUlljzZzwLRqyOxYPcnNgjbWqJz9zZGCFtb YtnC18wQNwhKnJz5hGUCo/gsJOtmIWmfhaR9FpL2WUjaFzCyrmLkKC1OLctNNzLcxAiMwGMS bI47GBd8sjzEKM3BoiTOu0HvTKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxnyD6Dm6/t/Z WfLfmvrtj950RXhGqudKPaGFTvIlsr8N27UbyzOu72qu2aik1/95zkZ+Mb0JU3OtD8kGuza4 Hz+2g4FR4drBDcsYLM7u6iq/XXCYaceuB6wTLO7v/Nx31/LXjF9aH9Qyl6zumV+kVpydsO6D +US5yvzSOTX9bhrm1wTSdh2aosRSnJFoqMVcVJwIAHap3HaOAgAA Cc: John E Drake , "status@ietf.org" , Jeff Tantsura , "stbryant@cisco.com" Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 21:06:56 -0000 Robert, as has been said on the list before, RFC 3031 is not listed in the charter. But there are definitions in it that are useful to be adapted for SPRING.=20 -- Sri On 9/23/13 1:53 PM, "Robert Raszuk" wrote: >Last email on this ... > >rfc3031 says: > > - Sometimes it is desirable to force a packet to follow a > particular route which is explicitly chosen at or before the > time the packet enters the network, rather than being chosen by > the normal dynamic routing algorithm as the packet travels > through the network. > >My example application is to use normal dynamic routing algorithm >which based on the above text does not fall under term of "explicit" >it is neither loose ERO or strict ERO - there is no ERO. > >Best, >R. > > > > > >On Mon, Sep 23, 2013 at 10:07 PM, Sriganesh Kini > wrote: >> If that is your application, then the (loose) explicit-route is the >> shortest-path. In case of MPLS-SPRING the source will push a label that >> results in the packet going along the shortest-path. >> >> >> On Mon, Sep 23, 2013 at 12:43 PM, Robert Raszuk >>wrote: >>> >>> Such "directions" in the application of removing need for LDP for >>> unicast traffic are computed by OSPF/ISIS SPF. >>> >>> Rgs, >>> R. >>> >>> > Directions, at a given level of detail, for getting from the ingress >>> > node to the egress node. >>> > >>> > Yours Irrespectively, >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >> >> >_______________________________________________ >status mailing list >status@ietf.org >https://www.ietf.org/mailman/listinfo/status From hannes@juniper.net Mon Sep 23 19:21:39 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436FC21F9FE9 for ; Mon, 23 Sep 2013 19:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F00scSoQgtp7 for ; Mon, 23 Sep 2013 19:21: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 CCC5D21F9D92 for ; Mon, 23 Sep 2013 19:21:32 -0700 (PDT) Received: from mail48-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 02:21:26 +0000 Received: from mail48-ch1 (localhost [127.0.0.1]) by mail48-ch1-R.bigfish.com (Postfix) with ESMTP id 41EB76018F; Tue, 24 Sep 2013 02:21:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz98dI9371Iec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail48-ch1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail48-ch1 (localhost.localdomain [127.0.0.1]) by mail48-ch1 (MessageSwitch) id 1379989283995523_8378; Tue, 24 Sep 2013 02:21:23 +0000 (UTC) Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail48-ch1.bigfish.com (Postfix) with ESMTP id ED69312006C; Tue, 24 Sep 2013 02:21:23 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 02:21:23 +0000 Received: from hannes-sslvpn-nc.jnpr.net (66.129.224.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 02:21:22 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: Date: Tue, 24 Sep 2013 01:03:29 +0200 Content-Transfer-Encoding: 7bit Message-ID: <26991B65-DBA8-4DFE-863B-85E9B723C4D1@juniper.net> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: John E Drake , "stbryant@cisco.com" , "status@ietf.org" , Jeff Tantsura , Sriganesh Kini Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 02:21:39 -0000 On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote: > Last email on this ... > > rfc3031 says: > > - Sometimes it is desirable to force a packet to follow a > particular route which is explicitly chosen at or before the > time the packet enters the network, rather than being chosen by > the normal dynamic routing algorithm as the packet travels > through the network. > > My example application is to use normal dynamic routing algorithm > which based on the above text does not fall under term of "explicit" > it is neither loose ERO or strict ERO - there is no ERO. there is always an ERO. for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get - which is consisting of a single 'loose' hop denominating the egress point. just ask yourself how is e.g. a RSVP/SR LSP: 192.168.1.1 'L' ERO different than a LDP LSP: FEC 192.168.1.1 ? /hannes From Ruediger.Geib@telekom.de Mon Sep 23 23:40:14 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA4B21F9AA7 for ; Mon, 23 Sep 2013 23:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqRERC2jDP96 for ; Mon, 23 Sep 2013 23:40:10 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 531F321F9B25 for ; Mon, 23 Sep 2013 23:40:06 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 24 Sep 2013 08:40:04 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.46]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 24 Sep 2013 08:40:04 +0200 From: To: Date: Tue, 24 Sep 2013 08:40:02 +0200 Thread-Topic: [Status] Chartering next steps Thread-Index: Ac64zNcJJu3PaUiKQQ23zmOGjOjUtAAIPY2A Message-ID: References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> <26991B65-DBA8-4DFE-863B-85E9B723C4D1@juniper.net> In-Reply-To: <26991B65-DBA8-4DFE-863B-85E9B723C4D1@juniper.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 06:40:14 -0000 Hannes, all, thanks for pointing out. I think SPRING's objective is to enhance hop-by-ho= p routing to additionally allow explicit routing without state maintainance= at transit nodes. Robert indicated, that changes in routing protocols required by SPRING are = not limited to features required to set up such explicit routes. And he's a= bsolutely correct with that. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Hannes Gredler Sent: Tuesday, September 24, 2013 1:03 AM To: Robert Raszuk Cc: John E Drake; stbryant@cisco.com; status@ietf.org; Jeff Tantsura; Sriga= nesh Kini Subject: Re: [Status] Chartering next steps On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote: > Last email on this ... > > rfc3031 says: > > - Sometimes it is desirable to force a packet to follow a > particular route which is explicitly chosen at or before the > time the packet enters the network, rather than being chosen by > the normal dynamic routing algorithm as the packet travels > through the network. > > My example application is to use normal dynamic routing algorithm > which based on the above text does not fall under term of "explicit" > it is neither loose ERO or strict ERO - there is no ERO. there is always an ERO. for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get - which is consisting of a single 'loose' hop denominating the egress point. just ask yourself how is e.g. a RSVP/SR LSP: 192.168.1.1 'L' ERO different than a LDP LSP: FEC 192.168.1.1 ? /hannes _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From stbryant@cisco.com Tue Sep 24 03:00:19 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A224D11E80D5 for ; Tue, 24 Sep 2013 03:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.232 X-Spam-Level: X-Spam-Status: No, score=-110.232 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOQF+9yGOgIN for ; Tue, 24 Sep 2013 03:00:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9D94011E8107 for ; Tue, 24 Sep 2013 03:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6136; q=dns/txt; s=iport; t=1380016811; x=1381226411; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=us35leMs6p2hZE0a52U9jwm5CSAUBkGPg0pwh+KpYTw=; b=SDu2qjL2uA2DxjIl9QSzsRiXhD4SnYNuGeZm0f67MTeEbfwMSaYO9Zvm t/YrzTTZY24SAEe+Zewe+0VKinDpU6rj8K/fDQWXWVltTyv81CbIqvbjM pheU0xSCAV8HWTNeTQUaohpbqxBEAa72VMO075wrxbhNosDsoZe7b2JIr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicKAMBhQVKQ/khM/2dsb2JhbABagwc4TMAMRQMCgSIWdIIlAQEBBAEBAS8BBTYKAQwECxEBAgEBAQEJFggHCQMCAQIBFR8DBggGDQEFAgEBiAEHBb0ijFyBNk9OIgcGhBcDl3yBL4sYhTCDJXEBdQ X-IronPort-AV: E=Sophos;i="4.90,969,1371081600"; d="scan'208";a="86890317" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 24 Sep 2013 10:00:07 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8OA05go027655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Sep 2013 10:00:06 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8OA02Fg003523; Tue, 24 Sep 2013 11:00:03 +0100 (BST) Message-ID: <524162A2.5030209@cisco.com> Date: Tue, 24 Sep 2013 11:00:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Robert Raszuk References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: John E Drake , "status@ietf.org" , Jeff Tantsura , Sriganesh Kini Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 24 Sep 2013 10:00:19 -0000 A one hop loose source route with the next hop = the egress PE. Stewart On 23/09/2013 19:08, Robert Raszuk wrote: > Hi Jeff, > > If I want to use SPRING to get rid of LDP between my ingress and > egress PEs what is my "explicit-route" in that case ? > > r. > > On Mon, Sep 23, 2013 at 8:05 PM, Jeff Tantsura > wrote: >> Agree with Sri. >> Strict and loose explicit routes define pretty well what SPRING does >> >> Cheers, >> Jeff >> >> >> >> >> -----Original Message----- >> From: Sriganesh Kini >> Date: Monday, September 23, 2013 11:02 AM >> To: "robert@raszuk.net" >> Cc: John Drake , "status@ietf.org" , >> "stbryant@cisco.com" >> Subject: Re: [Status] Chartering next steps >> >>> Robert, >>> >>> MPLS has defined "strict", "loose" and combinations of those in the >>> context of "explicit-routes". SPRING should be able to re-use/re-define it >>> as necessary. >>> >>> Interpreting "explicit-route" as "hop-by-hop" seems like a stretch. >>> >>> I don't see a strong reason for yet another term "defined path". >>> >>> -- Sri >>> >>> >>> >>> >>> >>> >>> On 9/23/13 10:50 AM, "Robert Raszuk" wrote: >>> >>>> The observation is that SR may not require explicit-route in all >>>> scenarios. I can see cases of loose-routes yet based on segment based >>>> routing paradigm. >>>> >>>> Besides explicit route may be interpreted as hop-by-hop path which is >>>> clearly not the case. >>>> >>>> I would recommend to s/explicit route/defined path/ >>>> >>>> r. >>>> >>>> >>>> >>>> On Mon, Sep 23, 2013 at 7:44 PM, Sriganesh Kini >>>> wrote: >>>>> From RFC 3031, sec 3.21 >>>>> >>>>> Explicit routing may be useful for a number of purposes, such as >>>>> policy routing or traffic engineering. In MPLS, the explicit route >>>>> needs to be specified at the time that labels are assigned, but the >>>>> explicit route does not have to be specified with each IP packet. >>>>> This makes MPLS explicit routing much more efficient than the >>>>> alternative of IP source routing. >>>>> >>>>> >>>>> If the "explicit-route" in SPRING is the same as explicit-route in >>>>> RFC3031 >>>>> then we are ruling out source-routing ! IMO we should call it >>>>> explicit-route >>>>> but re-define it for SPRING. The definition could be "a set of >>>>> identifiers >>>>> in the packet that allow it to be steered through the network without >>>>> having >>>>> per flow information at each intermediate node". However this >>>>> re-definition >>>>> need not be in the charter but could go in another document >>>>> (architecture >>>>> document). >>>>> >>>>> - Sri >>>>> >>>>> >>>>> >>>>> On Mon, Sep 23, 2013 at 8:01 AM, John E Drake >>>>> wrote: >>>>>> Stewart, >>>>>> >>>>>> >>>>>> >>>>>> Upon reflection, I spoke too soon. The use of the term Œexplicit >>>>>> route¹ >>>>>> as suggested by Lou and myself is fine, but the sentence you added: >>>>>> >>>>>> >>>>>> >>>>>> ³Steering is achieved by specifying in the packet an ordered set of >>>>>> nodes >>>>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>>> packet.² >>>>>> >>>>>> >>>>>> >>>>>> has issues. A packet *will not* have contain an ordered set of nodes >>>>>> and/or links and/or shortest-path-next-hops to be traversed by the >>>>>> packet, >>>>>> rather it will have a set of identifiers specifying resources within a >>>>>> SPRING region, and these specified resources *are not* limited to >>>>>> ³nodes >>>>>> and/or links and/or shortest-path-next-hops²; they may also include, >>>>>> for >>>>>> example, forwarding adjacencies and services. >>>>>> >>>>>> >>>>>> >>>>>> I suggest that we strike the sentence. As Stefano points out, a >>>>>> charter >>>>>> is not a design specification. >>>>>> >>>>>> >>>>>> >>>>>> Yours Irrespectively, >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On >>>>>> Behalf >>>>>> Of Stewart Bryant >>>>>> Sent: Monday, September 23, 2013 6:13 AM >>>>>> To: status@ietf.org >>>>>> >>>>>> >>>>>> Subject: Re: [Status] Chartering next steps >>>>>> >>>>>> >>>>>> >>>>>> I have included the proposed changes and some text that >>>>>> >>>>>> >>>>>> clarifies the link-node discussion. >>>>>> >>>>>> The current charter text is at >>>>>> >>>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/ >>>>>> >>>>>> The diffs are at >>>>>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2F >>>>>> d >>>>>> oc%2Fcharter-ietf-spring%2Fwithmilestones-00-00.txt&difftype=--html&sub >>>>>> m >>>>>> it=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spr >>>>>> i >>>>>> ng%2Fwithmilestones-00-01.txt >>>>>> >>>>>> or if you prefer: >>>>>> >>>>>> http://tinyurl.com/o24a9lz >>>>>> >>>>>> The link node text I added was >>>>>> >>>>>> "Steering is achieved by specifying in the packet an ordered >>>>>> set of nodes and/or links and/or shortest-path-next-hops >>>>>> to be traversed by the packet." >>>>>> >>>>>> - Stewart >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> status mailing list >>>>>> status@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/status >>>>>> >>>>> >>>>> _______________________________________________ >>>>> status mailing list >>>>> status@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/status >>>>> >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From hannes@juniper.net Tue Sep 24 05:12:33 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39DD21F9929 for ; Tue, 24 Sep 2013 05:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20KrauOszrd8 for ; Tue, 24 Sep 2013 05:12:28 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id DDABF21F9926 for ; Tue, 24 Sep 2013 05:12:18 -0700 (PDT) Received: from mail3-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE025.bigfish.com (10.3.207.147) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 12:12:17 +0000 Received: from mail3-am1 (localhost [127.0.0.1]) by mail3-am1-R.bigfish.com (Postfix) with ESMTP id 8889C460126; Tue, 24 Sep 2013 12:12:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zz98dI9371I148cI542Id87dhec9Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944hce6hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail3-am1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail3-am1 (localhost.localdomain [127.0.0.1]) by mail3-am1 (MessageSwitch) id 138002473569377_4704; Tue, 24 Sep 2013 12:12:15 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.228]) by mail3-am1.bigfish.com (Postfix) with ESMTP id 021114E004B; Tue, 24 Sep 2013 12:12:15 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 12:12:14 +0000 Received: from juniper.net (66.129.224.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 12:12:13 +0000 Date: Tue, 24 Sep 2013 14:12:08 +0200 From: Hannes Gredler To: Message-ID: <20130924121207.GA2607@juniper.net> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> <26991B65-DBA8-4DFE-863B-85E9B723C4D1@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [66.129.224.36] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:12:33 -0000 On Tue, Sep 24, 2013 at 08:40:02AM +0200, Ruediger.Geib@telekom.de wrote: | thanks for pointing out. I think SPRING's objective is to enhance hop-by-hop routing to additionally allow explicit routing without state maintainance at transit nodes. my read is that it its the other way around. there is enough exisiting protocols which support hop-by-hop routing. what i am looking for the spot which is not covered by existing protocols (read: explicit routing at scale, w/o tracking midpoint state) | Robert indicated, that changes in routing protocols required by SPRING are not limited to features required to set up such explicit routes. And he's absolutely correct with that. thats fine - note that in all the exisiting IGP MPLS drafts there is both support for explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions such that you can learn transport labels from non adjacent routers. /hannes | | -----Original Message----- | From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Hannes Gredler | Sent: Tuesday, September 24, 2013 1:03 AM | To: Robert Raszuk | Cc: John E Drake; stbryant@cisco.com; status@ietf.org; Jeff Tantsura; Sriganesh Kini | Subject: Re: [Status] Chartering next steps | | | On Sep 23, 2013, at 10:53 PM, Robert Raszuk wrote: | | > Last email on this ... | > | > rfc3031 says: | > | > - Sometimes it is desirable to force a packet to follow a | > particular route which is explicitly chosen at or before the | > time the packet enters the network, rather than being chosen by | > the normal dynamic routing algorithm as the packet travels | > through the network. | > | > My example application is to use normal dynamic routing algorithm | > which based on the above text does not fall under term of "explicit" | > it is neither loose ERO or strict ERO - there is no ERO. | | there is always an ERO. | for hop-by-hop LSPs the ERO admittedly is as 'loose' as 'loose' can get - | which is consisting of a single 'loose' hop denominating the egress point. | | just ask yourself how is e.g. | a RSVP/SR LSP: 192.168.1.1 'L' ERO different than | a LDP LSP: FEC 192.168.1.1 ? | | /hannes | | | _______________________________________________ | status mailing list | status@ietf.org | https://www.ietf.org/mailman/listinfo/status | | From jnc@mercury.lcs.mit.edu Tue Sep 24 13:27:41 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A37121F90DC for ; Tue, 24 Sep 2013 13:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpTmjaoe77s2 for ; Tue, 24 Sep 2013 13:27:36 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5411E8167 for ; Tue, 24 Sep 2013 13:27:29 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 3FBB018C0E9; Tue, 24 Sep 2013 16:27:27 -0400 (EDT) To: hannes@juniper.net, status@ietf.org Message-Id: <20130924202727.3FBB018C0E9@mercury.lcs.mit.edu> Date: Tue, 24 Sep 2013 16:27:27 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:27:41 -0000 > From: Hannes Gredler > what i am looking for the spot which is not covered by existing > protocols (read: explicit routing at scale, w/o tracking midpoint state) This is probably not quite what you're looking for, but may I point you at: http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html It had the characteristics you're looking for (explicit routing, without knowing all the details in the middle), but of course it was a much more powerful, general design, intended as it was to replace _all_ EGPs and most IGPs. Noel From Ruediger.Geib@telekom.de Tue Sep 24 23:32:46 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F39411E80D9 for ; Tue, 24 Sep 2013 23:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyCuhbnDEE7Q for ; Tue, 24 Sep 2013 23:32:41 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1E11E80DC for ; Tue, 24 Sep 2013 23:32:41 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 25 Sep 2013 08:32:39 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.46]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 25 Sep 2013 08:32:39 +0200 From: To: Date: Wed, 25 Sep 2013 08:32:38 +0200 Thread-Topic: [Status] Chartering next steps Thread-Index: Ac65H128ivTj81+uRACSexw/uB2xWAAlyffw Message-ID: References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> <26991B65-DBA8-4DFE-863B-85E9B723C4D1@juniper.net> <20130924121207.GA2607@juniper.net> In-Reply-To: <20130924121207.GA2607@juniper.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 06:32:46 -0000 Hannes, please explain your point. Regards, Ruediger -----Original Message----- From: Hannes Gredler [mailto:hannes@juniper.net] my read is that it its the other way around. there is enough exisiting protocols which support hop-by-hop routing. what i am looking for the spot which is not covered by existing protocols (read: explicit routing at scale, w/o tracking midpoint state) Means we've solved all hop-by-hop and ER issues by the existing protocols a= nd you don't see a point in any SPRING related activity? thats fine - note that in all the exisiting IGP MPLS drafts there is bo= th support for explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions such that you can learn transport labels from non adjacent routers. Yes, and you are one of the authors. If you believe there's no spot covered= by existing protocols, why are you entertaining drafts related to SPRING? If all spots are covered: which single existing protocol detects a domain's= complete MPLS topology coupled with IGP topology and utilisation of the MP= LS topology discovered that way for routing at a source node? From hannes@juniper.net Wed Sep 25 02:02:32 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A35521F9F08 for ; Wed, 25 Sep 2013 02:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBpmqDdfEYfO for ; Wed, 25 Sep 2013 02:02:26 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5021F9F86 for ; Wed, 25 Sep 2013 02:02:22 -0700 (PDT) Received: from mail33-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Wed, 25 Sep 2013 09:02:22 +0000 Received: from mail33-co9 (localhost [127.0.0.1]) by mail33-co9-R.bigfish.com (Postfix) with ESMTP id 4B4A3200131; Wed, 25 Sep 2013 09:02:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz98dId79eh9371I542Id87dhec9I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h) Received-SPF: pass (mail33-co9: domain of juniper.net designates 157.56.242.197 as permitted sender) client-ip=157.56.242.197; envelope-from=hannes@juniper.net; helo=BL2PRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail33-co9 (localhost.localdomain [127.0.0.1]) by mail33-co9 (MessageSwitch) id 1380099741130097_12332; Wed, 25 Sep 2013 09:02:21 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.226]) by mail33-co9.bigfish.com (Postfix) with ESMTP id 122221E0097; Wed, 25 Sep 2013 09:02:21 +0000 (UTC) Received: from BL2PRD0512HT002.namprd05.prod.outlook.com (157.56.242.197) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 25 Sep 2013 09:02:20 +0000 Received: from hannes-sslvpn-nc.jnpr.net (66.129.224.50) by pod51010.outlook.com (10.255.233.35) with Microsoft SMTP Server (TLS) id 14.16.359.1; Wed, 25 Sep 2013 09:02:19 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="iso-8859-1" From: Hannes Gredler In-Reply-To: Date: Wed, 25 Sep 2013 11:02:15 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <0686A204-0BCE-4DCF-8ACA-B4C5374C0451@juniper.net> References: <95453A37E413464E93B5ABC0F8164C4D02E78CDE@eusaamb101.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C74839934B77@eusaamb109.ericsson.se> <389ed007dfc54276adbdf9ba52a20645@BY2PR05MB142.namprd05.prod.outlook.com> <26991B65-DBA8-4DFE-863B-85E9B723C4D1@juniper.net> <20130924121207.GA2607@juniper.net> To: X-Mailer: Apple Mail (2.1283) X-Originating-IP: [66.129.224.50] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: status@ietf.org Subject: Re: [Status] Chartering next steps X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 09:02:32 -0000 On Sep 25, 2013, at 8:32 AM, wrote: > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] >=20 > my read is that it its the other way around. > there is enough exisiting protocols which support hop-by-hop = routing. >=20 > what i am looking for the spot which is not covered by > existing protocols (read: explicit routing at scale, > w/o tracking midpoint state) >=20 > Means we've solved all hop-by-hop and ER issues by the existing = protocols and you don't see a point in any SPRING related activity? what i am looking in SPRING is to augment the protocol stack with semantics which do not yet exist. as a counter-example introducing IGP advertised hop-by-hop labels (just to replace LDP for transport labels is redundant) and as such rather uninteresting. however there are use cases which require transport labels to be learned from non-adjacecnt routers. (e.g. R-LFA, R-LFA+DF) and IGP disseminated labels would fix that problem just nice. >=20 > thats fine - note that in all the exisiting IGP MPLS drafts there = is both support for > explicit routes and hop-by-hop LSPs, mostly to avoid T-LDP sessions > such that you can learn transport labels from non adjacent routers. >=20 > Yes, and you are one of the authors. If you believe there's no spot = covered by existing protocols, why are you entertaining drafts related = to SPRING? today no protocol supports learning of labels from non-adjacent = neighbors, like we need it in R-LFA and R-LFA+DF - so the 'workaround' is to dynamically bring up LDP sessions which is arguably a bit more = expensive as you cannot construct R-LFA backup paths in s "single pass", after initial PQ set calculation you always need to wait until the T-LDP labels from the PQ neighbors have been learned. upon major topology changes this translates into twice the forwarding = table updates, twice the BGP route resolver dependency checking, etc. the 'segment routing extensions' draft and the 'label in IGP drafts=20 which i co-authored, fix that specific problem by allowing to = calculate/update backup paths in a "single pass". > If all spots are covered: which single existing protocol detects a = domain's complete MPLS topology coupled with IGP topology and = utilisation of the MPLS topology discovered that way for routing at a = source node? the cardinal mistake in here seems to me is the desire to have a 'single = protocol'. as no protocol has the sum of properties of all the other protocols, there will be always a 'plurality' of protocols. IOW just because we introduce hop-by-hop labels and explicit routes in = the IGP does not imply that neither LDP, RSVP nor BGP-LU is going away. at best we may see some shift of functionality from protocol X to = protocol Y. hope that clarifies, /hannes From stbryant@cisco.com Mon Sep 30 08:52:46 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43A721F958A for ; Mon, 30 Sep 2013 08:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcZvRuJ9C7z0 for ; Mon, 30 Sep 2013 08:52:37 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BC1BC21F9425 for ; Mon, 30 Sep 2013 08:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3766; q=dns/txt; s=iport; t=1380556356; x=1381765956; h=message-id:date:from:reply-to:mime-version:to:subject; bh=04nJXyo2cbkostImX3rw5RfHbREU2chh6sPkpxcggpw=; b=Zok7tchfDc9zmpjHf//bwg5gBmi6qiH6YEVTrqYk83ZzicTMTu3QsnN/ IoAmhiYnHMR0wdqEixZkb30Oz8Yc9/97ALv8lPPN53vPc13GXc5vgDm5R uItOUSzfyB5MZPCLR0b7ZrM6PmUjpuJiPORaGxajVm9ewLiJZ7z1uQN5u w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFAHKdSVKQ/khN/2dsb2JhbABagweKELkkFm0HgyQgHRYYAwIBAgFLDQgBAYgCnECHAJo1k3oDl3+ReYMl X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208,217";a="17916635" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 30 Sep 2013 15:52:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8UFqTC2029006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Sep 2013 15:52:30 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r8UFqTDW013567; Mon, 30 Sep 2013 16:52:29 +0100 (BST) Message-ID: <52499E3D.6090607@cisco.com> Date: Mon, 30 Sep 2013 16:52:29 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "status@ietf.org" Content-Type: multipart/alternative; boundary="------------010701090203050001030008" Subject: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 30 Sep 2013 15:52:47 -0000 This is a multi-part message in MIME format. --------------010701090203050001030008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian and I took a close look the SPRING charter and have edited it to get text that we think is more likely to get through the review cycles. The intent of the changes is not change the work programme, the deliverables or the networks. The purpose of the changes is to generate what we think is a viable charter that matches the intent of this list. First we added a summary of what spring is and why it is needed - that is covered by the first paragraph, the list of *example* and the following paragraph. We then note that we need bot strict and loose path specification. We then discuss the trust model We then say we start with single AS but must be able to multi-AS We call out centralized and distributed path comp. We then call out SPRING as an OAM and the need to manage SPRING. Then for data plane, control plane and management we say, try to use existing, but if that does not work we specify the process for change. Note that we talk about data planes in the plural. We then provide the deliverable as an edited version of the delivery plan. We do not explicitly call out either MPLS or IPv6 (or any other data plane), because, 1) That emerges from the use cases. 2) The charter says use the dataplanes (note the plural) and protocols that are derived from the use cases. The charter therefore set a strong expectation that whatever dataplanes need to to be used to satisfy the network need is in scope. Comments please Stewart PS you may see -04 with some cosmetic/layout changes. --------------010701090203050001030008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Adrian and I took a close look the SPRING charter
and have edited it to get text that we think is more
likely to get through the review cycles.

The intent of the changes is not change the work 
programme, the deliverables or the networks. The
purpose of the changes is to generate what we think
is a viable charter that matches the intent of
this list.

First we added a summary of what spring is and 
why it is needed - that is covered by the first
paragraph, the list of *example* and the following
paragraph.

We then note that we need bot strict and loose
path specification.

We then discuss the trust model

We then say we start with single AS but must be
able to multi-AS

We call out centralized and distributed path comp.

We then call out SPRING as an OAM and the need
to manage SPRING.

Then for data plane, control plane and management
we say, try to use existing, but if that does
not work we specify the process for change.
Note that we talk about data planes in the plural.

We then provide the deliverable as an edited
version of the delivery plan.

We do not explicitly call out either MPLS or
IPv6 (or any other data plane), because, 

1) That emerges from the use cases.
2) The charter says use the dataplanes (note the 
plural) and protocols that are derived from
the use cases.

The charter therefore set a strong expectation
that whatever dataplanes need to to be used 
to satisfy the network need is in scope.

Comments please 

Stewart

PS you may see -04 with some cosmetic/layout changes.
--------------010701090203050001030008-- From afarrel@juniper.net Mon Sep 30 12:25:07 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CA421F8F6D for ; Mon, 30 Sep 2013 12:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkHBb5LiJYUE for ; Mon, 30 Sep 2013 12:25:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id E9C7521F95D0 for ; Mon, 30 Sep 2013 12:24:50 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8UJOkff018917; Mon, 30 Sep 2013 20:24:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r8UJOjgJ018894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Sep 2013 20:24:46 +0100 From: "Adrian Farrel" To: , References: <52499E3D.6090607@cisco.com> In-Reply-To: <52499E3D.6090607@cisco.com> Date: Mon, 30 Sep 2013 20:24:44 +0100 Message-ID: <07c401cebe12$b85c0450$29140cf0$@juniper.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C5_01CEBE1B.1A22DD50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFCLD8QcesKSxnAmjdU5lkhsTSwFJr3zAdA Content-Language: en-gb X-Mailman-Approved-At: Mon, 30 Sep 2013 12:57:19 -0700 Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: afarrel@juniper.net List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 19:25:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07C5_01CEBE1B.1A22DD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit And Stewart wanted to say... http://datatracker.ietf.org/wg/spring/charter/ From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: 30 September 2013 16:52 To: status@ietf.org Subject: [Status] Updated charter - version 3 and maybe 4 Adrian and I took a close look the SPRING charter and have edited it to get text that we think is more likely to get through the review cycles. The intent of the changes is not change the work programme, the deliverables or the networks. The purpose of the changes is to generate what we think is a viable charter that matches the intent of this list. First we added a summary of what spring is and why it is needed - that is covered by the first paragraph, the list of *example* and the following paragraph. We then note that we need bot strict and loose path specification. We then discuss the trust model We then say we start with single AS but must be able to multi-AS We call out centralized and distributed path comp. We then call out SPRING as an OAM and the need to manage SPRING. Then for data plane, control plane and management we say, try to use existing, but if that does not work we specify the process for change. Note that we talk about data planes in the plural. We then provide the deliverable as an edited version of the delivery plan. We do not explicitly call out either MPLS or IPv6 (or any other data plane), because, 1) That emerges from the use cases. 2) The charter says use the dataplanes (note the plural) and protocols that are derived from the use cases. The charter therefore set a strong expectation that whatever dataplanes need to to be used to satisfy the network need is in scope. Comments please Stewart PS you may see -04 with some cosmetic/layout changes. ------=_NextPart_000_07C5_01CEBE1B.1A22DD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And Stewart wanted to = say...

 

http://datatracker.ietf.org/wg/spring/charter/=

 

From: = status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of = Stewart Bryant
Sent: 30 September 2013 16:52
To: = status@ietf.org
Subject: [Status] Updated charter - version 3 = and maybe 4

 

Adrian and I took a close =
look the SPRING charter
and have edited it to get =
text that we think is more
likely to get through =
the review cycles.
 
The =
intent of the changes is not change the work =

programme, the deliverables or the networks. =
The
purpose of the changes is to generate what we =
think
is a viable charter that matches the intent =
of
this =
list.
 
First we added a =
summary of what spring is and 
why it is needed - =
that is covered by the first
paragraph, the list of =
*example* and the =
following
paragraph.
 =
;
We then note that we need bot strict and =
loose
path =
specification.
 
We then =
discuss the trust =
model
 
We then say we =
start with single AS but must be
able to =
multi-AS
 
We call out =
centralized and distributed path =
comp.
 
We then call out =
SPRING as an OAM and the need
to manage =
SPRING.
 
Then for data =
plane, control plane and management
we say, try to =
use existing, but if that does
not work we specify =
the process for change.
Note that we talk about =
data planes in the =
plural.
 
We then provide =
the deliverable as an edited
version of the =
delivery plan.
 
We do =
not explicitly call out either MPLS or
IPv6 (or any =
other data plane), because, =

 
1) That emerges from =
the use cases.
2) The charter says use the =
dataplanes (note the 
plural) and protocols that =
are derived from
the use =
cases.
 
The charter =
therefore set a strong expectation
that whatever =
dataplanes need to to be used 
to satisfy the =
network need is in =
scope.
 
Comments please =

 
Stewart
 
PS you may see -04 with some =
cosmetic/layout =
changes.
 
 
 
------=_NextPart_000_07C5_01CEBE1B.1A22DD50-- From loa@pi.nu Mon Sep 30 18:45:47 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6114A21F8E1F for ; Mon, 30 Sep 2013 18:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTxT1-Ttl05N for ; Mon, 30 Sep 2013 18:45:42 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id CC13521F8EB5 for ; Mon, 30 Sep 2013 18:45:37 -0700 (PDT) Received: from [192.168.1.6] (unknown [112.208.84.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9EED71802039; Tue, 1 Oct 2013 03:45:18 +0200 (CEST) Message-ID: <524A292C.7040902@pi.nu> Date: Tue, 01 Oct 2013 09:45:16 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: afarrel@juniper.net, stbryant@cisco.com References: <52499E3D.6090607@cisco.com> <07c401cebe12$b85c0450$29140cf0$@juniper.net> In-Reply-To: <07c401cebe12$b85c0450$29140cf0$@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "status@ietf.org" Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 01:45:47 -0000 Adrian and Stewart, what is the value of "conjuntion"? If one group develops a spec and sends it to the owner of the technology for wglc is that "in conjunction"? /Loa On 2013-10-01 03:24, Adrian Farrel wrote: > And Stewart wanted to say... > > http://datatracker.ietf.org/wg/spring/charter/ > > *From:*status-bounces@ietf.org [mailto:status-bounces@ietf.org] *On > Behalf Of *Stewart Bryant > *Sent:* 30 September 2013 16:52 > *To:* status@ietf.org > *Subject:* [Status] Updated charter - version 3 and maybe 4 > > Adrian and I took a close look the SPRING charter > > and have edited it to get text that we think is more > > likely to get through the review cycles. > > > > The intent of the changes is not change the work > > programme, the deliverables or the networks. The > > purpose of the changes is to generate what we think > > is a viable charter that matches the intent of > > this list. > > > > First we added a summary of what spring is and > > why it is needed - that is covered by the first > > paragraph, the list of *example* and the following > > paragraph. > > > > We then note that we need bot strict and loose > > path specification. > > > > We then discuss the trust model > > > > We then say we start with single AS but must be > > able to multi-AS > > > > We call out centralized and distributed path comp. > > > > We then call out SPRING as an OAM and the need > > to manage SPRING. > > > > Then for data plane, control plane and management > > we say, try to use existing, but if that does > > not work we specify the process for change. > > Note that we talk about data planes in the plural. > > > > We then provide the deliverable as an edited > > version of the delivery plan. > > > > We do not explicitly call out either MPLS or > > IPv6 (or any other data plane), because, > > > > 1) That emerges from the use cases. > > 2) The charter says use the dataplanes (note the > > plural) and protocols that are derived from > > the use cases. > > > > The charter therefore set a strong expectation > > that whatever dataplanes need to to be used > > to satisfy the network need is in scope. > > > > Comments please > > > > Stewart > > > > PS you may see -04 with some cosmetic/layout changes. > > > > > > > > > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64