Re: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 26 August 2014 22:47 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 42A281A008F for <sfc@ietfa.amsl.com>; Tue, 26 Aug 2014 15:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.168
X-Spam-Level:
X-Spam-Status: No, score=-15.168 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.668, 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 d-2B-lb04-q8 for <sfc@ietfa.amsl.com>; Tue, 26 Aug 2014 15:47:49 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F741A0030 for <sfc@ietf.org>; Tue, 26 Aug 2014 15:47:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19705; q=dns/txt; s=iport; t=1409093270; x=1410302870; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RTxo5mgY3fLDjucN0JZHPTPPs25Tpa6a2Wf2eaZzDxU=; b=T1uZpUD6+xQWTtSphGh5UC1LQuRUf7NhN60gIG5zWhZYvC0ItW8aOK4K LRQl6+U1F1SqRq/rwcPyB4H+I29t1Tfmys1lnTzesEMOXLXhNRknKW51G fOLyoAw7T9ZNTXv1HGqPG/VxoVY9MfyOhzfnD5u8qyfyUM5kfWrHCsKk+ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFADMO/VOtJV2b/2dsb2JhbABbgmojU00GBATMUAENh0gBgRIWd4QDAQEBAgIBAQEaSgcJAhACAQgRAQIBAigHJwsUAwYIAgQOBQkSiCcBBwW/TxeOahEBPw0EBgEGA4MmgR0FjxmCFIQrhCuCUYEyJpM8g15sAYEOOYEHAQEB
X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208,217";a="350530340"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2014 22:47:40 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7QMlceT024775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <sfc@ietf.org>; Tue, 26 Aug 2014 22:47:38 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 17:47:38 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
Thread-Topic: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt
Thread-Index: AQHPwX+823D98hH+hEyK09QTQQiCow==
Date: Tue, 26 Aug 2014 22:47:37 +0000
Message-ID: <4B25B0E0-F6D5-49A6-BA1C-17B8195038CD@cisco.com>
References: <20140822165913.29275.92328.idtracker@ietfa.amsl.com> <AB349F4E-C2F0-4A87-A77E-262329945FEB@cisco.com> <53FB6D2E.3010202@cisco.com> <CFE7F8D7-6B83-4728-9984-DE47CFA9D8BA@cisco.com> <AB21074A-3769-4493-9AF8-FF44D631E8E7@cisco.com> <5DE5431F-8519-4E8C-8A0B-49465A4A7857@cisco.com>
In-Reply-To: <5DE5431F-8519-4E8C-8A0B-49465A4A7857@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.238.17]
Content-Type: multipart/alternative; boundary="_000_4B25B0E0F6D549A6BA1C17B8195038CDciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vFiOOCFRATtbM7hkMzDPy6PlvUw
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt
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: Tue, 26 Aug 2014 22:47:51 -0000
Naiming, You are right -- this is covered in Section 4.3, under "Terminating SFPs", we can massage the definition some more. THanks, Carlos. On Aug 25, 2014, at 4:47 PM, Naiming Shen <naiming@cisco.com<mailto:naiming@cisco.com>> wrote: On Aug 25, 2014, at 1:36 PM, Naiming Shen <naiming@cisco.com<mailto:naiming@cisco.com>> wrote: Carlos, One of the function of SFF could be to "de-encapsulate" the SFC, it can be the case of the last hop on the SFC list, there may not be any SF associated with the SFF, but only to remove the service transport and NSH header and to forward the packet normally. Otherwise, after the last SF/SFF service function, service header and transport is removed, the packet could route through the original "classifier" device again and it has no information that packet has already gone through the SFC defined. This can cause looping. This of course depends on where the location of the last SFF in the topology. One way to solve this can be to define the SFC last item being the SFF which is the next-hop of the classifier device in normal routing/forwarding to make sure the classifier device will to see this packet in original typo, "… will not see this …" format(without NSH and transport) twice. thanks. - Naiming On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote: Reinaldo, Thanks for the comment, good set of points. It does seem that the definition itself might be unnecessarily overly restrictive. We could say "zero or more" or we could say "typically one or more", but I think it is better to spell out the function. Here's one more comprehensive proposal: Old: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation. New: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as for delivering traffic to a classifier or mapping out traffic to another SFF (in the same or different type of overlay). WG, Reinaldo, Thoughts? Thanks, Carlos. On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <repenno@cisco.com<mailto:repenno@cisco.com>> wrote: A couple of points about SFF definition. You mention "one or more connected service functions" But in our implementation we have two types of SFFs that do not have SFs: - A SFF that maps from one overlay to another, say, VXLAN to GRE - A SFF that only has a classifier (no SFs in itself) Where would they fit or how to to make sure the architecture can predict their usage? thanks, On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote: SFC, Please find below the email notice of a new revision of draft-merged-sfc-architecture. Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02&url1=draft-merged-sfc-architecture-00 We still expect further changes to the document; but we also believe that this revision captures the key points and addresses the key open items, as planned in Toronto. The key objective being to create a single document basis for the SFC architecture. SFC Chairs, We believe that this revision fulfills the next steps agreed in Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf). This revision, while we expect changes, is now close enough that we think it makes sense for the WG to take it as the basis for the WG document to address the deliverable. draft-merged-sfc-architecture-02 addressed the key points -- and we believe is ready to start a poll for adoption. Can you please initiate that WG adoption call for draft-merged-sfc-architecture-02? Thanks, Carlos & Joel. Begin forwarded message: From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> Subject: New Version Notification for draft-merged-sfc-architecture-02.txt Date: August 22, 2014 at 12:59:13 PM EDT To: Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>, Carlos Pignataro <cpignata@cisco.com<mailto:cpignata@cisco.com>>, "Joel M. Halpern" <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>, Carlos Pignataro <cpignata@cisco.com<mailto:cpignata@cisco.com>> A new version of I-D, draft-merged-sfc-architecture-02.txt has been successfully submitted by Carlos Pignataro and posted to the IETF repository. Name: draft-merged-sfc-architecture Revision: 02 Title: Service Function Chaining (SFC) Architecture Document date: 2014-08-22 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt Status: https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/ Htmlized: http://tools.ietf.org/html/draft-merged-sfc-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. This document does not propose solutions, protocols, or extensions to existing protocols. 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<http://tools.ietf.org/>. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org<mailto:sfc@ietf.org> https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Fwd: New Version Notification for draft-mer… Carlos Pignataro (cpignata)
- Re: [sfc] Fwd: New Version Notification for draft… Reinaldo Penno
- Re: [sfc] Fwd: New Version Notification for draft… Carlos Pignataro (cpignata)
- Re: [sfc] Fwd: New Version Notification for draft… Guy Meador III (meadorg)
- Re: [sfc] New Version Notification for draft-merg… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-merg… Guy Meador III (meadorg)
- Re: [sfc] Fwd: New Version Notification for draft… Naiming Shen
- Re: [sfc] Fwd: New Version Notification for draft… Naiming Shen
- Re: [sfc] Fwd: New Version Notification for draft… Reinaldo Penno
- Re: [sfc] Fwd: New Version Notification for draft… Hongyu Li (Julio)
- Re: [sfc] Fwd: New Version Notification for draft… Alla Goldner
- Re: [sfc] New Version Notification for draft-merg… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-merg… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-merg… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-merg… Carlos Pignataro (cpignata)
- Re: [sfc] New Version Notification for draft-merg… Alla Goldner
- Re: [sfc] New Version Notification for draft-merg… Naiming Shen