Re: [sfc] Typo in section 5.5 of merged arch document
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Sun, 07 September 2014 23:55 UTC
Return-Path: <cpignata@cisco.com>
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 B27571A063E for <sfc@ietfa.amsl.com>; Sun, 7 Sep 2014 16:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level:
X-Spam-Status: No, score=-16.152 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=-1.652, 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 XB8JQ9bvtyxh for <sfc@ietfa.amsl.com>; Sun, 7 Sep 2014 16:55:15 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69621A063D for <sfc@ietf.org>; Sun, 7 Sep 2014 16:55:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4032; q=dns/txt; s=iport; t=1410134114; x=1411343714; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bT8vn5NRGJnvqNTDsGhb/pWCsA0BEnXW68TmXCvtK44=; b=mYPHH6Lfn/HLRcmowgSDstZNzHyDhS+MUjpoifiGqPKvqZ0x2BfDKO5M 5So22Zg7Cb6tcIqCp6M0HVs6DBnxVR5ygBFUKsW5XpZ7nUpWgFbbUbwwl xYbeqvcIXkLRijqDJnT26dZEn0OoEHsJ3ZMHlU5VkSpChtmtZvHmsqhdJ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0FADTvDFStJV2d/2dsb2JhbABZgkcjI1NXBMljAQuHSgGBCxZ4hAQBAQQBAQFiCQsQAgEIBA4tBycLFAMOAgQOBYhCAQy7FQETBI9JBAYBgy+BHQWPK4IVhDCHApUsg2FsgUiBBwEBAQ
X-IronPort-AV: E=Sophos; i="5.04,484,1406592000"; d="scan'208,217"; a="75782193"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 07 Sep 2014 23:55:14 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s87NtDvT022532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Sep 2014 23:55:13 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Sun, 7 Sep 2014 18:55:13 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Anil Gunturu <anil.gunturu@riftio.com>
Thread-Topic: [sfc] Typo in section 5.5 of merged arch document
Thread-Index: AQHPyq4mIVlTJs0oo0O+yBPYzac7/5v2rNYA
Date: Sun, 07 Sep 2014 23:55:12 +0000
Message-ID: <9C997479-F40D-46D3-9795-A89810DCCCB8@cisco.com>
References: <D031EE1F.58EE%anil.gunturu@riftio.com>
In-Reply-To: <D031EE1F.58EE%anil.gunturu@riftio.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.215.180]
Content-Type: multipart/alternative; boundary="_000_9C997479F40D46D39795A89810DCCCB8ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nw9PEXoSIuz0KG7CwR4FhzIWPxI
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Typo in section 5.5 of merged arch document
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Sep 2014 23:55:16 -0000
Good catch -- thanks Anil. Carlos. On Sep 7, 2014, at 11:12 AM, Anil Gunturu <anil.gunturu@riftio.com<mailto:anil.gunturu@riftio.com>> wrote: In section 5.5 of https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/?include_text=1, SPF should be SFP to be constant with the terminology. "In the simplest case, where there is only a single function in the SPF (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC. In the cases where the classifier is separate from the single function or a function at the terminal address may need sub-prefix or per-subscriber metadata, a single SPF exists (the metadata changes but the SPF does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4.” -Anil _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Typo in section 5.5 of merged arch document Anil Gunturu
- Re: [sfc] Typo in section 5.5 of merged arch docu… Carlos Pignataro (cpignata)