Re: [bess] draft-fm-bess-service-chaining

"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Wed, 22 July 2015 17:30 UTC

Return-Path: <wim.henderickx@alcatel-lucent.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2885E1A6F32 for <bess@ietfa.amsl.com>; Wed, 22 Jul 2015 10:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.802
X-Spam-Level:
X-Spam-Status: No, score=-5.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 iaCRBl9mqV_h for <bess@ietfa.amsl.com>; Wed, 22 Jul 2015 10:30:11 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A52971B2BD2 for <bess@ietf.org>; Wed, 22 Jul 2015 10:30:10 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 863C4812214A1; Wed, 22 Jul 2015 17:30:05 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MHU8a2007223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 19:30:08 +0200
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 19:30:08 +0200
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "draft-fm-bess-service-chaining@tools.ietf.org" <draft-fm-bess-service-chaining@tools.ietf.org>
Thread-Topic: draft-fm-bess-service-chaining
Thread-Index: AQHQxKQNV8WKoaofxESBkc3VR5ewBw==
Date: Wed, 22 Jul 2015 17:30:06 +0000
Message-ID: <BB0E3655-1585-420B-AD78-7D0904018722@alcatel-lucent.com>
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.150701
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_BB0E36551585420BAD787D0904018722alcatellucentcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/7hL4dI8AX89Z6NXTzO4a22Zm7qI>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] draft-fm-bess-service-chaining
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 17:30:13 -0000

Adding the bess wg

From: Wim Henderickx
Date: Wednesday 22 July 2015 19:24
To: "draft-fm-bess-service-chaining@tools.ietf.org<mailto:draft-fm-bess-service-chaining@tools.ietf.org>"
Subject: draft-fm-bess-service-chaining

While I support to see this work progress I have the following remarks while reading this draft:

  *   The doc is much focussed on the VRF constructions and architecture, but in some use cases we need to program the SF, which is not always clear and we should be a bit more explicit about it in the draft
  *   If a SF is L2 vs L3 we need to program the static NH and IP@ a bit different and we should clarify this
  *   A question I have is if in this architecture a SFF could be shared using the same interface/sub-interface with other service chains or not. Based on this it would also be good to document the things the SFC architecture allows and are supported or not with this proposal.