From nobody Thu Feb 4 08:27:25 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0076E1B3282; Thu, 4 Feb 2016 08:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD5fMzdvRtET; Thu, 4 Feb 2016 08:27:19 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1776B1B3281; Thu, 4 Feb 2016 08:27:18 -0800 (PST) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id u14GRHVm004965; Thu, 4 Feb 2016 17:27:17 +0100 Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id EB82FA5; Thu, 4 Feb 2016 17:27:16 +0100 (CET) Received: by mail-lb0-f182.google.com with SMTP id x4so34954073lbm.0; Thu, 04 Feb 2016 08:27:16 -0800 (PST) X-Gm-Message-State: AG10YOTHGKY73m75fiVeKyOLcp2vvOuTOD7a/TCrCATuH3XuIrVYxCbCACt5jstbj8PwrblNh7n9WLk09ms85w== X-Received: by 10.112.146.34 with SMTP id sz2mr3902872lbb.96.1454603236099; Thu, 04 Feb 2016 08:27:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.17.168 with HTTP; Thu, 4 Feb 2016 08:26:56 -0800 (PST) From: Alberto Rodriguez-Natal Date: Thu, 4 Feb 2016 17:26:56 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "lisp@ietf.org list" , nvo3@ietf.org, SDN IRTF list , nfvrg@irtf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a85c82d50dc052af43562 Archived-At: Subject: [sfc] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 16:27:23 -0000 --047d7b3a85c82d50dc052af43562 Content-Type: text/plain; charset=UTF-8 Hi all, We would like to announce the first release of OpenOverlayRouter (OOR - spelled "double-O-R"), an open-source project, under the Apache 2.0 License, to instantiate programmable overlays. OOR is edge-oriented and multiplatform (Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-deploy overlay infrastructure. OOR is based on the former LISPmob.org code. * Who can use it * OOR is intended for end-users looking for easy multihoming, companies with strong presence at the edge, startups interested in overlay solutions and researchers exploring new scenarios. * Supported protocols * OOR is interoperable with OpenDaylight and supports several protocols for both the data and control plane. On the control plane, it supports NETCONF for provisioning and management and LISP for operational state exchange. On the data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap includes L2 overlays, further encapsulations and support for SFC headers. * Code * You can find all the details and get the code at: http://openoverlayrouter.org/ Thanks! The OpenOverlayRouter team --047d7b3a85c82d50dc052af43562 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We would like to announce the first release= of OpenOverlayRouter (OOR - spelled "double-O-R"), an open-sourc= e project, under the Apache 2.0 License, to instantiate programmable overla= ys. OOR is edge-oriented and multiplatform (Android, Linux and OpenWRT) wit= h the aim to offer a flexible and easy-to-deploy overlay infrastructure. OO= R is based on the former LISPmob.org code.


* Who can use it *
OOR is intended for end-users looking for easy multihoming, companies = with strong presence at the edge, startups interested in overlay solutions = and researchers exploring new scenarios.


* Supported protocols *=

OOR is interoperable with OpenDaylight and supports several protoco= ls for both the data and control plane. On the control plane, it supports N= ETCONF for provisioning and management and LISP for operational state excha= nge. On the data plane, it supports IPv4 and IPv6 overlays with LISP and VX= LAN-GPE encapsulations. The roadmap includes L2 overlays, further encapsula= tions and support for SFC headers.


* Code *

You can find = all the details and get the code at:
http://openoverlayrouter.org/


Thanks!
The OpenOver= layRouter team
--047d7b3a85c82d50dc052af43562-- From nobody Thu Feb 4 12:00:40 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655C71AD363; Thu, 4 Feb 2016 12:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKZFXniHFjIc; Thu, 4 Feb 2016 12:00:36 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BE71AD17F; Thu, 4 Feb 2016 12:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3106; q=dns/txt; s=iport; t=1454616028; x=1455825628; h=from:to:cc:subject:date:message-id:mime-version; bh=guGEOlqEkhkf0/rj62r1Gx8sb722GPBopHaiJlJ1lHI=; b=jijbbl5NgMGMpGymWAr9B6jz71F/KGlcb6jg2zGkh7UCSPFkWEJX2FU5 4BBC/yrhowBG6lEHTfUUcRa9yd9RbJx9uiXHu0lCPEtG17Qtr3KXgT6Af WQLsctjViEC2GdRus3pozDx4qTDUUpRtXLjESBNC26rY8Evw6Wp2TR5Kd w=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgAerbNW/4UNJK1egzpSc4hVsQEOg?= =?us-ascii?q?WYhhWyBQTgUAQEBAQEBAX8LhDgMBCNWEgELAT4CNCcEDhOIDQ6xY48ZAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBDQQEhhKBbYcpglMrgQ8FlnEBgn2BY2qIBAeOao4/A?= =?us-ascii?q?R4BQ4IwgTSIGHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,396,1449532800"; d="asc'?scan'208,217";a="70165809" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2016 20:00:27 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u14K0Ql9003057 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 20:00:26 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 4 Feb 2016 15:00:26 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 4 Feb 2016 15:00:26 -0500 From: "Carlos Pignataro (cpignata)" To: "sfc-chairs@ietf.org" Thread-Topic: draft-penno-sfc-appid-03 - Using Application Identification in Services Function Chaining Metadata Thread-Index: AQHRX4awbZsOig9yj0+/ztxKVpz+aQ== Date: Thu, 4 Feb 2016 20:00:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.214.67] Content-Type: multipart/signed; boundary="Apple-Mail=_1C18D918-BCC3-486C-8B40-F59D558C890D"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "sfc@ietf.org" Subject: [sfc] draft-penno-sfc-appid-03 - Using Application Identification in Services Function Chaining Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:00:38 -0000 --Apple-Mail=_1C18D918-BCC3-486C-8B40-F59D558C890D Content-Type: multipart/alternative; boundary="Apple-Mail=_3687F9DE-AD09-4489-9745-A2F202986B42" --Apple-Mail=_3687F9DE-AD09-4489-9745-A2F202986B42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, SFC Chairs, The SFC Application Identification draft, on its fourth version, was = discussed in various SFC meetings already. We believe it is ready for WG Adoption, and we=E2=80=99d like to request = it be considered as an SFC document with an adoption call https://datatracker.ietf.org/doc/draft-penno-sfc-appid/ = Thanks, =E2=80=94 Carlos. --Apple-Mail=_3687F9DE-AD09-4489-9745-A2F202986B42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, SFC Chairs,

The SFC Application Identification draft, = on its fourth version, was discussed in various SFC meetings = already.

We = believe it is ready for WG Adoption, and we=E2=80=99d like to request it = be considered as an SFC document with an adoption call

https://datatracker.ietf.org/doc/draft-penno-sfc-appid/

Thanks,

=E2=80=94 = Carlos.
= --Apple-Mail=_3687F9DE-AD09-4489-9745-A2F202986B42-- --Apple-Mail=_1C18D918-BCC3-486C-8B40-F59D558C890D 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 iQIcBAEBCAAGBQJWs63ZAAoJEIXgpQGOZny9iqYP/0SPyy7ttW7a2PgR2ROCByNN sA4i3dz2PnVmCk6O3+p5IYwaye6wAmUTucMQ9VO/LxN8Udf/9DtvX/4GjGGNmG8S pStiZhA5Lpkp7R5cNmJCc99OEhfZ8oLyI4g87A6aR3DjK1Qn4qj8rwxoYIQgdzz6 mWB3eZSGOXWYQfRULamDNEh5+YVeJK3NEUjrGtUHLRTHBPsxRiHtoLHYd4Xo3Xei v88ngn7MweoPtWaLxoUuj0xFC1h2OSQpsdtpuz+1FSK8ajKKfd3+LqLPI+BP64im nVcDwkm2DNPPtcDaLWY/DvAFw1k8NJ8ImGMrHg8HObwyKlJ0TA+Sfhj9PTirmZCv 2p743MpFcXfCp2fT4qmJu2hbBuqDimMDnMwU3aU5+MvNkAN1NrrrmVxllG8616/g QSAp1zwl+HM+cPrNKTdjUdtmLd1QEmoU45zDZdGhhLZ6dhhzHL5cNLJUg9a4CWNd UDGTcC9WajQUca7u02SoWNGKVPrRwawMQMPst86OCKfLLV47ByW+pYRHAiI0aBJX JwH4505YCDaSbmPFIRNjrrCpDHDjVwjRZ2ZAh0NcrzkAeC55nzJK22KQbxSgcGnc HksDD2EO3ijO30ULxuAPW+8lFw3DwJ6E9FHAAkITcSA7+xkqIHrtBlsWH2exDxpj cpxKWjzGMZ1sVM+d1Atf =ecwS -----END PGP SIGNATURE----- --Apple-Mail=_1C18D918-BCC3-486C-8B40-F59D558C890D-- From nobody Thu Feb 4 12:01:31 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC91ACE9C; Thu, 4 Feb 2016 12:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH89eeK2V3QE; Thu, 4 Feb 2016 12:01:28 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA741ACEFB; Thu, 4 Feb 2016 12:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3229; q=dns/txt; s=iport; t=1454616054; x=1455825654; h=from:to:cc:subject:date:message-id:mime-version; bh=J+02nhKxIkdgiwNQIsmeEBJamkuid0Duv0lKV90xvMg=; b=LtGxxUjH6SQ9RD77KdnQxCMndhPA9toGSqKdiIuvamPhgPINDwZrHBB1 y+Xo9IXY3NEZ4I3zqFDB/RdebDEs4M/o8A5L3hiaRt75y7JxwInBTYPV/ 2SmnusDzoRWYWsTR/xpErhCjerQ7ueUJWKB0o5BVmg7rcAAQQ+iAvmqG0 4=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgCmrLNW/4wNJK1egzpSc4hVsQEOg?= =?us-ascii?q?WYhhWyBQTgUAQEBAQEBAX8LhDgMBCNWEgELAT4CNCcEDhOIDQ6xZI8bAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBDQQEhhKBbYcpglMrgQ8FlnEBgn2BY2qIBI5xjj8BH?= =?us-ascii?q?gFDg2SIGHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,396,1449532800"; d="asc'?scan'208,217";a="234907064" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2016 20:00:53 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u14K0qGH022699 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 20:00:53 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 4 Feb 2016 15:00:52 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 4 Feb 2016 15:00:51 -0500 From: "Carlos Pignataro (cpignata)" To: "sfc-chairs@ietf.org" Thread-Topic: draft-penno-sfc-trace-03 - Services Function Chaining Traceroute Thread-Index: AQHRX4a/UUya8geQr0Cr2ce1xnwv/Q== Date: Thu, 4 Feb 2016 20:00:51 +0000 Message-ID: <0D16544C-B32C-4C6C-9B57-E0A58028910F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.214.67] Content-Type: multipart/signed; boundary="Apple-Mail=_4E73E602-6B5D-40BB-9658-4EBA150758F1"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , "draft-penno-sfc-trace@ietf.org" Subject: [sfc] draft-penno-sfc-trace-03 - Services Function Chaining Traceroute X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:01:29 -0000 --Apple-Mail=_4E73E602-6B5D-40BB-9658-4EBA150758F1 Content-Type: multipart/alternative; boundary="Apple-Mail=_C5735011-778D-4EE8-AA14-51E4FDD2650E" --Apple-Mail=_C5735011-778D-4EE8-AA14-51E4FDD2650E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, SFC Chairs, The SFC Traceroute draft was presented and discussed in various SFC = meetings already. It has running code, and it is on its 4th revision. We believe it has always received good support and it is relatively = stable and solid. We=E2=80=99d like to request WG Adoption of it. https://datatracker.ietf.org/doc/draft-penno-sfc-trace/ = Thanks, =E2=80=94 Carlos. --Apple-Mail=_C5735011-778D-4EE8-AA14-51E4FDD2650E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, SFC Chairs,

The SFC Traceroute draft was presented and = discussed in various SFC meetings already. It has running code, and it = is on its 4th revision.

We believe it has always received good support and it is = relatively stable and solid.

We=E2=80=99d like to request WG = Adoption of it.

https://datatracker.ietf.org/doc/draft-penno-sfc-trace/

Thanks,

=E2=80=94 Carlos.
= --Apple-Mail=_C5735011-778D-4EE8-AA14-51E4FDD2650E-- --Apple-Mail=_4E73E602-6B5D-40BB-9658-4EBA150758F1 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 iQIcBAEBCAAGBQJWs63yAAoJEIXgpQGOZny9hoMP/j4Fo//mO4XSX2nZ/otUBVis yGQ1ABskShFxUWyNz8P918Cnv1eazt7JY9RaX5E1Dnpk8XekmTIGnzXMWatyp77e yGcB3gZYbvZ3rgQ7IJm58iIxqaZ6dzs38ki+AcZ6878muU4bxoMuL/lqOJJRdCqQ sShaOymBy5OHO8zIP9rx9cRYF49YInsplGoVLNJvPvIroDgRxJJ9pkVy/4BtzbIA qkfnRU759XBMl8Mi2CMaFRNICIWze2YGvVL2l/kXMNO1N7LvowQqb9q5x8pFkUgk AjdAcUoDHsUrXI5FvSKwsW9Y4jNW1jSSXkNyWvrW1Bfct5ujLdrBSIhRDQYDcIcY RDJFHvQVUsCJakz1K3YBns8lGflEVl3886dHqeO+LWaOuQQPS1fazzOYb1dyyvuP bg/8uLllPmY4+xW6zAbWAevIH5fgqLY8S7GOVnVMpJ4LcAxOXmz5aKs05bjz3VkE mvcNqWIVt84RIoIDOEv7mMSyw0KWU/KzUeAeG0V/8OBtNj3fcDImMYjtzF2LpJU0 QZ6mRgakobHOqJAa+vAos3ymgSAdk/cKNDNsFY7m1XpyDvndbkHlZlGHMzkC4vKT 9vLBwjTTLEn9q/khu0q/fn39ZIuHstOkjkLda4xHYwnJXTaA3aArhTwKzdNYH62W vLcxwWYf8Rb3ZmKXks4E =x1eS -----END PGP SIGNATURE----- --Apple-Mail=_4E73E602-6B5D-40BB-9658-4EBA150758F1-- From nobody Thu Feb 4 12:45:36 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542821AD289; Thu, 4 Feb 2016 12:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neK6X7NiF1hL; Thu, 4 Feb 2016 12:45:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A681AD277; Thu, 4 Feb 2016 12:45:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DA5746021AA; Thu, 4 Feb 2016 12:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454618726; bh=W6QK93HhGgzND8wSkcKe6KplAAdbd32hdeJ5x4pmp6c=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=MwEOZZW7TEngo7RFlaimew2wQtoasF+ZR8ELHA2T/+J98yCPEPiTkoj8bi9UwzMoP SmIbIxmgFPl7b9uFLhvxivcejsA0zjoiDepxaBh374GilljNZAOJPRpoHyxYhR9QQM 66xk2qbM+QSn7rBMJJd4t5bwo0jk1XXm/u3i6nVs= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5608260219B; Thu, 4 Feb 2016 12:45:26 -0800 (PST) To: "Carlos Pignataro (cpignata)" , "sfc-chairs@ietf.org" References: From: "Joel M. Halpern" Message-ID: <56B3B842.4050206@joelhalpern.com> Date: Thu, 4 Feb 2016 15:44:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-penno-sfc-appid@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] draft-penno-sfc-appid-03 - Using Application Identification in Services Function Chaining Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:45:33 -0000 Using the App-ID as defined in this draft fas part of SFC metadata makes good sense. I am however confused by the YANG model. One place it might apply is at classifiers. But we are not, as far as I know configuring classification rules. And I expect that metadata application will be as a configured blob based on the classification results. The other place it might apply is in a service function, determining the value of metadata it needs to knwo about. But service function configuration is, as far as I know, out of scope for our work. Yours, Joel On 2/4/16 3:00 PM, Carlos Pignataro (cpignata) wrote: > Hi, SFC Chairs, > > The /SFC Application Identification/ draft, on its fourth version, was > discussed in various SFC meetings already. > > We believe it is ready for WG Adoption, and we’d like to request it be > considered as an SFC document with an adoption call > > https://datatracker.ietf.org/doc/draft-penno-sfc-appid/ > > Thanks, > > — Carlos. > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 4 12:50:12 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B941AD35B; Thu, 4 Feb 2016 12:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOBUYamBtvmQ; Thu, 4 Feb 2016 12:50:09 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B491AD35A; Thu, 4 Feb 2016 12:50:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7549E6021C2; Thu, 4 Feb 2016 12:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454619006; bh=hgbUATSdSMoSALLEUSstoz9kins/U/lUc+1Zj9oFHUw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=os1hPx7MahPEI5zhCwv8sL9Sm8imAHy+fVy5bYbpcuS8frnT4bvqs00kOide2fEKI KenJfypwk1Sx5WI44GbFmzY0lLD2PTjZYsOUpsiUa0xxrI+Z8vQwYso/9HkCVs9SG3 o3FGWvgcgRwcnCzCMCFI4tFcV7FkQmbNoJQFMhC4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E6A586021BC; Thu, 4 Feb 2016 12:50:05 -0800 (PST) To: "Carlos Pignataro (cpignata)" , "sfc-chairs@ietf.org" References: <0D16544C-B32C-4C6C-9B57-E0A58028910F@cisco.com> From: "Joel M. Halpern" Message-ID: <56B3B95A.9060008@joelhalpern.com> Date: Thu, 4 Feb 2016 15:49:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <0D16544C-B32C-4C6C-9B57-E0A58028910F@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" , "draft-penno-sfc-trace@ietf.org" Subject: Re: [sfc] draft-penno-sfc-trace-03 - Services Function Chaining Traceroute X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 20:50:11 -0000 I support adoption of this draft. It is work we need as part of our solution. Yours, Joel On 2/4/16 3:00 PM, Carlos Pignataro (cpignata) wrote: > Hi, SFC Chairs, > > The *SFC Traceroute* draft was presented and discussed in various SFC > meetings already. It has running code, and it is on its 4th revision. > > We believe it has always received good support and it is relatively > stable and solid. > > We’d like to request WG Adoption of it. > > https://datatracker.ietf.org/doc/draft-penno-sfc-trace/ > > Thanks, > > — Carlos. > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Feb 5 00:06:26 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9C1A026A; Fri, 5 Feb 2016 00:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAl9puYZjarE; Fri, 5 Feb 2016 00:06:23 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519161A01A9; Fri, 5 Feb 2016 00:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7008; q=dns/txt; s=iport; t=1454659583; x=1455869183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/o7OQXiaV1pZLNPfGiKr54gWYLU4KvnViaq+ou/GF7o=; b=a4t/T1mKG93XrzE4puSkD/fKQmLhHT8t2GrNxsU9JEkacsST/CSNZsVv 2gcNFqSp2T7np8q6pObv2iikkISxYweE25VJcr+6pN9Uf8ombwYzCvVmh i5sNvPI99SRn3ySw2O7SqOC4lXv3aHd8g/LQa8CqzX/ZM/dR+hwnSkr9L E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgC0V7RW/4QNJK1egm5MUm0GiFWxD?= =?us-ascii?q?AENgWYhhWwCHIEcOBQBAQEBAQEBgQqEQQEBAQQjCkwQAgEIEQQBASgDAgICMBQ?= =?us-ascii?q?JCAIEAQ0FCIgTDrB1jnABAQEBAQEBAQEBAQEBAQEBAQEBAQERBIpJhF8JgkqBO?= =?us-ascii?q?gWWcwGFS4d9jnqOPgEeAQFCg2RqiQB8AQEB?= X-IronPort-AV: E=Sophos; i="5.22,399,1449532800"; d="scan'208,217"; a="68476662" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2016 08:06:22 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1586Mjw029063 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 08:06:22 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 02:06:21 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Fri, 5 Feb 2016 02:06:21 -0600 From: "Roberta Maglione (robmgl)" To: "Carlos Pignataro (cpignata)" , "sfc-chairs@ietf.org" Thread-Topic: [sfc] draft-penno-sfc-trace-03 - Services Function Chaining Traceroute Thread-Index: AQHRX4a/UUya8geQr0Cr2ce1xnwv/Z8dGNAQ Date: Fri, 5 Feb 2016 08:06:21 +0000 Message-ID: <60328aa3e6354a29b3baef22d07900f5@XCH-RCD-009.cisco.com> References: <0D16544C-B32C-4C6C-9B57-E0A58028910F@cisco.com> In-Reply-To: <0D16544C-B32C-4C6C-9B57-E0A58028910F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.228.113] Content-Type: multipart/alternative; boundary="_000_60328aa3e6354a29b3baef22d07900f5XCHRCD009ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , "draft-penno-sfc-trace@ietf.org" Subject: Re: [sfc] draft-penno-sfc-trace-03 - Services Function Chaining Traceroute X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 08:06:25 -0000 --_000_60328aa3e6354a29b3baef22d07900f5XCHRCD009ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBXRyBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LCB0aGlzIGlzIGEgdmVy eSB1c2VmdWwgZnVuY3Rpb24uDQpSZWdhcmRzDQpSb2JlcnRhDQoNCkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybG9zIFBpZ25hdGFybyAoY3Bp Z25hdGEpDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDQsIDIwMTYgOTowMSBQTQ0KVG86IHNm Yy1jaGFpcnNAaWV0Zi5vcmcNCkNjOiBzZmNAaWV0Zi5vcmc7IGRyYWZ0LXBlbm5vLXNmYy10cmFj ZUBpZXRmLm9yZw0KU3ViamVjdDogW3NmY10gZHJhZnQtcGVubm8tc2ZjLXRyYWNlLTAzIC0gU2Vy dmljZXMgRnVuY3Rpb24gQ2hhaW5pbmcgVHJhY2Vyb3V0ZQ0KDQpIaSwgU0ZDIENoYWlycywNCg0K VGhlIFNGQyBUcmFjZXJvdXRlIGRyYWZ0IHdhcyBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCBpbiB2 YXJpb3VzIFNGQyBtZWV0aW5ncyBhbHJlYWR5LiBJdCBoYXMgcnVubmluZyBjb2RlLCBhbmQgaXQg aXMgb24gaXRzIDR0aCByZXZpc2lvbi4NCg0KV2UgYmVsaWV2ZSBpdCBoYXMgYWx3YXlzIHJlY2Vp dmVkIGdvb2Qgc3VwcG9ydCBhbmQgaXQgaXMgcmVsYXRpdmVseSBzdGFibGUgYW5kIHNvbGlkLg0K DQpXZeKAmWQgbGlrZSB0byByZXF1ZXN0IFdHIEFkb3B0aW9uIG9mIGl0Lg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5uby1zZmMtdHJhY2UvDQoNClRoYW5rcywN Cg0K4oCUIENhcmxvcy4NCg== --_000_60328aa3e6354a29b3baef22d07900f5XCHRCD009ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzdXBwb3J0IHRoZSBXRyBhZG9wdGlvbiBvZiB0aGlz IGRvY3VtZW50LCB0aGlzIGlzIGEgdmVyeSB1c2VmdWwgZnVuY3Rpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9i ZXJ0YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDA0LCAyMDE2IDk6MDEgUE08YnI+DQo8Yj5U bzo8L2I+IHNmYy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzsg ZHJhZnQtcGVubm8tc2ZjLXRyYWNlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzZmNd IGRyYWZ0LXBlbm5vLXNmYy10cmFjZS0wMyAtIFNlcnZpY2VzIEZ1bmN0aW9uIENoYWluaW5nIFRy YWNlcm91dGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSwgU0ZDIENoYWlycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSA8Yj5TRkMgVHJhY2Vyb3V0ZTwvYj4gZHJhZnQgd2FzIHByZXNlbnRlZCBhbmQgZGlz Y3Vzc2VkIGluIHZhcmlvdXMgU0ZDIG1lZXRpbmdzIGFscmVhZHkuIEl0IGhhcyBydW5uaW5nIGNv ZGUsIGFuZCBpdCBpcyBvbiBpdHMgNHRoIHJldmlzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBiZWxpZXZlIGl0IGhhcyBhbHdheXMg cmVjZWl2ZWQgZ29vZCBzdXBwb3J0IGFuZCBpdCBpcyByZWxhdGl2ZWx5IHN0YWJsZSBhbmQgc29s aWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pldl4oCZZCBsaWtlIHRvIHJlcXVlc3QgV0cgQWRvcHRpb24gb2YgaXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVubm8tc2ZjLXRyYWNlLyI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVubm8tc2ZjLXRyYWNlLw0KPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCUIENhcmxv cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_60328aa3e6354a29b3baef22d07900f5XCHRCD009ciscocom_-- From nobody Fri Feb 5 06:23:45 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F117A1B2F0D; Fri, 5 Feb 2016 06:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrJPTJzws0Be; Fri, 5 Feb 2016 06:23:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A49A1B3961; Fri, 5 Feb 2016 06:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14110; q=dns/txt; s=iport; t=1454682220; x=1455891820; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3N5JfGMezz+iYGDcjCjhaQjWo+M0R5uvg4iNDOcws+g=; b=PCZ2Yjinddmp5S219EvkngrjHzP+TJ9zC9NJh8FznZh/krIg+eutd/y9 C4D8XDBUpEc77BP1uuscp0HTxMJ8C08+lXGtZWKrWW2PZpBoBReLgUDeK RpTBR4Raoo7c8ODmSsuL8z4sjwbddFM1r0QAz7uOWmXFdSeTbmGKla4Qx c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWBABTr7RW/4kNJK1egm5MUm0GhCmEL?= =?us-ascii?q?KEjjnR2DoFmFwEGgj+BWYFXAoEwOBQBAQEBAQEBgQqEQQEBAQIBAQEBASBLCwU?= =?us-ascii?q?LAgEIEQQBAQEnAwICJwsUCQgCBA4FDgsCh3gIDrB+jmcBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQENCIIfg3OBbQiCQoQ4ASYJCIJCK4EPBZZ1AYJ9gWRqiASCJYxOjj0?= =?us-ascii?q?BDw8BQ4FMghhqAQEBiH18AQEB?= X-IronPort-AV: E=Sophos;i="5.22,400,1449532800"; d="asc'?scan'208,217";a="68336784" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2016 14:23:39 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u15ENdcC020772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 14:23:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 09:23:38 -0500 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 5 Feb 2016 09:23:38 -0500 From: "Carlos Pignataro (cpignata)" To: Alexander Vainshtein Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2j0avRNDVouIEKwOnMGpfvWQZ8dSGwAgACOLwA= Date: Fri, 5 Feb 2016 14:23:38 +0000 Message-ID: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.54.100] Content-Type: multipart/signed; boundary="Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" , Alberto Rodriguez-Natal Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:23:43 -0000 --Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5 Content-Type: multipart/alternative; boundary="Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A" --Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sasha, It seems to me to be extremely relevant and very proper, as we want more = open source software connections with the IETF. https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf = = https://www.internetsociety.org/publications/ietf-journal-march-2015/open-= standards-open-source-open-loop = =E2=80=9CWithin the IETF, we face numerous issues around our own life = cycle. [=E2=80=A6] What does the subject matter of popular, = network-centric OSS projects imply might be missing at the IETF?=E2=80=9D =E2=80=9CHow to Make the IETF Relevant in this Environment =E2=80=A2 Fix, change, or reinvent the liaison process because it will = be critical to collaboration with OSS projects. In fact, don=E2=80=99t = even use the liaison process as a model. =E2=80=A2 Embrace Open Source projects.=E2=80=9D Thanks, =E2=80=94 Carlos. > On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein = wrote: >=20 > Is this a proper kind of message on IETF mailing lists? >=20 >=20 > From: nvo3 > on = behalf of Alberto Rodriguez-Natal > > Sent: Thursday, February 4, 2016 6:26 PM > To: lisp@ietf.org list; nvo3@ietf.org = ; SDN IRTF list; nfvrg@irtf.org = ; sfc@ietf.org > Subject: [nvo3] OpenOverlayRouter released! >=20 > Hi all, >=20 > We would like to announce the first release of OpenOverlayRouter (OOR = - spelled "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code. >=20 >=20 > * Who can use it * >=20 > OOR is intended for end-users looking for easy multihoming, companies = with strong presence at the edge, startups interested in overlay = solutions and researchers exploring new scenarios. >=20 >=20 > * Supported protocols * >=20 > OOR is interoperable with OpenDaylight and supports several protocols = for both the data and control plane. On the control plane, it supports = NETCONF for provisioning and management and LISP for operational state = exchange. On the data plane, it supports IPv4 and IPv6 overlays with = LISP and VXLAN-GPE encapsulations. The roadmap includes L2 overlays, = further encapsulations and support for SFC headers. >=20 >=20 > * Code * >=20 > You can find all the details and get the code at: > http://openoverlayrouter.org/ = >=20 >=20 > Thanks! > The OpenOverlayRouter team > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 = --Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Sasha,

It seems to me to be extremely relevant = and very proper, as we want more open source software connections with = the IETF.
https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf
https://www.internetsociety.org/publications/ietf-journal-march= -2015/open-standards-open-source-open-loop

=E2=80=9CWithin the IETF, = we face numerous issues around our own life cycle. [=E2=80=A6] What = does the subject matter of popular, network-centric OSS projects = imply might be missing at the IETF?=E2=80=9D

=E2=80=9CHow to Make the IETF Relevant in this = Environment

=E2=80=A2 Fix, = change, or reinvent the liaison process because it will be critical to = collaboration with OSS projects. In fact, don=E2=80=99t even use = the liaison process as a model.
=E2=80=A2 Embrace Open Source projects.=E2=80=9D

Thanks,

=E2=80=94 = Carlos.


On = Feb 5, 2016, at 12:54 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Is this a proper kind of =  message on  IETF mailing lists?


From: nvo3 <nvo3-bounces@ietf.org> on behalf of Alberto = Rodriguez-Natal <arnatal@ac.upc.edu>
Sent: Thursday, February 4, 2016 = 6:26 PM
To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF = list; nfvrg@irtf.org; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter = released!
 
Hi all,

We would = like to announce the first release of OpenOverlayRouter (OOR - spelled = "double-O-R"), an open-source project, under the Apache 2.0 License, to = instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code.


* Who can use it *

OOR is intended for end-users looking for easy multihoming, = companies with strong presence at the edge, startups interested in = overlay solutions and researchers exploring new scenarios.


* Supported protocols *

OOR is interoperable with OpenDaylight and = supports several protocols for both the data and control plane. On the = control plane, it supports NETCONF for provisioning and management and = LISP for operational state exchange. On the data plane, it supports IPv4 = and IPv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap = includes L2 overlays, further encapsulations and support for SFC = headers.


* Code *

You can find all the details and get the code = at:
http://openoverlayrouter.org/


Thanks!
The OpenOverlayRouter = team
_______________________________________________
nvo3 mailing = list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

= --Apple-Mail=_44D0ACB1-6E3A-4082-9799-4FAEC4135D3A-- --Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5 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 iQIcBAEBCAAGBQJWtLBqAAoJEIXgpQGOZny9bcQQAKVwP3gVK0FjL+XNzzuYtPH6 MPTZ5NhTgV+RMaWKNnPFExfFT2SYwkSaHfrQ99yuMOyXrcbRFeh6QIbq3diNLmV+ off0eoBnHMof+rzEiR+W/Yp0PjaSmYr0iULeLiF53i/m1lAnCoyHv9tA9pqoVEbz BkWIC6fz059RgIlEdOR1R5rGO/kBjZZHqWOfRFu5xw6QVb9eWMG0l1YMIZ4r5y+r Jf74Q6ABHrHM//VSCe45wbiBnNMYCOvzUKd8/yPWTtXhj9ru2MshuvP7ZD7sA/wG Nhu6cWzb7V2NKOZF0ZeZLPeZacnFAUXLZRGGo0T3QiPk62kW14lzzMSkyK0GLRAp Nj3CnE3xZIY1GM21Sv9aRZyXcABLmybFgCTsPJR9dHAtcEP8+9u+ngsmXnLL4lhv wpQpmuXGYqUzs9Jctfhua0mJJb8QB7irqXjGl7RdFiWx7o3/UjqAVeiejsfb/kZb 2gcRFIe4xUH7JyJmsAlS3eBNHKI7ZYW6ORX9Vugl08kaaSYMhW3abRCJK7L2U7sy t2rsrQn4yEe6tFxgIHKdqH/0C+omwzgBk739yj893rHzvZADFk7nNuwc3YIyrgpl ArRx3cCe9NhYlAnFgHpq/6Q/uPssexPzwUJEGSRrmTEcxhcBvzE/f662KZXXeO9Q wMBhGfsTAZijhWuK+y3d =F6p8 -----END PGP SIGNATURE----- --Apple-Mail=_D2B1ACA0-B6A0-45D5-8807-216672242AB5-- From nobody Fri Feb 5 07:08:47 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A631B3A3E; Fri, 5 Feb 2016 07:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BLEp98-Wc1k; Fri, 5 Feb 2016 07:08:39 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196271B3A38; Fri, 5 Feb 2016 07:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17518; q=dns/txt; s=iport; t=1454684918; x=1455894518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tNEwPRwA2KLU79mx4PYh/E9zytfHpTDsQ2gVEuIWZ7Q=; b=DG+Nrp2RSO/lhDtsgSOjlfwdCaHdxb08ZteuQ1uFWOtBP8C5KwXuMF71 sZLKTO74hv1r0Alg3obmn+yvNIQQPLHXKPB6x241x1yHw0beZ8Pu7L0+C HDufm3utsEUGoOOgSL3DZWOzEntxu5qgH/kLb81UdHhjZoWlH61ffgtcA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAwAOurRW/4gNJK1egm5MUl4PBoQph?= =?us-ascii?q?CyhI450dgENgWYXAQaCP4FZgVcCHIEUOBQBAQEBAQEBgQqEQQEBAQICAQEBIEs?= =?us-ascii?q?LEAIBCBEEAQEoAwICAiULFAkIAgQOBRkCiAAOsG2OZgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARWCH4NzgW2CSoQ4AQ8XCQiCQiuBDwWWdQGFS4gEgiWMTo49AQ8PAQF?= =?us-ascii?q?CgUw3GYFIagEBAYh9fAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,401,1449532800"; d="scan'208,217"; a="74193303" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Feb 2016 15:08:37 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u15F8bbt024595 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Feb 2016 15:08:37 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 5 Feb 2016 09:08:36 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Fri, 5 Feb 2016 09:08:36 -0600 From: "Paul Quinn (paulq)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2j1xsTPugnWN0uqwhbV/LDzPp8dWS8AgACOMACAAAyNAA== Date: Fri, 5 Feb 2016 15:08:36 +0000 Message-ID: <720EE3ED-688E-4DB5-8CF6-4B2D9F357348@cisco.com> References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> In-Reply-To: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.17.230] Content-Type: multipart/alternative; boundary="_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Alexander Vainshtein , SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" , Alberto Rodriguez-Natal Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 15:08:40 -0000 --_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCBzYWlkIENhcmxvcyEgIENvZGUgRlRXIQ0KDQoNCk9uIEZlYiA1LCAyMDE2LCBhdCA5OjIz IEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWls dG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3JvdGU6DQoNClNhc2hhLA0KDQpJdCBzZWVtcyB0byBt ZSB0byBiZSBleHRyZW1lbHkgcmVsZXZhbnQgYW5kIHZlcnkgcHJvcGVyLCBhcyB3ZSB3YW50IG1v cmUgb3BlbiBzb3VyY2Ugc29mdHdhcmUgY29ubmVjdGlvbnMgd2l0aCB0aGUgSUVURi4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTEvMjAxNC4xMS4xM19EV2FyZC1JRVRGLTkxLnBkZg0K aHR0cHM6Ly93d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9wdWJsaWNhdGlvbnMvaWV0Zi1qb3VybmFs LW1hcmNoLTIwMTUvb3Blbi1zdGFuZGFyZHMtb3Blbi1zb3VyY2Utb3Blbi1sb29wDQoNCuKAnFdp dGhpbiB0aGUgSUVURiwgd2UgZmFjZSBudW1lcm91cyBpc3N1ZXMgYXJvdW5kIG91ciBvd24gbGlm ZSBjeWNsZS4gW+KApl0gV2hhdCBkb2VzIHRoZSBzdWJqZWN0IG1hdHRlciBvZiBwb3B1bGFyLCBu ZXR3b3JrLWNlbnRyaWMgT1NTIHByb2plY3RzIGltcGx5IG1pZ2h0IGJlIG1pc3NpbmcgYXQgdGhl IElFVEY/4oCdDQoNCuKAnEhvdyB0byBNYWtlIHRoZSBJRVRGIFJlbGV2YW50IGluIHRoaXMgRW52 aXJvbm1lbnQNCg0K4oCiIEZpeCwgY2hhbmdlLCBvciByZWludmVudCB0aGUgbGlhaXNvbiBwcm9j ZXNzIGJlY2F1c2UgaXQgd2lsbCBiZSBjcml0aWNhbCB0byBjb2xsYWJvcmF0aW9uIHdpdGggT1NT IHByb2plY3RzLiBJbiBmYWN0LCBkb27igJl0IGV2ZW4gdXNlIHRoZSBsaWFpc29uIHByb2Nlc3Mg YXMgYSBtb2RlbC4NCuKAoiBFbWJyYWNlIE9wZW4gU291cmNlIHByb2plY3RzLuKAnQ0KDQpUaGFu a3MsDQoNCuKAlCBDYXJsb3MuDQoNCg0KT24gRmViIDUsIDIwMTYsIGF0IDEyOjU0IEFNLCBBbGV4 YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRv OkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPj4gd3JvdGU6DQoNCklzIHRoaXMgYSBw cm9wZXIga2luZCBvZiAgbWVzc2FnZSBvbiAgSUVURiBtYWlsaW5nIGxpc3RzPw0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBudm8zIDxudm8zLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBbGJlcnRv IFJvZHJpZ3Vlei1OYXRhbCA8YXJuYXRhbEBhYy51cGMuZWR1PG1haWx0bzphcm5hdGFsQGFjLnVw Yy5lZHU+Pg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgNjoyNiBQTQ0KVG86IGxp c3BAaWV0Zi5vcmc8bWFpbHRvOmxpc3BAaWV0Zi5vcmc+IGxpc3Q7IG52bzNAaWV0Zi5vcmc8bWFp bHRvOm52bzNAaWV0Zi5vcmc+OyBTRE4gSVJURiBsaXN0OyBuZnZyZ0BpcnRmLm9yZzxtYWlsdG86 bmZ2cmdAaXJ0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFtudm8zXSBPcGVuT3ZlcmxheVJvdXRlciByZWxlYXNlZCENCg0KSGkgYWxsLA0KDQpXZSB3 b3VsZCBsaWtlIHRvIGFubm91bmNlIHRoZSBmaXJzdCByZWxlYXNlIG9mIE9wZW5PdmVybGF5Um91 dGVyIChPT1IgLSBzcGVsbGVkICJkb3VibGUtTy1SIiksIGFuIG9wZW4tc291cmNlIHByb2plY3Qs IHVuZGVyIHRoZSBBcGFjaGUgMi4wIExpY2Vuc2UsIHRvIGluc3RhbnRpYXRlIHByb2dyYW1tYWJs ZSBvdmVybGF5cy4gT09SIGlzIGVkZ2Utb3JpZW50ZWQgYW5kIG11bHRpcGxhdGZvcm0gKEFuZHJv aWQsIExpbnV4IGFuZCBPcGVuV1JUKSB3aXRoIHRoZSBhaW0gdG8gb2ZmZXIgYSBmbGV4aWJsZSBh bmQgZWFzeS10by1kZXBsb3kgb3ZlcmxheSBpbmZyYXN0cnVjdHVyZS4gT09SIGlzIGJhc2VkIG9u IHRoZSBmb3JtZXIgTElTUG1vYi5vcmc8aHR0cDovL2xpc3Btb2Iub3JnLz4gY29kZS4NCg0KDQoq IFdobyBjYW4gdXNlIGl0ICoNCg0KT09SIGlzIGludGVuZGVkIGZvciBlbmQtdXNlcnMgbG9va2lu ZyBmb3IgZWFzeSBtdWx0aWhvbWluZywgY29tcGFuaWVzIHdpdGggc3Ryb25nIHByZXNlbmNlIGF0 IHRoZSBlZGdlLCBzdGFydHVwcyBpbnRlcmVzdGVkIGluIG92ZXJsYXkgc29sdXRpb25zIGFuZCBy ZXNlYXJjaGVycyBleHBsb3JpbmcgbmV3IHNjZW5hcmlvcy4NCg0KDQoqIFN1cHBvcnRlZCBwcm90 b2NvbHMgKg0KDQpPT1IgaXMgaW50ZXJvcGVyYWJsZSB3aXRoIE9wZW5EYXlsaWdodCBhbmQgc3Vw cG9ydHMgc2V2ZXJhbCBwcm90b2NvbHMgZm9yIGJvdGggdGhlIGRhdGEgYW5kIGNvbnRyb2wgcGxh bmUuIE9uIHRoZSBjb250cm9sIHBsYW5lLCBpdCBzdXBwb3J0cyBORVRDT05GIGZvciBwcm92aXNp b25pbmcgYW5kIG1hbmFnZW1lbnQgYW5kIExJU1AgZm9yIG9wZXJhdGlvbmFsIHN0YXRlIGV4Y2hh bmdlLiBPbiB0aGUgZGF0YSBwbGFuZSwgaXQgc3VwcG9ydHMgSVB2NCBhbmQgSVB2NiBvdmVybGF5 cyB3aXRoIExJU1AgYW5kIFZYTEFOLUdQRSBlbmNhcHN1bGF0aW9ucy4gVGhlIHJvYWRtYXAgaW5j bHVkZXMgTDIgb3ZlcmxheXMsIGZ1cnRoZXIgZW5jYXBzdWxhdGlvbnMgYW5kIHN1cHBvcnQgZm9y IFNGQyBoZWFkZXJzLg0KDQoNCiogQ29kZSAqDQoNCllvdSBjYW4gZmluZCBhbGwgdGhlIGRldGFp bHMgYW5kIGdldCB0aGUgY29kZSBhdDoNCmh0dHA6Ly9vcGVub3ZlcmxheXJvdXRlci5vcmcvPGh0 dHA6Ly93ZWJkZWZlbmNlLmdsb2JhbC5ibGFja3NwaWRlci5jb20vdXJsd3JhcC8/cT1BWGljSmNx eERjSkFEQUJBUzB6QUl2OTVrUVlxT21vb29YSWVpN3prMkpIanZNZ2VqTVFNekJNRVY5OTJBN2NQ d09zTllMdzBxUXVUMVRCZzRhemlwaHl5RGpDbjluUTVYM09UOW1uWEFqSTlVZTVrb1dLUnFYY3Fj cVJjbkpoLXYzY2ZEekhxU0tLVmpIRXhuZjM3MVI0Ul9sYTdhaWdvJlo+DQoNCg0KVGhhbmtzIQ0K VGhlIE9wZW5PdmVybGF5Um91dGVyIHRlYW0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0KbnZvM0BpZXRmLm9yZzxtYWls dG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg0K --_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KV2VsbCBzYWlkIENhcmxvcyEgJm5i c3A7Q29kZSBGVFchDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEZlYiA1LCAyMDE2LCBhdCA5OjIzIEFNLCBDYXJsb3Mg UGlnbmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5j b20iIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5TYXNoYSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkl0IHNlZW1zIHRvIG1lIHRvIGJlIGV4dHJlbWVseSByZWxldmFudCBh bmQgdmVyeSBwcm9wZXIsIGFzIHdlIHdhbnQgbW9yZSBvcGVuIHNvdXJjZSBzb2Z0d2FyZSBjb25u ZWN0aW9ucyB3aXRoIHRoZSBJRVRGLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkxLzIwMTQuMTEuMTNfRFdhcmQtSUVURi05MS5wZGYi IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21lZXRpbmcvOTEvMjAxNC4xMS4xM19EV2Fy ZC1JRVRGLTkxLnBkZjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9wdWJsaWNhdGlvbnMvaWV0Zi1qb3VybmFsLW1hcmNoLTIw MTUvb3Blbi1zdGFuZGFyZHMtb3Blbi1zb3VyY2Utb3Blbi1sb29wIiBjbGFzcz0iIj5odHRwczov L3d3dy5pbnRlcm5ldHNvY2lldHkub3JnL3B1YmxpY2F0aW9ucy9pZXRmLWpvdXJuYWwtbWFyY2gt MjAxNS9vcGVuLXN0YW5kYXJkcy1vcGVuLXNvdXJjZS1vcGVuLWxvb3A8L2E+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0i Ij7igJxXaXRoaW4gdGhlIElFVEYsIHdlIGZhY2UgbnVtZXJvdXMgaXNzdWVzIGFyb3VuZCBvdXIg b3duIGxpZmUgY3ljbGUuIFvigKZdJm5ic3A7V2hhdCBkb2VzJm5ic3A7dGhlIHN1YmplY3QgbWF0 dGVyIG9mIHBvcHVsYXIsIG5ldHdvcmstY2VudHJpYyBPU1MgcHJvamVjdHMgaW1wbHkgbWlnaHQm bmJzcDtiZSBtaXNzaW5nIGF0IHRoZSBJRVRGP+KAnTwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGkgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBj bGFzcz0iIj7igJxIb3cgdG8gTWFrZSB0aGUgSUVURiBSZWxldmFudCBpbiB0aGlzIEVudmlyb25t ZW50PC9pPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48aSBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPuKAoiBGaXgsIGNoYW5nZSwg b3IgcmVpbnZlbnQgdGhlIGxpYWlzb24gcHJvY2VzcyBiZWNhdXNlIGl0IHdpbGwgYmUgY3JpdGlj YWwgdG8gY29sbGFib3JhdGlvbiB3aXRoIE9TUyBwcm9qZWN0cy4mbmJzcDtJbiBmYWN0LCBkb27i gJl0IGV2ZW4gdXNlIHRoZSBsaWFpc29uIHByb2Nlc3MgYXMgYSBtb2RlbC48YnIgY2xhc3M9IiI+ DQo8L2k+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxpIGNsYXNzPSIiPuKAoiBFbWJyYWNlIE9wZW4g U291cmNlIHByb2plY3RzLuKAnTwvaT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBGZWIgNSwgMjAxNiwgYXQgMTI6NTQgQU0sIEFsZXhhbmRlciBWYWluc2h0ZWluICZsdDs8YSBo cmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIGNsYXNzPSIiPkFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg aWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQt c2l6ZTogMTJwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIFRpbWVzLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IiBjbGFzcz0iIj5JcyB0 aGlzIGEgcHJvcGVyIGtpbmQgb2YgJm5ic3A7bWVzc2FnZSBvbiAmbmJzcDtJRVRGIG1haWxpbmcg bGlzdHM/PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSIi IGNsYXNzPSIiPg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZS1ibG9j azsgd2lkdGg6IDY3Ny4xNzE4NzVweDsiIGNsYXNzPSIiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1z ZyIgZGlyPSJsdHIiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5Gcm9tOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+bnZvMyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bnZvMy1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsgb24NCiBiZWhhbGYgb2YgQWxiZXJ0byBSb2RyaWd1ZXotTmF0YWwg Jmx0OzxhIGhyZWY9Im1haWx0bzphcm5hdGFsQGFjLnVwYy5lZHUiIGNsYXNzPSIiPmFybmF0YWxA YWMudXBjLmVkdTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBG ZWJydWFyeSA0LCAyMDE2IDY6MjYgUE08YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpsaXNwQGlldGYub3JnIiBjbGFzcz0iIj5saXNwQGlldGYub3JnPC9hPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5saXN0OzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bnZv M0BpZXRmLm9yZyIgY2xhc3M9IiI+bnZvM0BpZXRmLm9yZzwvYT47DQogU0ROIElSVEYgbGlzdDs8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOm5mdnJnQGlydGYub3JnIiBjbGFzcz0iIj5uZnZyZ0BpcnRmLm9yZzwvYT47PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpzZmNAaWV0Zi5vcmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+W252bzNdIE9wZW5PdmVybGF5Um91dGVyIHJlbGVhc2VkITwvZm9udD4N CjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBhbGwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K V2Ugd291bGQgbGlrZSB0byBhbm5vdW5jZSB0aGUgZmlyc3QgcmVsZWFzZSBvZiBPcGVuT3Zlcmxh eVJvdXRlciAoT09SIC0gc3BlbGxlZCAmcXVvdDtkb3VibGUtTy1SJnF1b3Q7KSwgYW4gb3Blbi1z b3VyY2UgcHJvamVjdCwgdW5kZXIgdGhlIEFwYWNoZSAyLjAgTGljZW5zZSwgdG8gaW5zdGFudGlh dGUgcHJvZ3JhbW1hYmxlIG92ZXJsYXlzLiBPT1IgaXMgZWRnZS1vcmllbnRlZCBhbmQgbXVsdGlw bGF0Zm9ybSAoQW5kcm9pZCwgTGludXggYW5kIE9wZW5XUlQpIHdpdGgNCiB0aGUgYWltIHRvIG9m ZmVyIGEgZmxleGlibGUgYW5kIGVhc3ktdG8tZGVwbG95IG92ZXJsYXkgaW5mcmFzdHJ1Y3R1cmUu IE9PUiBpcyBiYXNlZCBvbiB0aGUgZm9ybWVyPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9saXNwbW9iLm9yZy8iIGNsYXNzPSIi PkxJU1Btb2Iub3JnPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5jb2RlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiogV2hvIGNhbiB1c2UgaXQgKjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9PUiBpcyBp bnRlbmRlZCBmb3IgZW5kLXVzZXJzIGxvb2tpbmcgZm9yIGVhc3kgbXVsdGlob21pbmcsIGNvbXBh bmllcyB3aXRoIHN0cm9uZyBwcmVzZW5jZSBhdCB0aGUgZWRnZSwgc3RhcnR1cHMgaW50ZXJlc3Rl ZCBpbiBvdmVybGF5IHNvbHV0aW9ucyBhbmQgcmVzZWFyY2hlcnMgZXhwbG9yaW5nIG5ldyBzY2Vu YXJpb3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBTdXBw b3J0ZWQgcHJvdG9jb2xzICo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPT1IgaXMgaW50 ZXJvcGVyYWJsZSB3aXRoIE9wZW5EYXlsaWdodCBhbmQgc3VwcG9ydHMgc2V2ZXJhbCBwcm90b2Nv bHMgZm9yIGJvdGggdGhlIGRhdGEgYW5kIGNvbnRyb2wgcGxhbmUuIE9uIHRoZSBjb250cm9sIHBs YW5lLCBpdCBzdXBwb3J0cyBORVRDT05GIGZvciBwcm92aXNpb25pbmcgYW5kIG1hbmFnZW1lbnQg YW5kIExJU1AgZm9yIG9wZXJhdGlvbmFsIHN0YXRlIGV4Y2hhbmdlLiBPbiB0aGUgZGF0YSBwbGFu ZSwgaXQgc3VwcG9ydHMgSVB2NA0KIGFuZCBJUHY2IG92ZXJsYXlzIHdpdGggTElTUCBhbmQgVlhM QU4tR1BFIGVuY2Fwc3VsYXRpb25zLiBUaGUgcm9hZG1hcCBpbmNsdWRlcyBMMiBvdmVybGF5cywg ZnVydGhlciBlbmNhcHN1bGF0aW9ucyBhbmQgc3VwcG9ydCBmb3IgU0ZDIGhlYWRlcnMuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiBDb2RlICo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3UgY2FuIGZpbmQgYWxsIHRoZSBkZXRhaWxzIGFuZCBnZXQg dGhlIGNvZGUgYXQ6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3dlYmRlZmVuY2UuZ2xv YmFsLmJsYWNrc3BpZGVyLmNvbS91cmx3cmFwLz9xPUFYaWNKY3F4RGNKQURBQkFTMHpBSXY5NWtR WXFPbW9vb1hJZWk3emsySkhqdk1nZWpNUU16Qk1FVjk5MkE3Y1B3T3NOWUx3MHFRdVQxVEJnNGF6 aXBoeXlEakNuOW5RNVgzT1Q5bW5YQWpJOVVlNWtvV0tScVhjcWNxUmNuSmgtdjNjZkR6SHFTS0tW akhFeG5mMzcxUjRSX2xhN2FpZ28mYW1wO1oiIGNsYXNzPSIiPmh0dHA6Ly9vcGVub3ZlcmxheXJv dXRlci5vcmcvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClRoYW5rcyE8YnIgY2xhc3M9IiI+DQpUaGUgT3Blbk92ZXJsYXlSb3V0ZXIgdGVhbTwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPm52bzMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5u dm8zQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zIiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMzwvYT48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm52bzMgbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIGNs YXNzPSIiPm52bzNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9udm8zPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_720EE3ED688E4DB58CF64B2D9F357348ciscocom_-- From nobody Fri Feb 5 08:39:25 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4D1B3B45; Fri, 5 Feb 2016 08:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKdbJwyHPuQ1; Fri, 5 Feb 2016 08:39:17 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325EA1B3B30; Fri, 5 Feb 2016 08:39:17 -0800 (PST) Received: by mail-pa0-x229.google.com with SMTP id ho8so36533191pac.2; Fri, 05 Feb 2016 08:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hdBfi4CSJ28N3VYcOnPxJS0iXk+guQHpKfIH1M71eE8=; b=IQuBepzgpHVsIu48Q9ZOUJ4i6bW2Tf8I/juCxVKCgMLuv8PMHPUXurYHc0pmMkB+zw a/tgV5hW06ZSAYx7QiiYzV6cThU1VApxyW80C+JxDwwvfLkA4n35V1NIm6rQjRnINjDt k1/7oXjPW5wsX8KyOvGCX7hybt3coyB1KBcTenwtQPMTMZ9z7wwMu7R4+jTul285h5xY wVd6rUPIUIOrxoq8zbrl1qUH1NUXgrCaDF9wjm2wApSPVaPr8IpmNMmatEwAu4YK8100 jqiqj83GlJQS/8ozbWvIi6sBK9EKvgg0pZFqszgC4pDpabyZET6cO3UKfsj6d8/2GjXy anug== 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:cc:content-transfer-encoding:message-id:references :to; bh=hdBfi4CSJ28N3VYcOnPxJS0iXk+guQHpKfIH1M71eE8=; b=kNe9LxvgbhvidKvhcKDjcJUIburazY/zbr1vl7DrOtaym24riX2VY1DuwiyI7WbXg9 ws0iezfcxIMRf5JFBt5YOkSCJaMC420d5nlt9QBCThV7rCXP/6IhlXwCvJ6eogD0C6qd R6y8q931hizbXBt9kwy5+Cnoj1pofkwFuYUa+z8k1LdRtALmDsDeUjiKPO5dFTTa+BWl bsuOEqwUmPgDTsURkmdcoSUcjWfpbB0mHdbhk8t41iQl5ZWIRReqIT0mwd96iCwrnJmL kUjtc7vj5aQHn1MCJ+p/7mzZ4au3wmfgVWTRj0pE0PkPeNa9lpyWzbJI1t09eFdFeBDh 8m5A== X-Gm-Message-State: AG10YOS4iuFj8jLa+Wv1XxGazt4R6rMZHwPY+L1P9e8JVG/KjkEMFL1He2B+deaShFTztg== X-Received: by 10.66.124.164 with SMTP id mj4mr13598046pab.128.1454690356804; Fri, 05 Feb 2016 08:39:16 -0800 (PST) Received: from [10.0.0.48] (c-98-248-50-149.hsd1.ca.comcast.net. [98.248.50.149]) by smtp.gmail.com with ESMTPSA id n4sm25704772pfi.3.2016.02.05.08.39.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 08:39:15 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (13D15) In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> Date: Fri, 5 Feb 2016 08:39:13 -0800 Content-Transfer-Encoding: 7bit Message-Id: <8C368751-8559-414E-AA92-CBC0B32766A0@gmail.com> References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> To: "MORTON, ALFRED C (AL)" Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , Alexander Vainshtein , SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" , Alberto Rodriguez-Natal Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:39:20 -0000 --Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ++ Overlays probably the most sustainable artifact of network virtualization tr= end. Good to distill distinct overlay notions into practical code base combining t= hem. Further build from there in parallel to formal interface standardization. --szb > On Feb 5, 2016, at 6:53 AM, MORTON, ALFRED C (AL) wrote= : >=20 > +1 Carlos, and Running Code has *always* been of interest here. > Al > =20 > From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of Carlos Pignataro (= cpignata) > Sent: Friday, February 05, 2016 9:24 AM > To: Alexander Vainshtein > Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; nfvrg@= irtf.org; Alberto Rodriguez-Natal > Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter released! > =20 > Sasha, > =20 > It seems to me to be extremely relevant and very proper, as we want more o= pen source software connections with the IETF. > https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf > https://www.internetsociety.org/publications/ietf-journal-march-2015/open-= standards-open-source-open-loop > =20 > =E2=80=9CWithin the IETF, we face numerous issues around our own life cycl= e. [=E2=80=A6] What does the subject matter of popular, network-centric OSS p= rojects imply might be missing at the IETF?=E2=80=9D > =20 > =E2=80=9CHow to Make the IETF Relevant in this Environment > =20 > =E2=80=A2 Fix, change, or reinvent the liaison process because it will be c= ritical to collaboration with OSS projects. In fact, don=E2=80=99t even use t= he liaison process as a model. > =E2=80=A2 Embrace Open Source projects.=E2=80=9D > =20 > Thanks, > =20 > =E2=80=94 Carlos. > =20 > =20 > On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein wrote: > =20 > Is this a proper kind of message on IETF mailing lists? > =20 >=20 > From: nvo3 on behalf of Alberto Rodriguez-Natal > Sent: Thursday, February 4, 2016 6:26 PM > To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; sfc@= ietf.org > Subject: [nvo3] OpenOverlayRouter released! > =20 > Hi all, >=20 > We would like to announce the first release of OpenOverlayRouter (OOR - sp= elled "double-O-R"), an open-source project, under the Apache 2.0 License, t= o instantiate programmable overlays. OOR is edge-oriented and multiplatform (= Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-dep= loy overlay infrastructure. OOR is based on the former LISPmob.org code. >=20 >=20 > * Who can use it * >=20 > OOR is intended for end-users looking for easy multihoming, companies with= strong presence at the edge, startups interested in overlay solutions and r= esearchers exploring new scenarios. >=20 >=20 > * Supported protocols * >=20 > OOR is interoperable with OpenDaylight and supports several protocols for b= oth the data and control plane. On the control plane, it supports NETCONF fo= r provisioning and management and LISP for operational state exchange. On th= e data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE enc= apsulations. The roadmap includes L2 overlays, further encapsulations and su= pport for SFC headers. >=20 >=20 > * Code * >=20 > You can find all the details and get the code at: > http://openoverlayrouter.org/ >=20 >=20 > Thanks! > The OpenOverlayRouter team > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > =20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 --Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
++
Overlays probably the most sustainable artifact of network virtualization t= rend.
Good to distill distinct overlay n= otions into practical code base combining them.
Further build from there in parallel to formal interface standardiza= tion.


--szb

On Feb= 5, 2016, at 6:53 AM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:

+1 Carlos, and Running Code has *always* been of intere= st here.

Al

 

From: Nfvrg [= mailto:nfvrg-bounces@irtf.org]= On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, Feb= ruary 05, 2016 9:24 AM
To: Alexander Vainshtein
Cc: SDN I= RTF list; lisp@ietf.org list; sfc@ietf.org; nvo= 3@ietf.org; nfvrg@irtf.org; Albert= o Rodriguez-Natal
Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter re= leased!

 <= /o:p>

Sasha,

 

It se= ems to me to be extremely relevant and very proper, as we want more open sou= rce software connections with the IETF.

 

=E2= =80=9CWithin the IETF, we face numerous issues around our own life cycle. [=E2= =80=A6] What does the subject matter of popular, network-centric O= SS projects imply might be missing at the IETF?=E2=80=9D=

 

=E2=80=9CHow to Make the IETF Relevant in this Environme= nt

 

=

=E2=80=A2 Fix, change, or reinvent the l= iaison process because it will be critical to collaboration with OSS project= s. In fact, don=E2=80=99t even use the liaison process as a model.<= o:p>

=E2=80=A2 Embrace Open So= urce projects.=E2=80=9D

=  

Thanks,

 

=E2=80=94 Carlos.

 

 

On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

 

 

From: nvo3 <nv= o3-bounces@ietf.org> on behalf of Alberto Rodriguez-Natal <arnatal@ac.upc.edu>
Sent: Thursday, February 4, 2016 6= :26 PM
To: lisp@ietf.org list; = nvo3@ietf.org; SDN IRTF list; n= fvrg@irtf.org; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter released!=

 =

Hi all,

We would like to announce the first release of Ope= nOverlayRouter (OOR - spelled "double-O-R"), an open-source project, under t= he Apache 2.0 License, to instantiate programmable overlays. OOR is edge-ori= ented and multiplatform (Android, Linux and OpenWRT) with the aim to offer a= flexible and easy-to-deploy overlay infrastructure. OOR is based on the for= mer LISPmob.org = code.


* Who can use it *

OOR is intended for end-users loo= king for easy multihoming, companies with strong presence at the edge, start= ups interested in overlay solutions and researchers exploring new scenarios.=


* Supported protocols *

OOR is interoperable with OpenDay= light and supports several protocols for both the data and control plane. On= the control plane, it supports NETCONF for provisioning and management and L= ISP for operational state exchange. On the data plane, it supports IPv4 and I= Pv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap includes L2= overlays, further encapsulations and support for SFC headers.


* C= ode *

You can find all the details and get the code at:
http:= //openoverlayrouter.org/


Thanks!
The OpenOverlayRouter tea= m

_= ______________________________________________
nvo3 mailing list
nvo3@ietf.org
<= span style=3D"font-size:9.0pt;font-family:"Helvetica","sans-s= erif"">https://www.ietf.org/mailman/listinfo/nvo3=

 

___________= ____________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.or= g/mailman/listinfo/nvo3
= --Apple-Mail-6E8DDD13-52AD-4E5E-9F48-E8DB498832FB-- From nobody Sun Feb 7 08:04:27 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7D61B35D7; Thu, 4 Feb 2016 21:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM8grWqaeKVw; Thu, 4 Feb 2016 21:54:47 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0102.outbound.protection.outlook.com [104.47.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83831B35D1; Thu, 4 Feb 2016 21:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m7DZMZf8l/ATP+auT63y0S3sT5Z1i40WaDjdBuI2zwE=; b=gWWqiFvYJIMRkZf+mCODYq33ex0t0fISrV0beTkAYoY0aIn20v4ONfpaWMuQQM8kk3AXl97jISlJWpN5UySuzv62IoKBAxFFBza6zPYoWj+xD1PIyBYlQLnoFUNpbuD2rEvhrNdtp1r5tpoPDx0ww1tp00lSRwqPSCa7g0EKq1k= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 5 Feb 2016 05:54:44 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0396.020; Fri, 5 Feb 2016 05:54:44 +0000 From: Alexander Vainshtein To: Alberto Rodriguez-Natal , "lisp@ietf.org list" , "nvo3@ietf.org" , SDN IRTF list , "nfvrg@irtf.org" , "sfc@ietf.org" Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2jz4A1OabkdbU2B2yaF8oT/fp8c9FCs Date: Fri, 5 Feb 2016 05:54:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ac.upc.edu; dkim=none (message not signed) header.d=none;ac.upc.edu; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [164.40.145.154] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0780; 5:7TjDzULx2Zn6HptkpX7PJXjLOu5uGPDPo8ep/r813df8egnct3LQKCsoeZLrQhhHCO/ykPcrTvgVWBoKvMQQvezQPxvvDlEchn+g0aNBc1dpblh1yf9Jbi4ttMYpbCrJGQWypu4Ki0uJaZYCzgBOdA==; 24:44Ln6JIELgzvTdvpA2HOzlMCPO4bDxtI1W5s7J4jH4Hb+hoChJtg9e+NBRZm2DtZwoZKBv3XrNA9yl5d5RKgkhORWuC8FR8WvsD3U5ALkiA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0780; x-ms-office365-filtering-correlation-id: c4a1d411-82f6-4eb5-291e-08d32df0d931 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB3PR03MB0780; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0780; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(2201001)(74316001)(19617315012)(19625215002)(107886002)(1220700001)(3280700002)(87936001)(189998001)(86362001)(1096002)(102836003)(5008740100001)(19580395003)(586003)(15395725005)(5002640100001)(5001960100002)(11100500001)(16236675004)(40100003)(19580405001)(2501003)(33656002)(15975445007)(92566002)(6116002)(2950100001)(66066001)(106116001)(122556002)(50986999)(76176999)(77096005)(54356999)(3846002)(19627405001)(3660700001)(2906002)(10400500002)(226693001)(2900100001)(5004730100002)(5003600100002)(3900700001)(5001770100001)(2171001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0780; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2016 05:54:44.8025 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0780 Archived-At: X-Mailman-Approved-At: Sun, 07 Feb 2016 08:04:25 -0800 Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 05:54:50 -0000 --_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is this a proper kind of message on IETF mailing lists? ________________________________ From: nvo3 on behalf of Alberto Rodriguez-Natal Sent: Thursday, February 4, 2016 6:26 PM To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; sfc@i= etf.org Subject: [nvo3] OpenOverlayRouter released! Hi all, We would like to announce the first release of OpenOverlayRouter (OOR - spe= lled "double-O-R"), an open-source project, under the Apache 2.0 License, t= o instantiate programmable overlays. OOR is edge-oriented and multiplatform= (Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-= deploy overlay infrastructure. OOR is based on the former LISPmob.org code. * Who can use it * OOR is intended for end-users looking for easy multihoming, companies with = strong presence at the edge, startups interested in overlay solutions and r= esearchers exploring new scenarios. * Supported protocols * OOR is interoperable with OpenDaylight and supports several protocols for b= oth the data and control plane. On the control plane, it supports NETCONF f= or provisioning and management and LISP for operational state exchange. On = the data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE = encapsulations. The roadmap includes L2 overlays, further encapsulations an= d support for SFC headers. * Code * You can find all the details and get the code at: http://openoverlayrouter.org/ Thanks! The OpenOverlayRouter team --_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Is this a proper kind of  message on  IETF mailing lists?



From: nvo3 <nvo3-bounces= @ietf.org> on behalf of Alberto Rodriguez-Natal <arnatal@ac.upc.edu&g= t;
Sent: Thursday, February 4, 2016 6:26 PM
To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org= ; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter released!
 
Hi all,

We would like to announce the first release of OpenOverlayRouter (OOR - spe= lled "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and mul= tiplatform (Android, Linux and OpenWRT) with the aim to offer a flexible and easy-to-deploy overlay infrastructure. OOR= is based on the former LISPmob.org code.


* Who can use it *

OOR is intended for end-users looking for easy multihoming, companies with = strong presence at the edge, startups interested in overlay solutions and r= esearchers exploring new scenarios.


* Supported protocols *

OOR is interoperable with OpenDaylight and supports several protocols for b= oth the data and control plane. On the control plane, it supports NETCONF f= or provisioning and management and LISP for operational state exchange. On = the data plane, it supports IPv4 and IPv6 overlays with LISP and VXLAN-GPE encapsulations. The roadmap incl= udes L2 overlays, further encapsulations and support for SFC headers.


* Code *

You can find all the details and get the code at:
http://openoverlayrouter.org/


Thanks!
The OpenOverlayRouter team
--_000_DB3PR03MB0780DA2CE529B076DCBBD9379DD20DB3PR03MB0780eurp_-- From nobody Sun Feb 7 08:04:29 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333A61B39F9; Fri, 5 Feb 2016 06:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gey2QHOzqK-b; Fri, 5 Feb 2016 06:53:24 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id B4CD91B39F1; Fri, 5 Feb 2016 06:53:23 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id EBA441229CE; Fri, 5 Feb 2016 09:56:12 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id AE332E1008; Fri, 5 Feb 2016 09:50:16 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Fri, 5 Feb 2016 09:53:22 -0500 From: "MORTON, ALFRED C (AL)" To: "Carlos Pignataro (cpignata)" , Alexander Vainshtein Date: Fri, 5 Feb 2016 09:53:21 -0500 Thread-Topic: [nvo3] OpenOverlayRouter released! Thread-Index: AQHRX2j0avRNDVouIEKwOnMGpfvWQZ8dSGwAgACOLwD//7RG4A== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> In-Reply-To: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 07 Feb 2016 08:04:25 -0800 Cc: SDN IRTF list , "lisp@ietf.org list" , "sfc@ietf.org" , "nvo3@ietf.org" , "nfvrg@irtf.org" , Alberto Rodriguez-Natal Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 14:53:26 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgQ2FybG9zLCBhbmQgUnVubmluZyBDb2RlIGhhcyAqYWx3YXlzKiBiZWVuIG9mIGludGVyZXN0 IGhlcmUuDQpBbA0KDQpGcm9tOiBOZnZyZyBbbWFpbHRvOm5mdnJnLWJvdW5jZXNAaXJ0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNClNlbnQ6IEZyaWRheSwg RmVicnVhcnkgMDUsIDIwMTYgOToyNCBBTQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluDQpDYzog U0ROIElSVEYgbGlzdDsgbGlzcEBpZXRmLm9yZyBsaXN0OyBzZmNAaWV0Zi5vcmc7IG52bzNAaWV0 Zi5vcmc7IG5mdnJnQGlydGYub3JnOyBBbGJlcnRvIFJvZHJpZ3Vlei1OYXRhbA0KU3ViamVjdDog UmU6IFtOZnZyZ10gW252bzNdIE9wZW5PdmVybGF5Um91dGVyIHJlbGVhc2VkIQ0KDQpTYXNoYSwN Cg0KSXQgc2VlbXMgdG8gbWUgdG8gYmUgZXh0cmVtZWx5IHJlbGV2YW50IGFuZCB2ZXJ5IHByb3Bl ciwgYXMgd2Ugd2FudCBtb3JlIG9wZW4gc291cmNlIHNvZnR3YXJlIGNvbm5lY3Rpb25zIHdpdGgg dGhlIElFVEYuDQpodHRwczovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzkxLzIwMTQuMTEuMTNfRFdh cmQtSUVURi05MS5wZGYNCmh0dHBzOi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvcHVibGljYXRp b25zL2lldGYtam91cm5hbC1tYXJjaC0yMDE1L29wZW4tc3RhbmRhcmRzLW9wZW4tc291cmNlLW9w ZW4tbG9vcA0KDQrigJxXaXRoaW4gdGhlIElFVEYsIHdlIGZhY2UgbnVtZXJvdXMgaXNzdWVzIGFy b3VuZCBvdXIgb3duIGxpZmUgY3ljbGUuIFvigKZdIFdoYXQgZG9lcyB0aGUgc3ViamVjdCBtYXR0 ZXIgb2YgcG9wdWxhciwgbmV0d29yay1jZW50cmljIE9TUyBwcm9qZWN0cyBpbXBseSBtaWdodCBi ZSBtaXNzaW5nIGF0IHRoZSBJRVRGP+KAnQ0KDQrigJxIb3cgdG8gTWFrZSB0aGUgSUVURiBSZWxl dmFudCBpbiB0aGlzIEVudmlyb25tZW50DQoNCuKAoiBGaXgsIGNoYW5nZSwgb3IgcmVpbnZlbnQg dGhlIGxpYWlzb24gcHJvY2VzcyBiZWNhdXNlIGl0IHdpbGwgYmUgY3JpdGljYWwgdG8gY29sbGFi b3JhdGlvbiB3aXRoIE9TUyBwcm9qZWN0cy4gSW4gZmFjdCwgZG9u4oCZdCBldmVuIHVzZSB0aGUg bGlhaXNvbiBwcm9jZXNzIGFzIGEgbW9kZWwuDQrigKIgRW1icmFjZSBPcGVuIFNvdXJjZSBwcm9q ZWN0cy7igJ0NCg0KVGhhbmtzLA0KDQrigJQgQ2FybG9zLg0KDQoNCk9uIEZlYiA1LCAyMDE2LCBh dCAxMjo1NCBBTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+IHdyb3Rl Og0KDQpJcyB0aGlzIGEgcHJvcGVyIGtpbmQgb2YgIG1lc3NhZ2Ugb24gIElFVEYgbWFpbGluZyBs aXN0cz8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG52bzMgPG52 bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIEFsYmVydG8gUm9kcmlndWV6LU5hdGFsIDxhcm5hdGFsQGFjLnVwYy5lZHU8bWFpbHRv OmFybmF0YWxAYWMudXBjLmVkdT4+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgNCwgMjAxNiA2 OjI2IFBNDQpUbzogbGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4gbGlzdDsgbnZv M0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz47IFNETiBJUlRGIGxpc3Q7IG5mdnJnQGly dGYub3JnPG1haWx0bzpuZnZyZ0BpcnRmLm9yZz47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KU3ViamVjdDogW252bzNdIE9wZW5PdmVybGF5Um91dGVyIHJlbGVhc2VkIQ0KDQpI aSBhbGwsDQoNCldlIHdvdWxkIGxpa2UgdG8gYW5ub3VuY2UgdGhlIGZpcnN0IHJlbGVhc2Ugb2Yg T3Blbk92ZXJsYXlSb3V0ZXIgKE9PUiAtIHNwZWxsZWQgImRvdWJsZS1PLVIiKSwgYW4gb3Blbi1z b3VyY2UgcHJvamVjdCwgdW5kZXIgdGhlIEFwYWNoZSAyLjAgTGljZW5zZSwgdG8gaW5zdGFudGlh dGUgcHJvZ3JhbW1hYmxlIG92ZXJsYXlzLiBPT1IgaXMgZWRnZS1vcmllbnRlZCBhbmQgbXVsdGlw bGF0Zm9ybSAoQW5kcm9pZCwgTGludXggYW5kIE9wZW5XUlQpIHdpdGggdGhlIGFpbSB0byBvZmZl ciBhIGZsZXhpYmxlIGFuZCBlYXN5LXRvLWRlcGxveSBvdmVybGF5IGluZnJhc3RydWN0dXJlLiBP T1IgaXMgYmFzZWQgb24gdGhlIGZvcm1lciBMSVNQbW9iLm9yZzxodHRwOi8vbGlzcG1vYi5vcmcv PiBjb2RlLg0KDQoNCiogV2hvIGNhbiB1c2UgaXQgKg0KDQpPT1IgaXMgaW50ZW5kZWQgZm9yIGVu ZC11c2VycyBsb29raW5nIGZvciBlYXN5IG11bHRpaG9taW5nLCBjb21wYW5pZXMgd2l0aCBzdHJv bmcgcHJlc2VuY2UgYXQgdGhlIGVkZ2UsIHN0YXJ0dXBzIGludGVyZXN0ZWQgaW4gb3ZlcmxheSBz b2x1dGlvbnMgYW5kIHJlc2VhcmNoZXJzIGV4cGxvcmluZyBuZXcgc2NlbmFyaW9zLg0KDQoNCiog U3VwcG9ydGVkIHByb3RvY29scyAqDQoNCk9PUiBpcyBpbnRlcm9wZXJhYmxlIHdpdGggT3BlbkRh eWxpZ2h0IGFuZCBzdXBwb3J0cyBzZXZlcmFsIHByb3RvY29scyBmb3IgYm90aCB0aGUgZGF0YSBh bmQgY29udHJvbCBwbGFuZS4gT24gdGhlIGNvbnRyb2wgcGxhbmUsIGl0IHN1cHBvcnRzIE5FVENP TkYgZm9yIHByb3Zpc2lvbmluZyBhbmQgbWFuYWdlbWVudCBhbmQgTElTUCBmb3Igb3BlcmF0aW9u YWwgc3RhdGUgZXhjaGFuZ2UuIE9uIHRoZSBkYXRhIHBsYW5lLCBpdCBzdXBwb3J0cyBJUHY0IGFu ZCBJUHY2IG92ZXJsYXlzIHdpdGggTElTUCBhbmQgVlhMQU4tR1BFIGVuY2Fwc3VsYXRpb25zLiBU aGUgcm9hZG1hcCBpbmNsdWRlcyBMMiBvdmVybGF5cywgZnVydGhlciBlbmNhcHN1bGF0aW9ucyBh bmQgc3VwcG9ydCBmb3IgU0ZDIGhlYWRlcnMuDQoNCg0KKiBDb2RlICoNCg0KWW91IGNhbiBmaW5k IGFsbCB0aGUgZGV0YWlscyBhbmQgZ2V0IHRoZSBjb2RlIGF0Og0KaHR0cDovL29wZW5vdmVybGF5 cm91dGVyLm9yZy88aHR0cDovL3dlYmRlZmVuY2UuZ2xvYmFsLmJsYWNrc3BpZGVyLmNvbS91cmx3 cmFwLz9xPUFYaWNKY3F4RGNKQURBQkFTMHpBSXY5NWtRWXFPbW9vb1hJZWk3emsySkhqdk1nZWpN UU16Qk1FVjk5MkE3Y1B3T3NOWUx3MHFRdVQxVEJnNGF6aXBoeXlEakNuOW5RNVgzT1Q5bW5YQWpJ OVVlNWtvV0tScVhjcWNxUmNuSmgtdjNjZkR6SHFTS0tWakhFeG5mMzcxUjRSX2xhN2FpZ28mWj4N Cg0KDQpUaGFua3MhDQpUaGUgT3Blbk92ZXJsYXlSb3V0ZXIgdGVhbQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGluZyBsaXN0DQpudm8z QGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9udm8zDQoNCg== --_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAy IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXRh Yi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtY29u dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxh bmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+KzEgQ2FybG9zLCBhbmQgUnVubmluZyBDb2Rl IGhhcyAqPGI+YWx3YXlzPC9iPiogYmVlbiBvZiBpbnRlcmVzdCBoZXJlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+QWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiBOZnZyZyBbbWFpbHRvOm5mdnJnLWJvdW5jZXNAaXJ0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8 L2I+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZl YnJ1YXJ5IDA1LCAyMDE2IDk6MjQgQU08YnI+PGI+VG86PC9iPiBBbGV4YW5kZXIgVmFpbnNodGVp bjxicj48Yj5DYzo8L2I+IFNETiBJUlRGIGxpc3Q7IGxpc3BAaWV0Zi5vcmcgbGlzdDsgc2ZjQGll dGYub3JnOyBudm8zQGlldGYub3JnOyBuZnZyZ0BpcnRmLm9yZzsgQWxiZXJ0byBSb2RyaWd1ZXot TmF0YWw8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbTmZ2cmddIFtudm8zXSBPcGVuT3ZlcmxheVJv dXRlciByZWxlYXNlZCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNh c2hhLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkl0IHNlZW1zIHRvIG1l IHRvIGJlIGV4dHJlbWVseSByZWxldmFudCBhbmQgdmVyeSBwcm9wZXIsIGFzIHdlIHdhbnQgbW9y ZSBvcGVuIHNvdXJjZSBzb2Z0d2FyZSBjb25uZWN0aW9ucyB3aXRoIHRoZSBJRVRGLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21lZXRpbmcvOTEvMjAxNC4xMS4xM19EV2FyZC1JRVRGLTkxLnBkZiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWVldGluZy85MS8yMDE0LjExLjEzX0RXYXJkLUlFVEYtOTEucGRmPC9h PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmludGVybmV0c29jaWV0eS5vcmcvcHVibGljYXRpb25zL2lldGYtam91cm5hbC1t YXJjaC0yMDE1L29wZW4tc3RhbmRhcmRzLW9wZW4tc291cmNlLW9wZW4tbG9vcCI+aHR0cHM6Ly93 d3cuaW50ZXJuZXRzb2NpZXR5Lm9yZy9wdWJsaWNhdGlvbnMvaWV0Zi1qb3VybmFsLW1hcmNoLTIw MTUvb3Blbi1zdGFuZGFyZHMtb3Blbi1zb3VyY2Utb3Blbi1sb29wPC9hPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPuKAnFdpdGhpbiB0aGUgSUVURiwgd2UgZmFjZSBu dW1lcm91cyBpc3N1ZXMgYXJvdW5kIG91ciBvd24gbGlmZSBjeWNsZS4gW+KApl0mbmJzcDtXaGF0 IGRvZXMmbmJzcDt0aGUgc3ViamVjdCBtYXR0ZXIgb2YgcG9wdWxhciwgbmV0d29yay1jZW50cmlj IE9TUyBwcm9qZWN0cyBpbXBseSBtaWdodCZuYnNwO2JlIG1pc3NpbmcgYXQgdGhlIElFVEY/4oCd PC9pPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPuKAnEhvdyB0byBN YWtlIHRoZSBJRVRGIFJlbGV2YW50IGluIHRoaXMgRW52aXJvbm1lbnQ8L2k+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+4oCiIEZpeCwgY2hhbmdlLCBvciByZWludmVu dCB0aGUgbGlhaXNvbiBwcm9jZXNzIGJlY2F1c2UgaXQgd2lsbCBiZSBjcml0aWNhbCB0byBjb2xs YWJvcmF0aW9uIHdpdGggT1NTIHByb2plY3RzLiZuYnNwO0luIGZhY3QsIGRvbuKAmXQgZXZlbiB1 c2UgdGhlIGxpYWlzb24gcHJvY2VzcyBhcyBhIG1vZGVsLjwvaT48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48aT7igKIgRW1icmFjZSBPcGVuIFNvdXJjZSBwcm9q ZWN0cy7igJ08L2k+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPuKAlCBDYXJsb3MuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGJs b2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gRmViIDUsIDIwMTYsIGF0IDEyOjU0IEFNLCBBbGV4YW5k ZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVj aXRlbGUuY29tIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxkaXYgaWQ9ZGl2dGFnZGVmYXVsdHdyYXBwZXI+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPklzIHRoaXMgYSBwcm9wZXIga2luZCBvZiAm bmJzcDttZXNzYWdlIG9uICZuYnNwO0lFVEYgbWFpbGluZyBsaXN0cz88bzpwPjwvbzpwPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn cm91bmQ6d2hpdGUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdiBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Jz48aHIgc2l6ZT0yIHdpZHRoPTY3NyBzdHlsZT0nd2lkdGg6NTA3LjlwdCcgYWxpZ249Y2VudGVy PjwvZGl2PjxkaXYgaWQ9ZGl2UnBseUZ3ZE1zZz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1h cHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz5udm8zICZsdDs8YSBocmVmPSJtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnIj5udm8zLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWxiZXJ0byBSb2RyaWd1ZXotTmF0 YWwgJmx0OzxhIGhyZWY9Im1haWx0bzphcm5hdGFsQGFjLnVwYy5lZHUiPmFybmF0YWxAYWMudXBj LmVkdTwvYT4mZ3Q7PGJyPjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgNjoyNiBQTTxicj48 Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86bGlzcEBpZXRmLm9yZyI+bGlzcEBpZXRmLm9yZzwvYT48c3BhbiBjbGFz cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPmxpc3Q7PHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bnZvM0BpZXRm Lm9yZyI+bnZvM0BpZXRmLm9yZzwvYT47IFNETiBJUlRGIGxpc3Q7PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmZ2cmdAaXJ0Zi5v cmciPm5mdnJnQGlydGYub3JnPC9hPjs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwv YT48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj5bbnZvM10gT3Blbk92ZXJsYXlSb3V0ZXIgcmVsZWFzZWQhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz5IaSBhbGwsPGJyPjxicj5XZSB3b3VsZCBs aWtlIHRvIGFubm91bmNlIHRoZSBmaXJzdCByZWxlYXNlIG9mIE9wZW5PdmVybGF5Um91dGVyIChP T1IgLSBzcGVsbGVkICZxdW90O2RvdWJsZS1PLVImcXVvdDspLCBhbiBvcGVuLXNvdXJjZSBwcm9q ZWN0LCB1bmRlciB0aGUgQXBhY2hlIDIuMCBMaWNlbnNlLCB0byBpbnN0YW50aWF0ZSBwcm9ncmFt bWFibGUgb3ZlcmxheXMuIE9PUiBpcyBlZGdlLW9yaWVudGVkIGFuZCBtdWx0aXBsYXRmb3JtIChB bmRyb2lkLCBMaW51eCBhbmQgT3BlbldSVCkgd2l0aCB0aGUgYWltIHRvIG9mZmVyIGEgZmxleGli bGUgYW5kIGVhc3ktdG8tZGVwbG95IG92ZXJsYXkgaW5mcmFzdHJ1Y3R1cmUuIE9PUiBpcyBiYXNl ZCBvbiB0aGUgZm9ybWVyPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwOi8vbGlzcG1vYi5vcmcvIj5MSVNQbW9iLm9yZzwvYT48c3BhbiBj bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPmNvZGUuPGJyPjxicj48YnI+ KiBXaG8gY2FuIHVzZSBpdCAqPGJyPjxicj5PT1IgaXMgaW50ZW5kZWQgZm9yIGVuZC11c2VycyBs b29raW5nIGZvciBlYXN5IG11bHRpaG9taW5nLCBjb21wYW5pZXMgd2l0aCBzdHJvbmcgcHJlc2Vu Y2UgYXQgdGhlIGVkZ2UsIHN0YXJ0dXBzIGludGVyZXN0ZWQgaW4gb3ZlcmxheSBzb2x1dGlvbnMg YW5kIHJlc2VhcmNoZXJzIGV4cGxvcmluZyBuZXcgc2NlbmFyaW9zLjxicj48YnI+PGJyPiogU3Vw cG9ydGVkIHByb3RvY29scyAqPGJyPjxicj5PT1IgaXMgaW50ZXJvcGVyYWJsZSB3aXRoIE9wZW5E YXlsaWdodCBhbmQgc3VwcG9ydHMgc2V2ZXJhbCBwcm90b2NvbHMgZm9yIGJvdGggdGhlIGRhdGEg YW5kIGNvbnRyb2wgcGxhbmUuIE9uIHRoZSBjb250cm9sIHBsYW5lLCBpdCBzdXBwb3J0cyBORVRD T05GIGZvciBwcm92aXNpb25pbmcgYW5kIG1hbmFnZW1lbnQgYW5kIExJU1AgZm9yIG9wZXJhdGlv bmFsIHN0YXRlIGV4Y2hhbmdlLiBPbiB0aGUgZGF0YSBwbGFuZSwgaXQgc3VwcG9ydHMgSVB2NCBh bmQgSVB2NiBvdmVybGF5cyB3aXRoIExJU1AgYW5kIFZYTEFOLUdQRSBlbmNhcHN1bGF0aW9ucy4g VGhlIHJvYWRtYXAgaW5jbHVkZXMgTDIgb3ZlcmxheXMsIGZ1cnRoZXIgZW5jYXBzdWxhdGlvbnMg YW5kIHN1cHBvcnQgZm9yIFNGQyBoZWFkZXJzLjxicj48YnI+PGJyPiogQ29kZSAqPGJyPjxicj5Z b3UgY2FuIGZpbmQgYWxsIHRoZSBkZXRhaWxzIGFuZCBnZXQgdGhlIGNvZGUgYXQ6PGJyPjxhIGhy ZWY9Imh0dHA6Ly93ZWJkZWZlbmNlLmdsb2JhbC5ibGFja3NwaWRlci5jb20vdXJsd3JhcC8/cT1B WGljSmNxeERjSkFEQUJBUzB6QUl2OTVrUVlxT21vb29YSWVpN3prMkpIanZNZ2VqTVFNekJNRVY5 OTJBN2NQd09zTllMdzBxUXVUMVRCZzRhemlwaHl5RGpDbjluUTVYM09UOW1uWEFqSTlVZTVrb1dL UnFYY3FjcVJjbkpoLXYzY2ZEekhxU0tLVmpIRXhuZjM3MVI0Ul9sYTdhaWdvJmFtcDtaIj5odHRw Oi8vb3Blbm92ZXJsYXlyb3V0ZXIub3JnLzwvYT48YnI+PGJyPjxicj5UaGFua3MhPGJyPlRoZSBP cGVuT3ZlcmxheVJvdXRlciB0ZWFtPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5udm8zIG1haWxpbmcgbGlzdDxicj48L3NwYW4+PGEg aHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5udm8zQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Ei LCJzYW5zLXNlcmlmIic+PGJyPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL252bzMiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL252bzM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78NJFPSRVEXG0re_-- From nobody Sun Feb 7 08:11:02 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A231B3C70 for ; Sun, 7 Feb 2016 08:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_B7VA4OBe4y for ; Sun, 7 Feb 2016 08:11:00 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id DB12D1B3C6F for ; Sun, 7 Feb 2016 08:10:59 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0195.001; Sun, 7 Feb 2016 11:11:04 -0500 From: Dave Dolson To: VictorVu , opendaylight sfc Thread-Topic: ODL Hierarchical SFC implementation demo Thread-Index: AQHRYKpVkMg6kAGKxUCtOkLBdXvfMJ8gubc1 Date: Sun, 7 Feb 2016 16:11:02 +0000 Message-ID: References: <56B5971F.4090402@gmail.com> In-Reply-To: <56B5971F.4090402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.58.216.64] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] ODL Hierarchical SFC implementation demo X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 16:11:01 -0000 Hi Victor,=0A= Thanks for sharing your design.=0A= I have some comments from my perspective.=0A= =0A= 1. Your slides don't clearly show the controllers. One of the main goals of= hSFC is to have independent control of the top-level domain and lower-leve= l domains. So I think it is important to show a controller for each domain.= =0A= Note that in the top-level domain, the controller will view the sub-domain = as merely an SF. In the lower-level domain, the controller deals with only = what is in the sub-domain, from controller on down. The IBN is the glue bet= ween them and may be configured independently of either, in my opinion.=0A= I think it is important to consider the controllers may be from different p= rojects as well (e.g., not all ODL).=0A= In fact, you should consider doing this work outside of the ODL project. It= seems to be more general.=0A= =0A= 2. The use of MD-1 for the SFF IP address is troubling because (a) it doesn= 't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH (vs. = Ethernet/NSH and others). It isn't clear to me that this information needs = to be saved in the packet anyhow, because the SFF is always the same. E.g.,= SFF2 can just be configured as the SFF for the IBN.=0A= =0A= 3. Looking at slide 10, keeping in mind the bidirectional nature of traffic= , it may be useful to show classifiers on both sides of the sub-domain, or = make it more clear that the red path is only for client-to-server traffic a= nd a different path is required for server-to-client traffic.=0A= =0A= I look forward to following your work.=0A= Thanks,=0A= -Dave=0A= =0A= ________________________________________=0A= From: VictorVu [minowar91@gmail.com]=0A= Sent: Saturday, February 06, 2016 1:47 AM=0A= To: opendaylight sfc=0A= Cc: Dave Dolson=0A= Subject: ODL Hierarchical SFC implementation demo=0A= =0A= Hi,=0A= I m trying to implement the Hierarchical SFC concept into ODL SFC. This=0A= is our demo=0A= https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4c7= -SYWX6q4/edit?usp=3Dsharing=0A= =0A= I would like to ask anyone interested to help us reviewing our design.=0A= Please give me your comment so that we can discuss further.=0A= =0A= Best regards,=0A= =0A= ---=0A= This email has been checked for viruses by Avast antivirus software.=0A= https://www.avast.com/antivirus=0A= =0A= From nobody Sun Feb 7 09:02:01 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339DB1A0040 for ; Sun, 7 Feb 2016 09:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiDOwH66SdOq for ; Sun, 7 Feb 2016 09:01:57 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 82B651A000E for ; Sun, 7 Feb 2016 09:01:57 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 7 Feb 2016 12:01:57 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Sun, 7 Feb 2016 12:01:56 -0500 From: Dave Dolson To: Keith Burns Thread-Topic: [sfc-dev] ODL Hierarchical SFC implementation demo Thread-Index: AQHRYKpVkMg6kAGKxUCtOkLBdXvfMJ8gubc1gABhUoD//7Yn+A== Date: Sun, 7 Feb 2016 17:02:00 +0000 Message-ID: <20160207170150.5697621.18376.64566@sandvine.com> References: <56B5971F.4090402@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: VictorVu , opendaylight sfc , "sfc@ietf.org" , Colin Dixon Subject: Re: [sfc] [sfc-dev] ODL Hierarchical SFC implementation demo X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 17:01:59 -0000 Keith, The hierarchical approach becomes relevant for large numbers of nodes and w= hen independent management of domains is desired. I admit it is difficult t= o see the benefit in a small-scale proof of concept. -Dave From: Keith Burns Sent: Sunday, February 7, 2016 11:26 AM To: Dave Dolson Cc: sfc@ietf.org; opendaylight sfc; VictorVu; Colin Dixon Subject: Re: [sfc-dev] ODL Hierarchical SFC implementation demo I'm also curious how the same thing couldn't be handled with 3 chains and a= classifier. Might be an interesting TWS talk even if it's scope is beyond = ODL. On Feb 7, 2016 5:11 PM, "Dave Dolson" > wrote: Hi Victor, Thanks for sharing your design. I have some comments from my perspective. 1. Your slides don't clearly show the controllers. One of the main goals of= hSFC is to have independent control of the top-level domain and lower-leve= l domains. So I think it is important to show a controller for each domain. Note that in the top-level domain, the controller will view the sub-domain = as merely an SF. In the lower-level domain, the controller deals with only = what is in the sub-domain, from controller on down. The IBN is the glue bet= ween them and may be configured independently of either, in my opinion. I think it is important to consider the controllers may be from different p= rojects as well (e.g., not all ODL). In fact, you should consider doing this work outside of the ODL project. It= seems to be more general. 2. The use of MD-1 for the SFF IP address is troubling because (a) it doesn= 't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH (vs. = Ethernet/NSH and others). It isn't clear to me that this information needs = to be saved in the packet anyhow, because the SFF is always the same. E.g.,= SFF2 can just be configured as the SFF for the IBN. 3. Looking at slide 10, keeping in mind the bidirectional nature of traffic= , it may be useful to show classifiers on both sides of the sub-domain, or = make it more clear that the red path is only for client-to-server traffic a= nd a different path is required for server-to-client traffic. I look forward to following your work. Thanks, -Dave ________________________________________ From: VictorVu [minowar91@gmail.com] Sent: Saturday, February 06, 2016 1:47 AM To: opendaylight sfc Cc: Dave Dolson Subject: ODL Hierarchical SFC implementation demo Hi, I m trying to implement the Hierarchical SFC concept into ODL SFC. This is our demo https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4c7= -SYWX6q4/edit?usp=3Dsharing I would like to ask anyone interested to help us reviewing our design. Please give me your comment so that we can discuss further. Best regards, --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev From nobody Sun Feb 7 16:41:55 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582BD1A871A; Sun, 7 Feb 2016 16:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-YI5f94TJs0; Sun, 7 Feb 2016 16:41:50 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30D01A8716; Sun, 7 Feb 2016 16:41:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.30; From: "Susan Hares" To: "'MORTON, ALFRED C \(AL\)'" , "'Carlos Pignataro \(cpignata\)'" , "'Alexander Vainshtein'" References: <4E7E7ADA-2647-4B00-9968-36981056E8B1@cisco.com> <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D2E26DF2A78@NJFPSRVEXG0.research.att.com> Date: Sun, 7 Feb 2016 19:41:40 -0500 Message-ID: <00d601d16209$7a235a60$6e6a0f20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D161DF.91505FA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEa13StjE5LHmI2LycE7tADVdmQWwJuieFbAe3+c14CVq6ciqBYyiYA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'SDN IRTF list' , lisp@ietf.org, sfc@ietf.org, nvo3@ietf.org, nfvrg@irtf.org, 'Alberto Rodriguez-Natal' Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 00:41:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D7_01D161DF.91505FA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 to Al and Carlos. Running code has and should be of interest in = IETF.=20 =20 Sue=20 =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL) Sent: Friday, February 05, 2016 9:53 AM To: Carlos Pignataro (cpignata); Alexander Vainshtein Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; = nfvrg@irtf.org; Alberto Rodriguez-Natal Subject: Re: [sfc] [nvo3] OpenOverlayRouter released! =20 +1 Carlos, and Running Code has *always* been of interest here. Al =20 From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of Carlos = Pignataro (cpignata) Sent: Friday, February 05, 2016 9:24 AM To: Alexander Vainshtein Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; = nfvrg@irtf.org; Alberto Rodriguez-Natal Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter released! =20 Sasha, =20 It seems to me to be extremely relevant and very proper, as we want more = open source software connections with the IETF. https://www.ietf.org/meeting/91/2014.11.13_DWard-IETF-91.pdf https://www.internetsociety.org/publications/ietf-journal-march-2015/open= -standards-open-source-open-loop =20 =E2=80=9CWithin the IETF, we face numerous issues around our own life = cycle. [=E2=80=A6] What does the subject matter of popular, = network-centric OSS projects imply might be missing at the = IETF?=E2=80=9D =20 =E2=80=9CHow to Make the IETF Relevant in this Environment =20 =E2=80=A2 Fix, change, or reinvent the liaison process because it will = be critical to collaboration with OSS projects. In fact, don=E2=80=99t = even use the liaison process as a model. =E2=80=A2 Embrace Open Source projects.=E2=80=9D =20 Thanks, =20 =E2=80=94 Carlos. =20 =20 On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein = wrote: =20 Is this a proper kind of message on IETF mailing lists? =20 _____ =20 From: nvo3 on behalf of Alberto Rodriguez-Natal = Sent: Thursday, February 4, 2016 6:26 PM To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; = sfc@ietf.org Subject: [nvo3] OpenOverlayRouter released! =20 Hi all, We would like to announce the first release of OpenOverlayRouter (OOR - = spelled "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code. * Who can use it * OOR is intended for end-users looking for easy multihoming, companies = with strong presence at the edge, startups interested in overlay = solutions and researchers exploring new scenarios. * Supported protocols * OOR is interoperable with OpenDaylight and supports several protocols = for both the data and control plane. On the control plane, it supports = NETCONF for provisioning and management and LISP for operational state = exchange. On the data plane, it supports IPv4 and IPv6 overlays with = LISP and VXLAN-GPE encapsulations. The roadmap includes L2 overlays, = further encapsulations and support for SFC headers. * Code * You can find all the details and get the code at: http://openoverlayrouter.org/ = = Thanks! The OpenOverlayRouter team _______________________________________________ nvo3 mailing list nvo3@ietf.org = https://www.ietf.org/mailman/listinfo/nvo3 =20 ------=_NextPart_000_00D7_01D161DF.91505FA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1 to Al and Carlos.=C2=A0 Running code has and should be of interest = in IETF.

 

Sue

 

From:= = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of MORTON, ALFRED C = (AL)
Sent: Friday, February 05, 2016 9:53 AM
To: = Carlos Pignataro (cpignata); Alexander Vainshtein
Cc: SDN IRTF = list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; nfvrg@irtf.org; = Alberto Rodriguez-Natal
Subject: Re: [sfc] [nvo3] = OpenOverlayRouter released!

 

+1 = Carlos, and Running Code has *always* been of interest = here.

Al

 

From:= = Nfvrg [mailto:nfvrg-bounces@irtf.org]= On Behalf Of Carlos Pignataro (cpignata)
Sent: Friday, = February 05, 2016 9:24 AM
To: Alexander = Vainshtein
Cc: SDN IRTF list; lisp@ietf.org list; sfc@ietf.org; nvo3@ietf.org; nfvrg@irtf.org; Alberto = Rodriguez-Natal
Subject: Re: [Nfvrg] [nvo3] OpenOverlayRouter = released!

 

Sasha,

 

It seems to me to be extremely relevant and very = proper, as we want more open source software connections with the = IETF.

 

=E2=80=9CWithin the IETF, we face numerous issues = around our own life cycle. [=E2=80=A6] What does the subject = matter of popular, network-centric OSS projects imply might be = missing at the IETF?=E2=80=9D

 

=E2=80=9CHow to Make the IETF Relevant in this = Environment

 

=E2=80=A2 Fix, change, or reinvent the liaison = process because it will be critical to collaboration with OSS = projects. In fact, don=E2=80=99t even use the liaison process as a = model.

=E2=80=A2 = Embrace Open Source projects.=E2=80=9D

 

Thanks,

 

=E2=80=94 Carlos.

 

 

On Feb 5, 2016, at 12:54 AM, Alexander Vainshtein = <Alexander.Vainshtein@eci= tele.com> wrote:

 

Is this a proper kind of  message on =  IETF mailing lists?

 

From: nvo3 = <nvo3-bounces@ietf.org> on = behalf of Alberto Rodriguez-Natal <arnatal@ac.upc.edu>
Sent:=  Thursday, February = 4, 2016 6:26 PM
To: lisp@ietf.org list; nvo3@ietf.org; SDN IRTF list; nfvrg@irtf.org; sfc@ietf.org
Subject: [nvo3] OpenOverlayRouter = released!

 

Hi all,

We would = like to announce the first release of OpenOverlayRouter (OOR - spelled = "double-O-R"), an open-source project, under the Apache 2.0 = License, to instantiate programmable overlays. OOR is edge-oriented and = multiplatform (Android, Linux and OpenWRT) with the aim to offer a = flexible and easy-to-deploy overlay infrastructure. OOR is based on the = former LISPmob.org code.


* Who can = use it *

OOR is intended for end-users looking for easy = multihoming, companies with strong presence at the edge, startups = interested in overlay solutions and researchers exploring new = scenarios.


* Supported protocols *

OOR is = interoperable with OpenDaylight and supports several protocols for both = the data and control plane. On the control plane, it supports NETCONF = for provisioning and management and LISP for operational state exchange. = On the data plane, it supports IPv4 and IPv6 overlays with LISP and = VXLAN-GPE encapsulations. The roadmap includes L2 overlays, further = encapsulations and support for SFC headers.


* Code = *

You can find all the details and get the code at:
http://openoverlayrouter.org/


Thanks!
The = OpenOverlayRouter team

__________= _____________________________________
nvo3 mailing list
nvo3@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/nvo3

 

------=_NextPart_000_00D7_01D161DF.91505FA0-- From nobody Sun Feb 7 23:59:36 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BED1ACD25 for ; Sun, 7 Feb 2016 23:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjAtEqJtzn5m for ; Sun, 7 Feb 2016 23:59:32 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D186D1ACD23 for ; Sun, 7 Feb 2016 23:59:31 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id ik10so80208070igb.1 for ; Sun, 07 Feb 2016 23:59:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=gSot9sJeoFJMOKyuo6bslBwws4CGdYI/0BvhSOkUu8I=; b=mC47VbrrOMKS9Xg9tE7A4OzZpf9wSvWNZkWDzMrjP/WcxWC9HaqES9EImqeG05RAuZ Lj0EIBTrSUHjR37DuYNd+XmW5eqpN9rOoKdostqkw5zKmHfXUzk/CD7TUI2B7sz/sp40 loBOTjA9MdTnX0k6RigmFFLtGUrSybBK8SlfMU95AkugMXs/Y8E0xO/mAeZRrTpPbyjx Xc3ZzZSpGpbYs6pGZtJrgtffDFEDYHV+UmamsVyG2yUT4NFOVzJ3rubIr++tk6wCYhFc HJnV1vlGJ4R3qIjKbuKM8XZNU2fdZ7Ve8DwhQZCbaDkDE39MMko83NH1z6mKL8P/bXCp dRtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=gSot9sJeoFJMOKyuo6bslBwws4CGdYI/0BvhSOkUu8I=; b=TylR6jvAM8t0dEm/MMBJcby0s0ds6FRD+oEO2QgopvFh5A3tYVgCEU1T3bI5JlLj9y RcQbTVdom8VtGNUTR9p1pUMpKR6arL4RnBEd9i5FWEDHyO/LOAkH2/TFdhWH28mXsHGa pX+dR8VaOYRqZEhGQk9JThIhqUYF/zyDQBXYqlDVmrIVjKYVSDcC0/g9EeLZuXlH5zbR dUlJ6JvDlTQxfp+abS864WAG5oG0oak9SRtKMvJWrqe/BL73rONbUr2Epclo6Xb5rpne carJw7A+8piduwMZLBCp+4oUHTqPjUP4E7XkoZ7OsTkuhlhzuEnhpY4YKHtflYpq3R0L YYUw== X-Gm-Message-State: AG10YOQ8DVPB/fyB7NLt/FkNYCA5X5aehZoICznS7pOggbMOnsTnQRUHaKiigSW0d+MHeNt5oedVvuW3KNN7qQ== X-Received: by 10.50.39.107 with SMTP id o11mr5996087igk.21.1454918371228; Sun, 07 Feb 2016 23:59:31 -0800 (PST) MIME-Version: 1.0 References: <56B5971F.4090402@gmail.com> In-Reply-To: From: Victor Vu Date: Mon, 08 Feb 2016 07:59:21 +0000 Message-ID: To: Dave Dolson , opendaylight sfc Content-Type: multipart/alternative; boundary=047d7bdca294b1c1c9052b3d9439 Archived-At: Cc: Keith Burns , "sfc@ietf.org" Subject: Re: [sfc] ODL Hierarchical SFC implementation demo X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 07:59:34 -0000 --047d7bdca294b1c1c9052b3d9439 Content-Type: text/plain; charset=UTF-8 Hi, Thanks for your comments. 1. Of course each domain is managed by one controller, I am sorry not clarify that in the figure. About IBN, I think they should be configured by the lower-level domain controller because: (a) Independently configuring IBN would increase the management complexity. The entity responsible for this task should know well about all SFC domains. which is not good for security. (b) higher level domain should not do this task because like you said, it views the sub-domain as merely an SF. I am not sure but I believe your idea is making an independent entity to enable hSFC (creating connection node between domains, configuring IBN ...). But in my opinion, SFC controllers should do thisand ODL is a good starting point since it already support SFC. 2. You are right using MD-1 for IP address will cause problem with IPv6, but we can solve this problem in the future with NSH metadata type 2 I also understand that SFF could be shared by higher and lower domain, but I am considering about multi-domain NFV environment, where each NFV MANO manage their own SFC components and don't need/don't want to share them 3. Sub-domain controller will decide whether there is bi-directional path or not in it's configuration. I mean it's up to sub-domain manager to flexibly make the decision. I will add the reversed path for clarification. On Sun, Feb 7, 2016 at 11:26 PM Keith Burns wrote: > I'm also curious how the same thing couldn't be handled with 3 chains and > a classifier. Might be an interesting TWS talk even if it's scope is beyond > ODL. > In my topology, this thing could definitely be done with 3 chains and a classifier. Like Dave said, this concept only benefit in large-scale DC. Actually, I want to apply this concept in multi-domain NFV, so my design might make more sense in this context. Again, I appreciate all your comments, they help me a lot to complete the design. Currently my demo runs with the simplest scenario: no IPv6, sub-domain only receives hSFC traffic, last SF decrease SI, ... There are some discussion points in my final slide. After solving those point I will refactor and open the demo code. On Sun, Feb 7, 2016 at 11:10 PM Dave Dolson wrote: > Hi Victor, > Thanks for sharing your design. > I have some comments from my perspective. > > 1. Your slides don't clearly show the controllers. One of the main goals > of hSFC is to have independent control of the top-level domain and > lower-level domains. So I think it is important to show a controller for > each domain. > Note that in the top-level domain, the controller will view the sub-domain > as merely an SF. In the lower-level domain, the controller deals with only > what is in the sub-domain, from controller on down. The IBN is the glue > between them and may be configured independently of either, in my opinion. > I think it is important to consider the controllers may be from different > projects as well (e.g., not all ODL). > In fact, you should consider doing this work outside of the ODL project. > It seems to be more general. > > 2. The use of MD-1 for the SFF IP address is troubling because (a) it > doesn't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH > (vs. Ethernet/NSH and others). It isn't clear to me that this information > needs to be saved in the packet anyhow, because the SFF is always the same. > E.g., SFF2 can just be configured as the SFF for the IBN. > > 3. Looking at slide 10, keeping in mind the bidirectional nature of > traffic, it may be useful to show classifiers on both sides of the > sub-domain, or make it more clear that the red path is only for > client-to-server traffic and a different path is required for > server-to-client traffic. > > I look forward to following your work. > Thanks, > -Dave > > ________________________________________ > From: VictorVu [minowar91@gmail.com] > Sent: Saturday, February 06, 2016 1:47 AM > To: opendaylight sfc > Cc: Dave Dolson > Subject: ODL Hierarchical SFC implementation demo > > Hi, > I m trying to implement the Hierarchical SFC concept into ODL SFC. This > is our demo > > https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4c7-SYWX6q4/edit?usp=sharing > > I would like to ask anyone interested to help us reviewing our design. > Please give me your comment so that we can discuss further. > > Best regards, > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > --047d7bdca294b1c1c9052b3d9439 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
Thanks for your comments.=

1. Of course each domain is managed by one controller, I am s= orry not clarify that in the figure.
About IBN, I think they shoul= d be configured by the lower-level domain controller because: (a) Independe= ntly configuring IBN would increase the management complexity. The entity r= esponsible for this task should know well about all SFC domains. which is n= ot good for security. (b) higher level domain should not do this task becau= se like you said, it views the sub-domain as merely an SF.
I am no= t sure but I believe your idea is making an independent entity to enable hS= FC (creating connection node between domains, configuring IBN ...). But in = my opinion, SFC controllers should do thisand ODL is a good starting point = since it already support SFC.

2. You are right using MD-1 for IP address will cause problem with IPv6,= but we can solve this problem in the future with NSH metadata type 2
I also understand that SFF could be shared by higher and lower dom= ain, but I am considering about multi-domain NFV environment, where each NF= V MANO manage their own SFC components and don't need/don't want to= share them

3. Sub-domain controller will decide whether = there is bi-directional path or not in it's configuration. I mean it= 9;s up to sub-domain manager to flexibly make the decision. I will add the = reversed path for clarification.



=
On Sun, Feb 7, 2016 at 11:26 PM Keith Burns <alagalah@gmail.com> wrote:

I'm also curious how the same thing couldn't be handled with 3 chains and = a classifier. Might be an interesting TWS talk even if it's scope is=20 beyond ODL.


In my topology, this thing could definitel= y be done with 3 chains and a classifier. Like Dave said, this concept only= benefit in large-scale DC. Actually, I want to apply this concept in multi= -domain NFV, so my design might make more sense in this context.
<= /div>
Again, I appreciate all your comments, they help me a l= ot to complete the design.
Currently my demo runs with the si= mplest scenario: no IPv6, sub-domain only receives hSFC traffic, last SF de= crease SI, ...
There are some discussion points in my final slide. After= solving those point I will refactor and open the demo code.


On Sun, Feb 7, 2016 at 1= 1:10 PM Dave Dolson <ddolson@san= dvine.com> wrote:
Hi Victo= r,
Thanks for sharing your design.
I have some comments from my perspective.

1. Your slides don't clearly show the controllers. One of the main goal= s of hSFC is to have independent control of the top-level domain and lower-= level domains. So I think it is important to show a controller for each dom= ain.
Note that in the top-level domain, the controller will view the sub-domain = as merely an SF. In the lower-level domain, the controller deals with only = what is in the sub-domain, from controller on down. The IBN is the glue bet= ween them and may be configured independently of either, in my opinion.
I think it is important to consider the controllers may be from different p= rojects as well (e.g., not all ODL).
In fact, you should consider doing this work outside of the ODL project. It= seems to be more general.

2. The use of MD-1 for the SFF IP address is troubling because (a) it doesn= 't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH (= vs. Ethernet/NSH and others). It isn't clear to me that this informatio= n needs to be saved in the packet anyhow, because the SFF is always the sam= e. E.g., SFF2 can just be configured as the SFF for the IBN.

3. Looking at slide 10, keeping in mind the bidirectional nature of traffic= , it may be useful to show classifiers on both sides of the sub-domain, or = make it more clear that the red path is only for client-to-server traffic a= nd a different path is required for server-to-client traffic.

I look forward to following your work.
Thanks,
-Dave

________________________________________
From: VictorVu [mi= nowar91@gmail.com]
Sent: Saturday, February 06, 2016 1:47 AM
To: opendaylight sfc
Cc: Dave Dolson
Subject: ODL Hierarchical SFC implementation demo

Hi,
I m trying to implement the Hierarchical SFC concept into ODL SFC. This
is our demo
https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4= c7-SYWX6q4/edit?usp=3Dsharing

I would like to ask anyone interested to help us reviewing our design.
Please give me your comment so that we can discuss further.

Best regards,

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--047d7bdca294b1c1c9052b3d9439-- From nobody Mon Feb 8 08:04:44 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206971B3C93 for ; Sun, 7 Feb 2016 08:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bdpM5SQ-Mxm for ; Sun, 7 Feb 2016 08:26:20 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D3B1B3C91 for ; Sun, 7 Feb 2016 08:26:20 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id 5so44290384igt.0 for ; Sun, 07 Feb 2016 08:26:20 -0800 (PST) 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=1hx8t5heCaSZ1ZE4V7B6rxLJNBnVqbyYexkNbpg7s2c=; b=HFZQ5lKiNr8eiBChK/IdSgr+2JYWrMNH1kkb0XPUcYJmTQKcUWKab1IIB4Et7XUnQx YzlvrNBB8ukgiF3ECqQrTBKH3zPbFXtV72aLo/3v9jymroW27KyVaI6gjFuTG/3FLKwp kMs9H0hCMWZjnS/MG1bwsLH6PNT6kdCY5+IRF8qi50aRiD7ue6veVmq1DAtTNb0c7gkQ wgBOndkxck9JRFuIXE9sezM9/zlw6YYj6TUqeyC+Ya99jUF3C8jCQCEAuAmOa+6MeOa1 ec2gVYUpAsp9UyQ3vCWqIfHiCbDR8+FLD6oo2DHm+LlXRq7Qc+u9hUEE6NAVzZCsr/Ha VSkg== 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=1hx8t5heCaSZ1ZE4V7B6rxLJNBnVqbyYexkNbpg7s2c=; b=J4Y6sOiBxLCtRQfjTG17HdJJrVoTELro7QrfGhJWgNFICK0fVkUJSibCp6iMAjunjU 4TOpwA521KtqxH4/5UtrdOxx0VdfwcuuwGRwxws962EQXKTM5um+MWsPJjxIlU2acL9/ /tdTfB4rvPdyL2ohk1hGA9qy0VSqAQj2wtBRyjIYSLsuCU4gpbny1fJZAYsQe9TrXKqS e59ZM0jaSNBoVJVR4sM9Pdt96cxgI9uDk1PlxPuy3Oa3q6nqd4ymWKuvAeCC5cAYu7xi DL+d1tvpKlAmmc+VTq9MidFxDSShQP4iIeqZ4JyB3Zm5GFD7lZuhQWevKA212D033/Yo YTow== X-Gm-Message-State: AG10YORPwZgWaJ0s4+tZL5Qk/JZW1HTKIEvjLv7pziGc7vnw37IbdtrPlj0iS6aeV1u1Bl28uT7BM7Y9eJK5tQ== MIME-Version: 1.0 X-Received: by 10.50.119.131 with SMTP id ku3mr18465325igb.1.1454862379508; Sun, 07 Feb 2016 08:26:19 -0800 (PST) Received: by 10.64.82.137 with HTTP; Sun, 7 Feb 2016 08:26:19 -0800 (PST) Received: by 10.64.82.137 with HTTP; Sun, 7 Feb 2016 08:26:19 -0800 (PST) In-Reply-To: References: <56B5971F.4090402@gmail.com> Date: Sun, 7 Feb 2016 17:26:19 +0100 Message-ID: From: Keith Burns To: Dave Dolson Content-Type: multipart/alternative; boundary=001a11348b0a53edd6052b308b93 Archived-At: X-Mailman-Approved-At: Mon, 08 Feb 2016 08:04:43 -0800 Cc: VictorVu , opendaylight sfc , sfc@ietf.org, Colin Dixon Subject: Re: [sfc] [sfc-dev] ODL Hierarchical SFC implementation demo X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 16:26:22 -0000 --001a11348b0a53edd6052b308b93 Content-Type: text/plain; charset=UTF-8 I'm also curious how the same thing couldn't be handled with 3 chains and a classifier. Might be an interesting TWS talk even if it's scope is beyond ODL. On Feb 7, 2016 5:11 PM, "Dave Dolson" wrote: > Hi Victor, > Thanks for sharing your design. > I have some comments from my perspective. > > 1. Your slides don't clearly show the controllers. One of the main goals > of hSFC is to have independent control of the top-level domain and > lower-level domains. So I think it is important to show a controller for > each domain. > Note that in the top-level domain, the controller will view the sub-domain > as merely an SF. In the lower-level domain, the controller deals with only > what is in the sub-domain, from controller on down. The IBN is the glue > between them and may be configured independently of either, in my opinion. > I think it is important to consider the controllers may be from different > projects as well (e.g., not all ODL). > In fact, you should consider doing this work outside of the ODL project. > It seems to be more general. > > 2. The use of MD-1 for the SFF IP address is troubling because (a) it > doesn't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH > (vs. Ethernet/NSH and others). It isn't clear to me that this information > needs to be saved in the packet anyhow, because the SFF is always the same. > E.g., SFF2 can just be configured as the SFF for the IBN. > > 3. Looking at slide 10, keeping in mind the bidirectional nature of > traffic, it may be useful to show classifiers on both sides of the > sub-domain, or make it more clear that the red path is only for > client-to-server traffic and a different path is required for > server-to-client traffic. > > I look forward to following your work. > Thanks, > -Dave > > ________________________________________ > From: VictorVu [minowar91@gmail.com] > Sent: Saturday, February 06, 2016 1:47 AM > To: opendaylight sfc > Cc: Dave Dolson > Subject: ODL Hierarchical SFC implementation demo > > Hi, > I m trying to implement the Hierarchical SFC concept into ODL SFC. This > is our demo > > https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4c7-SYWX6q4/edit?usp=sharing > > I would like to ask anyone interested to help us reviewing our design. > Please give me your comment so that we can discuss further. > > Best regards, > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > sfc-dev mailing list > sfc-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > --001a11348b0a53edd6052b308b93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm also curious how the same thing couldn't be hand= led with 3 chains and a classifier. Might be an interesting TWS talk even i= f it's scope is beyond ODL.

On Feb 7, 2016 5:11 PM, "Dave Dolson" = <ddolson@sandvine.com> wr= ote:
Hi Victor,
Thanks for sharing your design.
I have some comments from my perspective.

1. Your slides don't clearly show the controllers. One of the main goal= s of hSFC is to have independent control of the top-level domain and lower-= level domains. So I think it is important to show a controller for each dom= ain.
Note that in the top-level domain, the controller will view the sub-domain = as merely an SF. In the lower-level domain, the controller deals with only = what is in the sub-domain, from controller on down. The IBN is the glue bet= ween them and may be configured independently of either, in my opinion.
I think it is important to consider the controllers may be from different p= rojects as well (e.g., not all ODL).
In fact, you should consider doing this work outside of the ODL project. It= seems to be more general.

2. The use of MD-1 for the SFF IP address is troubling because (a) it doesn= 't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH (= vs. Ethernet/NSH and others). It isn't clear to me that this informatio= n needs to be saved in the packet anyhow, because the SFF is always the sam= e. E.g., SFF2 can just be configured as the SFF for the IBN.

3. Looking at slide 10, keeping in mind the bidirectional nature of traffic= , it may be useful to show classifiers on both sides of the sub-domain, or = make it more clear that the red path is only for client-to-server traffic a= nd a different path is required for server-to-client traffic.

I look forward to following your work.
Thanks,
-Dave

________________________________________
From: VictorVu [minowar91@gmail.com<= /a>]
Sent: Saturday, February 06, 2016 1:47 AM
To: opendaylight sfc
Cc: Dave Dolson
Subject: ODL Hierarchical SFC implementation demo

Hi,
I m trying to implement the Hierarchical SFC concept into ODL SFC. This
is our demo
https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4= c7-SYWX6q4/edit?usp=3Dsharing

I would like to ask anyone interested to help us reviewing our design.
Please give me your comment so that we can discuss further.

Best regards,

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
sfc-dev mailing list
sfc-dev@lists.opendayligh= t.org
https://lists.opendaylight.org/mailman/listin= fo/sfc-dev
--001a11348b0a53edd6052b308b93-- From nobody Thu Feb 11 11:18:33 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FB41B3966 for ; Thu, 11 Feb 2016 11:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lO2W-11ucmm for ; Thu, 11 Feb 2016 11:18:31 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D542C1B2E3B for ; Thu, 11 Feb 2016 11:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5049; q=dns/txt; s=iport; t=1455218310; x=1456427910; h=from:to:subject:date:message-id:mime-version; bh=Oj6RHViEM0r6cZokkmRmFILtvg6MGbyXK/f/lMPYiUg=; b=KY/FGSb8Z7uo+CcBmFsYkVYx0DGLG4TMtHSMtWkX3vc0pGR/am5VTbo/ T9kUyS5XCbROOlQbPtp/57TrEHq79+/Zrui1pXsx5TDhjNUrpTEWqswqs oRc2+CKQq0R6G/GoK160QSYPANp8V8JUwWxUlZZDFyRaGclFeLIzSNJ+s 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBQAk3rxW/49dJa1egm5MgUWIVbE4g?= =?us-ascii?q?WeHQzkTAQEBAQEBAX8LhEgdbgGBACcEiC2iWZ5iAQEIAgEdhhKIOBEBhFgFjV+?= =?us-ascii?q?FD4QJAYETjD+BXYRDiFWOPQEhAUCDZYgNNHwBAQE?= X-IronPort-AV: E=Sophos; i="5.22,432,1449532800"; d="scan'208,217"; a="70542633" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 19:18:26 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1BJIPHA005418 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Feb 2016 19:18:26 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 13:18:25 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 13:18:25 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJA== Date: Thu, 11 Feb 2016 19:18:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D2E248AF4327Bjguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:18:32 -0000 --_000_D2E248AF4327Bjguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-trace-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_D2E248AF4327Bjguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <50AFF4044F1D8C4EA3409D13709975AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-trace-03 as a WG document. The = call for adoption will run for 2 weeks ending 2/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG’s = decisions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is als= o a good time to poll for knowledge of any IPR that applies to this draft, = in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).= If you are listed as a document author please respond to this email (to th= e chairs) whether or not you are aware of any relevant IPR.


Thanks!


SFC Chairs

--_000_D2E248AF4327Bjguicharciscocom_-- From nobody Thu Feb 11 11:24:49 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F011B3967 for ; Thu, 11 Feb 2016 11:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0HNKACXGvF0 for ; Thu, 11 Feb 2016 11:24:43 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97931B3962 for ; Thu, 11 Feb 2016 11:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5049; q=dns/txt; s=iport; t=1455218682; x=1456428282; h=from:to:subject:date:message-id:mime-version; bh=XTDsAHpEvG39rD6dBXz3miq0itm6KfVLE2XTe4egyNc=; b=Vl7LQTTLB1u8AW31odUCblydojpIFwPprhZlcJHNW7esDYG59yuql07S DmPJA96YBTa7z0ehX+oMSJ52nzBUMfsseWdPyFa0I2row/4p9q3C0iwmV jKtTLwQ6oTXt7X9GO41F5CT0tKRVpciuSB/ye46qZVwKYlfnAd+G2pyNt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBQDF37xW/5FdJa1egm5MgUWIVbE4g?= =?us-ascii?q?WeHQzkTAQEBAQEBAX8LhEgdbgGBACcEiC2iXp5hAQEIAgEdhhKIOBEBhFgFjV+?= =?us-ascii?q?FD4QJAYETjD+BXYRDiFWOPQEhAUCDZYgNNHwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208,217";a="236014157" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 19:24:21 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1BJOLoE010990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Feb 2016 19:24:21 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 13:24:20 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 13:24:21 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAQ== Date: Thu, 11 Feb 2016 19:24:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D2E24A1343289jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:24:46 -0000 --_000_D2E24A1343289jguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-appid-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_D2E24A1343289jguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-appid-03 as a WG document. The = call for adoption will run for 2 weeks ending 2/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG’s = decisions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is als= o a good time to poll for knowledge of any IPR that applies to this draft, = in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).= If you are listed as a document author please respond to this email (to th= e chairs) whether or not you are aware of any relevant IPR.


Thanks!


SFC Chairs

--_000_D2E24A1343289jguicharciscocom_-- From nobody Thu Feb 11 11:58:56 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419DA1B3961 for ; Thu, 11 Feb 2016 11:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1B2bA9oQSv3 for ; Thu, 11 Feb 2016 11:58:50 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42721B2EEC for ; Thu, 11 Feb 2016 11:58:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AA3FD2A5F00; Thu, 11 Feb 2016 11:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455220730; bh=O+bsc4tcFsX/Wqy+Uj3TXJ3oxOrAXLM7boaimQbC0n4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LgPbAoYy9Ag/L7U08H/tIhy19pS1JiTeKZxzuTdmq9Nhkwo9+wuMR+14mNXkpv+8o kyQX69/FPjbx7hETD8re1zY+W+Bqty3oSFmGipKR9CVtz/PlfkDX5UUkHJrWV2n6ui jroNG306RUn4qjigHQ7CJdZjFL1AmyZ2QgJZ0hSA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43C1D1C07A1; Thu, 11 Feb 2016 11:58:50 -0800 (PST) To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <56BCE7C5.5030109@joelhalpern.com> Date: Thu, 11 Feb 2016 14:57:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 19:58:55 -0000 I am reluctant to adopt this document as it stands. I have two related concerns, both related to the basic approach. First, the proposal has no mechanism for tracing the service function forwarders. It seems to me that in terms of OAM of service function paths, the service function forwarders are the critical element to be able to verify. Second, it assumes that there is value in having a special aspect of the service functions report service function type and identity. Given that this will be specialized code, it does not tell us much about the actual operation of the service functions. As a lesser concern, there is a routing area design team working to pull together a coherent approach to OAM. I would at least like to talk with them before we adopt a basic approach that may be needlessly at variance with other ongoing work. Yours, Joel On 2/11/16 2:18 PM, Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of draft-penno-sfc-trace-03 > as a WG document. The call for adoption will run for 2 weeks ending > 2/25/2016. > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the WG’s decisions. > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email (to > the chairs) whether or not you are aware of any relevant IPR. > > > Thanks! > > > SFC Chairs > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 11 12:06:16 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268451B39C6 for ; Thu, 11 Feb 2016 12:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwYbvp1D7nyP for ; Thu, 11 Feb 2016 12:06:07 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399671B2EF2 for ; Thu, 11 Feb 2016 12:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2911; q=dns/txt; s=iport; t=1455221167; x=1456430767; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sk6qZOJl8Wi7dljJVVdIyECTgPoiniAMx8gfHQK0ovg=; b=LkxpHtfn+M1y9Gllaa0J8DRBjX+fLpsev8zLkPUlVGTWF/K4aVoyJBj4 Jf4sJr/xa3mRf4kY8db/t3Z+yzg/DsRq+FkaZ0fd1MZbIFcPnCJLEOSyC +Cr8rsR2s50cIUXCFnriA6Vj6JccczM5UCxNn49aK/rBqz8Bvr2yYij/T Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBn6bxW/4cNJK1VCYM6Um0GiFWxK?= =?us-ascii?q?wENgWcXCoVsAoE1OBQBAQEBAQEBgQqEQgEBBAEBARpRGwIBCBguJwslAgQBEog?= =?us-ascii?q?aDsErAQEBAQEBAQEBAQEBAQEBAQEVBIYShDaEAgcKAYRYBY1fiRgBjVKBXYRDi?= =?us-ascii?q?FWOPQEeAQFCg2VqhyM0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="237477227" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 20:05:55 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1BK5tlA001636 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 20:05:55 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 14:05:54 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 14:05:54 -0600 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4A= Date: Thu, 11 Feb 2016 20:05:54 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> In-Reply-To: <56BCE7C5.5030109@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.204] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <967A896B16B61144A566A94FB0CD0CF4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:06:13 -0000 Hello Joel, On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" wrote: >I am reluctant to adopt this document as it stands. >I have two related concerns, both related to the basic approach. > >First, the proposal has no mechanism for tracing the service function >forwarders. It seems to me that in terms of OAM of service function >paths, the service function forwarders are the critical element to be >able to verify. [RP] The SFF info is present in the trace reply message. Maybe we need to put more info? > >Second, it assumes that there is value in having a special aspect of the >service functions report service function type and identity. Given that >this will be specialized code, it does not tell us much about the actual >operation of the service functions. [RP] I think it is basic info. An admin will know that the SF that the packet is traversing is of proper type and actual instance. Given protocol is extensible one has extend to include many other SF specific metrics. > >As a lesser concern, there is a routing area design team working to pull >together a coherent approach to OAM. I would at least like to talk with >them before we adopt a basic approach that may be needlessly at variance >with other ongoing work. > >Yours, >Joel > >On 2/11/16 2:18 PM, Jim Guichard (jguichar) wrote: >> Dear WG: >> >> >> This email serves as a call for WG adoption of draft-penno-sfc-trace-03 >> as a WG document. The call for adoption will run for 2 weeks ending >> 2/25/2016. >> >> Please note that this is a call for adoption, and not a last call for >> content of the document. Adopting a WG document simply means that the WG >> will focus its efforts on that particular draft going forward, and use >> that document for resolving open issues and documenting the WG=B9s >>decisions. >> >> Please indicate whether you support adoption for not, and if not why. >> Issues you have with the current document itself can also be raised, but >> they should be raised in the context of what should be changed in the >> document going forward, rather than a pre-condition for adoption. >> >> Finally, now is also a good time to poll for knowledge of any IPR that >> applies to this draft, in line with the IPR disclosure obligations for >> WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). >> If you are listed as a document author please respond to this email (to >> the chairs) whether or not you are aware of any relevant IPR. >> >> >> Thanks! >> >> >> SFC Chairs >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 11 12:19:21 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95B61B39EE for ; Thu, 11 Feb 2016 12:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nQ6h_NQW-Y6 for ; Thu, 11 Feb 2016 12:19:11 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A140F1B39EA for ; Thu, 11 Feb 2016 12:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=313; q=dns/txt; s=iport; t=1455221946; x=1456431546; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=+5nen9hn1X4fqSsbkE5+EfpYDGVJP0R6/kblm3k3Iig=; b=hfCfLfcVnlZxioxCwytVcriNmSfATk2U/lvLg/ii3xd2d9DOi97Uw4/6 qFoAPqR+VwxSGp1pWu1FIvgs5O7zXdyXqvdUcje7pq65jRNM6iqeOTAyA QqeAw3zr6XYn2ciKqHiUE9taOQugcfsgoT70SpTjQQWv68IHSz92Q9ELZ g=; X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="236863372" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 20:19:06 +0000 Received: from [10.82.249.58] (rtp-vpn6-313.cisco.com [10.82.249.58]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1BKJ559008919; Thu, 11 Feb 2016 20:19:05 GMT To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <56BCECB8.5000005@cisco.com> Date: Thu, 11 Feb 2016 15:19:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:19:13 -0000 On 2/11/16 14:18, Jim Guichard (jguichar) wrote: > Dear WG: > > > This email serves as a call for WG adoption of draft-penno-sfc-trace-03 > as a WG document. The call for adoption will run for 2 weeks ending > 2/25/2016. I support adoption. This is useful for troubleshooting the service plane. Joe From nobody Thu Feb 11 12:29:16 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DB81B3A0E for ; Thu, 11 Feb 2016 12:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKa1grem7gLD for ; Thu, 11 Feb 2016 12:29:14 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BD71B3A0D for ; Thu, 11 Feb 2016 12:29:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E55A22A5F46; Thu, 11 Feb 2016 12:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455222553; bh=loNEM2hbo3awV/Ztr8VhSYE+TPWx2nF6e5dqsCDdZaM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lghTVordXH+iVQzQy66Zefl38CUmU/O2UaAP14xfRGXaTlJuHT2bVNPeSjaV8LsF2 OAIOQKuv/HhT/loBa4EQAyJnUGrJqKBljmgO1hAwVeM68ieN9aBY+4OPb0qCH7vUfx L8Ps6WO5mgIfW4TJmuYkyQN5fLMKBqeysmu4gL9A= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 75ABF1C0C4F; Thu, 11 Feb 2016 12:29:13 -0800 (PST) To: "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <56BCE7C5.5030109@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56BCEEE4.8080401@joelhalpern.com> Date: Thu, 11 Feb 2016 15:28:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:29:15 -0000 On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: > Hello Joel, > > On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" > wrote: > >> I am reluctant to adopt this document as it stands. >> I have two related concerns, both related to the basic approach. >> >> First, the proposal has no mechanism for tracing the service function >> forwarders. It seems to me that in terms of OAM of service function >> paths, the service function forwarders are the critical element to be >> able to verify. > > > [RP] The SFF info is present in the trace reply message. Maybe we need to > put more info? [JMH] What I see is that if a traceroute somehow gets to an SFF with an SI of the SIL, the SFF will generate a response. The current understanding is that SF rather than SFF will decrement TTL. If so, if the SI hits the limit, the SF will generate the response, and the packet won't get to the next SFF. So I can't see when this case would ever get triggered. Also, it is rather unclear how the receiver would know that a response was from the SFF rather than an SF. Is there a magic SF Type for SFF? > >> >> Second, it assumes that there is value in having a special aspect of the >> service functions report service function type and identity. Given that >> this will be specialized code, it does not tell us much about the actual >> operation of the service functions. > > > [RP] I think it is basic info. An admin will know that the SF that the > packet is traversing is of proper type and actual instance. Given protocol > is extensible one has extend to include many other SF specific metrics. > [JMH}I was apparently unclear. I am not asking for more information. I am not sure that this is useful information to extract. The actual configuration of this information is not related to the work the service function does, so there is no reason for it to be correct. And trying to monitor service function operability this way seems unfortunate. Yours, Joel From nobody Thu Feb 11 12:47:38 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F191B2F3C for ; Thu, 11 Feb 2016 12:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnIRPg4Y5Bfd for ; Thu, 11 Feb 2016 12:47:26 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EDC1B3A1A for ; Thu, 11 Feb 2016 12:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2631; q=dns/txt; s=iport; t=1455223646; x=1456433246; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eH6U9C89oglkQdYst5fVYx2/X74GVRj/8umfVzThwsw=; b=b92ufaH9+HC25VR0Jw2AOUpm2z1uXGqQI6D0xDFXPa7KhJUjTL/bdv6O B2JllbbbCciaBrFmnjyqhSGD+F4IMVyB6hsnEirTTVjaQnneHoLuzmw+j hS2nTDRYn1mmThRl19A5IU4NdwM9/lgTBuiNX+33H7UIk8vOre5oYmoVt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQDg8rxW/5FdJa1VCYM6gT8GiFWxK?= =?us-ascii?q?wENgWeGDQKBNTgUAQEBAQEBAYEKhEIBAQQdHU8CAQgYHhAyJQIEARKIGsFGAQE?= =?us-ascii?q?BAQEBAQMBAQEBAQEahhKENoQJBCOEPAWWdwGNUo51jj0BHgEBQoNlaocbPHwBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.22,432,1449532800"; d="scan'208";a="237490356" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 20:47:25 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1BKlPfK005200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 20:47:25 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 14:47:24 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 14:47:24 -0600 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaA Date: Thu, 11 Feb 2016 20:47:24 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> In-Reply-To: <56BCEEE4.8080401@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.204] Content-Type: text/plain; charset="us-ascii" Content-ID: <2ADC76FF2A7CF34181AF5F1AF422FCD0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:47:37 -0000 The response is always from SFF because that is the entity that drops the packet. That is precisely the situation this tool is supposed to detect. IF the SI (even for regular data packets) is not large enough the packet will dropped by the SFF, not SF. A packet that is decremented to SI=3D0 (wa= s 1 on ingress to SF) was processed by SF and should still be sent packet to SFF, which will then drop it. On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: > > >On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >> Hello Joel, >> >> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >> wrote: >> >>> I am reluctant to adopt this document as it stands. >>> I have two related concerns, both related to the basic approach. >>> >>> First, the proposal has no mechanism for tracing the service function >>> forwarders. It seems to me that in terms of OAM of service function >>> paths, the service function forwarders are the critical element to be >>> able to verify. >> >> >> [RP] The SFF info is present in the trace reply message. Maybe we need >>to >> put more info? >[JMH] What I see is that if a traceroute somehow gets to an SFF with an >SI of the SIL, the SFF will generate a response. The current >understanding is that SF rather than SFF will decrement TTL. If so, if >the SI hits the limit, the SF will generate the response, and the packet >won't get to the next SFF. So I can't see when this case would ever get >triggered. >Also, it is rather unclear how the receiver would know that a response >was from the SFF rather than an SF. Is there a magic SF Type for SFF? > >> >>> >>> Second, it assumes that there is value in having a special aspect of >>>the >>> service functions report service function type and identity. Given >>>that >>> this will be specialized code, it does not tell us much about the >>>actual >>> operation of the service functions. >> >> >> [RP] I think it is basic info. An admin will know that the SF that the >> packet is traversing is of proper type and actual instance. Given >>protocol >> is extensible one has extend to include many other SF specific metrics. >> >[JMH}I was apparently unclear. I am not asking for more information. I >am not sure that this is useful information to extract. The actual >configuration of this information is not related to the work the service >function does, so there is no reason for it to be correct. And trying >to monitor service function operability this way seems unfortunate. > >Yours, >Joel From nobody Thu Feb 11 12:52:42 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9434A1B3A3B for ; Thu, 11 Feb 2016 12:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-GHCKhOfjPo for ; Thu, 11 Feb 2016 12:52:26 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630451B3A42 for ; Thu, 11 Feb 2016 12:52:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48D712A5F51; Thu, 11 Feb 2016 12:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455223940; bh=76ob81nPIrR5Ky+p0epRPYjYmnGIuRLBIKzStX/iP80=; h=Subject:To:References:From:Date:In-Reply-To:From; b=q/TpCYWvnvohNiOi5sJE7ZttNORE1+mI9ZDPbW4guqWBVFjooCtr7jBQmKkL91fik THuGk+wdV5t5mqeBkJ7qKKvg3G7AELcik//a9PPzQi2efZuBfWn/On0w4Y23S+8V1D yCUM/q5pNb4mr2Nt/wFEXyoaj5uU2iLXALWherQ8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CFC942A5F52; Thu, 11 Feb 2016 12:52:19 -0800 (PST) To: "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56BCF44E.7070406@joelhalpern.com> Date: Thu, 11 Feb 2016 15:51:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:52:30 -0000 Ahh. I had missed how you were interacting between the SF and the SFF. Sorry. Please confirm: the idea is that the SF at the end will add its information, and then the SFF fronting it will send the resulting traceroute response? It looks like the response is an NSH packet. In which case it goes in the NSH transport. If that transport is MPLS, for example, how will the receiver know who sent the response? Yours, Joel On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: > The response is always from SFF because that is the entity that drops the > packet. That is precisely the situation this tool is supposed to detect. > IF the SI (even for regular data packets) is not large enough the packet > will dropped by the SFF, not SF. A packet that is decremented to SI=0 (was > 1 on ingress to SF) was processed by SF and should still be sent packet to > SFF, which will then drop it. > > > On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: > >> >> >> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>> Hello Joel, >>> >>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>> wrote: >>> >>>> I am reluctant to adopt this document as it stands. >>>> I have two related concerns, both related to the basic approach. >>>> >>>> First, the proposal has no mechanism for tracing the service function >>>> forwarders. It seems to me that in terms of OAM of service function >>>> paths, the service function forwarders are the critical element to be >>>> able to verify. >>> >>> >>> [RP] The SFF info is present in the trace reply message. Maybe we need >>> to >>> put more info? >> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >> SI of the SIL, the SFF will generate a response. The current >> understanding is that SF rather than SFF will decrement TTL. If so, if >> the SI hits the limit, the SF will generate the response, and the packet >> won't get to the next SFF. So I can't see when this case would ever get >> triggered. >> Also, it is rather unclear how the receiver would know that a response >> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >> >>> >>>> >>>> Second, it assumes that there is value in having a special aspect of >>>> the >>>> service functions report service function type and identity. Given >>>> that >>>> this will be specialized code, it does not tell us much about the >>>> actual >>>> operation of the service functions. >>> >>> >>> [RP] I think it is basic info. An admin will know that the SF that the >>> packet is traversing is of proper type and actual instance. Given >>> protocol >>> is extensible one has extend to include many other SF specific metrics. >>> >> [JMH}I was apparently unclear. I am not asking for more information. I >> am not sure that this is useful information to extract. The actual >> configuration of this information is not related to the work the service >> function does, so there is no reason for it to be correct. And trying >> to monitor service function operability this way seems unfortunate. >> >> Yours, >> Joel > > From nobody Thu Feb 11 13:42:34 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AE51B3AE2 for ; Thu, 11 Feb 2016 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T367BhRwinC for ; Thu, 11 Feb 2016 13:42:21 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39D51B3ADF for ; Thu, 11 Feb 2016 13:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3588; q=dns/txt; s=iport; t=1455226940; x=1456436540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qWYn0t5lSiu/CbeYji4KJt0xtnxEn+4Y4RerrlzyhQA=; b=e/7Ymd5Ro1cK6kYTANfG/Z7dUXNe/GLuq4oTvOvayw9XuuetR3/WlrKH 2Ao3F2Wrb/GV7v2o4WWGw4RfejAexKwoNun0tB15TKKtcOhRWiLnfgFkU x8l7vcoUEpQkK7njQ5Pkvur42UHPkDp5YT/RJhq1h3WII4V80HjOART1F M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQD5/7xW/5ldJa1VCYM6gT+IW7ErA?= =?us-ascii?q?Q2BZ4YNAoE1OBQBAQEBAQEBgQqEQQEBAQMBHR0/BQsCAQgYHhAyJQIEDgWIEgj?= =?us-ascii?q?BTQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGEoFsgkqECQQjgy2BDwWWdwGNUoFdh?= =?us-ascii?q?EOIVY49AR4BAUKDZWqHG4E4AQEB?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="70298276" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 21:41:56 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1BLfueE019118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 21:41:56 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 15:41:55 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 15:41:55 -0600 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaAgACHPgD//6mGVA== Date: Thu, 11 Feb 2016 21:41:55 +0000 Message-ID: <28330B1E-07A2-41D3-B2E1-68F428BCD1B7@cisco.com> References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> ,<56BCF44E.7070406@joelhalpern.com> In-Reply-To: <56BCF44E.7070406@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 21:42:23 -0000 > On Feb 11, 2016, at 12:52 PM, Joel M. Halpern wrote= : >=20 > Ahh. I had missed how you were interacting between the SF and the SFF. = Sorry. >=20 > Please confirm: the idea is that the SF at the end will add its informat= ion, and then the SFF fronting it will send the resulting traceroute respon= se? [RP] confirmed >=20 > It looks like the response is an NSH packet. In which case it goes in th= e NSH transport. If that transport is MPLS, for example, how will the rece= iver know who sent the response? [RP] need to think of what kind of info can be put in the response tlv. >=20 > Yours, > Joel >=20 >> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >> The response is always from SFF because that is the entity that drops th= e >> packet. That is precisely the situation this tool is supposed to detect. >> IF the SI (even for regular data packets) is not large enough the packet >> will dropped by the SFF, not SF. A packet that is decremented to SI=3D0 = (was >> 1 on ingress to SF) was processed by SF and should still be sent packet = to >> SFF, which will then drop it. >>=20 >>=20 >>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>=20 >>>=20 >>>=20 >>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>> Hello Joel, >>>>=20 >>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>> wrote: >>>>=20 >>>>> I am reluctant to adopt this document as it stands. >>>>> I have two related concerns, both related to the basic approach. >>>>>=20 >>>>> First, the proposal has no mechanism for tracing the service function >>>>> forwarders. It seems to me that in terms of OAM of service function >>>>> paths, the service function forwarders are the critical element to be >>>>> able to verify. >>>>=20 >>>>=20 >>>> [RP] The SFF info is present in the trace reply message. Maybe we need >>>> to >>>> put more info? >>> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >>> SI of the SIL, the SFF will generate a response. The current >>> understanding is that SF rather than SFF will decrement TTL. If so, if >>> the SI hits the limit, the SF will generate the response, and the packe= t >>> won't get to the next SFF. So I can't see when this case would ever ge= t >>> triggered. >>> Also, it is rather unclear how the receiver would know that a response >>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>>=20 >>>>=20 >>>>>=20 >>>>> Second, it assumes that there is value in having a special aspect of >>>>> the >>>>> service functions report service function type and identity. Given >>>>> that >>>>> this will be specialized code, it does not tell us much about the >>>>> actual >>>>> operation of the service functions. >>>>=20 >>>>=20 >>>> [RP] I think it is basic info. An admin will know that the SF that the >>>> packet is traversing is of proper type and actual instance. Given >>>> protocol >>>> is extensible one has extend to include many other SF specific metrics= . >>> [JMH}I was apparently unclear. I am not asking for more information. = I >>> am not sure that this is useful information to extract. The actual >>> configuration of this information is not related to the work the servic= e >>> function does, so there is no reason for it to be correct. And trying >>> to monitor service function operability this way seems unfortunate. >>>=20 >>> Yours, >>> Joel >>=20 >>=20 From nobody Thu Feb 11 13:59:59 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6D1B3B26 for ; Thu, 11 Feb 2016 13:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZggoRuihEu8 for ; Thu, 11 Feb 2016 13:59:51 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4C1B3B24 for ; Thu, 11 Feb 2016 13:59:51 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0195.001; Thu, 11 Feb 2016 16:59:55 -0500 From: Dave Dolson To: "Joel M. Halpern" , "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8nltCAgAACOQCAAAZEAIAABVQAgAABIQD//7QmIA== Date: Thu, 11 Feb 2016 21:59:54 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> In-Reply-To: <56BCF44E.7070406@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 21:59:55 -0000 Reinaldo, I also have the question about the trace report. It is to be sent to=20 an IP/port, but the transport is not mentioned (that I could see). Is it intended to be UDP? -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 11, 2016 3:51 PM To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Ahh. I had missed how you were interacting between the SF and the SFF.=20 Sorry. Please confirm: the idea is that the SF at the end will add its=20 information, and then the SFF fronting it will send the resulting=20 traceroute response? It looks like the response is an NSH packet. In which case it goes in=20 the NSH transport. If that transport is MPLS, for example, how will the=20 receiver know who sent the response? Yours, Joel On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: > The response is always from SFF because that is the entity that drops the > packet. That is precisely the situation this tool is supposed to detect. > IF the SI (even for regular data packets) is not large enough the packet > will dropped by the SFF, not SF. A packet that is decremented to SI=3D0 (= was > 1 on ingress to SF) was processed by SF and should still be sent packet t= o > SFF, which will then drop it. > > > On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: > >> >> >> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>> Hello Joel, >>> >>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>> wrote: >>> >>>> I am reluctant to adopt this document as it stands. >>>> I have two related concerns, both related to the basic approach. >>>> >>>> First, the proposal has no mechanism for tracing the service function >>>> forwarders. It seems to me that in terms of OAM of service function >>>> paths, the service function forwarders are the critical element to be >>>> able to verify. >>> >>> >>> [RP] The SFF info is present in the trace reply message. Maybe we need >>> to >>> put more info? >> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >> SI of the SIL, the SFF will generate a response. The current >> understanding is that SF rather than SFF will decrement TTL. If so, if >> the SI hits the limit, the SF will generate the response, and the packet >> won't get to the next SFF. So I can't see when this case would ever get >> triggered. >> Also, it is rather unclear how the receiver would know that a response >> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >> >>> >>>> >>>> Second, it assumes that there is value in having a special aspect of >>>> the >>>> service functions report service function type and identity. Given >>>> that >>>> this will be specialized code, it does not tell us much about the >>>> actual >>>> operation of the service functions. >>> >>> >>> [RP] I think it is basic info. An admin will know that the SF that the >>> packet is traversing is of proper type and actual instance. Given >>> protocol >>> is extensible one has extend to include many other SF specific metrics. >>> >> [JMH}I was apparently unclear. I am not asking for more information. I >> am not sure that this is useful information to extract. The actual >> configuration of this information is not related to the work the service >> function does, so there is no reason for it to be correct. And trying >> to monitor service function operability this way seems unfortunate. >> >> Yours, >> Joel > > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 11 14:08:15 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C414E1B3B28 for ; Thu, 11 Feb 2016 14:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHbjkzNrJhLw for ; Thu, 11 Feb 2016 14:08:08 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5929A1B3006 for ; Thu, 11 Feb 2016 14:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4477; q=dns/txt; s=iport; t=1455228488; x=1456438088; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=a07XgTa/cYfX8JWiTy7mbAu1EnJhTb8wBBCcSAeLQZ8=; b=KhWLFXTt1dCiHSJFuljzjzBuRKtbIQaz996ctxXPBL/YIDNV0LcnZstM KCYHU1H6EELBiAz6U5Dv0pRfBcZSIN4gyXvC1p8/yhzg9j/t96HHvCOTH DUrHGDHjHizLO8QRdwwXnHtMenKV5vFvNqhzfx8JVegYEhg7piXS6vwo2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCEBb1W/4oNJK1VCYM6Um0GiFWxK?= =?us-ascii?q?wENgWcXCoVsAoE1OBQBAQEBAQEBgQqEQQEBAQQBAQEaURcEAgEIDgMEAQEBJwc?= =?us-ascii?q?nCxQJCAIEARKIGg7BNAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKENoQJBIRfB?= =?us-ascii?q?Y1fiRgBjVKBXYRDiFWOPQEeAQFCggIZgUpqhxs8fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="235729743" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 22:08:07 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1BM87L8013355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 22:08:07 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 16:08:06 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 16:08:06 -0600 From: "Reinaldo Penno (repenno)" To: Dave Dolson , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaAgACHPgCAABMhAP//fC2A Date: Thu, 11 Feb 2016 22:08:06 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.204] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9A8696EB78E253489117367666C9CFD7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:08:13 -0000 The current implementation uses UDP because of NAT traversal. This is something I did because at some point my SFC trace client was behind a NAT and I wanted to get my responses back. How useful this is? Can=B9t say, it was to me.=20 The draft says (I hope) that the transport used should be the same as the one in NSH the trace request. But I=B9m open to suggestions (or more importantly actual text) since Joel also had a questions about it. On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >Reinaldo, >I also have the question about the trace report. It is to be sent to >an IP/port, but the transport is not mentioned (that I could see). >Is it intended to be UDP? > >-Dave > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Thursday, February 11, 2016 3:51 PM >To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > >Ahh. I had missed how you were interacting between the SF and the SFF. > Sorry. > >Please confirm: the idea is that the SF at the end will add its >information, and then the SFF fronting it will send the resulting >traceroute response? > >It looks like the response is an NSH packet. In which case it goes in >the NSH transport. If that transport is MPLS, for example, how will the >receiver know who sent the response? > >Yours, >Joel > >On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >> The response is always from SFF because that is the entity that drops >>the >> packet. That is precisely the situation this tool is supposed to detect. >> IF the SI (even for regular data packets) is not large enough the packet >> will dropped by the SFF, not SF. A packet that is decremented to SI=3D0 >>(was >> 1 on ingress to SF) was processed by SF and should still be sent packet >>to >> SFF, which will then drop it. >> >> >> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >> >>> >>> >>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>> Hello Joel, >>>> >>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>> wrote: >>>> >>>>> I am reluctant to adopt this document as it stands. >>>>> I have two related concerns, both related to the basic approach. >>>>> >>>>> First, the proposal has no mechanism for tracing the service function >>>>> forwarders. It seems to me that in terms of OAM of service function >>>>> paths, the service function forwarders are the critical element to be >>>>> able to verify. >>>> >>>> >>>> [RP] The SFF info is present in the trace reply message. Maybe we need >>>> to >>>> put more info? >>> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >>> SI of the SIL, the SFF will generate a response. The current >>> understanding is that SF rather than SFF will decrement TTL. If so, if >>> the SI hits the limit, the SF will generate the response, and the >>>packet >>> won't get to the next SFF. So I can't see when this case would ever >>>get >>> triggered. >>> Also, it is rather unclear how the receiver would know that a response >>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>> >>>> >>>>> >>>>> Second, it assumes that there is value in having a special aspect of >>>>> the >>>>> service functions report service function type and identity. Given >>>>> that >>>>> this will be specialized code, it does not tell us much about the >>>>> actual >>>>> operation of the service functions. >>>> >>>> >>>> [RP] I think it is basic info. An admin will know that the SF that the >>>> packet is traversing is of proper type and actual instance. Given >>>> protocol >>>> is extensible one has extend to include many other SF specific >>>>metrics. >>>> >>> [JMH}I was apparently unclear. I am not asking for more information. >>>I >>> am not sure that this is useful information to extract. The actual >>> configuration of this information is not related to the work the >>>service >>> function does, so there is no reason for it to be correct. And trying >>> to monitor service function operability this way seems unfortunate. >>> >>> Yours, >>> Joel >> >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 11 14:17:05 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2A1B3B5D for ; Thu, 11 Feb 2016 14:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K55ZPMAUI_4k for ; Thu, 11 Feb 2016 14:16:50 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABDB1B3B4F for ; Thu, 11 Feb 2016 14:16:50 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Thu, 11 Feb 2016 17:16:49 -0500 From: Dave Dolson To: "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8nltCAgAACOQCAAAZEAIAABVQAgAABIQD//7QmIIAAYUUA//+slwA= Date: Thu, 11 Feb 2016 22:16:53 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:17:02 -0000 Oh I see, you do say "The SFF will use the same encapsulation as the receiv= ed packet." I guess then the packets would traverse SFC somehow to get back? Actually, I think it is useful to use UDP for the trace report regardless=20 of the encapsulation type. In other words, the OAM packet traverses the data plane until an SFF acts on it, and then the report is sent over the control plane. I think this is what you have, effectively, which is why you like the UDP. How do you feel about that, sending the trace report over UDP regardless of= the NSH encapsulation? -Dave -----Original Message----- From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]=20 Sent: Thursday, February 11, 2016 5:08 PM To: Dave Dolson; Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 The current implementation uses UDP because of NAT traversal. This is something I did because at some point my SFC trace client was behind a NAT and I wanted to get my responses back. How useful this is? Can=B9t say, it was to me.=20 The draft says (I hope) that the transport used should be the same as the one in NSH the trace request. But I=B9m open to suggestions (or more importantly actual text) since Joel also had a questions about it. On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >Reinaldo, >I also have the question about the trace report. It is to be sent to >an IP/port, but the transport is not mentioned (that I could see). >Is it intended to be UDP? > >-Dave > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Thursday, February 11, 2016 3:51 PM >To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > >Ahh. I had missed how you were interacting between the SF and the SFF. > Sorry. > >Please confirm: the idea is that the SF at the end will add its >information, and then the SFF fronting it will send the resulting >traceroute response? > >It looks like the response is an NSH packet. In which case it goes in >the NSH transport. If that transport is MPLS, for example, how will the >receiver know who sent the response? > >Yours, >Joel > >On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >> The response is always from SFF because that is the entity that drops >>the >> packet. That is precisely the situation this tool is supposed to detect. >> IF the SI (even for regular data packets) is not large enough the packet >> will dropped by the SFF, not SF. A packet that is decremented to SI=3D0 >>(was >> 1 on ingress to SF) was processed by SF and should still be sent packet >>to >> SFF, which will then drop it. >> >> >> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >> >>> >>> >>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>> Hello Joel, >>>> >>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>> wrote: >>>> >>>>> I am reluctant to adopt this document as it stands. >>>>> I have two related concerns, both related to the basic approach. >>>>> >>>>> First, the proposal has no mechanism for tracing the service function >>>>> forwarders. It seems to me that in terms of OAM of service function >>>>> paths, the service function forwarders are the critical element to be >>>>> able to verify. >>>> >>>> >>>> [RP] The SFF info is present in the trace reply message. Maybe we need >>>> to >>>> put more info? >>> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >>> SI of the SIL, the SFF will generate a response. The current >>> understanding is that SF rather than SFF will decrement TTL. If so, if >>> the SI hits the limit, the SF will generate the response, and the >>>packet >>> won't get to the next SFF. So I can't see when this case would ever >>>get >>> triggered. >>> Also, it is rather unclear how the receiver would know that a response >>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>> >>>> >>>>> >>>>> Second, it assumes that there is value in having a special aspect of >>>>> the >>>>> service functions report service function type and identity. Given >>>>> that >>>>> this will be specialized code, it does not tell us much about the >>>>> actual >>>>> operation of the service functions. >>>> >>>> >>>> [RP] I think it is basic info. An admin will know that the SF that the >>>> packet is traversing is of proper type and actual instance. Given >>>> protocol >>>> is extensible one has extend to include many other SF specific >>>>metrics. >>>> >>> [JMH}I was apparently unclear. I am not asking for more information. >>>I >>> am not sure that this is useful information to extract. The actual >>> configuration of this information is not related to the work the >>>service >>> function does, so there is no reason for it to be correct. And trying >>> to monitor service function operability this way seems unfortunate. >>> >>> Yours, >>> Joel >> >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 11 14:34:11 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C601B3B8A for ; Thu, 11 Feb 2016 14:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDeBL2NhaTYW for ; Thu, 11 Feb 2016 14:34:05 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038621B3B88 for ; Thu, 11 Feb 2016 14:34:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DAB6B1C0C4F; Thu, 11 Feb 2016 14:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455230044; bh=o2BsWrfW7EHQx+8CcfadIVUlkpeqLY0yDJX5toQAmew=; h=Subject:To:References:From:Date:In-Reply-To:From; b=I3rbfyWSQVmYplWdY4ZNE+N4BDlw/nCw1+zERXChD5OV7anF9Fonpvi7UFqGJvTCw /6KUnVJpAndizr2ueqioq8z9TrcdT7kXzwReuO3TxXljrxiOAGRHcBEJt2EHSzhkXc b13voQhkapTnWXXZqF78nwkim/CZ5A6rLAMmSA4g= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 224791C0178; Thu, 11 Feb 2016 14:34:04 -0800 (PST) To: Dave Dolson , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56BD0C26.5090702@joelhalpern.com> Date: Thu, 11 Feb 2016 17:33:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:34:10 -0000 Thinking about the return message, given that there are not always symmetric NSH paths, I don't think one can use NSH to carry the reply back. Given that we can assume IP, why not remove the NSH header from the reply. Instead, put a destination port number in the reply, and use UDP to send the reply back to the requester, no matter what the NSH transport is. This has the advantage of removing any dependence of the forwared trace-route on the some other reverse path functioning. And it allows the probing entity to use a collector which is not collocated with the egress of some service path. Yours, Joel On 2/11/16 5:16 PM, Dave Dolson wrote: > Oh I see, you do say "The SFF will use the same encapsulation as the received packet." > I guess then the packets would traverse SFC somehow to get back? > > Actually, I think it is useful to use UDP for the trace report regardless > of the encapsulation type. > In other words, the OAM packet traverses the data plane until an > SFF acts on it, and then the report is sent over the control plane. > > I think this is what you have, effectively, which is why you like the UDP. > > How do you feel about that, sending the trace report over UDP regardless of the > NSH encapsulation? > > > -Dave > > > -----Original Message----- > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > Sent: Thursday, February 11, 2016 5:08 PM > To: Dave Dolson; Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > > The current implementation uses UDP because of NAT traversal. This is > something I did because at some point my SFC trace client was behind a NAT > and I wanted to get my responses back. How useful this is? Can¹t say, it > was to me. > > The draft says (I hope) that the transport used should be the same as the > one in NSH the trace request. But I¹m open to suggestions (or more > importantly actual text) since Joel also had a questions about it. > > > > On 2/11/16, 1:59 PM, "Dave Dolson" wrote: > >> Reinaldo, >> I also have the question about the trace report. It is to be sent to >> an IP/port, but the transport is not mentioned (that I could see). >> Is it intended to be UDP? >> >> -Dave >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 11, 2016 3:51 PM >> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >> >> Ahh. I had missed how you were interacting between the SF and the SFF. >> Sorry. >> >> Please confirm: the idea is that the SF at the end will add its >> information, and then the SFF fronting it will send the resulting >> traceroute response? >> >> It looks like the response is an NSH packet. In which case it goes in >> the NSH transport. If that transport is MPLS, for example, how will the >> receiver know who sent the response? >> >> Yours, >> Joel >> >> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>> The response is always from SFF because that is the entity that drops >>> the >>> packet. That is precisely the situation this tool is supposed to detect. >>> IF the SI (even for regular data packets) is not large enough the packet >>> will dropped by the SFF, not SF. A packet that is decremented to SI=0 >>> (was >>> 1 on ingress to SF) was processed by SF and should still be sent packet >>> to >>> SFF, which will then drop it. >>> >>> >>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>> >>>> >>>> >>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>> Hello Joel, >>>>> >>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>> wrote: >>>>> >>>>>> I am reluctant to adopt this document as it stands. >>>>>> I have two related concerns, both related to the basic approach. >>>>>> >>>>>> First, the proposal has no mechanism for tracing the service function >>>>>> forwarders. It seems to me that in terms of OAM of service function >>>>>> paths, the service function forwarders are the critical element to be >>>>>> able to verify. >>>>> >>>>> >>>>> [RP] The SFF info is present in the trace reply message. Maybe we need >>>>> to >>>>> put more info? >>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >>>> SI of the SIL, the SFF will generate a response. The current >>>> understanding is that SF rather than SFF will decrement TTL. If so, if >>>> the SI hits the limit, the SF will generate the response, and the >>>> packet >>>> won't get to the next SFF. So I can't see when this case would ever >>>> get >>>> triggered. >>>> Also, it is rather unclear how the receiver would know that a response >>>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>>> >>>>> >>>>>> >>>>>> Second, it assumes that there is value in having a special aspect of >>>>>> the >>>>>> service functions report service function type and identity. Given >>>>>> that >>>>>> this will be specialized code, it does not tell us much about the >>>>>> actual >>>>>> operation of the service functions. >>>>> >>>>> >>>>> [RP] I think it is basic info. An admin will know that the SF that the >>>>> packet is traversing is of proper type and actual instance. Given >>>>> protocol >>>>> is extensible one has extend to include many other SF specific >>>>> metrics. >>>>> >>>> [JMH}I was apparently unclear. I am not asking for more information. >>>> I >>>> am not sure that this is useful information to extract. The actual >>>> configuration of this information is not related to the work the >>>> service >>>> function does, so there is no reason for it to be correct. And trying >>>> to monitor service function operability this way seems unfortunate. >>>> >>>> Yours, >>>> Joel >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 11 14:35:15 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618051B3B96 for ; Thu, 11 Feb 2016 14:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEecnLSaAvlq for ; Thu, 11 Feb 2016 14:35:04 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EF61B3B9F for ; Thu, 11 Feb 2016 14:35:03 -0800 (PST) X-AuditID: c618062d-f79dd6d000003091-43-56bd09076490 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 19.15.12433.7090DB65; Thu, 11 Feb 2016 23:19:51 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Thu, 11 Feb 2016 17:35:01 -0500 From: Gregory Mirsky To: Dave Dolson , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8nltCAgAACOQCAAAZEAIAABVQAgAABIQD//7QmIIAAYUUA//+slwCAAAVQUA== Date: Thu, 11 Feb 2016 22:35:01 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF112219C5D08@eusaamb103.ericsson.se> References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonSpedc2+YQddaC4utyx6yWyydp27x 8dQbJouHb96zWDx5sJXdgdVjyu+NrB5Llvxk8jg35Tujx9fN21kDWKK4bFJSczLLUov07RK4 MlYfPMhSsM+g4mhTG3sDY5N6FyMHh4SAicSMTTFdjJxAppjEhXvr2boYuTiEBI4wSuxp+M8O khASWM4osaQrCcRmEzCSeLGxhx2kSETgEqNES9dFFpCEsICzRNPkx6wgtoiAi8Sx7mtMEHaW xKuVp8DiLAKqEmc/XGAEsXkFfCXeHnzBDLFtKrNE86bPzCAJToEAiRUf37CB2IxAJ30/tQZs ELOAuMStJ/OZIE4VkFiy5zwzhC0q8fLxP1YIW1FiX/90doh6PYkbU6ewQdjaEssWvmaGWCwo cXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLYxAiMn2MSbLo7GO9P9zzEKMDB qMTDa3BrT5gQa2JZcWXuIUYJDmYlEV4Jrr1hQrwpiZVVqUX58UWlOanFhxilOViUxHmXOqwP ExJITyxJzU5NLUgtgskycXBKNTBGJh2IFJ2Zc9dw/QwvnfRDyQIqGx4d5NjG3H33Y9A3vkiL 7t7AKQt6NikmPuuYc/VDSuiETdx7wk8xpK/RM3av1tUzlRY5slxrrdAjPXYb17gHM1KO/33r ui4p5/atJ/HGi7ibpxV8UfobsqvrQGGDo4VluXrhyenSUr5Rp48pxSxIqIkKqFZiKc5INNRi LipOBADzwqOVmwIAAA== Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:35:06 -0000 Hi Dave, I agree that sending Echo reply over IP/UDP is most practical. I don't thin= k that we can expect SFP to be bi-directional and thus to guarantee return = path based on NSH of Echo request packet. But here's the question, how resp= onder selects destination IP address and whether destination UDP port is dy= namic or assigned by IANA. Regards, Greg -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, February 11, 2016 2:17 PM To: Reinaldo Penno (repenno); Joel M. Halpern; Jim Guichard (jguichar); sfc= @ietf.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Oh I see, you do say "The SFF will use the same encapsulation as the receiv= ed packet." I guess then the packets would traverse SFC somehow to get back? Actually, I think it is useful to use UDP for the trace report regardless o= f the encapsulation type. In other words, the OAM packet traverses the data plane until an SFF acts o= n it, and then the report is sent over the control plane. I think this is what you have, effectively, which is why you like the UDP. How do you feel about that, sending the trace report over UDP regardless of= the NSH encapsulation? -Dave -----Original Message----- From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] Sent: Thursday, February 11, 2016 5:08 PM To: Dave Dolson; Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 The current implementation uses UDP because of NAT traversal. This is somet= hing I did because at some point my SFC trace client was behind a NAT and I= wanted to get my responses back. How useful this is? Can=B9t say, it was t= o me.=20 The draft says (I hope) that the transport used should be the same as the o= ne in NSH the trace request. But I=B9m open to suggestions (or more import= antly actual text) since Joel also had a questions about it. On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >Reinaldo, >I also have the question about the trace report. It is to be sent to an=20 >IP/port, but the transport is not mentioned (that I could see). >Is it intended to be UDP? > >-Dave > > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Thursday, February 11, 2016 3:51 PM >To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > >Ahh. I had missed how you were interacting between the SF and the SFF. > Sorry. > >Please confirm: the idea is that the SF at the end will add its=20 >information, and then the SFF fronting it will send the resulting=20 >traceroute response? > >It looks like the response is an NSH packet. In which case it goes in=20 >the NSH transport. If that transport is MPLS, for example, how will=20 >the receiver know who sent the response? > >Yours, >Joel > >On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >> The response is always from SFF because that is the entity that drops=20 >>the packet. That is precisely the situation this tool is supposed to=20 >>detect. >> IF the SI (even for regular data packets) is not large enough the=20 >>packet will dropped by the SFF, not SF. A packet that is decremented=20 >>to SI=3D0 (was >> 1 on ingress to SF) was processed by SF and should still be sent=20 >>packet to SFF, which will then drop it. >> >> >> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >> >>> >>> >>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>> Hello Joel, >>>> >>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>> wrote: >>>> >>>>> I am reluctant to adopt this document as it stands. >>>>> I have two related concerns, both related to the basic approach. >>>>> >>>>> First, the proposal has no mechanism for tracing the service=20 >>>>> function forwarders. It seems to me that in terms of OAM of=20 >>>>> service function paths, the service function forwarders are the=20 >>>>> critical element to be able to verify. >>>> >>>> >>>> [RP] The SFF info is present in the trace reply message. Maybe we=20 >>>> need to put more info? >>> [JMH] What I see is that if a traceroute somehow gets to an SFF with=20 >>>an SI of the SIL, the SFF will generate a response. The current =20 >>>understanding is that SF rather than SFF will decrement TTL. If so,=20 >>>if the SI hits the limit, the SF will generate the response, and the=20 >>>packet won't get to the next SFF. So I can't see when this case=20 >>>would ever get triggered. >>> Also, it is rather unclear how the receiver would know that a=20 >>>response was from the SFF rather than an SF. Is there a magic SF Type = for SFF? >>> >>>> >>>>> >>>>> Second, it assumes that there is value in having a special aspect=20 >>>>> of the service functions report service function type and=20 >>>>> identity. Given that this will be specialized code, it does not=20 >>>>> tell us much about the actual operation of the service functions. >>>> >>>> >>>> [RP] I think it is basic info. An admin will know that the SF that=20 >>>>the packet is traversing is of proper type and actual instance.=20 >>>>Given protocol is extensible one has extend to include many other=20 >>>>SF specific metrics. >>>> >>> [JMH}I was apparently unclear. I am not asking for more information. >>>I >>> am not sure that this is useful information to extract. The actual =20 >>>configuration of this information is not related to the work the=20 >>>service function does, so there is no reason for it to be correct. =20 >>>And trying to monitor service function operability this way seems=20 >>>unfortunate. >>> >>> Yours, >>> Joel >> >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 11 14:39:03 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1B51B3B82 for ; Thu, 11 Feb 2016 14:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKG5vEMl63Wk for ; Thu, 11 Feb 2016 14:38:49 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DC51B305D for ; Thu, 11 Feb 2016 14:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9278; q=dns/txt; s=iport; t=1455230329; x=1456439929; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YX8CaDxqtfTgljWzMghv6tR3K5vFjc6vZuQsyN5Ajzw=; b=EYAduSYZyZWaidMfjuz4tpqjWLIe5AfLAFXSDAV7/778VemFB0Pdm/IO CXiXK/Gz6AGurSEXRrntl4nKXkr58xWKFBiwvIdWLH8vLmqTn+/xWyrUN QFJvFzLyhIeOxbU+ONUYvrBFT5ggvkeLkwMihBpk9BTgjo27zw+gBakDJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBYDL1W/4sNJK1VCYM6Um0GiFWxK?= =?us-ascii?q?wENgWcXCoVsAhyBGTgUAQEBAQEBAYEKhEEBAQEEAQEBGhc6FwQCAQgRBAEBAQQ?= =?us-ascii?q?jBQICJQsUCQgCBAESiBoOlSudCwaPBwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEd?= =?us-ascii?q?YUdhDaECQQjgnyBQAWWdwGNUoFdhEOIVY49AR4BAUKCAhmBSmqHGzx8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="236906124" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Feb 2016 22:38:48 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1BMcmmV001611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 22:38:48 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 16:38:47 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 16:38:47 -0600 From: "Reinaldo Penno (repenno)" To: Gregory Mirsky , Dave Dolson , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaAgACHPgCAABMhAP//fC2AABEST4AAAKIggP//eu8A Date: Thu, 11 Feb 2016 22:38:47 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> <7347100B5761DC41A166AC17F22DF112219C5D08@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF112219C5D08@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.204] Content-Type: text/plain; charset="euc-kr" Content-ID: <1A36F450AC43214DB4BFF5B52A93E8B6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:38:55 -0000 VGhlIGN1cnJlbnQgZHJhZnQgYWxsb3dzIGZvciB0aGUgY2xpZW50IHRvIHNwZWNpZnkgdGhlIHJl dHVybiBJUDpwb3J0IHNvDQp0aGF0IGRpcmVjdCByZXBvcnQgbWVzc2FnZXMgYXJlIHNlbnQuIFRo ZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIG1ha2VzDQpmdWxsIHVzZSBvZiB0aGlzLiAgSSB3b3Vs ZCBnZXQgdGhlIGV4dGVybmFsIE5BVCBJUDpwb3J0IGFuZCBwdXQgaW50IGhpcw0KZmllbGQuIFJl cGxpZXMgd291bGQgZ2V0IHRvIG1lIGFjcm9zcyBOQVQsIHZlcnkgaGFuZHksIGF0IGxlYXN0IHRv IG1lLg0KDQoiRGVzdCBQb3J0OiAgVGhlIHRyYWNlIHJlcG9ydCBtdXN0IGJlIHNlbnQgdG8gdGhp cyBkZXN0aW5hdGlvbiBQb3J0DQoNCiAgIERlc3QgSVA6ICB0aGUgdHJhY2UgcmVwb3J0IG11c3Qg YmUgc2VudCB0byB0aGlzIGRlc3RpbmF0aW9uIElQDQogICAgICBBZGRyZXNzobENCg0KDQoNCg0K DQpPbiAyLzExLzE2LCAyOjM1IFBNLCAiR3JlZ29yeSBNaXJza3kiIDxncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+SGkgRGF2ZSwNCj5JIGFncmVlIHRoYXQgc2VuZGluZyBF Y2hvIHJlcGx5IG92ZXIgSVAvVURQIGlzIG1vc3QgcHJhY3RpY2FsLiBJIGRvbid0DQo+dGhpbmsg dGhhdCB3ZSBjYW4gZXhwZWN0IFNGUCB0byBiZSBiaS1kaXJlY3Rpb25hbCBhbmQgdGh1cyB0byBn dWFyYW50ZWUNCj5yZXR1cm4gcGF0aCBiYXNlZCBvbiBOU0ggb2YgRWNobyByZXF1ZXN0IHBhY2tl dC4gQnV0IGhlcmUncyB0aGUgcXVlc3Rpb24sDQo+aG93IHJlc3BvbmRlciBzZWxlY3RzIGRlc3Rp bmF0aW9uIElQIGFkZHJlc3MgYW5kIHdoZXRoZXIgZGVzdGluYXRpb24gVURQDQo+cG9ydCBpcyBk eW5hbWljIG9yIGFzc2lnbmVkIGJ5IElBTkEuDQo+DQo+CVJlZ2FyZHMsDQo+CQlHcmVnDQo+DQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgRG9sc29uDQo+U2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDExLCAyMDE2IDI6MTcgUE0NCj5UbzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBK b2VsIE0uIEhhbHBlcm47IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOw0KPnNmY0BpZXRmLm9yZw0K PlN1YmplY3Q6IFJlOiBbc2ZjXSBDYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1z ZmMtdHJhY2UtMDMNCj4NCj5PaCBJIHNlZSwgeW91IGRvIHNheSAiVGhlIFNGRiB3aWxsIHVzZSB0 aGUgc2FtZSBlbmNhcHN1bGF0aW9uIGFzIHRoZQ0KPnJlY2VpdmVkIHBhY2tldC4iDQo+SSBndWVz cyB0aGVuIHRoZSBwYWNrZXRzIHdvdWxkIHRyYXZlcnNlIFNGQyBzb21laG93IHRvIGdldCBiYWNr Pw0KPg0KPkFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzIHVzZWZ1bCB0byB1c2UgVURQIGZvciB0aGUg dHJhY2UgcmVwb3J0IHJlZ2FyZGxlc3MNCj5vZiB0aGUgZW5jYXBzdWxhdGlvbiB0eXBlLg0KPklu IG90aGVyIHdvcmRzLCB0aGUgT0FNIHBhY2tldCB0cmF2ZXJzZXMgdGhlIGRhdGEgcGxhbmUgdW50 aWwgYW4gU0ZGIGFjdHMNCj5vbiBpdCwgYW5kIHRoZW4gdGhlIHJlcG9ydCBpcyBzZW50IG92ZXIg dGhlIGNvbnRyb2wgcGxhbmUuDQo+DQo+SSB0aGluayB0aGlzIGlzIHdoYXQgeW91IGhhdmUsIGVm ZmVjdGl2ZWx5LCB3aGljaCBpcyB3aHkgeW91IGxpa2UgdGhlIFVEUC4NCj4NCj5Ib3cgZG8geW91 IGZlZWwgYWJvdXQgdGhhdCwgc2VuZGluZyB0aGUgdHJhY2UgcmVwb3J0IG92ZXIgVURQIHJlZ2Fy ZGxlc3MNCj5vZiB0aGUgTlNIIGVuY2Fwc3VsYXRpb24/DQo+DQo+DQo+LURhdmUNCj4NCj4NCj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5v KSBbbWFpbHRvOnJlcGVubm9AY2lzY28uY29tXQ0KPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAx MSwgMjAxNiA1OjA4IFBNDQo+VG86IERhdmUgRG9sc29uOyBKb2VsIE0uIEhhbHBlcm47IEppbSBH dWljaGFyZCAoamd1aWNoYXIpOyBzZmNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW3NmY10gQ2Fs bCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLXRyYWNlLTAzDQo+DQo+VGhlIGN1 cnJlbnQgaW1wbGVtZW50YXRpb24gdXNlcyBVRFAgYmVjYXVzZSBvZiBOQVQgdHJhdmVyc2FsLiBU aGlzIGlzDQo+c29tZXRoaW5nIEkgZGlkIGJlY2F1c2UgYXQgc29tZSBwb2ludCBteSBTRkMgdHJh Y2UgY2xpZW50IHdhcyBiZWhpbmQgYQ0KPk5BVCBhbmQgSSB3YW50ZWQgdG8gZ2V0IG15IHJlc3Bv bnNlcyBiYWNrLiBIb3cgdXNlZnVsIHRoaXMgaXM/IENhbqn2dCBzYXksDQo+aXQgd2FzIHRvIG1l LiANCj4NCj5UaGUgZHJhZnQgc2F5cyAoSSBob3BlKSB0aGF0IHRoZSB0cmFuc3BvcnQgdXNlZCBz aG91bGQgYmUgdGhlIHNhbWUgYXMgdGhlDQo+b25lIGluIE5TSCB0aGUgdHJhY2UgcmVxdWVzdC4g IEJ1dCBJqfZtIG9wZW4gdG8gc3VnZ2VzdGlvbnMgKG9yIG1vcmUNCj5pbXBvcnRhbnRseSBhY3R1 YWwgdGV4dCkgc2luY2UgSm9lbCBhbHNvIGhhZCBhIHF1ZXN0aW9ucyBhYm91dCBpdC4NCj4NCj4N Cj4NCj5PbiAyLzExLzE2LCAxOjU5IFBNLCAiRGF2ZSBEb2xzb24iIDxkZG9sc29uQHNhbmR2aW5l LmNvbT4gd3JvdGU6DQo+DQo+PlJlaW5hbGRvLA0KPj5JIGFsc28gaGF2ZSB0aGUgcXVlc3Rpb24g YWJvdXQgdGhlIHRyYWNlIHJlcG9ydC4gSXQgaXMgdG8gYmUgc2VudCB0byBhbg0KPj5JUC9wb3J0 LCBidXQgdGhlIHRyYW5zcG9ydCBpcyBub3QgbWVudGlvbmVkICh0aGF0IEkgY291bGQgc2VlKS4N Cj4+SXMgaXQgaW50ZW5kZWQgdG8gYmUgVURQPw0KPj4NCj4+LURhdmUNCj4+DQo+Pg0KPj4NCj4+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NCj4+U2VudDogVGh1cnNk YXksIEZlYnJ1YXJ5IDExLCAyMDE2IDM6NTEgUE0NCj4+VG86IFJlaW5hbGRvIFBlbm5vIChyZXBl bm5vKTsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IHNmY0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBS ZTogW3NmY10gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtcGVubm8tc2ZjLXRyYWNlLTAz DQo+Pg0KPj5BaGguICBJIGhhZCBtaXNzZWQgaG93IHlvdSB3ZXJlIGludGVyYWN0aW5nIGJldHdl ZW4gdGhlIFNGIGFuZCB0aGUgU0ZGLg0KPj4gIFNvcnJ5Lg0KPj4NCj4+UGxlYXNlIGNvbmZpcm06 ICB0aGUgaWRlYSBpcyB0aGF0IHRoZSBTRiBhdCB0aGUgZW5kIHdpbGwgYWRkIGl0cw0KPj5pbmZv cm1hdGlvbiwgYW5kIHRoZW4gdGhlIFNGRiBmcm9udGluZyBpdCB3aWxsIHNlbmQgdGhlIHJlc3Vs dGluZw0KPj50cmFjZXJvdXRlIHJlc3BvbnNlPw0KPj4NCj4+SXQgbG9va3MgbGlrZSB0aGUgcmVz cG9uc2UgaXMgYW4gTlNIIHBhY2tldC4gIEluIHdoaWNoIGNhc2UgaXQgZ29lcyBpbg0KPj50aGUg TlNIIHRyYW5zcG9ydC4gIElmIHRoYXQgdHJhbnNwb3J0IGlzIE1QTFMsIGZvciBleGFtcGxlLCBo b3cgd2lsbA0KPj50aGUgcmVjZWl2ZXIga25vdyB3aG8gc2VudCB0aGUgcmVzcG9uc2U/DQo+Pg0K Pj5Zb3VycywNCj4+Sm9lbA0KPj4NCj4+T24gMi8xMS8xNiAzOjQ3IFBNLCBSZWluYWxkbyBQZW5u byAocmVwZW5ubykgd3JvdGU6DQo+Pj4gVGhlIHJlc3BvbnNlIGlzIGFsd2F5cyBmcm9tIFNGRiBi ZWNhdXNlIHRoYXQgaXMgdGhlIGVudGl0eSB0aGF0IGRyb3BzDQo+Pj50aGUgIHBhY2tldC4gVGhh dCBpcyBwcmVjaXNlbHkgdGhlIHNpdHVhdGlvbiB0aGlzIHRvb2wgaXMgc3VwcG9zZWQgdG8NCj4+ PmRldGVjdC4NCj4+PiBJRiB0aGUgU0kgKGV2ZW4gZm9yIHJlZ3VsYXIgZGF0YSBwYWNrZXRzKSBp cyBub3QgbGFyZ2UgZW5vdWdoIHRoZQ0KPj4+cGFja2V0ICB3aWxsIGRyb3BwZWQgYnkgdGhlIFNG Riwgbm90IFNGLiBBIHBhY2tldCB0aGF0IGlzIGRlY3JlbWVudGVkDQo+Pj50byBTST0wICh3YXMN Cj4+PiAxIG9uIGluZ3Jlc3MgdG8gU0YpIHdhcyBwcm9jZXNzZWQgYnkgU0YgYW5kIHNob3VsZCBz dGlsbCBiZSBzZW50DQo+Pj5wYWNrZXQgdG8gIFNGRiwgd2hpY2ggd2lsbCB0aGVuIGRyb3AgaXQu DQo+Pj4NCj4+Pg0KPj4+IE9uIDIvMTEvMTYsIDEyOjI4IFBNLCAiSm9lbCBNLiBIYWxwZXJuIiA8 am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMi8x MS8xNiAzOjA1IFBNLCBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykgd3JvdGU6DQo+Pj4+PiBIZWxs byBKb2VsLA0KPj4+Pj4NCj4+Pj4+IE9uIDIvMTEvMTYsIDExOjU3IEFNLCAic2ZjIG9uIGJlaGFs ZiBvZiBKb2VsIE0uIEhhbHBlcm4iDQo+Pj4+PiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBJIGFtIHJl bHVjdGFudCB0byBhZG9wdCB0aGlzIGRvY3VtZW50IGFzIGl0IHN0YW5kcy4NCj4+Pj4+PiBJIGhh dmUgdHdvIHJlbGF0ZWQgY29uY2VybnMsIGJvdGggcmVsYXRlZCB0byB0aGUgYmFzaWMgYXBwcm9h Y2guDQo+Pj4+Pj4NCj4+Pj4+PiBGaXJzdCwgdGhlIHByb3Bvc2FsIGhhcyBubyBtZWNoYW5pc20g Zm9yIHRyYWNpbmcgdGhlIHNlcnZpY2UNCj4+Pj4+PiBmdW5jdGlvbiBmb3J3YXJkZXJzLiAgSXQg c2VlbXMgdG8gbWUgdGhhdCBpbiB0ZXJtcyBvZiBPQU0gb2YNCj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0 aW9uIHBhdGhzLCB0aGUgc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXJzIGFyZSB0aGUNCj4+Pj4+ PiBjcml0aWNhbCBlbGVtZW50IHRvIGJlIGFibGUgdG8gdmVyaWZ5Lg0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+PiBbUlBdIFRoZSBTRkYgaW5mbyBpcyBwcmVzZW50IGluIHRoZSB0cmFjZSByZXBseSBtZXNz YWdlLiBNYXliZSB3ZQ0KPj4+Pj4gbmVlZCB0byBwdXQgbW9yZSBpbmZvPw0KPj4+PiBbSk1IXSBX aGF0IEkgc2VlIGlzIHRoYXQgaWYgYSB0cmFjZXJvdXRlIHNvbWVob3cgZ2V0cyB0byBhbiBTRkYg d2l0aA0KPj4+PmFuICBTSSBvZiB0aGUgU0lMLCB0aGUgU0ZGIHdpbGwgZ2VuZXJhdGUgYSByZXNw b25zZS4gIFRoZSBjdXJyZW50DQo+Pj4+dW5kZXJzdGFuZGluZyBpcyB0aGF0IFNGIHJhdGhlciB0 aGFuIFNGRiB3aWxsIGRlY3JlbWVudCBUVEwuICBJZiBzbywNCj4+Pj5pZiAgdGhlIFNJIGhpdHMg dGhlIGxpbWl0LCB0aGUgU0Ygd2lsbCBnZW5lcmF0ZSB0aGUgcmVzcG9uc2UsIGFuZCB0aGUNCj4+ Pj5wYWNrZXQgIHdvbid0IGdldCB0byB0aGUgbmV4dCBTRkYuICBTbyBJIGNhbid0IHNlZSB3aGVu IHRoaXMgY2FzZQ0KPj4+PndvdWxkIGV2ZXIgZ2V0ICB0cmlnZ2VyZWQuDQo+Pj4+IEFsc28sIGl0 IGlzIHJhdGhlciB1bmNsZWFyIGhvdyB0aGUgcmVjZWl2ZXIgd291bGQga25vdyB0aGF0IGENCj4+ Pj5yZXNwb25zZSAgd2FzIGZyb20gdGhlIFNGRiByYXRoZXIgdGhhbiBhbiBTRi4gIElzIHRoZXJl IGEgbWFnaWMgU0YNCj4+Pj5UeXBlIGZvciBTRkY/DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pj4gU2Vjb25kLCBpdCBhc3N1bWVzIHRoYXQgdGhlcmUgaXMgdmFsdWUgaW4gaGF2aW5nIGEgc3Bl Y2lhbCBhc3BlY3QNCj4+Pj4+PiBvZiB0aGUgc2VydmljZSBmdW5jdGlvbnMgcmVwb3J0IHNlcnZp Y2UgZnVuY3Rpb24gdHlwZSBhbmQNCj4+Pj4+PiBpZGVudGl0eS4gIEdpdmVuIHRoYXQgdGhpcyB3 aWxsIGJlIHNwZWNpYWxpemVkIGNvZGUsIGl0IGRvZXMgbm90DQo+Pj4+Pj4gdGVsbCB1cyBtdWNo IGFib3V0IHRoZSBhY3R1YWwgb3BlcmF0aW9uIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gW1JQXSBJIHRoaW5rIGl0IGlzIGJhc2ljIGluZm8uIEFuIGFkbWlu IHdpbGwga25vdyB0aGF0IHRoZSBTRiB0aGF0DQo+Pj4+PnRoZSAgcGFja2V0IGlzIHRyYXZlcnNp bmcgaXMgb2YgcHJvcGVyIHR5cGUgYW5kIGFjdHVhbCBpbnN0YW5jZS4NCj4+Pj4+R2l2ZW4gIHBy b3RvY29sICBpcyBleHRlbnNpYmxlIG9uZSBoYXMgZXh0ZW5kIHRvIGluY2x1ZGUgbWFueSBvdGhl cg0KPj4+Pj5TRiBzcGVjaWZpYyBtZXRyaWNzLg0KPj4+Pj4NCj4+Pj4gW0pNSH1JIHdhcyBhcHBh cmVudGx5IHVuY2xlYXIuICBJIGFtIG5vdCBhc2tpbmcgZm9yIG1vcmUgaW5mb3JtYXRpb24uDQo+ Pj4+SQ0KPj4+PiBhbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgdXNlZnVsIGluZm9ybWF0aW9uIHRv IGV4dHJhY3QuICBUaGUgYWN0dWFsDQo+Pj4+Y29uZmlndXJhdGlvbiBvZiB0aGlzIGluZm9ybWF0 aW9uIGlzIG5vdCByZWxhdGVkIHRvIHRoZSB3b3JrIHRoZQ0KPj4+PnNlcnZpY2UgIGZ1bmN0aW9u IGRvZXMsIHNvIHRoZXJlIGlzIG5vIHJlYXNvbiBmb3IgaXQgdG8gYmUgY29ycmVjdC4NCj4+Pj5B bmQgdHJ5aW5nICB0byBtb25pdG9yIHNlcnZpY2UgZnVuY3Rpb24gb3BlcmFiaWxpdHkgdGhpcyB3 YXkgc2VlbXMNCj4+Pj51bmZvcnR1bmF0ZS4NCj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwN Cj4+Pg0KPj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Thu Feb 11 14:45:32 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147C1B3BC1 for ; Thu, 11 Feb 2016 14:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vrfpoe06dXL for ; Thu, 11 Feb 2016 14:45:21 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DE81B3B8B for ; Thu, 11 Feb 2016 14:45:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1DDAC1C0558; Thu, 11 Feb 2016 14:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455230721; bh=AeK4BLJFDL8nOib1TG+TwBQXKqROneKXRlBT4GkA+7Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=f/bXEzHDmujMTGpyuV+GQZKSK9uKFExHow269VYGgaG7I8ld1eZ4FmGOQwsu30Buu JWwh4pM/cjnnYEKSPmVFOm7lzUK5flFok75TTyC9Zs9WPVCxEALczUERnIkwaOpFKb Z7Hb5MVmCaGNY9EvhzVHry4aB30icIIhvSgfkSM0= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 80ECD8C005B; Thu, 11 Feb 2016 14:45:20 -0800 (PST) To: "Reinaldo Penno (repenno)" , Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56BD0ECB.3060206@joelhalpern.com> Date: Thu, 11 Feb 2016 17:44:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:45:23 -0000 I think the problem is that the draft does not say UDP anywhere. Since reverse NSH does not actually work, the draft does not currently tell you how to send the response. As long as we are discussing details, some notes that do not block adoption: I think the packet format needs a corellation ID so that responses can be matched to requests. Also, I do not like trying to infer whether IPv4 or IPv6 should be used from the contents of the address field. I don't care if it is padded, but I would like to see explicit v4 / v6 indication. Yours, Joel On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: > The current implementation uses UDP because of NAT traversal. This is > something I did because at some point my SFC trace client was behind a NAT > and I wanted to get my responses back. How useful this is? Can¹t say, it > was to me. > > The draft says (I hope) that the transport used should be the same as the > one in NSH the trace request. But I¹m open to suggestions (or more > importantly actual text) since Joel also had a questions about it. > > > > On 2/11/16, 1:59 PM, "Dave Dolson" wrote: > >> Reinaldo, >> I also have the question about the trace report. It is to be sent to >> an IP/port, but the transport is not mentioned (that I could see). >> Is it intended to be UDP? >> >> -Dave >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 11, 2016 3:51 PM >> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >> >> Ahh. I had missed how you were interacting between the SF and the SFF. >> Sorry. >> >> Please confirm: the idea is that the SF at the end will add its >> information, and then the SFF fronting it will send the resulting >> traceroute response? >> >> It looks like the response is an NSH packet. In which case it goes in >> the NSH transport. If that transport is MPLS, for example, how will the >> receiver know who sent the response? >> >> Yours, >> Joel >> >> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>> The response is always from SFF because that is the entity that drops >>> the >>> packet. That is precisely the situation this tool is supposed to detect. >>> IF the SI (even for regular data packets) is not large enough the packet >>> will dropped by the SFF, not SF. A packet that is decremented to SI=0 >>> (was >>> 1 on ingress to SF) was processed by SF and should still be sent packet >>> to >>> SFF, which will then drop it. >>> >>> >>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>> >>>> >>>> >>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>> Hello Joel, >>>>> >>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>> wrote: >>>>> >>>>>> I am reluctant to adopt this document as it stands. >>>>>> I have two related concerns, both related to the basic approach. >>>>>> >>>>>> First, the proposal has no mechanism for tracing the service function >>>>>> forwarders. It seems to me that in terms of OAM of service function >>>>>> paths, the service function forwarders are the critical element to be >>>>>> able to verify. >>>>> >>>>> >>>>> [RP] The SFF info is present in the trace reply message. Maybe we need >>>>> to >>>>> put more info? >>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >>>> SI of the SIL, the SFF will generate a response. The current >>>> understanding is that SF rather than SFF will decrement TTL. If so, if >>>> the SI hits the limit, the SF will generate the response, and the >>>> packet >>>> won't get to the next SFF. So I can't see when this case would ever >>>> get >>>> triggered. >>>> Also, it is rather unclear how the receiver would know that a response >>>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>>> >>>>> >>>>>> >>>>>> Second, it assumes that there is value in having a special aspect of >>>>>> the >>>>>> service functions report service function type and identity. Given >>>>>> that >>>>>> this will be specialized code, it does not tell us much about the >>>>>> actual >>>>>> operation of the service functions. >>>>> >>>>> >>>>> [RP] I think it is basic info. An admin will know that the SF that the >>>>> packet is traversing is of proper type and actual instance. Given >>>>> protocol >>>>> is extensible one has extend to include many other SF specific >>>>> metrics. >>>>> >>>> [JMH}I was apparently unclear. I am not asking for more information. >>>> I >>>> am not sure that this is useful information to extract. The actual >>>> configuration of this information is not related to the work the >>>> service >>>> function does, so there is no reason for it to be correct. And trying >>>> to monitor service function operability this way seems unfortunate. >>>> >>>> Yours, >>>> Joel >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Thu Feb 11 14:51:37 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8B81B3BBF for ; Thu, 11 Feb 2016 14:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84mfbZzYttpn for ; Thu, 11 Feb 2016 14:51:28 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F095D1B3B00 for ; Thu, 11 Feb 2016 14:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8174; q=dns/txt; s=iport; t=1455231087; x=1456440687; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KTOBQ1wbMMnpYR4H/WCLjuxh2cAKMVZ/Sgjbo0YE9wc=; b=PNUNENQAH47mPTZ789TBq2QBWksOnCdU2Z/oWmgQ84/FlwafzhBvBCea C9yq0f2vDBSHG/BTXdtsIGMQ2gmGZAkjs0x54rZ9vpeZ6yEFl5HmkA/1V 3NjowE+DWXFjnOy+8huBktDOpMTXZe0FsnJvUE540ToixtH/6X5yDN7RK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDqD71W/5tdJa1VCYM6Um0GiFWxL?= =?us-ascii?q?QENgWcXCoVsAhyBGjgUAQEBAQEBAYEKhEEBAQEEAQEBGhc6FwQCAQgRBAEBAQQ?= =?us-ascii?q?jBQICJQsUCQgCBAESiBoOlS2dCwaPBwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEd?= =?us-ascii?q?YUdhDaECQQjgnyBQAWWdwGNUoFdhEOIVY49AR4BAUKCAhmBSmqHGgEGGR18AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="235744934" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 22:51:26 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1BMpQxV026205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 22:51:26 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 16:51:26 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 16:51:25 -0600 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaAgACHPgCAABMhAP//fC2AABIIxoD//3vUAA== Date: Thu, 11 Feb 2016 22:51:25 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> <56BD0ECB.3060206@joelhalpern.com> In-Reply-To: <56BD0ECB.3060206@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.204] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:51:34 -0000 UmlnaHQsIHRoaXMgaXMgc29tZXRoaW5nIGhvcGVmdWxseSB3ZSBjYW4gZml4IGFmdGVyIGFkb3B0 aW9uLiBJIHdhc26hr3QNCnN1cmUgaXQgd291bGQgZ2V0IHdpZGUgc3VwcG9ydCBidXQgaXQgc2Vl bXMgZm9sa3MgYXJlIGhhcHB5IHdpdGggVURQLg0KDQpJbiB0aGUgY3VycmVudCBpbXBsZW1lbnRh dGlvbiByZXNwb25zZXMgYXJlIGFscmVhZHkgc2VudCBvdmVyIFVEUCBhcyBJDQptZW50aW9uZWQg aW4gb3RoZXIgcmVwbHkuIEJ1dCBOU0ggaGVhZGVyIGlzIHN0aWxsIHRoZXJlIChhbHRob3VnaCBu b3QgdXNlZA0KZm9yIGZvcndhcmRpbmcpIHNvIHRoYXQgbWV0YWRhdGEsIHNlcnZpY2UgcGF0aCwg aW5kZXggYW5kIG90aGVycyBjYW4gYmUNCmRpc3BsYXkvZGVidWdnZWQgYnkgY2xpZW50Lg0KDQpP biAyLzExLzE2LCAyOjQ0IFBNLCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNv bT4gd3JvdGU6DQoNCj5JIHRoaW5rIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGRyYWZ0IGRvZXMg bm90IHNheSBVRFAgYW55d2hlcmUuICBTaW5jZQ0KPnJldmVyc2UgTlNIIGRvZXMgbm90IGFjdHVh bGx5IHdvcmssIHRoZSBkcmFmdCBkb2VzIG5vdCBjdXJyZW50bHkgdGVsbA0KPnlvdSBob3cgdG8g c2VuZCB0aGUgcmVzcG9uc2UuDQo+DQo+QXMgbG9uZyBhcyB3ZSBhcmUgZGlzY3Vzc2luZyBkZXRh aWxzLCBzb21lIG5vdGVzIHRoYXQgZG8gbm90IGJsb2NrDQo+YWRvcHRpb246DQo+SSB0aGluayB0 aGUgcGFja2V0IGZvcm1hdCBuZWVkcyBhIGNvcmVsbGF0aW9uIElEIHNvIHRoYXQgcmVzcG9uc2Vz IGNhbg0KPmJlIG1hdGNoZWQgdG8gcmVxdWVzdHMuDQo+QWxzbywgSSBkbyBub3QgbGlrZSB0cnlp bmcgdG8gaW5mZXIgd2hldGhlciBJUHY0IG9yIElQdjYgc2hvdWxkIGJlIHVzZWQNCj5mcm9tIHRo ZSBjb250ZW50cyBvZiB0aGUgYWRkcmVzcyBmaWVsZC4gIEkgZG9uJ3QgY2FyZSBpZiBpdCBpcyBw YWRkZWQsDQo+YnV0IEkgd291bGQgbGlrZSB0byBzZWUgZXhwbGljaXQgdjQgLyB2NiBpbmRpY2F0 aW9uLg0KPg0KPllvdXJzLA0KPkpvZWwNCj4NCj5PbiAyLzExLzE2IDU6MDggUE0sIFJlaW5hbGRv IFBlbm5vIChyZXBlbm5vKSB3cm90ZToNCj4+IFRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uIHVz ZXMgVURQIGJlY2F1c2Ugb2YgTkFUIHRyYXZlcnNhbC4gVGhpcyBpcw0KPj4gc29tZXRoaW5nIEkg ZGlkIGJlY2F1c2UgYXQgc29tZSBwb2ludCBteSBTRkMgdHJhY2UgY2xpZW50IHdhcyBiZWhpbmQg YQ0KPj5OQVQNCj4+IGFuZCBJIHdhbnRlZCB0byBnZXQgbXkgcmVzcG9uc2VzIGJhY2suIEhvdyB1 c2VmdWwgdGhpcyBpcz8gQ2FuqfZ0IHNheSwgaXQNCj4+IHdhcyB0byBtZS4NCj4+DQo+PiBUaGUg ZHJhZnQgc2F5cyAoSSBob3BlKSB0aGF0IHRoZSB0cmFuc3BvcnQgdXNlZCBzaG91bGQgYmUgdGhl IHNhbWUgYXMNCj4+dGhlDQo+PiBvbmUgaW4gTlNIIHRoZSB0cmFjZSByZXF1ZXN0LiAgQnV0IEmp 9m0gb3BlbiB0byBzdWdnZXN0aW9ucyAob3IgbW9yZQ0KPj4gaW1wb3J0YW50bHkgYWN0dWFsIHRl eHQpIHNpbmNlIEpvZWwgYWxzbyBoYWQgYSBxdWVzdGlvbnMgYWJvdXQgaXQuDQo+Pg0KPj4NCj4+ DQo+PiBPbiAyLzExLzE2LCAxOjU5IFBNLCAiRGF2ZSBEb2xzb24iIDxkZG9sc29uQHNhbmR2aW5l LmNvbT4gd3JvdGU6DQo+Pg0KPj4+IFJlaW5hbGRvLA0KPj4+IEkgYWxzbyBoYXZlIHRoZSBxdWVz dGlvbiBhYm91dCB0aGUgdHJhY2UgcmVwb3J0LiBJdCBpcyB0byBiZSBzZW50IHRvDQo+Pj4gYW4g SVAvcG9ydCwgYnV0IHRoZSB0cmFuc3BvcnQgaXMgbm90IG1lbnRpb25lZCAodGhhdCBJIGNvdWxk IHNlZSkuDQo+Pj4gSXMgaXQgaW50ZW5kZWQgdG8gYmUgVURQPw0KPj4+DQo+Pj4gLURhdmUNCj4+ Pg0KPj4+DQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxw ZXJuDQo+Pj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDExLCAyMDE2IDM6NTEgUE0NCj4+PiBU bzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2Zj QGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9m IGRyYWZ0LXBlbm5vLXNmYy10cmFjZS0wMw0KPj4+DQo+Pj4gQWhoLiAgSSBoYWQgbWlzc2VkIGhv dyB5b3Ugd2VyZSBpbnRlcmFjdGluZyBiZXR3ZWVuIHRoZSBTRiBhbmQgdGhlIFNGRi4NCj4+PiAg IFNvcnJ5Lg0KPj4+DQo+Pj4gUGxlYXNlIGNvbmZpcm06ICB0aGUgaWRlYSBpcyB0aGF0IHRoZSBT RiBhdCB0aGUgZW5kIHdpbGwgYWRkIGl0cw0KPj4+IGluZm9ybWF0aW9uLCBhbmQgdGhlbiB0aGUg U0ZGIGZyb250aW5nIGl0IHdpbGwgc2VuZCB0aGUgcmVzdWx0aW5nDQo+Pj4gdHJhY2Vyb3V0ZSBy ZXNwb25zZT8NCj4+Pg0KPj4+IEl0IGxvb2tzIGxpa2UgdGhlIHJlc3BvbnNlIGlzIGFuIE5TSCBw YWNrZXQuICBJbiB3aGljaCBjYXNlIGl0IGdvZXMgaW4NCj4+PiB0aGUgTlNIIHRyYW5zcG9ydC4g IElmIHRoYXQgdHJhbnNwb3J0IGlzIE1QTFMsIGZvciBleGFtcGxlLCBob3cgd2lsbA0KPj4+dGhl DQo+Pj4gcmVjZWl2ZXIga25vdyB3aG8gc2VudCB0aGUgcmVzcG9uc2U/DQo+Pj4NCj4+PiBZb3Vy cywNCj4+PiBKb2VsDQo+Pj4NCj4+PiBPbiAyLzExLzE2IDM6NDcgUE0sIFJlaW5hbGRvIFBlbm5v IChyZXBlbm5vKSB3cm90ZToNCj4+Pj4gVGhlIHJlc3BvbnNlIGlzIGFsd2F5cyBmcm9tIFNGRiBi ZWNhdXNlIHRoYXQgaXMgdGhlIGVudGl0eSB0aGF0IGRyb3BzDQo+Pj4+IHRoZQ0KPj4+PiBwYWNr ZXQuIFRoYXQgaXMgcHJlY2lzZWx5IHRoZSBzaXR1YXRpb24gdGhpcyB0b29sIGlzIHN1cHBvc2Vk IHRvDQo+Pj4+ZGV0ZWN0Lg0KPj4+PiBJRiB0aGUgU0kgKGV2ZW4gZm9yIHJlZ3VsYXIgZGF0YSBw YWNrZXRzKSBpcyBub3QgbGFyZ2UgZW5vdWdoIHRoZQ0KPj4+PnBhY2tldA0KPj4+PiB3aWxsIGRy b3BwZWQgYnkgdGhlIFNGRiwgbm90IFNGLiBBIHBhY2tldCB0aGF0IGlzIGRlY3JlbWVudGVkIHRv IFNJPTANCj4+Pj4gKHdhcw0KPj4+PiAxIG9uIGluZ3Jlc3MgdG8gU0YpIHdhcyBwcm9jZXNzZWQg YnkgU0YgYW5kIHNob3VsZCBzdGlsbCBiZSBzZW50DQo+Pj4+cGFja2V0DQo+Pj4+IHRvDQo+Pj4+ IFNGRiwgd2hpY2ggd2lsbCB0aGVuIGRyb3AgaXQuDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDIvMTEv MTYsIDEyOjI4IFBNLCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3Jv dGU6DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIDIvMTEvMTYgMzowNSBQTSwgUmVpbmFs ZG8gUGVubm8gKHJlcGVubm8pIHdyb3RlOg0KPj4+Pj4+IEhlbGxvIEpvZWwsDQo+Pj4+Pj4NCj4+ Pj4+PiBPbiAyLzExLzE2LCAxMTo1NyBBTSwgInNmYyBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxw ZXJuIg0KPj4+Pj4+IDxzZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1oQGpvZWxo YWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gSSBhbSByZWx1Y3RhbnQgdG8gYWRv cHQgdGhpcyBkb2N1bWVudCBhcyBpdCBzdGFuZHMuDQo+Pj4+Pj4+IEkgaGF2ZSB0d28gcmVsYXRl ZCBjb25jZXJucywgYm90aCByZWxhdGVkIHRvIHRoZSBiYXNpYyBhcHByb2FjaC4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gRmlyc3QsIHRoZSBwcm9wb3NhbCBoYXMgbm8gbWVjaGFuaXNtIGZvciB0cmFjaW5n IHRoZSBzZXJ2aWNlDQo+Pj4+Pj4+ZnVuY3Rpb24NCj4+Pj4+Pj4gZm9yd2FyZGVycy4gIEl0IHNl ZW1zIHRvIG1lIHRoYXQgaW4gdGVybXMgb2YgT0FNIG9mIHNlcnZpY2UNCj4+Pj4+Pj5mdW5jdGlv bg0KPj4+Pj4+PiBwYXRocywgdGhlIHNlcnZpY2UgZnVuY3Rpb24gZm9yd2FyZGVycyBhcmUgdGhl IGNyaXRpY2FsIGVsZW1lbnQgdG8NCj4+Pj4+Pj5iZQ0KPj4+Pj4+PiBhYmxlIHRvIHZlcmlmeS4N Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gW1JQXSBUaGUgU0ZGIGluZm8gaXMgcHJlc2VudCBpbiB0 aGUgdHJhY2UgcmVwbHkgbWVzc2FnZS4gTWF5YmUgd2UNCj4+Pj4+Pm5lZWQNCj4+Pj4+PiB0bw0K Pj4+Pj4+IHB1dCBtb3JlIGluZm8/DQo+Pj4+PiBbSk1IXSBXaGF0IEkgc2VlIGlzIHRoYXQgaWYg YSB0cmFjZXJvdXRlIHNvbWVob3cgZ2V0cyB0byBhbiBTRkYgd2l0aA0KPj4+Pj5hbg0KPj4+Pj4g U0kgb2YgdGhlIFNJTCwgdGhlIFNGRiB3aWxsIGdlbmVyYXRlIGEgcmVzcG9uc2UuICBUaGUgY3Vy cmVudA0KPj4+Pj4gdW5kZXJzdGFuZGluZyBpcyB0aGF0IFNGIHJhdGhlciB0aGFuIFNGRiB3aWxs IGRlY3JlbWVudCBUVEwuICBJZiBzbywNCj4+Pj4+aWYNCj4+Pj4+IHRoZSBTSSBoaXRzIHRoZSBs aW1pdCwgdGhlIFNGIHdpbGwgZ2VuZXJhdGUgdGhlIHJlc3BvbnNlLCBhbmQgdGhlDQo+Pj4+PiBw YWNrZXQNCj4+Pj4+IHdvbid0IGdldCB0byB0aGUgbmV4dCBTRkYuICBTbyBJIGNhbid0IHNlZSB3 aGVuIHRoaXMgY2FzZSB3b3VsZCBldmVyDQo+Pj4+PiBnZXQNCj4+Pj4+IHRyaWdnZXJlZC4NCj4+ Pj4+IEFsc28sIGl0IGlzIHJhdGhlciB1bmNsZWFyIGhvdyB0aGUgcmVjZWl2ZXIgd291bGQga25v dyB0aGF0IGENCj4+Pj4+cmVzcG9uc2UNCj4+Pj4+IHdhcyBmcm9tIHRoZSBTRkYgcmF0aGVyIHRo YW4gYW4gU0YuICBJcyB0aGVyZSBhIG1hZ2ljIFNGIFR5cGUgZm9yDQo+Pj4+PlNGRj8NCj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gU2Vjb25kLCBpdCBhc3N1bWVzIHRoYXQgdGhlcmUg aXMgdmFsdWUgaW4gaGF2aW5nIGEgc3BlY2lhbCBhc3BlY3QNCj4+Pj4+Pj5vZg0KPj4+Pj4+PiB0 aGUNCj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgcmVwb3J0IHNlcnZpY2UgZnVuY3Rpb24gdHlw ZSBhbmQgaWRlbnRpdHkuICBHaXZlbg0KPj4+Pj4+PiB0aGF0DQo+Pj4+Pj4+IHRoaXMgd2lsbCBi ZSBzcGVjaWFsaXplZCBjb2RlLCBpdCBkb2VzIG5vdCB0ZWxsIHVzIG11Y2ggYWJvdXQgdGhlDQo+ Pj4+Pj4+IGFjdHVhbA0KPj4+Pj4+PiBvcGVyYXRpb24gb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25z Lg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBbUlBdIEkgdGhpbmsgaXQgaXMgYmFzaWMgaW5mby4g QW4gYWRtaW4gd2lsbCBrbm93IHRoYXQgdGhlIFNGIHRoYXQNCj4+Pj4+PnRoZQ0KPj4+Pj4+IHBh Y2tldCBpcyB0cmF2ZXJzaW5nIGlzIG9mIHByb3BlciB0eXBlIGFuZCBhY3R1YWwgaW5zdGFuY2Uu IEdpdmVuDQo+Pj4+Pj4gcHJvdG9jb2wNCj4+Pj4+PiBpcyBleHRlbnNpYmxlIG9uZSBoYXMgZXh0 ZW5kIHRvIGluY2x1ZGUgbWFueSBvdGhlciBTRiBzcGVjaWZpYw0KPj4+Pj4+IG1ldHJpY3MuDQo+ Pj4+Pj4NCj4+Pj4+IFtKTUh9SSB3YXMgYXBwYXJlbnRseSB1bmNsZWFyLiAgSSBhbSBub3QgYXNr aW5nIGZvciBtb3JlIGluZm9ybWF0aW9uLg0KPj4+Pj4gSQ0KPj4+Pj4gYW0gbm90IHN1cmUgdGhh dCB0aGlzIGlzIHVzZWZ1bCBpbmZvcm1hdGlvbiB0byBleHRyYWN0LiAgVGhlIGFjdHVhbA0KPj4+ Pj4gY29uZmlndXJhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCByZWxhdGVkIHRvIHRo ZSB3b3JrIHRoZQ0KPj4+Pj4gc2VydmljZQ0KPj4+Pj4gZnVuY3Rpb24gZG9lcywgc28gdGhlcmUg aXMgbm8gcmVhc29uIGZvciBpdCB0byBiZSBjb3JyZWN0LiAgQW5kDQo+Pj4+PnRyeWluZw0KPj4+ Pj4gdG8gbW9uaXRvciBzZXJ2aWNlIGZ1bmN0aW9uIG9wZXJhYmlsaXR5IHRoaXMgd2F5IHNlZW1z IHVuZm9ydHVuYXRlLg0KPj4+Pj4NCj4+Pj4+IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pg0KPj4+ Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+Pg0KDQo= From nobody Thu Feb 11 14:57:03 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399301B3BCF for ; Thu, 11 Feb 2016 14:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9JPRqFAJz4h for ; Thu, 11 Feb 2016 14:56:54 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265C71B2A56 for ; Thu, 11 Feb 2016 14:56:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0A1818C005B; Thu, 11 Feb 2016 14:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455231414; bh=rOrjUE7ufIwK1A2cRV7YVWiTA05lsOm3cIh694Y8dMg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BWanwF0nixuebuv4eYBPq3QjMwUtVJ42042mVASBY46ixtCJoTG450eSQNYpWRcah vRRNIZKHYN4t+/qs7iXEJ1CSo3WpWilSeuEyX8Uhv3bH5hlcmSrHzv7SmMhd+XzDUC PGcboiWG6Zyhyb7RaVu/48QIjfFhCJDxeN5dZp7w= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 848AC1C0178; Thu, 11 Feb 2016 14:56:53 -0800 (PST) To: "Reinaldo Penno (repenno)" , "sfc@ietf.org" References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> <56BD0ECB.3060206@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56BD1180.3030800@joelhalpern.com> Date: Thu, 11 Feb 2016 17:56:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 22:57:02 -0000 I think it is very hard for the reader to understand how this is supposed to work from the current draft. Personally, what I would like is a revised draft that addresses two issues: 1) Gives an explicit description of the theory of operation so the reader does not have to infer it from the packet format and processing descriptions. 2) Gives an explicit description of how replies can be returned. It can not be implemented inter-operably from what is in there. I am fine with your saying IP/UDP carrying NSH for adoption. That may even be the right answer. While I would like to see the IP address family and correlation ID issues addressed, I can live with that being dealt with after adoption. Yours, Joel On 2/11/16 5:51 PM, Reinaldo Penno (repenno) wrote: > Right, this is something hopefully we can fix after adoption. I wasn¡¯t > sure it would get wide support but it seems folks are happy with UDP. > > In the current implementation responses are already sent over UDP as I > mentioned in other reply. But NSH header is still there (although not used > for forwarding) so that metadata, service path, index and others can be > display/debugged by client. > > On 2/11/16, 2:44 PM, "Joel M. Halpern" wrote: > >> I think the problem is that the draft does not say UDP anywhere. Since >> reverse NSH does not actually work, the draft does not currently tell >> you how to send the response. >> >> As long as we are discussing details, some notes that do not block >> adoption: >> I think the packet format needs a corellation ID so that responses can >> be matched to requests. >> Also, I do not like trying to infer whether IPv4 or IPv6 should be used >>from the contents of the address field. I don't care if it is padded, >> but I would like to see explicit v4 / v6 indication. >> >> Yours, >> Joel >> >> On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: >>> The current implementation uses UDP because of NAT traversal. This is >>> something I did because at some point my SFC trace client was behind a >>> NAT >>> and I wanted to get my responses back. How useful this is? Can©öt say, it >>> was to me. >>> >>> The draft says (I hope) that the transport used should be the same as >>> the >>> one in NSH the trace request. But I©öm open to suggestions (or more >>> importantly actual text) since Joel also had a questions about it. >>> >>> >>> >>> On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >>> >>>> Reinaldo, >>>> I also have the question about the trace report. It is to be sent to >>>> an IP/port, but the transport is not mentioned (that I could see). >>>> Is it intended to be UDP? >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, February 11, 2016 3:51 PM >>>> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >>>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>>> >>>> Ahh. I had missed how you were interacting between the SF and the SFF. >>>> Sorry. >>>> >>>> Please confirm: the idea is that the SF at the end will add its >>>> information, and then the SFF fronting it will send the resulting >>>> traceroute response? >>>> >>>> It looks like the response is an NSH packet. In which case it goes in >>>> the NSH transport. If that transport is MPLS, for example, how will >>>> the >>>> receiver know who sent the response? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>>>> The response is always from SFF because that is the entity that drops >>>>> the >>>>> packet. That is precisely the situation this tool is supposed to >>>>> detect. >>>>> IF the SI (even for regular data packets) is not large enough the >>>>> packet >>>>> will dropped by the SFF, not SF. A packet that is decremented to SI=0 >>>>> (was >>>>> 1 on ingress to SF) was processed by SF and should still be sent >>>>> packet >>>>> to >>>>> SFF, which will then drop it. >>>>> >>>>> >>>>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>>> >>>>>> >>>>>> >>>>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>>>> Hello Joel, >>>>>>> >>>>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>>>> wrote: >>>>>>> >>>>>>>> I am reluctant to adopt this document as it stands. >>>>>>>> I have two related concerns, both related to the basic approach. >>>>>>>> >>>>>>>> First, the proposal has no mechanism for tracing the service >>>>>>>> function >>>>>>>> forwarders. It seems to me that in terms of OAM of service >>>>>>>> function >>>>>>>> paths, the service function forwarders are the critical element to >>>>>>>> be >>>>>>>> able to verify. >>>>>>> >>>>>>> >>>>>>> [RP] The SFF info is present in the trace reply message. Maybe we >>>>>>> need >>>>>>> to >>>>>>> put more info? >>>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with >>>>>> an >>>>>> SI of the SIL, the SFF will generate a response. The current >>>>>> understanding is that SF rather than SFF will decrement TTL. If so, >>>>>> if >>>>>> the SI hits the limit, the SF will generate the response, and the >>>>>> packet >>>>>> won't get to the next SFF. So I can't see when this case would ever >>>>>> get >>>>>> triggered. >>>>>> Also, it is rather unclear how the receiver would know that a >>>>>> response >>>>>> was from the SFF rather than an SF. Is there a magic SF Type for >>>>>> SFF? >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Second, it assumes that there is value in having a special aspect >>>>>>>> of >>>>>>>> the >>>>>>>> service functions report service function type and identity. Given >>>>>>>> that >>>>>>>> this will be specialized code, it does not tell us much about the >>>>>>>> actual >>>>>>>> operation of the service functions. >>>>>>> >>>>>>> >>>>>>> [RP] I think it is basic info. An admin will know that the SF that >>>>>>> the >>>>>>> packet is traversing is of proper type and actual instance. Given >>>>>>> protocol >>>>>>> is extensible one has extend to include many other SF specific >>>>>>> metrics. >>>>>>> >>>>>> [JMH}I was apparently unclear. I am not asking for more information. >>>>>> I >>>>>> am not sure that this is useful information to extract. The actual >>>>>> configuration of this information is not related to the work the >>>>>> service >>>>>> function does, so there is no reason for it to be correct. And >>>>>> trying >>>>>> to monitor service function operability this way seems unfortunate. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> > From nobody Thu Feb 11 15:06:11 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F1B1B3BE8 for ; Thu, 11 Feb 2016 15:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJPM-IbLLt20 for ; Thu, 11 Feb 2016 15:05:57 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2F51B3BE6 for ; Thu, 11 Feb 2016 15:05:57 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Feb 2016 18:06:01 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Thu, 11 Feb 2016 18:05:56 -0500 From: Dave Dolson To: "Joel M. Halpern" , "Reinaldo Penno (repenno)" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8nltCAgAACOQCAAAZEAIAABVQAgAABIQD//7QmIIAAYUUAgAAKKID//7I1uA== Date: Thu, 11 Feb 2016 23:06:00 +0000 Message-ID: <20160211230554.5697621.36378.65489@sandvine.com> References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> ,<56BD0ECB.3060206@joelhalpern.com> In-Reply-To: <56BD0ECB.3060206@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 23:06:03 -0000 Joel, I was actually happy to see the ipv4-mapped ipv6 address used. It's a great way of supporting both versions without requiring an extra bit= , while giving first-class status to ipv6 (it makes ipv4) the special case. Original Message From: Joel M. Halpern Sent: Thursday, February 11, 2016 5:45 PM To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar); sfc@iet= f.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 I think the problem is that the draft does not say UDP anywhere. Since reverse NSH does not actually work, the draft does not currently tell you how to send the response. As long as we are discussing details, some notes that do not block adoption= : I think the packet format needs a corellation ID so that responses can be matched to requests. Also, I do not like trying to infer whether IPv4 or IPv6 should be used from the contents of the address field. I don't care if it is padded, but I would like to see explicit v4 / v6 indication. Yours, Joel On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: > The current implementation uses UDP because of NAT traversal. This is > something I did because at some point my SFC trace client was behind a NA= T > and I wanted to get my responses back. How useful this is? Can=B9t say, i= t > was to me. > > The draft says (I hope) that the transport used should be the same as the > one in NSH the trace request. But I=B9m open to suggestions (or more > importantly actual text) since Joel also had a questions about it. > > > > On 2/11/16, 1:59 PM, "Dave Dolson" wrote: > >> Reinaldo, >> I also have the question about the trace report. It is to be sent to >> an IP/port, but the transport is not mentioned (that I could see). >> Is it intended to be UDP? >> >> -Dave >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Thursday, February 11, 2016 3:51 PM >> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >> >> Ahh. I had missed how you were interacting between the SF and the SFF. >> Sorry. >> >> Please confirm: the idea is that the SF at the end will add its >> information, and then the SFF fronting it will send the resulting >> traceroute response? >> >> It looks like the response is an NSH packet. In which case it goes in >> the NSH transport. If that transport is MPLS, for example, how will the >> receiver know who sent the response? >> >> Yours, >> Joel >> >> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>> The response is always from SFF because that is the entity that drops >>> the >>> packet. That is precisely the situation this tool is supposed to detect= . >>> IF the SI (even for regular data packets) is not large enough the packe= t >>> will dropped by the SFF, not SF. A packet that is decremented to SI=3D0 >>> (was >>> 1 on ingress to SF) was processed by SF and should still be sent packet >>> to >>> SFF, which will then drop it. >>> >>> >>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>> >>>> >>>> >>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>> Hello Joel, >>>>> >>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>> wrote: >>>>> >>>>>> I am reluctant to adopt this document as it stands. >>>>>> I have two related concerns, both related to the basic approach. >>>>>> >>>>>> First, the proposal has no mechanism for tracing the service functio= n >>>>>> forwarders. It seems to me that in terms of OAM of service function >>>>>> paths, the service function forwarders are the critical element to b= e >>>>>> able to verify. >>>>> >>>>> >>>>> [RP] The SFF info is present in the trace reply message. Maybe we nee= d >>>>> to >>>>> put more info? >>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with a= n >>>> SI of the SIL, the SFF will generate a response. The current >>>> understanding is that SF rather than SFF will decrement TTL. If so, i= f >>>> the SI hits the limit, the SF will generate the response, and the >>>> packet >>>> won't get to the next SFF. So I can't see when this case would ever >>>> get >>>> triggered. >>>> Also, it is rather unclear how the receiver would know that a response >>>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>>> >>>>> >>>>>> >>>>>> Second, it assumes that there is value in having a special aspect of >>>>>> the >>>>>> service functions report service function type and identity. Given >>>>>> that >>>>>> this will be specialized code, it does not tell us much about the >>>>>> actual >>>>>> operation of the service functions. >>>>> >>>>> >>>>> [RP] I think it is basic info. An admin will know that the SF that th= e >>>>> packet is traversing is of proper type and actual instance. Given >>>>> protocol >>>>> is extensible one has extend to include many other SF specific >>>>> metrics. >>>>> >>>> [JMH}I was apparently unclear. I am not asking for more information. >>>> I >>>> am not sure that this is useful information to extract. The actual >>>> configuration of this information is not related to the work the >>>> service >>>> function does, so there is no reason for it to be correct. And trying >>>> to monitor service function operability this way seems unfortunate. >>>> >>>> Yours, >>>> Joel >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Thu Feb 11 16:09:56 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B96B1B3CFE; Thu, 11 Feb 2016 16:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpmsoXGha_rp; Thu, 11 Feb 2016 16:09:29 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0E61B3CF8; Thu, 11 Feb 2016 16:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2775; q=dns/txt; s=iport; t=1455235769; x=1456445369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h52+AzzLO+BizeyISoIKEOA+aDCEuQ0viS7rp+qvUjE=; b=A+tM/xIoF8PUOcNhMKGJ3yqXhezKb5Rxf0RN+OETxSGm8Abuvl84RiqL z/zpj72gjhGIt19RxrpcuDGCoi+vpfG7p2gnLW1+UMmVssY7/Yaygi5i7 pkqxemTx4Vt2phQfTy8SWePhDpl0w+6BtX6fo/91U9z/zIZSS26KXtsQz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAeIr1W/5FdJa1egzpSbQaIVbEqA?= =?us-ascii?q?Q2BZyOFagKBNjgUAQEBAQEBAX8LhEEBAQEEOj0CDAQCAQgRBAEBHwkHMhQHAQE?= =?us-ascii?q?FAwIEDgUIiBIOwSYBAQEBAQEBAQEBAQEBAQEBAQEBAQEVikiIbAWNJ4lQAYVNh?= =?us-ascii?q?36BZEqDeYhVjj0BHgEBQoNlagGHVnwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="236753898" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 00:09:28 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1C09Smr005134 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 00:09:28 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 18:09:27 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 18:09:27 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt Thread-Index: AQHRZQhY9c88+3ynwkOLHr9c9z3LPJ8nh70Q Date: Fri, 12 Feb 2016 00:09:27 +0000 Message-ID: References: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> In-Reply-To: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.10.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" , "draft-kumar-sfc-nsh-udp-transport@tools.ietf.org" Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 00:09:38 -0000 Hello All, We published -02 version of the UDP transport draft for NSH based on the fe= edback we received from David Black and others. In particular, it aligns with the usage guidelines in I-D.ietf-tsvwg-rfc540= 5bis version-07 w.r.t congestion control, security and other considerations= . Your feedback on the draft is very much appreciated. Regards, nsh-udp draft co-authors PS: Home for this draft is still being hashed out. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, February 11, 2016 12:11 PM To: Walter Haeffner ; Rajeev Manur ; Larry Kreeger (kreeger) ; Surendra Kumar (s= mkumar) ; Surendra Kumar (smkumar) ; = David T. Melman ; Sumandra Majee ; Dav= id Melman ; Larry Kreeger (kreeger) Subject: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.= txt A new version of I-D, draft-kumar-sfc-nsh-udp-transport-02.txt has been successfully submitted by Surendra Kumar and posted to the IETF re= pository. Name: draft-kumar-sfc-nsh-udp-transport Revision: 02 Title: UDP Transport for Network Service Header Document date: 2016-02-11 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-ud= p-transport-02.txt Status: https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-tr= ansport/ Htmlized: https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transpo= rt-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-nsh-udp= -transport-02 Abstract: This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP transport protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to deploy NSH by not requiring additional overhead as is typical of overlay encapsulation mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the virtual network and realize Service Function Chains (SFCs). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Feb 11 16:43:10 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12831B3D29; Thu, 11 Feb 2016 16:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdYp-g93T3xu; Thu, 11 Feb 2016 16:42:57 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2341A6F9B; Thu, 11 Feb 2016 16:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3117; q=dns/txt; s=iport; t=1455237776; x=1456447376; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=mL5RujlLu8pt2gOMhBLBDxrzwPJDepndMbkm/4CJxWo=; b=Gg5THBw8M2Q3J7IFjxx+Tl/fDNi645iMMbdDdGzAmYhBVynQGEfTM/dm hyj9TCrkWB1HH1ha+yYCSMwdjb8kbFNgfVdf9hMWPTA+QulC2un7DG2u2 iRfYkc5+0JVUIiaf7euNAx4/L+PMo+fJUwRxvtZx056JbJztdNVzT2t8a Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBTKr1W/5tdJa1egzpSbQaIVbEpA?= =?us-ascii?q?Q2BZyOFagKBOTgUAQEBAQEBAX8LhEEBAQEEOj0CDAQCAQgRBAEBHwkHMhQJCAI?= =?us-ascii?q?EDgUIiBIOwTUBAQEBAQEBAQEBAQEBAQEBAQEBAQEVikeIbAWNJ4lQAYVNh36BY?= =?us-ascii?q?0qDeYhVjj0BHgEBQoNkagGHInwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="236764588" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 00:42:55 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1C0gt7U008862 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 00:42:55 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 18:42:55 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 18:42:55 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt Thread-Index: AQHRZQhY9c88+3ynwkOLHr9c9z3LPJ8nh70QgAAKsuA= Date: Fri, 12 Feb 2016 00:42:55 +0000 Message-ID: References: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.10.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [sfc] New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 00:43:02 -0000 2nd attempt to get it sent right. -----Original Message----- From: Surendra Kumar (smkumar)=20 Sent: Thursday, February 11, 2016 4:09 PM To: sfc@ietf.org Cc: 'tsvwg@ietf.org' ; draft-kumar-sfc-nsh-udp-transport@to= ols.ietf.org Subject: FW: New Version Notification for draft-kumar-sfc-nsh-udp-transport= -02.txt Hello All, We published -02 version of the UDP transport draft for NSH based on the fe= edback we received from David Black and others. In particular, it aligns with the usage guidelines in I-D.ietf-tsvwg-rfc540= 5bis version-07 w.r.t congestion control, security and other considerations= . Your feedback on the draft is very much appreciated. Regards, nsh-udp draft co-authors PS: Home for this draft is still being hashed out. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, February 11, 2016 12:11 PM To: Walter Haeffner ; Rajeev Manur ; Larry Kreeger (kreeger) ; Surendra Kumar (s= mkumar) ; Surendra Kumar (smkumar) ; = David T. Melman ; Sumandra Majee ; Dav= id Melman ; Larry Kreeger (kreeger) Subject: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.= txt A new version of I-D, draft-kumar-sfc-nsh-udp-transport-02.txt has been successfully submitted by Surendra Kumar and posted to the IETF re= pository. Name: draft-kumar-sfc-nsh-udp-transport Revision: 02 Title: UDP Transport for Network Service Header Document date: 2016-02-11 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-ud= p-transport-02.txt Status: https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-tr= ansport/ Htmlized: https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transpo= rt-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-nsh-udp= -transport-02 Abstract: This draft describes the transport encapsulation to carry Network Service Header (NSH) over UDP transport protocol. This enables applications and services using NSH to communicate over a simple layer-3 network without topological constraints. It brings down the barrier to deploy NSH by not requiring additional overhead as is typical of overlay encapsulation mechanisms designed on top of UDP. As a first benefit, this method eases the deployment of Service Function Chaining (SFC) by allowing SFC components to utilize the basic UDP/IP stack available in virtually all network elements and end systems to setup the virtual network and realize Service Function Chains (SFCs). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Feb 11 17:30:24 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33A91B318E for ; Thu, 11 Feb 2016 17:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbwA_IMrJCxi for ; Thu, 11 Feb 2016 17:30:05 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892671B319D for ; Thu, 11 Feb 2016 17:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6262; q=dns/txt; s=iport; t=1455240600; x=1456450200; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oGsv4uSEQxeHg2VXYxdBz3YS+szMGKINmnljIN/oaNY=; b=kMg19Hps52VYy3Y/hvonbJaPLNvB3v1pdulbY3nazRTviGiuiiklTcTj vwKl7zvGXhRRkA2ap4H/ae/PX6U7lFOE1ivhwLKslwDyPaMRXUyDW7yTJ C2sHRU2VG/OvXHteZxcEEGXa2b2IfZgRvfMLCB174NrCtEJrNJBj7nlNI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQAbNb1W/4gNJK1VCYM6Um2IW7EpA?= =?us-ascii?q?Q2BZxcKhWwCgTk4FAEBAQEBAQGBCoRBAQEBAwEBAQEaUQsFBwQCAQgOAwQBAQE?= =?us-ascii?q?nBycLFAkIAgQOBYgSCA7BLgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhGBbIJKh?= =?us-ascii?q?AkEI4MtgQ8FjV+JGAGNUoFchEOIVY49AR4BAUKCAhmBSWqGZgEGGYEZAQEB?= X-IronPort-AV: E=Sophos;i="5.22,433,1449532800"; d="scan'208";a="70611222" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2016 01:29:59 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1C1TxRN030128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 01:29:59 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 19:29:58 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 19:29:58 -0600 From: "Reinaldo Penno (repenno)" To: Dave Dolson Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaAgACHPgCAABMhAP//fC2AABIIxoAAAMCsAP//w6Rh Date: Fri, 12 Feb 2016 01:29:58 +0000 Message-ID: <25A768D0-2FC2-4C47-A545-2C9B3970D964@cisco.com> References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> , <56BD0ECB.3060206@joelhalpern.com>, <20160211230554.5697621.36378.65489@sandvine.com> In-Reply-To: <20160211230554.5697621.36378.65489@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 01:30:09 -0000 That is my thinking as well. Mapped addresses already provide explicit fami= ly and promote IPv6 > On Feb 11, 2016, at 3:05 PM, Dave Dolson wrote: >=20 > Joel, I was actually happy to see the ipv4-mapped ipv6 address used. > It's a great way of supporting both versions without requiring an extra b= it, while giving first-class status to ipv6 (it makes ipv4) the special cas= e. >=20 >=20 >=20 > Original Message > From: Joel M. Halpern > Sent: Thursday, February 11, 2016 5:45 PM > To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar); sfc@i= etf.org > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >=20 >=20 > I think the problem is that the draft does not say UDP anywhere. Since > reverse NSH does not actually work, the draft does not currently tell > you how to send the response. >=20 > As long as we are discussing details, some notes that do not block adopti= on: > I think the packet format needs a corellation ID so that responses can > be matched to requests. > Also, I do not like trying to infer whether IPv4 or IPv6 should be used > from the contents of the address field. I don't care if it is padded, > but I would like to see explicit v4 / v6 indication. >=20 > Yours, > Joel >=20 >> On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: >> The current implementation uses UDP because of NAT traversal. This is >> something I did because at some point my SFC trace client was behind a N= AT >> and I wanted to get my responses back. How useful this is? Can=B9t say, = it >> was to me. >>=20 >> The draft says (I hope) that the transport used should be the same as th= e >> one in NSH the trace request. But I=B9m open to suggestions (or more >> importantly actual text) since Joel also had a questions about it. >>=20 >>=20 >>=20 >>> On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >>>=20 >>> Reinaldo, >>> I also have the question about the trace report. It is to be sent to >>> an IP/port, but the transport is not mentioned (that I could see). >>> Is it intended to be UDP? >>>=20 >>> -Dave >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 11, 2016 3:51 PM >>> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>>=20 >>> Ahh. I had missed how you were interacting between the SF and the SFF. >>> Sorry. >>>=20 >>> Please confirm: the idea is that the SF at the end will add its >>> information, and then the SFF fronting it will send the resulting >>> traceroute response? >>>=20 >>> It looks like the response is an NSH packet. In which case it goes in >>> the NSH transport. If that transport is MPLS, for example, how will th= e >>> receiver know who sent the response? >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>>> The response is always from SFF because that is the entity that drops >>>> the >>>> packet. That is precisely the situation this tool is supposed to detec= t. >>>> IF the SI (even for regular data packets) is not large enough the pack= et >>>> will dropped by the SFF, not SF. A packet that is decremented to SI=3D= 0 >>>> (was >>>> 1 on ingress to SF) was processed by SF and should still be sent packe= t >>>> to >>>> SFF, which will then drop it. >>>>=20 >>>>=20 >>>>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>>> Hello Joel, >>>>>>=20 >>>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>>> wrote: >>>>>>=20 >>>>>>> I am reluctant to adopt this document as it stands. >>>>>>> I have two related concerns, both related to the basic approach. >>>>>>>=20 >>>>>>> First, the proposal has no mechanism for tracing the service functi= on >>>>>>> forwarders. It seems to me that in terms of OAM of service functio= n >>>>>>> paths, the service function forwarders are the critical element to = be >>>>>>> able to verify. >>>>>>=20 >>>>>>=20 >>>>>> [RP] The SFF info is present in the trace reply message. Maybe we ne= ed >>>>>> to >>>>>> put more info? >>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with = an >>>>> SI of the SIL, the SFF will generate a response. The current >>>>> understanding is that SF rather than SFF will decrement TTL. If so, = if >>>>> the SI hits the limit, the SF will generate the response, and the >>>>> packet >>>>> won't get to the next SFF. So I can't see when this case would ever >>>>> get >>>>> triggered. >>>>> Also, it is rather unclear how the receiver would know that a respons= e >>>>> was from the SFF rather than an SF. Is there a magic SF Type for SFF= ? >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Second, it assumes that there is value in having a special aspect o= f >>>>>>> the >>>>>>> service functions report service function type and identity. Given >>>>>>> that >>>>>>> this will be specialized code, it does not tell us much about the >>>>>>> actual >>>>>>> operation of the service functions. >>>>>>=20 >>>>>>=20 >>>>>> [RP] I think it is basic info. An admin will know that the SF that t= he >>>>>> packet is traversing is of proper type and actual instance. Given >>>>>> protocol >>>>>> is extensible one has extend to include many other SF specific >>>>>> metrics. >>>>> [JMH}I was apparently unclear. I am not asking for more information. >>>>> I >>>>> am not sure that this is useful information to extract. The actual >>>>> configuration of this information is not related to the work the >>>>> service >>>>> function does, so there is no reason for it to be correct. And tryin= g >>>>> to monitor service function operability this way seems unfortunate. >>>>>=20 >>>>> Yours, >>>>> Joel >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >>=20 From nobody Thu Feb 11 22:46:49 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF91B404C; Thu, 11 Feb 2016 22:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFWoyrior_tw; Thu, 11 Feb 2016 22:46:45 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D4A1B404B; Thu, 11 Feb 2016 22:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4663; q=dns/txt; s=iport; t=1455259604; x=1456469204; h=from:to:cc:subject:date:message-id:mime-version; bh=VcK6kgAaSjJaUkCWk5hZ+8iAdBX1yDpgrNoKqkp/8o4=; b=L/CwT7gFnkX9UW8fecI/FpuRqZKXDr1vLFCMXvLKqG09/OrTOzA+wJ81 BzKkpPWI6eUHbUogdhGDILEwy/hwvXH8A3rjGZ7RzHWEEiRb/KJJaS2XD 7bxbhv1eje0oUm0XOSKl3bePAobKOcvRpWpVXCa+GUG9YFJH6rCDeJ5JL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQDIfr1W/4QNJK1egm5MUnOIVbEuA?= =?us-ascii?q?Q2BZ4YNgTc4FAEBAQEBAQF/C4REBC1MEgGBACYBBA4NiBLBJwEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBFpMzBZJuhAkBjU2OfY49AR4BAUKDZIgNfAEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,435,1449532800"; d="scan'208,217"; a="72631478" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2016 06:46:43 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1C6kgxZ007779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 06:46:42 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 12 Feb 2016 00:46:42 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Fri, 12 Feb 2016 00:46:42 -0600 From: "Surendra Kumar (smkumar)" To: "sfc-chairs@ietf.org" Thread-Topic: draft-kumar-sfc-offloads - Service Function Simple Offloads Thread-Index: AdFlYBB18Eop8gl7Sv6GRn9kHZ2gtw== Date: Fri, 12 Feb 2016 06:46:42 +0000 Message-ID: <4d599a78b3244b9cb841fde1d03803c5@XCH-RCD-020.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.71.225] Content-Type: multipart/alternative; boundary="_000_4d599a78b3244b9cb841fde1d03803c5XCHRCD020ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , "draft-kumar-sfc-offloads@ietf.org" Subject: [sfc] draft-kumar-sfc-offloads - Service Function Simple Offloads X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 06:46:46 -0000 --_000_4d599a78b3244b9cb841fde1d03803c5XCHRCD020ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SFC Chairs, This draft was presented in Honolulu as well as in Dallas. Further, same requirement also came up later in the form of 'bypass bit' wh= ich was left out of NSH draft, at the time of merging the drafts, to tackle= separately in this draft. We believe it has received good discussion and support. It is at its third = revision considering the original draft it was split from based on the WG f= eedback. We request WG adoption of this draft. Regards, Surendra. --_000_4d599a78b3244b9cb841fde1d03803c5XCHRCD020ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi SFC Chairs,

 

This draft was presented in Honolulu as well as in = Dallas.

Further, same requirement also came up later in the= form of ‘bypass bit’ which was left out of NSH draft, at the t= ime of merging the drafts, to tackle separately in this draft.

 

We believe it has received good discussion and supp= ort. It is at its third revision considering the original draft it was spli= t from based on the WG feedback.

 

We request WG adoption of this draft.

 

Regards,

Surendra.

 

--_000_4d599a78b3244b9cb841fde1d03803c5XCHRCD020ciscocom_-- From nobody Fri Feb 12 03:54:04 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3821B4414 for ; Fri, 12 Feb 2016 03:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hoU3Z0UFz3g for ; Fri, 12 Feb 2016 03:53:57 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67F31B4412 for ; Fri, 12 Feb 2016 03:53:56 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 721D26FC0D74F; Fri, 12 Feb 2016 11:53:52 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1CBrsCq004397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Feb 2016 11:53:54 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1CBrrFh021585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Feb 2016 12:53:53 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.224]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 12 Feb 2016 12:53:54 +0100 From: "Henderickx, Wim (Nokia - BE)" To: "EXT Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZYwLtiRJoKym90WZ9h+13r5AJA== Date: Fri, 12 Feb 2016 11:53:52 +0000 Message-ID: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_FE4E0315DADC4D48AD02FE4B032C3E14alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 11:54:03 -0000 --_000_FE4E0315DADC4D48AD02FE4B032C3E14alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGEgZmV3IGNsYXJpZmljYXRpb24gcXVlc3Rpb25zIG9uIHRoaXM/DQoNCiAgKiAgIFdo YXQgYWJvdXQgTUQgdHlwZSAyPw0KICAqICAgSG93IHdpbGwgdGhpcyB3b3JrIGluIFNGRiBwcm94 eSBtb2RlPw0KICAqICAgRG9lcyB0aGUgU0Ygd2hlbiByZXBseWluZyBzZW50IGEgdHJhY2UgcmVw b3J0IG9yIGRvIHdlIGV4cGVjdCB0aGUgU0ZGIHRvIGRvIHRoaXMgaW4gdGhpcyBwcm9wb3NhbD8g SSByZWFkIHNvbWUgaW5jb25zaXN0ZW5jaWVzIGluIHRoZSBkcmFmdDogb25lIGlzIHRoZSByZXBv cnQgaXMgYWRkaW5nIHRoZSBhZGRpdGlvbmFsIGRhdGEgaW4gc2VjdGlvbiAzLCB3aGlsZSBpbiBz ZWN0aW9uIDUgdGhlIFNGRiBpcyBzZW5kaW5nIHRoZSByZXBvcnQNCg0KRnJvbTogc2ZjIDxzZmMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgSmltIEd1aWNoYXJkIDxqZ3VpY2hhckBjaXNjby5jb208bWFpbHRvOmpndWljaGFyQGNpc2Nv LmNvbT4+DQpEYXRlOiBUaHVyc2RheSAxMSBGZWJydWFyeSAyMDE2IGF0IDIzOjE4DQpUbzogInNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIENhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0 LXBlbm5vLXNmYy10cmFjZS0wMw0KDQpEZWFyIFdHOg0KDQpUaGlzIGVtYWlsIHNlcnZlcyBhcyBh IGNhbGwgZm9yIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXBlbm5vLXNmYy10cmFjZS0wMyBhcyBhIFdH IGRvY3VtZW50LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gd2lsbCBydW4gZm9yIDIgd2Vla3MgZW5k aW5nIDIvMjUvMjAxNi4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRv cHRpb24sIGFuZCBub3QgYSBsYXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBB ZG9wdGluZyBhIFdHIGRvY3VtZW50IHNpbXBseSBtZWFucyB0aGF0IHRoZSBXRyB3aWxsIGZvY3Vz IGl0cyBlZmZvcnRzIG9uIHRoYXQgcGFydGljdWxhciBkcmFmdCBnb2luZyBmb3J3YXJkLCBhbmQg dXNlIHRoYXQgZG9jdW1lbnQgZm9yIHJlc29sdmluZyBvcGVuIGlzc3VlcyBhbmQgZG9jdW1lbnRp bmcgdGhlIFdH4oCZcyBkZWNpc2lvbnMuDQoNClBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBz dXBwb3J0IGFkb3B0aW9uIGZvciBub3QsIGFuZCBpZiBub3Qgd2h5LiBJc3N1ZXMgeW91IGhhdmUg d2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCBpdHNlbGYgY2FuIGFsc28gYmUgcmFpc2VkLCBidXQg dGhleSBzaG91bGQgYmUgcmFpc2VkIGluIHRoZSBjb250ZXh0IG9mIHdoYXQgc2hvdWxkIGJlIGNo YW5nZWQgaW4gdGhlIGRvY3VtZW50IGdvaW5nIGZvcndhcmQsIHJhdGhlciB0aGFuIGEgcHJlLWNv bmRpdGlvbiBmb3IgYWRvcHRpb24uDQoNCkZpbmFsbHksIG5vdyBpcyBhbHNvIGEgZ29vZCB0aW1l IHRvIHBvbGwgZm9yIGtub3dsZWRnZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRy YWZ0LCBpbiBsaW5lIHdpdGggdGhlIElQUiBkaXNjbG9zdXJlIG9ibGlnYXRpb25zIGZvciBXRyBw YXJ0aWNpcGFudHMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUg ZGV0YWlscykuIElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSBy ZXNwb25kIHRvIHRoaXMgZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KVGhhbmtzIQ0KDQpTRkMgQ2hhaXJzDQo= --_000_FE4E0315DADC4D48AD02FE4B032C3E14alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <1174359D83264447B89128C46FB0B95A@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SSBo YXZlIGEgZmV3IGNsYXJpZmljYXRpb24gcXVlc3Rpb25zIG9uIHRoaXM/PC9kaXY+DQo8dWw+DQo8 bGk+V2hhdCBhYm91dCBNRCB0eXBlIDI/PC9saT48bGk+SG93IHdpbGwgdGhpcyB3b3JrIGluIFNG RiBwcm94eSBtb2RlPzwvbGk+PGxpPkRvZXMgdGhlIFNGIHdoZW4gcmVwbHlpbmcgc2VudCBhIHRy YWNlIHJlcG9ydCBvciBkbyB3ZSBleHBlY3QgdGhlIFNGRiB0byBkbyB0aGlzIGluIHRoaXMgcHJv cG9zYWw/IEkgcmVhZCBzb21lIGluY29uc2lzdGVuY2llcyBpbiB0aGUgZHJhZnQ6IG9uZSBpcyB0 aGUgcmVwb3J0IGlzIGFkZGluZyB0aGUgYWRkaXRpb25hbCBkYXRhIGluIHNlY3Rpb24gMywgd2hp bGUgaW4gc2VjdGlvbiA1IHRoZSBTRkYgaXMgc2VuZGluZyB0aGUgcmVwb3J0PC9saT48L3VsPg0K PGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1h bGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRF Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAw aW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJP UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5zZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgSmltIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amd1aWNoYXJAY2lzY28uY29t Ij5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXkgMTEgRmVicnVhcnkgMjAxNiBhdCAyMzoxODxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bc2ZjXSBDYWxsIGZvciBX RyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtdHJhY2UtMDM8YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBDb25zb2xhczsiPkRlYXIgV0c6PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1m YW1pbHk6IENvbnNvbGFzOyI+PGJyPg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyI+VGhpcyBlbWFp bCBzZXJ2ZXMgYXMgYSBjYWxsIGZvciBXRyBhZG9wdGlvbiBvZiBkcmFmdC1wZW5uby1zZmMtdHJh Y2UtMDMgYXMgYSBXRyBkb2N1bWVudC4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdpbGwgcnVuIGZv ciAyIHdlZWtzDQogZW5kaW5nIDIvMjUvMjAxNi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTMuNXB0OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyI+ UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24sIGFuZCBub3QgYSBs YXN0IGNhbGwgZm9yIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50LiBBZG9wdGluZyBhIFdHIGRvY3Vt ZW50IHNpbXBseSBtZWFucyB0aGF0DQogdGhlIFdHIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMgb24g dGhhdCBwYXJ0aWN1bGFyIGRyYWZ0IGdvaW5nIGZvcndhcmQsIGFuZCB1c2UgdGhhdCBkb2N1bWVu dCBmb3IgcmVzb2x2aW5nIG9wZW4gaXNzdWVzIGFuZCBkb2N1bWVudGluZyB0aGUgV0figJlzIGRl Y2lzaW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMu NXB0OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyI+UGxlYXNlIGluZGljYXRlIHdoZXRo ZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gZm9yIG5vdCwgYW5kIGlmIG5vdCB3aHkuIElzc3VlcyB5 b3UgaGF2ZSB3aXRoIHRoZSBjdXJyZW50IGRvY3VtZW50IGl0c2VsZiBjYW4gYWxzbyBiZSByYWlz ZWQsDQogYnV0IHRoZXkgc2hvdWxkIGJlIHJhaXNlZCBpbiB0aGUgY29udGV4dCBvZiB3aGF0IHNo b3VsZCBiZSBjaGFuZ2VkIGluIHRoZSBkb2N1bWVudCBnb2luZyBmb3J3YXJkLCByYXRoZXIgdGhh biBhIHByZS1jb25kaXRpb24gZm9yIGFkb3B0aW9uLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMy41cHQ7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQ29u c29sYXM7Ij5GaW5hbGx5LCBub3cgaXMgYWxzbyBhIGdvb2QgdGltZSB0byBwb2xsIGZvciBrbm93 bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgaW4gbGluZSB3aXRo IHRoZSBJUFIgZGlzY2xvc3VyZSBvYmxpZ2F0aW9ucw0KIGZvciBXRyBwYXJ0aWNpcGFudHMgKHNl ZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuIElmIHlv dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMg ZW1haWwgKHRvIHRoZSBjaGFpcnMpIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUi48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQ29uc29sYXM7Ij48YnI+DQo8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTog Q29uc29sYXM7Ij5UaGFua3MhPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IENvbnNvbGFzOyI+PGJyPg0KPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1p bHk6IENvbnNvbGFzOyI+U0ZDIENoYWlyczwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FE4E0315DADC4D48AD02FE4B032C3E14alcatellucentcom_-- From nobody Fri Feb 12 06:15:06 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDB11A0196 for ; Fri, 12 Feb 2016 06:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek_XXHG7DGss for ; Fri, 12 Feb 2016 06:15:03 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id DEFC01A0191 for ; Fri, 12 Feb 2016 06:15:02 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 12 Feb 2016 09:15:06 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Fri, 12 Feb 2016 09:15:02 -0500 From: Dave Dolson To: "Reinaldo Penno (repenno)" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8nltCAgAACOQCAAAZEAIAABVQAgAABIQD//7QmIIAAYUUAgAAKKID//7I1uIAAfAoAgAB/UOA= Date: Fri, 12 Feb 2016 14:15:06 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> , <56BD0ECB.3060206@joelhalpern.com>, <20160211230554.5697621.36378.65489@sandvine.com> <25A768D0-2FC2-4C47-A545-2C9B3970D964@cisco.com> In-Reply-To: <25A768D0-2FC2-4C47-A545-2C9B3970D964@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:15:05 -0000 (Extra info) For those not familiar with the concept, some operating systems=20 support the use of IPv4-mapped-IPv6 addresses in socket application code. Code is written for IPv6 sockets, and IPv4 also works if an IPv4-mapped-IPv6 address is used, provided the IPV6_V6ONLY socket option is zero. So it's a good way to give IPv6 first-class status and also support IPv4 without separate code paths or flags. The format is standardized in RFC4291: https://tools.ietf.org/html/rfc4291#section-2.5.5.2 Motivation is described in section 4.2 of RFC4038: https://tools.ietf.org/html/rfc4038#section-4.2 Both Linux and FreeBSD support this. -Dave -----Original Message----- From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]=20 Sent: Thursday, February 11, 2016 8:30 PM To: Dave Dolson Cc: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 That is my thinking as well. Mapped addresses already provide explicit fami= ly and promote IPv6 > On Feb 11, 2016, at 3:05 PM, Dave Dolson wrote: >=20 > Joel, I was actually happy to see the ipv4-mapped ipv6 address used. > It's a great way of supporting both versions without requiring an extra b= it, while giving first-class status to ipv6 (it makes ipv4) the special cas= e. >=20 >=20 >=20 > Original Message > From: Joel M. Halpern > Sent: Thursday, February 11, 2016 5:45 PM > To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar); sfc@i= etf.org > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >=20 >=20 > I think the problem is that the draft does not say UDP anywhere. Since > reverse NSH does not actually work, the draft does not currently tell > you how to send the response. >=20 > As long as we are discussing details, some notes that do not block adopti= on: > I think the packet format needs a corellation ID so that responses can > be matched to requests. > Also, I do not like trying to infer whether IPv4 or IPv6 should be used > from the contents of the address field. I don't care if it is padded, > but I would like to see explicit v4 / v6 indication. >=20 > Yours, > Joel >=20 >> On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: >> The current implementation uses UDP because of NAT traversal. This is >> something I did because at some point my SFC trace client was behind a N= AT >> and I wanted to get my responses back. How useful this is? Can=B9t say, = it >> was to me. >>=20 >> The draft says (I hope) that the transport used should be the same as th= e >> one in NSH the trace request. But I=B9m open to suggestions (or more >> importantly actual text) since Joel also had a questions about it. >>=20 >>=20 >>=20 >>> On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >>>=20 >>> Reinaldo, >>> I also have the question about the trace report. It is to be sent to >>> an IP/port, but the transport is not mentioned (that I could see). >>> Is it intended to be UDP? >>>=20 >>> -Dave >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 11, 2016 3:51 PM >>> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>>=20 >>> Ahh. I had missed how you were interacting between the SF and the SFF. >>> Sorry. >>>=20 >>> Please confirm: the idea is that the SF at the end will add its >>> information, and then the SFF fronting it will send the resulting >>> traceroute response? >>>=20 >>> It looks like the response is an NSH packet. In which case it goes in >>> the NSH transport. If that transport is MPLS, for example, how will th= e >>> receiver know who sent the response? >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>>> The response is always from SFF because that is the entity that drops >>>> the >>>> packet. That is precisely the situation this tool is supposed to detec= t. >>>> IF the SI (even for regular data packets) is not large enough the pack= et >>>> will dropped by the SFF, not SF. A packet that is decremented to SI=3D= 0 >>>> (was >>>> 1 on ingress to SF) was processed by SF and should still be sent packe= t >>>> to >>>> SFF, which will then drop it. >>>>=20 >>>>=20 >>>>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>>> Hello Joel, >>>>>>=20 >>>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>>> wrote: >>>>>>=20 >>>>>>> I am reluctant to adopt this document as it stands. >>>>>>> I have two related concerns, both related to the basic approach. >>>>>>>=20 >>>>>>> First, the proposal has no mechanism for tracing the service functi= on >>>>>>> forwarders. It seems to me that in terms of OAM of service functio= n >>>>>>> paths, the service function forwarders are the critical element to = be >>>>>>> able to verify. >>>>>>=20 >>>>>>=20 >>>>>> [RP] The SFF info is present in the trace reply message. Maybe we ne= ed >>>>>> to >>>>>> put more info? >>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with = an >>>>> SI of the SIL, the SFF will generate a response. The current >>>>> understanding is that SF rather than SFF will decrement TTL. If so, = if >>>>> the SI hits the limit, the SF will generate the response, and the >>>>> packet >>>>> won't get to the next SFF. So I can't see when this case would ever >>>>> get >>>>> triggered. >>>>> Also, it is rather unclear how the receiver would know that a respons= e >>>>> was from the SFF rather than an SF. Is there a magic SF Type for SFF= ? >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Second, it assumes that there is value in having a special aspect o= f >>>>>>> the >>>>>>> service functions report service function type and identity. Given >>>>>>> that >>>>>>> this will be specialized code, it does not tell us much about the >>>>>>> actual >>>>>>> operation of the service functions. >>>>>>=20 >>>>>>=20 >>>>>> [RP] I think it is basic info. An admin will know that the SF that t= he >>>>>> packet is traversing is of proper type and actual instance. Given >>>>>> protocol >>>>>> is extensible one has extend to include many other SF specific >>>>>> metrics. >>>>> [JMH}I was apparently unclear. I am not asking for more information. >>>>> I >>>>> am not sure that this is useful information to extract. The actual >>>>> configuration of this information is not related to the work the >>>>> service >>>>> function does, so there is no reason for it to be correct. And tryin= g >>>>> to monitor service function operability this way seems unfortunate. >>>>>=20 >>>>> Yours, >>>>> Joel >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >>=20 From nobody Fri Feb 12 06:55:15 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253481A19E5 for ; Fri, 12 Feb 2016 06:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WP38b--QT-c for ; Fri, 12 Feb 2016 06:55:10 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037D11A0AFE for ; Fri, 12 Feb 2016 06:55:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E10CF2407A1; Fri, 12 Feb 2016 06:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455288909; bh=d066xsQxEzry5ZPCa9YYyvX2ywx/zJHlHzTZPiRybYw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=D8H162ugZXZp3T+WegsVxy45YkcZJYplwmGmnuvJ+l7biaXfMFkJoQBtLrEBliHrR hprU4Kc2g+2nACgD7kc7Y3QCjuVOjwEkPusgIRe21wCYrSs7cjD6yj6fVhVDAuRERg dUApq95iiRiDOtviIAOlxrM2VOT/CJvWa5aDSpCs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3C84C240621; Fri, 12 Feb 2016 06:55:09 -0800 (PST) To: Dave Dolson , "Reinaldo Penno (repenno)" References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> <56BD0ECB.3060206@joelhalpern.com> <20160211230554.5697621.36378.65489@sandvine.com> <25A768D0-2FC2-4C47-A545-2C9B3970D964@cisco.com> From: "Joel M. Halpern" Message-ID: <56BDF216.6080804@joelhalpern.com> Date: Fri, 12 Feb 2016 09:54:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 14:55:12 -0000 Looking at the descriptions you point to, those descriptions seems to assume that the user of the IPv4-mapped address is an IPv6-speaker, and that some other device will translate the packet into IPv4. If so, that is not the same as declaring that the SFF should send an IPv4 message based on being told an IPv6 destination address which is an IPv4-mapped format address. Is there somewhere else where that is described as a desired behavior for dual-stack devices? Yours, Joel On 2/12/16 9:15 AM, Dave Dolson wrote: > (Extra info) > For those not familiar with the concept, some operating systems > support the use of IPv4-mapped-IPv6 addresses in socket application code. > > Code is written for IPv6 sockets, and IPv4 also works if an > IPv4-mapped-IPv6 address is used, provided the IPV6_V6ONLY socket > option is zero. > > So it's a good way to give IPv6 first-class status and also support IPv4 > without separate code paths or flags. > > The format is standardized in RFC4291: > https://tools.ietf.org/html/rfc4291#section-2.5.5.2 > > Motivation is described in section 4.2 of RFC4038: > https://tools.ietf.org/html/rfc4038#section-4.2 > > > Both Linux and FreeBSD support this. > > -Dave > > > > -----Original Message----- > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > Sent: Thursday, February 11, 2016 8:30 PM > To: Dave Dolson > Cc: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > > That is my thinking as well. Mapped addresses already provide explicit family and promote IPv6 > > >> On Feb 11, 2016, at 3:05 PM, Dave Dolson wrote: >> >> Joel, I was actually happy to see the ipv4-mapped ipv6 address used. >> It's a great way of supporting both versions without requiring an extra bit, while giving first-class status to ipv6 (it makes ipv4) the special case. >> >> >> >> Original Message >> From: Joel M. Halpern >> Sent: Thursday, February 11, 2016 5:45 PM >> To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >> >> >> I think the problem is that the draft does not say UDP anywhere. Since >> reverse NSH does not actually work, the draft does not currently tell >> you how to send the response. >> >> As long as we are discussing details, some notes that do not block adoption: >> I think the packet format needs a corellation ID so that responses can >> be matched to requests. >> Also, I do not like trying to infer whether IPv4 or IPv6 should be used >> from the contents of the address field. I don't care if it is padded, >> but I would like to see explicit v4 / v6 indication. >> >> Yours, >> Joel >> >>> On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: >>> The current implementation uses UDP because of NAT traversal. This is >>> something I did because at some point my SFC trace client was behind a NAT >>> and I wanted to get my responses back. How useful this is? Can¹t say, it >>> was to me. >>> >>> The draft says (I hope) that the transport used should be the same as the >>> one in NSH the trace request. But I¹m open to suggestions (or more >>> importantly actual text) since Joel also had a questions about it. >>> >>> >>> >>>> On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >>>> >>>> Reinaldo, >>>> I also have the question about the trace report. It is to be sent to >>>> an IP/port, but the transport is not mentioned (that I could see). >>>> Is it intended to be UDP? >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, February 11, 2016 3:51 PM >>>> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >>>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>>> >>>> Ahh. I had missed how you were interacting between the SF and the SFF. >>>> Sorry. >>>> >>>> Please confirm: the idea is that the SF at the end will add its >>>> information, and then the SFF fronting it will send the resulting >>>> traceroute response? >>>> >>>> It looks like the response is an NSH packet. In which case it goes in >>>> the NSH transport. If that transport is MPLS, for example, how will the >>>> receiver know who sent the response? >>>> >>>> Yours, >>>> Joel >>>> >>>>> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>>>> The response is always from SFF because that is the entity that drops >>>>> the >>>>> packet. That is precisely the situation this tool is supposed to detect. >>>>> IF the SI (even for regular data packets) is not large enough the packet >>>>> will dropped by the SFF, not SF. A packet that is decremented to SI=0 >>>>> (was >>>>> 1 on ingress to SF) was processed by SF and should still be sent packet >>>>> to >>>>> SFF, which will then drop it. >>>>> >>>>> >>>>>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>>>> Hello Joel, >>>>>>> >>>>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>>>> wrote: >>>>>>> >>>>>>>> I am reluctant to adopt this document as it stands. >>>>>>>> I have two related concerns, both related to the basic approach. >>>>>>>> >>>>>>>> First, the proposal has no mechanism for tracing the service function >>>>>>>> forwarders. It seems to me that in terms of OAM of service function >>>>>>>> paths, the service function forwarders are the critical element to be >>>>>>>> able to verify. >>>>>>> >>>>>>> >>>>>>> [RP] The SFF info is present in the trace reply message. Maybe we need >>>>>>> to >>>>>>> put more info? >>>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF with an >>>>>> SI of the SIL, the SFF will generate a response. The current >>>>>> understanding is that SF rather than SFF will decrement TTL. If so, if >>>>>> the SI hits the limit, the SF will generate the response, and the >>>>>> packet >>>>>> won't get to the next SFF. So I can't see when this case would ever >>>>>> get >>>>>> triggered. >>>>>> Also, it is rather unclear how the receiver would know that a response >>>>>> was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Second, it assumes that there is value in having a special aspect of >>>>>>>> the >>>>>>>> service functions report service function type and identity. Given >>>>>>>> that >>>>>>>> this will be specialized code, it does not tell us much about the >>>>>>>> actual >>>>>>>> operation of the service functions. >>>>>>> >>>>>>> >>>>>>> [RP] I think it is basic info. An admin will know that the SF that the >>>>>>> packet is traversing is of proper type and actual instance. Given >>>>>>> protocol >>>>>>> is extensible one has extend to include many other SF specific >>>>>>> metrics. >>>>>> [JMH}I was apparently unclear. I am not asking for more information. >>>>>> I >>>>>> am not sure that this is useful information to extract. The actual >>>>>> configuration of this information is not related to the work the >>>>>> service >>>>>> function does, so there is no reason for it to be correct. And trying >>>>>> to monitor service function operability this way seems unfortunate. >>>>>> >>>>>> Yours, >>>>>> Joel >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> From nobody Fri Feb 12 07:42:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE51B1A1B9C for ; Fri, 12 Feb 2016 07:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKOlFXPXRQfx for ; Fri, 12 Feb 2016 07:42:54 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F251A1B8C for ; Fri, 12 Feb 2016 07:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8675; q=dns/txt; s=iport; t=1455291774; x=1456501374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=De34+xn96/mHNOZVDuvNml7yeL0q9eBf3d1YsDSl0qM=; b=NbLF3znHuJTzs+xBIuy9EJ2vcoamyOpne1T6ufx1xq5dkZPpaMRH5rk8 QZEdUPBvrqbiJZ6RkVOh0LnGn7Z6zpmQ9ivR1QivgdtHIuLvJNLVQpr81 bUGe4m7A9JDpK1OBUndzxuI00vIew33p1evifMc32s5Jn9DwEbokambj9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAm/L1W/4YNJK1VCYM6Um0GiFWxM?= =?us-ascii?q?gENgWcXCoVsAoE3OBQBAQEBAQEBgQqEQQEBAQQBAQEaUQsMBAIBCBEEAQEBJwc?= =?us-ascii?q?nCxQJCAIEAQ0FCIgSDsFtAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKR4QJBIRfB?= =?us-ascii?q?Y1fiRgBhU+HfoFlhEOIVY49AR4BAUKCAhmBSWoBAQGGbgEGGR18AQEB?= X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="236988686" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2016 15:42:53 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1CFgrOp010423 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2016 15:42:53 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 12 Feb 2016 09:42:52 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Fri, 12 Feb 2016 09:42:52 -0600 From: "Roberta Maglione (robmgl)" To: "Joel M. Halpern" , Dave Dolson Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8np5SA//98G4CAAIxiAP//fzaAgACHPgCAABMhAP//fC2AABIIxoAAAMCsAP//w6RhgAE6WwCAAArvAIAAXQnQ Date: Fri, 12 Feb 2016 15:42:52 +0000 Message-ID: References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> <56BD0ECB.3060206@joelhalpern.com> <20160211230554.5697621.36378.65489@sandvine.com> <25A768D0-2FC2-4C47-A545-2C9B3970D964@cisco.com> <56BDF216.6080804@joelhalpern.com> In-Reply-To: <56BDF216.6080804@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.205.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 15:42:57 -0000 Hello Joel, Not sure if this is what you are looking for, but 6PE, RFC 4798 (https://t= ools.ietf.org/html/rfc4798 ), shows an example of use of IPv4-mapped IPv6 a= ddress on dual-stack devices. In 6PE the IPv4 address of the egress 6PE router is encoded as an IPv4-mapp= ed IPv6 address in the BGP Next Hop field. =20 Regards Roberta -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, February 12, 2016 3:54 PM To: Dave Dolson; Reinaldo Penno (repenno) Cc: Jim Guichard (jguichar); Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Looking at the descriptions you point to, those descriptions seems to assum= e that the user of the IPv4-mapped address is an IPv6-speaker, and that som= e other device will translate the packet into IPv4. If so, that is not the same as declaring that the SFF should send an IPv4 message based on being told an IPv6 destination address which is an IP= v4-mapped format address. Is there somewhere else where that is described as a desired behavior for d= ual-stack devices? Yours, Joel On 2/12/16 9:15 AM, Dave Dolson wrote: > (Extra info) > For those not familiar with the concept, some operating systems=20 > support the use of IPv4-mapped-IPv6 addresses in socket application code. > > Code is written for IPv6 sockets, and IPv4 also works if an > IPv4-mapped-IPv6 address is used, provided the IPV6_V6ONLY socket=20 > option is zero. > > So it's a good way to give IPv6 first-class status and also support=20 > IPv4 without separate code paths or flags. > > The format is standardized in RFC4291: > https://tools.ietf.org/html/rfc4291#section-2.5.5.2 > > Motivation is described in section 4.2 of RFC4038: > https://tools.ietf.org/html/rfc4038#section-4.2 > > > Both Linux and FreeBSD support this. > > -Dave > > > > -----Original Message----- > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > Sent: Thursday, February 11, 2016 8:30 PM > To: Dave Dolson > Cc: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > > That is my thinking as well. Mapped addresses already provide explicit=20 > family and promote IPv6 > > >> On Feb 11, 2016, at 3:05 PM, Dave Dolson wrote: >> >> Joel, I was actually happy to see the ipv4-mapped ipv6 address used. >> It's a great way of supporting both versions without requiring an extra = bit, while giving first-class status to ipv6 (it makes ipv4) the special ca= se. >> >> >> >> Original Message >> From: Joel M. Halpern >> Sent: Thursday, February 11, 2016 5:45 PM >> To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar);=20 >> sfc@ietf.org >> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >> >> >> I think the problem is that the draft does not say UDP anywhere. =20 >> Since reverse NSH does not actually work, the draft does not=20 >> currently tell you how to send the response. >> >> As long as we are discussing details, some notes that do not block adopt= ion: >> I think the packet format needs a corellation ID so that responses=20 >> can be matched to requests. >> Also, I do not like trying to infer whether IPv4 or IPv6 should be=20 >> used from the contents of the address field. I don't care if it is=20 >> padded, but I would like to see explicit v4 / v6 indication. >> >> Yours, >> Joel >> >>> On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: >>> The current implementation uses UDP because of NAT traversal. This=20 >>> is something I did because at some point my SFC trace client was=20 >>> behind a NAT and I wanted to get my responses back. How useful this=20 >>> is? Can=B9t say, it was to me. >>> >>> The draft says (I hope) that the transport used should be the same=20 >>> as the one in NSH the trace request. But I=B9m open to suggestions=20 >>> (or more importantly actual text) since Joel also had a questions about= it. >>> >>> >>> >>>> On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >>>> >>>> Reinaldo, >>>> I also have the question about the trace report. It is to be sent=20 >>>> to an IP/port, but the transport is not mentioned (that I could see). >>>> Is it intended to be UDP? >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M.=20 >>>> Halpern >>>> Sent: Thursday, February 11, 2016 3:51 PM >>>> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >>>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>>> >>>> Ahh. I had missed how you were interacting between the SF and the SFF= . >>>> Sorry. >>>> >>>> Please confirm: the idea is that the SF at the end will add its=20 >>>> information, and then the SFF fronting it will send the resulting=20 >>>> traceroute response? >>>> >>>> It looks like the response is an NSH packet. In which case it goes=20 >>>> in the NSH transport. If that transport is MPLS, for example, how=20 >>>> will the receiver know who sent the response? >>>> >>>> Yours, >>>> Joel >>>> >>>>> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>>>> The response is always from SFF because that is the entity that=20 >>>>> drops the packet. That is precisely the situation this tool is=20 >>>>> supposed to detect. >>>>> IF the SI (even for regular data packets) is not large enough the=20 >>>>> packet will dropped by the SFF, not SF. A packet that is=20 >>>>> decremented to SI=3D0 (was >>>>> 1 on ingress to SF) was processed by SF and should still be sent=20 >>>>> packet to SFF, which will then drop it. >>>>> >>>>> >>>>>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>>>> Hello Joel, >>>>>>> >>>>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>>>> wrote: >>>>>>> >>>>>>>> I am reluctant to adopt this document as it stands. >>>>>>>> I have two related concerns, both related to the basic approach. >>>>>>>> >>>>>>>> First, the proposal has no mechanism for tracing the service=20 >>>>>>>> function forwarders. It seems to me that in terms of OAM of=20 >>>>>>>> service function paths, the service function forwarders are the=20 >>>>>>>> critical element to be able to verify. >>>>>>> >>>>>>> >>>>>>> [RP] The SFF info is present in the trace reply message. Maybe=20 >>>>>>> we need to put more info? >>>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF=20 >>>>>> with an SI of the SIL, the SFF will generate a response. The=20 >>>>>> current understanding is that SF rather than SFF will decrement=20 >>>>>> TTL. If so, if the SI hits the limit, the SF will generate the=20 >>>>>> response, and the packet won't get to the next SFF. So I can't=20 >>>>>> see when this case would ever get triggered. >>>>>> Also, it is rather unclear how the receiver would know that a=20 >>>>>> response was from the SFF rather than an SF. Is there a magic SF Ty= pe for SFF? >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Second, it assumes that there is value in having a special aspect = of >>>>>>>> the >>>>>>>> service functions report service function type and identity. Give= n >>>>>>>> that >>>>>>>> this will be specialized code, it does not tell us much about the >>>>>>>> actual >>>>>>>> operation of the service functions. >>>>>>> >>>>>>> >>>>>>> [RP] I think it is basic info. An admin will know that the SF that = the >>>>>>> packet is traversing is of proper type and actual instance. Given >>>>>>> protocol >>>>>>> is extensible one has extend to include many other SF specific >>>>>>> metrics. >>>>>> [JMH}I was apparently unclear. I am not asking for more information= . >>>>>> I >>>>>> am not sure that this is useful information to extract. The actual >>>>>> configuration of this information is not related to the work the >>>>>> service >>>>>> function does, so there is no reason for it to be correct. And tryi= ng >>>>>> to monitor service function operability this way seems unfortunate. >>>>>> >>>>>> Yours, >>>>>> Joel >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 12 07:52:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802251A1B95 for ; Fri, 12 Feb 2016 07:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHZO7T-5SV3l for ; Fri, 12 Feb 2016 07:52:53 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B421A1BF2 for ; Fri, 12 Feb 2016 07:52:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E09A31C059C; Fri, 12 Feb 2016 07:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455292372; bh=pkzrrqgYzuKUR9/P1ZyZf9Kvqc/ed8DToTWZlPGXcvI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qpl3XgHRbnxVlVNLwinP9VPCTjSU0BjTIWUhR6IUtqI7bxM5MH+e3NwvcHuEL5Auy xY/HBrRAKwqiEJ0jFJVDUNdMCR0rxxKaKaxsMl2P1Fji+JSCoF0AR/G/Oa7j4F0U3J JHjYH17KlxTl45GK7w9oW4GWFKPYiS9U0goQQZuY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2E5091C04BF; Fri, 12 Feb 2016 07:52:52 -0800 (PST) To: "Roberta Maglione (robmgl)" , Dave Dolson References: <56BCE7C5.5030109@joelhalpern.com> <56BCEEE4.8080401@joelhalpern.com> <56BCF44E.7070406@joelhalpern.com> <56BD0ECB.3060206@joelhalpern.com> <20160211230554.5697621.36378.65489@sandvine.com> <25A768D0-2FC2-4C47-A545-2C9B3970D964@cisco.com> <56BDF216.6080804@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56BDFF9D.3020607@joelhalpern.com> Date: Fri, 12 Feb 2016 10:51:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 15:52:55 -0000 Thank you Roberta. This is very close to what I am asking for, and probably close enough that I should shut up. The interesting difference in that particular case is that the 6PE device knows that it only has an IPv4 interface in the direction in which it received the IPv6 address with a mapped IPv4 content. Unless I come across a larger issue, I will accept this pointer as saying that the approach is sufficient, and let the matter drop. Yours, Joel On 2/12/16 10:42 AM, Roberta Maglione (robmgl) wrote: > Hello Joel, > Not sure if this is what you are looking for, but 6PE, RFC 4798 (https://tools.ietf.org/html/rfc4798 ), shows an example of use of IPv4-mapped IPv6 address on dual-stack devices. > > In 6PE the IPv4 address of the egress 6PE router is encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. > > Regards > Roberta > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, February 12, 2016 3:54 PM > To: Dave Dolson; Reinaldo Penno (repenno) > Cc: Jim Guichard (jguichar); Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 > > Looking at the descriptions you point to, those descriptions seems to assume that the user of the IPv4-mapped address is an IPv6-speaker, and that some other device will translate the packet into IPv4. > > If so, that is not the same as declaring that the SFF should send an > IPv4 message based on being told an IPv6 destination address which is an IPv4-mapped format address. > > Is there somewhere else where that is described as a desired behavior for dual-stack devices? > > Yours, > Joel > > On 2/12/16 9:15 AM, Dave Dolson wrote: >> (Extra info) >> For those not familiar with the concept, some operating systems >> support the use of IPv4-mapped-IPv6 addresses in socket application code. >> >> Code is written for IPv6 sockets, and IPv4 also works if an >> IPv4-mapped-IPv6 address is used, provided the IPV6_V6ONLY socket >> option is zero. >> >> So it's a good way to give IPv6 first-class status and also support >> IPv4 without separate code paths or flags. >> >> The format is standardized in RFC4291: >> https://tools.ietf.org/html/rfc4291#section-2.5.5.2 >> >> Motivation is described in section 4.2 of RFC4038: >> https://tools.ietf.org/html/rfc4038#section-4.2 >> >> >> Both Linux and FreeBSD support this. >> >> -Dave >> >> >> >> -----Original Message----- >> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >> Sent: Thursday, February 11, 2016 8:30 PM >> To: Dave Dolson >> Cc: Joel M. Halpern; Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >> >> That is my thinking as well. Mapped addresses already provide explicit >> family and promote IPv6 >> >> >>> On Feb 11, 2016, at 3:05 PM, Dave Dolson wrote: >>> >>> Joel, I was actually happy to see the ipv4-mapped ipv6 address used. >>> It's a great way of supporting both versions without requiring an extra bit, while giving first-class status to ipv6 (it makes ipv4) the special case. >>> >>> >>> >>> Original Message >>> From: Joel M. Halpern >>> Sent: Thursday, February 11, 2016 5:45 PM >>> To: Reinaldo Penno (repenno); Dave Dolson; Jim Guichard (jguichar); >>> sfc@ietf.org >>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>> >>> >>> I think the problem is that the draft does not say UDP anywhere. >>> Since reverse NSH does not actually work, the draft does not >>> currently tell you how to send the response. >>> >>> As long as we are discussing details, some notes that do not block adoption: >>> I think the packet format needs a corellation ID so that responses >>> can be matched to requests. >>> Also, I do not like trying to infer whether IPv4 or IPv6 should be >>> used from the contents of the address field. I don't care if it is >>> padded, but I would like to see explicit v4 / v6 indication. >>> >>> Yours, >>> Joel >>> >>>> On 2/11/16 5:08 PM, Reinaldo Penno (repenno) wrote: >>>> The current implementation uses UDP because of NAT traversal. This >>>> is something I did because at some point my SFC trace client was >>>> behind a NAT and I wanted to get my responses back. How useful this >>>> is? Can¹t say, it was to me. >>>> >>>> The draft says (I hope) that the transport used should be the same >>>> as the one in NSH the trace request. But I¹m open to suggestions >>>> (or more importantly actual text) since Joel also had a questions about it. >>>> >>>> >>>> >>>>> On 2/11/16, 1:59 PM, "Dave Dolson" wrote: >>>>> >>>>> Reinaldo, >>>>> I also have the question about the trace report. It is to be sent >>>>> to an IP/port, but the transport is not mentioned (that I could see). >>>>> Is it intended to be UDP? >>>>> >>>>> -Dave >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. >>>>> Halpern >>>>> Sent: Thursday, February 11, 2016 3:51 PM >>>>> To: Reinaldo Penno (repenno); Jim Guichard (jguichar); sfc@ietf.org >>>>> Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 >>>>> >>>>> Ahh. I had missed how you were interacting between the SF and the SFF. >>>>> Sorry. >>>>> >>>>> Please confirm: the idea is that the SF at the end will add its >>>>> information, and then the SFF fronting it will send the resulting >>>>> traceroute response? >>>>> >>>>> It looks like the response is an NSH packet. In which case it goes >>>>> in the NSH transport. If that transport is MPLS, for example, how >>>>> will the receiver know who sent the response? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>>> On 2/11/16 3:47 PM, Reinaldo Penno (repenno) wrote: >>>>>> The response is always from SFF because that is the entity that >>>>>> drops the packet. That is precisely the situation this tool is >>>>>> supposed to detect. >>>>>> IF the SI (even for regular data packets) is not large enough the >>>>>> packet will dropped by the SFF, not SF. A packet that is >>>>>> decremented to SI=0 (was >>>>>> 1 on ingress to SF) was processed by SF and should still be sent >>>>>> packet to SFF, which will then drop it. >>>>>> >>>>>> >>>>>>> On 2/11/16, 12:28 PM, "Joel M. Halpern" wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 2/11/16 3:05 PM, Reinaldo Penno (repenno) wrote: >>>>>>>> Hello Joel, >>>>>>>> >>>>>>>> On 2/11/16, 11:57 AM, "sfc on behalf of Joel M. Halpern" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I am reluctant to adopt this document as it stands. >>>>>>>>> I have two related concerns, both related to the basic approach. >>>>>>>>> >>>>>>>>> First, the proposal has no mechanism for tracing the service >>>>>>>>> function forwarders. It seems to me that in terms of OAM of >>>>>>>>> service function paths, the service function forwarders are the >>>>>>>>> critical element to be able to verify. >>>>>>>> >>>>>>>> >>>>>>>> [RP] The SFF info is present in the trace reply message. Maybe >>>>>>>> we need to put more info? >>>>>>> [JMH] What I see is that if a traceroute somehow gets to an SFF >>>>>>> with an SI of the SIL, the SFF will generate a response. The >>>>>>> current understanding is that SF rather than SFF will decrement >>>>>>> TTL. If so, if the SI hits the limit, the SF will generate the >>>>>>> response, and the packet won't get to the next SFF. So I can't >>>>>>> see when this case would ever get triggered. >>>>>>> Also, it is rather unclear how the receiver would know that a >>>>>>> response was from the SFF rather than an SF. Is there a magic SF Type for SFF? >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Second, it assumes that there is value in having a special aspect of >>>>>>>>> the >>>>>>>>> service functions report service function type and identity. Given >>>>>>>>> that >>>>>>>>> this will be specialized code, it does not tell us much about the >>>>>>>>> actual >>>>>>>>> operation of the service functions. >>>>>>>> >>>>>>>> >>>>>>>> [RP] I think it is basic info. An admin will know that the SF that the >>>>>>>> packet is traversing is of proper type and actual instance. Given >>>>>>>> protocol >>>>>>>> is extensible one has extend to include many other SF specific >>>>>>>> metrics. >>>>>>> [JMH}I was apparently unclear. I am not asking for more information. >>>>>>> I >>>>>>> am not sure that this is useful information to extract. The actual >>>>>>> configuration of this information is not related to the work the >>>>>>> service >>>>>>> function does, so there is no reason for it to be correct. And trying >>>>>>> to monitor service function operability this way seems unfortunate. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 15 21:50:39 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CE01B3611 for ; Mon, 15 Feb 2016 21:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NqqK3gT1Gen for ; Mon, 15 Feb 2016 21:50:36 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D901B360F for ; Mon, 15 Feb 2016 21:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3260; q=dns/txt; s=iport; t=1455601836; x=1456811436; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4dvc28LIiRJSt989jedI+ZlD8ebsIXqCqyDMDdTI5og=; b=Yli7S9NnyGDu+Xg2gMEKBvFtqQL4tlgLaMgJZQUvXvVphwmLyC2ntKwl fuTxZnAt3+VddxkPoRowHgAWAamJJwM/Jc20Bd6D+NWG7uRZvYSouSEII xizUpdtTyWMSQS2JuCkgl9MM8dMlN8FZTdCkWtWePjARNGaQlX/JSMpyz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgDPt8JW/5pdJa1egzpSbQa6HQENg?= =?us-ascii?q?WcjhWoCHIEZOBQBAQEBAQEBfwuEQQEBAQQjETMQDgQCAQgRBAEBAwIjAwICAjA?= =?us-ascii?q?UAQYBAQUDAgQTCIgSDqkLjwIBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4lLhzKBO?= =?us-ascii?q?gWNKIlVAYVQh3+BY0qDeYhUjj8BHgEBQoNjagGHUnwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,454,1449532800"; d="scan'208";a="238233324" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2016 05:50:35 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1G5oZQX018596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Feb 2016 05:50:35 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 15 Feb 2016 23:50:35 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Mon, 15 Feb 2016 23:50:35 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt Thread-Index: AQHRaEgftY5gODLGKEWM7VvRoI+RuZ8uJK9Q Date: Tue, 16 Feb 2016 05:50:35 +0000 Message-ID: <85ce2e5bb4c04c9799b06e87b06c3fab@XCH-RCD-020.cisco.com> References: <20160215232512.27882.60936.idtracker@ietfa.amsl.com> In-Reply-To: <20160215232512.27882.60936.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.101.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-kumar-sfc-nsh-forwarding-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 05:50:38 -0000 SGVsbG8gQWxsLA0KDQpUaGlzIGlzIGEgbmV3IGRyYWZ0IHRvIHNlcGFyYXRlIHNlcnZpY2UgZm9y d2FyZGluZyBmcm9tIHNlcnZpY2UgZGVsaXZlcnkgZnVuY3Rpb24gaW4gTlNILg0KSXQgY29udGFp bnMgdGhlIHNlcnZpY2UgcGF0aCBoZWFkZXIgdXBkYXRlcyB0byBTRkZzIGFuZCBlbmFibGVzIGlu dGVncml0eSBjaGVja3Mgb24gaXQuDQoNClRoYW5rcywNClN1cmVuZHJhLg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxNSwg MjAxNiAzOjI1IFBNDQpUbzogRG9uZ2tlZSBMZWUgPGRvbmdrZWUubGVlQHNrLmNvbT47IFBldGVy IEJvc2NoIChwYm9zY2gpIDxwYm9zY2hAY2lzY28uY29tPjsgUmFqZWV2IE1hbnVyIDxybWFudXJA YnJvYWRjb20uY29tPjsgSm9lbCBNLiBIYWxwZXJuIDxqb2VsLmhhbHBlcm5AZXJpY3Nzb24uY29t PjsgU3VtYW5kcmEgTWFqZWUgPHMubWFqZWVAZjUuY29tPjsgU3VyZW5kcmEgS3VtYXIgKHNta3Vt YXIpIDxzbWt1bWFyQGNpc2NvLmNvbT47IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSA8c21rdW1h ckBjaXNjby5jb20+OyBKb2VsIEhhbHBlcm4gPGpvZWwuaGFscGVybkBlcmljc3Nvbi5jb20+OyBL ZW50IExldW5nIChrbGV1bmcpIDxrbGV1bmdAY2lzY28uY29tPg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rdW1hci1zZmMtbnNoLWZvcndhcmRpbmctMDAudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWt1bWFyLXNmYy1uc2gtZm9yd2FyZGlu Zy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3VyZW5kcmEgS3Vt YXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQta3Vt YXItc2ZjLW5zaC1mb3J3YXJkaW5nDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJSW5mcmFzdHJ1Y3R1 cmUgU2VydmljZSBGb3J3YXJkaW5nIEZvciBOU0gNCkRvY3VtZW50IGRhdGU6CTIwMTYtMDItMTUN Ckdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE3DQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWt1bWFyLXNmYy1u c2gtZm9yd2FyZGluZy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1rdW1hci1zZmMtbnNoLWZvcndhcmRpbmcvDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt1bWFyLXNmYy1uc2gtZm9y d2FyZGluZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIHNl cGFyYXRpb24gb2Ygc2VydmljZSBmb3J3YXJkaW5nIGZ1bmN0aW9uDQogICBhbmQgc2VydmljZSBk ZWxpdmVyeSBmdW5jdGlvbiBhYnN0cmFjdGlvbnMsIGFsb25nIHdpdGggdGhlIG1lY2hhbmljcw0K ICAgb2YgTlNIIGVuY2Fwc3VsYXRlZCBwYWNrZXQgZm9yd2FyZGluZyB3aXRoIHN1Y2ggc2VwYXJh dGlvbiwgaW4gU0ZDDQogICBkZXBsb3ltZW50cy4NCg0KICAgVGhpcyBzZXBhcmF0aW9uIGZyZWVz IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBmcm9tIG1ha2luZyBmb3J3YXJkaW5nDQogICBkZWNpc2lv bnMgYW5kIHRoZSBuZWNlc3NhcnkgY29udHJvbCBwbGFuZSBpbnRlZ3JhdGlvbiwgdGhlcmVieQ0K ICAga2VlcGluZyB0aGUgc2VydmljZSBmdW5jdGlvbnMgc2ltcGxlIGFuZCBmb2N1c2VkIG9uIHNl cnZpY2UgZGVsaXZlcnkuDQogICBGdXJ0aGVyLCB0aGlzIHNlcGFyYXRpb24gZnVsbHkgY29udGFp bnMgdGhlIGZvcndhcmRpbmcgZGVjaXNpb25zIGluDQogICBmb3J3YXJkaW5nIGZ1bmN0aW9ucywg dGhlcmVieSBhbGxvd2luZyBpbXBsZW1lbnRhdGlvbnMgdG8gZW5mb3JjZQ0KICAgaW50ZWdyaXR5 IG9mIHRoZSBmb3J3YXJkaW5nIHN0YXRlIGNhcnJpZWQgaW4gTlNIIHdoaWNoIGluIHR1cm4gaXMN CiAgIHJlcXVpcmVkIGZvciBjb3JyZWN0bHkgZm9yd2FyZGluZyBOU0ggZW5jYXBzdWxhdGVkIHBh Y2tldHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Feb 17 09:35:09 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E4A1ACDEC for ; Wed, 17 Feb 2016 09:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWTbMZC_iBma for ; Wed, 17 Feb 2016 09:35:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195A81AC439 for ; Wed, 17 Feb 2016 09:35:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIS29792; Wed, 17 Feb 2016 17:34:57 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0235.001; Wed, 17 Feb 2016 17:34:54 +0000 From: Georgios Karagiannis To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8wiFxA Date: Wed, 17 Feb 2016 17:34:54 +0000 Message-ID: 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.221.64.108] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC2D0F6F1Blhreml502mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56C4AF42.0068, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 42535a6fecbdcd108256e20989a5ba9c Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:35:08 -0000 --_000_C5034E44CD620A44971BAAEB372655DC2D0F6F1Blhreml502mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Hi all, Agree that draft-penno-sfc-trace-03 is useful since it provides several sol= utions for requirements identified in ietf-sfc-oam-framework. However, as we identified in the draft-yang-sfc-trace-issue-analysis-01, se= e URL below, draft-penno-sfc-trace-03 describes a solution of SFC traceroute based on NSH header, but only a subset of the requirements provi= ded in ietf-sfc-oam-framework are addressed. https://www.ietf.org/id/draft-yang-sfc-trace-issue-analysis-01.txt In my opinion the draft-yang-sfc-trace-issue-analysis-01 complements the me= ntioned gaps in draft-penno-sfc-trace-03. Therefore, I propose to add the provided information in draft-yang-sfc-trac= e-issue-analysis-01 in draft-penno-sfc-trace-03 before the latter one gets = a SFC WG status. Best regards, Georgios From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, February 11, 2016 8:18 PM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-trace-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_C5034E44CD620A44971BAAEB372655DC2D0F6F1Blhreml502mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim, Hi all,

 <= /p>

Agree that draft-penno-sf= c-trace-03 is useful since it provides several solutions for requirements i= dentified in ietf-sfc-oam-framework.

However, as we identified= in the draft-yang-sfc-trace-issue-analysis-01, see URL below, draft-penno-= sfc-trace-03 describes a solution of SFC

traceroute based on NSH h= eader, but only a subset of the requirements provided in ietf-sfc-oam-frame= work are addressed.

 <= /p>

https://www.ietf.org/id/d= raft-yang-sfc-trace-issue-analysis-01.txt

 <= /p>

 <= /p>

In my opinion the draft-y= ang-sfc-trace-issue-analysis-01 complements the mentioned gaps in draft-pen= no-sfc-trace-03.

 <= /p>

Therefore, I propose to a= dd the provided information in draft-yang-sfc-trace-issue-analysis-01 in dr= aft-penno-sfc-trace-03 before the latter one gets a SFC WG status.

 <= /p>

Best regards,<= /span>

Georgios

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, February 11, 2016 8:18 PM
To: sfc@ietf.org
Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03=

 

Dear WG:

&n= bsp;

This email serves as a call for WG adoption of draft-penno-sfc= -trace-03 as a WG document. The call for adoption will run for 2 weeks endi= ng 2/25/2016.

 <= /span>

Please note that this is a call for adoption, and not a last c= all for content of the document. Adopting a WG document simply means that t= he WG will focus its efforts on that particular draft going forward, and use that document for resolving open i= ssues and documenting the WG’s decisions.

 <= /span>

Please indicate whether you support adoption for not, and if n= ot why. Issues you have with the current document itself can also be raised= , but they should be raised in the context of what should be changed in the document going forward, rather than a pre= -condition for adoption. 

 <= /span>

Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure obligations= for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document aut= hor please respond to this email (to the chairs) whether or not you are awa= re of any relevant IPR.=

&n= bsp;

Thanks!

&n= bsp;

SFC Chairs=

--_000_C5034E44CD620A44971BAAEB372655DC2D0F6F1Blhreml502mbs_-- From nobody Wed Feb 17 09:51:38 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3F1AD0A5 for ; Wed, 17 Feb 2016 09:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTyIYetIl2nX for ; Wed, 17 Feb 2016 09:51:34 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8371C1AD05D for ; Wed, 17 Feb 2016 09:51:34 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Wed, 17 Feb 2016 12:51:33 -0500 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRZQD6tiRJoKym90WZ9h+13r5AJJ8wjB1A Date: Wed, 17 Feb 2016 17:51:37 +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: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830E737C0wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:51:37 -0000 --_000_E8355113905631478EFF04F5AA706E9830E737C0wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the trace approach, assuming it will be specified to work with MD= -type=3D2 as well. It is a simple point-solution for tracing paths. The UDP transport needs to be clarified, but this can be easily fixed. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, February 11, 2016 2:18 PM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-trace-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_E8355113905631478EFF04F5AA706E9830E737C0wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the trace appro= ach, assuming it will be specified to work with MD-type=3D2 as well.

It is a simple point-solu= tion for tracing paths.

 <= /p>

The UDP transport needs t= o be clarified, but this can be easily fixed.

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, February 11, 2016 2:18 PM
To: sfc@ietf.org
Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03=

 

Dear WG:

&n= bsp;

This email serves as a call for WG adoption of draft-penno-sfc= -trace-03 as a WG document. The call for adoption will run for 2 weeks endi= ng 2/25/2016.

 <= /span>

Please note that this is a call for adoption, and not a last c= all for content of the document. Adopting a WG document simply means that t= he WG will focus its efforts on that particular draft going forward, and use that document for resolving open i= ssues and documenting the WG’s decisions.

 <= /span>

Please indicate whether you support adoption for not, and if n= ot why. Issues you have with the current document itself can also be raised= , but they should be raised in the context of what should be changed in the document going forward, rather than a pre= -condition for adoption. 

 <= /span>

Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure obligations= for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document aut= hor please respond to this email (to the chairs) whether or not you are awa= re of any relevant IPR.=

&n= bsp;

Thanks!

&n= bsp;

SFC Chairs=

--_000_E8355113905631478EFF04F5AA706E9830E737C0wtlexchp2sandvi_-- From nobody Wed Feb 17 11:21:26 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C857B1A1A20 for ; Wed, 17 Feb 2016 11:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLEmyyUhbIC2 for ; Wed, 17 Feb 2016 11:21:22 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19ACC1A873A for ; Wed, 17 Feb 2016 11:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11019; q=dns/txt; s=iport; t=1455736882; x=1456946482; h=from:to:subject:date:message-id:mime-version; bh=UQFCeedPUhyY8tSqFkjwRwsNW27eon9FOCWKZGD62vs=; b=U5nyBKNaz98iW7Nab8cKqTqD/ETlGnLBIQgodIyHRPUUzYUb6tYCJyQU hTODHEh2sRTjx0hIXy9LzkcpIQBJjgGDalLra2vetwT4FWTzyTLYixY8m JR4tjWk3V707x+9UnhGTH/ULWYQ8IKOzO0w2vDeliHZoTaTyYHter9wQT 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgArx8RW/4gNJK1egm5MUm0GuhgBD?= =?us-ascii?q?YFnhg0CgUw4FAEBAQEBAQFkJ4RBAQEBBB0QXgEIDgMDAQEBKDkUCQoEARIbh3+?= =?us-ascii?q?7YQEBAQEBAQEBAQEBAQEBAQEBAQEXhhKEO4QFEQE+FoQEBY1ihRGEEQGNWIFch?= =?us-ascii?q?EOIVI5GAR4BAUKDY2qHEDR8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,462,1449532800"; d="scan'208,217";a="239703051" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Feb 2016 19:21:21 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1HJLLiI022034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 19:21:21 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 13:21:21 -0600 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 13:21:21 -0600 From: "Reinaldo Penno (repenno)" To: Dave Dolson , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRabhidpWTGBDjUUexzi5vV6poDw== Date: Wed, 17 Feb 2016 19:21:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.84.230] Content-Type: multipart/alternative; boundary="_000_D2EA0762227B3repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:21:25 -0000 --_000_D2EA0762227B3repennociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think my takeaway from the feedback is the following: - MD-Type 2 - An introduction section on operational model. - UDP replies SFC Trace today can be extended to carry whatever folks want so I'm not con= cerned about that. Thanks, From: sfc > on behalf of = Dave Dolson > Date: Wednesday, February 17, 2016 at 9:51 AM To: "Jim Guichard (jguichar)" >, "sfc@ietf.org" > Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 I support the trace approach, assuming it will be specified to work with MD= -type=3D2 as well. It is a simple point-solution for tracing paths. The UDP transport needs to be clarified, but this can be easily fixed. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, February 11, 2016 2:18 PM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-trace-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_D2EA0762227B3repennociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <029695D46069714589F04C9374E4FA02@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I think my takeaway from the feedback is the following:

-  MD-Type 2
- An introduction section on operational model. 
- UDP replies

SFC Trace today can be extended to carry whatever folks want so I̵= 7;m not concerned about that.

Thanks,


From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson &l= t;ddolson@sandvine.com>
Date: Wednesday, February 17, 2016 = at 9:51 AM
To: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com>, = "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Call for WG adop= tion of draft-penno-sfc-trace-03

I support the trace approach, assum= ing it will be specified to work with MD-type=3D2 as well.

It is a simple point-solution for t= racing paths.

 

The UDP transport needs to be clari= fied, but this can be easily fixed.

 

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, February 11, 2016 2:18 PM
To: sfc@ietf.org
Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03=

 

Dear WG:

&n= bsp;

This email serves as a call for WG adoption of draft-penno-sfc= -trace-03 as a WG document. The call for adoption will run for 2 weeks endi= ng 2/25/2016.

 <= /span>

Please note that this is a call for adoption, and not a last c= all for content of the document. Adopting a WG document simply means that t= he WG will focus its efforts on that particular draft going forward, and use that document for resolving open i= ssues and documenting the WG’s decisions.

 <= /span>

Please indicate whether you support adoption for not, and if n= ot why. Issues you have with the current document itself can also be raised= , but they should be raised in the context of what should be changed in the document going forward, rather than a pre= -condition for adoption. 

 <= /span>

Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure obligations= for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document aut= hor please respond to this email (to the chairs) whether or not you are awa= re of any relevant IPR.=

&n= bsp;

Thanks!

&n= bsp;

SFC Chairs=

--_000_D2EA0762227B3repennociscocom_-- From nobody Wed Feb 17 19:23:18 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C46971B2E92; Wed, 17 Feb 2016 13:52:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217215256.8444.76404.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 13:52:56 -0800 Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 19:23:15 -0800 Cc: mls.ietf@gmail.com, sfc-chairs@ietf.org, sfc@ietf.org, akatlas@gmail.com Subject: [sfc] sfc - New Meeting Session Request for IETF 95 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 21:52:57 -0000 A new meeting session request has just been submitted by Martin Stiemerling, a Chair of the sfc working group. --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Martin Stiemerling Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: bess i2rs idr lisp mpls nvo3 rtgwg sdnrg spring Special Requests: --------------------------------------------------------- From nobody Wed Feb 17 19:23:19 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013271A8ADC; Wed, 17 Feb 2016 15:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZQjoBduXWlU; Wed, 17 Feb 2016 15:38:06 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90531A8A3F; Wed, 17 Feb 2016 15:38:01 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1HNbxOk016449 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Feb 2016 18:37:59 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u1HNbxOk016449 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1455752280; bh=wQ+6a5uqkuFKjGT7T+AbZrVb11s=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=L8xb51BrdvlifSRt7+NiBie0rFheJSU6s8oE1AGuR2A8IFO/KJDf6rmMlDlEU0pL4 frCEduLGsLDEZaQ/rNuFGDpjMCKF4aVKkMKEsse5Sf6GUPA5DdrCBrPtANDHPbSynT 2r18fg7i2Es3zDcE/+TSsj5sJYIqyHAx9NrlocAo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u1HNbxOk016449 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 17 Feb 2016 18:37:39 -0500 Received: from MXHUB228.corp.emc.com (MXHUB228.corp.emc.com [10.253.68.98]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u1HNbgP6003965 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 17 Feb 2016 18:37:45 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.172]) by MXHUB228.corp.emc.com ([10.253.68.98]) with mapi id 14.03.0266.001; Wed, 17 Feb 2016 18:37:43 -0500 From: "Black, David" To: "Surendra Kumar (smkumar)" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt Thread-Index: AQHRZQhY9c88+3ynwkOLHr9c9z3LPJ8nh70QgAljE3A= Date: Wed, 17 Feb 2016 23:37:41 +0000 Message-ID: References: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 19:23:15 -0800 Cc: "tsvwg@ietf.org" , "draft-kumar-sfc-nsh-udp-transport@tools.ietf.org" Subject: Re: [sfc] New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 23:38:13 -0000 Hi Surendra, While I'll need to read the NSH/UDP draft in detail, I'll supply one quick = comment. Based on this text in Section 1.1 of the NSH/UDP draft: NSH and more broadly SFC, in its initial specification, targets only a single administrative domain and falls into the applicability type 2: controlled environment. It is assumed that SFC is deployed over a single or even multiple connected IP networks that are all under the same administrative domain or cooperating domains. It is thus assumed that these controlled networks are traffic engineered and manage congestion through external means. Deploying SFC over the Internet and hence the use of UDP to carry NSH over the Internet is out of scope for this draft. NSH/UDP applicability is close to that of MPLS/UDP (RFC 7510). As a lot of= things were learned in working on that RFC, I strongly recommend reading RFC 7510 and aligning with it on UDP-related topics (e.g., congestion control and IP= v6 zero checksums) to the extent reasonable (e.g., the NSH/UDP draft should cite RFC 7510). While the rfc5405bis draft provides some guidelines on what to do (which are important, and that draft should continue to be cited), RFC 7510 is a worked example in the same design space as NSH/UDP. To the extent that NSH/UDP diverges significantly from what RFC 7510 specifies on UDP-related topics, there should be very good reasons for doing so (IMNSHO)= . Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Surendra Kumar > (smkumar) > Sent: Thursday, February 11, 2016 7:09 PM > To: sfc@ietf.org > Cc: tsvwg@ietf.org; draft-kumar-sfc-nsh-udp-transport@tools.ietf.org > Subject: [tsvwg] FW: New Version Notification for draft-kumar-sfc-nsh-udp= - > transport-02.txt >=20 > Hello All, >=20 > We published -02 version of the UDP transport draft for NSH based on the > feedback we received from David Black and others. >=20 > In particular, it aligns with the usage guidelines in I-D.ietf-tsvwg-rfc5= 405bis > version-07 w.r.t congestion control, security and other considerations. >=20 > Your feedback on the draft is very much appreciated. >=20 > Regards, > nsh-udp draft co-authors > PS: Home for this draft is still being hashed out. >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, February 11, 2016 12:11 PM > To: Walter Haeffner ; Rajeev Manur > ; Larry Kreeger (kreeger) ; > Surendra Kumar (smkumar) ; Surendra Kumar (smkumar) > ; David T. Melman ; Sumandra > Majee ; David Melman ; Larry > Kreeger (kreeger) > Subject: New Version Notification for draft-kumar-sfc-nsh-udp-transport-0= 2.txt >=20 >=20 > A new version of I-D, draft-kumar-sfc-nsh-udp-transport-02.txt > has been successfully submitted by Surendra Kumar and posted to the IETF > repository. >=20 > Name: draft-kumar-sfc-nsh-udp-transport > Revision: 02 > Title: UDP Transport for Network Service Header > Document date: 2016-02-11 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-= udp- > transport-02.txt > Status: https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-= transport/ > Htmlized: https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-trans= port-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-nsh-u= dp-transport- > 02 >=20 > Abstract: > This draft describes the transport encapsulation to carry Network > Service Header (NSH) over UDP transport protocol. This enables > applications and services using NSH to communicate over a simple > layer-3 network without topological constraints. It brings down the > barrier to deploy NSH by not requiring additional overhead as is > typical of overlay encapsulation mechanisms designed on top of UDP. >=20 > As a first benefit, this method eases the deployment of Service > Function Chaining (SFC) by allowing SFC components to utilize the > basic UDP/IP stack available in virtually all network elements and > end systems to setup the virtual network and realize Service Function > Chains (SFCs). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Wed Feb 17 22:21:52 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3313C1B2D4B; Wed, 17 Feb 2016 22:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F885Zc3C5d_9; Wed, 17 Feb 2016 22:21:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147221A88F5; Wed, 17 Feb 2016 22:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5311; q=dns/txt; s=iport; t=1455776509; x=1456986109; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5grIGUjJHAoq5KIk08JEtWYaFPf4lMjjvy+vBDi8zn8=; b=XSNFjHMq7DhybdDlBJKLK5bEe3okHVbzVz7k2gBrXTup6Z14nBDgAOFE 3XFp1SecdiBwWfW8qP923U1qgGWJZ5Qe+9cpqBaqHFVTopyrJnGmeCxy+ m8DotYrng3sUk5jMPL4zMrChveqJielRI4fn6coFUyQlkCQk9nhFmT3MC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAPYsVW/4MNJK1egzpSbQa5dgENg?= =?us-ascii?q?WchhWwCgVw4FAEBAQEBAQFkJ4RBAQEBBDo9AgwEAgEIEQQBAR8JBzIUCQgCBAE?= =?us-ascii?q?NBQiIEg67YAEBAQEBAQEBAQEBAQEBAQEBAQEBARWKTYQ7hDQFjSqFSYQRAYVSh?= =?us-ascii?q?3+BY0qDeYMlhS+DVYIciFUBHgEBQoNjaodEfAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,464,1449532800"; d="scan'208";a="74375176" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2016 06:21:47 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1I6LlTK007971 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Feb 2016 06:21:47 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 18 Feb 2016 00:21:47 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Thu, 18 Feb 2016 00:21:49 -0600 From: "Surendra Kumar (smkumar)" To: "Black, David" , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt Thread-Index: AQHRZQhY9c88+3ynwkOLHr9c9z3LPJ8nh70QgAljE3CAAG9mwA== Date: Thu, 18 Feb 2016 06:21:48 +0000 Message-ID: References: <20160211201106.3882.86407.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.73.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tsvwg@ietf.org" , "draft-kumar-sfc-nsh-udp-transport@tools.ietf.org" Subject: Re: [sfc] New Version Notification for draft-kumar-sfc-nsh-udp-transport-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 06:21:51 -0000 David, Many thanks for the comments again. We will certainly review RFC7510 and update as needed. Will also look forward to any other comments you may have. Surendra. -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Wednesday, February 17, 2016 3:38 PM To: Surendra Kumar (smkumar) ; sfc@ietf.org Cc: tsvwg@ietf.org; draft-kumar-sfc-nsh-udp-transport@tools.ietf.org Subject: RE: New Version Notification for draft-kumar-sfc-nsh-udp-transport= -02.txt Hi Surendra, While I'll need to read the NSH/UDP draft in detail, I'll supply one quick = comment. Based on this text in Section 1.1 of the NSH/UDP draft: NSH and more broadly SFC, in its initial specification, targets only a single administrative domain and falls into the applicability type 2: controlled environment. It is assumed that SFC is deployed over a single or even multiple connected IP networks that are all under the same administrative domain or cooperating domains. It is thus assumed that these controlled networks are traffic engineered and manage congestion through external means. Deploying SFC over the Internet and hence the use of UDP to carry NSH over the Internet is out of scope for this draft. NSH/UDP applicability is close to that of MPLS/UDP (RFC 7510). As a lot of= things were learned in working on that RFC, I strongly recommend reading R= FC 7510 and aligning with it on UDP-related topics (e.g., congestion contro= l and IPv6 zero checksums) to the extent reasonable (e.g., the NSH/UDP draf= t should cite RFC 7510). While the rfc5405bis draft provides some guidelines on what to do (which ar= e important, and that draft should continue to be cited), RFC 7510 is a wor= ked example in the same design space as NSH/UDP. To the extent that NSH/UD= P diverges significantly from what RFC 7510 specifies on UDP-related topics= , there should be very good reasons for doing so (IMNSHO). Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Surendra=20 > Kumar > (smkumar) > Sent: Thursday, February 11, 2016 7:09 PM > To: sfc@ietf.org > Cc: tsvwg@ietf.org; draft-kumar-sfc-nsh-udp-transport@tools.ietf.org > Subject: [tsvwg] FW: New Version Notification for=20 > draft-kumar-sfc-nsh-udp- transport-02.txt >=20 > Hello All, >=20 > We published -02 version of the UDP transport draft for NSH based on=20 > the feedback we received from David Black and others. >=20 > In particular, it aligns with the usage guidelines in=20 > I-D.ietf-tsvwg-rfc5405bis > version-07 w.r.t congestion control, security and other considerations. >=20 > Your feedback on the draft is very much appreciated. >=20 > Regards, > nsh-udp draft co-authors > PS: Home for this draft is still being hashed out. >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, February 11, 2016 12:11 PM > To: Walter Haeffner ; Rajeev Manur=20 > ; Larry Kreeger (kreeger) ;=20 > Surendra Kumar (smkumar) ; Surendra Kumar (smkumar)=20 > ; David T. Melman ; Sumandra=20 > Majee ; David Melman ; Larry=20 > Kreeger (kreeger) > Subject: New Version Notification for=20 > draft-kumar-sfc-nsh-udp-transport-02.txt >=20 >=20 > A new version of I-D, draft-kumar-sfc-nsh-udp-transport-02.txt > has been successfully submitted by Surendra Kumar and posted to the=20 > IETF repository. >=20 > Name: draft-kumar-sfc-nsh-udp-transport > Revision: 02 > Title: UDP Transport for Network Service Header > Document date: 2016-02-11 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-= udp- > transport-02.txt > Status: https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-= transport/ > Htmlized: https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-trans= port-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-kumar-sfc-nsh-u= dp-transport- > 02 >=20 > Abstract: > This draft describes the transport encapsulation to carry Network > Service Header (NSH) over UDP transport protocol. This enables > applications and services using NSH to communicate over a simple > layer-3 network without topological constraints. It brings down the > barrier to deploy NSH by not requiring additional overhead as is > typical of overlay encapsulation mechanisms designed on top of UDP. >=20 > As a first benefit, this method eases the deployment of Service > Function Chaining (SFC) by allowing SFC components to utilize the > basic UDP/IP stack available in virtually all network elements and > end systems to setup the virtual network and realize Service Function > Chains (SFCs). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat From nobody Thu Feb 18 11:17:46 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D80F71B2C32; Thu, 18 Feb 2016 11:17:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218191745.13999.59292.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 11:17:45 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-oam-framework-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:17:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Service Function Chaining Operation, Administration and Maintenance Framework Authors : Sam K. Aldrin Ram Krishnan Nobo Akiya Carlos Pignataro Anoop Ghanwani Filename : draft-ietf-sfc-oam-framework-01.txt Pages : 10 Date : 2016-02-18 Abstract: This document provides reference framework for Operations, Administration and Maintenance (OAM) for Service Function Chaining (SFC). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 18 11:21:31 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAA01A0383 for ; Thu, 18 Feb 2016 11:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw-uUB4OXWoU for ; Thu, 18 Feb 2016 11:21:28 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F701B2ED1 for ; Thu, 18 Feb 2016 11:21:08 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id b35so44655767qge.0 for ; Thu, 18 Feb 2016 11:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=3utjc5+IftQXD/tBCSuXJ9fa5v3IPbiwK6hA6BaExt8=; b=Fmna4HFTAEB1HWSi+l/Sb9mPfB94A4zi6NTKHFYmIK2d2K6yANS2opgT6/7rpsFDNw pBXebNXg7Gs10UjtH5V2JtZE5fG3vlaGTnnkR8WSEX6wxLtfjm6KnQ0XmgC/myPr+aQ9 RVBuAczUn73mp12DaR3zDk2s7HtgGyncdXHb/0XDqHS76ZaNMlBUGsi6UyYPRGrWzgJw rcDZNRoRA2VktEk8/57WtOmMwxS0AjiDvu2PzX5hnn3Xllrr9kgvDY6Pkgei2jnmozU0 4LIX4AM1Djl8qgHkhZc27QWTeqaAobB3Rx6KEHqalpEzNtmDHO242gPWPgfKbOJAUTKh 6Ekw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3utjc5+IftQXD/tBCSuXJ9fa5v3IPbiwK6hA6BaExt8=; b=A0agVryC+HCoqj9k9FGkvFAIO3cysrxc8+iYkjyFv0BatMqpEXUubPwO//jyon6bND Chvti1AlwVVoGy7HI7XSSVW/M4j63g8zlaqbokTmVxHTgw7vKNjsi6qgdjvGaZ6TyzFT o9wph0+LhAgqho3cDJC8ASSJN+7hFj0GkdrYf3Ji4M7HsMziwhg+i92w0xLV74gdIB9k 8h7qvzF9KH8AoNyxB1xqj2sVINi9eK+Ao1XLfBf104Pvjk4KkL/H4jPzAM989HNSi/Ox JrWZ+zL/ow2ENz7daQZWwJhMO+Xa13e7quC56yyG3yPGCubGCgAfr8nYsXagAgO0nW1N J1wQ== X-Gm-Message-State: AG10YOQAW1Br/17oYZK0Vz6TCLNSBsSp7h7zEgwNPBwgNQg16v91I6qtLNbBo1MPbbd8wOgHEGeBnRlY9qpD3Q== MIME-Version: 1.0 X-Received: by 10.140.144.83 with SMTP id 80mr11479864qhq.102.1455823267483; Thu, 18 Feb 2016 11:21:07 -0800 (PST) Sender: ghanwani@gmail.com Received: by 10.55.8.7 with HTTP; Thu, 18 Feb 2016 11:21:07 -0800 (PST) In-Reply-To: <20160218191745.13999.59292.idtracker@ietfa.amsl.com> References: <20160218191745.13999.59292.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 11:21:07 -0800 X-Google-Sender-Auth: v7qjqmSo8Rs2J5yGr8W1Ta0uV-A Message-ID: From: Anoop Ghanwani To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a11354320b6d7c0052c104477 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-oam-framework-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:21:30 -0000 --001a11354320b6d7c0052c104477 Content-Type: text/plain; charset=UTF-8 This is simply a date refresh to keep the document active. We need to update the document based on comments received from the WG during the call of adoption. http://www.ietf.org/mail-archive/web/sfc/current/msg03681.html Anoop On Thu, Feb 18, 2016 at 11:17 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining of the IETF. > > Title : Service Function Chaining Operation, > Administration and Maintenance Framework > Authors : Sam K. Aldrin > Ram Krishnan > Nobo Akiya > Carlos Pignataro > Anoop Ghanwani > Filename : draft-ietf-sfc-oam-framework-01.txt > Pages : 10 > Date : 2016-02-18 > > Abstract: > This document provides reference framework for Operations, > Administration and Maintenance (OAM) for Service Function > Chaining (SFC). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-oam-framework-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-oam-framework-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a11354320b6d7c0052c104477 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is simply a date refresh to keep the document active.= =C2=A0 We need to update the document based on comments received from the W= G during the call of adoption.
http://www.ietf.org/mail-archive/web/sfc= /current/msg03681.html

Anoop

On Thu, = Feb 18, 2016 at 11:17 AM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Service Function Chaining of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Service Function Chaining Operation, Administration and Maintenance Framew= ork
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Sam = K. Aldrin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ram Krishnan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Nobo Akiya
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Carlos Pignataro
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anoop Ghanwani
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sfc-oam-framework-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-02-18

Abstract:
=C2=A0 =C2=A0This document provides reference framework for Operations,
=C2=A0 =C2=A0Administration and Maintenance (OAM) for Service Function
=C2=A0 =C2=A0Chaining (SFC).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft= -ietf-sfc-oam-framework/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sf= c-oam-framework-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-sfc-oam-framework-01


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

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

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

--001a11354320b6d7c0052c104477-- From nobody Mon Feb 22 09:06:11 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD381A00B0 for ; Mon, 22 Feb 2016 09:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TRNFER=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cxfC3EV8R-r for ; Mon, 22 Feb 2016 09:06:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A7B1A017C for ; Mon, 22 Feb 2016 09:06:07 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id C22A0EA36998 for ; Mon, 22 Feb 2016 17:06:02 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1MH65vc015833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Feb 2016 17:06:05 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1MH65s6015036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Feb 2016 18:06:05 +0100 Received: from [135.224.194.238] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 22 Feb 2016 18:06:04 +0100 Message-ID: <56CB3FFC.9000802@alcatel-lucent.com> Date: Mon, 22 Feb 2016 18:06:04 +0100 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> X-Forwarded-Message-Id: <56CB3E3E.6080602@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: [sfc] Fwd: [bess] Poll for adoption: draft-fm-bess-service-chaining-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: BESS List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 17:06:09 -0000 WG, this is a heads-up on a poll for adoption we have just initiated in BESS. Please post your comments on the BESS WG list. Thanks -m -------- Message transféré -------- Sujet : [bess] Poll for adoption: draft-fm-bess-service-chaining-02 Date : Mon, 22 Feb 2016 17:58:38 +0100 De : EXT Martin Vigoureux Pour : bess@ietf.org Copie à : draft-fm-bess-service-chaining@tools.ietf.org Hello working group, This email starts a two-week poll on adopting draft-fm-bess-service-chaining-02 [1] as a working group Document. Please state on the list if you support adoption or not (in both cases, please also state the reasons). This poll runs until *the 7th of March*. Note that IPR has been disclosed against an earlier version of this document: https://datatracker.ietf.org/ipr/2284/ Yet, we are *coincidentally* also polling for knowledge of any other IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). ==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Martin & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Fri Feb 26 13:26:08 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D681B30AA for ; Fri, 26 Feb 2016 13:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9l6r_AqpQfT for ; Fri, 26 Feb 2016 13:26:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB031B3095 for ; Fri, 26 Feb 2016 13:26:05 -0800 (PST) Received: from localhost ([::1]:59053 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZPtj-000065-KI; Fri, 26 Feb 2016 13:26:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:26:03 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/1#comment:1 Message-ID: <082.48dadf91b586119c3032304ad120c4e9@tools.ietf.org> References: <067.854b9432f4a1a69fe89a18812cb3d2ab@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <067.854b9432f4a1a69fe89a18812cb3d2ab@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226212605.2BB031B3095@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:26:05 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #1 (nsh): Add a new field to include the SFC Identifier X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:26:06 -0000 #1: Add a new field to include the SFC Identifier Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: The current NSH draft specifies a pathID, this has proven simple and viable to implement. Implementation may (and do) utilize that pathID to represent an abstract or specific path. If further specificity is desired, the NSH metadata may be used to carry other path information. I do not plan to update the draft, given that there is no WG consensus for any changes. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:26:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8371B30B3 for ; Fri, 26 Feb 2016 13:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59vf-OMZ0TQJ for ; Fri, 26 Feb 2016 13:26:56 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4131B30B4 for ; Fri, 26 Feb 2016 13:26:56 -0800 (PST) Received: from localhost ([::1]:59130 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZPuY-0004Yf-Jt; Fri, 26 Feb 2016 13:26:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:26:54 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/2#comment:2 Message-ID: <082.fecfa59c6d961f2db0c0ec3de770d99d@tools.ietf.org> References: <067.d9de1b008ffa635f50f33ae8427da5ce@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <067.d9de1b008ffa635f50f33ae8427da5ce@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226212656.9C4131B30B4@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:26:56 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #2 (nsh): Remove "MD Type" field and the companion "MD-type 1" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:26:57 -0000 #2: Remove "MD Type" field and the companion "MD-type 1" Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: Reply: Having the ability specify formats for NSH has proven very useful. This was raised on on list and there was no consensus for change, I recommend this item be marked as resolved in the tracker. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:27:33 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B732A1B30AF for ; Fri, 26 Feb 2016 13:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JATU8PYoBiAk for ; Fri, 26 Feb 2016 13:27:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6961B30AD for ; Fri, 26 Feb 2016 13:27:30 -0800 (PST) Received: from localhost ([::1]:59180 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZPv7-0007g5-9U; Fri, 26 Feb 2016 13:27:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:27:29 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/3#comment:2 Message-ID: <082.793c209f6bcc9c774ecb42cd104a5480@tools.ietf.org> References: <067.9c65f9ec41260d7f098b9c209486a5bb@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <067.9c65f9ec41260d7f098b9c209486a5bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226212730.4F6961B30AD@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:27:30 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #3 (nsh): Critical Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:27:31 -0000 #3: Critical Metadata Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: Reply: it is unclear what suggested action is being requested. If further clarification of critical metadata in required, text can be added to the draft, subject to WG review. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:42:23 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AF1B3109 for ; Fri, 26 Feb 2016 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_7Nmgt6BhoW for ; Fri, 26 Feb 2016 13:42:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DE31B3106 for ; Fri, 26 Feb 2016 13:42:21 -0800 (PST) Received: from localhost ([::1]:33193 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZQ9T-0002S4-KD; Fri, 26 Feb 2016 13:42:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:42:19 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/4#comment:2 Message-ID: <082.0e88669a7a0e57dbff78b6b891875fb0@tools.ietf.org> References: <067.2e537206d49515dea942156a26002995@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <067.2e537206d49515dea942156a26002995@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226214221.A1DE31B3106@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:42:21 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #4 (nsh): Reuse the IPFIX registry for identifying context types X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:42:22 -0000 #4: Reuse the IPFIX registry for identifying context types Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: Reply: The 400+ IPFIX information elements were created for a protocol for IP Flow Information Export, and thus it would not be optimal to reuse as there are many unneeded things. Consensus seems to want to prioritize precision over blind reuse. I do not plan to update the draft and suggest that this item be marked as resolved in the tracker. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:43:13 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD561B310A for ; Fri, 26 Feb 2016 13:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD_5DpurwkXr for ; Fri, 26 Feb 2016 13:43:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2911B310E for ; Fri, 26 Feb 2016 13:43:11 -0800 (PST) Received: from localhost ([::1]:33303 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZQAH-00053j-Ur; Fri, 26 Feb 2016 13:43:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:43:09 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/5#comment:2 Message-ID: <082.f63cc08f3756e8c9a5192a2a730a45f6@tools.ietf.org> References: <067.0b825595ee908d21484db6241f4365fa@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <067.0b825595ee908d21484db6241f4365fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226214311.2D2911B310E@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:43:11 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #5 (nsh): Support of SF Spirals X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:43:12 -0000 #5: Support of SF Spirals Changes (by paulq@cisco.com): * status: new => closed * resolution: => invalid Comment: Reply: This was answered on the list: http://www.ietf.org/mail- archive/web/sfc/current/msg03188.html and therefore no changes are needed. Given that, this item can be marked as resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: invalid Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:43:39 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B657F1B3119 for ; Fri, 26 Feb 2016 13:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX-KtGW5WZpB for ; Fri, 26 Feb 2016 13:43:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D431B3116 for ; Fri, 26 Feb 2016 13:43:36 -0800 (PST) Received: from localhost ([::1]:33367 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZQAi-0005d7-CT; Fri, 26 Feb 2016 13:43:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:43:36 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/6#comment:1 Message-ID: <082.d987d3daaa86c0b6ea9dac155fde49b7@tools.ietf.org> References: <067.24f7ef0bb98de131151711a2cbc27822@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <067.24f7ef0bb98de131151711a2cbc27822@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226214336.A5D431B3116@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:43:36 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #6 (nsh): Version Handling X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:43:37 -0000 #6: Version Handling Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: Reply: Discussed on list: http://www.ietf.org/mail- archive/web/sfc/current/msg03149.html. There was no consensus to changed the adopted format, in fact the value of version bits seems well accepted and therefore no changes are needed and the topic should be marked as resolved in the tracker. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:44:24 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4131B311E for ; Fri, 26 Feb 2016 13:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqmEOWje3ALR for ; Fri, 26 Feb 2016 13:44:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A271B3117 for ; Fri, 26 Feb 2016 13:44:21 -0800 (PST) Received: from localhost ([::1]:33443 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZQBR-0007M7-Ja; Fri, 26 Feb 2016 13:44:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:44:21 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/7#comment:1 Message-ID: <082.92049a9d0a1d31cc3f4f386a35e78181@tools.ietf.org> References: <067.c91a7cdd5d0c0d845958971641d0fe5a@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <067.c91a7cdd5d0c0d845958971641d0fe5a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226214421.D5A271B3117@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:44:21 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #7 (nsh): reserved bits X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:44:23 -0000 #7: reserved bits Changes (by paulq@cisco.com): * status: new => closed * resolution: => worksforme Comment: Reply: This text seems like a helpful clarification. Barring objection, it can be added to the draft. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: worksforme Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:44:55 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8A1B3122 for ; Fri, 26 Feb 2016 13:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzMuiFyiZXsn for ; Fri, 26 Feb 2016 13:44:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE251B311D for ; Fri, 26 Feb 2016 13:44:52 -0800 (PST) Received: from localhost ([::1]:33500 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZQBw-00005e-Iy; Fri, 26 Feb 2016 13:44:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:44:52 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/8#comment:1 Message-ID: <082.c2a010f0a48cdbb0593ffde6bf8266eb@tools.ietf.org> References: <067.a577405664bcb265357d8521442ca3b1@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <067.a577405664bcb265357d8521442ca3b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226214452.DFE251B311D@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:44:52 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #8 (nsh): Use cases X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:44:54 -0000 #8: Use cases Changes (by paulq@cisco.com): * status: new => closed * resolution: => worksforme Comment: Reply: NSH and the use case draft seem consistent. However, it would be helpful for the use case drafts to reference the allocations drafts, and vice versa to provide a consistent view for readers. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: worksforme Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Fri Feb 26 13:45:18 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7593B1B311B for ; Fri, 26 Feb 2016 13:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjENN2vswJGr for ; Fri, 26 Feb 2016 13:45:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639461B3125 for ; Fri, 26 Feb 2016 13:45:15 -0800 (PST) Received: from localhost ([::1]:33554 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aZQCJ-0000ps-2T; Fri, 26 Feb 2016 13:45:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com X-Trac-Project: sfc Date: Fri, 26 Feb 2016 21:45:15 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/10#comment:1 Message-ID: <082.7faf2f0b4545924030d740d19fcb524f@tools.ietf.org> References: <067.78e3cad1267e838836b8aa31364bf52f@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <067.78e3cad1267e838836b8aa31364bf52f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160226214515.639461B3125@ietfa.amsl.com> Resent-Date: Fri, 26 Feb 2016 13:45:15 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #10 (nsh): O bit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:45:17 -0000 #10: O bit Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: Reply: The current version of the draft states: "A short reference is included below, RFC 7498 [RFC7498], provides a more comprehensive review of the SFC Problem Statement." That seems like a reasonable approach, and propose marking this item as resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Sun Feb 28 22:02:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D4C1B2CC4 for ; Sun, 28 Feb 2016 22:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa3YKNdkNMet for ; Sun, 28 Feb 2016 22:02:55 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2CE1B2CC2 for ; Sun, 28 Feb 2016 22:02:55 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id n186so33150346wmn.1 for ; Sun, 28 Feb 2016 22:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:reply-to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=kEbZBqS3HmkgGWjPAjnzemddkQZwS+C0sWHvisbBKWY=; b=aSxDahdt8KRaDATPH30+2f2pWKCrJ7YdfLzp7TjTHmeBDAhhoCFcQZwMMrmO5TgOIE gvxmcdqp952Vb6uVMejEwAI2VCIBo1EVGtFOAIHwqf+pn6UCcUYMA2wRwSfa7NKgUPAN OQMLKErlpzJDEhLYLVjL0+ELY5kpRKkkyzIwpNFuSoNA2GbcwSZOLBwYDYOS47A0ftnP 9DJBXOUl7JUZPOhgIHBXpziFPcsaRYZrhq1EU+3S8UAwyO4SWTK7mZF6jZpizb2Oh2EZ cUO4IB4sTFKgdwwINbTaPEu/0Po6Ct1+innK9piIdzLUL5uUK50ExRNHA6JsfjBWDgHX MEBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:reply-to:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=kEbZBqS3HmkgGWjPAjnzemddkQZwS+C0sWHvisbBKWY=; b=DyaI6FRJWWr51lsdwCV/LhPatt+8nPw1E4lIq1tvDKq8LdQT/kj7pe1HjRkE7ujjtN i9mot5dw8gLsbp+eHExJsOsGlyfVlwFZ8Ywq0WqMUl2gdX6RnycsVxC5WJXFhXAcrprs OUjbfA29I+SPZOBvj9ePV1Cz5t3QBEEIDJhpbmfZE8VqW/efLSEYeul4JmdR+2h84r17 Ek/MbYWn8FBeR25ansJajFxiGhAgqAlFm7iJDp0dDegjfThEIMKYeNp4TLjS43X/E8zc kSQxB3JZuNMW0wsydqX+vNPWK957zdSh+xEBWC7bBmPu3n5YjXBg+NhL5OMCUpQxsMs3 PXTg== X-Gm-Message-State: AD7BkJLuOClEItbpU1N1p+bGrXd8Upnjn26Hej7dJCNux2GBFTZYaEkbJUSE4HfpEit+cw== X-Received: by 10.194.249.42 with SMTP id yr10mr12950210wjc.12.1456725774052; Sun, 28 Feb 2016 22:02:54 -0800 (PST) Received: from fritz.box (p200300061579C6310DDF5DFE456457A8.dip0.t-ipconnect.de. [2003:6:1579:c631:ddf:5dfe:4564:57a8]) by smtp.googlemail.com with ESMTPSA id s66sm14702700wmb.6.2016.02.28.22.02.52 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 22:02:53 -0800 (PST) To: sfc@ietf.org From: Martin Stiemerling Message-ID: <56D3DF0B.8010100@gmail.com> Date: Mon, 29 Feb 2016 07:02:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [sfc] Call for Buenos Aires SFC Agenda Topics X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "sfc-chairs@ietf.org" List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 06:02:57 -0000 Greetings WG: Our meeting in Buenos Aires is fast approaching. As always the goal of the meeting will be to make the best use of our limited face-to-face time. With that in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations that best further the work of the WG, and that generally means focusing on key charter deliverables and topics with important open issues to resolve. When making a request please consider what you think the WG should do with its content – for example: - Does the document have useful content that should be moved into another WG document or progress on its own merit - Does the content have a good basis for one of the WG documents per the charter - Should the document content be merged with one or more other documents, so that a combined document could become a WG document **Please send your request to the SFC chairs until March 10th, 6 am UTC.** The request must include the name of the draft to be presented, time for the presentation requested, and the presenter. Thanks, Jim, Thomas & Martin From nobody Mon Feb 29 07:25:02 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A75421B339C; Mon, 29 Feb 2016 07:23:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160229152335.11664.87880.idtracker@ietfa.amsl.com> Date: Mon, 29 Feb 2016 07:23:35 -0800 Archived-At: X-Mailman-Approved-At: Mon, 29 Feb 2016 07:25:00 -0800 Cc: sfc-chairs@ietf.org, sfc@ietf.org, smccammon@amsl.com, akatlas@gmail.com Subject: [sfc] sfc - Update to a Meeting Session Request for IETF 95 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 15:23:35 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the sfc working group. --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: bess i2rs idr lisp mpls nvo3 rtgwg sdnrg spring tcpinc tsvarea mptcp dtn rmcat tsvwg Special Requests: --------------------------------------------------------- From nobody Mon Feb 29 12:51:21 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9AE1B3BC3 for ; Mon, 29 Feb 2016 12:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDSxJYbAUqXz for ; Mon, 29 Feb 2016 12:51:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B97A1B3BD9 for ; Mon, 29 Feb 2016 12:50:37 -0800 (PST) Received: from localhost ([::1]:46945 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aaUm4-0006Ho-K4; Mon, 29 Feb 2016 12:50:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com X-Trac-Project: sfc Date: Mon, 29 Feb 2016 20:50:36 -0000 X-URL: https://tools.ietf.org/sfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/9#comment:1 Message-ID: <082.b205b32ae1f2cbf88a233de956fba3eb@tools.ietf.org> References: <067.899935ca6705bc1c7b688cce09a8131c@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <067.899935ca6705bc1c7b688cce09a8131c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, paulq@cisco.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-nsh@ietf.org Resent-Message-Id: <20160229205037.4B97A1B3BD9@ietfa.amsl.com> Resent-Date: Mon, 29 Feb 2016 12:50:37 -0800 (PST) Resent-From: trac+sfc@tools.ietf.org Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #9 (nsh): Remove Section 2.2 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:51:20 -0000 #9: Remove Section 2.2 Changes (by paulq@cisco.com): * status: new => closed * resolution: => wontfix Comment: Reply: The current version of the draft states: "A short reference is included below, RFC 7498 [RFC7498], provides a more comprehensive review of the SFC Problem Statement." That seems like a reasonable approach, and propose marking this item as resolved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: nsh | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc