From nobody Thu Apr 2 12:00:28 2015 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 F18741B2D75 for ; Thu, 2 Apr 2015 12:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tF-s5tWNProX for ; Thu, 2 Apr 2015 12:00:16 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9E41AC442 for ; Thu, 2 Apr 2015 12:00:09 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.178) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Apr 2015 15:00:08 -0400 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, 2 Apr 2015 15:00:07 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: Metadata and inserted packets Thread-Index: AdBtdzvQuvBWj6EySvmspinvcWdx3w== Date: Thu, 2 Apr 2015 19:00:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830BB3E71wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Metadata and inserted packets 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, 02 Apr 2015 19:00:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830BB3E71wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to start a thread on how service functions deal with metadata in N= SH, in particular how an SF might decide what metadata should be added to a= packet it injects. (Issues I raised in Dallas.) I'm starting from the assumption that when an SF injects a packet, it knows= which service path ID and Service Index (and other NSH header fields) shou= ld be used. The semantics of these fields are well defined. However, I'm having trouble with what metadata values should be used. My be= lief is that some semantics must be defined for metadata. This question applies to MD-type 1, in which the semantics of each of the 4= Mandatory Context Headers must be known, as well as the optional fields of= MD-types 1 & 2, where a potentially large set of TLV class/Type must be de= alt with. The MD-type-1 question is probably more easily dealt with by documentation,= although draft-ietf-sfc-nsh-00 does not say enough. I think draft-guichard= -sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-mobility-allocation-00 c= ould define things clearly enough. (For example, what "Source Class" from dc-allocation should be added to inj= ected traffic?) Allow me to put forward some propositions for you to knock down: 1. Meta-data representing a notion of network separation (e.g., tenan= t) must be standardized as such so that traffic does not cross networks. 2. In general, meta-data must not be more specific than a transport s= ession (e.g., TCP or UDP connection). This allows injection of metadata by = cloning exemplar packets of the same flow. 3. If meta-data is more specific than a transport session, all SFs th= at might encounter such meta-data must be aware of the semantics (could be = configured or hard-coded) David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830BB3E71wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to start a thread on how service func= tions deal with metadata in NSH, in particular how an SF might decide what = metadata should be added to a packet it injects.

(Issues I raised in Dallas.)

 

I’m starting from the assumption that when an = SF injects a packet, it knows which service path ID and Service Index (and = other NSH header fields) should be used. The semantics of these fields are = well defined.

 

However, I’m having trouble with what metadata= values should be used. My belief is that some semantics must be defined fo= r metadata.

 

This question applies to MD-type 1, in which the sem= antics of each of the 4 Mandatory Context Headers must be known, as well as= the optional fields of MD-types 1 & 2, where a potentially large set o= f TLV class/Type must be dealt with.

 

The MD-type-1 question is probably more easily dealt= with by documentation, although draft-ietf-sfc-nsh-00 does not say enough.= I think draft-guichard-sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-m= obility-allocation-00 could define things clearly enough.

(For example, what “Source Class” from d= c-allocation should be added to injected traffic?)

 

Allow me to put forward some propositions for you to= knock down:

1.     &= nbsp; Meta-data representing a notion of network separati= on (e.g., tenant) must be standardized as such so that traffic does not cro= ss networks.

2.     &= nbsp; In general, meta-data must not be more specific tha= n a transport session (e.g., TCP or UDP connection). This allows injection = of metadata by cloning exemplar packets of the same flow.

3.     &= nbsp; If meta-data is more specific than a transport sess= ion, all SFs that might encounter such meta-data must be aware of the seman= tics (could be configured or hard-coded)

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830BB3E71wtlexchp2sandvi_-- From nobody Fri Apr 3 01:28:09 2015 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 953091A017F for ; Fri, 3 Apr 2015 01:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 xl9cQvyRx3ar for ; Fri, 3 Apr 2015 01:28:04 -0700 (PDT) Received: from mc26.lon.server.colt.net (mc26.lon.server.colt.net [212.74.77.106]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300441A03A5 for ; Fri, 3 Apr 2015 01:28:02 -0700 (PDT) Received: from mc26.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 100E076247 for ; Fri, 3 Apr 2015 09:28:00 +0100 (BST) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc26.lon.server.colt.net (Postfix) with ESMTPS id CD3427623B for ; Fri, 3 Apr 2015 09:27:59 +0100 (BST) X-IronPort-AV: E=Sophos;i="5.11,516,1422918000"; d="scan'208,217";a="1621817" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.9]) by mx3.qosmos.com with ESMTP; 03 Apr 2015 10:27:59 +0200 Received: from CAROUBIER.jungle.qosmos.com ([169.254.1.132]) by LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4%14]) with mapi id 14.01.0438.000; Fri, 3 Apr 2015 10:27:58 +0200 From: Nicolas BOUTHORS To: "sfc@ietf.org" , "ddolson@sandvine.com" Thread-Topic: Re: [sfc] Metadata and inserted packets, Thread-Index: AdBt47KrXsAxcL7BRteQNjJd9Oecbw== Date: Fri, 3 Apr 2015 08:27:58 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7F4715@CAROUBIER.jungle.qosmos.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D7F4715CAROUBIERjungleqo_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1383-7.6.0.1031-21446.000 X-TM-AS-Result: No--7.455-5.0-31-10 X-imss-scan-details: No--7.455-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-9.0.0.1383-7.6.1031-21446.000 X-TMASE-Result: 10--7.455100-5.000000 X-TMASE-MatchedRID: /77LoUQXvQ/Zfnct5UBzcQwfhKwa9GwDesw8RnBRGwohvFjBsLEZNIoq 0jpAVQEF/cXBCuWBETMO5baMJ3gaWgtgJ854eHwOU+OjsPhIWDiPmFSaq6xM+A6QlBHhBZuwVhb DEH23DRMZZK5fsTIp6CIhtQCwm7ilvDRbzrzaoTU8iGBitgVMxpZ6zKu0q4rtHwn36xCQpqBnKw nYEuaPmLfFNN7R3fHTquSvFq6q+vilVxitbVRsrjOuKcnvvGopCI3p+Ju8mqpb6PBUqmq+Ui+xS /oevUsGOizxfdLIyWA5NrMZPf265B/yubtiMTISma6DzXaohvMpWss5kPUFdFakwmZiZTF81b2D 8ysmq+mALcUfYYwTRrZyZqSpv0X1Z7JaXA6lTKFSD4O3bvc+k2WzwZQ2L6jNvoOlww2PR7TzTu3 5URal5lehZ8JDMoGXaPRqhqPig2MiH63KRFU6CTbN0t/c2qF2MrX+p1uNztAR8rMICe0qkPMxs+ ucp3ZM//nkqRz73/pz3XExg2oeRXupOhUR/AE8e5NWR5iixe294SbmkSVpdAhXVCKc/ywVi+yW9 wFpQ+1/kkUPZznabzYoqz5zxvWSOkqgzcXr71Avj6wHfIGxyeuuKhwJNrcTj4SLcdrJqV3dKUSB W7I322+5ieh24ZYRgDLqnrRlXraNZCyaPpOjcnnN0DN7HnFmlPiBUOW/Iv8Wa6GkobY6kRRXuNq 7FkTTVyiURB/fy4XgQFBX8027dauz1mnU9v63a0/t1l8Wmds66MA2IuOFdqurR2UnSMgMftwZ3X 11IV0= X-TMASE-SNAP-Result: 1.761031.0004-0-1-17:0,12:0 Archived-At: Subject: Re: [sfc] Metadata and inserted packets, 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, 03 Apr 2015 08:28:07 -0000 --_000_76B41B8FACE1514795D30EC137FF391D7F4715CAROUBIERjungleqo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it is a good idea to revisit Metadata. Personally I am concerned wi= th 2 points. 1) The max size of each optional metadata field that can be transporte= d (128 bytes for now) 2) How to "standardize" metadata. Point 1) can be addressed in different ways. The format of of Variable leng= th Context Headers has a 5 bit length, which is quite limiting for some applic= ations. On Point 2) A large set TLV Class will have to be defined, to allow for int= eroperable exchange of Metadata Over SFC. This has already been address in IETF by the IPFIX standard. I s= uggest that we facilitate/enable the use of IPFIX messages as optional meta= data fields. In particular of offline congruent metadata messages. IPFIX is= a well deployed IETF standard, with a large number of TLV Class defines globally and per en= terprise. Allowing IPFIX based metadata field would somewhat address the points rais= ed by David Dolson in his mail. Nicolas >> Allow me to put forward some propositions for you to knock down: >> >> 1. Meta-data representing a notion of network separation (e.g., >> tenant) must be standardized as such so that traffic does not cross >> networks. >> >> 2. In general, meta-data must not be more specific than a transport >> session (e.g., TCP or UDP connection). This allows injection of >> metadata by cloning exemplar packets of the same flow. >> >> 3. If meta-data is more specific than a transport session, all SFs >> that might encounter such meta-data must be aware of the semantics >> (could be configured or hard-coded) >> >> >> >> David Dolson This message and any attachments (the "message") are confidential, intended= solely for the addressees. If you are not the intended recipient, please n= otify the sender immediately by e-mail and delete this message from your sy= stem. In this case, you are not authorized to use, copy this message and/or= disclose the content to any other person. E-mails are susceptible to alter= ation. Neither Qosmos nor any of its subsidiaries or affiliates shall be li= able for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confide= ntiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous ave= z re?u ce message par erreur, merci d'en informer imm?diatement son ?metteu= r par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans = cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/= ou en divulguer le contenu ? un tiers. Tout message ?lectronique est suscep= tible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? a= u titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?. --_000_76B41B8FACE1514795D30EC137FF391D7F4715CAROUBIERjungleqo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it is a good idea to re= visit Metadata. Personally I am concerned with 2 points.

 

1)      The max size of each optional met= adata field that can be transported (128 bytes for now)

2)      How to “standardize” = metadata.

 

Point 1) can be addressed in di= fferent ways. The format of of Variable length

Context Headers has a 5 bit len= gth, which is quite limiting for some applications.

&= nbsp;    

On Point 2) A large set TLV Cla= ss will have to be defined, to allow for interoperable exchange of Metadata=

Over SFC. This has already been= address in IETF by the IPFIX standard.  I suggest that we facilitate/= enable the use of IPFIX messages as optional metadata fields. In particular= of offline congruent metadata messages. IPFIX is a well deployed

IETF standard, with a large num= ber of TLV Class defines globally and per enterprise.

 

Allowing IPFIX based metadata f= ield would somewhat address the points  raised by David Dolson in his mail.

 

Nicolas

     &= nbsp;           &nbs= p; 

>> Allow me to put forwar= d some propositions for you to knock down:

>>

>> 1.  Meta-data rep= resenting a notion of network separation (e.g.,

>> tenant) must be standa= rdized as such so that traffic does not cross

>> networks.

>>

>> 2.  In general, m= eta-data must not be more specific than a transport

>> session (e.g., TCP or = UDP connection). This allows injection of

>> metadata by cloning ex= emplar packets of the same flow.

>>

>> 3.  If meta-data = is more specific than a transport session, all SFs

>> that might encounter s= uch meta-data must be aware of the semantics

>> (could be configured o= r hard-coded)

>>

>> 

>>

>> David Dolson

 

This message and any attachments (the "message") are confidential= , intended solely for the addressees. If you are not the intended recipient= , please notify the sender immediately by e-mail and delete this message fr= om your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any ot= her person. E-mails are susceptible to alteration. Neither Qosmos nor any o= f its subsidiaries or affiliates shall be liable for the message if altered= , changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "me= ssage")sont confidentiels et établis à l'intention exclu= sive de ses destinataires. Si vous avez reçu ce message par erreur, = merci d’en informer immédiatement son émetteur par cour= rier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n= 217;êtes pas autorisé à utiliser, copier ce message et/= ou en divulguer le contenu à un tiers. Tout message électroni= que est susceptible d'altération. Qosmos et ses filiales décl= inent toute responsabilité au titre de ce message s'il a été altéré, d&ea= cute;formé ou falsifié.

--_000_76B41B8FACE1514795D30EC137FF391D7F4715CAROUBIERjungleqo_-- From nobody Tue Apr 7 09:04:21 2015 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 3DD471A909C; Mon, 6 Apr 2015 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 vBbEzaVXiGF7; Mon, 6 Apr 2015 11:25:54 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 682401A908F; Mon, 6 Apr 2015 11:25:54 -0700 (PDT) Received: by iggg4 with SMTP id g4so8377879igg.0; Mon, 06 Apr 2015 11:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P7IfUONHD84I5oiDrktuOlOCL8on5vYdOFDb74WYrlw=; b=w+tC20hF1YOYDWWb7Lu2XPdRly3VDtzAg9Vox9jKW9G5rRR2L3zexyFOZ+xMd/Qpj4 rwhTZBSy0axw5tkpIveAf3YJ2nZLvoCnG9Lx+12Jgf0wEIaC31Rn4l4f8N5rWSDqglGc 9ifI2f0enQFfVb2TqfjyuUGD4ec3zHFTPhT+dM+M6T30o3B6tWIYPJOzCYGFJQK+6ker r6mcITU2Ifp1TedelohaJlCuvcQgWLfH+o8xgS9xlZUhkA06jpcTX3aFWc02CcAFOpNf YEv/RSENFiSykY/uHDjY1zVrVCjMbZS1kMfjODD4fYcnjFMWwEvC0ud4CFMP3FEGuAc6 tUmw== MIME-Version: 1.0 X-Received: by 10.50.79.233 with SMTP id m9mr21859528igx.45.1428344753812; Mon, 06 Apr 2015 11:25:53 -0700 (PDT) Received: by 10.107.52.21 with HTTP; Mon, 6 Apr 2015 11:25:53 -0700 (PDT) In-Reply-To: <550AABAC.9020008@cisco.com> References: <55033E87.3030305@juniper.net> <5503403E.4050304@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CB77@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CBB2@NKGEML512-MBS.china.huawei.com> <2E4BB27CAB87BF43B4207C0E55860F1827D3C5@eusaamb103.ericsson.se> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CCE9@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831CEFD@NKGEML512-MBS.china.huawei.com> <550A2B98.4010409@gmail.com> <95467337-1826-4C9E-888A-ABABE872CD56@cisco.com> <550AABAC.9020008@cisco.com> Date: Mon, 6 Apr 2015 11:25:53 -0700 Message-ID: From: Tony Przygienda To: Stewart Bryant Content-Type: multipart/alternative; boundary=089e0139fffcab1e100513126d2f Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 09:04:19 -0700 Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" , Antoni Przygienda , "IJsbrand Wijnands \(iwijnand\)" , "Jeffrey \(Zhaohui\) Zhang" , Ignas Bagdonas , Xuxiaohu , Eric Rosen Subject: Re: [sfc] [Bier] Encapsulation first nibble 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, 06 Apr 2015 18:25:56 -0000 --089e0139fffcab1e100513126d2f Content-Type: text/plain; charset=UTF-8 As individual contributor: So, hold and below, I refreshed my memory on all the PWE3 architecture and control words and PW and got enlilghtened about the 'heuristical' DPIs and generally me thinks that we cannot use the 4 bits as 'version number' starting at 0 but have to align the 4 bits with the PW CW which already took the 0000 and 0001 while the 4 and 6 are black magic to be avoided. With that I think now Eric makes most sense (while the 0x15 is intriguing as well). So, will BIER be IPv7 ? or IPv8 to leave IPv7 some breathing space ;-) On Thu, Mar 19, 2015 at 3:57 AM, Stewart Bryant wrote: > Re-my last email. > > Aren't learning spell correctors annoying! VCXO was supposed to be > VCCV. Clearly my iPad feels itself to be more closely affiliated to my > radio interests than my PW interests :( > > - Stewart > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --089e0139fffcab1e100513126d2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As individual= contributor:=C2=A0

<= /div>
So, hold and below, I refr= eshed my memory on all the PWE3 architecture and control words and PW and g= ot enlilghtened about the 'heuristical' DPIs and generally me think= s that we cannot use the 4 bits as 'version number' starting at 0 b= ut have to align the 4 bits with the PW CW which already took the 0000 and = 0001 =C2=A0while the 4 and 6 are black magic to be avoided.=C2=A0

With that I think now Eric makes most sense (while the = =C2=A00x15 is intriguing as well). So, will BIER be IPv7 ? =C2=A0or IPv8 to= leave IPv7 =C2=A0some breathing space ;-)=C2=A0

On Thu, Mar 19, 2015 at 3:57 AM,= Stewart Bryant <stbryant@cisco.com> wrote:
Re-my last email.

Aren't learning spell correctors annoying!=C2=A0 VCXO was supposed to b= e
VCCV.=C2=A0 Clearly my iPad feels itself to be more closely affiliated to m= y
radio interests than my PW interests :(

- Stewart



_______________________________________________
BIER mailing list
BIER@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bier

--089e0139fffcab1e100513126d2f-- From nobody Tue Apr 7 11:07:56 2015 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 802131B3937 for ; Tue, 7 Apr 2015 11:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, SPF_PASS=-0.001, 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 kQaMtrBeMkrG for ; Tue, 7 Apr 2015 11:07:52 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E8D1B3936 for ; Tue, 7 Apr 2015 11:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1428430072; x=1459966072; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bB0vC+RWSmKXwXB+6UPJkcPqLRuLmJgCpJgwq1dMFGg=; b=SStxu97AS2NpSRDGrC0mSnCeRklZpnlTf789dIWLnk/8JUsuZDcgFPBF 7pa/WEtHI3Fcnptb6Cn7XBo9aG+bWLi/aBLFfJsYG+Mmon8223Oi3TEWV c3ZAJUnEPHuc9iV66PFBl7nH2QpuMx0DJO4f/ZCqPIfzsMrBqVgEb8waA Y=; X-IronPort-AV: E=Sophos;i="5.11,539,1422921600"; d="scan'208,217";a="156612020" X-IPAS-Result: A2CqBABdHCRV/+sKqMBcgkWBFVwFy0MCgXsBAQEBAQF+hB4BAQEBAy1cAgEIDgMEAQEoBzIUCQgBAQQBEgjUegEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4UCAYQtBYYeqTiEEW+BRH8BAQE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 07 Apr 2015 18:07:23 +0000 Received: from SEAEXCHMBX05.olympus.F5Net.com (192.168.15.227) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Apr 2015 11:07:23 -0700 Received: from SEAEXCHMBX05.olympus.F5Net.com ([fe80::9cc0:5dc7:726d:3b50]) by SEAEXCHMBX05.olympus.F5Net.com ([fe80::9cc0:5dc7:726d:3b50%21]) with mapi id 15.00.1044.021; Tue, 7 Apr 2015 11:07:23 -0700 From: Sunil Vallamkonda To: Dave Dolson , "sfc@ietf.org" Thread-Topic: Metadata and inserted packets Thread-Index: AdBtdzvQuvBWj6EySvmspinvcWdx3wD5AnZw Date: Tue, 7 Apr 2015 18:07:22 +0000 Message-ID: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.com> References: 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: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_25b67d99694b497c9266b2feeb5ec987SEAEXCHMBX05olympusF5Ne_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Metadata and inserted packets 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, 07 Apr 2015 18:07:55 -0000 --_000_25b67d99694b497c9266b2feeb5ec987SEAEXCHMBX05olympusF5Ne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello David, To address below, the metadata would need to be adaptable and scalable acro= ss vendors as TLVs in service chains. I'd suggest a format for TLV metadata : ----------------------------------------------------------------------- | Type | Length | Vendor-ID = | ----------------------------------------------------------------------- | Vendor-Type | Vendor-Length | Attribute-Value | ----------------------------------------------------------------------- Thank you, Sunil From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, April 02, 2015 12:00 PM To: sfc@ietf.org Subject: [sfc] Metadata and inserted packets I'd like to start a thread on how service functions deal with metadata in N= SH, in particular how an SF might decide what metadata should be added to a= packet it injects. (Issues I raised in Dallas.) I'm starting from the assumption that when an SF injects a packet, it knows= which service path ID and Service Index (and other NSH header fields) shou= ld be used. The semantics of these fields are well defined. However, I'm having trouble with what metadata values should be used. My be= lief is that some semantics must be defined for metadata. This question applies to MD-type 1, in which the semantics of each of the 4= Mandatory Context Headers must be known, as well as the optional fields of= MD-types 1 & 2, where a potentially large set of TLV class/Type must be de= alt with. The MD-type-1 question is probably more easily dealt with by documentation,= although draft-ietf-sfc-nsh-00 does not say enough. I think draft-guichard= -sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-mobility-allocation-00 c= ould define things clearly enough. (For example, what "Source Class" from dc-allocation should be added to inj= ected traffic?) Allow me to put forward some propositions for you to knock down: 1. Meta-data representing a notion of network separation (e.g., tenan= t) must be standardized as such so that traffic does not cross networks. 2. In general, meta-data must not be more specific than a transport s= ession (e.g., TCP or UDP connection). This allows injection of metadata by = cloning exemplar packets of the same flow. 3. If meta-data is more specific than a transport session, all SFs th= at might encounter such meta-data must be aware of the semantics (could be = configured or hard-coded) David Dolson Senior Software Architect, Sandvine Inc. --_000_25b67d99694b497c9266b2feeb5ec987SEAEXCHMBX05olympusF5Ne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello David,

 

To address below, the = metadata would need to be adaptable and scalable across vendors as TLVs in = service chains.

I’d suggest a fo= rmat for TLV metadata :

 

----------------------= -------------------------------------------------

|    &n= bsp; Type           =     |     Length    =      |        &= nbsp;Vendor-ID          &= nbsp;         |

----------------------= -------------------------------------------------

|   Vendor-T= ype       |   Vendor-Length  |=    Attribute-Value  |

----------------------= -------------------------------------------------

 

 

Thank you,<= /span>

Sunil

 

From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Dave Dolson
Sent: Thursday, April 02, 2015 12:00 PM
To: sfc@ietf.org
Subject: [sfc] Metadata and inserted packets

 

I’d like to start a thread on how service func= tions deal with metadata in NSH, in particular how an SF might decide what = metadata should be added to a packet it injects.

(Issues I raised in Dallas.)

 

I’m starting from the assumption that when an = SF injects a packet, it knows which service path ID and Service Index (and = other NSH header fields) should be used. The semantics of these fields are = well defined.

 

However, I’m having trouble with what metadata= values should be used. My belief is that some semantics must be defined fo= r metadata.

 

This question applies to MD-type 1, in which the sem= antics of each of the 4 Mandatory Context Headers must be known, as well as= the optional fields of MD-types 1 & 2, where a potentially large set o= f TLV class/Type must be dealt with.

 

The MD-type-1 question is probably more easily dealt= with by documentation, although draft-ietf-sfc-nsh-00 does not say enough.= I think draft-guichard-sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-m= obility-allocation-00 could define things clearly enough.

(For example, what “Source Class” from d= c-allocation should be added to injected traffic?)

 

Allow me to put forward some propositions for you to= knock down:

1.     &= nbsp; Meta-data representing a notion of network separati= on (e.g., tenant) must be standardized as such so that traffic does not cro= ss networks.

2.     &= nbsp; In general, meta-data must not be more specific tha= n a transport session (e.g., TCP or UDP connection). This allows injection = of metadata by cloning exemplar packets of the same flow.

3.     &= nbsp; If meta-data is more specific than a transport sess= ion, all SFs that might encounter such meta-data must be aware of the seman= tics (could be configured or hard-coded)

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_25b67d99694b497c9266b2feeb5ec987SEAEXCHMBX05olympusF5Ne_-- From nobody Tue Apr 7 11:59:55 2015 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 9D7271A90A6 for ; Tue, 7 Apr 2015 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HBkPQBXV_8QF for ; Tue, 7 Apr 2015 11:59:50 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3269C1A90A4 for ; Tue, 7 Apr 2015 11:59:50 -0700 (PDT) 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; Tue, 7 Apr 2015 14:59:49 -0400 From: Dave Dolson To: Sunil Vallamkonda , "sfc@ietf.org" Thread-Topic: Metadata and inserted packets Thread-Index: AdBtdzvQuvBWj6EySvmspinvcWdx3wD5AnZwAAIt0zA= Date: Tue, 7 Apr 2015 18:59:48 +0000 Message-ID: References: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.com> In-Reply-To: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830BBC8FBwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Metadata and inserted packets 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, 07 Apr 2015 18:59:53 -0000 --_000_E8355113905631478EFF04F5AA706E9830BBC8FBwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sunil, How would the SF know the semantics of the metadata with respect to packet = injection? Would you have an out-of-band dictionary that maps vendor/type to the infor= mation? (E.g., "vendor/type 1001/27 is a network separation identifier") The semantics could also be placed in-band, in the form of a fieldd. field values: - network separation metadata - transport flow attribute metadata - source IP metadata - destination IP metadata -Dave From: Sunil Vallamkonda [mailto:sunilvk@f5.com] Sent: Tuesday, April 07, 2015 2:07 PM To: Dave Dolson; sfc@ietf.org Subject: RE: Metadata and inserted packets Hello David, To address below, the metadata would need to be adaptable and scalable acro= ss vendors as TLVs in service chains. I'd suggest a format for TLV metadata : ----------------------------------------------------------------------- | Type | Length | Vendor-ID = | ----------------------------------------------------------------------- | Vendor-Type | Vendor-Length | Attribute-Value | ----------------------------------------------------------------------- Thank you, Sunil From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, April 02, 2015 12:00 PM To: sfc@ietf.org Subject: [sfc] Metadata and inserted packets I'd like to start a thread on how service functions deal with metadata in N= SH, in particular how an SF might decide what metadata should be added to a= packet it injects. (Issues I raised in Dallas.) I'm starting from the assumption that when an SF injects a packet, it knows= which service path ID and Service Index (and other NSH header fields) shou= ld be used. The semantics of these fields are well defined. However, I'm having trouble with what metadata values should be used. My be= lief is that some semantics must be defined for metadata. This question applies to MD-type 1, in which the semantics of each of the 4= Mandatory Context Headers must be known, as well as the optional fields of= MD-types 1 & 2, where a potentially large set of TLV class/Type must be de= alt with. The MD-type-1 question is probably more easily dealt with by documentation,= although draft-ietf-sfc-nsh-00 does not say enough. I think draft-guichard= -sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-mobility-allocation-00 c= ould define things clearly enough. (For example, what "Source Class" from dc-allocation should be added to inj= ected traffic?) Allow me to put forward some propositions for you to knock down: 1. Meta-data representing a notion of network separation (e.g., tenan= t) must be standardized as such so that traffic does not cross networks. 2. In general, meta-data must not be more specific than a transport s= ession (e.g., TCP or UDP connection). This allows injection of metadata by = cloning exemplar packets of the same flow. 3. If meta-data is more specific than a transport session, all SFs th= at might encounter such meta-data must be aware of the semantics (could be = configured or hard-coded) David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830BBC8FBwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sunil,

 

How would the SF know = the semantics of the metadata with respect to packet injection?<= /span>

 

Would you have an out-= of-band dictionary that maps vendor/type to the information?

(E.g., “vendor/t= ype 1001/27 is a network separation identifier”)

 

The semantics could al= so be placed in-band, in the form of a fieldd.

field values:

- network separation m= etadata

- transport flow attri= bute metadata

- source IP metadata

- destination IP metad= ata

 

 

-Dave

 

 

 

From: Sunil Va= llamkonda [mailto:sunilvk@f5.com]
Sent: Tuesday, April 07, 2015 2:07 PM
To: Dave Dolson; sfc@ietf.org
Subject: RE: Metadata and inserted packets

 

Hello David,

 

To address below, the = metadata would need to be adaptable and scalable across vendors as TLVs in = service chains.

I’d suggest a fo= rmat for TLV metadata :

 

----------------------= -------------------------------------------------

|    &n= bsp; Type           =     |     Length    =      |        &= nbsp;Vendor-ID          &= nbsp;         |

----------------------= -------------------------------------------------

|   Vendor-T= ype       |   Vendor-Length  |=    Attribute-Value  |

----------------------= -------------------------------------------------

 

 

Thank you,<= /span>

Sunil

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, April 02, 2015 12:00 PM
To: sfc@ietf.org
Subject: [sfc] Metadata and inserted packets

 

I’d like to start a thread on how service func= tions deal with metadata in NSH, in particular how an SF might decide what = metadata should be added to a packet it injects.

(Issues I raised in Dallas.)

 

I’m starting from the assumption that when an = SF injects a packet, it knows which service path ID and Service Index (and = other NSH header fields) should be used. The semantics of these fields are = well defined.

 

However, I’m having trouble with what metadata= values should be used. My belief is that some semantics must be defined fo= r metadata.

 

This question applies to MD-type 1, in which the sem= antics of each of the 4 Mandatory Context Headers must be known, as well as= the optional fields of MD-types 1 & 2, where a potentially large set o= f TLV class/Type must be dealt with.

 

The MD-type-1 question is probably more easily dealt= with by documentation, although draft-ietf-sfc-nsh-00 does not say enough.= I think draft-guichard-sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-m= obility-allocation-00 could define things clearly enough.

(For example, what “Source Class” from d= c-allocation should be added to injected traffic?)

 

Allow me to put forward some propositions for you to= knock down:

1.       Meta-data representing a notion of network separation (e.g., tenant)= must be standardized as such so that traffic does not cross networks.=

2.       In general, meta-data must not be more specific than a transport ses= sion (e.g., TCP or UDP connection). This allows injection of metadata by cl= oning exemplar packets of the same flow.

3.       If meta-data is more specific than a transport session, all SFs that= might encounter such meta-data must be aware of the semantics (could be co= nfigured or hard-coded)

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_E8355113905631478EFF04F5AA706E9830BBC8FBwtlexchp2sandvi_-- From nobody Tue Apr 7 12:25:05 2015 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 95AFC1B3AF5 for ; Tue, 7 Apr 2015 12:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, SPF_PASS=-0.001, 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 ohcmj8o0BQdU for ; Tue, 7 Apr 2015 12:25:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F961B3B3C for ; Tue, 7 Apr 2015 12:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1428434700; x=1459970700; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=T0RfZve0cxLHvATOlcQgX586cS6/mO20kjKQURob2uY=; b=MM82/rKIfBWLvBETbT6u2znV+Sn5bbcc3UmCiWt3Td9huK3mDlM3YuLG vSQedZml4AmfTYF1+abuXQrKrs041w61QLGvVIHyUal903/zCxYBVL3kP d2WVR7J6oWyE6EghlhIWFmSQ2yXY+L/mCzEdHwLYyoMWYXuUygkZFqrIu M=; X-IronPort-AV: E=Sophos;i="5.11,539,1422921600"; d="scan'208,217";a="156624882" X-IPAS-Result: A2CqBAAGLiRV/+sKqMBcgkWBFVwFy0MCgXsBAQEBAQF+hB4BAQEBAy1cAgEIDgMEAQEoBzIUCQgBAQQBEgjUfwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLK4UCAYQtBYYeqTiEEW+BRH8BAQE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 07 Apr 2015 19:24:59 +0000 Received: from SEAEXCHMBX05.olympus.F5Net.com (192.168.15.227) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Apr 2015 12:24:58 -0700 Received: from SEAEXCHMBX05.olympus.F5Net.com ([fe80::9cc0:5dc7:726d:3b50]) by SEAEXCHMBX05.olympus.F5Net.com ([fe80::9cc0:5dc7:726d:3b50%21]) with mapi id 15.00.1044.021; Tue, 7 Apr 2015 12:24:58 -0700 From: Sunil Vallamkonda To: Dave Dolson , "sfc@ietf.org" Thread-Topic: Metadata and inserted packets Thread-Index: AdBtdzvQuvBWj6EySvmspinvcWdx3wD5AnZwAAIt0zAAAMlr4A== Date: Tue, 7 Apr 2015 19:24:58 +0000 Message-ID: <3e6fe671599d4a9e8789bd6f5bd83c38@SEAEXCHMBX05.olympus.F5Net.com> References: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.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: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_3e6fe671599d4a9e8789bd6f5bd83c38SEAEXCHMBX05olympusF5Ne_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Metadata and inserted packets 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, 07 Apr 2015 19:25:04 -0000 --_000_3e6fe671599d4a9e8789bd6f5bd83c38SEAEXCHMBX05olympusF5Ne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, The vendor dictionary could be OOB from Classifier in control plane as part= of provisioning. The in-band semantics may be restrictive on metadata across vendors and TLV= s, IMHO. Thank you, Sunil From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, April 07, 2015 12:00 PM To: Sunil Vallamkonda; sfc@ietf.org Subject: RE: Metadata and inserted packets Sunil, How would the SF know the semantics of the metadata with respect to packet = injection? Would you have an out-of-band dictionary that maps vendor/type to the infor= mation? (E.g., "vendor/type 1001/27 is a network separation identifier") The semantics could also be placed in-band, in the form of a fieldd. field values: - network separation metadata - transport flow attribute metadata - source IP metadata - destination IP metadata -Dave From: Sunil Vallamkonda [mailto:sunilvk@f5.com] Sent: Tuesday, April 07, 2015 2:07 PM To: Dave Dolson; sfc@ietf.org Subject: RE: Metadata and inserted packets Hello David, To address below, the metadata would need to be adaptable and scalable acro= ss vendors as TLVs in service chains. I'd suggest a format for TLV metadata : ----------------------------------------------------------------------- | Type | Length | Vendor-ID = | ----------------------------------------------------------------------- | Vendor-Type | Vendor-Length | Attribute-Value | ----------------------------------------------------------------------- Thank you, Sunil From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Thursday, April 02, 2015 12:00 PM To: sfc@ietf.org Subject: [sfc] Metadata and inserted packets I'd like to start a thread on how service functions deal with metadata in N= SH, in particular how an SF might decide what metadata should be added to a= packet it injects. (Issues I raised in Dallas.) I'm starting from the assumption that when an SF injects a packet, it knows= which service path ID and Service Index (and other NSH header fields) shou= ld be used. The semantics of these fields are well defined. However, I'm having trouble with what metadata values should be used. My be= lief is that some semantics must be defined for metadata. This question applies to MD-type 1, in which the semantics of each of the 4= Mandatory Context Headers must be known, as well as the optional fields of= MD-types 1 & 2, where a potentially large set of TLV class/Type must be de= alt with. The MD-type-1 question is probably more easily dealt with by documentation,= although draft-ietf-sfc-nsh-00 does not say enough. I think draft-guichard= -sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-mobility-allocation-00 c= ould define things clearly enough. (For example, what "Source Class" from dc-allocation should be added to inj= ected traffic?) Allow me to put forward some propositions for you to knock down: 1. Meta-data representing a notion of network separation (e.g., tenan= t) must be standardized as such so that traffic does not cross networks. 2. In general, meta-data must not be more specific than a transport s= ession (e.g., TCP or UDP connection). This allows injection of metadata by = cloning exemplar packets of the same flow. 3. If meta-data is more specific than a transport session, all SFs th= at might encounter such meta-data must be aware of the semantics (could be = configured or hard-coded) David Dolson Senior Software Architect, Sandvine Inc. --_000_3e6fe671599d4a9e8789bd6f5bd83c38SEAEXCHMBX05olympusF5Ne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 

The vendor dictionary = could be OOB from Classifier in control plane as part of provisioning.=

The in-band semantics = may be restrictive on metadata across vendors and TLVs, IMHO.

 

Thank you,<= /span>

Sunil

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Tuesday, April 07, 2015 12:00 PM
To: Sunil Vallamkonda; sfc@ietf.org
Subject: RE: Metadata and inserted packets

 

Sunil,

 

How would the SF know = the semantics of the metadata with respect to packet injection?<= /span>

 

Would you have an out-= of-band dictionary that maps vendor/type to the information?

(E.g., “vendor/t= ype 1001/27 is a network separation identifier”)

 

The semantics could al= so be placed in-band, in the form of a fieldd.

field values:

- network separation m= etadata

- transport flow attri= bute metadata

- source IP metadata

- destination IP metad= ata

 

 

-Dave

 

 

 

From: Sunil Vallamkonda [mailto:sunilvk@f5.com]
Sent: Tuesday, April 07, 2015 2:07 PM
To: Dave Dolson; sfc@ietf.org Subject: RE: Metadata and inserted packets

 

Hello David,

 

To address below, the = metadata would need to be adaptable and scalable across vendors as TLVs in = service chains.

I’d suggest a fo= rmat for TLV metadata :

 

----------------------= -------------------------------------------------

|    &n= bsp; Type           =     |     Length    =      |        &= nbsp;Vendor-ID          &= nbsp;         |

----------------------= -------------------------------------------------

|   Vendor-T= ype       |   Vendor-Length  |=    Attribute-Value  |

----------------------= -------------------------------------------------

 

 

Thank you,<= /span>

Sunil

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, April 02, 2015 12:00 PM
To: sfc@ietf.org
Subject: [sfc] Metadata and inserted packets

 

I’d like to start a thread on how service func= tions deal with metadata in NSH, in particular how an SF might decide what = metadata should be added to a packet it injects.

(Issues I raised in Dallas.)

 

I’m starting from the assumption that when an = SF injects a packet, it knows which service path ID and Service Index (and = other NSH header fields) should be used. The semantics of these fields are = well defined.

 

However, I’m having trouble with what metadata= values should be used. My belief is that some semantics must be defined fo= r metadata.

 

This question applies to MD-type 1, in which the sem= antics of each of the 4 Mandatory Context Headers must be known, as well as= the optional fields of MD-types 1 & 2, where a potentially large set o= f TLV class/Type must be dealt with.

 

The MD-type-1 question is probably more easily dealt= with by documentation, although draft-ietf-sfc-nsh-00 does not say enough.= I think draft-guichard-sfc-nsh-dc-allocation-01 and draft-napper-sfc-nsh-m= obility-allocation-00 could define things clearly enough.

(For example, what “Source Class” from d= c-allocation should be added to injected traffic?)

 

Allow me to put forward some propositions for you to= knock down:

1.  = ;     Meta-data representing a notion of network separation (e.g., tenant)= must be standardized as such so that traffic does not cross networks.=

2.  = ;     In general, meta-data must not be more specific than a transport ses= sion (e.g., TCP or UDP connection). This allows injection of metadata by cl= oning exemplar packets of the same flow.

3.  = ;     If meta-data is more specific than a transport session, all SFs that= might encounter such meta-data must be aware of the semantics (could be co= nfigured or hard-coded)

 

 

 

David Dolson

Senior Software Architect, Sandvine Inc.<= /p>

 

--_000_3e6fe671599d4a9e8789bd6f5bd83c38SEAEXCHMBX05olympusF5Ne_-- From nobody Tue Apr 7 18:17:42 2015 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 4F31B1B2AE0 for ; Tue, 7 Apr 2015 18:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AFRp9FVC7cYy for ; Tue, 7 Apr 2015 18:17:39 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656461B2AD9 for ; Tue, 7 Apr 2015 18:17:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 426931BD4919; Tue, 7 Apr 2015 18:17:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [189.42.147.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 183F21BD491D; Tue, 7 Apr 2015 18:17:37 -0700 (PDT) Message-ID: <552481AF.6020303@joelhalpern.com> Date: Tue, 07 Apr 2015 21:17:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dave Dolson , Sunil Vallamkonda , "sfc@ietf.org" References: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Metadata and inserted packets 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, 08 Apr 2015 01:17:41 -0000 I would expect that there will need to be application configuration that indicates what metadata type code a given SF should use for communicate what piece of information. This "type" might be a position in the fixed MD-1, or a TLV code in the MD-2. I do not expect that the protocol for provisioning this to service functions is part of SFC, any more than all the other configuration information that applications need to do their job. While I would not be surprised to eventually have a registry of well-known types, I do not see anyw ay to get around needing the configuration information for many service functions which care about metadata. There is just going to be too much variability. I hope that we do not have to put vendor IDs into the types, as the MD-2 TLV already looks to be larger than we like. Yours, Joel On 4/7/15 2:59 PM, Dave Dolson wrote: > Sunil, > > How would the SF know the semantics of the metadata with respect to > packet injection? > > Would you have an out-of-band dictionary that maps vendor/type to the > information? > > (E.g., vendor/type 1001/27 is a network separation identifier) > > The semantics could also be placed in-band, in the form of a fieldd. > > field values: > > - network separation metadata > > - transport flow attribute metadata > > - source IP metadata > > - destination IP metadata > > -Dave > > *From:*Sunil Vallamkonda [mailto:sunilvk@f5.com] > *Sent:* Tuesday, April 07, 2015 2:07 PM > *To:* Dave Dolson; sfc@ietf.org > *Subject:* RE: Metadata and inserted packets > > Hello David, > > To address below, the metadata would need to be adaptable and scalable > across vendors as TLVs in service chains. > > Id suggest a format for TLV metadata : > > ----------------------------------------------------------------------- > > | Type | Length | > Vendor-ID | > > ----------------------------------------------------------------------- > > | Vendor-Type | Vendor-Length | Attribute-Value | > > ----------------------------------------------------------------------- > > Thank you, > > Sunil > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dave Dolson > *Sent:* Thursday, April 02, 2015 12:00 PM > *To:* sfc@ietf.org > *Subject:* [sfc] Metadata and inserted packets > > Id like to start a thread on how service functions deal with metadata > in NSH, in particular how an SF might decide what metadata should be > added to a packet it injects. > > (Issues I raised in Dallas.) > > Im starting from the assumption that when an SF injects a packet, it > knows which service path ID and Service Index (and other NSH header > fields) should be used. The semantics of these fields are well defined. > > However, Im having trouble with what metadata values should be used. My > belief is that some semantics must be defined for metadata. > > This question applies to MD-type 1, in which the semantics of each of > the 4 Mandatory Context Headers must be known, as well as the optional > fields of MD-types 1 & 2, where a potentially large set of TLV > class/Type must be dealt with. > > The MD-type-1 question is probably more easily dealt with by > documentation, although draft-ietf-sfc-nsh-00 does not say enough. I > think draft-guichard-sfc-nsh-dc-allocation-01 and > draft-napper-sfc-nsh-mobility-allocation-00 could define things clearly > enough. > > (For example, what Source Class from dc-allocation should be added to > injected traffic?) > > Allow me to put forward some propositions for you to knock down: > > 1.Meta-data representing a notion of network separation (e.g., tenant) > must be standardized as such so that traffic does not cross networks. > > 2.In general, meta-data must not be more specific than a transport > session (e.g., TCP or UDP connection). This allows injection of metadata > by cloning exemplar packets of the same flow. > > 3.If meta-data is more specific than a transport session, all SFs that > might encounter such meta-data must be aware of the semantics (could be > configured or hard-coded) > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Apr 7 20:01:26 2015 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 ADDCF1B2C15; Tue, 7 Apr 2015 20:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 j7LhjUvxnwpH; Tue, 7 Apr 2015 20:01:21 -0700 (PDT) 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 65DB11B2C14; Tue, 7 Apr 2015 20:01:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRD56760; Wed, 08 Apr 2015 03:01:18 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Apr 2015 04:01:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 8 Apr 2015 11:01:09 +0800 From: Xuxiaohu To: Xuxiaohu , "'Erik Nordmark'" , "nvo3@ietf.org" Thread-Topic: Re: [nvo3] Encapsulation considerations Thread-Index: AdBxodagEeaWbZwEQCSsmj8ZrqiVwQAAXeVA Date: Wed, 8 Apr 2015 03:01:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323576@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] Encapsulation considerations 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, 08 Apr 2015 03:01:22 -0000 T2YgY291cnNlLCBpZiBpdCdzIGFsbG93ZWQgdG8gbWFrZSBhIG1pbm9yIGNoYW5nZSB0byB0aGUg TVBMUyBhcmNoaXRlY3R1cmUgKGkuZS4sIGFkZGluZyBhIHByb3RvY29sIGZpZWxkIGltbWVkaWF0 ZWx5IGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIHRvIGluZGljYXRlIHRoZSBN UExTIHBheWxvYWQgdHlwZSApLCB0aGUgZmlyc3QgbmliYmxlIGlzc3VlIGltcG9zZWQgb24gdGhv c2UgbmV3IGVuY2Fwc3VsYXRpb25zIHdoaWNoIG1heSBiZSB0cmFuc3BvcnRlZCBvdmVyIE1QTFMg d291bGQgZGlzYXBwZWFyIGZvcmV2ZXIuIEZ1cnRoZXJtb3JlLCB0aGUgbmVjZXNzaXR5IG9mIGFs bG9jYXRpbmcgbG9jYWwgbGFiZWxzIGp1c3QgZm9yIHRoZSBwdXJwb3NlIG9mIGluZGljYXRpbmcg dGhvc2UgbmV3IGVuY2Fwc3VsYXRpb25zIChpbWFnaW5lIGhvdyB0byB0cmFuc3BvcnQgTlNIIG92 ZXIgTVBMUykgd291bGQgZGlzYXBwZWFyIGZvcmV2ZXIgYXMgd2VsbC4NCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFv aHUNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwOCwgMjAxNSAxMDoxNSBBTQ0KPiBUbzogJ0Vy aWsgTm9yZG1hcmsnOyBudm8zQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbnZvM10gRW5jYXBz dWxhdGlvbiBjb25zaWRlcmF0aW9ucw0KPiANCj4gSGkgRXJpaywNCj4gDQo+IEFzIGl0IGhhcyBz YWlkIGluIHRoZSBkcmFmdCA6ICIuLi4gV2UgbGF0ZXIgZXhwYW5kZWQgdGhlIHNjb3BlIHNvbWV3 aGF0IHRvDQo+IGNvbnNpZGVyIGhvdyB0aGUgZW5jYXBzdWxhdGlvbnMgd291bGQgcGxheSB3aXRo IE1QTFMgInRyYW5zcG9ydCIsIHdoaWNoIGlzDQo+IGltcG9ydGFudCBiZWNhdXNlIFNGQyBhbmQg QklFUiBzZWVtIHRvIHRhcmdldCBiZWluZyBkZXBlbmRlbnQgb2YgdGhlDQo+IHVuZGVybHlpbmcg InRyYW5zcG9ydCIuLi4iLCBpdCB3b3VsZCBiZSBuZWNlc3NhcnkgdG8gY29uc2lkZXIgdGhlIGZp cnN0IG5pYmJsZQ0KPiBpc3N1ZSBmb3IgdGhvc2UgZW5jYXBzdWxhdGlvbnMgd2hpY2ggbWF5IGJl IHRyYW5zcG9ydGVkIG92ZXIgTVBMUy4gTW9yZQ0KPiBzcGVjaWZpY2FsbHksIGZvciB0aG9zZSBl bmNhcHN1bGF0aW9ucyB3aGljaCBtYXkgYmUgZGlyZWN0bHkgZW5jYXBzdWxhdGVkIGZ1cnRoZXIN Cj4gd2l0aCBhbiBNUExTIGhlYWRlciwgdGhleSBtdXN0IG5vdCBzdGFydCB3aXRoIHRoZSB2YWx1 ZSA0IChJUHY0KSBvciB0aGUgdmFsdWUgNg0KPiAoSVB2NikgaW4gdGhlIGZpcnN0IG5pYmJsZS4g T3RoZXJ3aXNlLCB0aGV5IHdvdWxkIGJlIG1pc3Rha2VubHkgaW50ZXJwcmV0ZWQgYXMgSVANCj4g cGF5bG9hZHMgYnkgdHJhbnNpdCBMU1JzIGFuZCB0aGVyZWZvcmUgYmUgc3ViamVjdGVkIHRvIEVD TVAgYW5kIHBvdGVudGlhbA0KPiBwYWNrZXQgbWlzb3JkZXJpbmcuDQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZy b206IEVyaWsgTm9yZG1hcmsgW21haWx0bzpub3JkbWFya0Bzb25pYy5uZXRdDQo+ID4gU2VudDog MjAxNcTqM9TCMjbI1SA1OjAxDQo+ID4gVG86IG52bzNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBb bnZvM10gRW5jYXBzdWxhdGlvbiBjb25zaWRlcmF0aW9ucw0KPiA+DQo+ID4NCj4gPiBJIHByZXNl bnRlZCBwYXJ0IG9mIHRoaXMgYXQgdGhlIG1vc3QgcmVjZW50IE5WTzMgaW50ZXJpbSBtZWV0aW5n LlRoZQ0KPiA+IGZ1bGwNCj4gMTINCj4gPiBhcmVhcyBvZiBjb25zaWRlcmF0aW9ucyB3aGVyZSBw cmVzZW50ZWQgYXQgUlRHV0cgZWFybGllciB0aGlzIHdlZWsuDQo+ID4gICBUaGUgZHJhZnQgaXMN Cj4gPiAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ydGctZHQtZW5j YXAvDQo+ID4gICBhbmQgdGhlIHNsaWRlcyBhcmUgYXQNCj4gPiAgICBodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItcnRnd2ctOC5wZGYNCj4gPg0KPiA+ IFRoZXJlIGlzIHByb2JhYmx5IGFkZGl0aW9uYWwgdGhpbmdzIGluIHRoZXJlIHRvIGNvbnNpZGVy IGZvciBOVk8zLCBhbmQNCj4gYWR2aWNlDQo+ID4gdGhhdCBjYW4gYmUgcmV1c2VkIHRvIG1ha2Ug aXQgZWFzaWVyIHRvIG1vdmUgTlZPMyBmb3J3YXJkLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiAg ICAgRXJpaw0KPiA+DQo+ID4NCj4gPg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From nobody Wed Apr 8 19:20:38 2015 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 81EA81B2A28; Wed, 8 Apr 2015 19:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 1qYiwCyXgeYn; Wed, 8 Apr 2015 19:20:30 -0700 (PDT) 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 19E9C1B2A27; Wed, 8 Apr 2015 19:20:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUQ26433; Thu, 09 Apr 2015 02:20:27 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Apr 2015 03:20:26 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 9 Apr 2015 10:20:21 +0800 From: Xuxiaohu To: Erik Nordmark , "nvo3@ietf.org" Thread-Topic: [nvo3] Encapsulation considerations Thread-Index: AQHQcljZ0fVc246YHEKvkFIl2pYVuJ1D7uKA Date: Thu, 9 Apr 2015 02:20:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> In-Reply-To: <5525C22C.1030303@acm.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] Encapsulation considerations 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, 09 Apr 2015 02:20:31 -0000 SGkgRXJpaywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmlrIE5v cmRtYXJrIFttYWlsdG86bm9yZG1hcmtAYWNtLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEFwcmls IDA5LCAyMDE1IDg6MDUgQU0NCj4gVG86IFh1eGlhb2h1OyBudm8zQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbbnZvM10gRW5jYXBzdWxhdGlvbiBjb25zaWRlcmF0aW9ucw0KPiANCj4gT24gNC83 LzE1IDc6MTUgUE0sIFh1eGlhb2h1IHdyb3RlOg0KPiA+IEhpIEVyaWssDQo+ID4NCj4gPiBBcyBp dCBoYXMgc2FpZCBpbiB0aGUgZHJhZnQgOiAiLi4uIFdlIGxhdGVyIGV4cGFuZGVkIHRoZSBzY29w ZSBzb21ld2hhdCB0bw0KPiBjb25zaWRlciBob3cgdGhlIGVuY2Fwc3VsYXRpb25zIHdvdWxkIHBs YXkgd2l0aCBNUExTICJ0cmFuc3BvcnQiLCB3aGljaCBpcw0KPiBpbXBvcnRhbnQgYmVjYXVzZSBT RkMgYW5kIEJJRVIgc2VlbSB0byB0YXJnZXQgYmVpbmcgZGVwZW5kZW50IG9mIHRoZQ0KPiB1bmRl cmx5aW5nICJ0cmFuc3BvcnQiLi4uIiwgaXQgd291bGQgYmUgbmVjZXNzYXJ5IHRvIGNvbnNpZGVy IHRoZSBmaXJzdCBuaWJibGUNCj4gaXNzdWUgZm9yIHRob3NlIGVuY2Fwc3VsYXRpb25zIHdoaWNo IG1heSBiZSB0cmFuc3BvcnRlZCBvdmVyIE1QTFMuIE1vcmUNCj4gc3BlY2lmaWNhbGx5LCBmb3Ig dGhvc2UgZW5jYXBzdWxhdGlvbnMgd2hpY2ggbWF5IGJlIGRpcmVjdGx5IGVuY2Fwc3VsYXRlZCBm dXJ0aGVyDQo+IHdpdGggYW4gTVBMUyBoZWFkZXIsIHRoZXkgbXVzdCBub3Qgc3RhcnQgd2l0aCB0 aGUgdmFsdWUgNCAoSVB2NCkgb3IgdGhlIHZhbHVlIDYNCj4gKElQdjYpIGluIHRoZSBmaXJzdCBu aWJibGUuIE90aGVyd2lzZSwgdGhleSB3b3VsZCBiZSBtaXN0YWtlbmx5IGludGVycHJldGVkIGFz IElQDQo+IHBheWxvYWRzIGJ5IHRyYW5zaXQgTFNScyBhbmQgdGhlcmVmb3JlIGJlIHN1YmplY3Rl ZCB0byBFQ01QIGFuZCBwb3RlbnRpYWwNCj4gcGFja2V0IG1pc29yZGVyaW5nLg0KPiANCj4gWGlh b2h1LA0KPiBHb29kIHBvaW50Lg0KPiANCj4gQnV0IEkgY291bGRuJ3QgdGVsbCBmcm9tIHRoZSBl bWFpbHMgb24gdGhlIEJJRVIgbGlzdCB3aGV0aGVyIHRoZSBjb25zdHJhaW50cyBvbiB0aGUNCj4g Zmlyc3QgbmliYmxlIHZhbHVlIGlzIGEgc3RyaWN0IHJlcXVpcmVtZW50IGluIGFsbCBjYXNlcywg b3Igd2hldGhlciBpdCBpcyBjb25kaXRpb25hbA0KPiBvbiBzb21ldGhpbmcgKGFuZCBpZiBzbywg d2hhdCBpcyB0aGUgY29uZGl0aW9uKS4NCg0KVGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhv dWdodCBvZiBpbmNsdWRlOiAxKSB0aGUgZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFj a2V0IG1pc29yZGVyaW5nOyAyKSB0aGUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQg b3ZlciBhbiBNUExTIFBTTjsgMykgTFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRo ZSBjb250ZW50cyBvZiB0aGUgTVBMUyBwYXlsb2FkIHRvIHNlbGVjdCB0aGUgRUNNUCBwYXRoLg0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQoNCj4gT25jZSBJIGtub3cgdGhhdCBhbnN3ZXIgd2Ug Y2FuIGRlZmluaXRlbHkgYWRkIHNvbWUgdGV4dCBwb2ludGluZyBvdXQgdGhlIGlzc3VlLg0KPiAN Cj4gVGhhbmtzLA0KPiAgICAgRXJpaw0KPiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBY aWFvaHUNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBF cmlrIE5vcmRtYXJrIFttYWlsdG86bm9yZG1hcmtAc29uaWMubmV0XQ0KPiA+PiBTZW50OiAyMDE1 xOoz1MIyNsjVIDU6MDENCj4gPj4gVG86IG52bzNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW252 bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnMNCj4gPj4NCj4gPj4NCj4gPj4gSSBwcmVz ZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2VudCBOVk8zIGludGVyaW0gbWVldGlu Zy5UaGUNCj4gPj4gZnVsbA0KPiA+IDEyDQo+ID4+IGFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdo ZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVyIHRoaXMgd2Vlay4NCj4gPj4gICAgVGhlIGRy YWZ0IGlzDQo+ID4+ICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1y dGctZHQtZW5jYXAvDQo+ID4+ICAgIGFuZCB0aGUgc2xpZGVzIGFyZSBhdA0KPiA+PiAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgu cGRmDQo+ID4+DQo+ID4+IFRoZXJlIGlzIHByb2JhYmx5IGFkZGl0aW9uYWwgdGhpbmdzIGluIHRo ZXJlIHRvIGNvbnNpZGVyIGZvciBOVk8zLA0KPiA+PiBhbmQNCj4gPiBhZHZpY2UNCj4gPj4gdGhh dCBjYW4gYmUgcmV1c2VkIHRvIG1ha2UgaXQgZWFzaWVyIHRvIG1vdmUgTlZPMyBmb3J3YXJkLg0K PiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiAgICAgIEVyaWsNCj4gPj4NCj4gPj4NCj4gPj4NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gPiBudm8zQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo+ID4NCg0K From nobody Thu Apr 9 08:26:22 2015 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 D46851A8833 for ; Thu, 9 Apr 2015 08:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 t0hDuqnMSJVj for ; Thu, 9 Apr 2015 08:26:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661521A8785 for ; Thu, 9 Apr 2015 08:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2250; q=dns/txt; s=iport; t=1428593178; x=1429802778; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GkcfRIssy+xL/tqN1kB6BH+X9SELBfMF82YVanYu4ls=; b=mJcOYblaZKx4kyjN/lv+BQqs7Y5TyEmzFVi4446BTWrLX1lxIGGR0Vzp xyIwVzv4/nIZzjFYuhmMdVkiT7RpRlh49kli6nQU62g5UdEfgwkxZoA/G rLOYK1B5/8azfUvf5hPV+SoWBLwEn3Kn/zFVCJpxQe5XO5+B2zbE5X09b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BjBADymCZV/5ldJa1cgwhSXAWDEMBHZgmBU4V9AhyBIjgUAQEBAQEBAX2EHwEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIIQ23KJZYAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhigqESzgGgmIvgRYFkHqDeIcwOoMAkA4ig29vAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,550,1422921600"; d="scan'208";a="139734647" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 09 Apr 2015 15:26:17 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t39FQHFa021875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Apr 2015 15:26:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 10:26:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-reddy-sfc-nsh-encrypt-00.txt Thread-Index: AQHQcteC8v/M4OuTa0OxgJAepzglR51EzAQQ Date: Thu, 9 Apr 2015 15:26:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A411FEE5B@xmb-rcd-x10.cisco.com> References: <20150409151134.27261.11652.idtracker@ietfa.amsl.com> In-Reply-To: <20150409151134.27261.11652.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.196] 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-reddy-sfc-nsh-encrypt-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: Thu, 09 Apr 2015 15:26:21 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGFkZHMgZGF0YSBvcmlnaW4gYXV0aGVudGljYXRpb24gYW5k IG9wdGlvbmFsIGVuY3J5cHRpb24gZGlyZWN0bHkgdG8gTmV0d29yayBTZXJ2aWNlIEhlYWRlcnMg KE5TSCkgdXNlZCBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZy4NCkNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KLVRpcnUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDksIDIwMTUgODo0MiBQTQ0K VG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpOyBTY290dCBGbHVocmVyIChzZmx1aHJlcik7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkp OyBTY290dCBGbHVocmVyIChzZmx1aHJlcik7IFBhdWwgUXVpbm4gKHBhdWxxKTsgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgUGF1bCBRdWlubiAocGF1bHEpDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXNmYy1uc2gtZW5jcnlwdC0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktc2ZjLW5zaC1lbmNyeXB0LTAw LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVk ZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcmVk ZHktc2ZjLW5zaC1lbmNyeXB0DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJQXV0aGVudGljYXRlZCBh bmQgZW5jcnlwdGVkIE5TSCBzZXJ2aWNlIGNoYWlucw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wNC0w OQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTINClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS1zZmMt bnNoLWVuY3J5cHQtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktc2ZjLW5zaC1lbmNyeXB0Lw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXNmYy1uc2gtZW5jcnlwdC0w MA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGFkZHMgZGF0YSBvcmlnaW4g YXV0aGVudGljYXRpb24gYW5kIG9wdGlvbmFsDQogICBlbmNyeXB0aW9uIGRpcmVjdGx5IHRvIE5l dHdvcmsgU2VydmljZSBIZWFkZXJzIChOU0gpIHVzZWQgZm9yIFNlcnZpY2UNCiAgIEZ1bmN0aW9u IENoYWluaW5nLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Apr 9 10:50:46 2015 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 ECDD31B3020; Thu, 9 Apr 2015 10:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 AH5XSFAWdHxY; Thu, 9 Apr 2015 10:50:32 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 EEA611B3005; Thu, 9 Apr 2015 10:50:27 -0700 (PDT) Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t39HoKJ0005206 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Apr 2015 10:50:20 -0700 Message-ID: <5526BBDB.3000805@acm.org> Date: Thu, 09 Apr 2015 10:50:19 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Xuxiaohu , Erik Nordmark , "nvo3@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVb/0+50Af8ZeMxdOuGDh90O3udgK4gFmlhDa5vfLYq3/CwN4RBN8w9VNu10S5+W3FNLONgEZ1dE/+SLyN4FvlPl X-Sonic-ID: C;RMWo4+De5BGN6tBwQIsAyQ== M;4mnA4+De5BGN6tBwQIsAyQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] Encapsulation considerations 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, 09 Apr 2015 17:50:37 -0000 On 4/8/15 7:20 PM, Xuxiaohu wrote: > Hi Erik, > >> But I couldn't tell from the emails on the BIER list whether the >> constraints on the first nibble value is a strict requirement in all >> cases, or whether it is conditional on something (and if so, what is >> the condition). > The conditions that I have thought of include: 1) the encapsulation is sensitive to packet misordering; 2) the encapsulation may be transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS payload to select the ECMP path. Those are conditions when the misordering would happen. But are you saying that any LSR is free to use the MPLS payload (including looking for 4 and 6 in the first nibble) to determine whether the packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes? Thanks, Erik > > Best regards, > Xiaohu > >> Once I know that answer we can definitely add some text pointing out the issue. >> >> Thanks, >> Erik >> >>> Best regards, >>> Xiaohu >>> >>>> -----Original Message----- >>>> From: Erik Nordmark [mailto:nordmark@sonic.net] >>>> Sent: 2015年3月26日 5:01 >>>> To: nvo3@ietf.org >>>> Subject: [nvo3] Encapsulation considerations >>>> >>>> >>>> I presented part of this at the most recent NVO3 interim meeting.The >>>> full >>> 12 >>>> areas of considerations where presented at RTGWG earlier this week. >>>> The draft is >>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ >>>> and the slides are at >>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>> >>>> There is probably additional things in there to consider for NVO3, >>>> and >>> advice >>>> that can be reused to make it easier to move NVO3 forward. >>>> >>>> Regards, >>>> Erik >>>> >>>> >>>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> > From nobody Thu Apr 9 11:01:40 2015 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 A97CC1B304F; Thu, 9 Apr 2015 11:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, HTML_MESSAGE=0.001, 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 W4boevSxiwMa; Thu, 9 Apr 2015 11:01:33 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (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 44BFF1B304C; Thu, 9 Apr 2015 11:01:33 -0700 (PDT) Received: by obbry2 with SMTP id ry2so26599060obb.1; Thu, 09 Apr 2015 11:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UcszIte+kdNmlchUsLjxmFom+vsM4s7FNGkJ4ZPDZMA=; b=GRJ/vE02uznPFRLi7xT0qQz8hbstVvmo68GoKUQBD+Lkil2EGj7k6XYDL1lZjs07rQ VnnBOOpgPNqU+Xo8Rs17/5rwvoABYlofLZGrJ9yx0YJ4qWFGblfw4gt40UKUqtwqrrCR MSn7WIgyDR5cyX1djd6za9p9AxML6FMizJnOHpCEzvVdpRqZf+leMYTqg2Ob1sK4C5XU jODm9d/TsufDpvadUZZUyTeTH+9y3aMckap8uAd3Rxnkn4if0Njz/Dy06rJNAKuIRqMg 1Haugi0Kf06JwIM62tT/oF0j6otrbDKFy/6UV/aX5kkcYjMQLEcEsBjgM733pxkTmizi EeVA== MIME-Version: 1.0 X-Received: by 10.60.165.68 with SMTP id yw4mr39722675oeb.76.1428602492766; Thu, 09 Apr 2015 11:01:32 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Thu, 9 Apr 2015 11:01:32 -0700 (PDT) In-Reply-To: <5526BBDB.3000805@acm.org> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> Date: Thu, 9 Apr 2015 14:01:32 -0400 Message-ID: From: Alia Atlas To: Erik Nordmark Content-Type: multipart/alternative; boundary=047d7b4508621b532f05134e700a Archived-At: Cc: BIER , "mpls@ietf.org" , Xuxiaohu , "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] Encapsulation considerations 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, 09 Apr 2015 18:01:35 -0000 --047d7b4508621b532f05134e700a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark wrote: > On 4/8/15 7:20 PM, Xuxiaohu wrote: > >> Hi Erik, >> >> But I couldn't tell from the emails on the BIER list whether the >>> constraints on the first nibble value is a strict requirement in all ca= ses, >>> or whether it is conditional on something (and if so, what is the >>> condition). >>> >> The conditions that I have thought of include: 1) the encapsulation is >> sensitive to packet misordering; 2) the encapsulation may be transported >> over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of t= he >> MPLS payload to select the ECMP path. >> > Those are conditions when the misordering would happen. But are you sayin= g > that any LSR is free to use the MPLS payload (including looking for 4 and= 6 > in the first nibble) to determine whether the packet is IPv4 and IPv6 and > use what it thinks are IPv4 and IPv6 fields for ECMP purposes? Take a quick look at RFC 4385 - which is the control word for pseudo-wires. The short form is that a number of routers at the time peeked beneath the label stack to figure out whether what was inside as IPv4 or IPv6 based solely upon the first nibble. A recommendation was made that the checksum should also be verified, but the only equipment that I'm certain of that did that isn't around anymore. Also look at Section 2.4 of RFC 7325. Alia > > Thanks, > Erik > > >> Best regards, >> Xiaohu >> >> Once I know that answer we can definitely add some text pointing out th= e >>> issue. >>> >>> Thanks, >>> Erik >>> >>> Best regards, >>>> Xiaohu >>>> >>>> -----Original Message----- >>>>> From: Erik Nordmark [mailto:nordmark@sonic.net] >>>>> Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01 >>>>> To: nvo3@ietf.org >>>>> Subject: [nvo3] Encapsulation considerations >>>>> >>>>> >>>>> I presented part of this at the most recent NVO3 interim meeting.The >>>>> full >>>>> >>>> 12 >>>> >>>>> areas of considerations where presented at RTGWG earlier this week. >>>>> The draft is >>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ >>>>> and the slides are at >>>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>>> >>>>> There is probably additional things in there to consider for NVO3, >>>>> and >>>>> >>>> advice >>>> >>>>> that can be reused to make it easier to move NVO3 forward. >>>>> >>>>> Regards, >>>>> Erik >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --047d7b4508621b532f05134e700a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <nordmark@acm.org> = wrote:
On 4/8/15 7:20 PM= , Xuxiaohu wrote:
Hi Erik,

But I couldn't tell from the emails on the BIER list whether the constr= aints on the first nibble value is a strict requirement in all cases, or wh= ether it is conditional on something (and if so, what is the condition).
The conditions that I have thought of include: 1) the encapsulation is sens= itive to packet misordering; 2) the encapsulation may be transported over a= n MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS p= ayload to select the ECMP path.
Those are conditions when the misordering would happen. But are you saying = that any LSR is free to use the MPLS payload (including looking for 4 and 6= in the first nibble) to determine whether the packet is IPv4 and IPv6 and = use what it thinks are IPv4 and IPv6 fields for ECMP purposes?
=

Take a quick look at RFC 4385 - which is the control wo= rd for pseudo-wires.
The short form is that a number of routers a= t the time peeked beneath the label stack to figure out whether what was in= side as IPv4 or IPv6 based solely upon the first nibble.=C2=A0 A recommenda= tion was made that the checksum should also be verified, but the only equip= ment that I'm certain of that did that isn't around anymore.
<= div>
Also look at Section 2.4 of RFC 7325.

Alia
=C2=A0

Thanks,
=C2=A0 =C2=A0Erik


Best regards,
Xiaohu

Once I know that answer we can definitely add some text pointing out the is= sue.

Thanks,
=C2=A0 =C2=A0 =C2=A0Erik

Best regards,
Xiaohu

-----Original Message-----
From: Erik Nordmark [mailto:nordmark@sonic.net]
Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01
To: nvo3@ietf.org Subject: [nvo3] Encapsulation considerations


I presented part of this at the most recent NVO3 interim meeting.The
full
12
areas of considerations where presented at RTGWG earlier this week.
=C2=A0 =C2=A0 The draft is
=C2=A0 =C2=A0 =C2=A0 http://datatracker.ietf.org/doc/draft-rt= g-dt-encap/
=C2=A0 =C2=A0 and the slides are at
=C2=A0 =C2=A0 =C2=A0http://www.ietf.org/proceedin= gs/92/slides/slides-92-rtgwg-8.pdf

There is probably additional things in there to consider for NVO3,
and
advice
that can be reused to make it easier to move NVO3 forward.

Regards,
=C2=A0 =C2=A0 =C2=A0 Erik



_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3



_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

--047d7b4508621b532f05134e700a-- From nobody Thu Apr 9 11:17:51 2015 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 3DFF21B3095; Thu, 9 Apr 2015 11:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 4YHLhlfslwPw; Thu, 9 Apr 2015 11:17:46 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (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 40A0B1A898C; Thu, 9 Apr 2015 11:17:43 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so121483270ied.1; Thu, 09 Apr 2015 11:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ep1PYuLdHD4McTHckhL6SXQnJuOuosi1r9kMflJgwiE=; b=L18Q37asqH3AhFeg3sKzSY20q7KKjqmetk3m7PTu+e1LTUU3ueF6msVsxFjC7GJD/b +fLXsVbQPzab4oWB2crvSMb38tT9ClkcyMLPhZAS21lcTvsk0uZ4SqQuYykBfEeIGrPE kQmDwVDzFkvL/FWhHUcKxNrwmcGR2sQKAOjmtgQnyK6JHhGQpgkQEC03ErT+GBrI1Apr xKawyzWPnlDY76XSS2nNrodnILLatjc/KynlnJWMQm66wbQAGvEaJ1rVNKNzb6pSArAe NrqoLXLzB74Ly9ixpb8hUeQ0/qAueCS61AKJ6zgdPSOGIGcCIUUQPxQ8v3sAesSsOT8z TAfw== MIME-Version: 1.0 X-Received: by 10.50.93.69 with SMTP id cs5mr22608983igb.4.1428603462778; Thu, 09 Apr 2015 11:17:42 -0700 (PDT) Received: by 10.107.52.21 with HTTP; Thu, 9 Apr 2015 11:17:42 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> Date: Thu, 9 Apr 2015 11:17:42 -0700 Message-ID: From: Tony Przygienda To: Alia Atlas Content-Type: multipart/alternative; boundary=089e01537ed8ec84a605134ea9e0 Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" , "nvo3@ietf.org" , Erik Nordmark , Xuxiaohu Subject: Re: [sfc] [Bier] [nvo3] Encapsulation considerations 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, 09 Apr 2015 18:17:49 -0000 --089e01537ed8ec84a605134ea9e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would venture to say that a. BIER misordering would be a bad thing for many applications but I do not think that the encapsulation per se misorders or not as property, it=E2=80=99s the way the intermediate routers are allowed to play shannigan= s (or seen differently, =E2=80=98heuristically=E2=80=99 come up with things given= unclear semantics of the encaps) that causes misordering. So it is up to the encaps to give enough info so the routers in the middle do the =E2=80=98right thin= g=E2=80=99. Modulo historical problems with CW support and so on =E2=80=A6 b. This flavor of discussion is repeating, e.g. eVPN RFC with the CW/no CW debate which I could restore only partially and other groups now = =E2=80=A6 OK, lemme stick my (na=C3=AFve ;-) head far out: why do encaps guidelines f= or everything that can go over PSN not mandate CW from now on? Existing gear and historical RFCs supported until they peter out and entropy labels being an orthogonal mechanism =E2=80=A6 Or do we think the =E2=80=98heuristical = DPI' is a bottomless box of band-aids ? --- tony On Thu, Apr 9, 2015 at 11:01 AM, Alia Atlas wrote: > On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark wrote: > >> On 4/8/15 7:20 PM, Xuxiaohu wrote: >> >>> Hi Erik, >>> >>> But I couldn't tell from the emails on the BIER list whether the >>>> constraints on the first nibble value is a strict requirement in all c= ases, >>>> or whether it is conditional on something (and if so, what is the >>>> condition). >>>> >>> The conditions that I have thought of include: 1) the encapsulation is >>> sensitive to packet misordering; 2) the encapsulation may be transporte= d >>> over an MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of = the >>> MPLS payload to select the ECMP path. >>> >> Those are conditions when the misordering would happen. But are you >> saying that any LSR is free to use the MPLS payload (including looking f= or >> 4 and 6 in the first nibble) to determine whether the packet is IPv4 and >> IPv6 and use what it thinks are IPv4 and IPv6 fields for ECMP purposes? > > > Take a quick look at RFC 4385 - which is the control word for pseudo-wire= s. > The short form is that a number of routers at the time peeked beneath the > label stack to figure out whether what was inside as IPv4 or IPv6 based > solely upon the first nibble. A recommendation was made that the checksu= m > should also be verified, but the only equipment that I'm certain of that > did that isn't around anymore. > > Also look at Section 2.4 of RFC 7325. > > Alia > > >> >> Thanks, >> Erik >> >> >>> Best regards, >>> Xiaohu >>> >>> Once I know that answer we can definitely add some text pointing out >>>> the issue. >>>> >>>> Thanks, >>>> Erik >>>> >>>> Best regards, >>>>> Xiaohu >>>>> >>>>> -----Original Message----- >>>>>> From: Erik Nordmark [mailto:nordmark@sonic.net] >>>>>> Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01 >>>>>> To: nvo3@ietf.org >>>>>> Subject: [nvo3] Encapsulation considerations >>>>>> >>>>>> >>>>>> I presented part of this at the most recent NVO3 interim meeting.The >>>>>> full >>>>>> >>>>> 12 >>>>> >>>>>> areas of considerations where presented at RTGWG earlier this week. >>>>>> The draft is >>>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ >>>>>> and the slides are at >>>>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>>>> >>>>>> There is probably additional things in there to consider for NVO3, >>>>>> and >>>>>> >>>>> advice >>>>> >>>>>> that can be reused to make it easier to move NVO3 forward. >>>>>> >>>>>> Regards, >>>>>> Erik >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> >>>>> >>> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > --089e01537ed8ec84a605134ea9e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would venture to say that=

a.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 BIER misordering would be a bad thing for many applications but I do not think t= hat the encapsulation per se misorders or not as property, it=E2=80=99s the way= the intermediate routers are allowed to play shannigans (or seen differently, =E2=80=98heuri= stically=E2=80=99 come up with things given unclear semantics of the encaps) that causes misordering. So it is up to the encaps to give enough info so the routers i= n the middle do the =E2=80=98right thing=E2=80=99. Modulo historical problems wit= h CW support and so on =E2=80=A6

b.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 This flavor of discussion is repeating, e.g. eVPN RFC with the CW/no CW debate which I cou= ld restore only partially and other groups now =E2=80=A6

=C2=A0

OK, lemme stick my (na=C3=AFve ;-) head far = out: why do encaps guidelines for everything that can go over PSN not mandate CW from now on? Existing gear a= nd historical RFCs supported until they peter out and entropy labels being an = orthogonal mechanism =E2=80=A6 =C2=A0Or do we think the =E2=80=98heuristica= l DPI' is a bottomless box of band-aids ?

=C2=A0

--- tony=C2=A0


On Thu, Apr 9, 2015 at 11:01 A= M, Alia Atlas <akatlas@gmail.com> wrote:
On Thu, Apr 9, 2015 at 1:50 PM, Erik Nordmark <= span dir=3D"ltr"><= nordmark@acm.org> wrote:
On 4/8/15 7:20 PM, Xuxiaohu wrote:
Hi Erik,

But I couldn't tell from the emails on the BIER list whether the constr= aints on the first nibble value is a strict requirement in all cases, or wh= ether it is conditional on something (and if so, what is the condition).
The conditions that I have thought of include: 1) the encapsulation is sens= itive to packet misordering; 2) the encapsulation may be transported over a= n MPLS PSN; 3) LSRs within that MPLS PSN may use the contents of the MPLS p= ayload to select the ECMP path.
Those are conditions when the misordering would happen. But are you saying = that any LSR is free to use the MPLS payload (including looking for 4 and 6= in the first nibble) to determine whether the packet is IPv4 and IPv6 and = use what it thinks are IPv4 and IPv6 fields for ECMP purposes?
=

Take a quick look at RFC 4385 - which is the con= trol word for pseudo-wires.
The short form is that a number of ro= uters at the time peeked beneath the label stack to figure out whether what= was inside as IPv4 or IPv6 based solely upon the first nibble.=C2=A0 A rec= ommendation was made that the checksum should also be verified, but the onl= y equipment that I'm certain of that did that isn't around anymore.=

Also look at Section 2.4 of RFC 7325.
<= br>
Alia
=C2=A0

Thanks,
=C2=A0 =C2=A0Erik


Best regards,
Xiaohu

Once I know that answer we can definitely add some text pointing out the is= sue.

Thanks,
=C2=A0 =C2=A0 =C2=A0Erik

Best regards,
Xiaohu

-----Original Message-----
From: Erik Nordmark [mailto:nordmark@sonic.net]
Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5 5:01
To: nvo3@ietf.org Subject: [nvo3] Encapsulation considerations


I presented part of this at the most recent NVO3 interim meeting.The
full
12
areas of considerations where presented at RTGWG earlier this week.
=C2=A0 =C2=A0 The draft is
=C2=A0 =C2=A0 =C2=A0 http://datatracker.ietf.org/doc/draft-rt= g-dt-encap/
=C2=A0 =C2=A0 and the slides are at
=C2=A0 =C2=A0 =C2=A0http://www.ietf.org/proceedin= gs/92/slides/slides-92-rtgwg-8.pdf

There is probably additional things in there to consider for NVO3,
and
advice
that can be reused to make it easier to move NVO3 forward.

Regards,
=C2=A0 =C2=A0 =C2=A0 Erik



_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3



_______________________________________________


_______________________________________________
BIER mailing list
BIER@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/bier


--089e01537ed8ec84a605134ea9e0-- From nobody Thu Apr 9 11:48:07 2015 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 6913F1A86F7; Thu, 9 Apr 2015 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 XueSsRgGfWmS; Thu, 9 Apr 2015 11:47:54 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 6AC5F1A3B9D; Thu, 9 Apr 2015 11:47:46 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-d9-552672c071f2 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 57.01.12456.0C276255; Thu, 9 Apr 2015 14:38:24 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 9 Apr 2015 14:47:43 -0400 From: David Allan I To: Tony Przygienda , Alia Atlas Thread-Topic: [Bier] [sfc] [nvo3] Encapsulation considerations Thread-Index: AQHQcvGAbLNbfLoTTU+uoBqvb9o3op1E/6Lg Date: Thu, 9 Apr 2015 18:47:42 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> 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: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyuXSPn+6BIrVQg55NphafHl5itlg6Yw+T xa2lK1kt+qfuZLJ4Ol/S4smDrewWux9sZLHYen4VowOHx+Ur3h47Z91l92g58pbVY8mSn0wB LFFcNimpOZllqUX6dglcGV/XLWEqaNvNWHFp9gS2BsaebYxdjJwcEgImEl+eHGeHsMUkLtxb z9bFyMUhJHCUUeLkpxtACQ4gZxmjxDFXkBo2AQOJPf+/gPWKCHhKbH84AayeWWA/o8TPX9fZ QBLCArYSa55fYYcospM4v+EzVIORxMv7t1hAbBYBFYnNs1aB1fAK+EqcOHOdFWLxSyaJW+ue gw3iFAiUuDLhCzOIzQh03fdTa5hAbGYBcYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtqLEvv7p 7BD1+RLrVl1ihVgmKHFy5hOWCYyis5CMmoWkbBaSsllA/zMLaEqs36UPUaIoMaX7ITuErSHR OmcuO7L4Akb2VYwcpcWpZbnpRgabGIFRekyCTXcH456XlocYBTgYlXh4HyxRDRViTSwrrsw9 xCjNwaIkzrvowcEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw5ufw/ty36ceFDA8vlROeb Zqvnaj7cuGPnlWI7fU4P2RVPr6cG1a50ORpxeLZq/5L1zzxb1Q2e/XngWfHGaeFnZxaWIsmW 9Lhl+qKb3NWf9yrv/PNm/UurP4meV6dUh4RM1eXNZoludT5+MiVO/rSczUkNvbBXH1dkTTk6 2fumiaEL20ub/HglluKMREMt5qLiRABsk3w0swIAAA== Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" , "nvo3@ietf.org" , Erik Nordmark , Xuxiaohu Subject: Re: [sfc] [Bier] [nvo3] Encapsulation considerations 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, 09 Apr 2015 18:48:01 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PIGl0IGlzIHNpbXBseSBhIHJlc3RyaWN0aW9uIG9uIHRoZSBmaXJzdCBmb3VyIGJpdHMgb2Yg YW55dGhpbmcgdGhhdCBjYW4gYmUgZGlyZWN0bHkgZW5jYXBzdWxhdGVkIGluIE1QTFMNCg0KT3Ro ZXJ3aXNlLCBkZXNpZ25pbmcgKGZvciBleGFtcGxlKSBhIHZlcnNpb24gZmllbGQgZm9yIHdoaWNo IElBTkEgd2lsbCBoYXZlIHRvIHB1bmNoIGhvbGVzIGluIHRoZSBhc3NpZ25tZW50IHJhbmdlIGRv ZXMgbm90IHNlZW0gbGlrZSBhIGdvb2QgaWRlYS4gQW5kIEnigJl2ZSBub3QgYmVlbiBhYmxlIHRv IGNvbnZpbmNlIG15c2VsZiB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgaGFzIGNvbXBsZXRlbHkgZ29u ZSBhd2F5Lg0KDQpDaGVlcnMNCkRhdmUNCg0KRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbnkgUHJ6eWdpZW5kYQ0KU2VudDogVGh1cnNkYXks IEFwcmlsIDA5LCAyMDE1IDExOjE4IEFNDQpUbzogQWxpYSBBdGxhcw0KQ2M6IG1wbHNAaWV0Zi5v cmc7IEJJRVI7IHNmY0BpZXRmLm9yZzsgbnZvM0BpZXRmLm9yZzsgRXJpayBOb3JkbWFyazsgWHV4 aWFvaHUNClN1YmplY3Q6IFJlOiBbQmllcl0gW3NmY10gW252bzNdIEVuY2Fwc3VsYXRpb24gY29u c2lkZXJhdGlvbnMNCg0KSSB3b3VsZCB2ZW50dXJlIHRvIHNheSB0aGF0DQphLiAgICAgIEJJRVIg bWlzb3JkZXJpbmcgd291bGQgYmUgYSBiYWQgdGhpbmcgZm9yIG1hbnkgYXBwbGljYXRpb25zIGJ1 dCBJIGRvIG5vdCB0aGluayB0aGF0IHRoZSBlbmNhcHN1bGF0aW9uIHBlciBzZSBtaXNvcmRlcnMg b3Igbm90IGFzIHByb3BlcnR5LCBpdOKAmXMgdGhlIHdheSB0aGUgaW50ZXJtZWRpYXRlIHJvdXRl cnMgYXJlIGFsbG93ZWQgdG8gcGxheSBzaGFubmlnYW5zIChvciBzZWVuIGRpZmZlcmVudGx5LCDi gJhoZXVyaXN0aWNhbGx54oCZIGNvbWUgdXAgd2l0aCB0aGluZ3MgZ2l2ZW4gdW5jbGVhciBzZW1h bnRpY3Mgb2YgdGhlIGVuY2FwcykgdGhhdCBjYXVzZXMgbWlzb3JkZXJpbmcuIFNvIGl0IGlzIHVw IHRvIHRoZSBlbmNhcHMgdG8gZ2l2ZSBlbm91Z2ggaW5mbyBzbyB0aGUgcm91dGVycyBpbiB0aGUg bWlkZGxlIGRvIHRoZSDigJhyaWdodCB0aGluZ+KAmS4gTW9kdWxvIGhpc3RvcmljYWwgcHJvYmxl bXMgd2l0aCBDVyBzdXBwb3J0IGFuZCBzbyBvbiDigKYNCmIuICAgICAgVGhpcyBmbGF2b3Igb2Yg ZGlzY3Vzc2lvbiBpcyByZXBlYXRpbmcsIGUuZy4gZVZQTiBSRkMgd2l0aCB0aGUgQ1cvbm8gQ1cg ZGViYXRlIHdoaWNoIEkgY291bGQgcmVzdG9yZSBvbmx5IHBhcnRpYWxseSBhbmQgb3RoZXIgZ3Jv dXBzIG5vdyDigKYNCg0KT0ssIGxlbW1lIHN0aWNrIG15IChuYcOvdmUgOy0pIGhlYWQgZmFyIG91 dDogd2h5IGRvIGVuY2FwcyBndWlkZWxpbmVzIGZvciBldmVyeXRoaW5nIHRoYXQgY2FuIGdvIG92 ZXIgUFNOIG5vdCBtYW5kYXRlIENXIGZyb20gbm93IG9uPyBFeGlzdGluZyBnZWFyIGFuZCBoaXN0 b3JpY2FsIFJGQ3Mgc3VwcG9ydGVkIHVudGlsIHRoZXkgcGV0ZXIgb3V0IGFuZCBlbnRyb3B5IGxh YmVscyBiZWluZyBhbiBvcnRob2dvbmFsIG1lY2hhbmlzbSDigKYgIE9yIGRvIHdlIHRoaW5rIHRo ZSDigJhoZXVyaXN0aWNhbCBEUEknIGlzIGEgYm90dG9tbGVzcyBib3ggb2YgYmFuZC1haWRzID8N Cg0KLS0tIHRvbnkNCg0KT24gVGh1LCBBcHIgOSwgMjAxNSBhdCAxMTowMSBBTSwgQWxpYSBBdGxh cyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4gd3JvdGU6DQpP biBUaHUsIEFwciA5LCAyMDE1IGF0IDE6NTAgUE0sIEVyaWsgTm9yZG1hcmsgPG5vcmRtYXJrQGFj bS5vcmc8bWFpbHRvOm5vcmRtYXJrQGFjbS5vcmc+PiB3cm90ZToNCk9uIDQvOC8xNSA3OjIwIFBN LCBYdXhpYW9odSB3cm90ZToNCkhpIEVyaWssDQpCdXQgSSBjb3VsZG4ndCB0ZWxsIGZyb20gdGhl IGVtYWlscyBvbiB0aGUgQklFUiBsaXN0IHdoZXRoZXIgdGhlIGNvbnN0cmFpbnRzIG9uIHRoZSBm aXJzdCBuaWJibGUgdmFsdWUgaXMgYSBzdHJpY3QgcmVxdWlyZW1lbnQgaW4gYWxsIGNhc2VzLCBv ciB3aGV0aGVyIGl0IGlzIGNvbmRpdGlvbmFsIG9uIHNvbWV0aGluZyAoYW5kIGlmIHNvLCB3aGF0 IGlzIHRoZSBjb25kaXRpb24pLg0KVGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBv ZiBpbmNsdWRlOiAxKSB0aGUgZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFja2V0IG1p c29yZGVyaW5nOyAyKSB0aGUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBh biBNUExTIFBTTjsgMykgTFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250 ZW50cyBvZiB0aGUgTVBMUyBwYXlsb2FkIHRvIHNlbGVjdCB0aGUgRUNNUCBwYXRoLg0KVGhvc2Ug YXJlIGNvbmRpdGlvbnMgd2hlbiB0aGUgbWlzb3JkZXJpbmcgd291bGQgaGFwcGVuLiBCdXQgYXJl IHlvdSBzYXlpbmcgdGhhdCBhbnkgTFNSIGlzIGZyZWUgdG8gdXNlIHRoZSBNUExTIHBheWxvYWQg KGluY2x1ZGluZyBsb29raW5nIGZvciA0IGFuZCA2IGluIHRoZSBmaXJzdCBuaWJibGUpIHRvIGRl dGVybWluZSB3aGV0aGVyIHRoZSBwYWNrZXQgaXMgSVB2NCBhbmQgSVB2NiBhbmQgdXNlIHdoYXQg aXQgdGhpbmtzIGFyZSBJUHY0IGFuZCBJUHY2IGZpZWxkcyBmb3IgRUNNUCBwdXJwb3Nlcz8NCg0K VGFrZSBhIHF1aWNrIGxvb2sgYXQgUkZDIDQzODUgLSB3aGljaCBpcyB0aGUgY29udHJvbCB3b3Jk IGZvciBwc2V1ZG8td2lyZXMuDQpUaGUgc2hvcnQgZm9ybSBpcyB0aGF0IGEgbnVtYmVyIG9mIHJv dXRlcnMgYXQgdGhlIHRpbWUgcGVla2VkIGJlbmVhdGggdGhlIGxhYmVsIHN0YWNrIHRvIGZpZ3Vy ZSBvdXQgd2hldGhlciB3aGF0IHdhcyBpbnNpZGUgYXMgSVB2NCBvciBJUHY2IGJhc2VkIHNvbGVs eSB1cG9uIHRoZSBmaXJzdCBuaWJibGUuICBBIHJlY29tbWVuZGF0aW9uIHdhcyBtYWRlIHRoYXQg dGhlIGNoZWNrc3VtIHNob3VsZCBhbHNvIGJlIHZlcmlmaWVkLCBidXQgdGhlIG9ubHkgZXF1aXBt ZW50IHRoYXQgSSdtIGNlcnRhaW4gb2YgdGhhdCBkaWQgdGhhdCBpc24ndCBhcm91bmQgYW55bW9y ZS4NCg0KQWxzbyBsb29rIGF0IFNlY3Rpb24gMi40IG9mIFJGQyA3MzI1Lg0KDQpBbGlhDQoNCg0K VGhhbmtzLA0KICAgRXJpaw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCk9uY2UgSSBrbm93IHRo YXQgYW5zd2VyIHdlIGNhbiBkZWZpbml0ZWx5IGFkZCBzb21lIHRleHQgcG9pbnRpbmcgb3V0IHRo ZSBpc3N1ZS4NCg0KVGhhbmtzLA0KICAgICBFcmlrDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86bm9y ZG1hcmtAc29uaWMubmV0PG1haWx0bzpub3JkbWFya0Bzb25pYy5uZXQ+XQ0KU2VudDogMjAxNeW5 tDPmnIgyNuaXpSA1OjAxDQpUbzogbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4N ClN1YmplY3Q6IFtudm8zXSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zDQoNCg0KSSBwcmVz ZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2VudCBOVk8zIGludGVyaW0gbWVldGlu Zy5UaGUNCmZ1bGwNCjEyDQphcmVhcyBvZiBjb25zaWRlcmF0aW9ucyB3aGVyZSBwcmVzZW50ZWQg YXQgUlRHV0cgZWFybGllciB0aGlzIHdlZWsuDQogICAgVGhlIGRyYWZ0IGlzDQogICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJ0Zy1kdC1lbmNhcC8NCiAgICBhbmQg dGhlIHNsaWRlcyBhcmUgYXQNCiAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgucGRmDQoNClRoZXJlIGlzIHByb2JhYmx5IGFkZGl0 aW9uYWwgdGhpbmdzIGluIHRoZXJlIHRvIGNvbnNpZGVyIGZvciBOVk8zLA0KYW5kDQphZHZpY2UN CnRoYXQgY2FuIGJlIHJldXNlZCB0byBtYWtlIGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2Fy ZC4NCg0KUmVnYXJkcywNCiAgICAgIEVyaWsNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNAaWV0Zi5vcmc8 bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCSUVSIG1haWxpbmcgbGlz dA0KQklFUkBpZXRmLm9yZzxtYWlsdG86QklFUkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmllcg0KDQo= --_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklNTyBpdCBpcyBzaW1wbHkgYSByZXN0cmljdGlvbiBvbiB0aGUgZmlyc3QgZm91ciBiaXRzIG9m IGFueXRoaW5nIHRoYXQgY2FuIGJlIGRpcmVjdGx5IGVuY2Fwc3VsYXRlZCBpbiBNUExTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5PdGhlcndpc2UsIGRlc2lnbmluZyAoZm9yIGV4YW1wbGUpIGEgdmVyc2lvbiBmaWVsZCBm b3Igd2hpY2ggSUFOQSB3aWxsIGhhdmUgdG8gcHVuY2ggaG9sZXMgaW4gdGhlIGFzc2lnbm1lbnQg cmFuZ2UgZG9lcyBub3Qgc2VlbSBsaWtlIGEgZ29vZCBpZGVhLiBBbmQgSeKAmXZlDQogbm90IGJl ZW4gYWJsZSB0byBjb252aW5jZSBteXNlbGYgdGhhdCB0aGlzIHJlcXVpcmVtZW50IGhhcyBjb21w bGV0ZWx5IGdvbmUgYXdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBC SUVSIFttYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5U b255IFByenlnaWVuZGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA5LCAyMDE1 IDExOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBBbGlhIEF0bGFzPGJyPg0KPGI+Q2M6PC9iPiBtcGxz QGlldGYub3JnOyBCSUVSOyBzZmNAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IEVyaWsgTm9yZG1h cms7IFh1eGlhb2h1PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQmllcl0gW3NmY10gW252bzNd IEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IHdvdWxkIHZlbnR1cmUgdG8gc2F5IHRoYXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNzVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QklFUiBtaXNvcmRl cmluZyB3b3VsZCBiZSBhIGJhZCB0aGluZyBmb3IgbWFueSBhcHBsaWNhdGlvbnMgYnV0IEkgZG8g bm90IHRoaW5rIHRoYXQgdGhlIGVuY2Fwc3VsYXRpb24gcGVyIHNlIG1pc29yZGVycyBvciBub3Qg YXMgcHJvcGVydHksIGl04oCZcyB0aGUgd2F5IHRoZSBpbnRlcm1lZGlhdGUgcm91dGVycw0KIGFy ZSBhbGxvd2VkIHRvIHBsYXkgc2hhbm5pZ2FucyAob3Igc2VlbiBkaWZmZXJlbnRseSwg4oCYaGV1 cmlzdGljYWxseeKAmSBjb21lIHVwIHdpdGggdGhpbmdzIGdpdmVuIHVuY2xlYXIgc2VtYW50aWNz IG9mIHRoZSBlbmNhcHMpIHRoYXQgY2F1c2VzIG1pc29yZGVyaW5nLiBTbyBpdCBpcyB1cCB0byB0 aGUgZW5jYXBzIHRvIGdpdmUgZW5vdWdoIGluZm8gc28gdGhlIHJvdXRlcnMgaW4gdGhlIG1pZGRs ZSBkbyB0aGUg4oCYcmlnaHQgdGhpbmfigJkuIE1vZHVsbw0KIGhpc3RvcmljYWwgcHJvYmxlbXMg d2l0aCBDVyBzdXBwb3J0IGFuZCBzbyBvbiDigKYgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi43NWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5iLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGZsYXZv ciBvZiBkaXNjdXNzaW9uIGlzIHJlcGVhdGluZywgZS5nLiBlVlBOIFJGQyB3aXRoIHRoZSBDVy9u byBDVyBkZWJhdGUgd2hpY2ggSSBjb3VsZCByZXN0b3JlIG9ubHkgcGFydGlhbGx5IGFuZCBvdGhl ciBncm91cHMgbm93IOKApg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIGxlbW1lIHN0aWNrIG15IChuYcOv dmUgOy0pIGhlYWQgZmFyIG91dDogd2h5IGRvIGVuY2FwcyBndWlkZWxpbmVzIGZvciBldmVyeXRo aW5nIHRoYXQgY2FuIGdvIG92ZXINCiBQU04gbm90IG1hbmRhdGUgQ1cgZnJvbSBub3cgb24/IEV4 aXN0aW5nIGdlYXIgYW5kIGhpc3RvcmljYWwgUkZDcyBzdXBwb3J0ZWQgdW50aWwgdGhleSBwZXRl ciBvdXQgYW5kIGVudHJvcHkgbGFiZWxzIGJlaW5nIGFuIG9ydGhvZ29uYWwgbWVjaGFuaXNtIOKA piAmbmJzcDtPciBkbyB3ZSB0aGluayB0aGUg4oCYaGV1cmlzdGljYWwgRFBJJyBpcyBhIGJvdHRv bWxlc3MgYm94IG9mIGJhbmQtYWlkcyA/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS0gdG9ueSZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgQXByIDksIDIwMTUgYXQgMTE6MDEgQU0sIEFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1haWx0 bzpha2F0bGFzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFrYXRsYXNAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA5LCAyMDE1IGF0IDE6NTAgUE0sIEVyaWsgTm9yZG1h cmsgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JkbWFya0BhY20ub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bm9yZG1hcmtAYWNtLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gNC84LzE1IDc6MjAgUE0sIFh1eGlhb2h1IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5I aSBFcmlrLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkgY291bGRu J3QgdGVsbCBmcm9tIHRoZSBlbWFpbHMgb24gdGhlIEJJRVIgbGlzdCB3aGV0aGVyIHRoZSBjb25z dHJhaW50cyBvbiB0aGUgZmlyc3QgbmliYmxlIHZhbHVlIGlzIGEgc3RyaWN0IHJlcXVpcmVtZW50 IGluIGFsbCBjYXNlcywgb3Igd2hldGhlciBpdCBpcyBjb25kaXRpb25hbCBvbiBzb21ldGhpbmcg KGFuZCBpZiBzbywgd2hhdCBpcyB0aGUgY29uZGl0aW9uKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBvZiBp bmNsdWRlOiAxKSB0aGUgZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFja2V0IG1pc29y ZGVyaW5nOyAyKSB0aGUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhbiBN UExTIFBTTjsgMykgTFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250ZW50 cyBvZiB0aGUgTVBMUyBwYXlsb2FkIHRvIHNlbGVjdA0KIHRoZSBFQ01QIHBhdGguPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9zZSBhcmUgY29uZGl0aW9ucyB3aGVuIHRo ZSBtaXNvcmRlcmluZyB3b3VsZCBoYXBwZW4uIEJ1dCBhcmUgeW91IHNheWluZyB0aGF0IGFueSBM U1IgaXMgZnJlZSB0byB1c2UgdGhlIE1QTFMgcGF5bG9hZCAoaW5jbHVkaW5nIGxvb2tpbmcgZm9y IDQgYW5kIDYgaW4gdGhlIGZpcnN0IG5pYmJsZSkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIHBh Y2tldCBpcyBJUHY0IGFuZCBJUHY2IGFuZCB1c2Ugd2hhdCBpdA0KIHRoaW5rcyBhcmUgSVB2NCBh bmQgSVB2NiBmaWVsZHMgZm9yIEVDTVAgcHVycG9zZXM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYWtlIGEgcXVpY2sgbG9vayBhdCBSRkMgNDM4NSAtIHdo aWNoIGlzIHRoZSBjb250cm9sIHdvcmQgZm9yIHBzZXVkby13aXJlcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzaG9ydCBmb3JtIGlzIHRo YXQgYSBudW1iZXIgb2Ygcm91dGVycyBhdCB0aGUgdGltZSBwZWVrZWQgYmVuZWF0aCB0aGUgbGFi ZWwgc3RhY2sgdG8gZmlndXJlIG91dCB3aGV0aGVyIHdoYXQgd2FzIGluc2lkZSBhcyBJUHY0IG9y IElQdjYgYmFzZWQgc29sZWx5IHVwb24gdGhlIGZpcnN0IG5pYmJsZS4mbmJzcDsgQSByZWNvbW1l bmRhdGlvbiB3YXMgbWFkZSB0aGF0IHRoZSBjaGVja3N1bSBzaG91bGQgYWxzbyBiZQ0KIHZlcmlm aWVkLCBidXQgdGhlIG9ubHkgZXF1aXBtZW50IHRoYXQgSSdtIGNlcnRhaW4gb2YgdGhhdCBkaWQg dGhhdCBpc24ndCBhcm91bmQgYW55bW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBsb29rIGF0IFNlY3Rpb24gMi40IG9mIFJGQyA3 MzI1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbGlhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NClRoYW5rcyw8YnI+DQombmJzcDsgJm5ic3A7RXJpazxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KWGlhb2h1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uY2UgSSBrbm93IHRoYXQg YW5zd2VyIHdlIGNhbiBkZWZpbml0ZWx5IGFkZCBzb21lIHRleHQgcG9pbnRpbmcgb3V0IHRoZSBp c3N1ZS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtFcmlrPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogRXJpayBO b3JkbWFyayBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpub3JkbWFya0Bzb25pYy5uZXQiIHRhcmdl dD0iX2JsYW5rIj5ub3JkbWFya0Bzb25pYy5uZXQ8L2E+XTxicj4NClNlbnQ6IDIwMTU8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+MzxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4yNjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwvc3Bhbj4g NTowMTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24g Y29uc2lkZXJhdGlvbnM8YnI+DQo8YnI+DQo8YnI+DQpJIHByZXNlbnRlZCBwYXJ0IG9mIHRoaXMg YXQgdGhlIG1vc3QgcmVjZW50IE5WTzMgaW50ZXJpbSBtZWV0aW5nLlRoZTxicj4NCmZ1bGw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEyPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hcmVhcyBvZiBjb25zaWRlcmF0aW9ucyB3aGVyZSBwcmVzZW50ZWQg YXQgUlRHV0cgZWFybGllciB0aGlzIHdlZWsuPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgZHJhZnQg aXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJ0Zy1kdC1lbmNhcC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnRnLWR0LWVuY2FwLzwvYT48YnI+DQom bmJzcDsgJm5ic3A7IGFuZCB0aGUgc2xpZGVzIGFyZSBhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xp ZGVzLTkyLXJ0Z3dnLTgucGRmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgucGRmPC9hPjxicj4NCjxicj4N ClRoZXJlIGlzIHByb2JhYmx5IGFkZGl0aW9uYWwgdGhpbmdzIGluIHRoZXJlIHRvIGNvbnNpZGVy IGZvciBOVk8zLDxicj4NCmFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YWR2aWNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPnRoYXQgY2FuIGJlIHJldXNlZCB0byBtYWtlIGl0IGVhc2llciB0byBt b3ZlIE5WTzMgZm9yd2FyZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IEVyaWs8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpudm8zIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpudm8zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZvM0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL252bzM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+c2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpCSUVSIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIj5CSUVSQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllciIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllcjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E6C17D2345AC7A45B7D054D407AA205C393B878Aeusaamb105erics_-- From nobody Thu Apr 9 16:17:00 2015 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 DB3641B3541; Thu, 9 Apr 2015 15:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 I-CY_1sqUw5x; Thu, 9 Apr 2015 15:50:33 -0700 (PDT) Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id BDF451B3534; Thu, 9 Apr 2015 15:50:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,552,1422950400"; d="scan'208";a="61710338" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 09 Apr 2015 15:55:35 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 9 Apr 2015 15:50:33 -0700 Received: from SJEXCHMB06.corp.ad.broadcom.com ([fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 9 Apr 2015 15:50:32 -0700 From: Ian Cox To: Erik Nordmark , Xuxiaohu , "nvo3@ietf.org" Thread-Topic: [Bier] [nvo3] Encapsulation considerations Thread-Index: AQHQclja5X+vlmoZrkq2Qyp/IFKZP51EaByAgAED1ID//9vF8A== Date: Thu, 9 Apr 2015 22:50:31 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> In-Reply-To: <5526BBDB.3000805@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2015 16:16:58 -0700 Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [sfc] [Bier] [nvo3] Encapsulation considerations 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, 09 Apr 2015 22:50:38 -0000 TVBMUyBoYXMgbm8gaW5kaWNhdGlvbiBpbiB0aGUgbGFiZWwgc3RhY2sgZm9yIGludGVybWVkaWF0 ZSBub2RlcyB3aGF0IHRoZSB1bmRlcmx5aW5nIHBheWxvYWQgaXMuICBUbyBhY2hpZXZlIGJldHRl ciBsb2FkIGJhbGFuY2luZyBvZiBNUExTIHRyYWZmaWMgbW9zdCBoYXJkd2FyZSB0b2RheSBsb29r cyB0byBzZWUgaWYgdGhlIGZpcnN0IG5pYmJsZSBpcyA0IG9yIDYgdGhlbiBwYXJzZSBpbnRvIHRo ZSBwYXlsb2FkIHVuZGVyIHRoZSBiZWxpZWYgdGhhdCBpdCBpcyBhIElQdjQgb3IgdjYgcGFja2V0 IGFuZCBwYXJzZSB0aGUgYWRkcmVzcyBmaWVsZHMgb3V0IHRvIHVzZSBpbiB0aGUgRUNNUCBoYXNo LiAgSWYgeW91ciBkZWZpbmluZyBzb21ldGhpbmcgbmV3IHBsZWFzZSBwdXQgYSAibmV4dCBwcm90 b2NvbCIgb3IgdHlwZSBmaWVsZCBpbiB0aGUgcHJlY2VkaW5nIGhlYWRlciBzbyBpdCBjbGVhciB3 aGF0IHRoZSBuZXh0IHByb3RvY29sIGlzLiAgVGhlIDQgb3IgNiBndWVzcyBmb3IgdGhlIHVuZGVy bHlpbmcgTVBMUyBwYXlsb2FkIGJlaW5nIGFuIElQIHBhY2tldCB3YXMgZmluZSB1bnRpbCBJRUVF IGFsbG9jYXRlZCBNQUMgYWRkcmVzc2VzIHN0YXJ0aW5nIHdpdGggNi4gVGhpcyBpc3N1ZSBpcyBz cGVjaWZpYyBQV0UzIHBhY2tldHMgdGhhdCBkbyBub3QgY29udGFpbiB0aGUgY29udHJvbCB3b3Jk Lg0KDQoNCklhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQklFUiBbbWFp bHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWsgTm9yZG1hcmsNClNl bnQ6IFRodXJzZGF5LCBBcHJpbCAwOSwgMjAxNSAxMDo1MCBBTQ0KVG86IFh1eGlhb2h1OyBFcmlr IE5vcmRtYXJrOyBudm8zQGlldGYub3JnDQpDYzogbXBsc0BpZXRmLm9yZzsgQklFUjsgc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW0JpZXJdIFtudm8zXSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVy YXRpb25zDQoNCk9uIDQvOC8xNSA3OjIwIFBNLCBYdXhpYW9odSB3cm90ZToNCj4gSGkgRXJpaywN Cj4NCj4+IEJ1dCBJIGNvdWxkbid0IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxp c3Qgd2hldGhlciB0aGUgDQo+PiBjb25zdHJhaW50cyBvbiB0aGUgZmlyc3QgbmliYmxlIHZhbHVl IGlzIGEgc3RyaWN0IHJlcXVpcmVtZW50IGluIGFsbCANCj4+IGNhc2VzLCBvciB3aGV0aGVyIGl0 IGlzIGNvbmRpdGlvbmFsIG9uIHNvbWV0aGluZyAoYW5kIGlmIHNvLCB3aGF0IGlzIA0KPj4gdGhl IGNvbmRpdGlvbikuIA0KPiBUaGUgY29uZGl0aW9ucyB0aGF0IEkgaGF2ZSB0aG91Z2h0IG9mIGlu Y2x1ZGU6IDEpIHRoZSBlbmNhcHN1bGF0aW9uIGlzIHNlbnNpdGl2ZSB0byBwYWNrZXQgbWlzb3Jk ZXJpbmc7IDIpIHRoZSBlbmNhcHN1bGF0aW9uIG1heSBiZSB0cmFuc3BvcnRlZCBvdmVyIGFuIE1Q TFMgUFNOOyAzKSBMU1JzIHdpdGhpbiB0aGF0IE1QTFMgUFNOIG1heSB1c2UgdGhlIGNvbnRlbnRz IG9mIHRoZSBNUExTIHBheWxvYWQgdG8gc2VsZWN0IHRoZSBFQ01QIHBhdGguDQpUaG9zZSBhcmUg Y29uZGl0aW9ucyB3aGVuIHRoZSBtaXNvcmRlcmluZyB3b3VsZCBoYXBwZW4uIEJ1dCBhcmUgeW91 IA0Kc2F5aW5nIHRoYXQgYW55IExTUiBpcyBmcmVlIHRvIHVzZSB0aGUgTVBMUyBwYXlsb2FkIChp bmNsdWRpbmcgbG9va2luZyANCmZvciA0IGFuZCA2IGluIHRoZSBmaXJzdCBuaWJibGUpIHRvIGRl dGVybWluZSB3aGV0aGVyIHRoZSBwYWNrZXQgaXMgSVB2NCANCmFuZCBJUHY2IGFuZCB1c2Ugd2hh dCBpdCB0aGlua3MgYXJlIElQdjQgYW5kIElQdjYgZmllbGRzIGZvciBFQ01QIHB1cnBvc2VzPw0K DQpUaGFua3MsDQogICAgRXJpaw0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+ PiBPbmNlIEkga25vdyB0aGF0IGFuc3dlciB3ZSBjYW4gZGVmaW5pdGVseSBhZGQgc29tZSB0ZXh0 IHBvaW50aW5nIG91dCB0aGUgaXNzdWUuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gICAgICBFcmlrDQo+ Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBYaWFvaHUNCj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86bm9yZG1hcmtA c29uaWMubmV0XQ0KPj4+PiBTZW50OiAyMDE15bm0M+aciDI25pelIDU6MDENCj4+Pj4gVG86IG52 bzNAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJh dGlvbnMNCj4+Pj4NCj4+Pj4NCj4+Pj4gSSBwcmVzZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBt b3N0IHJlY2VudCBOVk8zIGludGVyaW0gbWVldGluZy5UaGUNCj4+Pj4gZnVsbA0KPj4+IDEyDQo+ Pj4+IGFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdoZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJs aWVyIHRoaXMgd2Vlay4NCj4+Pj4gICAgIFRoZSBkcmFmdCBpcw0KPj4+PiAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJ0Zy1kdC1lbmNhcC8NCj4+Pj4gICAgIGFu ZCB0aGUgc2xpZGVzIGFyZSBhdA0KPj4+PiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1ydGd3Zy04LnBkZg0KPj4+Pg0KPj4+PiBUaGVyZSBp cyBwcm9iYWJseSBhZGRpdGlvbmFsIHRoaW5ncyBpbiB0aGVyZSB0byBjb25zaWRlciBmb3IgTlZP MywNCj4+Pj4gYW5kDQo+Pj4gYWR2aWNlDQo+Pj4+IHRoYXQgY2FuIGJlIHJldXNlZCB0byBtYWtl IGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2FyZC4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+ Pj4gICAgICAgRXJpaw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+PiBu dm8zQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u dm8zDQo+Pj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCg== From nobody Thu Apr 9 18:37:22 2015 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 8F6461A8A83; Thu, 9 Apr 2015 18:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 aOR-A60Ak0el; Thu, 9 Apr 2015 18:37:14 -0700 (PDT) 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 51C831A0007; Thu, 9 Apr 2015 18:37:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRF73625; Fri, 10 Apr 2015 01:37:11 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 02:37:10 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 09:37:06 +0800 From: Xuxiaohu To: Ian Cox , Erik Nordmark , "nvo3@ietf.org" Thread-Topic: [Bier] [nvo3] Encapsulation considerations Thread-Index: AQHQcljZ0fVc246YHEKvkFIl2pYVuJ1D7uKAgACBmYCAAFPggIAArZvw Date: Fri, 10 Apr 2015 01:37:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE083246E5@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [sfc] [Bier] [nvo3] Encapsulation considerations 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, 10 Apr 2015 01:37:16 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJYW4gQ294IFttYWlsdG86aWNv eEBicm9hZGNvbS5jb21dDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTAsIDIwMTUgNjo1MSBBTQ0K PiBUbzogRXJpayBOb3JkbWFyazsgWHV4aWFvaHU7IG52bzNAaWV0Zi5vcmcNCj4gQ2M6IG1wbHNA aWV0Zi5vcmc7IEJJRVI7IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0JpZXJdIFtudm8z XSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zDQo+IA0KPiBNUExTIGhhcyBubyBpbmRpY2F0 aW9uIGluIHRoZSBsYWJlbCBzdGFjayBmb3IgaW50ZXJtZWRpYXRlIG5vZGVzIHdoYXQgdGhlDQo+ IHVuZGVybHlpbmcgcGF5bG9hZCBpcy4gIFRvIGFjaGlldmUgYmV0dGVyIGxvYWQgYmFsYW5jaW5n IG9mIE1QTFMgdHJhZmZpYyBtb3N0DQo+IGhhcmR3YXJlIHRvZGF5IGxvb2tzIHRvIHNlZSBpZiB0 aGUgZmlyc3QgbmliYmxlIGlzIDQgb3IgNiB0aGVuIHBhcnNlIGludG8gdGhlDQo+IHBheWxvYWQg dW5kZXIgdGhlIGJlbGllZiB0aGF0IGl0IGlzIGEgSVB2NCBvciB2NiBwYWNrZXQgYW5kIHBhcnNl IHRoZSBhZGRyZXNzDQo+IGZpZWxkcyBvdXQgdG8gdXNlIGluIHRoZSBFQ01QIGhhc2guICBJZiB5 b3VyIGRlZmluaW5nIHNvbWV0aGluZyBuZXcgcGxlYXNlIHB1dCBhDQo+ICJuZXh0IHByb3RvY29s IiBvciB0eXBlIGZpZWxkIGluIHRoZSBwcmVjZWRpbmcgaGVhZGVyIHNvIGl0IGNsZWFyIHdoYXQg dGhlIG5leHQNCg0KSXMgaXQgdG9vIGxhdGUgdG8gZml4IHRoYXQgZmxhdyBvZiB0aGUgTVBMUyBh cmNoaXRlY3R1cmUgKGUuZy4sIHRoZSBsYWNrIG9mIGFuIGV4cGxpY2l0IHByb3RvY29sIGlkIGZp ZWxkKT8gT3IgdGhhdCBmbGF3IGlzIGJlbGlldmVkIGFzIGFuIGluY29tcGxldGUgYmVhdXR5IGFu ZCB0aGVyZWZvcmUgc2hvdWxkIGJlIHByZXNlcnZlZCBmb3JldmVyPyANCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gcHJvdG9jb2wgaXMuICBUaGUgNCBvciA2IGd1ZXNzIGZvciB0aGUgdW5k ZXJseWluZyBNUExTIHBheWxvYWQgYmVpbmcgYW4gSVANCj4gcGFja2V0IHdhcyBmaW5lIHVudGls IElFRUUgYWxsb2NhdGVkIE1BQyBhZGRyZXNzZXMgc3RhcnRpbmcgd2l0aCA2LiBUaGlzIGlzc3Vl IGlzDQo+IHNwZWNpZmljIFBXRTMgcGFja2V0cyB0aGF0IGRvIG5vdCBjb250YWluIHRoZSBjb250 cm9sIHdvcmQuDQoNCj4gDQo+IElhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVyaWsgTm9yZG1hcmsNCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA5LCAyMDE1IDEwOjUwIEFN DQo+IFRvOiBYdXhpYW9odTsgRXJpayBOb3JkbWFyazsgbnZvM0BpZXRmLm9yZw0KPiBDYzogbXBs c0BpZXRmLm9yZzsgQklFUjsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQmllcl0gW252 bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnMNCj4gDQo+IE9uIDQvOC8xNSA3OjIwIFBN LCBYdXhpYW9odSB3cm90ZToNCj4gPiBIaSBFcmlrLA0KPiA+DQo+ID4+IEJ1dCBJIGNvdWxkbid0 IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxpc3Qgd2hldGhlciB0aGUNCj4gPj4g Y29uc3RyYWludHMgb24gdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZSBpcyBhIHN0cmljdCByZXF1aXJl bWVudCBpbiBhbGwNCj4gPj4gY2FzZXMsIG9yIHdoZXRoZXIgaXQgaXMgY29uZGl0aW9uYWwgb24g c29tZXRoaW5nIChhbmQgaWYgc28sIHdoYXQgaXMNCj4gPj4gdGhlIGNvbmRpdGlvbikuDQo+ID4g VGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBvZiBpbmNsdWRlOiAxKSB0aGUgZW5j YXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUNCj4gdG8gcGFja2V0IG1pc29yZGVyaW5nOyAyKSB0aGUg ZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhbiBNUExTDQo+IFBTTjsgMykg TFNScyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250ZW50cyBvZiB0aGUgTVBM UyBwYXlsb2FkIHRvDQo+IHNlbGVjdCB0aGUgRUNNUCBwYXRoLg0KPiBUaG9zZSBhcmUgY29uZGl0 aW9ucyB3aGVuIHRoZSBtaXNvcmRlcmluZyB3b3VsZCBoYXBwZW4uIEJ1dCBhcmUgeW91IHNheWlu Zw0KPiB0aGF0IGFueSBMU1IgaXMgZnJlZSB0byB1c2UgdGhlIE1QTFMgcGF5bG9hZCAoaW5jbHVk aW5nIGxvb2tpbmcgZm9yIDQgYW5kIDYgaW4gdGhlDQo+IGZpcnN0IG5pYmJsZSkgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgdGhlIHBhY2tldCBpcyBJUHY0IGFuZCBJUHY2IGFuZCB1c2Ugd2hhdCBpdA0K PiB0aGlua3MgYXJlIElQdjQgYW5kIElQdjYgZmllbGRzIGZvciBFQ01QIHB1cnBvc2VzPw0KPiAN Cj4gVGhhbmtzLA0KPiAgICAgRXJpaw0KPiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBY aWFvaHUNCj4gPg0KPiA+PiBPbmNlIEkga25vdyB0aGF0IGFuc3dlciB3ZSBjYW4gZGVmaW5pdGVs eSBhZGQgc29tZSB0ZXh0IHBvaW50aW5nIG91dCB0aGUNCj4gaXNzdWUuDQo+ID4+DQo+ID4+IFRo YW5rcywNCj4gPj4gICAgICBFcmlrDQo+ID4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+PiBY aWFvaHUNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBG cm9tOiBFcmlrIE5vcmRtYXJrIFttYWlsdG86bm9yZG1hcmtAc29uaWMubmV0XQ0KPiA+Pj4+IFNl bnQ6IDIwMTXlubQz5pyIMjbml6UgNTowMQ0KPiA+Pj4+IFRvOiBudm8zQGlldGYub3JnDQo+ID4+ Pj4gU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlvbnMNCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4gSSBwcmVzZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2Vu dCBOVk8zIGludGVyaW0NCj4gPj4+PiBtZWV0aW5nLlRoZSBmdWxsDQo+ID4+PiAxMg0KPiA+Pj4+ IGFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdoZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVy IHRoaXMgd2Vlay4NCj4gPj4+PiAgICAgVGhlIGRyYWZ0IGlzDQo+ID4+Pj4gICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ydGctZHQtZW5jYXAvDQo+ID4+Pj4gICAg IGFuZCB0aGUgc2xpZGVzIGFyZSBhdA0KPiA+Pj4+DQo+ID4+Pj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLXJ0Z3dnLTgucGRmDQo+ID4+Pj4NCj4g Pj4+PiBUaGVyZSBpcyBwcm9iYWJseSBhZGRpdGlvbmFsIHRoaW5ncyBpbiB0aGVyZSB0byBjb25z aWRlciBmb3IgTlZPMywNCj4gPj4+PiBhbmQNCj4gPj4+IGFkdmljZQ0KPiA+Pj4+IHRoYXQgY2Fu IGJlIHJldXNlZCB0byBtYWtlIGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2FyZC4NCj4gPj4+ Pg0KPiA+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4gICAgICAgRXJpaw0KPiA+Pj4+DQo+ID4+Pj4NCj4g Pj4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4+PiBudm8zQGlldGYub3JnDQo+ID4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4gPj4+DQo+ID4NCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJJ RVIgbWFpbGluZyBsaXN0DQo+IEJJRVJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyDQo= From nobody Thu Apr 9 20:34:41 2015 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 8333E1AC3EC; Thu, 9 Apr 2015 20:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 cxl2UdCFB4pd; Thu, 9 Apr 2015 20:34:33 -0700 (PDT) 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 7F3221AC3E9; Thu, 9 Apr 2015 20:34:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRF80664; Fri, 10 Apr 2015 03:34:30 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Apr 2015 04:34:29 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 10 Apr 2015 11:34:26 +0800 From: Xuxiaohu To: Tony Przygienda , Alia Atlas Thread-Topic: [Bier] [sfc] [nvo3] Encapsulation considerations Thread-Index: AQHQcljZ0fVc246YHEKvkFIl2pYVuJ1D7uKAgACBmYCAAAMiAIAABIUAgAETRwA= Date: Fri, 10 Apr 2015 03:34:25 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Erik Nordmark , "nvo3@ietf.org" , BIER , "sfc@ietf.org" , "mpls@ietf.org" Subject: Re: [sfc] [Bier] [nvo3] Encapsulation considerations 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, 10 Apr 2015 03:34:36 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KRnJvbTogVG9ueSBQcnp5Z2llbmRhIFttYWlsdG86dG9ueXNpZXRmQGdtYWls LmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMTAsIDIwMTUgMjoxOCBBTQ0KVG86IEFsaWEgQXRs YXMNCkNjOiBFcmlrIE5vcmRtYXJrOyBCSUVSOyBtcGxzQGlldGYub3JnOyBYdXhpYW9odTsgbnZv M0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0JpZXJdIFtzZmNdIFtudm8z XSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zDQoNCkkgd291bGQgdmVudHVyZSB0byBzYXkg dGhhdA0KYS4gICAgICBCSUVSIG1pc29yZGVyaW5nIHdvdWxkIGJlIGEgYmFkIHRoaW5nIGZvciBt YW55IGFwcGxpY2F0aW9ucyBidXQgSSBkbyBub3QgdGhpbmsgdGhhdCB0aGUgZW5jYXBzdWxhdGlv biBwZXIgc2UgbWlzb3JkZXJzIG9yIG5vdCBhcyBwcm9wZXJ0eSwgaXTigJlzIHRoZSB3YXkgdGhl IGludGVybWVkaWF0ZSByb3V0ZXJzIGFyZSBhbGxvd2VkIHRvIHBsYXkgc2hhbm5pZ2FucyAob3Ig c2VlbiBkaWZmZXJlbnRseSwg4oCYaGV1cmlzdGljYWxseeKAmSBjb21lIHVwIHdpdGggdGhpbmdz IGdpdmVuIHVuY2xlYXIgc2VtYW50aWNzIG9mIHRoZSBlbmNhcHMpIHRoYXQgY2F1c2VzIG1pc29y ZGVyaW5nLiBTbyBpdCBpcyB1cCB0byB0aGUgZW5jYXBzIHRvIGdpdmUgZW5vdWdoIGluZm8gc28g dGhlIHJvdXRlcnMgaW4gdGhlIG1pZGRsZSBkbyB0aGUg4oCYcmlnaHQgdGhpbmfigJkuIE1vZHVs byBoaXN0b3JpY2FsIHByb2JsZW1zIHdpdGggQ1cgc3VwcG9ydCBhbmQgc28gb24g4oCmDQpiLiAg ICAgIFRoaXMgZmxhdm9yIG9mIGRpc2N1c3Npb24gaXMgcmVwZWF0aW5nLCBlLmcuIGVWUE4gUkZD IHdpdGggdGhlIENXL25vIENXIGRlYmF0ZSB3aGljaCBJIGNvdWxkIHJlc3RvcmUgb25seSBwYXJ0 aWFsbHkgYW5kIG90aGVyIGdyb3VwcyBub3cg4oCmDQoNCk9LLCBsZW1tZSBzdGljayBteSAobmHD r3ZlIDstKSBoZWFkIGZhciBvdXQ6IHdoeSBkbyBlbmNhcHMgZ3VpZGVsaW5lcyBmb3IgZXZlcnl0 aGluZyB0aGF0IGNhbiBnbyBvdmVyIFBTTiBub3QgbWFuZGF0ZSBDVyBmcm9tIG5vdyBvbj8gRXhp c3RpbmcgZ2VhciBhbmQgaGlzdG9yaWNhbCBSRkNzIHN1cHBvcnRlZCB1bnRpbCB0aGV5IHBldGVy IG91dCBhbmQgZW50cm9weSBsYWJlbHMgYmVpbmcgYW4gb3J0aG9nb25hbCBtZWNoYW5pc20g4oCm ICBPciBkbyB3ZSB0aGluayB0aGUg4oCYaGV1cmlzdGljYWwgRFBJJyBpcyBhIGJvdHRvbWxlc3Mg Ym94IG9mIGJhbmQtYWlkcyA/DQpbWGlhb2h1XSBXb3VsZG7igJl0IGl0IGJlIGJldHRlciB0byBp bnNlcnQgYSBwcm90b2NvbCBpZCBmaWVsZCB0aGFuIHRvIGluc2VydCBhIENXPyBUaGUgbGF0dGVy IGNvdWxkIG9ubHkgdGVsbCB5b3UgdGhlIE1QTFMgcGF5bG9hZCBpcyBub3QgSVAgcGF5bG9hZCB3 aGlsZSB0aGUgZm9ybWVyIGNvdWxkIHRlbGwgeW91IHdoYXQgdGhlIE1QTFMgcGF5bG9hZCBpcy4g QXMgRXJpYyBtZW50aW9uZWQgcHJldmlvdXNseSBpbiB0aGUgQklFUiBtYWlsaW5nLWxpc3QsIGl0 4oCZcyB1c2VmdWwgZm9yIGludGVybWVkaWF0ZSByb3V0ZXJzIHRvIGtub3cgd2hldGhlciB0aGUg TVBMUyBwYXlsb2FkIGlzIGEgQklFUiBwYWNrZXQuIEluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0ICho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndWljaGFyZC1zZmMtbXBscy1tZXRhZGF0 YS0wMCkgYWxzbyBtZW50aW9uZWQgdGhlIG5lZWQgb2YgZGV0ZXJtaW5pbmcgdGhlIE1QTFMgcGF5 bG9hZCAoaS5lLiwganVzdCBrbm93aW5nIHRoZSBwYXlsb2FkIGlzIG5vdCBhbiBJUCBwYXlsb2Fk IGlzIG5vdCBlbm91Z2gpLiBIb3dldmVyLCB0aGUgYXBwcm9hY2ggYXMgZGVmaW5lZCBpbiB0aGlz IGRyYWZ0IGlzIG9ubHkgYXBwbGljYWJsZSBvZiBpbmRpY2F0aW5nIHRoZSBwcmVzZW5jZSBvZiBt ZXRhZGF0YSB3aXRoaW4gYW4gTVBMUyBwYWNrZXQuIFdvdWxkbuKAmXQgaXQgYmUgYmV0dGVyIHRv IGdvIGEgc3RlcCBmdXJ0aGVyIChpLmUuLCBpbnNlcnRpbmcgYSBwcm90b2NvbCBpZCBmaWVsZCBi ZXR3ZWVuIHRoZSBsYWJlbCBzdGFjayBhbmQgdGhlIE1QTFMgcGF5bG9hZCk/IEluIHRoaXMgd2F5 LCBpdOKAmXMgYXBwbGljYWJsZSBvZiBpbmRpY2F0aW5nIHdoYXRldmVyIE1QTFMgcGF5bG9hZHMg YW5kIHRoZXJlZm9yZSBpdCB3b3VsZCBub3QgbmVlZCB0aG9zZSBNUExTIHBheWxvYWRzIHRoZW1z ZWx2ZXMgdG8gaW5kaWNhdGUgdGhlIHBheWxvYWQgdHlwZXMgKGkuZS4sIGJ5IHVzaW5nIHRoZSBm aXJzdCBuaWJibGUgYXMgYSBwb29yLW1hbuKAmXMgcHJvdG9jb2wgaWQgZmllbGQpLg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQotLS0gdG9ueQ0KDQpPbiBUaHUsIEFwciA5LCAyMDE1IGF0IDExOjAx IEFNLCBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5j b20+PiB3cm90ZToNCk9uIFRodSwgQXByIDksIDIwMTUgYXQgMTo1MCBQTSwgRXJpayBOb3JkbWFy ayA8bm9yZG1hcmtAYWNtLm9yZzxtYWlsdG86bm9yZG1hcmtAYWNtLm9yZz4+IHdyb3RlOg0KT24g NC84LzE1IDc6MjAgUE0sIFh1eGlhb2h1IHdyb3RlOg0KSGkgRXJpaywNCkJ1dCBJIGNvdWxkbid0 IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxpc3Qgd2hldGhlciB0aGUgY29uc3Ry YWludHMgb24gdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZSBpcyBhIHN0cmljdCByZXF1aXJlbWVudCBp biBhbGwgY2FzZXMsIG9yIHdoZXRoZXIgaXQgaXMgY29uZGl0aW9uYWwgb24gc29tZXRoaW5nIChh bmQgaWYgc28sIHdoYXQgaXMgdGhlIGNvbmRpdGlvbikuDQpUaGUgY29uZGl0aW9ucyB0aGF0IEkg aGF2ZSB0aG91Z2h0IG9mIGluY2x1ZGU6IDEpIHRoZSBlbmNhcHN1bGF0aW9uIGlzIHNlbnNpdGl2 ZSB0byBwYWNrZXQgbWlzb3JkZXJpbmc7IDIpIHRoZSBlbmNhcHN1bGF0aW9uIG1heSBiZSB0cmFu c3BvcnRlZCBvdmVyIGFuIE1QTFMgUFNOOyAzKSBMU1JzIHdpdGhpbiB0aGF0IE1QTFMgUFNOIG1h eSB1c2UgdGhlIGNvbnRlbnRzIG9mIHRoZSBNUExTIHBheWxvYWQgdG8gc2VsZWN0IHRoZSBFQ01Q IHBhdGguDQpUaG9zZSBhcmUgY29uZGl0aW9ucyB3aGVuIHRoZSBtaXNvcmRlcmluZyB3b3VsZCBo YXBwZW4uIEJ1dCBhcmUgeW91IHNheWluZyB0aGF0IGFueSBMU1IgaXMgZnJlZSB0byB1c2UgdGhl IE1QTFMgcGF5bG9hZCAoaW5jbHVkaW5nIGxvb2tpbmcgZm9yIDQgYW5kIDYgaW4gdGhlIGZpcnN0 IG5pYmJsZSkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIHBhY2tldCBpcyBJUHY0IGFuZCBJUHY2 IGFuZCB1c2Ugd2hhdCBpdCB0aGlua3MgYXJlIElQdjQgYW5kIElQdjYgZmllbGRzIGZvciBFQ01Q IHB1cnBvc2VzPw0KDQpUYWtlIGEgcXVpY2sgbG9vayBhdCBSRkMgNDM4NSAtIHdoaWNoIGlzIHRo ZSBjb250cm9sIHdvcmQgZm9yIHBzZXVkby13aXJlcy4NClRoZSBzaG9ydCBmb3JtIGlzIHRoYXQg YSBudW1iZXIgb2Ygcm91dGVycyBhdCB0aGUgdGltZSBwZWVrZWQgYmVuZWF0aCB0aGUgbGFiZWwg c3RhY2sgdG8gZmlndXJlIG91dCB3aGV0aGVyIHdoYXQgd2FzIGluc2lkZSBhcyBJUHY0IG9yIElQ djYgYmFzZWQgc29sZWx5IHVwb24gdGhlIGZpcnN0IG5pYmJsZS4gIEEgcmVjb21tZW5kYXRpb24g d2FzIG1hZGUgdGhhdCB0aGUgY2hlY2tzdW0gc2hvdWxkIGFsc28gYmUgdmVyaWZpZWQsIGJ1dCB0 aGUgb25seSBlcXVpcG1lbnQgdGhhdCBJJ20gY2VydGFpbiBvZiB0aGF0IGRpZCB0aGF0IGlzbid0 IGFyb3VuZCBhbnltb3JlLg0KDQpBbHNvIGxvb2sgYXQgU2VjdGlvbiAyLjQgb2YgUkZDIDczMjUu DQoNCkFsaWENCg0KDQpUaGFua3MsDQogICBFcmlrDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K T25jZSBJIGtub3cgdGhhdCBhbnN3ZXIgd2UgY2FuIGRlZmluaXRlbHkgYWRkIHNvbWUgdGV4dCBw b2ludGluZyBvdXQgdGhlIGlzc3VlLg0KDQpUaGFua3MsDQogICAgIEVyaWsNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVyaWsgTm9yZG1h cmsgW21haWx0bzpub3JkbWFya0Bzb25pYy5uZXQ8bWFpbHRvOm5vcmRtYXJrQHNvbmljLm5ldD5d DQpTZW50OiAyMDE15bm0M+aciDI25pelIDU6MDENClRvOiBudm8zQGlldGYub3JnPG1haWx0bzpu dm8zQGlldGYub3JnPg0KU3ViamVjdDogW252bzNdIEVuY2Fwc3VsYXRpb24gY29uc2lkZXJhdGlv bnMNCg0KDQpJIHByZXNlbnRlZCBwYXJ0IG9mIHRoaXMgYXQgdGhlIG1vc3QgcmVjZW50IE5WTzMg aW50ZXJpbSBtZWV0aW5nLlRoZQ0KZnVsbA0KMTINCmFyZWFzIG9mIGNvbnNpZGVyYXRpb25zIHdo ZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVyIHRoaXMgd2Vlay4NCiAgICBUaGUgZHJhZnQg aXMNCiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnRnLWR0LWVu Y2FwLw0KICAgIGFuZCB0aGUgc2xpZGVzIGFyZSBhdA0KICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItcnRnd2ctOC5wZGYNCg0KVGhlcmUgaXMg cHJvYmFibHkgYWRkaXRpb25hbCB0aGluZ3MgaW4gdGhlcmUgdG8gY29uc2lkZXIgZm9yIE5WTzMs DQphbmQNCmFkdmljZQ0KdGhhdCBjYW4gYmUgcmV1c2VkIHRvIG1ha2UgaXQgZWFzaWVyIHRvIG1v dmUgTlZPMyBmb3J3YXJkLg0KDQpSZWdhcmRzLA0KICAgICAgRXJpaw0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpudm8zIG1haWxpbmcgbGlzdA0K bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnZvMw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJ RVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsN Cglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgVG9ueSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gVG9ueSBQcnp5Z2llbmRhIFttYWlsdG86dG9ueXNpZXRmQGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDEwLCAyMDE1IDI6MTggQU08YnI+ DQo8Yj5Ubzo8L2I+IEFsaWEgQXRsYXM8YnI+DQo8Yj5DYzo8L2I+IEVyaWsgTm9yZG1hcms7IEJJ RVI7IG1wbHNAaWV0Zi5vcmc7IFh1eGlhb2h1OyBudm8zQGlldGYub3JnOyBzZmNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtCaWVyXSBbc2ZjXSBbbnZvM10gRW5jYXBzdWxhdGlv biBjb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIHZlbnR1cmUg dG8gc2F5IHRoYXQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjU0LjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJJRVIgbWlzb3JkZXJpbmcg d291bGQgYmUgYSBiYWQgdGhpbmcgZm9yIG1hbnkgYXBwbGljYXRpb25zIGJ1dCBJIGRvIG5vdCB0 aGluayB0aGF0IHRoZSBlbmNhcHN1bGF0aW9uIHBlciBzZSBtaXNvcmRlcnMgb3Igbm90IGFzIHBy b3BlcnR5LCBpdOKAmXMgdGhlIHdheSB0aGUgaW50ZXJtZWRpYXRlDQogcm91dGVycyBhcmUgYWxs b3dlZCB0byBwbGF5IHNoYW5uaWdhbnMgKG9yIHNlZW4gZGlmZmVyZW50bHksIOKAmGhldXJpc3Rp Y2FsbHnigJkgY29tZSB1cCB3aXRoIHRoaW5ncyBnaXZlbiB1bmNsZWFyIHNlbWFudGljcyBvZiB0 aGUgZW5jYXBzKSB0aGF0IGNhdXNlcyBtaXNvcmRlcmluZy4gU28gaXQgaXMgdXAgdG8gdGhlIGVu Y2FwcyB0byBnaXZlIGVub3VnaCBpbmZvIHNvIHRoZSByb3V0ZXJzIGluIHRoZSBtaWRkbGUgZG8g dGhlIOKAmHJpZ2h0IHRoaW5n4oCZLg0KIE1vZHVsbyBoaXN0b3JpY2FsIHByb2JsZW1zIHdpdGgg Q1cgc3VwcG9ydCBhbmQgc28gb24g4oCmIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjU0LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMg Zmxhdm9yIG9mIGRpc2N1c3Npb24gaXMgcmVwZWF0aW5nLCBlLmcuIGVWUE4gUkZDIHdpdGggdGhl IENXL25vIENXIGRlYmF0ZSB3aGljaCBJIGNvdWxkIHJlc3RvcmUgb25seSBwYXJ0aWFsbHkgYW5k IG90aGVyIGdyb3VwcyBub3cg4oCmDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PSywgbGVtbWUgc3RpY2sgbXkgKG5hw692ZSA7LSkgaGVhZCBmYXIgb3V0OiB3aHkgZG8gZW5j YXBzIGd1aWRlbGluZXMgZm9yIGV2ZXJ5dGhpbmcNCiB0aGF0IGNhbiBnbyBvdmVyIFBTTiBub3Qg bWFuZGF0ZSBDVyBmcm9tIG5vdyBvbj8gRXhpc3RpbmcgZ2VhciBhbmQgaGlzdG9yaWNhbCBSRkNz IHN1cHBvcnRlZCB1bnRpbCB0aGV5IHBldGVyIG91dCBhbmQgZW50cm9weSBsYWJlbHMgYmVpbmcg YW4gb3J0aG9nb25hbCBtZWNoYW5pc20g4oCmICZuYnNwO09yIGRvIHdlIHRoaW5rIHRoZSDigJho ZXVyaXN0aWNhbCBEUEknIGlzIGEgYm90dG9tbGVzcyBib3ggb2YgYmFuZC1haWRzID8NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltYaWFvaHVdIFdvdWxkbuKAmXQgaXQgYmUgYmV0dGVyIHRvIGluc2VydCBhIHBy b3RvY29sIGlkIGZpZWxkIHRoYW4gdG8gaW5zZXJ0IGEgQ1c/IFRoZQ0KIGxhdHRlciBjb3VsZCBv bmx5IHRlbGwgeW91IHRoZSBNUExTIHBheWxvYWQgaXMgbm90IElQIHBheWxvYWQgd2hpbGUgdGhl IGZvcm1lciBjb3VsZCB0ZWxsIHlvdSB3aGF0IHRoZSBNUExTIHBheWxvYWQgaXMuIEFzIEVyaWMg bWVudGlvbmVkIHByZXZpb3VzbHkgaW4gdGhlIEJJRVIgbWFpbGluZy1saXN0LCBpdOKAmXMgdXNl ZnVsIGZvciBpbnRlcm1lZGlhdGUgcm91dGVycyB0byBrbm93IHdoZXRoZXIgdGhlIE1QTFMgcGF5 bG9hZCBpcyBhIEJJRVIgcGFja2V0Lg0KIEluIGFkZGl0aW9uLCB0aGlzIGRyYWZ0ICg8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndWljaGFyZC1zZmMtbXBscy1tZXRh ZGF0YS0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3VpY2hhcmQtc2ZjLW1w bHMtbWV0YWRhdGEtMDA8L2E+KSBhbHNvIG1lbnRpb25lZCB0aGUgbmVlZCBvZiBkZXRlcm1pbmlu ZyB0aGUgTVBMUyBwYXlsb2FkIChpLmUuLCBqdXN0IGtub3dpbmcgdGhlIHBheWxvYWQgaXMNCiBu b3QgYW4gSVAgcGF5bG9hZCBpcyBub3QgZW5vdWdoKS4gSG93ZXZlciwgdGhlIGFwcHJvYWNoIGFz IGRlZmluZWQgaW4gdGhpcyBkcmFmdCBpcyBvbmx5IGFwcGxpY2FibGUgb2YgaW5kaWNhdGluZyB0 aGUgcHJlc2VuY2Ugb2YgbWV0YWRhdGEgd2l0aGluIGFuIE1QTFMgcGFja2V0LiBXb3VsZG7igJl0 IGl0IGJlIGJldHRlciB0byBnbyBhIHN0ZXAgZnVydGhlciAoaS5lLiwgaW5zZXJ0aW5nIGEgcHJv dG9jb2wgaWQgZmllbGQgYmV0d2VlbiB0aGUgbGFiZWwNCiBzdGFjayBhbmQgdGhlIE1QTFMgcGF5 bG9hZCk/IEluIHRoaXMgd2F5LCBpdOKAmXMgYXBwbGljYWJsZSBvZiBpbmRpY2F0aW5nIHdoYXRl dmVyIE1QTFMgcGF5bG9hZHMgYW5kIHRoZXJlZm9yZSBpdCB3b3VsZCBub3QgbmVlZCB0aG9zZSBN UExTIHBheWxvYWRzIHRoZW1zZWx2ZXMgdG8gaW5kaWNhdGUgdGhlIHBheWxvYWQgdHlwZXMgKGku ZS4sIGJ5IHVzaW5nIHRoZSBmaXJzdCBuaWJibGUgYXMgYSBwb29yLW1hbuKAmXMgcHJvdG9jb2wg aWQgZmllbGQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C ZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLS0g dG9ueSZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBBcHIgOSwgMjAxNSBhdCAxMTowMSBBTSwgQWxp YSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+T24gVGh1LCBBcHIgOSwgMjAxNSBhdCAxOjUwIFBNLCBFcmlrIE5vcmRtYXJrICZs dDs8YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAYWNtLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmRt YXJrQGFjbS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gNC84LzE1IDc6MjAgUE0sIFh1eGlh b2h1IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEVyaWssPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkJ1dCBJIGNvdWxkbid0IHRlbGwgZnJvbSB0aGUgZW1haWxzIG9uIHRoZSBCSUVSIGxpc3Qg d2hldGhlciB0aGUgY29uc3RyYWludHMgb24gdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZSBpcyBhIHN0 cmljdCByZXF1aXJlbWVudCBpbiBhbGwgY2FzZXMsIG9yIHdoZXRoZXIgaXQgaXMgY29uZGl0aW9u YWwgb24gc29tZXRoaW5nIChhbmQgaWYgc28sIHdoYXQgaXMgdGhlIGNvbmRpdGlvbikuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhlIGNvbmRpdGlvbnMgdGhhdCBJIGhhdmUgdGhvdWdodCBvZiBpbmNsdWRlOiAxKSB0aGUg ZW5jYXBzdWxhdGlvbiBpcyBzZW5zaXRpdmUgdG8gcGFja2V0IG1pc29yZGVyaW5nOyAyKSB0aGUg ZW5jYXBzdWxhdGlvbiBtYXkgYmUgdHJhbnNwb3J0ZWQgb3ZlciBhbiBNUExTIFBTTjsgMykgTFNS cyB3aXRoaW4gdGhhdCBNUExTIFBTTiBtYXkgdXNlIHRoZSBjb250ZW50cyBvZiB0aGUNCiBNUExT IHBheWxvYWQgdG8gc2VsZWN0IHRoZSBFQ01QIHBhdGguPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRob3NlIGFyZSBjb25kaXRp b25zIHdoZW4gdGhlIG1pc29yZGVyaW5nIHdvdWxkIGhhcHBlbi4gQnV0IGFyZSB5b3Ugc2F5aW5n IHRoYXQgYW55IExTUiBpcyBmcmVlIHRvIHVzZSB0aGUgTVBMUyBwYXlsb2FkIChpbmNsdWRpbmcg bG9va2luZyBmb3IgNCBhbmQgNiBpbiB0aGUgZmlyc3QgbmliYmxlKSB0byBkZXRlcm1pbmUgd2hl dGhlciB0aGUgcGFja2V0IGlzIElQdjQgYW5kIElQdjYNCiBhbmQgdXNlIHdoYXQgaXQgdGhpbmtz IGFyZSBJUHY0IGFuZCBJUHY2IGZpZWxkcyBmb3IgRUNNUCBwdXJwb3Nlcz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UYWtlIGEgcXVpY2sgbG9vayBhdCBSRkMgNDM4 NSAtIHdoaWNoIGlzIHRoZSBjb250cm9sIHdvcmQgZm9yIHBzZXVkby13aXJlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIHNob3J0IGZvcm0gaXMgdGhhdCBhIG51bWJlciBvZiByb3V0ZXJzIGF0 IHRoZSB0aW1lIHBlZWtlZCBiZW5lYXRoIHRoZSBsYWJlbCBzdGFjayB0byBmaWd1cmUgb3V0IHdo ZXRoZXIgd2hhdCB3YXMgaW5zaWRlIGFzIElQdjQgb3IgSVB2NiBiYXNlZCBzb2xlbHkgdXBvbiB0 aGUgZmlyc3QgbmliYmxlLiZuYnNwOyBBIHJlY29tbWVuZGF0aW9uIHdhcyBtYWRlIHRoYXQgdGhl IGNoZWNrc3VtDQogc2hvdWxkIGFsc28gYmUgdmVyaWZpZWQsIGJ1dCB0aGUgb25seSBlcXVpcG1l bnQgdGhhdCBJJ20gY2VydGFpbiBvZiB0aGF0IGRpZCB0aGF0IGlzbid0IGFyb3VuZCBhbnltb3Jl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxzbyBs b29rIGF0IFNlY3Rpb24gMi40IG9mIFJGQyA3MzI1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJz cDtFcmlrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KQmVzdCByZWdh cmRzLDxicj4NClhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uY2Ug SSBrbm93IHRoYXQgYW5zd2VyIHdlIGNhbiBkZWZpbml0ZWx5IGFkZCBzb21lIHRleHQgcG9pbnRp bmcgb3V0IHRoZSBpc3N1ZS48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDtFcmlrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCByZWdhcmRz LDxicj4NClhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IEVyaWsgTm9yZG1hcmsgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bm9yZG1hcmtAc29uaWMubmV0 IiB0YXJnZXQ9Il9ibGFuayI+bm9yZG1hcmtAc29uaWMubmV0PC9hPl08YnI+DQpTZW50OiAyMDE1 PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4zPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4yNjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDU6MDE8YnI+DQpUbzogPGEgaHJlZj0i bWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFtudm8zXSBFbmNhcHN1bGF0aW9uIGNvbnNpZGVyYXRpb25zPGJyPg0KPGJy Pg0KPGJyPg0KSSBwcmVzZW50ZWQgcGFydCBvZiB0aGlzIGF0IHRoZSBtb3N0IHJlY2VudCBOVk8z IGludGVyaW0gbWVldGluZy5UaGU8YnI+DQpmdWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFyZWFzIG9mIGNv bnNpZGVyYXRpb25zIHdoZXJlIHByZXNlbnRlZCBhdCBSVEdXRyBlYXJsaWVyIHRoaXMgd2Vlay48 YnI+DQombmJzcDsgJm5ic3A7IFRoZSBkcmFmdCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcnRnLWR0LWVu Y2FwLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ydGctZHQtZW5jYXAvPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgYW5kIHRoZSBzbGlkZXMg YXJlIGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItcnRnd2ctOC5wZGYiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMt OTItcnRnd2ctOC5wZGY8L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgcHJvYmFibHkgYWRkaXRpb25h bCB0aGluZ3MgaW4gdGhlcmUgdG8gY29uc2lkZXIgZm9yIE5WTzMsPGJyPg0KYW5kPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFk dmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYXQgY2FuIGJlIHJldXNl ZCB0byBtYWtlIGl0IGVhc2llciB0byBtb3ZlIE5WTzMgZm9yd2FyZC48YnI+DQo8YnI+DQpSZWdh cmRzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEVyaWs8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm52bzMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZv MyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5zZmMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpCSUVSIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIj5CSUVSQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmll ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YmllcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08324770NKGEML512MBSchi_-- From nobody Sat Apr 11 11:58:37 2015 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 30A701B2C47 for ; Sat, 11 Apr 2015 11:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 teuRwJnzhruE for ; Sat, 11 Apr 2015 11:58:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 7CA9A1ACEA2 for ; Sat, 11 Apr 2015 11:58:34 -0700 (PDT) Received: from mb-aye.local (160.sub-70-211-1.myvzw.com [70.211.1.160]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3BIwWSG000395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Apr 2015 18:58:33 GMT (envelope-from joelja@bogus.com) To: Ian Cox , Erik Nordmark , Xuxiaohu , "nvo3@ietf.org" references: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832353F@NKGEML512-MBS.china.huawei.com> <5525C22C.1030303@acm.org> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08323BD3@NKGEML512-MBS.china.huawei.com> <5526BBDB.3000805@acm.org> From: joel jaeggli message-id: <55296ED2.9030204@bogus.com> Date: Sat, 11 Apr 2015 11:58:26 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN" Archived-At: Cc: "mpls@ietf.org" , BIER , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] [Bier] Encapsulation considerations 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: Sat, 11 Apr 2015 18:58:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/9/15 3:50 PM, Ian Cox wrote: > MPLS has no indication in the label stack for intermediate nodes what > the underlying payload is. To achieve better load balancing of MPLS > traffic most hardware today looks to see if the first nibble is 4 or > 6 then parse into the payload under the belief that it is a IPv4 or > v6 packet and parse the address fields out to use in the ECMP hash. Some of them also use the TOS or DSCP bits as part of the hashkey with the additional ensuing entertainment value that provides. > If your defining something new please put a "next protocol" or type > field in the preceding header so it clear what the next protocol is. > The 4 or 6 guess for the underlying MPLS payload being an IP packet > was fine until IEEE allocated MAC addresses starting with 6. This > issue is specific PWE3 packets that do not contain the control word. >=20 >=20 > Ian >=20 > -----Original Message----- From: BIER [mailto:bier-bounces@ietf.org] > On Behalf Of Erik Nordmark Sent: Thursday, April 09, 2015 10:50 AM=20 > To: Xuxiaohu; Erik Nordmark; nvo3@ietf.org Cc: mpls@ietf.org; BIER; > sfc@ietf.org Subject: Re: [Bier] [nvo3] Encapsulation considerations >=20 > On 4/8/15 7:20 PM, Xuxiaohu wrote: >> Hi Erik, >>=20 >>> But I couldn't tell from the emails on the BIER list whether the >>> constraints on the first nibble value is a strict requirement in >>> all cases, or whether it is conditional on something (and if so, >>> what is the condition). >> The conditions that I have thought of include: 1) the encapsulation >> is sensitive to packet misordering; 2) the encapsulation may be >> transported over an MPLS PSN; 3) LSRs within that MPLS PSN may use >> the contents of the MPLS payload to select the ECMP path. > Those are conditions when the misordering would happen. But are you=20 > saying that any LSR is free to use the MPLS payload (including > looking for 4 and 6 in the first nibble) to determine whether the > packet is IPv4 and IPv6 and use what it thinks are IPv4 and IPv6 > fields for ECMP purposes? >=20 > Thanks, Erik >=20 >>=20 >> Best regards, Xiaohu >>=20 >>> Once I know that answer we can definitely add some text pointing >>> out the issue. >>>=20 >>> Thanks, Erik >>>=20 >>>> Best regards, Xiaohu >>>>=20 >>>>> -----Original Message----- From: Erik Nordmark >>>>> [mailto:nordmark@sonic.net] Sent: 2015=E5=B9=B43=E6=9C=8826=E6=97=A5= 5:01 To: >>>>> nvo3@ietf.org Subject: [nvo3] Encapsulation considerations >>>>>=20 >>>>>=20 >>>>> I presented part of this at the most recent NVO3 interim >>>>> meeting.The full >>>> 12 >>>>> areas of considerations where presented at RTGWG earlier this >>>>> week. The draft is=20 >>>>> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ and the >>>>> slides are at=20 >>>>> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf >>>>> >>>>> >>>>>=20 There is probably additional things in there to consider for NVO3, >>>>> and >>>> advice >>>>> that can be reused to make it easier to move NVO3 forward. >>>>>=20 >>>>> Regards, Erik >>>>>=20 >>>>>=20 >>>>>=20 >>>> _______________________________________________ nvo3 mailing >>>> list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 >>>>=20 >>=20 >=20 > _______________________________________________ BIER mailing list=20 > BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier=20 > _______________________________________________ nvo3 mailing list=20 > nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 >=20 --UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUpbtMACgkQ8AA1q7Z/VrINqACeMRbp54zcWVo6pBHXm8GukO42 mIAAn1cqvs0a5eQLK26KUZIIBeIJyg2s =7sEa -----END PGP SIGNATURE----- --UnMxU96QRxfUMj5rPQ9blv0LQVFGp5UcN-- From nobody Mon Apr 13 00:59:52 2015 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 7413A1A896A for ; Mon, 13 Apr 2015 00:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 9-nlEJkGlXkh for ; Mon, 13 Apr 2015 00:59:47 -0700 (PDT) Received: from mc24.lon.server.colt.net (mc24.lon.server.colt.net [212.74.77.104]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC4F1A892B for ; Mon, 13 Apr 2015 00:59:46 -0700 (PDT) Received: from mc24.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 51C21DE288 for ; Mon, 13 Apr 2015 08:59:44 +0100 (BST) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc24.lon.server.colt.net (Postfix) with ESMTPS id 34C28DE280 for ; Mon, 13 Apr 2015 08:59:44 +0100 (BST) X-IronPort-AV: E=Sophos;i="5.11,568,1422918000"; d="scan'208";a="1634948" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.9]) by mx3.qosmos.com with ESMTP; 13 Apr 2015 09:59:43 +0200 Received: from CAROUBIER.jungle.qosmos.com ([169.254.1.132]) by LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4%14]) with mapi id 14.01.0438.000; Mon, 13 Apr 2015 09:59:43 +0200 From: Nicolas BOUTHORS To: "Joel M. Halpern" , Dave Dolson , Sunil Vallamkonda , "sfc@ietf.org" Thread-Topic: [sfc] Metadata and inserted packets Thread-Index: AQHQcahnOWclN7I7SUi84fizTL9sRJ1KkGBQ Date: Mon, 13 Apr 2015 07:59:42 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7FB325@CAROUBIER.jungle.qosmos.com> References: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.com> <552481AF.6020303@joelhalpern.com> In-Reply-To: <552481AF.6020303@joelhalpern.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1383-7.6.0.1031-21472.005 X-TM-AS-Result: No--21.972-5.0-31-10 X-imss-scan-details: No--21.972-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-9.0.0.1383-7.6.1031-21472.005 X-TMASE-Result: 10--21.971700-5.000000 X-TMASE-MatchedRID: B0+RG8xpjtSPrjM/ltMU+e9VsdrlGzy3QZXZg2I8JaajC1E/zCEIrzAp i0hTr2bdtSCkRsJOQ9cGdajbTv45cdELFBU3rAwzy7TSWcbz49ZVftPGBTR0rt9AcuyeVrEgNr7 D+S48oQv7mria/yRwJlHqzv7qaQgcBMj0MFuQQWqVUcz8XpiS9ECrr/LkAQ46rY9uF6odMlzMRU Madz4R8rmhl8vKoRQ6HqowHIqIBsVuOt28pPRUYj5lTEToxQ1VEeXPNyiMU06mdBo41X0qimtUy gsbhDwBIm1CiBNqnW8RpHQhHVRPTP85GCR7+GthJrUxoq6hvw8L8TGleseLPJSM2vr0PX/ELVCQ fSxiPcaEmmFz+RIbZixl8AW7jSya3Lit/ZLn13VHFWsq1vzd1BdnqTrUdQnPMxVjmK1sOgO4nEt c3+EQJsvnSCXBRWs5d7KoCIHTVwhiqZR3e04StS4uTw19Klh6esw8RnBRGwqXcnNUa+aFRdj4ib 1EjEkTOMG8/JVKkZo0S0/W73mBUbw0W8682qE1PIhgYrYFTMZAJ/ashI7fO6/10BLkgzmJ5o3Rm siWkPZRK2IsWVWBPrZI++wLI1khXRbTXzU+N9vKU6SUDu2Yh5JOcXMQc4jBEd+K6O5Nt52OSjkg rU5uA+6rxnCoEfKnSjovmgcp88j0MLyooWuV8bxygpRxo469yGlw1pWXiGzagsZM0qVv1+bGU8G B3wTOafcnFY/rkJAQsDYbh11w/E9YtDDzz0GUYh187EHd2qMtkTpJCcpFg5bFI4KuSdevo8WMkQ Wv6iUVR7DQWX/WkQGLeSok4rrZC24oEZ6SpSk+Mqg+CyrtwA== X-TMASE-SNAP-Result: 1.761031.0004-0-1-17:0,12:0 Archived-At: Subject: Re: [sfc] Metadata and inserted packets 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, 13 Apr 2015 07:59:50 -0000 SGVsbG8gYWxsLA0KDQpTdGFuZGFyZGl6YXRpb24gb2Ygd2VsbCBrbm93biBtZXRhZGF0YSB0eXBl cyBoYXMgYmVlbiBhZGRyZXNzZWQgZm9yIElQRlggKE5ldGZsb3cpIGluIHRoZSBjb250ZXh0IG9m IElBTkEuDQogU2VlIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXBmaXgvaXBmaXgu eGh0bWwNCg0KVGhlIElQRklYIDE2Yml0IEluZm9ybWF0aW9uIEVsZW1lbnQgaWRlbnRpdGllciBm aWVsZCBpcyBwcmV0dHkgbXVjaCB0aGUgc2FtZSBhcyB0aGUgTlNIICBUTFYgQ2xhc3MgZmllbGQu ICBJdCBoYXMgdGhlIHNhbWUgc2l6ZQ0KYW5kIHRoZSBzYW1lIG9iamVjdGl2ZSB3aGljaCBpcyB0 byBpZGVudGlmeSB0aGUgdHlwZSBvZiBNZXRhZGF0YSB0cmFuc3BvcnRlZC4NCg0KSVBGSVggUkZD NzAxMSBkZXNjcmliZXMgaG93IHRvIHRha2UgaW5mbyBhY2NvdW50IEVudHJlcHJpc2UgZXh0ZW5z aW9ucyByZWx5aW5nIG9uIGEgRmllbGQgU3BlY2lmaWVyICBGb3JtYXQgKHVzaW5nIGEgcmVzZXJ2 ZWQgRW50ZXJwcmlzZSBiaXQgaW4gdGhlICAxNmJpdCBJbmZvcm1hdGlvbiBFbGVtZW50IGlkZW50 aWZpZXIgZmllbGQpDQoNCkl0IGlzIHdvcnRoIGFkb3B0aW5nIHRoZSBzYW1lIG1vZGVsIGFzOg0K LSBJdCBpcyBhbHJlYWR5IHN0YW5kYXJkaXplZCwNCi0gSXQgaGFzIHJvb20gZm9yIGV4dGVuc2lv bnMNCi0gSXMgd2FzIGRlc2lnbmVkIHRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYXRvYmlsaXR5IGFu ZCBpcyBub3cgd2lkZWx5IHVzZWQuDQotIEl0IHdpbGwgZmFjaWxpdGF0ZSBTRkMgaW50ZWdyYXRp b24gd2l0aCBNb25pdG9yaW5nIGJhc2VkIHN5c3RlbSBmb3IgU0ZDIHRyYWZmaWMgKGF2b2lkaW5n IHVubmVjZXNzYXJ5IGNvbnZlcnNpb25zKQ0KDQoNCkkgcHJvcG9zZSB3ZSA6DQoxKSBzdXBwb3J0 IHRoZSBFbnRyZXByaXNlIGJpdCBpbiAgTlNIIFRMViBDbGFzcw0KMikgcmVmZXIgdG8gU2VlIGh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXBmaXgvaXBmaXgueGh0bWwgZm9yIHdlbGwg a25vd24gdmFsdWVzDQoNCg0KTmljb2xhcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NClNlbnQ6 IG1lcmNyZWRpIDggYXZyaWwgMjAxNSAwMzoxOA0KVG86IERhdmUgRG9sc29uOyBTdW5pbCBWYWxs YW1rb25kYTsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gTWV0YWRhdGEgYW5kIGlu c2VydGVkIHBhY2tldHMNCg0KSSB3b3VsZCBleHBlY3QgdGhhdCB0aGVyZSB3aWxsIG5lZWQgdG8g YmUgYXBwbGljYXRpb24gY29uZmlndXJhdGlvbiB0aGF0IGluZGljYXRlcyB3aGF0IG1ldGFkYXRh IHR5cGUgY29kZSBhIGdpdmVuIFNGIHNob3VsZCB1c2UgZm9yIGNvbW11bmljYXRlIHdoYXQgcGll Y2Ugb2YgaW5mb3JtYXRpb24uICBUaGlzICJ0eXBlIiBtaWdodCBiZSBhIHBvc2l0aW9uIGluIHRo ZSBmaXhlZCBNRC0xLCBvciBhIFRMViBjb2RlIGluIHRoZSBNRC0yLg0KDQpJIGRvIG5vdCBleHBl Y3QgdGhhdCB0aGUgcHJvdG9jb2wgZm9yIHByb3Zpc2lvbmluZyB0aGlzIHRvIHNlcnZpY2UgZnVu Y3Rpb25zIGlzIHBhcnQgb2YgU0ZDLCBhbnkgbW9yZSB0aGFuIGFsbCB0aGUgb3RoZXIgY29uZmln dXJhdGlvbiBpbmZvcm1hdGlvbiB0aGF0IGFwcGxpY2F0aW9ucyBuZWVkIHRvIGRvIHRoZWlyIGpv Yi4NCg0KV2hpbGUgSSB3b3VsZCBub3QgYmUgc3VycHJpc2VkIHRvIGV2ZW50dWFsbHkgaGF2ZSBh IHJlZ2lzdHJ5IG9mIHdlbGwta25vd24gdHlwZXMsIEkgZG8gbm90IHNlZSBhbnl3IGF5IHRvIGdl dCBhcm91bmQgbmVlZGluZyB0aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmb3IgbWFueSBz ZXJ2aWNlIGZ1bmN0aW9ucyB3aGljaCBjYXJlIGFib3V0IG1ldGFkYXRhLiAgVGhlcmUgaXMganVz dCBnb2luZyB0byBiZSB0b28gbXVjaCB2YXJpYWJpbGl0eS4NCg0KSSBob3BlIHRoYXQgd2UgZG8g bm90IGhhdmUgdG8gcHV0IHZlbmRvciBJRHMgaW50byB0aGUgdHlwZXMsIGFzIHRoZSBNRC0yIFRM ViBhbHJlYWR5IGxvb2tzIHRvIGJlIGxhcmdlciB0aGFuIHdlIGxpa2UuDQoNCllvdXJzLA0KSm9l bA0KDQpPbiA0LzcvMTUgMjo1OSBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQo+IFN1bmlsLA0KPg0K PiBIb3cgd291bGQgdGhlIFNGIGtub3cgdGhlIHNlbWFudGljcyBvZiB0aGUgbWV0YWRhdGEgd2l0 aCByZXNwZWN0IHRvDQo+IHBhY2tldCBpbmplY3Rpb24/DQo+DQo+IFdvdWxkIHlvdSBoYXZlIGFu IG91dC1vZi1iYW5kIGRpY3Rpb25hcnkgdGhhdCBtYXBzIHZlbmRvci90eXBlIHRvIHRoZQ0KPiBp bmZvcm1hdGlvbj8NCj4NCj4gKEUuZy4sIOKAnHZlbmRvci90eXBlIDEwMDEvMjcgaXMgYSBuZXR3 b3JrIHNlcGFyYXRpb24gaWRlbnRpZmllcuKAnSkNCj4NCj4gVGhlIHNlbWFudGljcyBjb3VsZCBh bHNvIGJlIHBsYWNlZCBpbi1iYW5kLCBpbiB0aGUgZm9ybSBvZiBhIGZpZWxkZC4NCj4NCj4gZmll bGQgdmFsdWVzOg0KPg0KPiAtIG5ldHdvcmsgc2VwYXJhdGlvbiBtZXRhZGF0YQ0KPg0KPiAtIHRy YW5zcG9ydCBmbG93IGF0dHJpYnV0ZSBtZXRhZGF0YQ0KPg0KPiAtIHNvdXJjZSBJUCBtZXRhZGF0 YQ0KPg0KPiAtIGRlc3RpbmF0aW9uIElQIG1ldGFkYXRhDQo+DQo+IC1EYXZlDQo+DQo+ICpGcm9t OipTdW5pbCBWYWxsYW1rb25kYSBbbWFpbHRvOnN1bmlsdmtAZjUuY29tXQ0KPiAqU2VudDoqIFR1 ZXNkYXksIEFwcmlsIDA3LCAyMDE1IDI6MDcgUE0NCj4gKlRvOiogRGF2ZSBEb2xzb247IHNmY0Bp ZXRmLm9yZw0KPiAqU3ViamVjdDoqIFJFOiBNZXRhZGF0YSBhbmQgaW5zZXJ0ZWQgcGFja2V0cw0K Pg0KPiBIZWxsbyBEYXZpZCwNCj4NCj4gVG8gYWRkcmVzcyBiZWxvdywgdGhlIG1ldGFkYXRhIHdv dWxkIG5lZWQgdG8gYmUgYWRhcHRhYmxlIGFuZCBzY2FsYWJsZQ0KPiBhY3Jvc3MgdmVuZG9ycyBh cyBUTFZzIGluIHNlcnZpY2UgY2hhaW5zLg0KPg0KPiBJ4oCZZCBzdWdnZXN0IGEgZm9ybWF0IGZv ciBUTFYgbWV0YWRhdGEgOg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4NCj4gfCAgICAgIFR5 cGUgICAgICAgICAgICAgICB8ICAgICBMZW5ndGggICAgICAgICB8DQo+ICAgICAgICBWZW5kb3It SUQgICAgICAgICAgICAgICAgICAgIHwNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtDQo+DQo+IHwg ICBWZW5kb3ItVHlwZSAgICAgICB8ICAgVmVuZG9yLUxlbmd0aCAgfCAgIEF0dHJpYnV0ZS1WYWx1 ZSAgfA0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4NCj4gVGhhbmsgeW91LA0KPg0KPiBTdW5p bA0KPg0KPiAqRnJvbToqIHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVo YWxmIE9mICpEYXZlIERvbHNvbg0KPiAqU2VudDoqIFRodXJzZGF5LCBBcHJpbCAwMiwgMjAxNSAx MjowMCBQTQ0KPiAqVG86KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ICpT dWJqZWN0OiogW3NmY10gTWV0YWRhdGEgYW5kIGluc2VydGVkIHBhY2tldHMNCj4NCj4gSeKAmWQg bGlrZSB0byBzdGFydCBhIHRocmVhZCBvbiBob3cgc2VydmljZSBmdW5jdGlvbnMgZGVhbCB3aXRo IG1ldGFkYXRhDQo+IGluIE5TSCwgaW4gcGFydGljdWxhciBob3cgYW4gU0YgbWlnaHQgZGVjaWRl IHdoYXQgbWV0YWRhdGEgc2hvdWxkIGJlDQo+IGFkZGVkIHRvIGEgcGFja2V0IGl0IGluamVjdHMu DQo+DQo+IChJc3N1ZXMgSSByYWlzZWQgaW4gRGFsbGFzLikNCj4NCj4gSeKAmW0gc3RhcnRpbmcg ZnJvbSB0aGUgYXNzdW1wdGlvbiB0aGF0IHdoZW4gYW4gU0YgaW5qZWN0cyBhIHBhY2tldCwgaXQN Cj4ga25vd3Mgd2hpY2ggc2VydmljZSBwYXRoIElEIGFuZCBTZXJ2aWNlIEluZGV4IChhbmQgb3Ro ZXIgTlNIIGhlYWRlcg0KPiBmaWVsZHMpIHNob3VsZCBiZSB1c2VkLiBUaGUgc2VtYW50aWNzIG9m IHRoZXNlIGZpZWxkcyBhcmUgd2VsbCBkZWZpbmVkLg0KPg0KPiBIb3dldmVyLCBJ4oCZbSBoYXZp bmcgdHJvdWJsZSB3aXRoIHdoYXQgbWV0YWRhdGEgdmFsdWVzIHNob3VsZCBiZSB1c2VkLg0KPiBN eSBiZWxpZWYgaXMgdGhhdCBzb21lIHNlbWFudGljcyBtdXN0IGJlIGRlZmluZWQgZm9yIG1ldGFk YXRhLg0KPg0KPiBUaGlzIHF1ZXN0aW9uIGFwcGxpZXMgdG8gTUQtdHlwZSAxLCBpbiB3aGljaCB0 aGUgc2VtYW50aWNzIG9mIGVhY2ggb2YNCj4gdGhlIDQgTWFuZGF0b3J5IENvbnRleHQgSGVhZGVy cyBtdXN0IGJlIGtub3duLCBhcyB3ZWxsIGFzIHRoZSBvcHRpb25hbA0KPiBmaWVsZHMgb2YgTUQt dHlwZXMgMSAmIDIsIHdoZXJlIGEgcG90ZW50aWFsbHkgbGFyZ2Ugc2V0IG9mIFRMVg0KPiBjbGFz cy9UeXBlIG11c3QgYmUgZGVhbHQgd2l0aC4NCj4NCj4gVGhlIE1ELXR5cGUtMSBxdWVzdGlvbiBp cyBwcm9iYWJseSBtb3JlIGVhc2lseSBkZWFsdCB3aXRoIGJ5DQo+IGRvY3VtZW50YXRpb24sIGFs dGhvdWdoIGRyYWZ0LWlldGYtc2ZjLW5zaC0wMCBkb2VzIG5vdCBzYXkgZW5vdWdoLiBJDQo+IHRo aW5rIGRyYWZ0LWd1aWNoYXJkLXNmYy1uc2gtZGMtYWxsb2NhdGlvbi0wMSBhbmQNCj4gZHJhZnQt bmFwcGVyLXNmYy1uc2gtbW9iaWxpdHktYWxsb2NhdGlvbi0wMCBjb3VsZCBkZWZpbmUgdGhpbmdz DQo+IGNsZWFybHkgZW5vdWdoLg0KPg0KPiAoRm9yIGV4YW1wbGUsIHdoYXQg4oCcU291cmNlIENs YXNz4oCdIGZyb20gZGMtYWxsb2NhdGlvbiBzaG91bGQgYmUgYWRkZWQNCj4gdG8gaW5qZWN0ZWQg dHJhZmZpYz8pDQo+DQo+IEFsbG93IG1lIHRvIHB1dCBmb3J3YXJkIHNvbWUgcHJvcG9zaXRpb25z IGZvciB5b3UgdG8ga25vY2sgZG93bjoNCj4NCj4gMS5NZXRhLWRhdGEgcmVwcmVzZW50aW5nIGEg bm90aW9uIG9mIG5ldHdvcmsgc2VwYXJhdGlvbiAoZS5nLiwgdGVuYW50KQ0KPiBtdXN0IGJlIHN0 YW5kYXJkaXplZCBhcyBzdWNoIHNvIHRoYXQgdHJhZmZpYyBkb2VzIG5vdCBjcm9zcyBuZXR3b3Jr cy4NCj4NCj4gMi5JbiBnZW5lcmFsLCBtZXRhLWRhdGEgbXVzdCBub3QgYmUgbW9yZSBzcGVjaWZp YyB0aGFuIGEgdHJhbnNwb3J0DQo+IHNlc3Npb24gKGUuZy4sIFRDUCBvciBVRFAgY29ubmVjdGlv bikuIFRoaXMgYWxsb3dzIGluamVjdGlvbiBvZg0KPiBtZXRhZGF0YSBieSBjbG9uaW5nIGV4ZW1w bGFyIHBhY2tldHMgb2YgdGhlIHNhbWUgZmxvdy4NCj4NCj4gMy5JZiBtZXRhLWRhdGEgaXMgbW9y ZSBzcGVjaWZpYyB0aGFuIGEgdHJhbnNwb3J0IHNlc3Npb24sIGFsbCBTRnMgdGhhdA0KPiBtaWdo dCBlbmNvdW50ZXIgc3VjaCBtZXRhLWRhdGEgbXVzdCBiZSBhd2FyZSBvZiB0aGUgc2VtYW50aWNz IChjb3VsZA0KPiBiZSBjb25maWd1cmVkIG9yIGhhcmQtY29kZWQpDQo+DQo+IERhdmlkIERvbHNv bg0KPg0KPiBTZW5pb3IgU29mdHdhcmUgQXJjaGl0ZWN0LCBTYW5kdmluZSBJbmMuDQo+DQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNm YyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVu dHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwsIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIGFkZHJlc3NlZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBh dXRob3JpemVkIHRvIHVzZSwgY29weSB0aGlzIG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBj b250ZW50IHRvIGFueSBvdGhlciBwZXJzb24uIEUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRvIGFs dGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2YgaXRzIHN1YnNpZGlhcmllcyBvciBh ZmZpbGlhdGVzIHNoYWxsIGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgYWx0ZXJlZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOoY2VzIGpv aW50ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udCBjb25maWRlbnRpZWxzIGV0IMOpdGFi bGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91 cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZOKAmWVuIGluZm9ybWVy IGltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlxdWUg ZXQgZOKAmWVmZmFjZXIgY2UgbWVzc2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFucyBjZXR0ZSBo eXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgYXV0b3Jpc8OpIMOgIHV0aWxpc2VyLCBjb3Bp ZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoCB1biB0aWVycy4g VG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24u IFFvc21vcyBldCBzZXMgZmlsaWFsZXMgZMOpY2xpbmVudCB0b3V0ZSByZXNwb25zYWJpbGl0w6kg YXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBzJ2lsIGEgw6l0w6kgYWx0w6lyw6ksIGTDqWZvcm3DqSBv dSBmYWxzaWZpw6kuDQo= From nobody Mon Apr 13 04:04:15 2015 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 88AFE1A9062 for ; Mon, 13 Apr 2015 04:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OEUrnbgEtdgS for ; Mon, 13 Apr 2015 04:04:11 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFA71A905F for ; Mon, 13 Apr 2015 04:04:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 69CE71BC0CC5; Mon, 13 Apr 2015 04:04:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from joels-mbp.vexwifi.com.br (unknown [200.165.200.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E18AA1BC0CBC; Mon, 13 Apr 2015 04:04:09 -0700 (PDT) Message-ID: <552BA2A6.6010606@joelhalpern.com> Date: Mon, 13 Apr 2015 07:04:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nicolas BOUTHORS , Dave Dolson , Sunil Vallamkonda , "sfc@ietf.org" References: <25b67d99694b497c9266b2feeb5ec987@SEAEXCHMBX05.olympus.F5Net.com> <552481AF.6020303@joelhalpern.com> <76B41B8FACE1514795D30EC137FF391D7FB325@CAROUBIER.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7FB325@CAROUBIER.jungle.qosmos.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Metadata and inserted packets 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, 13 Apr 2015 11:04:13 -0000 Actually Nicolas, none of the IPFix information identifiers are likely to appear as metadata with an SFC packet (i.e. the metadata in the NSH header.) While I do expect to se a registry for some metadata (such registries improve interoperability), I don't see any reason to think that the IPFIX registry is either a good basis or a good model for the work. Yours, Joel On 4/13/15 3:59 AM, Nicolas BOUTHORS wrote: > Hello all, > > Standardization of well known metadata types has been addressed for IPFX (Netflow) in the context of IANA. > See http://www.iana.org/assignments/ipfix/ipfix.xhtml > > The IPFIX 16bit Information Element identitier field is pretty much the same as the NSH TLV Class field. It has the same size > and the same objective which is to identify the type of Metadata transported. > > IPFIX RFC7011 describes how to take info account Entreprise extensions relying on a Field Specifier Format (using a reserved Enterprise bit in the 16bit Information Element identifier field) > > It is worth adopting the same model as: > - It is already standardized, > - It has room for extensions > - Is was designed to facilitate interoperatobility and is now widely used. > - It will facilitate SFC integration with Monitoring based system for SFC traffic (avoiding unnecessary conversions) > > > I propose we : > 1) support the Entreprise bit in NSH TLV Class > 2) refer to See http://www.iana.org/assignments/ipfix/ipfix.xhtml for well known values > > > Nicolas > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: mercredi 8 avril 2015 03:18 > To: Dave Dolson; Sunil Vallamkonda; sfc@ietf.org > Subject: Re: [sfc] Metadata and inserted packets > > I would expect that there will need to be application configuration that indicates what metadata type code a given SF should use for communicate what piece of information. This "type" might be a position in the fixed MD-1, or a TLV code in the MD-2. > > I do not expect that the protocol for provisioning this to service functions is part of SFC, any more than all the other configuration information that applications need to do their job. > > While I would not be surprised to eventually have a registry of well-known types, I do not see anyw ay to get around needing the configuration information for many service functions which care about metadata. There is just going to be too much variability. > > I hope that we do not have to put vendor IDs into the types, as the MD-2 TLV already looks to be larger than we like. > > Yours, > Joel > > On 4/7/15 2:59 PM, Dave Dolson wrote: >> Sunil, >> >> How would the SF know the semantics of the metadata with respect to >> packet injection? >> >> Would you have an out-of-band dictionary that maps vendor/type to the >> information? >> >> (E.g., “vendor/type 1001/27 is a network separation identifier”) >> >> The semantics could also be placed in-band, in the form of a fieldd. >> >> field values: >> >> - network separation metadata >> >> - transport flow attribute metadata >> >> - source IP metadata >> >> - destination IP metadata >> >> -Dave >> >> *From:*Sunil Vallamkonda [mailto:sunilvk@f5.com] >> *Sent:* Tuesday, April 07, 2015 2:07 PM >> *To:* Dave Dolson; sfc@ietf.org >> *Subject:* RE: Metadata and inserted packets >> >> Hello David, >> >> To address below, the metadata would need to be adaptable and scalable >> across vendors as TLVs in service chains. >> >> I’d suggest a format for TLV metadata : >> >> ---------------------------------------------------------------------- >> - >> >> | Type | Length | >> Vendor-ID | >> >> ---------------------------------------------------------------------- >> - >> >> | Vendor-Type | Vendor-Length | Attribute-Value | >> >> ---------------------------------------------------------------------- >> - >> >> Thank you, >> >> Sunil >> >> *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Dave Dolson >> *Sent:* Thursday, April 02, 2015 12:00 PM >> *To:* sfc@ietf.org >> *Subject:* [sfc] Metadata and inserted packets >> >> I’d like to start a thread on how service functions deal with metadata >> in NSH, in particular how an SF might decide what metadata should be >> added to a packet it injects. >> >> (Issues I raised in Dallas.) >> >> I’m starting from the assumption that when an SF injects a packet, it >> knows which service path ID and Service Index (and other NSH header >> fields) should be used. The semantics of these fields are well defined. >> >> However, I’m having trouble with what metadata values should be used. >> My belief is that some semantics must be defined for metadata. >> >> This question applies to MD-type 1, in which the semantics of each of >> the 4 Mandatory Context Headers must be known, as well as the optional >> fields of MD-types 1 & 2, where a potentially large set of TLV >> class/Type must be dealt with. >> >> The MD-type-1 question is probably more easily dealt with by >> documentation, although draft-ietf-sfc-nsh-00 does not say enough. I >> think draft-guichard-sfc-nsh-dc-allocation-01 and >> draft-napper-sfc-nsh-mobility-allocation-00 could define things >> clearly enough. >> >> (For example, what “Source Class” from dc-allocation should be added >> to injected traffic?) >> >> Allow me to put forward some propositions for you to knock down: >> >> 1.Meta-data representing a notion of network separation (e.g., tenant) >> must be standardized as such so that traffic does not cross networks. >> >> 2.In general, meta-data must not be more specific than a transport >> session (e.g., TCP or UDP connection). This allows injection of >> metadata by cloning exemplar packets of the same flow. >> >> 3.If meta-data is more specific than a transport session, all SFs that >> might encounter such meta-data must be aware of the semantics (could >> be configured or hard-coded) >> >> David Dolson >> >> Senior Software Architect, Sandvine Inc. >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > > This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. > > Ce message et toutes ses pièces jointes (ci-après le "message")sont confidentiels et établis à l'intention exclusive de ses destinataires. Si vous avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur par courrier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers. Tout message électronique est susceptible d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. > From nobody Tue Apr 14 07:10:49 2015 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 D0EFD1ACEA4; Mon, 13 Apr 2015 16:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 NAPfPoTNGvvW; Mon, 13 Apr 2015 16:35:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 12A641AD353; Mon, 13 Apr 2015 16:35:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7C6A0180206; Mon, 13 Apr 2015 16:34:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150413233449.7C6A0180206@rfc-editor.org> Date: Mon, 13 Apr 2015 16:34:49 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Tue, 14 Apr 2015 07:10:47 -0700 Cc: sfc@ietf.org, rfc-editor@rfc-editor.org Subject: [sfc] RFC 7498 on Problem Statement for Service Function Chaining 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, 13 Apr 2015 23:35:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7498 Title: Problem Statement for Service Function Chaining Author: P. Quinn, Ed., T. Nadeau, Ed. Status: Informational Stream: IETF Date: April 2015 Mailbox: paulq@cisco.com, tnadeau@lucidvision.com Pages: 13 Characters: 28970 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sfc-problem-statement-13.txt URL: https://www.rfc-editor.org/info/rfc7498 This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents. This document is a product of the Service Function Chaining Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Apr 14 16:15:59 2015 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 7E6C71B3060 for ; Tue, 14 Apr 2015 16:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_BACKHAIR_17=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 5P5SsnZwJQ99 for ; Tue, 14 Apr 2015 16:15:54 -0700 (PDT) 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 45FB51B3054 for ; Tue, 14 Apr 2015 16:15:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRJ98646; Tue, 14 Apr 2015 23:15:52 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Apr 2015 00:15:52 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Tue, 14 Apr 2015 16:15:47 -0700 From: Linda Dunbar To: "'Joel Halpern'" , "Carlos Pignataro (cpignata)" Thread-Topic: draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdA== Date: Tue, 14 Apr 2015 23:15:47 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.179] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C05EB9dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 14 Apr 2015 23:15:57 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C05EB9dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel and Carlos, Even though draft-ietf-sfc-architecture-07 is already in the status of "req= uest for publication", I hope you can make those simple changes suggested. The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different ways o= f using "Classifiers" to achieve SFC Symmetry. The definition of "Classifier" is "An element that performs Classification"= , which can be as simple as separating traffic based on some matching crite= ria. For traffic between A<->network <-> B, the classifier for traffic from "A"= -> "B" could be at the "network" port facing A; and the classifier for tra= ffic from "B" -> "A" could be at the "network" port facing B. Therefore, u= sing "Classifier" to achieve symmetry can be cumbersome, as your list descr= ibing "stateful classifiers", "cluster classifiers"; state exchanging among= "classifiers", ... If a centralized SFC controller is deployed, classifiers at either directio= n don't have to be involved in symmetry decision. Therefore, it is not true at all that "Symmetry may be realized in several ways depending on the SFF and classifier functionality." Symmetry is realized in great deal by how SFP is constructed or controlled. Since the sfc-architecture is not to advocate certain solutions, this docum= ent shouldn't have the description on state exchanges among classifiers to = achieve SFC symmetry, i.e. should delete the 4th paragraph and the bullets = after. Cheers, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C05EB9dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joel and Carlos,

 

Even though draft-ietf-sfc-architecture-07 is alread= y in the status of “request for publication”, I hope you can ma= ke those simple changes suggested.

 

 

The Section 2.2 of draft-ietf-sfc-architecture-07 li= sted 4 different ways of using “Classifiers” to achieve SFC Sym= metry.

 

The definition of R= 20;Classifier” is “An element that= performs Classification”, which can be as simple as separating traffic based on some matching = criteria.

 

For traffic between  A<->network <->= ; B, the classifier for traffic from “A” -> “B” = could be at the “network” port facing A; and the classifier for= traffic from “B” -> “A” could be at the “= network” port facing B.  Therefore, using "Classifier" to achieve symmetry can be cumbersome, as your list describing “stat= eful classifiers”, “cluster classifiers”; state exchangin= g among “classifiers”, …

 

If a centralized SFC controller is deployed, classif= iers at either direction don’t have to be involved in symmetry decisi= on.

 

Therefore, it is not t= rue at all that “Symmetry may be

realized in several ways depending on the SF= F and classifier

functionality.” 

 

Symmetry is realized in great deal by how SFP is con= structed or controlled.

 

Since the sfc-architec= ture is not to advocate certain solutions, this document shouldn’t ha= ve the description on state exchanges among classifiers to achieve SFC symm= etry, i.e. should delete the 4th paragraph and the bullets after.

 

Cheers,

 

Linda

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C05EB9dfweml701chm_-- From nobody Wed Apr 15 06:56:34 2015 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 34FF51A9112 for ; Wed, 15 Apr 2015 06:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 cHGUArMKRL_a for ; Wed, 15 Apr 2015 06:56:26 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924CB1A00CD for ; Wed, 15 Apr 2015 06:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6AA1C1BC17A7; Wed, 15 Apr 2015 06:56:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [104.129.196.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8BC3A1BC16AD; Wed, 15 Apr 2015 06:56:25 -0700 (PDT) Message-ID: <552E6E07.5050208@joelhalpern.com> Date: Wed, 15 Apr 2015 09:56:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linda Dunbar , "Carlos Pignataro (cpignata)" References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 13:56:32 -0000 I think your correction is backwards. It is true that the behavior you describe is permitted, and may even be common. It is still true that symmetry "may be realized ...". If this is a big deal, we could add a note that control mechanisms may play a role in achieving symmetry. I am not sure such a statement is needed, but I could live with it. The statement itself is needed to indicate that several mechanissm other folks want to use are also permitted by the archtiecture. Yours, Joel On 4/14/15 7:15 PM, Linda Dunbar wrote: > Joel and Carlos, > > Even though draft-ietf-sfc-architecture-07 is already in the status of > request for publication, I hope you can make those simple changes > suggested. > > The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different > ways of using Classifiers to achieve SFC Symmetry. > > The definition of Classifier is An element that performs > Classification, which can be as simple as separating traffic based on > some matching criteria. > > For traffic between A<->network <-> B, the classifier for traffic from > A -> B could be at the network port facing A; and the classifier > for traffic from B -> A could be at the network port facing B. > Therefore, using "Classifier" to achieve symmetry can be cumbersome, > as your list describing stateful classifiers, cluster classifiers; > state exchanging among classifiers, > > If a centralized SFC controller is deployed, classifiers at either > direction dont have to be involved in symmetry decision. > > Therefore, it is not true at all that Symmetry may be > > realized in several ways depending on the SFF and classifier > > functionality. > > Symmetry is realized in great deal by how SFP is constructed or controlled. > > Since the sfc-architecture is not to advocate certain solutions, this > document shouldnt have the description on state exchanges among > classifiers to achieve SFC symmetry, i.e. should delete the 4^th > paragraph and the bullets after. > > Cheers, > > Linda > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Apr 15 08:55:41 2015 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 5EB4B1B35F5 for ; Wed, 15 Apr 2015 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 cPT13G6sCDpU for ; Wed, 15 Apr 2015 08:55:35 -0700 (PDT) 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 2D3581B35E7 for ; Wed, 15 Apr 2015 08:55:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUX36286; Wed, 15 Apr 2015 15:55:33 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Apr 2015 16:55:33 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 15 Apr 2015 08:55:28 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CA= Date: Wed, 15 Apr 2015 15:55:27 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> In-Reply-To: <552E6E07.5050208@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 15:55:38 -0000 Most likely classifiers at either end of the SFC domain don't even know whe= re the FW (that require bidirectional congruency) in the network is and whi= ch instance of FW that packets will traverse. Bidirectional congruency, if = required, has to be at the SF instance level.=20 Therefore, very complicated mechanisms and coordination are required for a = head-end Classifier (that has an embedded DPI engine) to enforce bidirectio= nal congruency of a Firewall deployed in the middle of the network, and the= complex mechanisms needed to collaborate with the other end of Classifier.= =20 Yes, it will make so much more sense to say: - symmetry "may be realized by multiple mechanisms",=20 - " The statement itself is needed to indicate that several mechanism oth= er folks want to use are also permitted by the architecture.", and=20 - delete the description on Classifier based solutions Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, April 15, 2015 8:56 AM To: Linda Dunbar; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry I think your correction is backwards. It is true that the behavior you des= cribe is permitted, and may even be common. It is still true that symmetry= "may be realized ...". If this is a big deal, we could add a note that co= ntrol mechanisms may play a role in achieving symmetry. I am not sure such= a statement is needed, but I could live with it. The statement itself is needed to indicate that several mechanissm other fo= lks want to use are also permitted by the archtiecture. Yours, Joel On 4/14/15 7:15 PM, Linda Dunbar wrote: > Joel and Carlos, > > Even though draft-ietf-sfc-architecture-07 is already in the status of=20 > "request for publication", I hope you can make those simple changes=20 > suggested. > > The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different=20 > ways of using "Classifiers" to achieve SFC Symmetry. > > The definition of "Classifier" is "An element that performs=20 > Classification", which can be as simple as separating traffic based on=20 > some matching criteria. > > For traffic between A<->network <-> B, the classifier for traffic=20 > from "A" -> "B" could be at the "network" port facing A; and the=20 > classifier for traffic from "B" -> "A" could be at the "network" port fac= ing B. > Therefore, using "Classifier" to achieve symmetry can be cumbersome,=20 > as your list describing "stateful classifiers", "cluster classifiers";=20 > state exchanging among "classifiers", ... > > If a centralized SFC controller is deployed, classifiers at either=20 > direction don't have to be involved in symmetry decision. > > Therefore, it is not true at all that "Symmetry may be > > realized in several ways depending on the SFF and classifier > > functionality." > > Symmetry is realized in great deal by how SFP is constructed or controlle= d. > > Since the sfc-architecture is not to advocate certain solutions, this=20 > document shouldn't have the description on state exchanges among=20 > classifiers to achieve SFC symmetry, i.e. should delete the 4^th=20 > paragraph and the bullets after. > > Cheers, > > Linda > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Apr 15 09:02:37 2015 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 304A41B2CBC for ; Wed, 15 Apr 2015 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_LOW=-0.7, 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 KIG9-kQNH7i3 for ; Wed, 15 Apr 2015 09:02:33 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CF71AD366 for ; Wed, 15 Apr 2015 09:02:32 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0224.002; Wed, 15 Apr 2015 09:02:32 -0700 From: Ron Parker To: Linda Dunbar , "Joel M. Halpern" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CAAFZvOYA== Date: Wed, 15 Apr 2015 16:02:31 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.104.65.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 16:02:36 -0000 Linda, I think there are some topological considerations, here. If the network i= s arranged such that the related traffic in both directions (lets say upstr= eam and downstream for sake of discussion) traverses the same entity always= , as might be the case for various Subscriber Management Systems, then a cl= assifier located in that place would be capable of applying bidirectional c= ongruency. On the other hand, a network that is solely a layer 3 routed= cloud may not be able to guarantee that the same Router is always traverse= d for upstream and downstream wrt related traffic. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, April 15, 2015 11:55 AM To: Joel M. Halpern; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry Most likely classifiers at either end of the SFC domain don't even know whe= re the FW (that require bidirectional congruency) in the network is and whi= ch instance of FW that packets will traverse. Bidirectional congruency, if = required, has to be at the SF instance level.=20 Therefore, very complicated mechanisms and coordination are required for a = head-end Classifier (that has an embedded DPI engine) to enforce bidirectio= nal congruency of a Firewall deployed in the middle of the network, and the= complex mechanisms needed to collaborate with the other end of Classifier.= =20 Yes, it will make so much more sense to say: - symmetry "may be realized by multiple mechanisms", - " The statement itself is needed to indicate that several mechanism oth= er folks want to use are also permitted by the architecture.", and - delete the description on Classifier based solutions Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, April 15, 2015 8:56 AM To: Linda Dunbar; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry I think your correction is backwards. It is true that the behavior you des= cribe is permitted, and may even be common. It is still true that symmetry= "may be realized ...". If this is a big deal, we could add a note that co= ntrol mechanisms may play a role in achieving symmetry. I am not sure such= a statement is needed, but I could live with it. The statement itself is needed to indicate that several mechanissm other fo= lks want to use are also permitted by the archtiecture. Yours, Joel On 4/14/15 7:15 PM, Linda Dunbar wrote: > Joel and Carlos, > > Even though draft-ietf-sfc-architecture-07 is already in the status of=20 > "request for publication", I hope you can make those simple changes=20 > suggested. > > The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different=20 > ways of using "Classifiers" to achieve SFC Symmetry. > > The definition of "Classifier" is "An element that performs=20 > Classification", which can be as simple as separating traffic based on=20 > some matching criteria. > > For traffic between A<->network <-> B, the classifier for traffic=20 > from "A" -> "B" could be at the "network" port facing A; and the=20 > classifier for traffic from "B" -> "A" could be at the "network" port fac= ing B. > Therefore, using "Classifier" to achieve symmetry can be cumbersome,=20 > as your list describing "stateful classifiers", "cluster classifiers";=20 > state exchanging among "classifiers", ... > > If a centralized SFC controller is deployed, classifiers at either=20 > direction don't have to be involved in symmetry decision. > > Therefore, it is not true at all that "Symmetry may be > > realized in several ways depending on the SFF and classifier > > functionality." > > Symmetry is realized in great deal by how SFP is constructed or controlle= d. > > Since the sfc-architecture is not to advocate certain solutions, this=20 > document shouldn't have the description on state exchanges among=20 > classifiers to achieve SFC symmetry, i.e. should delete the 4^th=20 > paragraph and the bullets after. > > Cheers, > > Linda > > > > _______________________________________________ > 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 Wed Apr 15 09:19:56 2015 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 558A61B2D0F for ; Wed, 15 Apr 2015 09:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 oOQTEONW5Dzg for ; Wed, 15 Apr 2015 09:19:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFD61B2D08 for ; Wed, 15 Apr 2015 09:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=558; q=dns/txt; s=iport; t=1429114794; x=1430324394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cmrQVpJSImAYWsuSr/FXoGAGBizfpABfd9VLWZv1z20=; b=JqqJcAZdWQrqUNc354sk6SJ2w4F+li5xyt68mKbkk9LiKNl/aBNC3h8N qQyLvzvALvvev4x7/9mSAfbBAwYoxvBJ2qxk9rujdUZ2xgtD3CgdzwD/R e2cfaAEdeSi8ie6Lt7XNrV4WGIu+DPBya7oFbBXQBbujnBew5BC2BspCX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQDOji5V/5NdJa1cgwyBLgXNOgKBO0wBAQEBAQF+hCABAQEDATo/BQsCAQgSBh4FCzIXDgEBBA4FiCIIxHkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyuESTMHgxeBFgEEkRaKGIEdgziQJCKCM4E8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,582,1422921600"; d="scan'208";a="412052652" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP; 15 Apr 2015 16:19:53 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3FGJrDi004482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Apr 2015 16:19:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.189]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 11:19:53 -0500 From: "Paul Quinn (paulq)" To: Linda Dunbar Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAApPCeAAAQoioAAANnbgA== Date: Wed, 15 Apr 2015 16:19:52 +0000 Message-ID: <343023D9-8495-4DB9-8C51-AB4396B60212@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Joel M. Halpern" , "sfc@ietf.org" , Alia Atlas Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 16:19:55 -0000 Linda, > On Apr 15, 2015, at 11:55 AM, Linda Dunbar wrot= e: >=20 > Most likely classifiers at either end of the SFC domain don't even know w= here the FW (that require bidirectional congruency) in the network is and w= hich instance of FW that packets will traverse. Bidirectional congruency, i= f required, has to be at the SF instance level.=20 I'm a bit confused by this. Can you please give me an example of how the s= ymmetry can be handled by the SF instance(s), which, don't perform any path= forwarding? From nobody Wed Apr 15 09:34:12 2015 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 B0F1A1B2D6E for ; Wed, 15 Apr 2015 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 lRwLpX_aXsNE for ; Wed, 15 Apr 2015 09:34:09 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE111B2C93 for ; Wed, 15 Apr 2015 09:34:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,582,1422921600"; d="scan'208";a="157935740" X-IPAS-Result: A2CtBAC3ki5V/+sKqMBUCINeXAXHEh0KhgMCggcBAQEBAQF+hCABAQEBAwEBASQTNAsMBAIBCBEBAwEBAR4FBAcnCxQDBggBAQQBDQUIE4gcxG8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsrhCVXBwaEJwWcS4YeiXGDTYJVgTxvgUR/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 15 Apr 2015 16:34:07 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 15 Apr 2015 09:34:05 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::c9a6:e310:2052:6c8a]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::c9a6:e310:2052:6c8a%21]) with mapi id 15.00.1044.021; Wed, 15 Apr 2015 09:34:05 -0700 From: Ian Smith To: Linda Dunbar , "Joel M. Halpern" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CAAFJS7EA== Date: Wed, 15 Apr 2015 16:34:05 +0000 Message-ID: <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> 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: [192.168.15.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 16:34:11 -0000 I think it is also fair to say that there are cases where the chain itself = is not symmetric, but a subset of that chain is. =20 What I've found to be an effective way of looking situations like this is t= o treat them as two separate flows - one in each direction (to the internet= & from the internet) and then converge the flows on the nodes that expect = them to be converged. This yields a design paradigm where there is no symmetry, only persistent n= odes where both directions of traffic MUST traverse and nodes where both di= rections of traffic MAY traverse. This changes the problem from one where = a single full-duplex symmetry is required (usually in excess of actuality) = to one where two or more half-duplex symmetries are called for, and it shif= ts the problem of state from a wiring problem (or the arrangement of virtua= l wires) to a routing problem. Concentrating on this routing problem, not the wiring problem, is what I re= ad the document to be suggesting is the way forward. When you talk of using controllers, this is implicitly what you're talking = about doing. So there isn't a symmetry problem in your example of A > ne= twork > B, because there is implicitly B > network > A which doesn't have t= o have the same value of "network". And in the case of something like A = > D > B, the implication is that the sequence is locked in below routing in= physical or virtual wiring domain so that there is no choice but to go th= rough D to get to B from A and the inverse. In those cases, the implicatio= n is often that A =3D=3D B or that A and B share some sort of state managem= ent methodology either explicitly (some sort of distributed systems) or imp= licitly (because of link-flow associations). Finally, I'd suggest that a FW, in this kind of scenario, probably doesn't = _need_ to be tracking connections, because either it is being directed by a= controller on a flow by flow basis, in which case there are two rules in t= he rule set (in the case of A > network > B), or because the network state = is irrelevant because of a decision that was made outside of its view befor= e the flow gets to it (in the case of A > D > B). The bottom line being th= at if you try to just pick up the design patterns from an SFC-free network = and use them in and SFC network, the value that SFC adds on top of "Program= mable, Elastic, Virtualized, and Scalable Infrastructure with an API" is be= ing lost. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, April 15, 2015 11:55 AM To: Joel M. Halpern; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry Most likely classifiers at either end of the SFC domain don't even know whe= re the FW (that require bidirectional congruency) in the network is and whi= ch instance of FW that packets will traverse. Bidirectional congruency, if = required, has to be at the SF instance level.=20 Therefore, very complicated mechanisms and coordination are required for a = head-end Classifier (that has an embedded DPI engine) to enforce bidirectio= nal congruency of a Firewall deployed in the middle of the network, and the= complex mechanisms needed to collaborate with the other end of Classifier.= =20 Yes, it will make so much more sense to say: - symmetry "may be realized by multiple mechanisms", - " The statement itself is needed to indicate that several mechanism oth= er folks want to use are also permitted by the architecture.", and - delete the description on Classifier based solutions Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, April 15, 2015 8:56 AM To: Linda Dunbar; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry I think your correction is backwards. It is true that the behavior you des= cribe is permitted, and may even be common. It is still true that symmetry= "may be realized ...". If this is a big deal, we could add a note that co= ntrol mechanisms may play a role in achieving symmetry. I am not sure such= a statement is needed, but I could live with it. The statement itself is needed to indicate that several mechanissm other fo= lks want to use are also permitted by the archtiecture. Yours, Joel On 4/14/15 7:15 PM, Linda Dunbar wrote: > Joel and Carlos, > > Even though draft-ietf-sfc-architecture-07 is already in the status of=20 > "request for publication", I hope you can make those simple changes=20 > suggested. > > The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different=20 > ways of using "Classifiers" to achieve SFC Symmetry. > > The definition of "Classifier" is "An element that performs=20 > Classification", which can be as simple as separating traffic based on=20 > some matching criteria. > > For traffic between A<->network <-> B, the classifier for traffic=20 > from "A" -> "B" could be at the "network" port facing A; and the=20 > classifier for traffic from "B" -> "A" could be at the "network" port fac= ing B. > Therefore, using "Classifier" to achieve symmetry can be cumbersome,=20 > as your list describing "stateful classifiers", "cluster classifiers";=20 > state exchanging among "classifiers", ... > > If a centralized SFC controller is deployed, classifiers at either=20 > direction don't have to be involved in symmetry decision. > > Therefore, it is not true at all that "Symmetry may be > > realized in several ways depending on the SFF and classifier > > functionality." > > Symmetry is realized in great deal by how SFP is constructed or controlle= d. > > Since the sfc-architecture is not to advocate certain solutions, this=20 > document shouldn't have the description on state exchanges among=20 > classifiers to achieve SFC symmetry, i.e. should delete the 4^th=20 > paragraph and the bullets after. > > Cheers, > > Linda > > > > _______________________________________________ > 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 Wed Apr 15 09:42:52 2015 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 60A6C1B2E76 for ; Wed, 15 Apr 2015 09:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 RyEFR0rB_9VR for ; Wed, 15 Apr 2015 09:42:49 -0700 (PDT) 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 B2DB41B2E17 for ; Wed, 15 Apr 2015 09:42:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUX39844; Wed, 15 Apr 2015 16:42:47 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Apr 2015 17:42:46 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 15 Apr 2015 09:42:39 -0700 From: Linda Dunbar To: "Paul Quinn (paulq)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CD//84/AIAAceaA Date: Wed, 15 Apr 2015 16:42:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C0648E@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <343023D9-8495-4DB9-8C51-AB4396B60212@cisco.com> In-Reply-To: <343023D9-8495-4DB9-8C51-AB4396B60212@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "Joel M. Halpern" , "sfc@ietf.org" , Alia Atlas Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 16:42:50 -0000 Paul,=20 I don't mean at all that symmetry is achieved by SF instances. I am saying,= if a SF (e.g. stateful FW) needs both direction of a flow, it is the FW in= stance that needs both direction of a flow to traverse, not the abstract SF= (which can have many instances spread across the network).=20 I am trying to point out that if the congruency is required by SF instance,= it is very difficult for the head end classifier to achieve. More reasonab= le entity to achieve symmetry is the entity that manages the SFC path (or R= SP) selection.=20 Linda=20 -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, April 15, 2015 11:20 AM To: Linda Dunbar Cc: Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.org; Alia Atlas Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry Linda, > On Apr 15, 2015, at 11:55 AM, Linda Dunbar wrot= e: >=20 > Most likely classifiers at either end of the SFC domain don't even know w= here the FW (that require bidirectional congruency) in the network is and w= hich instance of FW that packets will traverse. Bidirectional congruency, i= f required, has to be at the SF instance level.=20 I'm a bit confused by this. Can you please give me an example of how the s= ymmetry can be handled by the SF instance(s), which, don't perform any path= forwarding? From nobody Wed Apr 15 13:25:10 2015 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 575071A8A0E for ; Wed, 15 Apr 2015 13:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GUm3SH9mFvi5 for ; Wed, 15 Apr 2015 13:25:05 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816541A8A0B for ; Wed, 15 Apr 2015 13:25:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 702C01BC7FD0; Wed, 15 Apr 2015 13:25:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [63.88.116.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E39CE1BC7E98; Wed, 15 Apr 2015 13:24:59 -0700 (PDT) Message-ID: <552EC919.9000908@joelhalpern.com> Date: Wed, 15 Apr 2015 16:24:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linda Dunbar , "Paul Quinn (paulq)" References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <343023D9-8495-4DB9-8C51-AB4396B60212@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657C0648E@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C0648E@dfweml701-chm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "sfc@ietf.org" , Alia Atlas Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 20:25:09 -0000 There were specific requests from working group members for fully symmetric SFCs. The fact that some folks don't need them does not free the authors to ignore the requests. Similarly, there were multiple approaches proposed to address tghe requirements, and since it can easily do so, the architecture should acknowledge that range. Which is what it tries to do. Yours, Joel On 4/15/15 12:42 PM, Linda Dunbar wrote: > Paul, > > I don't mean at all that symmetry is achieved by SF instances. I am saying, if a SF (e.g. stateful FW) needs both direction of a flow, it is the FW instance that needs both direction of a flow to traverse, not the abstract SF (which can have many instances spread across the network). > > I am trying to point out that if the congruency is required by SF instance, it is very difficult for the head end classifier to achieve. More reasonable entity to achieve symmetry is the entity that manages the SFC path (or RSP) selection. > > Linda > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Wednesday, April 15, 2015 11:20 AM > To: Linda Dunbar > Cc: Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.org; Alia Atlas > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry > > Linda, > > >> On Apr 15, 2015, at 11:55 AM, Linda Dunbar wrote: >> >> Most likely classifiers at either end of the SFC domain don't even know where the FW (that require bidirectional congruency) in the network is and which instance of FW that packets will traverse. Bidirectional congruency, if required, has to be at the SF instance level. > > I'm a bit confused by this. Can you please give me an example of how the symmetry can be handled by the SF instance(s), which, don't perform any path forwarding? > > From nobody Wed Apr 15 14:03:04 2015 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 3BA361A8F46 for ; Wed, 15 Apr 2015 14:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 lX778hh7Yx0e for ; Wed, 15 Apr 2015 14:03:01 -0700 (PDT) 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 B3CF71A8F42 for ; Wed, 15 Apr 2015 14:03:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUX53072; Wed, 15 Apr 2015 21:02:59 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 15 Apr 2015 22:02:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 15 Apr 2015 14:02:55 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "Paul Quinn (paulq)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CD//84/AIAAceaA///SlICAAGzeMA== Date: Wed, 15 Apr 2015 21:02:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C065CD@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <343023D9-8495-4DB9-8C51-AB4396B60212@cisco.com> <4A95BA014132FF49AE685FAB4B9F17F657C0648E@dfweml701-chm> <552EC919.9000908@joelhalpern.com> In-Reply-To: <552EC919.9000908@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "sfc@ietf.org" , Alia Atlas Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 21:03:03 -0000 It is perfectly reasonable to describe "full symmetric SFCs" in the archite= cture document. The current Section 2.2 has very good description of fully = symmetric SFCs and partially symmetric SFC, etc".=20 I just want to point out that SFC-architecture document shouldn't advocate = the solutions of using classifiers to achieve SFC symmetry. If you want to say something about the symmetry solutions, a more reasonabl= e entity to achieve symmetry is the entity that manages the SFC path (or RS= P) selection.=20 Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, April 15, 2015 3:25 PM To: Linda Dunbar; Paul Quinn (paulq) Cc: Carlos Pignataro (cpignata); sfc@ietf.org; Alia Atlas Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry There were specific requests from working group members for fully symmetric= SFCs. The fact that some folks don't need them does not free the authors = to ignore the requests. Similarly, there were multiple approaches proposed to address tghe requirem= ents, and since it can easily do so, the architecture should acknowledge th= at range. Which is what it tries to do. Yours, Joel On 4/15/15 12:42 PM, Linda Dunbar wrote: > Paul, > > I don't mean at all that symmetry is achieved by SF instances. I am sayin= g, if a SF (e.g. stateful FW) needs both direction of a flow, it is the FW = instance that needs both direction of a flow to traverse, not the abstract = SF (which can have many instances spread across the network). > > I am trying to point out that if the congruency is required by SF instanc= e, it is very difficult for the head end classifier to achieve. More reason= able entity to achieve symmetry is the entity that manages the SFC path (or= RSP) selection. > > Linda > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Wednesday, April 15, 2015 11:20 AM > To: Linda Dunbar > Cc: Joel M. Halpern; Carlos Pignataro (cpignata); sfc@ietf.org; Alia=20 > Atlas > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate=20 > various ways of using "Classifier" to achieve SFC Symmetry > > Linda, > > >> On Apr 15, 2015, at 11:55 AM, Linda Dunbar wro= te: >> >> Most likely classifiers at either end of the SFC domain don't even know = where the FW (that require bidirectional congruency) in the network is and = which instance of FW that packets will traverse. Bidirectional congruency, = if required, has to be at the SF instance level. > > I'm a bit confused by this. Can you please give me an example of how the= symmetry can be handled by the SF instance(s), which, don't perform any pa= th forwarding? > > From nobody Wed Apr 15 16:52:51 2015 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 434C91ACD9F for ; Wed, 15 Apr 2015 16:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 P8-5eXpQ4Tu8 for ; Wed, 15 Apr 2015 16:52:47 -0700 (PDT) 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 6D94A1ACD97 for ; Wed, 15 Apr 2015 16:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4F7901C01EF; Wed, 15 Apr 2015 16:52:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (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 71D211C0145; Wed, 15 Apr 2015 16:52:46 -0700 (PDT) Message-ID: <552EF9CE.30803@joelhalpern.com> Date: Wed, 15 Apr 2015 19:52:46 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Smith , Linda Dunbar , "Carlos Pignataro (cpignata)" References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> In-Reply-To: <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 15 Apr 2015 23:52:49 -0000 I could live with this model for symmetry. I agree with you that it reflects a common case. We were asked explicitly to include support for full symmetry, which is generally simpler to handle as a specific case rather than as a generalization of going through specific functions. There are mechanisms people would like to use that fit that model. Yours, Joel On 4/15/15 12:34 PM, Ian Smith wrote: > I think it is also fair to say that there are cases where the chain itself is not symmetric, but a subset of that chain is. > > What I've found to be an effective way of looking situations like this is to treat them as two separate flows - one in each direction (to the internet & from the internet) and then converge the flows on the nodes that expect them to be converged. > > This yields a design paradigm where there is no symmetry, only persistent nodes where both directions of traffic MUST traverse and nodes where both directions of traffic MAY traverse. This changes the problem from one where a single full-duplex symmetry is required (usually in excess of actuality) to one where two or more half-duplex symmetries are called for, and it shifts the problem of state from a wiring problem (or the arrangement of virtual wires) to a routing problem. > > Concentrating on this routing problem, not the wiring problem, is what I read the document to be suggesting is the way forward. > > When you talk of using controllers, this is implicitly what you're talking about doing. So there isn't a symmetry problem in your example of A > network > B, because there is implicitly B > network > A which doesn't have to have the same value of "network". And in the case of something like A > D > B, the implication is that the sequence is locked in below routing in physical or virtual wiring domain so that there is no choice but to go through D to get to B from A and the inverse. In those cases, the implication is often that A == B or that A and B share some sort of state management methodology either explicitly (some sort of distributed systems) or implicitly (because of link-flow associations). > > Finally, I'd suggest that a FW, in this kind of scenario, probably doesn't _need_ to be tracking connections, because either it is being directed by a controller on a flow by flow basis, in which case there are two rules in the rule set (in the case of A > network > B), or because the network state is irrelevant because of a decision that was made outside of its view before the flow gets to it (in the case of A > D > B). The bottom line being that if you try to just pick up the design patterns from an SFC-free network and use them in and SFC network, the value that SFC adds on top of "Programmable, Elastic, Virtualized, and Scalable Infrastructure with an API" is being lost. > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Wednesday, April 15, 2015 11:55 AM > To: Joel M. Halpern; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry > > Most likely classifiers at either end of the SFC domain don't even know where the FW (that require bidirectional congruency) in the network is and which instance of FW that packets will traverse. Bidirectional congruency, if required, has to be at the SF instance level. > > Therefore, very complicated mechanisms and coordination are required for a head-end Classifier (that has an embedded DPI engine) to enforce bidirectional congruency of a Firewall deployed in the middle of the network, and the complex mechanisms needed to collaborate with the other end of Classifier. > > > Yes, it will make so much more sense to say: > > - symmetry "may be realized by multiple mechanisms", > - " The statement itself is needed to indicate that several mechanism other folks want to use are also permitted by the architecture.", and > - delete the description on Classifier based solutions > > Linda > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 15, 2015 8:56 AM > To: Linda Dunbar; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry > > I think your correction is backwards. It is true that the behavior you describe is permitted, and may even be common. It is still true that symmetry "may be realized ...". If this is a big deal, we could add a note that control mechanisms may play a role in achieving symmetry. I am not sure such a statement is needed, but I could live with it. > > The statement itself is needed to indicate that several mechanissm other folks want to use are also permitted by the archtiecture. > > Yours, > Joel > > On 4/14/15 7:15 PM, Linda Dunbar wrote: >> Joel and Carlos, >> >> Even though draft-ietf-sfc-architecture-07 is already in the status of >> "request for publication", I hope you can make those simple changes >> suggested. >> >> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different >> ways of using "Classifiers" to achieve SFC Symmetry. >> >> The definition of "Classifier" is "An element that performs >> Classification", which can be as simple as separating traffic based on >> some matching criteria. >> >> For traffic between A<->network <-> B, the classifier for traffic >> from "A" -> "B" could be at the "network" port facing A; and the >> classifier for traffic from "B" -> "A" could be at the "network" port facing B. >> Therefore, using "Classifier" to achieve symmetry can be cumbersome, >> as your list describing "stateful classifiers", "cluster classifiers"; >> state exchanging among "classifiers", ... >> >> If a centralized SFC controller is deployed, classifiers at either >> direction don't have to be involved in symmetry decision. >> >> Therefore, it is not true at all that "Symmetry may be >> >> realized in several ways depending on the SFF and classifier >> >> functionality." >> >> Symmetry is realized in great deal by how SFP is constructed or controlled. >> >> Since the sfc-architecture is not to advocate certain solutions, this >> document shouldn't have the description on state exchanges among >> classifiers to achieve SFC symmetry, i.e. should delete the 4^th >> paragraph and the bullets after. >> >> Cheers, >> >> Linda >> >> >> >> _______________________________________________ >> 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 Wed Apr 15 17:15:00 2015 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 C98BA1ACE52 for ; Wed, 15 Apr 2015 17:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 nfZBl2gSJTgb for ; Wed, 15 Apr 2015 17:13:13 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764CA1ACE51 for ; Wed, 15 Apr 2015 17:13:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,584,1422921600"; d="scan'208";a="158011468" X-IPAS-Result: A2CtBABc/S5V/+sKqMBUCINeXAXHIh0KhgMCggIBAQEBAQF+hCABAQEBAwEBASQTNAsMBAIBCBEBAwEBAR4FBAcnCxQDBggBAQQBDQUIE4gcxjABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsrhCVXBwaEJwWcS4YeiXGDTYJVgTxvgUR/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 16 Apr 2015 00:13:13 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 15 Apr 2015 17:13:12 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::c9a6:e310:2052:6c8a]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::c9a6:e310:2052:6c8a%21]) with mapi id 15.00.1044.021; Wed, 15 Apr 2015 17:13:11 -0700 From: Ian Smith To: "Joel M. Halpern" , Linda Dunbar , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CAAFJS7EP//qCMAgABzbzA= Date: Thu, 16 Apr 2015 00:13:10 +0000 Message-ID: <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> <552EF9CE.30803@joelhalpern.com> In-Reply-To: <552EF9CE.30803@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: [192.168.15.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 16 Apr 2015 00:13:20 -0000 I recall the conversation re: supporting full symmetry, and I get that peop= le want it and generally think I understand why they want it. I suppose I'm reading it to say that you MAY have symmetric flows, and when= you do they should look "like this", but they aren't a MUST requirement of= the architecture. Is that what you intended? If so, I have no issue with it as written, since that is how it is actually= done today. -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, April 15, 2015 7:53 PM To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry I could live with this model for symmetry. I agree with you that it reflec= ts a common case. We were asked explicitly to include support for full sym= metry, which is generally simpler to handle as a specific case rather than = as a generalization of going through specific functions.=20 There are mechanisms people would like to use that fit that model. Yours, Joel On 4/15/15 12:34 PM, Ian Smith wrote: > I think it is also fair to say that there are cases where the chain itsel= f is not symmetric, but a subset of that chain is. > > What I've found to be an effective way of looking situations like this is= to treat them as two separate flows - one in each direction (to the intern= et & from the internet) and then converge the flows on the nodes that expec= t them to be converged. > > This yields a design paradigm where there is no symmetry, only persistent= nodes where both directions of traffic MUST traverse and nodes where both = directions of traffic MAY traverse. This changes the problem from one wher= e a single full-duplex symmetry is required (usually in excess of actuality= ) to one where two or more half-duplex symmetries are called for, and it sh= ifts the problem of state from a wiring problem (or the arrangement of virt= ual wires) to a routing problem. > > Concentrating on this routing problem, not the wiring problem, is what I = read the document to be suggesting is the way forward. > > When you talk of using controllers, this is implicitly what you're talkin= g about doing. So there isn't a symmetry problem in your example of A > = network > B, because there is implicitly B > network > A which doesn't have= to have the same value of "network". And in the case of something like = A > D > B, the implication is that the sequence is locked in below routing = in physical or virtual wiring domain so that there is no choice but to go = through D to get to B from A and the inverse. In those cases, the implicat= ion is often that A =3D=3D B or that A and B share some sort of state manag= ement methodology either explicitly (some sort of distributed systems) or i= mplicitly (because of link-flow associations). > > Finally, I'd suggest that a FW, in this kind of scenario, probably doesn'= t _need_ to be tracking connections, because either it is being directed by= a controller on a flow by flow basis, in which case there are two rules in= the rule set (in the case of A > network > B), or because the network stat= e is irrelevant because of a decision that was made outside of its view bef= ore the flow gets to it (in the case of A > D > B). The bottom line being = that if you try to just pick up the design patterns from an SFC-free networ= k and use them in and SFC network, the value that SFC adds on top of "Progr= ammable, Elastic, Virtualized, and Scalable Infrastructure with an API" is = being lost. > > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Wednesday, April 15, 2015 11:55 AM > To: Joel M. Halpern; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate=20 > various ways of using "Classifier" to achieve SFC Symmetry > > Most likely classifiers at either end of the SFC domain don't even know w= here the FW (that require bidirectional congruency) in the network is and w= hich instance of FW that packets will traverse. Bidirectional congruency, i= f required, has to be at the SF instance level. > > Therefore, very complicated mechanisms and coordination are required for = a head-end Classifier (that has an embedded DPI engine) to enforce bidirect= ional congruency of a Firewall deployed in the middle of the network, and t= he complex mechanisms needed to collaborate with the other end of Classifie= r. > > > Yes, it will make so much more sense to say: > > - symmetry "may be realized by multiple mechanisms", > - " The statement itself is needed to indicate that several mechanism = other folks want to use are also permitted by the architecture.", and > - delete the description on Classifier based solutions > > Linda > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 15, 2015 8:56 AM > To: Linda Dunbar; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate=20 > various ways of using "Classifier" to achieve SFC Symmetry > > I think your correction is backwards. It is true that the behavior you d= escribe is permitted, and may even be common. It is still true that symmet= ry "may be realized ...". If this is a big deal, we could add a note that = control mechanisms may play a role in achieving symmetry. I am not sure su= ch a statement is needed, but I could live with it. > > The statement itself is needed to indicate that several mechanissm other = folks want to use are also permitted by the archtiecture. > > Yours, > Joel > > On 4/14/15 7:15 PM, Linda Dunbar wrote: >> Joel and Carlos, >> >> Even though draft-ietf-sfc-architecture-07 is already in the status=20 >> of "request for publication", I hope you can make those simple=20 >> changes suggested. >> >> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different=20 >> ways of using "Classifiers" to achieve SFC Symmetry. >> >> The definition of "Classifier" is "An element that performs=20 >> Classification", which can be as simple as separating traffic based=20 >> on some matching criteria. >> >> For traffic between A<->network <-> B, the classifier for traffic=20 >> from "A" -> "B" could be at the "network" port facing A; and the=20 >> classifier for traffic from "B" -> "A" could be at the "network" port fa= cing B. >> Therefore, using "Classifier" to achieve symmetry can be=20 >> cumbersome, as your list describing "stateful classifiers", "cluster=20 >> classifiers"; state exchanging among "classifiers", ... >> >> If a centralized SFC controller is deployed, classifiers at either=20 >> direction don't have to be involved in symmetry decision. >> >> Therefore, it is not true at all that "Symmetry may be >> >> realized in several ways depending on the SFF and classifier >> >> functionality." >> >> Symmetry is realized in great deal by how SFP is constructed or controll= ed. >> >> Since the sfc-architecture is not to advocate certain solutions, this=20 >> document shouldn't have the description on state exchanges among=20 >> classifiers to achieve SFC symmetry, i.e. should delete the 4^th=20 >> paragraph and the bullets after. >> >> Cheers, >> >> Linda >> >> >> >> _______________________________________________ >> 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 Wed Apr 15 17:15:54 2015 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 949B61ACE31 for ; Wed, 15 Apr 2015 17:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 PP1qAS0xM6rk for ; Wed, 15 Apr 2015 17:15:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B694D1ACE39 for ; Wed, 15 Apr 2015 17:15:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9DA0F1BCE7F2; Wed, 15 Apr 2015 17:15:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B61AE1BCE5DA; Wed, 15 Apr 2015 17:15:49 -0700 (PDT) Message-ID: <552EFF35.10502@joelhalpern.com> Date: Wed, 15 Apr 2015 20:15:49 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Smith , Linda Dunbar , "Carlos Pignataro (cpignata)" References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> <552EF9CE.30803@joelhalpern.com> <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> In-Reply-To: <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 16 Apr 2015 00:15:52 -0000 We are certainly not mandating that all service function paths have to by symmetric. They clearly don't. I did not even think that we were mandating that if you want symmetry you have to do it this way. Using classifiers and SFF behaviors is one way to achieve it. Using control mechanisms so that from the point of view of the data plane mechanisms the two paths just happen to be the reverse of each other is also fine. And I am betting someone will come up with some alternative I have not even thought of. Is there a clarification we can add to make clear that the range of solutions is allowed by the architecture? Yours, Joel On 4/15/15 8:13 PM, Ian Smith wrote: > I recall the conversation re: supporting full symmetry, and I get that people want it and generally think I understand why they want it. > > I suppose I'm reading it to say that you MAY have symmetric flows, and when you do they should look "like this", but they aren't a MUST requirement of the architecture. Is that what you intended? > > If so, I have no issue with it as written, since that is how it is actually done today. > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 15, 2015 7:53 PM > To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry > > I could live with this model for symmetry. I agree with you that it reflects a common case. We were asked explicitly to include support for full symmetry, which is generally simpler to handle as a specific case rather than as a generalization of going through specific functions. > There are mechanisms people would like to use that fit that model. > > Yours, > Joel > > On 4/15/15 12:34 PM, Ian Smith wrote: >> I think it is also fair to say that there are cases where the chain itself is not symmetric, but a subset of that chain is. >> >> What I've found to be an effective way of looking situations like this is to treat them as two separate flows - one in each direction (to the internet & from the internet) and then converge the flows on the nodes that expect them to be converged. >> >> This yields a design paradigm where there is no symmetry, only persistent nodes where both directions of traffic MUST traverse and nodes where both directions of traffic MAY traverse. This changes the problem from one where a single full-duplex symmetry is required (usually in excess of actuality) to one where two or more half-duplex symmetries are called for, and it shifts the problem of state from a wiring problem (or the arrangement of virtual wires) to a routing problem. >> >> Concentrating on this routing problem, not the wiring problem, is what I read the document to be suggesting is the way forward. >> >> When you talk of using controllers, this is implicitly what you're talking about doing. So there isn't a symmetry problem in your example of A > network > B, because there is implicitly B > network > A which doesn't have to have the same value of "network". And in the case of something like A > D > B, the implication is that the sequence is locked in below routing in physical or virtual wiring domain so that there is no choice but to go through D to get to B from A and the inverse. In those cases, the implication is often that A == B or that A and B share some sort of state management methodology either explicitly (some sort of distributed systems) or implicitly (because of link-flow associations). >> >> Finally, I'd suggest that a FW, in this kind of scenario, probably doesn't _need_ to be tracking connections, because either it is being directed by a controller on a flow by flow basis, in which case there are two rules in the rule set (in the case of A > network > B), or because the network state is irrelevant because of a decision that was made outside of its view before the flow gets to it (in the case of A > D > B). The bottom line being that if you try to just pick up the design patterns from an SFC-free network and use them in and SFC network, the value that SFC adds on top of "Programmable, Elastic, Virtualized, and Scalable Infrastructure with an API" is being lost. >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, April 15, 2015 11:55 AM >> To: Joel M. Halpern; Carlos Pignataro (cpignata) >> Cc: sfc@ietf.org; 'Alia Atlas' >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate >> various ways of using "Classifier" to achieve SFC Symmetry >> >> Most likely classifiers at either end of the SFC domain don't even know where the FW (that require bidirectional congruency) in the network is and which instance of FW that packets will traverse. Bidirectional congruency, if required, has to be at the SF instance level. >> >> Therefore, very complicated mechanisms and coordination are required for a head-end Classifier (that has an embedded DPI engine) to enforce bidirectional congruency of a Firewall deployed in the middle of the network, and the complex mechanisms needed to collaborate with the other end of Classifier. >> >> >> Yes, it will make so much more sense to say: >> >> - symmetry "may be realized by multiple mechanisms", >> - " The statement itself is needed to indicate that several mechanism other folks want to use are also permitted by the architecture.", and >> - delete the description on Classifier based solutions >> >> Linda >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, April 15, 2015 8:56 AM >> To: Linda Dunbar; Carlos Pignataro (cpignata) >> Cc: sfc@ietf.org; 'Alia Atlas' >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate >> various ways of using "Classifier" to achieve SFC Symmetry >> >> I think your correction is backwards. It is true that the behavior you describe is permitted, and may even be common. It is still true that symmetry "may be realized ...". If this is a big deal, we could add a note that control mechanisms may play a role in achieving symmetry. I am not sure such a statement is needed, but I could live with it. >> >> The statement itself is needed to indicate that several mechanissm other folks want to use are also permitted by the archtiecture. >> >> Yours, >> Joel >> >> On 4/14/15 7:15 PM, Linda Dunbar wrote: >>> Joel and Carlos, >>> >>> Even though draft-ietf-sfc-architecture-07 is already in the status >>> of "request for publication", I hope you can make those simple >>> changes suggested. >>> >>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different >>> ways of using "Classifiers" to achieve SFC Symmetry. >>> >>> The definition of "Classifier" is "An element that performs >>> Classification", which can be as simple as separating traffic based >>> on some matching criteria. >>> >>> For traffic between A<->network <-> B, the classifier for traffic >>> from "A" -> "B" could be at the "network" port facing A; and the >>> classifier for traffic from "B" -> "A" could be at the "network" port facing B. >>> Therefore, using "Classifier" to achieve symmetry can be >>> cumbersome, as your list describing "stateful classifiers", "cluster >>> classifiers"; state exchanging among "classifiers", ... >>> >>> If a centralized SFC controller is deployed, classifiers at either >>> direction don't have to be involved in symmetry decision. >>> >>> Therefore, it is not true at all that "Symmetry may be >>> >>> realized in several ways depending on the SFF and classifier >>> >>> functionality." >>> >>> Symmetry is realized in great deal by how SFP is constructed or controlled. >>> >>> Since the sfc-architecture is not to advocate certain solutions, this >>> document shouldn't have the description on state exchanges among >>> classifiers to achieve SFC symmetry, i.e. should delete the 4^th >>> paragraph and the bullets after. >>> >>> Cheers, >>> >>> Linda >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Apr 15 18:05:01 2015 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 674881AD0A2 for ; Wed, 15 Apr 2015 18:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_17=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 zUy61VmQiaEg for ; Wed, 15 Apr 2015 18:04:55 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320B61AD0A7 for ; Wed, 15 Apr 2015 18:04:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,584,1422921600"; d="scan'208";a="158015697" X-IPAS-Result: A2CtBABMCi9V/+sKqMBUCINeXAXHJRoKhgMCggMBAQEBAQF+hCABAQEBAwEBASQTNAQHDAQCAQgRAQMBAQEeBQQHJwsUAwYIAgQBDQUIE4gcxi8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIosf4QlVwcGhCcFnEuGHolxg02CJRwUgTxvgUR/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 16 Apr 2015 01:04:54 +0000 Received: from SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 15 Apr 2015 18:04:53 -0700 Received: from SEAEXCHMBX04.olympus.F5Net.com ([fe80::c9a6:e310:2052:6c8a]) by SEAEXCHMBX04.olympus.F5Net.com ([fe80::c9a6:e310:2052:6c8a%21]) with mapi id 15.00.1044.021; Wed, 15 Apr 2015 18:04:53 -0700 From: Ian Smith To: Joel Halpern Direct , Linda Dunbar , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAAtbQqAAAs65CAAFJS7EP//qCMAgABzbzD//5MCgIAAclNw Date: Thu, 16 Apr 2015 01:04:53 +0000 Message-ID: <5c55e337d75f40948b70b4e5ba9f42a3@SEAEXCHMBX04.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> <552EF9CE.30803@joelhalpern.com> <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> <552EFF35.10502@joelhalpern.com> In-Reply-To: <552EFF35.10502@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: [192.168.15.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 16 Apr 2015 01:05:00 -0000 I think it is clear as written, I was just confirming that I was on the sam= e page. =20 Particularly, paragraph 1 in section 2.2 covers the MAY - MUST topic in a w= ay that shouldn't create uncertainty. And the rest of that section does a = fine job, I think, of explicating the tradeoffs of symmetric vs asymmetric = flows without being prescriptive. =20 A general observation that shouldn't delay publication is that we (networki= ng writ large) are, in general, experiencing namespace collisions that just= make things hard. "Classifier" comes with baggage in the form of assumpti= ons about the form factor a vendor might deliver the functionality, as this= thread shows, even if that is a pretty good label to hang on the function.= It is, in fact, a thing that is assigning a class or category to a datagr= am, packet, transport session, application transaction, or any other distin= guishing criteria; the very definition of "classifier". But that does not = mean, necessarily, that an SFC classifier is a deep packet inspector or tha= t it is, necessarily, burdened by the technological shortcomings of current= DPI offerings. It simply means that such a thing as an "SFC Classifier" e= xists and if DPI vendors (or vendors of any product) want their products to= be SFC classifiers, they have certain challenges to overcome, some of whic= h you touch on in section 2.2 regarding the relationship between state and = symmetry. =20 As Linda pointed out, there are other challenges as well, in particular the= relationship between decision and action. I don't believe that this is th= e document to delve into those things, in part because I don't believe that= the answers are complete enough to document. And in part because it takes= us down a rabbit hole that sounds much more like current best practices th= an architectural guidance. Maybe I'm wrong. Maybe we'll be rewriting this= sooner than we'd like because things have changed significantly. But I do= n't think that we have data to say that is the case today, so I feel that w= e should continue to press forward and not go down the rabbit hole (even th= ough I find it pretty darn interesting). =20 The corollary observation is that when we try to avoid such namespace bagga= ge, we end up with cumbersome names for things that end up being just as ba= d, if not worse. Again, there is no specific thing that I'm pointing at in= this draft, just a general observation after a day of heavy reading. =20 -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Wednesday, April 15, 2015 8:16 PM To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) Cc: sfc@ietf.org; 'Alia Atlas' Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate variou= s ways of using "Classifier" to achieve SFC Symmetry We are certainly not mandating that all service function paths have to by s= ymmetric. They clearly don't. I did not even think that we were mandating that if you want symmetry you h= ave to do it this way. Using classifiers and SFF behaviors is one way to a= chieve it. Using control mechanisms so that from the point of view of the = data plane mechanisms the two paths just happen to be the reverse of each o= ther is also fine. And I am betting someone will come up with some alterna= tive I have not even thought of. Is there a clarification we can add to make clear that the range of solutio= ns is allowed by the architecture? Yours, Joel On 4/15/15 8:13 PM, Ian Smith wrote: > I recall the conversation re: supporting full symmetry, and I get that pe= ople want it and generally think I understand why they want it. > > I suppose I'm reading it to say that you MAY have symmetric flows, and wh= en you do they should look "like this", but they aren't a MUST requirement = of the architecture. Is that what you intended? > > If so, I have no issue with it as written, since that is how it is actual= ly done today. > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 15, 2015 7:53 PM > To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate=20 > various ways of using "Classifier" to achieve SFC Symmetry > > I could live with this model for symmetry. I agree with you that it refl= ects a common case. We were asked explicitly to include support for full s= ymmetry, which is generally simpler to handle as a specific case rather tha= n as a generalization of going through specific functions. > There are mechanisms people would like to use that fit that model. > > Yours, > Joel > > On 4/15/15 12:34 PM, Ian Smith wrote: >> I think it is also fair to say that there are cases where the chain itse= lf is not symmetric, but a subset of that chain is. >> >> What I've found to be an effective way of looking situations like this i= s to treat them as two separate flows - one in each direction (to the inter= net & from the internet) and then converge the flows on the nodes that expe= ct them to be converged. >> >> This yields a design paradigm where there is no symmetry, only persisten= t nodes where both directions of traffic MUST traverse and nodes where both= directions of traffic MAY traverse. This changes the problem from one whe= re a single full-duplex symmetry is required (usually in excess of actualit= y) to one where two or more half-duplex symmetries are called for, and it s= hifts the problem of state from a wiring problem (or the arrangement of vir= tual wires) to a routing problem. >> >> Concentrating on this routing problem, not the wiring problem, is what I= read the document to be suggesting is the way forward. >> >> When you talk of using controllers, this is implicitly what you're talki= ng about doing. So there isn't a symmetry problem in your example of A >= network > B, because there is implicitly B > network > A which doesn't hav= e to have the same value of "network". And in the case of something like= A > D > B, the implication is that the sequence is locked in below routing= in physical or virtual wiring domain so that there is no choice but to go= through D to get to B from A and the inverse. In those cases, the implica= tion is often that A =3D=3D B or that A and B share some sort of state mana= gement methodology either explicitly (some sort of distributed systems) or = implicitly (because of link-flow associations). >> >> Finally, I'd suggest that a FW, in this kind of scenario, probably doesn= 't _need_ to be tracking connections, because either it is being directed b= y a controller on a flow by flow basis, in which case there are two rules i= n the rule set (in the case of A > network > B), or because the network sta= te is irrelevant because of a decision that was made outside of its view be= fore the flow gets to it (in the case of A > D > B). The bottom line being= that if you try to just pick up the design patterns from an SFC-free netwo= rk and use them in and SFC network, the value that SFC adds on top of "Prog= rammable, Elastic, Virtualized, and Scalable Infrastructure with an API" is= being lost. >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, April 15, 2015 11:55 AM >> To: Joel M. Halpern; Carlos Pignataro (cpignata) >> Cc: sfc@ietf.org; 'Alia Atlas' >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate=20 >> various ways of using "Classifier" to achieve SFC Symmetry >> >> Most likely classifiers at either end of the SFC domain don't even know = where the FW (that require bidirectional congruency) in the network is and = which instance of FW that packets will traverse. Bidirectional congruency, = if required, has to be at the SF instance level. >> >> Therefore, very complicated mechanisms and coordination are required for= a head-end Classifier (that has an embedded DPI engine) to enforce bidirec= tional congruency of a Firewall deployed in the middle of the network, and = the complex mechanisms needed to collaborate with the other end of Classifi= er. >> >> >> Yes, it will make so much more sense to say: >> >> - symmetry "may be realized by multiple mechanisms", >> - " The statement itself is needed to indicate that several mechanis= m other folks want to use are also permitted by the architecture.", and >> - delete the description on Classifier based solutions >> >> Linda >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, April 15, 2015 8:56 AM >> To: Linda Dunbar; Carlos Pignataro (cpignata) >> Cc: sfc@ietf.org; 'Alia Atlas' >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate=20 >> various ways of using "Classifier" to achieve SFC Symmetry >> >> I think your correction is backwards. It is true that the behavior you = describe is permitted, and may even be common. It is still true that symme= try "may be realized ...". If this is a big deal, we could add a note that= control mechanisms may play a role in achieving symmetry. I am not sure s= uch a statement is needed, but I could live with it. >> >> The statement itself is needed to indicate that several mechanissm other= folks want to use are also permitted by the archtiecture. >> >> Yours, >> Joel >> >> On 4/14/15 7:15 PM, Linda Dunbar wrote: >>> Joel and Carlos, >>> >>> Even though draft-ietf-sfc-architecture-07 is already in the status=20 >>> of "request for publication", I hope you can make those simple=20 >>> changes suggested. >>> >>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different=20 >>> ways of using "Classifiers" to achieve SFC Symmetry. >>> >>> The definition of "Classifier" is "An element that performs=20 >>> Classification", which can be as simple as separating traffic based=20 >>> on some matching criteria. >>> >>> For traffic between A<->network <-> B, the classifier for traffic=20 >>> from "A" -> "B" could be at the "network" port facing A; and the=20 >>> classifier for traffic from "B" -> "A" could be at the "network" port f= acing B. >>> Therefore, using "Classifier" to achieve symmetry can be=20 >>> cumbersome, as your list describing "stateful classifiers", "cluster=20 >>> classifiers"; state exchanging among "classifiers", ... >>> >>> If a centralized SFC controller is deployed, classifiers at either=20 >>> direction don't have to be involved in symmetry decision. >>> >>> Therefore, it is not true at all that "Symmetry may be >>> >>> realized in several ways depending on the SFF and classifier >>> >>> functionality." >>> >>> Symmetry is realized in great deal by how SFP is constructed or control= led. >>> >>> Since the sfc-architecture is not to advocate certain solutions,=20 >>> this document shouldn't have the description on state exchanges=20 >>> among classifiers to achieve SFC symmetry, i.e. should delete the=20 >>> 4^th paragraph and the bullets after. >>> >>> Cheers, >>> >>> Linda >>> >>> >>> >>> _______________________________________________ >>> 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 Apr 16 05:46:27 2015 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 3739D1A88CA for ; Thu, 16 Apr 2015 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_17=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 O5ocei7KXnO2 for ; Thu, 16 Apr 2015 05:46:23 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9131A1A88B6 for ; Thu, 16 Apr 2015 05:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9048; q=dns/txt; s=iport; t=1429188383; x=1430397983; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xqz9Bzc8KZxSI1eT9FoB2XMhrcDXZcQNXaKZweFS2j0=; b=O3AzrrqxXGIq+xzYJgqkJLk0dxhIqkeo0RAwpdyPVfCOoljUOXrgfHgQ UgPLDMrYKKCFYDe9219ZS83O5XuHnanf9OOFsOGz3btQoFh6mhZuEVv74 iVawNRVE7Uvv7omIVm0AZXGqJHc1yerNby5Nx8fBbupppWz2KnTxo6qQZ k=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BbBAC4rS9V/4kNJK1UCIMMUlwFgxDCA2YJgUUKhgMCgUU4FAEBAQEBAQF9hCABAQEDAQEBASAERwsFBwQCAQgOAwEDAQEBIwQDAgInCxQDBggCBA4FDg2IBwgNsR+VbAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyuEJSwrBwaCYi+BFgWOeoIcgXCBNIZ1gR2GH4lyg00igjOBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,587,1422921600"; d="asc'?scan'208";a="141685773" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 16 Apr 2015 12:46:22 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3GCkMA7019858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Apr 2015 12:46:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 07:46:22 -0500 From: "Carlos Pignataro (cpignata)" To: Ian Smith Thread-Topic: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry Thread-Index: AdB3CO1MZaglnSORSumKfRNcSqqUdAApPCeAAAQoioAAAVlpgAAPUiMAAAC2YwAAGk5JgA== Date: Thu, 16 Apr 2015 12:46:58 +0000 Message-ID: <8B3C1D7B-98C7-4379-9F58-7C4A3A0DF94B@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> <552EF9CE.30803@joelhalpern.com> <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> In-Reply-To: <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.52] Content-Type: multipart/signed; boundary="Apple-Mail=_D66F8603-8FC1-4076-B70E-4E556D51FD25"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Alia Atlas , "Joel M. Halpern" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 16 Apr 2015 12:46:26 -0000 --Apple-Mail=_D66F8603-8FC1-4076-B70E-4E556D51FD25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Net-net, it seems this thread is converging on no change needed. Alia, What=E2=80=99s the status of your AD review of the SFC Architecture? Thanks! =E2=80=94 Carlos. > On Apr 15, 2015, at 8:13 PM, Ian Smith wrote: >=20 > I recall the conversation re: supporting full symmetry, and I get that = people want it and generally think I understand why they want it. >=20 > I suppose I'm reading it to say that you MAY have symmetric flows, and = when you do they should look "like this", but they aren't a MUST = requirement of the architecture. Is that what you intended? >=20 > If so, I have no issue with it as written, since that is how it is = actually done today. >=20 >=20 >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 15, 2015 7:53 PM > To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) > Cc: sfc@ietf.org; 'Alia Atlas' > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate = various ways of using "Classifier" to achieve SFC Symmetry >=20 > I could live with this model for symmetry. I agree with you that it = reflects a common case. We were asked explicitly to include support for = full symmetry, which is generally simpler to handle as a specific case = rather than as a generalization of going through specific functions. > There are mechanisms people would like to use that fit that model. >=20 > Yours, > Joel >=20 > On 4/15/15 12:34 PM, Ian Smith wrote: >> I think it is also fair to say that there are cases where the chain = itself is not symmetric, but a subset of that chain is. >>=20 >> What I've found to be an effective way of looking situations like = this is to treat them as two separate flows - one in each direction (to = the internet & from the internet) and then converge the flows on the = nodes that expect them to be converged. >>=20 >> This yields a design paradigm where there is no symmetry, only = persistent nodes where both directions of traffic MUST traverse and = nodes where both directions of traffic MAY traverse. This changes the = problem from one where a single full-duplex symmetry is required = (usually in excess of actuality) to one where two or more half-duplex = symmetries are called for, and it shifts the problem of state from a = wiring problem (or the arrangement of virtual wires) to a routing = problem. >>=20 >> Concentrating on this routing problem, not the wiring problem, is = what I read the document to be suggesting is the way forward. >>=20 >> When you talk of using controllers, this is implicitly what you're = talking about doing. So there isn't a symmetry problem in your example = of A > network > B, because there is implicitly B > network > A which = doesn't have to have the same value of "network". And in the case of = something like A > D > B, the implication is that the sequence is locked = in below routing in physical or virtual wiring domain so that there is = no choice but to go through D to get to B from A and the inverse. In = those cases, the implication is often that A =3D=3D B or that A and B = share some sort of state management methodology either explicitly (some = sort of distributed systems) or implicitly (because of link-flow = associations). >>=20 >> Finally, I'd suggest that a FW, in this kind of scenario, probably = doesn't _need_ to be tracking connections, because either it is being = directed by a controller on a flow by flow basis, in which case there = are two rules in the rule set (in the case of A > network > B), or = because the network state is irrelevant because of a decision that was = made outside of its view before the flow gets to it (in the case of A > = D > B). The bottom line being that if you try to just pick up the = design patterns from an SFC-free network and use them in and SFC = network, the value that SFC adds on top of "Programmable, Elastic, = Virtualized, and Scalable Infrastructure with an API" is being lost. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Wednesday, April 15, 2015 11:55 AM >> To: Joel M. Halpern; Carlos Pignataro (cpignata) >> Cc: sfc@ietf.org; 'Alia Atlas' >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate >> various ways of using "Classifier" to achieve SFC Symmetry >>=20 >> Most likely classifiers at either end of the SFC domain don't even = know where the FW (that require bidirectional congruency) in the network = is and which instance of FW that packets will traverse. Bidirectional = congruency, if required, has to be at the SF instance level. >>=20 >> Therefore, very complicated mechanisms and coordination are required = for a head-end Classifier (that has an embedded DPI engine) to enforce = bidirectional congruency of a Firewall deployed in the middle of the = network, and the complex mechanisms needed to collaborate with the other = end of Classifier. >>=20 >>=20 >> Yes, it will make so much more sense to say: >>=20 >> - symmetry "may be realized by multiple mechanisms", >> - " The statement itself is needed to indicate that several = mechanism other folks want to use are also permitted by the = architecture.", and >> - delete the description on Classifier based solutions >>=20 >> Linda >>=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, April 15, 2015 8:56 AM >> To: Linda Dunbar; Carlos Pignataro (cpignata) >> Cc: sfc@ietf.org; 'Alia Atlas' >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate >> various ways of using "Classifier" to achieve SFC Symmetry >>=20 >> I think your correction is backwards. It is true that the behavior = you describe is permitted, and may even be common. It is still true = that symmetry "may be realized ...". If this is a big deal, we could = add a note that control mechanisms may play a role in achieving = symmetry. I am not sure such a statement is needed, but I could live = with it. >>=20 >> The statement itself is needed to indicate that several mechanissm = other folks want to use are also permitted by the archtiecture. >>=20 >> Yours, >> Joel >>=20 >> On 4/14/15 7:15 PM, Linda Dunbar wrote: >>> Joel and Carlos, >>>=20 >>> Even though draft-ietf-sfc-architecture-07 is already in the status >>> of "request for publication", I hope you can make those simple >>> changes suggested. >>>=20 >>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different >>> ways of using "Classifiers" to achieve SFC Symmetry. >>>=20 >>> The definition of "Classifier" is "An element that performs >>> Classification", which can be as simple as separating traffic based >>> on some matching criteria. >>>=20 >>> For traffic between A<->network <-> B, the classifier for traffic >>> from "A" -> "B" could be at the "network" port facing A; and the >>> classifier for traffic from "B" -> "A" could be at the "network" = port facing B. >>> Therefore, using "Classifier" to achieve symmetry can be >>> cumbersome, as your list describing "stateful classifiers", "cluster >>> classifiers"; state exchanging among "classifiers", ... >>>=20 >>> If a centralized SFC controller is deployed, classifiers at either >>> direction don't have to be involved in symmetry decision. >>>=20 >>> Therefore, it is not true at all that "Symmetry may be >>>=20 >>> realized in several ways depending on the SFF and classifier >>>=20 >>> functionality." >>>=20 >>> Symmetry is realized in great deal by how SFP is constructed or = controlled. >>>=20 >>> Since the sfc-architecture is not to advocate certain solutions, = this >>> document shouldn't have the description on state exchanges among >>> classifiers to achieve SFC symmetry, i.e. should delete the 4^th >>> paragraph and the bullets after. >>>=20 >>> Cheers, >>>=20 >>> Linda >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 --Apple-Mail=_D66F8603-8FC1-4076-B70E-4E556D51FD25 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 iEYEARECAAYFAlUvrx8ACgkQtfDPGTp3USyY1wCgqPOsonKBMVgLpKjZfS9gKx9S k0oAoLs+nA/dTHGGia8Z3EsP4sPnIC2E =KQbB -----END PGP SIGNATURE----- --Apple-Mail=_D66F8603-8FC1-4076-B70E-4E556D51FD25-- From nobody Thu Apr 16 09:38:11 2015 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 546091B32AA for ; Thu, 16 Apr 2015 09:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.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, HTML_MESSAGE=0.001, J_BACKHAIR_17=1, SPF_PASS=-0.001, 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 bTxEhwlxwWaA for ; Thu, 16 Apr 2015 09:38:04 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 ADDCA1B32A5 for ; Thu, 16 Apr 2015 09:38:04 -0700 (PDT) Received: by oblw8 with SMTP id w8so47816774obl.0 for ; Thu, 16 Apr 2015 09:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bfNBnh+tMajPhSo7REYENtYe7xQMC1YRwyKIXpMMSQE=; b=ZUrCdDSFmaqTKHmaeYlUhgQWBHSMAsnTn8PCzcFEGyX8fGpH10H7AA+D/ByRWU5loi iSlu2VqjYb3l40sTvC8QwCHDSXug6GKK3vHz6CK3h0UD/diJdxtcTNPimIvjZy30d/Tk UmEPpJ1QYAiJTPyxLOxJeYisEcs1jeKnWz9w/vNfBwBIJgDONludjKCSRNWZ9GciiVEM AWn3vtj3QB3afSWW+MmrMz2pvp+xLGioppjdCM4vvRlfPeotqkEhN7EeWK9opLgxAQ69 ehPzre1/HnL3hjrCZ9+ytmuInQZLLiY68zXXMZzzjsrTKnpVf5uenfpq1TFbm5Dy+oBj dI2w== MIME-Version: 1.0 X-Received: by 10.182.255.231 with SMTP id at7mr26543597obd.20.1429202284190; Thu, 16 Apr 2015 09:38:04 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Thu, 16 Apr 2015 09:38:04 -0700 (PDT) In-Reply-To: <8B3C1D7B-98C7-4379-9F58-7C4A3A0DF94B@cisco.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C05EB9@dfweml701-chm> <552E6E07.5050208@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657C063DB@dfweml701-chm> <7f6156f0085d41fb8c70e8bda7c06513@SEAEXCHMBX04.olympus.F5Net.com> <552EF9CE.30803@joelhalpern.com> <7944a7ecdeb744ff8154133adb75e348@SEAEXCHMBX04.olympus.F5Net.com> <8B3C1D7B-98C7-4379-9F58-7C4A3A0DF94B@cisco.com> Date: Thu, 16 Apr 2015 12:38:04 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a1134aaae7649560513da1651 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" , Ian Smith , Linda Dunbar Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry 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, 16 Apr 2015 16:38:08 -0000 --001a1134aaae7649560513da1651 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, Agreed as to the thread convergence. I'm still woefully behind on review the SFC architecture and other drafts. I will try and get to it this week - but if not this week, it may sit for 3 more weeks due to vacation, work-travel (a couple days that week might be possible), and IESG/IAB retreat. Do keep pinging me. Alia On Thu, Apr 16, 2015 at 8:46 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Net-net, it seems this thread is converging on no change needed. > > Alia, > > What=E2=80=99s the status of your AD review of the SFC Architecture? > > Thanks! > > =E2=80=94 Carlos. > > > On Apr 15, 2015, at 8:13 PM, Ian Smith wrote: > > > > I recall the conversation re: supporting full symmetry, and I get that > people want it and generally think I understand why they want it. > > > > I suppose I'm reading it to say that you MAY have symmetric flows, and > when you do they should look "like this", but they aren't a MUST > requirement of the architecture. Is that what you intended? > > > > If so, I have no issue with it as written, since that is how it is > actually done today. > > > > > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Wednesday, April 15, 2015 7:53 PM > > To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata) > > Cc: sfc@ietf.org; 'Alia Atlas' > > Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate > various ways of using "Classifier" to achieve SFC Symmetry > > > > I could live with this model for symmetry. I agree with you that it > reflects a common case. We were asked explicitly to include support for > full symmetry, which is generally simpler to handle as a specific case > rather than as a generalization of going through specific functions. > > There are mechanisms people would like to use that fit that model. > > > > Yours, > > Joel > > > > On 4/15/15 12:34 PM, Ian Smith wrote: > >> I think it is also fair to say that there are cases where the chain > itself is not symmetric, but a subset of that chain is. > >> > >> What I've found to be an effective way of looking situations like this > is to treat them as two separate flows - one in each direction (to the > internet & from the internet) and then converge the flows on the nodes th= at > expect them to be converged. > >> > >> This yields a design paradigm where there is no symmetry, only > persistent nodes where both directions of traffic MUST traverse and nodes > where both directions of traffic MAY traverse. This changes the problem > from one where a single full-duplex symmetry is required (usually in exce= ss > of actuality) to one where two or more half-duplex symmetries are called > for, and it shifts the problem of state from a wiring problem (or the > arrangement of virtual wires) to a routing problem. > >> > >> Concentrating on this routing problem, not the wiring problem, is what > I read the document to be suggesting is the way forward. > >> > >> When you talk of using controllers, this is implicitly what you're > talking about doing. So there isn't a symmetry problem in your example o= f > A > network > B, because there is implicitly B > network > A which doesn= 't > have to have the same value of "network". And in the case of something > like A > D > B, the implication is that the sequence is locked in below > routing in physical or virtual wiring domain so that there is no choice > but to go through D to get to B from A and the inverse. In those cases, > the implication is often that A =3D=3D B or that A and B share some sort = of > state management methodology either explicitly (some sort of distributed > systems) or implicitly (because of link-flow associations). > >> > >> Finally, I'd suggest that a FW, in this kind of scenario, probably > doesn't _need_ to be tracking connections, because either it is being > directed by a controller on a flow by flow basis, in which case there are > two rules in the rule set (in the case of A > network > B), or because th= e > network state is irrelevant because of a decision that was made outside o= f > its view before the flow gets to it (in the case of A > D > B). The bott= om > line being that if you try to just pick up the design patterns from an > SFC-free network and use them in and SFC network, the value that SFC adds > on top of "Programmable, Elastic, Virtualized, and Scalable Infrastructur= e > with an API" is being lost. > >> > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar > >> Sent: Wednesday, April 15, 2015 11:55 AM > >> To: Joel M. Halpern; Carlos Pignataro (cpignata) > >> Cc: sfc@ietf.org; 'Alia Atlas' > >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate > >> various ways of using "Classifier" to achieve SFC Symmetry > >> > >> Most likely classifiers at either end of the SFC domain don't even kno= w > where the FW (that require bidirectional congruency) in the network is an= d > which instance of FW that packets will traverse. Bidirectional congruency= , > if required, has to be at the SF instance level. > >> > >> Therefore, very complicated mechanisms and coordination are required > for a head-end Classifier (that has an embedded DPI engine) to enforce > bidirectional congruency of a Firewall deployed in the middle of the > network, and the complex mechanisms needed to collaborate with the other > end of Classifier. > >> > >> > >> Yes, it will make so much more sense to say: > >> > >> - symmetry "may be realized by multiple mechanisms", > >> - " The statement itself is needed to indicate that several mechanis= m > other folks want to use are also permitted by the architecture.", and > >> - delete the description on Classifier based solutions > >> > >> Linda > >> > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Wednesday, April 15, 2015 8:56 AM > >> To: Linda Dunbar; Carlos Pignataro (cpignata) > >> Cc: sfc@ietf.org; 'Alia Atlas' > >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate > >> various ways of using "Classifier" to achieve SFC Symmetry > >> > >> I think your correction is backwards. It is true that the behavior yo= u > describe is permitted, and may even be common. It is still true that > symmetry "may be realized ...". If this is a big deal, we could add a no= te > that control mechanisms may play a role in achieving symmetry. I am not > sure such a statement is needed, but I could live with it. > >> > >> The statement itself is needed to indicate that several mechanissm > other folks want to use are also permitted by the archtiecture. > >> > >> Yours, > >> Joel > >> > >> On 4/14/15 7:15 PM, Linda Dunbar wrote: > >>> Joel and Carlos, > >>> > >>> Even though draft-ietf-sfc-architecture-07 is already in the status > >>> of "request for publication", I hope you can make those simple > >>> changes suggested. > >>> > >>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different > >>> ways of using "Classifiers" to achieve SFC Symmetry. > >>> > >>> The definition of "Classifier" is "An element that performs > >>> Classification", which can be as simple as separating traffic based > >>> on some matching criteria. > >>> > >>> For traffic between A<->network <-> B, the classifier for traffic > >>> from "A" -> "B" could be at the "network" port facing A; and the > >>> classifier for traffic from "B" -> "A" could be at the "network" port > facing B. > >>> Therefore, using "Classifier" to achieve symmetry can be > >>> cumbersome, as your list describing "stateful classifiers", "cluster > >>> classifiers"; state exchanging among "classifiers", ... > >>> > >>> If a centralized SFC controller is deployed, classifiers at either > >>> direction don't have to be involved in symmetry decision. > >>> > >>> Therefore, it is not true at all that "Symmetry may be > >>> > >>> realized in several ways depending on the SFF and classifier > >>> > >>> functionality." > >>> > >>> Symmetry is realized in great deal by how SFP is constructed or > controlled. > >>> > >>> Since the sfc-architecture is not to advocate certain solutions, this > >>> document shouldn't have the description on state exchanges among > >>> classifiers to achieve SFC symmetry, i.e. should delete the 4^th > >>> paragraph and the bullets after. > >>> > >>> Cheers, > >>> > >>> Linda > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > --001a1134aaae7649560513da1651 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos,

Agreed as to the thread converg= ence.
I'm still woefully behind on review the SFC architectur= e and other drafts.
I will try and get to it this week - but if n= ot this week, it may sit for 3 more weeks
due to vacation, work-t= ravel (a couple days that week might be possible), and
IESG/IAB r= etreat.

Do keep pinging me.

Alia

On Thu, Apr 16, 2015 at 8:46 AM, Carlos Pignataro (cpignata) <cpignata@= cisco.com> wrote:
Net-net,= it seems this thread is converging on no change needed.

Alia,

What=E2=80=99s the status of your AD review of the SFC Architecture?

Thanks!

=E2=80=94 Carlos.

> On Apr 15, 2015, at 8:13 PM, Ian Smith <I.Smith@F5.com> wrote: >
> I recall the conversation re: supporting full symmetry, and I get that= people want it and generally think I understand why they want it.
>
> I suppose I'm reading it to say that you MAY have symmetric flows,= and when you do they should look "like this", but they aren'= t a MUST requirement of the architecture.=C2=A0 Is that what you intended?<= br> >
> If so, I have no issue with it as written, since that is how it is act= ually done today.
>
>
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
> Sent: Wednesday, April 15, 2015 7:53 PM
> To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata)
> Cc: sfc@ietf.org; 'Alia Atlas&= #39;
> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advoca= te various ways of using "Classifier" to achieve SFC Symmetry
>
> I could live with this model for symmetry.=C2=A0 I agree with you that= it reflects a common case.=C2=A0 We were asked explicitly to include suppo= rt for full symmetry, which is generally simpler to handle as a specific ca= se rather than as a generalization of going through specific functions.
> There are mechanisms people would like to use that fit that model.
>
> Yours,
> Joel
>
> On 4/15/15 12:34 PM, Ian Smith wrote:
>> I think it is also fair to say that there are cases where the chai= n itself is not symmetric, but a subset of that chain is.
>>
>> What I've found to be an effective way of looking situations l= ike this is to treat them as two separate flows - one in each direction (to= the internet & from the internet) and then converge the flows on the n= odes that expect them to be converged.
>>
>> This yields a design paradigm where there is no symmetry, only per= sistent nodes where both directions of traffic MUST traverse and nodes wher= e both directions of traffic MAY traverse.=C2=A0 This changes the problem f= rom one where a single full-duplex symmetry is required (usually in excess = of actuality) to one where two or more half-duplex symmetries are called fo= r, and it shifts the problem of state from a wiring problem (or the arrange= ment of virtual wires) to a routing problem.
>>
>> Concentrating on this routing problem, not the wiring problem, is = what I read the document to be suggesting is the way forward.
>>
>> When you talk of using controllers, this is implicitly what you= 9;re talking about doing.=C2=A0 So there isn't a symmetry problem in yo= ur example of=C2=A0 =C2=A0A > network > B, because there is implicitl= y B > network > A which doesn't have to have the same value of &q= uot;network".=C2=A0 =C2=A0 And in the case of something like A > D = > B, the implication is that the sequence is locked in below routing in = physical or virtual=C2=A0 wiring domain so that there is no choice but to g= o through D to get to B from A and the inverse.=C2=A0 In those cases, the i= mplication is often that A =3D=3D B or that A and B share some sort of stat= e management methodology either explicitly (some sort of distributed system= s) or implicitly (because of link-flow associations).
>>
>> Finally, I'd suggest that a FW, in this kind of scenario, prob= ably doesn't _need_ to be tracking connections, because either it is be= ing directed by a controller on a flow by flow basis, in which case there a= re two rules in the rule set (in the case of A > network > B), or bec= ause the network state is irrelevant because of a decision that was made ou= tside of its view before the flow gets to it (in the case of A > D > = B).=C2=A0 The bottom line being that if you try to just pick up the design = patterns from an SFC-free network and use them in and SFC network, the valu= e that SFC adds on top of "Programmable, Elastic, Virtualized, and Sca= lable Infrastructure with an API" is being lost.
>>
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Linda Dunbar
>> Sent: Wednesday, April 15, 2015 11:55 AM
>> To: Joel M. Halpern; Carlos Pignataro (cpignata)
>> Cc: sfc@ietf.org; 'Alia At= las'
>> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't ad= vocate
>> various ways of using "Classifier" to achieve SFC Symmet= ry
>>
>> Most likely classifiers at either end of the SFC domain don't = even know where the FW (that require bidirectional congruency) in the netwo= rk is and which instance of FW that packets will traverse. Bidirectional co= ngruency, if required, has to be at the SF instance level.
>>
>> Therefore, very complicated mechanisms and coordination are requir= ed for a head-end Classifier (that has an embedded DPI engine) to enforce b= idirectional congruency of a Firewall deployed in the middle of the network= , and the complex mechanisms needed to collaborate with the other end of Cl= assifier.
>>
>>
>> Yes, it will make so much more sense to say:
>>
>>=C2=A0 =C2=A0- symmetry "may be realized by multiple mechanism= s",
>>=C2=A0 =C2=A0- " The statement itself is needed to indicate th= at several mechanism other folks want to use are also permitted by the arch= itecture.", and
>>=C2=A0 =C2=A0- delete the description on Classifier based solutions=
>>
>> Linda
>>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Wednesday, April 15, 2015 8:56 AM
>> To: Linda Dunbar; Carlos Pignataro (cpignata)
>> Cc: sfc@ietf.org; 'Alia At= las'
>> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't ad= vocate
>> various ways of using "Classifier" to achieve SFC Symmet= ry
>>
>> I think your correction is backwards.=C2=A0 It is true that the be= havior you describe is permitted, and may even be common.=C2=A0 It is still= true that symmetry "may be realized ...".=C2=A0 If this is a big= deal, we could add a note that control mechanisms may play a role in achie= ving symmetry.=C2=A0 I am not sure such a statement is needed, but I could = live with it.
>>
>> The statement itself is needed to indicate that several mechanissm= other folks want to use are also permitted by the archtiecture.
>>
>> Yours,
>> Joel
>>
>> On 4/14/15 7:15 PM, Linda Dunbar wrote:
>>> Joel and Carlos,
>>>
>>> Even though draft-ietf-sfc-architecture-07 is already in the s= tatus
>>> of "request for publication", I hope you can make th= ose simple
>>> changes suggested.
>>>
>>> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 dif= ferent
>>> ways of using "Classifiers" to achieve SFC Symmetry.=
>>>
>>> The definition of "Classifier" is "An element t= hat performs
>>> Classification", which can be as simple as separating tra= ffic based
>>> on some matching criteria.
>>>
>>> For traffic between=C2=A0 A<->network <-> B, the c= lassifier for traffic
>>> from "A" -> "B" could be at the "n= etwork" port facing A; and the
>>> classifier for traffic from "B" -> "A" = could be at the "network" port facing B.
>>>=C2=A0 =C2=A0Therefore, using "Classifier" to achieve= symmetry can be
>>> cumbersome, as your list describing "stateful classifiers= ", "cluster
>>> classifiers"; state exchanging among "classifiers&qu= ot;, ...
>>>
>>> If a centralized SFC controller is deployed, classifiers at ei= ther
>>> direction don't have to be involved in symmetry decision.<= br> >>>
>>> Therefore, it is not true at all that "Symmetry may be >>>
>>> realized in several ways depending on the SFF and classifier >>>
>>> functionality."
>>>
>>> Symmetry is realized in great deal by how SFP is constructed o= r controlled.
>>>
>>> Since the sfc-architecture is not to advocate certain solution= s, this
>>> document shouldn't have the description on state exchanges= among
>>> classifiers to achieve SFC symmetry, i.e. should delete the 4^= th
>>> paragraph and the bullets after.
>>>
>>> Cheers,
>>>
>>> Linda
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>


--001a1134aaae7649560513da1651-- From nobody Thu Apr 16 12:23:18 2015 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 A0A661B351E; Thu, 16 Apr 2015 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 uGO-mN0_Y1q6; Thu, 16 Apr 2015 12:23:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F131B351B; Thu, 16 Apr 2015 12:23:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416192314.10396.57304.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 12:23:14 -0700 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: 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, 16 Apr 2015 19:23:16 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ From nobody Mon Apr 20 16:02:44 2015 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 824381B3411 for ; Mon, 20 Apr 2015 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 BEwg3jNx4xwb for ; Mon, 20 Apr 2015 16:02:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464061B3324 for ; Mon, 20 Apr 2015 16:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2386; q=dns/txt; s=iport; t=1429570962; x=1430780562; h=from:to:cc:subject:date:message-id:mime-version; bh=f+y4UvHetvzGFE8A95voFyaHBtQe1XfXzCj07VhJ898=; b=iC6dPpkBg+oHlrZ7sSSD7mnJLZPTpmOkD0oYW6v2Gv0e3D9wMhbIfqUw SCj8SsWixmtRgPVOsoJx4+/w0GhWYeWmCfe4VDlLzj06W1zEfpsdHq+Jt ZPkVB5fBj6OxZnp9T3l90z+S55uT4LfA4+CMxQVh3WWdZhdK9mmXgZWxE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CCBQCchDVV/49dJa1bgkVHgTPNKIE7TAEBAQEBAX6EIwR5EgEMAXMnBAEJBIgwylABAQEBAQEBAwEBAQEBAQEBGpA7hDQFkSuKIZUiIoNzgjOBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,611,1422921600"; d="scan'208,217";a="413374765" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 20 Apr 2015 23:02:42 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3KN2ffL022784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Apr 2015 23:02:41 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 20 Apr 2015 18:02:41 -0500 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , Thomas Narten Thread-Topic: NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysA== Date: Mon, 20 Apr 2015 23:02:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.154.36.128] Content-Type: multipart/alternative; boundary="_000_D15AD3A028AD4smkumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] NSH and UDP Transport 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, 20 Apr 2015 23:02:43 -0000 --_000_D15AD3A028AD4smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Chairs, The hallmark of NSH is that it can be transported over many different overl= ays. Towards that, we already have an ether-type that allows us to carry NS= H natively over Ethernet and non-natively over UDP =96 via VXLAN-GPE. Given= that UDP is the basic, simplest and most common overlay transports, we sho= uld enable transporting NSH natively over UDP, as well. Is there a process for requesting a UDP port# for NSH for working group dra= fts ? Alternatively, in the spirit of saving the UDP name space, is it okay= to transfer a pre-allocated but un-used UDP port# ? As part of my work, I = had UDP port# 6633 allocated a couple of years ago for a similar purpose. T= his number is unused and I would be glad to transfer this over to NSH. Thanks, Surendra. --_000_D15AD3A028AD4smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Chairs,

The hallmark of NSH is that it can be transported over many different = overlays. Towards that, we already have an ether-type that allows us to car= ry NSH natively over Ethernet and non-natively over UDP =96 via VXLAN-GPE. = Given that UDP is the basic, simplest and most common overlay transports, we should enable transporting NSH nati= vely over UDP, as well.

Is there a process for requesting a UDP port# for NSH for working grou= p drafts ? Alternatively, in the spirit of saving the UDP name space, is it= okay to transfer a pre-allocated but un-used UDP port# ? As part of my wor= k, I had UDP port# 6633 allocated a couple of years ago for a similar purpose. This number is unused and I w= ould be glad to transfer this over to NSH.

Thanks,
Surendra.
--_000_D15AD3A028AD4smkumarciscocom_-- From nobody Mon Apr 20 16:39:15 2015 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 EFE2E1B34EF for ; Mon, 20 Apr 2015 16:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ii1d1iBZ8Fxu for ; Mon, 20 Apr 2015 16:39:12 -0700 (PDT) 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 6024A1B34EC for ; Mon, 20 Apr 2015 16:39:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 153C52828A2; Mon, 20 Apr 2015 16:39:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (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 665901C01B1; Mon, 20 Apr 2015 16:39:11 -0700 (PDT) Message-ID: <55358DFD.2040804@joelhalpern.com> Date: Mon, 20 Apr 2015 19:38:37 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Surendra Kumar (smkumar)" , "Jim Guichard (jguichar)" , Thomas Narten References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 20 Apr 2015 23:39:14 -0000 This seems a reasonable course, but defining how the NSH header is carried on various transports seems not to be in my reading of the WG scope. In particular, it seems a bit odd to define the mechanisms for some randomly selected subset of transports. Thus, while the omission is arguably a bug in the charter, it is equally a bug to decide we will describe how to handle some transports. And do we really want to have to produce documents for each and every transport? Yours, Joel On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: > Hello Chairs, > > The hallmark of NSH is that it can be transported over many different > overlays. Towards that, we already have an ether-type that allows us to > carry NSH natively over Ethernet and non-natively over UDP via > VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay > transports, we should enable transporting NSH natively over UDP, as well. > > Is there a process for requesting a UDP port# for NSH for working group > drafts ? Alternatively, in the spirit of saving the UDP name space, is > it okay to transfer a pre-allocated but un-used UDP port# ? As part of > my work, I had UDP port# 6633 allocated a couple of years ago for a > similar purpose. This number is unused and I would be glad to transfer > this over to NSH. > > Thanks, > Surendra. > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Apr 20 18:29:44 2015 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 DB3381A1A12 for ; Mon, 20 Apr 2015 18:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 v1Ff4DZv-wlM for ; Mon, 20 Apr 2015 18:29:39 -0700 (PDT) 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 126AB1A19F6 for ; Mon, 20 Apr 2015 18:29:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVC16803; Tue, 21 Apr 2015 01:29:37 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 02:29:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 09:29:33 +0800 From: Xuxiaohu To: "Surendra Kumar (smkumar)" , "Jim Guichard (jguichar)" , Thomas Narten Thread-Topic: NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1WrQ7A Date: Tue, 21 Apr 2015 01:29:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326DDD@NKGEML512-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326DDDNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 21 Apr 2015 01:29:42 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326DDDNKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Surendra, I fully agree with you that we should enable transporting NSH natively over= UDP as well. Best regards, Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkuma= r) Sent: Tuesday, April 21, 2015 7:03 AM To: Jim Guichard (jguichar); Thomas Narten Cc: sfc@ietf.org Subject: [sfc] NSH and UDP Transport Hello Chairs, The hallmark of NSH is that it can be transported over many different overl= ays. Towards that, we already have an ether-type that allows us to carry NS= H natively over Ethernet and non-natively over UDP - via VXLAN-GPE. Given t= hat UDP is the basic, simplest and most common overlay transports, we shoul= d enable transporting NSH natively over UDP, as well. Is there a process for requesting a UDP port# for NSH for working group dra= fts ? Alternatively, in the spirit of saving the UDP name space, is it okay= to transfer a pre-allocated but un-used UDP port# ? As part of my work, I = had UDP port# 6633 allocated a couple of years ago for a similar purpose. T= his number is unused and I would be glad to transfer this over to NSH. Thanks, Surendra. --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326DDDNKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Surendr= a,

 = ;

I fully ag= ree with you that we should enable transporting NSH natively over UDP as we= ll.

 = ;

Best regar= ds,

Xiaohu

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Surendra Kumar (smkumar)
Sent: Tuesday, April 21, 2015 7:03 AM
To: Jim Guichard (jguichar); Thomas Narten
Cc: sfc@ietf.org
Subject: [sfc] NSH and UDP Transport

 

Hello Chairs= ,

 <= /o:p>

The hallmark= of NSH is that it can be transported over many different overlays. Towards= that, we already have an ether-type that allows us to carry NSH natively over Ethernet and non-natively over UDP – via VXLAN-GPE= . Given that UDP is the basic, simplest and most common overlay transports,= we should enable transporting NSH natively over UDP, as well.

 <= /o:p>

Is there a p= rocess for requesting a UDP port# for NSH for working group drafts ? Altern= atively, in the spirit of saving the UDP name space, is it okay to transfer a pre-allocated but un-used UDP port# ? As part of my wor= k, I had UDP port# 6633 allocated a couple of years ago for a similar purpo= se. This number is unused and I would be glad to transfer this over to NSH.=

 <= /o:p>

Thanks,=

Surendra.

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326DDDNKGEML512MBSchi_-- From nobody Mon Apr 20 18:36:31 2015 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 77A4C1A1B9E for ; Mon, 20 Apr 2015 18:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 WZY_4CKWVOIx for ; Mon, 20 Apr 2015 18:36:29 -0700 (PDT) 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 BC3781A1B6D for ; Mon, 20 Apr 2015 18:36:21 -0700 (PDT) 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 BVC17251; Tue, 21 Apr 2015 01:36:20 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 02:36:19 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 09:36:12 +0800 From: Xuxiaohu To: "Joel M. Halpern" , "Surendra Kumar (smkumar)" , "Jim Guichard (jguichar)" , "Thomas Narten" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1WCKaAgAClK7A= Date: Tue, 21 Apr 2015 01:36:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08326DF7@NKGEML512-MBS.china.huawei.com> References: <55358DFD.2040804@joelhalpern.com> In-Reply-To: <55358DFD.2040804@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 21 Apr 2015 01:36:30 -0000 Hi Joel, > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, April 21, 2015 7:39 AM > To: Surendra Kumar (smkumar); Jim Guichard (jguichar); Thomas Narten > Cc: sfc@ietf.org > Subject: Re: [sfc] NSH and UDP Transport >=20 > This seems a reasonable course, but defining how the NSH header is carrie= d on > various transports seems not to be in my reading of the WG scope. >=20 > In particular, it seems a bit odd to define the mechanisms for some rando= mly > selected subset of transports. Thus, while the omission is arguably a bu= g in the > charter, it is equally a bug to decide we will describe how to handle som= e > transports. And do we really want to have to produce documents for each = and > every transport? IMHO, we should at least produce documents for some common transports, such= as UDP/IP and MPLS. Best regards, Xiaohu > Yours, > Joel >=20 > On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: > > Hello Chairs, > > > > The hallmark of NSH is that it can be transported over many different > > overlays. Towards that, we already have an ether-type that allows us > > to carry NSH natively over Ethernet and non-natively over UDP - via > > VXLAN-GPE. Given that UDP is the basic, simplest and most common > > overlay transports, we should enable transporting NSH natively over UDP= , as > well. > > > > Is there a process for requesting a UDP port# for NSH for working > > group drafts ? Alternatively, in the spirit of saving the UDP name > > space, is it okay to transfer a pre-allocated but un-used UDP port# ? > > As part of my work, I had UDP port# 6633 allocated a couple of years > > ago for a similar purpose. This number is unused and I would be glad > > to transfer this over to NSH. > > > > Thanks, > > Surendra. > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 20 23:05:46 2015 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 9BFEF1ACD97 for ; Mon, 20 Apr 2015 23:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ryYl2ab218IA for ; Mon, 20 Apr 2015 23:05:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5E11B32C7 for ; Mon, 20 Apr 2015 23:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2530; q=dns/txt; s=iport; t=1429596339; x=1430805939; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QA43jZYN0CbTthIXd9Rz5dPYnLKY8JAe9YCu256Ljxc=; b=XjwalZsbNY3FhhLxU7ikMPFS/99ilSQQ9S6h+j9PEkGbK6uaAZxwDQHi metKAIxHSgtP0cwGoEvMPvGvnWVqfqVwiz9H4sjBEYJkD7LVMunLLhUOq vEKAWPHfhAMgLb4t/0Q1Nz/ruulpihxf/ZXbaDWHgDZ2Gk+sDOX9hnwe0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C6BACO6DVV/5FdJa1bgwxSXAXGBAmBRQqGBAKBPTgUAQEBAQEBAX2EIQEBBAEBAWQHCxACAQgYLicLJQIEAQkEBYgrDclvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4RRMweELQWLDYQAgh6KIYZvjjMig3NvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,614,1422921600"; d="scan'208";a="143044611" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 21 Apr 2015 06:05:35 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3L65ZvJ013864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Apr 2015 06:05:35 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 21 Apr 2015 01:05:35 -0500 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , Thomas Narten Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSA///2w4A= Date: Tue, 21 Apr 2015 06:05:35 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> In-Reply-To: <55358DFD.2040804@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.152.237] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9664D224F8DC5245A27C6497F16E1278@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 21 Apr 2015 06:05:44 -0000 I may be missing the point, without a transport NSH becomes meaningless, whether charter calls for it or not. And when NSH is defined to be transport independent, it is imperative we show it carried over the basic ones. Just a cursory look at the newly minted NVO3 encapsulations tells us how many are not over UDP. UDP does not even impose additional functionality requirements as is done by VxLAN like transports. If the goal is to enable wide and easy adoption of NSH without barrier to entry, UDP seems like a trivial one. So, UDP by any stretch is not a random choice in that sense. Btw, this is just a means to enable carrying NSH, without altering any bit or re-defining any of NSH. Absolutely not advocating yet another draft to say =B3NSH port# is x". Just allocating/recycling the port# and including i= t in the NSH draft suffices - probably a one line change to NSH. Surendra. On 4/20/15, 4:38 PM, "Joel M. Halpern" wrote: >This seems a reasonable course, but defining how the NSH header is >carried on various transports seems not to be in my reading of the WG >scope. > >In particular, it seems a bit odd to define the mechanisms for some >randomly selected subset of transports. Thus, while the omission is >arguably a bug in the charter, it is equally a bug to decide we will >describe how to handle some transports. And do we really want to have >to produce documents for each and every transport? > >Yours, >Joel > >On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >> Hello Chairs, >> >> The hallmark of NSH is that it can be transported over many different >> overlays. Towards that, we already have an ether-type that allows us to >> carry NSH natively over Ethernet and non-natively over UDP =AD via >> VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay >> transports, we should enable transporting NSH natively over UDP, as >>well. >> >> Is there a process for requesting a UDP port# for NSH for working group >> drafts ? Alternatively, in the spirit of saving the UDP name space, is >> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >> my work, I had UDP port# 6633 allocated a couple of years ago for a >> similar purpose. This number is unused and I would be glad to transfer >> this over to NSH. >> >> Thanks, >> Surendra. >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Tue Apr 21 04:27:34 2015 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 DC62C1A92E5 for ; Tue, 21 Apr 2015 04:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 DL37130IURjx for ; Tue, 21 Apr 2015 04:27:31 -0700 (PDT) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8F73B1A923D for ; Tue, 21 Apr 2015 04:27:31 -0700 (PDT) Received: from [192.168.1.108] (unknown [50.255.148.181]) by lucidvision.com (Postfix) with ESMTP id CD17C330CD8C; Tue, 21 Apr 2015 07:27:30 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <55358DFD.2040804@joelhalpern.com> Date: Tue, 21 Apr 2015 07:27:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55358DFD.2040804@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Thomas Narten , Guichard Jim , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 21 Apr 2015 11:27:33 -0000 If and when we do go with an inline encap, which I think we = should BTW, let us please not re-live the "challenges" we endured with = pseudo-wires=20 where we defined them piecemeal, and in some cases, quite differently = from the others. PWs are a related archetype of what we would be doing = here, so we should learn from that past experience. For those not lucky = enough to be part of that, the way we went about designing the = encaps/etc... for PWs resulted in having to go back and try to make = things right only to be thwarted by existing implementations and = deployments a number of times. We also had to retrofit OAM into that = after the train left the station which was not easy and is still being = normalized many years later. --Tom > On Apr 20, 2015:7:38 PM, at 7:38 PM, Joel M. Halpern = wrote: >=20 > This seems a reasonable course, but defining how the NSH header is = carried on various transports seems not to be in my reading of the WG = scope. >=20 > In particular, it seems a bit odd to define the mechanisms for some = randomly selected subset of transports. Thus, while the omission is = arguably a bug in the charter, it is equally a bug to decide we will = describe how to handle some transports. And do we really want to have = to produce documents for each and every transport? >=20 > Yours, > Joel >=20 > On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >> Hello Chairs, >>=20 >> The hallmark of NSH is that it can be transported over many different >> overlays. Towards that, we already have an ether-type that allows us = to >> carry NSH natively over Ethernet and non-natively over UDP =96 via >> VXLAN-GPE. Given that UDP is the basic, simplest and most common = overlay >> transports, we should enable transporting NSH natively over UDP, as = well. >>=20 >> Is there a process for requesting a UDP port# for NSH for working = group >> drafts ? Alternatively, in the spirit of saving the UDP name space, = is >> it okay to transfer a pre-allocated but un-used UDP port# ? As part = of >> my work, I had UDP port# 6633 allocated a couple of years ago for a >> similar purpose. This number is unused and I would be glad to = transfer >> this over to NSH. >>=20 >> Thanks, >> Surendra. >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 From nobody Tue Apr 21 08:06:47 2015 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 C62801ACDD1 for ; Tue, 21 Apr 2015 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7465jzDrafcn for ; Tue, 21 Apr 2015 08:06:44 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2944A1ACE02 for ; Tue, 21 Apr 2015 08:06:44 -0700 (PDT) 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; Tue, 21 Apr 2015 11:06:43 -0400 From: Dave Dolson To: "Thomas D. Nadeau" , "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W0dCAgADGEAD///l6kA== Date: Tue, 21 Apr 2015 15:06:41 +0000 Message-ID: References: <55358DFD.2040804@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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Guichard Jim , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 21 Apr 2015 15:06:45 -0000 To my mind, Tom's statements indicate an urgency to standardize sooner rath= er than later. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Tuesday, April 21, 2015 7:28 AM To: Joel M. Halpern Cc: Thomas Narten; Guichard Jim; Surendra Kumar (smkumar); sfc@ietf.org Subject: Re: [sfc] NSH and UDP Transport If and when we do go with an inline encap, which I think we should BTW, le= t us please not re-live the "challenges" we endured with pseudo-wires=20 where we defined them piecemeal, and in some cases, quite differently from = the others. PWs are a related archetype of what we would be doing here, so = we should learn from that past experience. For those not lucky enough to b= e part of that, the way we went about designing the encaps/etc... for PWs r= esulted in having to go back and try to make things right only to be thwart= ed by existing implementations and deployments a number of times. We also h= ad to retrofit OAM into that after the train left the station which was not= easy and is still being normalized many years later. --Tom > On Apr 20, 2015:7:38 PM, at 7:38 PM, Joel M. Halpern wrote: >=20 > This seems a reasonable course, but defining how the NSH header is carrie= d on various transports seems not to be in my reading of the WG scope. >=20 > In particular, it seems a bit odd to define the mechanisms for some rando= mly selected subset of transports. Thus, while the omission is arguably a = bug in the charter, it is equally a bug to decide we will describe how to h= andle some transports. And do we really want to have to produce documents = for each and every transport? >=20 > Yours, > Joel >=20 > On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >> Hello Chairs, >>=20 >> The hallmark of NSH is that it can be transported over many different >> overlays. Towards that, we already have an ether-type that allows us to >> carry NSH natively over Ethernet and non-natively over UDP - via >> VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay >> transports, we should enable transporting NSH natively over UDP, as well= . >>=20 >> Is there a process for requesting a UDP port# for NSH for working group >> drafts ? Alternatively, in the spirit of saving the UDP name space, is >> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >> my work, I had UDP port# 6633 allocated a couple of years ago for a >> similar purpose. This number is unused and I would be glad to transfer >> this over to NSH. >>=20 >> Thanks, >> Surendra. >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 21 22:00:47 2015 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 9DDEB1A8AB1 for ; Tue, 21 Apr 2015 22:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 5QP-YbKuKtgV for ; Tue, 21 Apr 2015 22:00:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16291A8AA5 for ; Tue, 21 Apr 2015 22:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3684; q=dns/txt; s=iport; t=1429678841; x=1430888441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UmKaEpfx870bsd/vPSK1qpW7EM8L3fQVthIogqdHoSA=; b=iIjUdDtFrHFJRxqZjTu4ftLQgCPFyNgbb6V+Mv08AmFfjrHhFJ/v4K3Y kmcCYi8AZdE+azV8a8QjnvaFFPhfrSQXv/JtlZomdf+d2pU4AkkY2iOWt Vy50mLUcos+6zPFWMrDd0XbI4OcbD20+IprB6kUDLDXZ6W9xNbv1xoCWr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DNCADGKjdV/4gNJK1bgwxSXAXHagqCM4NRAoE4TAEBAQEBAX6EIAEBAQQBAQFkBwsMBAIBCA4DBAEBAScHJwsUCQgCBAEJBAUbiBANyzsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs3hQQHBoQnBYsShiGKKYEigzyCFo45IoIegVVvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,621,1422921600"; d="scan'208";a="413715129" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 22 Apr 2015 05:00:24 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3M50N57006217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 05:00:23 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 00:00:23 -0500 From: "Surendra Kumar (smkumar)" To: Dave Dolson , "Thomas D. Nadeau" , "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KA Date: Wed, 22 Apr 2015 05:00:22 +0000 Message-ID: References: <55358DFD.2040804@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.4.8.150116 x-originating-ip: [10.24.156.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 22 Apr 2015 05:00:46 -0000 There is already an inline encapsulation in NSH draft - Layer2(ether-type). We need one for L4. If I=B9m an operator deploying an NFV solution on an L3 infrastructure, as one example, why do I need the overhead of VxLAN* ? It is broken out the door if we force a specific transport that is on top of UDP while not supporting UDP itself. Surendra. PS: As for the urgency, UDP #6633 is available if WG/IETF has no objection, as I mentioned earlier. On 4/21/15, 8:06 AM, "Dave Dolson" wrote: >To my mind, Tom's statements indicate an urgency to standardize sooner >rather than later. > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas D. Nadeau >Sent: Tuesday, April 21, 2015 7:28 AM >To: Joel M. Halpern >Cc: Thomas Narten; Guichard Jim; Surendra Kumar (smkumar); sfc@ietf.org >Subject: Re: [sfc] NSH and UDP Transport > > > If and when we do go with an inline encap, which I think we should BTW, >let us please not re-live the "challenges" we endured with pseudo-wires >where we defined them piecemeal, and in some cases, quite differently >from the others. PWs are a related archetype of what we would be doing >here, so we should learn from that past experience. For those not lucky >enough to be part of that, the way we went about designing the >encaps/etc... for PWs resulted in having to go back and try to make >things right only to be thwarted by existing implementations and >deployments a number of times. We also had to retrofit OAM into that >after the train left the station which was not easy and is still being >normalized many years later. > > --Tom > > > >> On Apr 20, 2015:7:38 PM, at 7:38 PM, Joel M. Halpern >> wrote: >>=20 >> This seems a reasonable course, but defining how the NSH header is >>carried on various transports seems not to be in my reading of the WG >>scope. >>=20 >> In particular, it seems a bit odd to define the mechanisms for some >>randomly selected subset of transports. Thus, while the omission is >>arguably a bug in the charter, it is equally a bug to decide we will >>describe how to handle some transports. And do we really want to have >>to produce documents for each and every transport? >>=20 >> Yours, >> Joel >>=20 >> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>> Hello Chairs, >>>=20 >>> The hallmark of NSH is that it can be transported over many different >>> overlays. Towards that, we already have an ether-type that allows us to >>> carry NSH natively over Ethernet and non-natively over UDP - via >>> VXLAN-GPE. Given that UDP is the basic, simplest and most common >>>overlay >>> transports, we should enable transporting NSH natively over UDP, as >>>well. >>>=20 >>> Is there a process for requesting a UDP port# for NSH for working group >>> drafts ? Alternatively, in the spirit of saving the UDP name space, is >>> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>> similar purpose. This number is unused and I would be glad to transfer >>> this over to NSH. >>>=20 >>> Thanks, >>> Surendra. >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 21 23:38:19 2015 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 316481B31B5 for ; Tue, 21 Apr 2015 23:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 64pwu-sUeMBy for ; Tue, 21 Apr 2015 23:38:16 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8221B31B4 for ; Tue, 21 Apr 2015 23:38:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,622,1422921600"; d="scan'208";a="158899346" X-IPAS-Result: A2B8DgCkQDdV/+sKqMBbg15cBbkTjjwdCoIzg1ECgX8BAQEBAQF+hCABAQEBAwEBASRABwsMBAIBCBEEAQEBCR4HDxgLFAkIAgQBCQQFG4gdy18BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs3hFEzBwaEJwWLEpFsgzyCFo45gkCBVW+BRIEAAQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 22 Apr 2015 06:38:15 +0000 Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 21 Apr 2015 23:38:14 -0700 Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1044.021; Tue, 21 Apr 2015 23:38:14 -0700 From: Sumandra Majee To: "Surendra Kumar (smkumar)" , Dave Dolson , "Thomas D. Nadeau" , "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1XBBuAgADGDwCAAD09gIAA6O4A//+kgEM= Date: Wed, 22 Apr 2015 06:38:14 +0000 Message-ID: <1429684699272.32602@F5.com> References: <55358DFD.2040804@joelhalpern.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: [192.168.15.239] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 22 Apr 2015 06:38:18 -0000 What is the packet format of such encapsulation would look like?=0A= =0A= L2 :: OUTER-IP :: OUTER-UDP [ NSH -> IP ->TCP -> Payload] ... is that wha= t you are proposing? =0A= =0A= I am not saving much on processing of this format, so what is the end goal?= =0A= =0A= ________________________________________=0A= From: sfc on behalf of Surendra Kumar (smkumar) =0A= Sent: Tuesday, April 21, 2015 10:00 PM=0A= To: Dave Dolson; Thomas D. Nadeau; Joel M. Halpern=0A= Cc: Thomas Narten; Jim Guichard (jguichar); sfc@ietf.org=0A= Subject: Re: [sfc] NSH and UDP Transport=0A= =0A= There is already an inline encapsulation in NSH draft -=0A= Layer2(ether-type). We need one for L4.=0A= =0A= If I=B9m an operator deploying an NFV solution on an L3 infrastructure, as= =0A= one example, why do I need the overhead of VxLAN* ? It is broken out the=0A= door if we force a specific transport that is on top of UDP while not=0A= supporting UDP itself.=0A= =0A= Surendra.=0A= PS: As for the urgency, UDP #6633 is available if WG/IETF has no=0A= objection, as I mentioned earlier.=0A= =0A= =0A= =0A= On 4/21/15, 8:06 AM, "Dave Dolson" wrote:=0A= =0A= >To my mind, Tom's statements indicate an urgency to standardize sooner=0A= >rather than later.=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas D. Nadeau=0A= >Sent: Tuesday, April 21, 2015 7:28 AM=0A= >To: Joel M. Halpern=0A= >Cc: Thomas Narten; Guichard Jim; Surendra Kumar (smkumar); sfc@ietf.org=0A= >Subject: Re: [sfc] NSH and UDP Transport=0A= >=0A= >=0A= > If and when we do go with an inline encap, which I think we should = BTW,=0A= >let us please not re-live the "challenges" we endured with pseudo-wires=0A= >where we defined them piecemeal, and in some cases, quite differently=0A= >from the others. PWs are a related archetype of what we would be doing=0A= >here, so we should learn from that past experience. For those not lucky= =0A= >enough to be part of that, the way we went about designing the=0A= >encaps/etc... for PWs resulted in having to go back and try to make=0A= >things right only to be thwarted by existing implementations and=0A= >deployments a number of times. We also had to retrofit OAM into that=0A= >after the train left the station which was not easy and is still being=0A= >normalized many years later.=0A= >=0A= > --Tom=0A= >=0A= >=0A= >=0A= >> On Apr 20, 2015:7:38 PM, at 7:38 PM, Joel M. Halpern=0A= >> wrote:=0A= >>=0A= >> This seems a reasonable course, but defining how the NSH header is=0A= >>carried on various transports seems not to be in my reading of the WG=0A= >>scope.=0A= >>=0A= >> In particular, it seems a bit odd to define the mechanisms for some=0A= >>randomly selected subset of transports. Thus, while the omission is=0A= >>arguably a bug in the charter, it is equally a bug to decide we will=0A= >>describe how to handle some transports. And do we really want to have=0A= >>to produce documents for each and every transport?=0A= >>=0A= >> Yours,=0A= >> Joel=0A= >>=0A= >> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote:=0A= >>> Hello Chairs,=0A= >>>=0A= >>> The hallmark of NSH is that it can be transported over many different= =0A= >>> overlays. Towards that, we already have an ether-type that allows us to= =0A= >>> carry NSH natively over Ethernet and non-natively over UDP - via=0A= >>> VXLAN-GPE. Given that UDP is the basic, simplest and most common=0A= >>>overlay=0A= >>> transports, we should enable transporting NSH natively over UDP, as=0A= >>>well.=0A= >>>=0A= >>> Is there a process for requesting a UDP port# for NSH for working group= =0A= >>> drafts ? Alternatively, in the spirit of saving the UDP name space, is= =0A= >>> it okay to transfer a pre-allocated but un-used UDP port# ? As part of= =0A= >>> my work, I had UDP port# 6633 allocated a couple of years ago for a=0A= >>> similar purpose. This number is unused and I would be glad to transfer= =0A= >>> this over to NSH.=0A= >>>=0A= >>> Thanks,=0A= >>> Surendra.=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>=0A= >> _______________________________________________=0A= >> sfc mailing list=0A= >> sfc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >=0A= >_______________________________________________=0A= >sfc mailing list=0A= >sfc@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/sfc=0A= =0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Wed Apr 22 05:33:22 2015 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 9554B1B356D for ; Wed, 22 Apr 2015 05:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 y03bFZ9SAKqd for ; Wed, 22 Apr 2015 05:33:19 -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 693891B356A for ; Wed, 22 Apr 2015 05:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2496; q=dns/txt; s=iport; t=1429705996; x=1430915596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EW54yIco7qkFTLLKaJUPdVQnVSTlVL92ixYGxjnZnFA=; b=Q+ChcK1P9i+bvjUfEjW8LWiffMJ7jaxe52uyjN9AGIJjel0fWJmt12i3 YTWQ4tpWTIPaaF4upH6wZW3mmZLBJFxOaNpJuhBu8fK4fk3Xo0F8EJOl3 /jU9pFyLXUOe7IX/s7Qyoj6nXyH2hFey5T8jxOXJZeK+zozds5RKpmt5+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBAAUlDdV/5xdJa1bgwxSXAXGAAmBRQqGBAKBNjgUAQEBAQEBAX2EIAEBAQMBAQEBZAcLBQsCAQgYLicLJQIECgQFiCMIDcwLAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIs3hFEzB4MXgRYFkTOKKYZ0jjkig3NvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,623,1422921600"; d="scan'208";a="143502510" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 22 Apr 2015 12:33:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3MCXElN007158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 12:33:15 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.203]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 07:33:15 -0500 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YA= Date: Wed, 22 Apr 2015 12:33:14 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> In-Reply-To: <55358DFD.2040804@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 22 Apr 2015 12:33:20 -0000 Joel,=20 I concur: we don't want to start picking transports here, it creates all ki= nds of issues and is clearly out of scope. =20 Rather, if there's a need for a transport to support NSH, then the work can= occur in the associated working group. So, if there's a need for MPLS, th= en a draft can be submitted to MPLS, similarly, NVO3, LISP, etc. can all ha= ve NSH supporting drafts. This ensures both consistency and proper layerin= g within the scope of those protocols. On the UDP front specifically, there's a clear move to a explicit protocol = demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best place way to ha= ve a proper protocol stack. =20 Paul > On Apr 20, 2015, at 7:38 PM, Joel M. Halpern wrote: >=20 > This seems a reasonable course, but defining how the NSH header is carrie= d on various transports seems not to be in my reading of the WG scope. >=20 > In particular, it seems a bit odd to define the mechanisms for some rando= mly selected subset of transports. Thus, while the omission is arguably a = bug in the charter, it is equally a bug to decide we will describe how to h= andle some transports. And do we really want to have to produce documents = for each and every transport? >=20 > Yours, > Joel >=20 > On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >> Hello Chairs, >>=20 >> The hallmark of NSH is that it can be transported over many different >> overlays. Towards that, we already have an ether-type that allows us to >> carry NSH natively over Ethernet and non-natively over UDP =96 via >> VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay >> transports, we should enable transporting NSH natively over UDP, as well= . >>=20 >> Is there a process for requesting a UDP port# for NSH for working group >> drafts ? Alternatively, in the spirit of saving the UDP name space, is >> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >> my work, I had UDP port# 6633 allocated a couple of years ago for a >> similar purpose. This number is unused and I would be glad to transfer >> this over to NSH. >>=20 >> Thanks, >> Surendra. >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From wenqin.shao@telecom-paristech.fr Wed Apr 22 07:41:04 2015 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 C12401ACD3E for ; Wed, 22 Apr 2015 07:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, 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 duBDE_v0JBeD for ; Wed, 22 Apr 2015 07:41:03 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id 543E91ACED4 for ; Wed, 22 Apr 2015 07:40:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 9DBA01016CC for ; Wed, 22 Apr 2015 16:40:16 +0200 (CEST) Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Q5KmFR1jntN9 for ; Wed, 22 Apr 2015 16:40:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id C597C101434 for ; Wed, 22 Apr 2015 16:40:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XRSaQCBPA7_0 for ; Wed, 22 Apr 2015 16:40:15 +0200 (CEST) Received: from dhcp164-89.enst.fr (dhcp164-89.enst.fr [137.194.165.89]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 7A4601016CC for ; Wed, 22 Apr 2015 16:40:15 +0200 (CEST) From: Wenqin SHAO Content-Type: multipart/alternative; boundary="Apple-Mail=_B53A087C-98AE-4008-90AF-3C592FC30EA4" Message-Id: <621121B9-3225-4397-8545-81398B5E21DA@telecom-paristech.fr> Date: Wed, 22 Apr 2015 16:41:07 +0200 To: sfc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [sfc] Shifted figure reference in draft-ietf-sfc-nsh-00 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, 22 Apr 2015 14:44:29 -0000 --Apple-Mail=_B53A087C-98AE-4008-90AF-3C592FC30EA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello list, I found that some figure references in draft-ietf-sfc-nsh-00 were = shifted and pointed actually to a neighbouring figure. Here below a list of suspicious candidates . page 13, =E2=80=9CFigure 7 below illustrates=E2=80=A6=E2=80=9D, instead = of being =E2=80=9CFigure 7=E2=80=9D, I guess the draft means =E2=80=9CFigu= re 9=E2=80=9D. page 21, =E2=80=9CFigure 10 below depicts an SPI/SI=E2=80=9D. Figure 11 = is actually following right below. page 22, =E2=80=9C...as per figures 11 and 12 below.=E2=80=9D I guess = the sentence is trying to refer to Figure 12 and 13. page 22, =E2=80=9C...essentially a series of weighted (equally or = otherwise) overlay links to be used (for load distribution, redundancy or policy), see Figure 13. The metric depicted in Figure 13 is an example to help illustrated weighing SFs. =E2=80=9C "Figure 13=E2=80=9D in the quoted sentences should be Figure 14. page 25, =E2=80=9CThe figure below depicts the policy associated with = the graph in Figure 14 above.=E2=80=9D Figure 15 is actually referred to = according to the context. page 27, =E2=80=9CMetadata Augmentation: Information may be added to = NSH's existing metadata, as depicted in Figure 18.=E2=80=9D Figure 19, = instead of 18 is referred to. page 28, =E2=80=9CFigure 19 illustrates an example of updating = metadata.=E2=80=9D Figure 20 illustrates metadata update, 19 is for = metadata augmentation. page 29, =E2=80=9CFigure 20 illustrates an example of this behavior.=E2=80= =9D Should be Figure 21 instead. Regards, Wenqin --Apple-Mail=_B53A087C-98AE-4008-90AF-3C592FC30EA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello list,

I found that some = figure references in draft-ietf-sfc-nsh-00 were shifted and pointed = actually to a neighbouring figure.
Here below a list of suspicious = candidates .

page 13, =E2=80=9CFigure 7 = below illustrates=E2=80=A6=E2=80=9D, instead of = being =E2=80=9CFigure 7=E2=80=9D, I guess the draft = means =E2=80=9CFigure 9=E2=80=9D.

page = 21, =E2=80=9CFigure 10 below depicts an SPI/SI=E2=80=9D. Figure 11 = is actually following right below.

page = 22, =E2=80=9C...as per figures 11 and 12 below.=E2=80=9D I guess the sentence is trying to refer to = Figure 12 and 13.

page 22, =E2=80=9C...essentiall= y a series of weighted (equally or otherwise)
   overlay links to be =
used (for load distribution, redundancy or
   policy), see Figure 13.  The metric depicted in Figure 13 is an
   example to help illustrated weighing SFs. =E2=80=9C
= 
"Figure 13=E2=80=9D in the quoted =
sentences should be Figure 14.

page 25, =E2=80=9CThe figure =
below depicts the policy associated with the graph in =
Figure 14 above.=E2=80=9D Figure 15 =
is actually referred to according to the =
context.

page 27, =E2=80=9CMetadata Augmentation: Information may be added to NSH's =
existing metadata, as depicted in Figure 18.=E2=80=9D Figure 19, instead of 18 is referred =
to.

page 28, =E2=80=9CFigure 19 illustrates an example =
of updating metadata.=E2=80=9D Figure 20 illustrates =
metadata update, 19 is for metadata =
augmentation.

page 29, =E2=80=9CFigure 20 =
illustrates an example of this behavior.=E2=80=9D Should be Figure 21 =
instead.

Regards,
Wenqin


= --Apple-Mail=_B53A087C-98AE-4008-90AF-3C592FC30EA4-- From nobody Wed Apr 22 09:27:53 2015 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 7AC571B3792 for ; Wed, 22 Apr 2015 09:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 ug8-KMUj1Bzt for ; Wed, 22 Apr 2015 09:27:50 -0700 (PDT) Received: from mxe01.gs.com (mxe01.gs.com [204.4.178.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33941B378E for ; Wed, 22 Apr 2015 09:27:46 -0700 (PDT) Received: from pps.filterd (gsppacdp01sd.idz.gs.com [127.0.0.1]) by gsppacdp01sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t3MGKCQE017321; Wed, 22 Apr 2015 12:27:44 -0400 Received: from gsppacdp03nd.inz.gs.com ([10.205.68.208]) by gsppacdp01sd.idz.gs.com with ESMTP id 1txenh8qx9-1; Wed, 22 Apr 2015 12:27:44 -0400 Received: from pps.filterd (gsppacdp03nd.inz.gs.com [127.0.0.1]) by gsppacdp03nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t3MGHbQd003350; Wed, 22 Apr 2015 12:27:44 -0400 Received: from gshcbdp02ex.firmwide.corp.gs.com (gshcbdp02ex.firmwide.corp.gs.com [10.135.172.5]) by gsppacdp03nd.inz.gs.com with ESMTP id 1txcmbhtft-1; Wed, 22 Apr 2015 12:27:44 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp02ex.firmwide.corp.gs.com ([10.135.172.5]) with mapi; Wed, 22 Apr 2015 12:27:43 -0400 From: "Zarny, Myo" To: "'Wenqin SHAO'" , "'sfc@ietf.org'" Date: Wed, 22 Apr 2015 12:27:41 -0400 Thread-Topic: [sfc] Shifted figure reference in draft-ietf-sfc-nsh-00 Thread-Index: AdB9CuDSpi9tt5HMSqW0XgtyCdC1dgADdB+g Message-ID: References: <621121B9-3225-4397-8545-81398B5E21DA@telecom-paristech.fr> In-Reply-To: <621121B9-3225-4397-8545-81398B5E21DA@telecom-paristech.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23071EB2A6EAGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-22_05:2015-04-22,2015-04-22,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-22_05:2015-04-22,2015-04-22,1970-01-01 signatures=0 Archived-At: Subject: Re: [sfc] Shifted figure reference in draft-ietf-sfc-nsh-00 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, 22 Apr 2015 16:27:52 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23071EB2A6EAGSCMAMP19EXfi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2VpcWluLA0KDQpUaGFua3MgZm9yIHRoZSB0aG9yb3VnaCByZWFkaW5nLiBXZeKAmXJlIGF3 YXJlIG9mIHNoaWZ0cyBpbiBmaWd1cmUgbnVtYmVycywgZXZlbiBpbiB0aGUgbGF0ZXN0IGRyYWZ0 ICgwNyksIGFuZCB3ZeKAmWxsIGhhdmUgaXQgZml4ZWQgaW4gdGhlIG5leHQgZHJhZnQuDQoNClJl Z2FyZHMsDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgV2VucWluIFNIQU8NClNlbnQ6IDIyIEFwcmlsIDIwMTUgMTA6NDEgQU0NClRvOiBzZmNA aWV0Zi5vcmcNClN1YmplY3Q6IFtzZmNdIFNoaWZ0ZWQgZmlndXJlIHJlZmVyZW5jZSBpbiBkcmFm dC1pZXRmLXNmYy1uc2gtMDANCg0KSGVsbG8gbGlzdCwNCg0KSSBmb3VuZCB0aGF0IHNvbWUgZmln dXJlIHJlZmVyZW5jZXMgaW4gZHJhZnQtaWV0Zi1zZmMtbnNoLTAwIHdlcmUgc2hpZnRlZCBhbmQg cG9pbnRlZCBhY3R1YWxseSB0byBhIG5laWdoYm91cmluZyBmaWd1cmUuDQpIZXJlIGJlbG93IGEg bGlzdCBvZiBzdXNwaWNpb3VzIGNhbmRpZGF0ZXMgLg0KDQpwYWdlIDEzLCDigJxGaWd1cmUgNyBi ZWxvdyBpbGx1c3RyYXRlc+KApuKAnSwgaW5zdGVhZCBvZiBiZWluZyDigJxGaWd1cmUgN+KAnSwg SSBndWVzcyB0aGUgZHJhZnQgbWVhbnMg4oCcRmlndXJlIDnigJ0uDQoNCnBhZ2UgMjEsIOKAnEZp Z3VyZSAxMCBiZWxvdyBkZXBpY3RzIGFuIFNQSS9TSeKAnS4gRmlndXJlIDExIGlzIGFjdHVhbGx5 IGZvbGxvd2luZyByaWdodCBiZWxvdy4NCg0KcGFnZSAyMiwg4oCcLi4uYXMgcGVyIGZpZ3VyZXMg MTEgYW5kIDEyIGJlbG93LuKAnSBJIGd1ZXNzIHRoZSBzZW50ZW5jZSBpcyB0cnlpbmcgdG8gcmVm ZXIgdG8gRmlndXJlIDEyIGFuZCAxMy4NCg0KcGFnZSAyMiwg4oCcLi4uZXNzZW50aWFsbHkgYSBz ZXJpZXMgb2Ygd2VpZ2h0ZWQgKGVxdWFsbHkgb3Igb3RoZXJ3aXNlKQ0KDQogICBvdmVybGF5IGxp bmtzIHRvIGJlIHVzZWQgKGZvciBsb2FkIGRpc3RyaWJ1dGlvbiwgcmVkdW5kYW5jeSBvcg0KDQog ICBwb2xpY3kpLCBzZWUgRmlndXJlIDEzLiAgVGhlIG1ldHJpYyBkZXBpY3RlZCBpbiBGaWd1cmUg MTMgaXMgYW4NCg0KICAgZXhhbXBsZSB0byBoZWxwIGlsbHVzdHJhdGVkIHdlaWdoaW5nIFNGcy4g 4oCcDQoNCiJGaWd1cmUgMTPigJ0gaW4gdGhlIHF1b3RlZCBzZW50ZW5jZXMgc2hvdWxkIGJlIEZp Z3VyZSAxNC4NCg0KDQpwYWdlIDI1LCDigJxUaGUgZmlndXJlIGJlbG93IGRlcGljdHMgdGhlIHBv bGljeSBhc3NvY2lhdGVkIHdpdGggdGhlIGdyYXBoIGluIEZpZ3VyZSAxNCBhYm92ZS7igJ0gRmln dXJlIDE1IGlzIGFjdHVhbGx5IHJlZmVycmVkIHRvIGFjY29yZGluZyB0byB0aGUgY29udGV4dC4N Cg0KDQpwYWdlIDI3LCDigJxNZXRhZGF0YSBBdWdtZW50YXRpb246IEluZm9ybWF0aW9uIG1heSBi ZSBhZGRlZCB0byBOU0gncyBleGlzdGluZyBtZXRhZGF0YSwgYXMgZGVwaWN0ZWQgaW4gRmlndXJl IDE4LuKAnSBGaWd1cmUgMTksIGluc3RlYWQgb2YgMTggaXMgcmVmZXJyZWQgdG8uDQoNCg0KcGFn ZSAyOCwg4oCcRmlndXJlIDE5IGlsbHVzdHJhdGVzIGFuIGV4YW1wbGUgb2YgdXBkYXRpbmcgbWV0 YWRhdGEu4oCdIEZpZ3VyZSAyMCBpbGx1c3RyYXRlcyBtZXRhZGF0YSB1cGRhdGUsIDE5IGlzIGZv ciBtZXRhZGF0YSBhdWdtZW50YXRpb24uDQoNCg0KcGFnZSAyOSwg4oCcRmlndXJlIDIwIGlsbHVz dHJhdGVzIGFuIGV4YW1wbGUgb2YgdGhpcyBiZWhhdmlvci7igJ0gU2hvdWxkIGJlIEZpZ3VyZSAy MSBpbnN0ZWFkLg0KDQoNClJlZ2FyZHMsDQoNCldlbnFpbg0KDQoNCg0K --_000_A3233753A4B65F43BCA1B64DA99A9C23071EB2A6EAGSCMAMP19EXfi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhp IFdlaXFpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyBmb3IgdGhlIHRob3JvdWdoIHJlYWRp bmcuIFdl4oCZcmUgYXdhcmUgb2Ygc2hpZnRzIGluIGZpZ3VyZSBudW1iZXJzLCBldmVuIGluIHRo ZSBsYXRlc3QgZHJhZnQgKDA3KSwgYW5kIHdl4oCZbGwgaGF2ZSBpdCBmaXhlZCBpbiB0aGUgbmV4 dCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPldlbnFpbiBTSEFPPGJyPjxiPlNlbnQ6 PC9iPiAyMiBBcHJpbCAyMDE1IDEwOjQxIEFNPGJyPjxiPlRvOjwvYj4gc2ZjQGlldGYub3JnPGJy PjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBTaGlmdGVkIGZpZ3VyZSByZWZlcmVuY2UgaW4gZHJhZnQt aWV0Zi1zZmMtbnNoLTAwPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6OC41cHQnPkhlbGxvIGxpc3QsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdCc+SSBmb3VuZCB0aGF0IHNvbWUgZmlndXJl IHJlZmVyZW5jZXMgaW4mbmJzcDtkcmFmdC1pZXRmLXNmYy1uc2gtMDAgd2VyZSBzaGlmdGVkIGFu ZCBwb2ludGVkIGFjdHVhbGx5IHRvIGEmbmJzcDtuZWlnaGJvdXJpbmcgZmlndXJlLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdCc+SGVyZSBiZWxvdyBhIGxp c3Qgb2Ygc3VzcGljaW91cyBjYW5kaWRhdGVzIC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdCc+cGFnZSAxMywg4oCcRmlndXJlIDcg YmVsb3cmbmJzcDtpbGx1c3RyYXRlc+KApuKAnSwgaW5zdGVhZCBvZiBiZWluZyZuYnNwO+KAnEZp Z3VyZSA34oCdLCBJIGd1ZXNzIHRoZSBkcmFmdCBtZWFucyZuYnNwO+KAnEZpZ3VyZSA54oCdLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0Jz5wYWdlIDIx LCZuYnNwO+KAnEZpZ3VyZSAxMCBiZWxvdyBkZXBpY3RzIGFuIFNQSS9TSeKAnS4gRmlndXJlIDEx IGlzIGFjdHVhbGx5IGZvbGxvd2luZyByaWdodCBiZWxvdy48L3NwYW4+PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0Jz5wYWdlIDIyLCZu YnNwO+KAnC4uLmFzIHBlciBmaWd1cmVzIDExIGFuZCAxMiBiZWxvdzwvc3Bhbj4uPHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo4LjVwdCc+4oCdIEkgZ3Vlc3MgdGhlIHNlbnRlbmNlIGlzIHRyeWluZyB0 byByZWZlciB0byBGaWd1cmUgMTIgYW5kIDEzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQnPnBhZ2UgMjIsJm5ic3A74oCc Li4uZXNzZW50aWFsbHkgYSBzZXJpZXMgb2Ygd2VpZ2h0ZWQgKGVxdWFsbHkgb3Igb3RoZXJ3aXNl KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPsKgwqAgb3ZlcmxheSBsaW5rcyB0 byBiZSB1c2VkIChmb3IgbG9hZCBkaXN0cmlidXRpb24sIHJlZHVuZGFuY3kgb3I8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiSGVs dmV0aWNhIiwic2Fucy1zZXJpZiInPsKgwqAgcG9saWN5KSwgc2VlIEZpZ3VyZSAxMy7CoCBUaGUg bWV0cmljIGRlcGljdGVkIGluIEZpZ3VyZSAxMyBpcyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PjxwcmUgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5z LXNlcmlmIic+wqDCoCBleGFtcGxlIHRvIGhlbHAgaWxsdXN0cmF0ZWQgd2VpZ2hpbmcgU0ZzLiA8 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdCc+4oCcPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIs InNhbnMtc2VyaWYiJz4mcXVvdDtGaWd1cmUgMTPigJ0gaW4gdGhlIHF1b3RlZCBzZW50ZW5jZXMg c2hvdWxkIGJlIEZpZ3VyZSAxNC48L3NwYW4+PG86cD48L286cD48L3ByZT48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+PGJyIGNsZWFyPWFsbCBzdHlsZT0ncGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzJz48L3NwYW4+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5wYWdlIDI1LCDigJxUaGUgZmlndXJlIGJlbG93 IGRlcGljdHMgdGhlIHBvbGljeSBhc3NvY2lhdGVkIHdpdGggdGhlIGdyYXBoIGluIEZpZ3VyZSAx NCBhYm92ZS7igJ0gRmlndXJlIDE1IGlzIGFjdHVhbGx5IHJlZmVycmVkIHRvIGFjY29yZGluZyB0 byB0aGUgY29udGV4dC48L3NwYW4+PG86cD48L286cD48L3ByZT48c3BhbiBzdHlsZT0nZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyc+PGJyIGNsZWFyPWFsbCBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzJz48L3NwYW4+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Ikhl bHZldGljYSIsInNhbnMtc2VyaWYiJz5wYWdlIDI3LCDigJxNZXRhZGF0YSBBdWdtZW50YXRpb246 IEluZm9ybWF0aW9uIG1heSBiZSBhZGRlZCB0byBOU0gncyBleGlzdGluZyBtZXRhZGF0YSwgYXMg ZGVwaWN0ZWQgaW4gRmlndXJlIDE4Ljwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0 Jz7igJ0gPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6Ikhl bHZldGljYSIsInNhbnMtc2VyaWYiJz5GaWd1cmUgMTksIGluc3RlYWQgb2YgMTggaXMgcmVmZXJy ZWQgdG8uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMnPjxiciBjbGVhcj1hbGwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+ PC9zcGFuPjxwcmUgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Ei LCJzYW5zLXNlcmlmIic+cGFnZSAyOCwg4oCcRmlndXJlIDE5IGlsbHVzdHJhdGVzIGFuIGV4YW1w bGUgb2YgdXBkYXRpbmcgbWV0YWRhdGEu4oCdIEZpZ3VyZSAyMCBpbGx1c3RyYXRlcyBtZXRhZGF0 YSB1cGRhdGUsIDE5IGlzIGZvciBtZXRhZGF0YSBhdWdtZW50YXRpb24uPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiSGVsdmV0 aWNhIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxiciBjbGVhcj1h bGwgc3R5bGU9J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PC9zcGFuPjxwcmUgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+cGFnZSAy OSwg4oCcRmlndXJlIDIwIGlsbHVzdHJhdGVzIGFuIGV4YW1wbGUgb2YgdGhpcyBiZWhhdmlvci48 L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdCc+4oCdPC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz4g U2hvdWxkIGJlIEZpZ3VyZSAyMSBpbnN0ZWFkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2Vy aWYiO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48YnIgY2xlYXI9YWxsIHN0eWxlPSdwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMnPjwvc3Bhbj48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDouNWlu O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkhlbHZl dGljYSIsInNhbnMtc2VyaWYiJz5XZW5xaW48L3NwYW4+PG86cD48L286cD48L3ByZT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlm Ijttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyc+PGJyIGNsZWFyPWFsbCBzdHlsZT0ncGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzJz48YnIgY2xlYXI9YWxsIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMnPjwvc3Bhbj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_A3233753A4B65F43BCA1B64DA99A9C23071EB2A6EAGSCMAMP19EXfi_-- From nobody Wed Apr 22 09:37:56 2015 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 DB5D21B3799 for ; Wed, 22 Apr 2015 09:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 PIXzQwIjcxM9 for ; Wed, 22 Apr 2015 09:37:52 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B243F1ACE9D for ; Wed, 22 Apr 2015 09:37:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,624,1422921600"; d="scan'208,217";a="158974838" X-IPAS-Result: A2CwBACFzTdV/+sKqMBbgkWBGVwFgxPEIR0BCYYEAhyBaAEBAQEBAYELhCABAQEBAyMKXAIBBgIRBAEBIQcDAgICMBQJCAIEARIIAYgvmmudApUBAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hD1DCgGCLTsSgTMFjxuGIYdLgz2CboZJhxuEFW8BgUOBAAEBAQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 22 Apr 2015 16:37:53 +0000 Received: from SEAEXCHMBX03.olympus.F5Net.com (192.168.15.225) by SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 22 Apr 2015 09:37:51 -0700 Received: from SEAEXCHMBX03.olympus.F5Net.com ([fe80::f95f:ea5d:773b:29b8]) by seaexchmbx03.olympus.F5Net.com ([fe80::f95f:ea5d:773b:29b8%13]) with mapi id 15.00.1044.021; Wed, 22 Apr 2015 09:37:51 -0700 From: Sunil Vallamkonda To: "Zarny, Myo" , 'Wenqin SHAO' , "'sfc@ietf.org'" Thread-Topic: [sfc] Shifted figure reference in draft-ietf-sfc-nsh-00 Thread-Index: AQHQfQrYMb9ugTQbT0Cj18CCiWKx9Z1ZrcSA//+K9tA= Date: Wed, 22 Apr 2015 16:37:50 +0000 Message-ID: References: <621121B9-3225-4397-8545-81398B5E21DA@telecom-paristech.fr> 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: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_a83752fc5e32453c95bcc90daf36a17aseaexchmbx03olympusF5Ne_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Shifted figure reference in draft-ietf-sfc-nsh-00 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, 22 Apr 2015 16:37:55 -0000 --_000_a83752fc5e32453c95bcc90daf36a17aseaexchmbx03olympusF5Ne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTXlvLA0KDQpBbHNvIHBsZWFzZSBmaW5kIGJlbG93IHBvc3NpYmxlIGNvcnJlY3Rpb25zIGFz IGFwcGxpY2FibGUgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXNmYy1uc2gt MDAudHh0DQoNClRoYW5rIHlvdSwNClN1bmlsLg0KDQotLQ0KRnJvbTogU3VuaWwgVmFsbGFta29u ZGENClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwNSwgMjAxNSAyOjI2IFBNDQpUbzogJ1BhdWwgUXVp bm4gKHBhdWxxKScNClN1YmplY3Q6IFJlOiBkcmFmdC1xdWlubi1zZmMtbnNoIGRvY3VtZW50DQoN CkhpLA0KDQpSZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4t c2ZjLW5zaC8NCg0KDQoxKSAgICAgIFBhZ2UgMjIsIFNlY3Rpb24gOS4xLCBsYXN0IHBhcmFncmFw aDoNCg0KICAgICAgICDigJxUaGUgbWV0cmljIGRlcGljdGVkIGluIEZpZ3VyZSAxMyBpcyBhbg0K ICAgICAgICBleGFtcGxlIHRvIGhlbHAgaWxsdXN0cmF0ZWQgd2VpZ2hpbmcgU0ZzLuKAnA0KU2hv dWxkIGFib3ZlIHJlYWQgYXMg4oCYRmlndXJlIDE04oCZID8NCg0KDQoyKSAgICAgIFBhZ2UgMjIs IGZpcnN0IHBhcmFncmFwaDoNCg0KICAgICAgICDigJxzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGNv bnRyb2wgcGxhbmUNCg0KICAgICAgICByZXNwb25zaWJpbGl0eSwgYXMgcGVyIGZpZ3VyZXMgMTEg YW5kIDEyIGJlbG93LuKAnQ0KDQogICAgICBTaG91bGQgdGhpcyBiZSDigJhmaWd1cmVzIDEyIGFu ZCAxMyBiZWxvd+KAmSA/DQoNCg0KMykgIFBhZ2UgMjEsIFNlY3Rpb24gOS4xIGxhc3Qgc2VudGVu Y2U6DQoNCuKAnCBGaWd1cmUgMTAgYmVsb3cgZGVwaWN0cyBhbiBTUEkvU0kgdG8gbmV0d29yayBv dmVybGF5IG1hcHBpbmcu4oCdDQoNCldvdWxkIHRoaXMgcmVhZCBhcyDigJhGaWd1cmUgMTHigJkg Pw0KDQpUaGFuayB5b3UsDQpTdW5pbC4NCg0KDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaYXJueSwgTXlvDQpTZW50OiBXZWRuZXNkYXks IEFwcmlsIDIyLCAyMDE1IDk6MjggQU0NClRvOiAnV2VucWluIFNIQU8nOyAnc2ZjQGlldGYub3Jn Jw0KU3ViamVjdDogUmU6IFtzZmNdIFNoaWZ0ZWQgZmlndXJlIHJlZmVyZW5jZSBpbiBkcmFmdC1p ZXRmLXNmYy1uc2gtMDANCg0KSGkgV2VpcWluLA0KDQpUaGFua3MgZm9yIHRoZSB0aG9yb3VnaCBy ZWFkaW5nLiBXZeKAmXJlIGF3YXJlIG9mIHNoaWZ0cyBpbiBmaWd1cmUgbnVtYmVycywgZXZlbiBp biB0aGUgbGF0ZXN0IGRyYWZ0ICgwNyksIGFuZCB3ZeKAmWxsIGhhdmUgaXQgZml4ZWQgaW4gdGhl IG5leHQgZHJhZnQuDQoNClJlZ2FyZHMsDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2VucWluIFNIQU8NClNlbnQ6IDIyIEFwcmlsIDIwMTUg MTA6NDEgQU0NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6 IFtzZmNdIFNoaWZ0ZWQgZmlndXJlIHJlZmVyZW5jZSBpbiBkcmFmdC1pZXRmLXNmYy1uc2gtMDAN Cg0KSGVsbG8gbGlzdCwNCg0KSSBmb3VuZCB0aGF0IHNvbWUgZmlndXJlIHJlZmVyZW5jZXMgaW4g ZHJhZnQtaWV0Zi1zZmMtbnNoLTAwIHdlcmUgc2hpZnRlZCBhbmQgcG9pbnRlZCBhY3R1YWxseSB0 byBhIG5laWdoYm91cmluZyBmaWd1cmUuDQpIZXJlIGJlbG93IGEgbGlzdCBvZiBzdXNwaWNpb3Vz IGNhbmRpZGF0ZXMgLg0KDQpwYWdlIDEzLCDigJxGaWd1cmUgNyBiZWxvdyBpbGx1c3RyYXRlc+KA puKAnSwgaW5zdGVhZCBvZiBiZWluZyDigJxGaWd1cmUgN+KAnSwgSSBndWVzcyB0aGUgZHJhZnQg bWVhbnMg4oCcRmlndXJlIDnigJ0uDQoNCnBhZ2UgMjEsIOKAnEZpZ3VyZSAxMCBiZWxvdyBkZXBp Y3RzIGFuIFNQSS9TSeKAnS4gRmlndXJlIDExIGlzIGFjdHVhbGx5IGZvbGxvd2luZyByaWdodCBi ZWxvdy4NCg0KcGFnZSAyMiwg4oCcLi4uYXMgcGVyIGZpZ3VyZXMgMTEgYW5kIDEyIGJlbG93LuKA nSBJIGd1ZXNzIHRoZSBzZW50ZW5jZSBpcyB0cnlpbmcgdG8gcmVmZXIgdG8gRmlndXJlIDEyIGFu ZCAxMy4NCg0KcGFnZSAyMiwg4oCcLi4uZXNzZW50aWFsbHkgYSBzZXJpZXMgb2Ygd2VpZ2h0ZWQg KGVxdWFsbHkgb3Igb3RoZXJ3aXNlKQ0KDQogICBvdmVybGF5IGxpbmtzIHRvIGJlIHVzZWQgKGZv ciBsb2FkIGRpc3RyaWJ1dGlvbiwgcmVkdW5kYW5jeSBvcg0KDQogICBwb2xpY3kpLCBzZWUgRmln dXJlIDEzLiAgVGhlIG1ldHJpYyBkZXBpY3RlZCBpbiBGaWd1cmUgMTMgaXMgYW4NCg0KICAgZXhh bXBsZSB0byBoZWxwIGlsbHVzdHJhdGVkIHdlaWdoaW5nIFNGcy4g4oCcDQoNCiJGaWd1cmUgMTPi gJ0gaW4gdGhlIHF1b3RlZCBzZW50ZW5jZXMgc2hvdWxkIGJlIEZpZ3VyZSAxNC4NCg0KDQpwYWdl IDI1LCDigJxUaGUgZmlndXJlIGJlbG93IGRlcGljdHMgdGhlIHBvbGljeSBhc3NvY2lhdGVkIHdp dGggdGhlIGdyYXBoIGluIEZpZ3VyZSAxNCBhYm92ZS7igJ0gRmlndXJlIDE1IGlzIGFjdHVhbGx5 IHJlZmVycmVkIHRvIGFjY29yZGluZyB0byB0aGUgY29udGV4dC4NCg0KDQpwYWdlIDI3LCDigJxN ZXRhZGF0YSBBdWdtZW50YXRpb246IEluZm9ybWF0aW9uIG1heSBiZSBhZGRlZCB0byBOU0gncyBl eGlzdGluZyBtZXRhZGF0YSwgYXMgZGVwaWN0ZWQgaW4gRmlndXJlIDE4LuKAnSBGaWd1cmUgMTks IGluc3RlYWQgb2YgMTggaXMgcmVmZXJyZWQgdG8uDQoNCg0KcGFnZSAyOCwg4oCcRmlndXJlIDE5 IGlsbHVzdHJhdGVzIGFuIGV4YW1wbGUgb2YgdXBkYXRpbmcgbWV0YWRhdGEu4oCdIEZpZ3VyZSAy MCBpbGx1c3RyYXRlcyBtZXRhZGF0YSB1cGRhdGUsIDE5IGlzIGZvciBtZXRhZGF0YSBhdWdtZW50 YXRpb24uDQoNCg0KcGFnZSAyOSwg4oCcRmlndXJlIDIwIGlsbHVzdHJhdGVzIGFuIGV4YW1wbGUg b2YgdGhpcyBiZWhhdmlvci7igJ0gU2hvdWxkIGJlIEZpZ3VyZSAyMSBpbnN0ZWFkLg0KDQoNClJl Z2FyZHMsDQoNCldlbnFpbg0KDQoNCg0K --_000_a83752fc5e32453c95bcc90daf36a17aseaexchmbx03olympusF5Ne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDoxNDE1MjAxODA2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTY0MzYyODE1NCA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIE15byw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyBw bGVhc2UgZmluZCBiZWxvdyBwb3NzaWJsZSBjb3JyZWN0aW9ucyBhcyBhcHBsaWNhYmxlIGluIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zZmMtbnNoLTAwLnR4dDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdW5pbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+LS08bzpwPjwvbzpwPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gU3VuaWwgVmFsbGFta29uZGEg PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAwNSwgMjAxNSAyOjI2IFBNPGJyPg0K PGI+VG86PC9iPiAnUGF1bCBRdWlubiAocGF1bHEpJzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog ZHJhZnQtcXVpbm4tc2ZjLW5zaCBkb2N1bWVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SZTogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cXVpbm4tc2ZjLW5zaC8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cXVpbm4tc2ZjLW5zaC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5QYWdlIDIyLCBTZWN0aW9uIDkuMSwg bGFzdCBwYXJhZ3JhcGg6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxUaGUgbWV0cmljIGRlcGljdGVkIGluIEZpZ3VyZSAx MyBpcyBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBleGFtcGxlIHRvIGhlbHAgaWxs dXN0cmF0ZWQgd2VpZ2hpbmcgU0ZzLjwvc3Bhbj7igJw8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPlNo b3VsZCBhYm92ZSByZWFkIGFzIOKAmEZpZ3VyZSAxNOKAmSA/PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5QYWdlIDIyLCBmaXJzdCBwYXJhZ3JhcGg6PG86cD48L286cD48 L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxz ZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGNvbnRyb2wgcGxhbmU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNpYmlsaXR5LCBh cyBwZXIgZmlndXJlcyAxMSBhbmQgMTIgYmVsb3cu4oCdPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNob3VsZCB0aGlzIGJlIOKAmGZpZ3VyZXMg MTIgYW5kIDEzIGJlbG934oCZID88bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlBhZ2UgMjEsIFNlY3Rpb24gOS4xIGxhc3Qgc2VudGVuY2U6DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnCBG aWd1cmUgMTAgYmVsb3cgZGVwaWN0cyBhbiBTUEkvU0kgdG8gbmV0d29yayBvdmVybGF5IG1hcHBp bmcu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5Xb3VsZCB0aGlzIHJlYWQgYXMg4oCYRmlndXJlIDEx4oCZID88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdW5pbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WmFybnksIE15bzxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDIyLCAyMDE1IDk6MjggQU08YnI+DQo8 Yj5Ubzo8L2I+ICdXZW5xaW4gU0hBTyc7ICdzZmNAaWV0Zi5vcmcnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbc2ZjXSBTaGlmdGVkIGZpZ3VyZSByZWZlcmVuY2UgaW4gZHJhZnQtaWV0Zi1zZmMt bnNoLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFdlaXFpbiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHRob3JvdWdoIHJlYWRpbmcu IFdl4oCZcmUgYXdhcmUgb2Ygc2hpZnRzIGluIGZpZ3VyZSBudW1iZXJzLCBldmVuIGluIHRoZSBs YXRlc3QgZHJhZnQgKDA3KSwgYW5kIHdl4oCZbGwgaGF2ZSBpdCBmaXhlZCBpbiB0aGUgbmV4dCBk cmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gc2ZjIFs8YSBocmVmPSJtYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPldlbnFpbiBTSEFPPGJyPg0KPGI+U2VudDo8L2I+IDIyIEFwcmlsIDIw MTUgMTA6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci PnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gU2hpZnRlZCBmaWd1 cmUgcmVmZXJlbmNlIGluIGRyYWZ0LWlldGYtc2ZjLW5zaC0wMDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdCI+SGVsbG8gbGlzdCw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdCI+SSBmb3VuZCB0aGF0IHNvbWUgZmlndXJlIHJlZmVyZW5j ZXMgaW4mbmJzcDtkcmFmdC1pZXRmLXNmYy1uc2gtMDAgd2VyZSBzaGlmdGVkIGFuZCBwb2ludGVk IGFjdHVhbGx5IHRvIGEmbmJzcDtuZWlnaGJvdXJpbmcgZmlndXJlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0Ij5IZXJlIGJlbG93IGEgbGlz dCBvZiBzdXNwaWNpb3VzIGNhbmRpZGF0ZXMgLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPnBhZ2UgMTMs IOKAnEZpZ3VyZSA3IGJlbG93Jm5ic3A7aWxsdXN0cmF0ZXPigKbigJ0sIGluc3RlYWQgb2YgYmVp bmcmbmJzcDvigJxGaWd1cmUgN+KAnSwgSSBndWVzcyB0aGUgZHJhZnQgbWVhbnMmbmJzcDvigJxG aWd1cmUgOeKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQiPnBhZ2UgMjEsJm5ic3A74oCcRmlndXJlIDEwIGJlbG93IGRlcGljdHMg YW4gU1BJL1NJ4oCdLiBGaWd1cmUgMTEgaXMgYWN0dWFsbHkgZm9sbG93aW5nIHJpZ2h0IGJlbG93 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0Ij5wYWdlIDIyLCZuYnNwO+KAnC4uLmFzIHBlciBm aWd1cmVzIDExIGFuZCAxMiBiZWxvdzwvc3Bhbj4uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dCI+4oCdIEkgZ3Vlc3MgdGhlIHNlbnRlbmNlIGlzIHRyeWluZyB0byByZWZlciB0byBGaWd1cmUg MTIgYW5kIDEzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0Ij5wYWdlIDIyLCZuYnNwO+KAnC4u LmVzc2VudGlhbGx5IGEgc2VyaWVzIG9mIHdlaWdodGVkIChlcXVhbGx5IG9yIG90aGVyd2lzZSk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDsgb3ZlcmxheSBsaW5rcyB0byBiZSB1c2VkIChmb3IgbG9hZCBkaXN0cmlidXRpb24sIHJlZHVu ZGFuY3kgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsgcG9saWN5KSwgc2VlIEZpZ3VyZSAxMy4mbmJzcDsgVGhlIG1ldHJpYyBkZXBpY3RlZCBp biBGaWd1cmUgMTMgaXMgYW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsgZXhhbXBsZSB0byBoZWxwIGlsbHVzdHJhdGVkIHdlaWdoaW5nIFNGcy4g PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPuKAnDwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O0ZpZ3VyZSAxM+KAnSBpbiB0aGUgcXVvdGVk IHNlbnRlbmNlcyBzaG91bGQgYmUgRmlndXJlIDE0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJh bGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPnBhZ2UgMjUsIOKAnFRoZSBmaWd1cmUgYmVsb3cgZGVwaWN0cyB0aGUgcG9saWN5IGFz c29jaWF0ZWQgd2l0aCB0aGUgZ3JhcGggaW4gRmlndXJlIDE0IGFib3ZlLuKAnSBGaWd1cmUgMTUg aXMgYWN0dWFsbHkgcmVmZXJyZWQgdG8gYWNjb3JkaW5nIHRvIHRoZSBjb250ZXh0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0K PC9zcGFuPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnBhZ2UgMjcsIOKAnE1ldGFkYXRhIEF1Z21lbnRhdGlv bjogSW5mb3JtYXRpb24gbWF5IGJlIGFkZGVkIHRvIE5TSCdzIGV4aXN0aW5nIG1ldGFkYXRhLCBh cyBkZXBpY3RlZCBpbiBGaWd1cmUgMTguPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41 cHQiPuKAnSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RmlndXJlIDE5LCBpbnN0ZWFkIG9mIDE4 IGlzIHJlZmVycmVkIHRvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnBhZ2UgMjgs IOKAnEZpZ3VyZSAxOSBpbGx1c3RyYXRlcyBhbiBleGFtcGxlIG9mIHVwZGF0aW5nIG1ldGFkYXRh LuKAnSBGaWd1cmUgMjAgaWxsdXN0cmF0ZXMgbWV0YWRhdGEgdXBkYXRlLCAxOSBpcyBmb3IgbWV0 YWRhdGEgYXVnbWVudGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnBhZ2Ug MjksIOKAnEZpZ3VyZSAyMCBpbGx1c3RyYXRlcyBhbiBleGFtcGxlIG9mIHRoaXMgYmVoYXZpb3Iu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPuKAnTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4gU2hvdWxkIGJlIEZpZ3VyZSAyMSBpbnN0ZWFkLjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNs ZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+V2VucWluPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+DQo8YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_a83752fc5e32453c95bcc90daf36a17aseaexchmbx03olympusF5Ne_-- From nobody Wed Apr 22 19:34:56 2015 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 0C6731B2DE8 for ; Wed, 22 Apr 2015 19:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fSBQMq4meAYz for ; Wed, 22 Apr 2015 19:34:53 -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 907791B2DE7 for ; Wed, 22 Apr 2015 19:34:49 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 8F17B22DFF80; Thu, 23 Apr 2015 02:34:46 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t3N2Yja3004156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 22:34:45 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 22:34:45 -0400 From: "Dolganow, Andrew (Andrew)" To: "Paul Quinn (paulq)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W0dCAgAJqwgCAAKgP9Q== Date: Thu, 23 Apr 2015 02:34:44 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 02:34:55 -0000 I agree. If we start specifying every single transport we will spent time t= hat otherwise can be spent on SFC-focused work.=20 There is no problem for other groups to specify how they want to encode SfC= in their transport type and bring this to SFC for review.=20 Andrew > On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) wrote: >=20 > Joel,=20 >=20 > I concur: we don't want to start picking transports here, it creates all = kinds of issues and is clearly out of scope. =20 >=20 > Rather, if there's a need for a transport to support NSH, then the work c= an occur in the associated working group. So, if there's a need for MPLS, = then a draft can be submitted to MPLS, similarly, NVO3, LISP, etc. can all = have NSH supporting drafts. This ensures both consistency and proper layer= ing within the scope of those protocols. >=20 > On the UDP front specifically, there's a clear move to a explicit protoco= l demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best place way to = have a proper protocol stack. =20 >=20 > Paul >=20 >=20 >> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern wrote= : >>=20 >> This seems a reasonable course, but defining how the NSH header is carri= ed on various transports seems not to be in my reading of the WG scope. >>=20 >> In particular, it seems a bit odd to define the mechanisms for some rand= omly selected subset of transports. Thus, while the omission is arguably a= bug in the charter, it is equally a bug to decide we will describe how to = handle some transports. And do we really want to have to produce documents= for each and every transport? >>=20 >> Yours, >> Joel >>=20 >>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>> Hello Chairs, >>>=20 >>> The hallmark of NSH is that it can be transported over many different >>> overlays. Towards that, we already have an ether-type that allows us to >>> carry NSH natively over Ethernet and non-natively over UDP =96 via >>> VXLAN-GPE. Given that UDP is the basic, simplest and most common overla= y >>> transports, we should enable transporting NSH natively over UDP, as wel= l. >>>=20 >>> Is there a process for requesting a UDP port# for NSH for working group >>> drafts ? Alternatively, in the spirit of saving the UDP name space, is >>> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>> similar purpose. This number is unused and I would be glad to transfer >>> this over to NSH. >>>=20 >>> Thanks, >>> Surendra. >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 22 22:01:08 2015 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 7A1721A1B8F for ; Wed, 22 Apr 2015 22:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fM4H5D5Z541c for ; Wed, 22 Apr 2015 22:01:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C5C1A1B98 for ; Wed, 22 Apr 2015 22:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24522; q=dns/txt; s=iport; t=1429765262; x=1430974862; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zXuzl5I1fJXOql3pxVHuqVyemEyhTMk14Ou9EKCVgug=; b=S4lKPOQPYuDQMNgVnp19uLzzkXEA6B0p6iYxpXF5HKXY1+ANH0Kt6y9o ZYECcNXlB7A7YIhHPP93v5xkOAZBRl+71FP/xeL585LbWFPjUo5j2jg9D nRmexxBb9Fl+9KAIb89eVt32xxMuab5vscIdHAAEAVG7JQi++TUvnQWfp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CFCAB0ezhV/5hdJa1bgkVHUlwFgxXEcwEJgjODUQIcgRxMAQEBAQEBgQuEIAEBAQQBAQEkQAcLDAQCAQgOAwQBASgFAgIlCxQJCAIEAQkEBRuIEA2aI5x6BpUdAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4RZEBcEBwaCXIFLBYY3iGqCIIoxgSKDP4IXjkQjg3NvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,628,1422921600"; d="scan'208,217";a="414033295" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 23 Apr 2015 05:01:01 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3N511b4027678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 05:01:01 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 00:01:00 -0500 From: "Surendra Kumar (smkumar)" To: Sumandra Majee , Dave Dolson , "Thomas D. Nadeau" , "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgA== Date: Thu, 23 Apr 2015 05:00:59 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> In-Reply-To: <1429684699272.32602@F5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.189.73] Content-Type: multipart/alternative; boundary="_000_D15DB47628ED7smkumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 05:01:07 -0000 --_000_D15DB47628ED7smkumarciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 U3VtYW5kcmEsDQoNClRoZXJlIGlzIG92ZXJoZWFkIGFzIHlvdSBwb2ludCBvdXQuIE5TSCBhbHJl YWR5IHByb3ZpZGVzIE1ELVR5cGUyIHRvIHJlZHVjZSB0aGUgTlNIIG92ZXJoZWFkLCB0aGUgYXJn dW1lbnQgaGFzIGFscmVhZHkgYmVlbiBtYWRlIGFuZCBhY2NlcHRlZC4NCg0KSXQgaXMgZmluZSB0 byBzdXBwb3J0IFNGQyBvdmVyIFZ4TEFOLiBIb3dldmVyLCB3aHkgbWFrZSB0aGF0IGEgcmVxdWly ZW1lbnQgdG8gZGVwbG95IFNGQyA/DQpXaHkgYXJlIHdlIHJlcXVpcmluZyBwcm92aXNpb25pbmcg b2YgVk5JcyB0byBkZXBsb3kgU0ZDID8NCldoeSBhcmUgd2UgcmVxdWlyaW5nIFZURVAgZnVuY3Rp b25hbGl0eSwgZXRjIHRvIGRlcGxveSBTRkMgPw0KV2h5IGFyZSB3ZSBhZGRpbmcgbW9yZSBjb3N0 IHRvIGRlcGxveSBTRkMgPw0KV2h5IGFyZSB3ZSBtYWtpbmcgaXQgY29tcGxleCB0byBkZXBsb3kg U0ZDIGluIGEgc2ltcGxlIEwzIG5ldHdvcmsgPw0KDQpBcyBmb3IgdGhlIHN0YWNraW5nL2xheWVy aW5nOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg TlNIICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t KyArLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBOU0ggICAg ICAgIHwgfCBWeExBTiogICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0rICstLS0t LS0tLS0tLS0rICstLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICB8IE5TSCAgICAgICAgfCB8 IEw0LW92ZXJsYXkgfCB8IEw0LW92ZXJsYXkgfA0KKy0tLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0t LSsgKy0tLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tLSsNCnwgTlNIICAgICAgICB8IHwgTDMtb3Zl cmxheSB8IHwgTDMgICAgICAgICB8IHwgTDMgICAgICAgICB8DQorLS0tLS0tLS0tLS0tKyArLS0t LS0tLS0tLS0tKyArLS0tLS0tLS0tLS0tKyArLS0tLS0tLS0tLS0tKw0KfCBMMi1vdmVybGF5IHwg fCBMMiAgICAgICAgIHwgfCBMMiAgICAgICAgIHwgfCBMMiAgICAgICAgIHwNCistLS0tLS0tLS0t LS0rICstLS0tLS0tLS0tLS0rICstLS0tLS0tLS0tLS0rICstLS0tLS0tLS0tLS0rDQogIEwyL0V0 eXBlICAgICAgICBHUkUvRXR5cGUgICAgICBVRFAvcG9ydCMgICAgIFZ4TEFOL3Byb3RvDQoNCldo YXQgaXMgbm90IHByb3BlciBhYm91dCBVRFAvcG9ydCMgc3RhY2tpbmcvbGF5ZXJpbmcgPw0KDQpT dXJlbmRyYS4NCg0KT24gNC8yMS8xNSwgMTE6MzggUE0sICJTdW1hbmRyYSBNYWplZSIgPFMuTWFq ZWVARjUuY29tPG1haWx0bzpTLk1hamVlQEY1LmNvbT4+IHdyb3RlOg0KDQpXaGF0IGlzIHRoZSBw YWNrZXQgZm9ybWF0IG9mIHN1Y2ggZW5jYXBzdWxhdGlvbiB3b3VsZCBsb29rIGxpa2U/DQoNCkwy IDo6ICBPVVRFUi1JUCA6OiBPVVRFUi1VRFAgWyBOU0ggLT4gSVAgLT5UQ1AgLT4gUGF5bG9hZF0g IC4uLiBpcyB0aGF0IHdoYXQgeW91IGFyZSBwcm9wb3Npbmc/DQoNCkkgYW0gbm90IHNhdmluZyBt dWNoIG9uIHByb2Nlc3Npbmcgb2YgdGhpcyBmb3JtYXQsIHNvIHdoYXQgaXMgdGhlIGVuZCBnb2Fs Pw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBzZmMg PHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJl aGFsZiBvZiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikgPHNta3VtYXJAY2lzY28uY29tPG1haWx0 bzpzbWt1bWFyQGNpc2NvLmNvbT4+DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwgMjAxNSAxMDow MCBQTQ0KVG86IERhdmUgRG9sc29uOyBUaG9tYXMgRC4gTmFkZWF1OyBKb2VsIE0uIEhhbHBlcm4N CkNjOiBUaG9tYXMgTmFydGVuOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTlNIIGFuZCBVRFAgVHJh bnNwb3J0DQoNClRoZXJlIGlzIGFscmVhZHkgYW4gaW5saW5lIGVuY2Fwc3VsYXRpb24gaW4gTlNI IGRyYWZ0IC0NCkxheWVyMihldGhlci10eXBlKS4gV2UgbmVlZCBvbmUgZm9yIEw0Lg0KDQpJZiBJ qfZtIGFuIG9wZXJhdG9yIGRlcGxveWluZyBhbiBORlYgc29sdXRpb24gb24gYW4gTDMgaW5mcmFz dHJ1Y3R1cmUsIGFzDQpvbmUgZXhhbXBsZSwgd2h5IGRvIEkgbmVlZCB0aGUgb3ZlcmhlYWQgb2Yg VnhMQU4qID8gSXQgaXMgYnJva2VuIG91dCB0aGUNCmRvb3IgaWYgd2UgZm9yY2UgYSBzcGVjaWZp YyB0cmFuc3BvcnQgdGhhdCBpcyBvbiB0b3Agb2YgVURQIHdoaWxlIG5vdA0Kc3VwcG9ydGluZyBV RFAgaXRzZWxmLg0KDQpTdXJlbmRyYS4NClBTOiBBcyBmb3IgdGhlIHVyZ2VuY3ksIFVEUCAjNjYz MyBpcyBhdmFpbGFibGUgaWYgV0cvSUVURiBoYXMgbm8NCm9iamVjdGlvbiwgYXMgSSBtZW50aW9u ZWQgZWFybGllci4NCg0KDQoNCk9uIDQvMjEvMTUsIDg6MDYgQU0sICJEYXZlIERvbHNvbiIgPGRk b2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOg0K DQpUbyBteSBtaW5kLCBUb20ncyBzdGF0ZW1lbnRzIGluZGljYXRlIGFuIHVyZ2VuY3kgdG8gc3Rh bmRhcmRpemUgc29vbmVyDQpyYXRoZXIgdGhhbiBsYXRlci4NCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBUaG9tYXMgRC4gTmFkZWF1DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwgMjAxNSA3 OjI4IEFNDQpUbzogSm9lbCBNLiBIYWxwZXJuDQpDYzogVGhvbWFzIE5hcnRlbjsgR3VpY2hhcmQg SmltOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIE5TSCBhbmQgVURQIFRyYW5zcG9ydA0KDQoNCiAg ICAgICBJZiBhbmQgd2hlbiB3ZSBkbyBnbyB3aXRoIGFuIGlubGluZSBlbmNhcCwgd2hpY2ggSSB0 aGluayB3ZSBzaG91bGQgQlRXLA0KbGV0IHVzIHBsZWFzZSBub3QgcmUtbGl2ZSB0aGUgImNoYWxs ZW5nZXMiIHdlIGVuZHVyZWQgd2l0aCBwc2V1ZG8td2lyZXMNCndoZXJlIHdlIGRlZmluZWQgdGhl bSBwaWVjZW1lYWwsIGFuZCBpbiBzb21lIGNhc2VzLCBxdWl0ZSBkaWZmZXJlbnRseQ0KZnJvbSB0 aGUgb3RoZXJzLiBQV3MgYXJlIGEgcmVsYXRlZCBhcmNoZXR5cGUgb2Ygd2hhdCB3ZSB3b3VsZCBi ZSBkb2luZw0KaGVyZSwgc28gd2Ugc2hvdWxkIGxlYXJuIGZyb20gdGhhdCBwYXN0IGV4cGVyaWVu Y2UuICBGb3IgdGhvc2Ugbm90IGx1Y2t5DQplbm91Z2ggdG8gYmUgcGFydCBvZiB0aGF0LCB0aGUg d2F5IHdlIHdlbnQgYWJvdXQgZGVzaWduaW5nIHRoZQ0KZW5jYXBzL2V0Yy4uLiBmb3IgUFdzIHJl c3VsdGVkIGluIGhhdmluZyB0byBnbyBiYWNrIGFuZCB0cnkgdG8gbWFrZQ0KdGhpbmdzIHJpZ2h0 IG9ubHkgdG8gYmUgdGh3YXJ0ZWQgYnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGFuZA0KZGVw bG95bWVudHMgYSBudW1iZXIgb2YgdGltZXMuIFdlIGFsc28gaGFkIHRvIHJldHJvZml0IE9BTSBp bnRvIHRoYXQNCmFmdGVyIHRoZSB0cmFpbiBsZWZ0IHRoZSBzdGF0aW9uIHdoaWNoIHdhcyBub3Qg ZWFzeSBhbmQgaXMgc3RpbGwgYmVpbmcNCm5vcm1hbGl6ZWQgbWFueSB5ZWFycyBsYXRlci4NCg0K ICAgICAgIC0tVG9tDQoNCg0KDQpPbiBBcHIgMjAsIDIwMTU6NzozOCBQTSwgYXQgNzozOCBQTSwg Sm9lbCBNLiBIYWxwZXJuDQo8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbT4+IHdyb3RlOg0KDQpUaGlzIHNlZW1zIGEgcmVhc29uYWJsZSBjb3Vyc2UsIGJ1dCBk ZWZpbmluZyBob3cgdGhlIE5TSCBoZWFkZXIgaXMNCmNhcnJpZWQgb24gdmFyaW91cyB0cmFuc3Bv cnRzIHNlZW1zIG5vdCB0byBiZSBpbiBteSByZWFkaW5nIG9mIHRoZSBXRw0Kc2NvcGUuDQoNCklu IHBhcnRpY3VsYXIsIGl0IHNlZW1zIGEgYml0IG9kZCB0byBkZWZpbmUgdGhlIG1lY2hhbmlzbXMg Zm9yIHNvbWUNCnJhbmRvbWx5IHNlbGVjdGVkIHN1YnNldCBvZiB0cmFuc3BvcnRzLiAgVGh1cywg d2hpbGUgdGhlIG9taXNzaW9uIGlzDQphcmd1YWJseSBhIGJ1ZyBpbiB0aGUgY2hhcnRlciwgaXQg aXMgZXF1YWxseSBhIGJ1ZyB0byBkZWNpZGUgd2Ugd2lsbA0KZGVzY3JpYmUgaG93IHRvIGhhbmRs ZSBzb21lIHRyYW5zcG9ydHMuICBBbmQgZG8gd2UgcmVhbGx5IHdhbnQgdG8gaGF2ZQ0KdG8gcHJv ZHVjZSBkb2N1bWVudHMgZm9yIGVhY2ggYW5kIGV2ZXJ5IHRyYW5zcG9ydD8NCg0KWW91cnMsDQpK b2VsDQoNCk9uIDQvMjAvMTUgNzowMiBQTSwgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIHdyb3Rl Og0KSGVsbG8gQ2hhaXJzLA0KDQpUaGUgaGFsbG1hcmsgb2YgTlNIIGlzIHRoYXQgaXQgY2FuIGJl IHRyYW5zcG9ydGVkIG92ZXIgbWFueSBkaWZmZXJlbnQNCm92ZXJsYXlzLiBUb3dhcmRzIHRoYXQs IHdlIGFscmVhZHkgaGF2ZSBhbiBldGhlci10eXBlIHRoYXQgYWxsb3dzIHVzIHRvDQpjYXJyeSBO U0ggbmF0aXZlbHkgb3ZlciBFdGhlcm5ldCBhbmQgbm9uLW5hdGl2ZWx5IG92ZXIgVURQIC0gdmlh DQpWWExBTi1HUEUuIEdpdmVuIHRoYXQgVURQIGlzIHRoZSBiYXNpYywgc2ltcGxlc3QgYW5kIG1v c3QgY29tbW9uDQpvdmVybGF5DQp0cmFuc3BvcnRzLCB3ZSBzaG91bGQgZW5hYmxlIHRyYW5zcG9y dGluZyBOU0ggbmF0aXZlbHkgb3ZlciBVRFAsIGFzDQp3ZWxsLg0KDQpJcyB0aGVyZSBhIHByb2Nl c3MgZm9yIHJlcXVlc3RpbmcgYSBVRFAgcG9ydCMgZm9yIE5TSCBmb3Igd29ya2luZyBncm91cA0K ZHJhZnRzID8gQWx0ZXJuYXRpdmVseSwgaW4gdGhlIHNwaXJpdCBvZiBzYXZpbmcgdGhlIFVEUCBu YW1lIHNwYWNlLCBpcw0KaXQgb2theSB0byB0cmFuc2ZlciBhIHByZS1hbGxvY2F0ZWQgYnV0IHVu LXVzZWQgVURQIHBvcnQjID8gQXMgcGFydCBvZg0KbXkgd29yaywgSSBoYWQgVURQIHBvcnQjIDY2 MzMgYWxsb2NhdGVkIGEgY291cGxlIG9mIHllYXJzIGFnbyBmb3IgYQ0Kc2ltaWxhciBwdXJwb3Nl LiBUaGlzIG51bWJlciBpcyB1bnVzZWQgYW5kIEkgd291bGQgYmUgZ2xhZCB0byB0cmFuc2Zlcg0K dGhpcyBvdmVyIHRvIE5TSC4NCg0KVGhhbmtzLA0KU3VyZW5kcmEuDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQoNCg== --_000_D15DB47628ED7smkumarciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <13F1AFE75C05B741A6E90B39283E7150@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5TdW1hbmRy YSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRw eDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5UaGVyZSBpcyBvdmVyaGVhZCBh cyB5b3UgcG9pbnQgb3V0LiBOU0ggYWxyZWFkeSBwcm92aWRlcyBNRC1UeXBlMiB0byByZWR1Y2Ug dGhlIE5TSCBvdmVyaGVhZCwgdGhlIGFyZ3VtZW50IGhhcyBhbHJlYWR5IGJlZW4gbWFkZSBhbmQg YWNjZXB0ZWQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNp emU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SXQgaXMgZmluZSB0 byBzdXBwb3J0IFNGQyBvdmVyIFZ4TEFOLiBIb3dldmVyLCB3aHkgbWFrZSB0aGF0IGEgcmVxdWly ZW1lbnQgdG8gZGVwbG95IFNGQyA/PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+V2h5IGFyZSB3ZSByZXF1aXJpbmcg cHJvdmlzaW9uaW5nIG9mIFZOSXMgdG8gZGVwbG95IFNGQyA/PC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+V2h5IGFy ZSB3ZSByZXF1aXJpbmcgVlRFUCBmdW5jdGlvbmFsaXR5LCBldGMgdG8gZGVwbG95IFNGQyA/PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyI+V2h5IGFyZSB3ZSBhZGRpbmcgbW9yZSBjb3N0IHRvIGRlcGxveSBTRkMgPzwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPldoeSBhcmUgd2UgbWFraW5nIGl0IGNvbXBsZXggdG8gZGVwbG95IFNGQyBp biBhIHNpbXBsZSBMMyBuZXR3b3JrID88L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRw eDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij5BcyBmb3IgdGhlIHN0YWNraW5nL2xheWVyaW5nOjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIiIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0tLS0tLS0mIzQz OzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgc3R5bGU9ImZvbnQtc2l6 ZTogMTJweDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 IE5TSCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJDb3VyaWVyIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0mIzQzOyAm IzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3Vy aWVyIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCBOU0ggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCB8 IFZ4TEFOKiAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNv dXJpZXIiIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0tLS0tLS0mIzQzOyAmIzQz Oy0tLS0tLS0tLS0tLSYjNDM7ICYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBOU0ggJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCB8IEw0LW92ZXJsYXkgfCB8IEw0LW92ZXJsYXkgfDwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgc3R5bGU9ImZvbnQtc2l6ZTog MTJweDsiPiYjNDM7LS0tLS0tLS0tLS0tJiM0MzsgJiM0MzstLS0tLS0tLS0tLS0mIzQzOyAmIzQz Oy0tLS0tLS0tLS0tLSYjNDM7ICYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij58IE5TSCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IHwgTDMtb3ZlcmxheSB8IHwgTDMgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgfCBMMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgc3R5bGU9ImZvbnQtc2l6ZTog MTJweDsiPiYjNDM7LS0tLS0tLS0tLS0tJiM0MzsgJiM0MzstLS0tLS0tLS0tLS0mIzQzOyAmIzQz Oy0tLS0tLS0tLS0tLSYjNDM7ICYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIiIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij58IEwyLW92 ZXJsYXkgfCB8IEwyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IHwgTDIgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHwgfCBMMiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZu YnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciIgc3R5bGU9ImZvbnQt c2l6ZTogMTJweDsiPiYjNDM7LS0tLS0tLS0tLS0tJiM0MzsgJiM0MzstLS0tLS0tLS0tLS0mIzQz OyAmIzQzOy0tLS0tLS0tLS0tLSYjNDM7ICYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L2ZvbnQ+PC9k aXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBzdHlsZT0iZm9udC1z aXplOiAxMnB4OyI+Jm5ic3A7IEwyL0V0eXBlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0dS RS9FdHlwZSAmbmJzcDsgJm5ic3A7ICZuYnNwO1VEUC9wb3J0IyAmbmJzcDsgJm5ic3A7IFZ4TEFO L3Byb3RvPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij5XaGF0IGlzIG5vdCBwcm9wZXIgYWJvdXQgVURQL3BvcnQjIHN0YWNraW5nL2xheWVy aW5nID88L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5TdXJlbmRyYS48L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTRweDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5PbiA0LzIxLzE1LCAxMTozOCBQTSwgJnF1b3Q7 U3VtYW5kcmEgTWFqZWUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpTLk1hamVlQEY1LmNvbSI+ Uy5NYWplZUBGNS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHls ZT0iZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYm9y ZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVw eDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1h cmdpbjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2PldoYXQgaXMgdGhlIHBhY2tldCBmb3JtYXQg b2Ygc3VjaCBlbmNhcHN1bGF0aW9uIHdvdWxkIGxvb2sgbGlrZT88L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkwyIDo6Jm5ic3A7Jm5ic3A7T1VURVItSVAgOjogT1VURVItVURQIFsgTlNI IC0mZ3Q7IElQIC0mZ3Q7VENQIC0mZ3Q7IFBheWxvYWRdJm5ic3A7Jm5ic3A7Li4uIGlzIHRoYXQg d2hhdCB5b3UgYXJlIHByb3Bvc2luZz8NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SSBhbSBub3Qgc2F2aW5nIG11Y2ggb24gcHJvY2Vzc2luZyBvZiB0aGlzIGZvcm1hdCwgc28gd2hh dCBpcyB0aGUgZW5kIGdvYWw/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PkZyb206IHNmYyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikgJmx0Ozxh IGhyZWY9Im1haWx0bzpzbWt1bWFyQGNpc2NvLmNvbSI+c21rdW1hckBjaXNjby5jb208L2E+Jmd0 OzwvZGl2Pg0KPGRpdj5TZW50OiBUdWVzZGF5LCBBcHJpbCAyMSwgMjAxNSAxMDowMCBQTTwvZGl2 Pg0KPGRpdj5UbzogRGF2ZSBEb2xzb247IFRob21hcyBELiBOYWRlYXU7IEpvZWwgTS4gSGFscGVy bjwvZGl2Pg0KPGRpdj5DYzogVGhvbWFzIE5hcnRlbjsgSmltIEd1aWNoYXJkIChqZ3VpY2hhcik7 IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxk aXY+U3ViamVjdDogUmU6IFtzZmNdIE5TSCBhbmQgVURQIFRyYW5zcG9ydDwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgaXMgYWxyZWFkeSBhbiBpbmxpbmUgZW5jYXBzdWxhdGlv biBpbiBOU0ggZHJhZnQgLTwvZGl2Pg0KPGRpdj5MYXllcjIoZXRoZXItdHlwZSkuIFdlIG5lZWQg b25lIGZvciBMNC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklmIEmp9m0gYW4gb3Bl cmF0b3IgZGVwbG95aW5nIGFuIE5GViBzb2x1dGlvbiBvbiBhbiBMMyBpbmZyYXN0cnVjdHVyZSwg YXM8L2Rpdj4NCjxkaXY+b25lIGV4YW1wbGUsIHdoeSBkbyBJIG5lZWQgdGhlIG92ZXJoZWFkIG9m IFZ4TEFOKiA/IEl0IGlzIGJyb2tlbiBvdXQgdGhlPC9kaXY+DQo8ZGl2PmRvb3IgaWYgd2UgZm9y Y2UgYSBzcGVjaWZpYyB0cmFuc3BvcnQgdGhhdCBpcyBvbiB0b3Agb2YgVURQIHdoaWxlIG5vdDwv ZGl2Pg0KPGRpdj5zdXBwb3J0aW5nIFVEUCBpdHNlbGYuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5TdXJlbmRyYS48L2Rpdj4NCjxkaXY+UFM6IEFzIGZvciB0aGUgdXJnZW5jeSwgVURQ ICM2NjMzIGlzIGF2YWlsYWJsZSBpZiBXRy9JRVRGIGhhcyBubzwvZGl2Pg0KPGRpdj5vYmplY3Rp b24sIGFzIEkgbWVudGlvbmVkIGVhcmxpZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9uIDQvMjEvMTUsIDg6MDYg QU0sICZxdW90O0RhdmUgRG9sc29uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBz YW5kdmluZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5H OjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2PlRvIG15IG1pbmQsIFRvbSdzIHN0YXRl bWVudHMgaW5kaWNhdGUgYW4gdXJnZW5jeSB0byBzdGFuZGFyZGl6ZSBzb29uZXI8L2Rpdj4NCjxk aXY+cmF0aGVyIHRoYW4gbGF0ZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+RnJv bTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUaG9tYXMgRC4gTmFkZWF1PC9kaXY+ DQo8ZGl2PlNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIxLCAyMDE1IDc6MjggQU08L2Rpdj4NCjxkaXY+ VG86IEpvZWwgTS4gSGFscGVybjwvZGl2Pg0KPGRpdj5DYzogVGhvbWFzIE5hcnRlbjsgR3VpY2hh cmQgSmltOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj5TdWJqZWN0OiBSZTogW3NmY10g TlNIIGFuZCBVRFAgVHJhbnNwb3J0PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIGFu ZCB3aGVuIHdlIGRvIGdvIHdpdGggYW4gaW5saW5lIGVuY2FwLCB3aGljaCBJIHRoaW5rIHdlIHNo b3VsZCBCVFcsPC9kaXY+DQo8ZGl2PmxldCB1cyBwbGVhc2Ugbm90IHJlLWxpdmUgdGhlICZxdW90 O2NoYWxsZW5nZXMmcXVvdDsgd2UgZW5kdXJlZCB3aXRoIHBzZXVkby13aXJlczwvZGl2Pg0KPGRp dj53aGVyZSB3ZSBkZWZpbmVkIHRoZW0gcGllY2VtZWFsLCBhbmQgaW4gc29tZSBjYXNlcywgcXVp dGUgZGlmZmVyZW50bHk8L2Rpdj4NCjxkaXY+ZnJvbSB0aGUgb3RoZXJzLiBQV3MgYXJlIGEgcmVs YXRlZCBhcmNoZXR5cGUgb2Ygd2hhdCB3ZSB3b3VsZCBiZSBkb2luZzwvZGl2Pg0KPGRpdj5oZXJl LCBzbyB3ZSBzaG91bGQgbGVhcm4gZnJvbSB0aGF0IHBhc3QgZXhwZXJpZW5jZS4mbmJzcDsmbmJz cDtGb3IgdGhvc2Ugbm90IGx1Y2t5PC9kaXY+DQo8ZGl2PmVub3VnaCB0byBiZSBwYXJ0IG9mIHRo YXQsIHRoZSB3YXkgd2Ugd2VudCBhYm91dCBkZXNpZ25pbmcgdGhlPC9kaXY+DQo8ZGl2PmVuY2Fw cy9ldGMuLi4gZm9yIFBXcyByZXN1bHRlZCBpbiBoYXZpbmcgdG8gZ28gYmFjayBhbmQgdHJ5IHRv IG1ha2U8L2Rpdj4NCjxkaXY+dGhpbmdzIHJpZ2h0IG9ubHkgdG8gYmUgdGh3YXJ0ZWQgYnkgZXhp c3RpbmcgaW1wbGVtZW50YXRpb25zIGFuZDwvZGl2Pg0KPGRpdj5kZXBsb3ltZW50cyBhIG51bWJl ciBvZiB0aW1lcy4gV2UgYWxzbyBoYWQgdG8gcmV0cm9maXQgT0FNIGludG8gdGhhdDwvZGl2Pg0K PGRpdj5hZnRlciB0aGUgdHJhaW4gbGVmdCB0aGUgc3RhdGlvbiB3aGljaCB3YXMgbm90IGVhc3kg YW5kIGlzIHN0aWxsIGJlaW5nPC9kaXY+DQo8ZGl2Pm5vcm1hbGl6ZWQgbWFueSB5ZWFycyBsYXRl ci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLVRvbTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FU VFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlk OyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pk9uIEFwciAyMCwgMjAx NTo3OjM4IFBNLCBhdCA3OjM4IFBNLCBKb2VsIE0uIEhhbHBlcm48L2Rpdj4NCjxkaXY+Jmx0Ozxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIj5qbWhAam9lbGhhbHBlcm4uY29tPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIHNlZW1zIGEg cmVhc29uYWJsZSBjb3Vyc2UsIGJ1dCBkZWZpbmluZyBob3cgdGhlIE5TSCBoZWFkZXIgaXM8L2Rp dj4NCjxkaXY+Y2FycmllZCBvbiB2YXJpb3VzIHRyYW5zcG9ydHMgc2VlbXMgbm90IHRvIGJlIGlu IG15IHJlYWRpbmcgb2YgdGhlIFdHPC9kaXY+DQo8ZGl2PnNjb3BlLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SW4gcGFydGljdWxhciwgaXQgc2VlbXMgYSBiaXQgb2RkIHRvIGRlZmlu ZSB0aGUgbWVjaGFuaXNtcyBmb3Igc29tZTwvZGl2Pg0KPGRpdj5yYW5kb21seSBzZWxlY3RlZCBz dWJzZXQgb2YgdHJhbnNwb3J0cy4mbmJzcDsmbmJzcDtUaHVzLCB3aGlsZSB0aGUgb21pc3Npb24g aXM8L2Rpdj4NCjxkaXY+YXJndWFibHkgYSBidWcgaW4gdGhlIGNoYXJ0ZXIsIGl0IGlzIGVxdWFs bHkgYSBidWcgdG8gZGVjaWRlIHdlIHdpbGw8L2Rpdj4NCjxkaXY+ZGVzY3JpYmUgaG93IHRvIGhh bmRsZSBzb21lIHRyYW5zcG9ydHMuJm5ic3A7Jm5ic3A7QW5kIGRvIHdlIHJlYWxseSB3YW50IHRv IGhhdmU8L2Rpdj4NCjxkaXY+dG8gcHJvZHVjZSBkb2N1bWVudHMgZm9yIGVhY2ggYW5kIGV2ZXJ5 IHRyYW5zcG9ydD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdXJzLDwvZGl2Pg0K PGRpdj5Kb2VsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PbiA0LzIwLzE1IDc6MDIg UE0sIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSB3cm90ZTo8L2Rpdj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp dj5IZWxsbyBDaGFpcnMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgaGFsbG1h cmsgb2YgTlNIIGlzIHRoYXQgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgbWFueSBkaWZmZXJl bnQ8L2Rpdj4NCjxkaXY+b3ZlcmxheXMuIFRvd2FyZHMgdGhhdCwgd2UgYWxyZWFkeSBoYXZlIGFu IGV0aGVyLXR5cGUgdGhhdCBhbGxvd3MgdXMgdG88L2Rpdj4NCjxkaXY+Y2FycnkgTlNIIG5hdGl2 ZWx5IG92ZXIgRXRoZXJuZXQgYW5kIG5vbi1uYXRpdmVseSBvdmVyIFVEUCAtIHZpYTwvZGl2Pg0K PGRpdj5WWExBTi1HUEUuIEdpdmVuIHRoYXQgVURQIGlzIHRoZSBiYXNpYywgc2ltcGxlc3QgYW5k IG1vc3QgY29tbW9uPC9kaXY+DQo8ZGl2Pm92ZXJsYXk8L2Rpdj4NCjxkaXY+dHJhbnNwb3J0cywg d2Ugc2hvdWxkIGVuYWJsZSB0cmFuc3BvcnRpbmcgTlNIIG5hdGl2ZWx5IG92ZXIgVURQLCBhczwv ZGl2Pg0KPGRpdj53ZWxsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SXMgdGhlcmUg YSBwcm9jZXNzIGZvciByZXF1ZXN0aW5nIGEgVURQIHBvcnQjIGZvciBOU0ggZm9yIHdvcmtpbmcg Z3JvdXA8L2Rpdj4NCjxkaXY+ZHJhZnRzID8gQWx0ZXJuYXRpdmVseSwgaW4gdGhlIHNwaXJpdCBv ZiBzYXZpbmcgdGhlIFVEUCBuYW1lIHNwYWNlLCBpczwvZGl2Pg0KPGRpdj5pdCBva2F5IHRvIHRy YW5zZmVyIGEgcHJlLWFsbG9jYXRlZCBidXQgdW4tdXNlZCBVRFAgcG9ydCMgPyBBcyBwYXJ0IG9m PC9kaXY+DQo8ZGl2Pm15IHdvcmssIEkgaGFkIFVEUCBwb3J0IyA2NjMzIGFsbG9jYXRlZCBhIGNv dXBsZSBvZiB5ZWFycyBhZ28gZm9yIGE8L2Rpdj4NCjxkaXY+c2ltaWxhciBwdXJwb3NlLiBUaGlz IG51bWJlciBpcyB1bnVzZWQgYW5kIEkgd291bGQgYmUgZ2xhZCB0byB0cmFuc2ZlcjwvZGl2Pg0K PGRpdj50aGlzIG92ZXIgdG8gTlNILjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhh bmtzLDwvZGl2Pg0KPGRpdj5TdXJlbmRyYS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvZGl2Pg0KPGRpdj5zZmMgbWFpbGluZyBsaXN0PC9kaXY+DQo8ZGl2PjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PnNmYyBtYWls aW5nIGxpc3Q8L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll dGYub3JnPC9hPjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmM8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L2Rpdj4NCjxkaXY+c2ZjIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj48YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9kaXY+DQo8ZGl2PnNmYyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D15DB47628ED7smkumarciscocom_-- From nobody Wed Apr 22 22:13:42 2015 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 87D201A6F3B for ; Wed, 22 Apr 2015 22:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 3kIgZAUrzM4t for ; Wed, 22 Apr 2015 22:13:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490141A1BC3 for ; Wed, 22 Apr 2015 22:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2786; q=dns/txt; s=iport; t=1429766017; x=1430975617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tcCW5B6cXEvT7IP5Uy6JqXWWWDCL8t+mYy0VUZCBulk=; b=HnHlJXFtym9hKNX5/kCEE28k2frjo7fA2UvvgdDtE/zj9Dm/VvsiWkfu J5qDQ9Wh5qDj82HvFd/DfiTf58EnGzs5KYDOkQXek/0IrlSd+qoAfs98U 0C0nkHdD8lYkMDBwGU3hwtd81MHSW+hRzDxpYjgFWVjy746dg7MHZCuYx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeBQC6fjhV/5pdJa1bgwxSXAXICgqGBAKBOEwBAQEBAQGBC4QhAQEEAQEBZAcLEAIBCBguJwslAgQBCQQFiCsNzEQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs3hQQHhC0Fix2GJIoxhniORCODc2+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,629,1422921600"; d="scan'208";a="414084303" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 23 Apr 2015 05:13:36 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3N5DadN029710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 05:13:36 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 00:13:36 -0500 From: "Surendra Kumar (smkumar)" To: "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAKIIgA== Date: Thu, 23 Apr 2015 05:13:35 +0000 Message-ID: References: <55358DFD.2040804@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.4.8.150116 x-originating-ip: [10.24.189.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 05:13:41 -0000 On 4/22/15, 5:33 AM, "Paul Quinn (paulq)" wrote: >Joel,=20 > >I concur: we don't want to start picking transports here, it creates all >kinds of issues and is clearly out of scope. > >Rather, if there's a need for a transport to support NSH, then the work >can occur in the associated working group. So, if there's a need for >MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, etc. >can all have NSH supporting drafts. This ensures both consistency and >proper layering within the scope of those protocols. > >On the UDP front specifically, there's a clear move to a explicit >protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best >place way to have a proper protocol stack. NSH provides demux too. So, GUE and GENEVE are equivalent to NSH signaled with UDP. I=B9m not sure how using UDP port# makes the stack improper. Surendra. > =20 > >Paul > > >> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern >>wrote: >>=20 >> This seems a reasonable course, but defining how the NSH header is >>carried on various transports seems not to be in my reading of the WG >>scope. >>=20 >> In particular, it seems a bit odd to define the mechanisms for some >>randomly selected subset of transports. Thus, while the omission is >>arguably a bug in the charter, it is equally a bug to decide we will >>describe how to handle some transports. And do we really want to have >>to produce documents for each and every transport? >>=20 >> Yours, >> Joel >>=20 >> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>> Hello Chairs, >>>=20 >>> The hallmark of NSH is that it can be transported over many different >>> overlays. Towards that, we already have an ether-type that allows us to >>> carry NSH natively over Ethernet and non-natively over UDP =AD via >>> VXLAN-GPE. Given that UDP is the basic, simplest and most common >>>overlay >>> transports, we should enable transporting NSH natively over UDP, as >>>well. >>>=20 >>> Is there a process for requesting a UDP port# for NSH for working group >>> drafts ? Alternatively, in the spirit of saving the UDP name space, is >>> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>> similar purpose. This number is unused and I would be glad to transfer >>> this over to NSH. >>>=20 >>> Thanks, >>> Surendra. >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Apr 23 04:10:06 2015 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 64BA31B2D20 for ; Thu, 23 Apr 2015 04:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 wvZ9VI2qUGyx for ; Thu, 23 Apr 2015 04:10:04 -0700 (PDT) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id DAF1A1B2D1B for ; Thu, 23 Apr 2015 04:09:52 -0700 (PDT) Received: from [192.168.1.108] (unknown [50.255.148.181]) by lucidvision.com (Postfix) with ESMTP id DC5A2333253D; Thu, 23 Apr 2015 07:09:51 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 23 Apr 2015 07:09:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55358DFD.2040804@joelhalpern.com> To: "Dolganow, Andrew (Andrew)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Thomas Narten , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" , Guichard Jim , "Paul \(paulq\) Quinn" , "Joel M. Halpern" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 11:10:05 -0000 In PWE3 we eventually did specify each one, we just did it a = little here and a little there. We had a different PW header and = transport encap depending on the transport for quite a while, which = proved to be rather interesting if you were implementing any of it. = Worse if you were an operator trying to deploy multiple types. = Eventually (think years later) we settled on a common header format, but = there were already some pretty good sized deployments out there which = resisted unifying the header. The lesson: try to do it right from the = beginning thinking that there will be multiple transport types. So = while SFC might not define the transport encaps, we should define a = common header format that works with at least a few = representative/obvious ones to start, and have a plan to define others = in collaboration with SFC using the same mechanism. Also consider OAM = now, not halfway down the road. That doesn=92t mean we need to = re-define existing mechanisms, but just make sure that if existing ones = exist (which I think they do BTW), that they are incorporated into the = unified plan somewhere. =97Tom > On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) = wrote: >=20 > I agree. If we start specifying every single transport we will spent = time that otherwise can be spent on SFC-focused work.=20 >=20 > There is no problem for other groups to specify how they want to = encode SfC in their transport type and bring this to SFC for review.=20 >=20 > Andrew >=20 >=20 >> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) = wrote: >>=20 >> Joel,=20 >>=20 >> I concur: we don't want to start picking transports here, it creates = all kinds of issues and is clearly out of scope. =20 >>=20 >> Rather, if there's a need for a transport to support NSH, then the = work can occur in the associated working group. So, if there's a need = for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, = etc. can all have NSH supporting drafts. This ensures both consistency = and proper layering within the scope of those protocols. >>=20 >> On the UDP front specifically, there's a clear move to a explicit = protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best = place way to have a proper protocol stack. =20 >>=20 >> Paul >>=20 >>=20 >>> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern = wrote: >>>=20 >>> This seems a reasonable course, but defining how the NSH header is = carried on various transports seems not to be in my reading of the WG = scope. >>>=20 >>> In particular, it seems a bit odd to define the mechanisms for some = randomly selected subset of transports. Thus, while the omission is = arguably a bug in the charter, it is equally a bug to decide we will = describe how to handle some transports. And do we really want to have = to produce documents for each and every transport? >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>>> Hello Chairs, >>>>=20 >>>> The hallmark of NSH is that it can be transported over many = different >>>> overlays. Towards that, we already have an ether-type that allows = us to >>>> carry NSH natively over Ethernet and non-natively over UDP =96 via >>>> VXLAN-GPE. Given that UDP is the basic, simplest and most common = overlay >>>> transports, we should enable transporting NSH natively over UDP, as = well. >>>>=20 >>>> Is there a process for requesting a UDP port# for NSH for working = group >>>> drafts ? Alternatively, in the spirit of saving the UDP name space, = is >>>> it okay to transfer a pre-allocated but un-used UDP port# ? As part = of >>>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>>> similar purpose. This number is unused and I would be glad to = transfer >>>> this over to NSH. >>>>=20 >>>> Thanks, >>>> Surendra. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 From nobody Thu Apr 23 05:55:12 2015 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 CFEBC1A9308 for ; Thu, 23 Apr 2015 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VVjTaVNEUhIF for ; Thu, 23 Apr 2015 05:55:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEBF1A92AF for ; Thu, 23 Apr 2015 05:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6102; q=dns/txt; s=iport; t=1429793709; x=1431003309; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fKfWsafpixx2BiND6rjfHIwTQ5O+4A3oR9VwzjpDQyc=; b=aCXZssXSNsN5DKtwr3xC7341MGB8a+H6lfyVcnrnKUtbmUZxK1or30DS 0+Ni28g/2KjqB6T59bLgmtsEBUE9ZfVynlslw4uAb2SfP3y8/BFc6eIOj Cji+x29IyAqZmL+OxJmlKJ5hFdrw4hpcfGfkw/gD5hoYEa8N7nK7+/j0Z M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBQAI6zhV/5BdJa1bgwpSXAXFN4I0CoYEAoE5TAEBAQEBAYELhCABAQEDAQEBAWQHCwULAgEIDgouJwslAgQKBAUOiBUIDcxfAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4UEB4MXgRYFkUGBcoE3hwiGeI5EI4FkIhyBUW+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,631,1422921600"; d="asc'?scan'208";a="414239417" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 23 Apr 2015 12:55:08 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t3NCt8ML003007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 12:55:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 07:55:08 -0500 From: "Carlos Pignataro (cpignata)" To: Tom Nadeau Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAdawA= Date: Thu, 23 Apr 2015 12:55:47 +0000 Message-ID: <4F8D4D97-CFDF-4EA1-9A32-54F807741E31@cisco.com> References: <55358DFD.2040804@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.235.130] Content-Type: multipart/signed; boundary="Apple-Mail=_CD9BBD43-C754-4B18-8E5F-63D47A3A6327"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Dolganow, Andrew \(Andrew\)" , "Paul Quinn \(paulq\)" , "Joel M. Halpern" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 12:55:12 -0000 --Apple-Mail=_CD9BBD43-C754-4B18-8E5F-63D47A3A6327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree Tom that there are certainly lessons from the PWE3 work. In that case, however, the actual =93PWE3 header=94 (i.e., the Control = Word) was specified piecemeal, for each protocol transported *over* the = PW. For SFC, in contrast, the =93SFC Header=94 is common and defined in = a single place, the NSH, for whatever is transported *over* the NSH. I = think this SFC WG decision is wise and might even show we have learned = from the PWE3 experience. Thanks, =97 Carlos. > On Apr 23, 2015, at 7:09 AM, Thomas D. Nadeau = wrote: >=20 >=20 > In PWE3 we eventually did specify each one, we just did it a = little here and a little there. We had a different PW header and = transport encap depending on the transport for quite a while, which = proved to be rather interesting if you were implementing any of it. = Worse if you were an operator trying to deploy multiple types. = Eventually (think years later) we settled on a common header format, but = there were already some pretty good sized deployments out there which = resisted unifying the header. The lesson: try to do it right from the = beginning thinking that there will be multiple transport types. So = while SFC might not define the transport encaps, we should define a = common header format that works with at least a few = representative/obvious ones to start, and have a plan to define others = in collaboration with SFC using the same mechanism. Also consider OAM = now, not halfway down the road. That doesn=92t mean we need to = re-define existing mechanisms, but just make sure that if existing ones = exist (which I think they do BTW), that they are incorporated into the = unified plan somewhere. >=20 > =97Tom >=20 >=20 >> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) = wrote: >>=20 >> I agree. If we start specifying every single transport we will spent = time that otherwise can be spent on SFC-focused work. >>=20 >> There is no problem for other groups to specify how they want to = encode SfC in their transport type and bring this to SFC for review. >>=20 >> Andrew >>=20 >>=20 >>> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) = wrote: >>>=20 >>> Joel, >>>=20 >>> I concur: we don't want to start picking transports here, it creates = all kinds of issues and is clearly out of scope. >>>=20 >>> Rather, if there's a need for a transport to support NSH, then the = work can occur in the associated working group. So, if there's a need = for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, = etc. can all have NSH supporting drafts. This ensures both consistency = and proper layering within the scope of those protocols. >>>=20 >>> On the UDP front specifically, there's a clear move to a explicit = protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best = place way to have a proper protocol stack. >>>=20 >>> Paul >>>=20 >>>=20 >>>> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern = wrote: >>>>=20 >>>> This seems a reasonable course, but defining how the NSH header is = carried on various transports seems not to be in my reading of the WG = scope. >>>>=20 >>>> In particular, it seems a bit odd to define the mechanisms for some = randomly selected subset of transports. Thus, while the omission is = arguably a bug in the charter, it is equally a bug to decide we will = describe how to handle some transports. And do we really want to have = to produce documents for each and every transport? >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>>>> Hello Chairs, >>>>>=20 >>>>> The hallmark of NSH is that it can be transported over many = different >>>>> overlays. Towards that, we already have an ether-type that allows = us to >>>>> carry NSH natively over Ethernet and non-natively over UDP =96 via >>>>> VXLAN-GPE. Given that UDP is the basic, simplest and most common = overlay >>>>> transports, we should enable transporting NSH natively over UDP, = as well. >>>>>=20 >>>>> Is there a process for requesting a UDP port# for NSH for working = group >>>>> drafts ? Alternatively, in the spirit of saving the UDP name = space, is >>>>> it okay to transfer a pre-allocated but un-used UDP port# ? As = part of >>>>> my work, I had UDP port# 6633 allocated a couple of years ago for = a >>>>> similar purpose. This number is unused and I would be glad to = transfer >>>>> this over to NSH. >>>>>=20 >>>>> Thanks, >>>>> Surendra. >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_CD9BBD43-C754-4B18-8E5F-63D47A3A6327 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 iEYEARECAAYFAlU466wACgkQtfDPGTp3USzaQACg2s721J1d/ZO3NMBSofKCixJi lWYAoM4GaFLqRQStJW9lioLb2I3s4YCP =38Vl -----END PGP SIGNATURE----- --Apple-Mail=_CD9BBD43-C754-4B18-8E5F-63D47A3A6327-- From nobody Thu Apr 23 06:48:43 2015 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 B09ED1A00FD for ; Thu, 23 Apr 2015 06:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XmsNPflc7x-z for ; Thu, 23 Apr 2015 06:48:38 -0700 (PDT) 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 DBFAC1B30B2 for ; Thu, 23 Apr 2015 06:48:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C8607250A10; Thu, 23 Apr 2015 06:48:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (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 06FD32403F1; Thu, 23 Apr 2015 06:48:24 -0700 (PDT) Message-ID: <5538F7F6.9070502@joelhalpern.com> Date: Thu, 23 Apr 2015 09:47:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" References: <55358DFD.2040804@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Thomas Narten , Guichard Jim , "Joel M. Halpern" , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 13:48:40 -0000 I think I am missing your point Thomas. We have an agreed common header (or at least an agreed basis and expectation that we will complete the rest expeditiously.) So I do not see any risk of ending up with a different NSH header for each transport. The question is where / when do we specify the transport details. If Surendra wants to take the existing, registered, code point, and indicate that what it is to carry is NSH (and presumably update it again when the RFC comes out) that is fine. I have no objection personally, and I can see no grounds for the working group to object. Where I have some concern is with the description of the Ethernet code point and the UDP port in the NSH document. That seems to be outside of the agreed scope. Yours, Joel On 4/23/15 7:09 AM, Thomas D. Nadeau wrote: > > In PWE3 we eventually did specify each one, we just did it a little here and a little there. We had a different PW header and transport encap depending on the transport for quite a while, which proved to be rather interesting if you were implementing any of it. Worse if you were an operator trying to deploy multiple types. Eventually (think years later) we settled on a common header format, but there were already some pretty good sized deployments out there which resisted unifying the header. The lesson: try to do it right from the beginning thinking that there will be multiple transport types. So while SFC might not define the transport encaps, we should define a common header format that works with at least a few representative/obvious ones to start, and have a plan to define others in collaboration with SFC using the same mechanism. Also consider OAM now, not halfway down the road. That doesnt mean we need to re-define existing mechanisms, but just make sure that if existi n g ones exist (which I think they do BTW), that they are incorporated into the unified plan somewhere. > > Tom > > >> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) wrote: >> >> I agree. If we start specifying every single transport we will spent time that otherwise can be spent on SFC-focused work. >> >> There is no problem for other groups to specify how they want to encode SfC in their transport type and bring this to SFC for review. >> >> Andrew >> >> >>> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) wrote: >>> >>> Joel, >>> >>> I concur: we don't want to start picking transports here, it creates all kinds of issues and is clearly out of scope. >>> >>> Rather, if there's a need for a transport to support NSH, then the work can occur in the associated working group. So, if there's a need for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, etc. can all have NSH supporting drafts. This ensures both consistency and proper layering within the scope of those protocols. >>> >>> On the UDP front specifically, there's a clear move to a explicit protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best place way to have a proper protocol stack. >>> >>> Paul >>> >>> >>>> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern wrote: >>>> >>>> This seems a reasonable course, but defining how the NSH header is carried on various transports seems not to be in my reading of the WG scope. >>>> >>>> In particular, it seems a bit odd to define the mechanisms for some randomly selected subset of transports. Thus, while the omission is arguably a bug in the charter, it is equally a bug to decide we will describe how to handle some transports. And do we really want to have to produce documents for each and every transport? >>>> >>>> Yours, >>>> Joel >>>> >>>>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>>>> Hello Chairs, >>>>> >>>>> The hallmark of NSH is that it can be transported over many different >>>>> overlays. Towards that, we already have an ether-type that allows us to >>>>> carry NSH natively over Ethernet and non-natively over UDP via >>>>> VXLAN-GPE. Given that UDP is the basic, simplest and most common overlay >>>>> transports, we should enable transporting NSH natively over UDP, as well. >>>>> >>>>> Is there a process for requesting a UDP port# for NSH for working group >>>>> drafts ? Alternatively, in the spirit of saving the UDP name space, is >>>>> it okay to transfer a pre-allocated but un-used UDP port# ? As part of >>>>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>>>> similar purpose. This number is unused and I would be glad to transfer >>>>> this over to NSH. >>>>> >>>>> Thanks, >>>>> Surendra. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 Apr 23 06:51:27 2015 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 92DA01A011B for ; Thu, 23 Apr 2015 06:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KNHDWM-iRBwQ for ; Thu, 23 Apr 2015 06:51:18 -0700 (PDT) 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 5A2281A88F1 for ; Thu, 23 Apr 2015 06:51:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 46B6E24066E; Thu, 23 Apr 2015 06:51:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (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 59421250A18; Thu, 23 Apr 2015 06:51:12 -0700 (PDT) Message-ID: <5538F89D.2000302@joelhalpern.com> Date: Thu, 23 Apr 2015 09:50:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Surendra Kumar (smkumar)" , Sumandra Majee , Dave Dolson , "Thomas D. Nadeau" , "Joel M. Halpern" References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 7bit Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 13:51:19 -0000 Your questions below are precisely why the charter calls for us to be transport independent. We are not here to debate the benefits and drawbacks of various transport. No one other than you has asked to mandate or require anything about the transports. Yours, Joel On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: > Sumandra, ... > It is fine to support SFC over VxLAN. However, why make that a > requirement to deploy SFC ? > Why are we requiring provisioning of VNIs to deploy SFC ? > Why are we requiring VTEP functionality, etc to deploy SFC ? > Why are we adding more cost to deploy SFC ? > Why are we making it complex to deploy SFC in a simple L3 network ? ... From nobody Thu Apr 23 06:57:36 2015 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 C830A1A0076 for ; Thu, 23 Apr 2015 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 2zM0K3_uHxum for ; Thu, 23 Apr 2015 06:57:31 -0700 (PDT) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 77D0E1A00B5 for ; Thu, 23 Apr 2015 06:57:21 -0700 (PDT) Received: from [192.168.1.108] (unknown [50.255.148.181]) by lucidvision.com (Postfix) with ESMTP id 0BC543334A37; Thu, 23 Apr 2015 09:57:21 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Thomas D. Nadeau" In-Reply-To: <5538F7F6.9070502@joelhalpern.com> Date: Thu, 23 Apr 2015 09:57:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Thomas Narten , Guichard Jim , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 13:57:32 -0000 > On Apr 23, 2015:9:47 AM, at 9:47 AM, Joel M. Halpern = wrote: >=20 > I think I am missing your point Thomas. We have an agreed common = header (or at least an agreed basis and expectation that we will = complete the rest expeditiously.) So I do not see any risk of ending up = with a different NSH header for each transport. >=20 > The question is where / when do we specify the transport details. Exactly. We need a common mapping/approach to transport - or at = least some coordination here. It shouldn=92t be done willy nilly. =97Tom > If Surendra wants to take the existing, registered, code point, and = indicate that what it is to carry is NSH (and presumably update it again = when the RFC comes out) that is fine. I have no objection personally, = and I can see no grounds for the working group to object. >=20 > Where I have some concern is with the description of the Ethernet code = point and the UDP port in the NSH document. That seems to be outside of = the agreed scope. >=20 > Yours, > Joel >=20 > On 4/23/15 7:09 AM, Thomas D. Nadeau wrote: >>=20 >> In PWE3 we eventually did specify each one, we just did it a = little here and a little there. We had a different PW header and = transport encap depending on the transport for quite a while, which = proved to be rather interesting if you were implementing any of it. = Worse if you were an operator trying to deploy multiple types. = Eventually (think years later) we settled on a common header format, but = there were already some pretty good sized deployments out there which = resisted unifying the header. The lesson: try to do it right from the = beginning thinking that there will be multiple transport types. So = while SFC might not define the transport encaps, we should define a = common header format that works with at least a few = representative/obvious ones to start, and have a plan to define others = in collaboration with SFC using the same mechanism. Also consider OAM = now, not halfway down the road. That doesn=92t mean we need to = re-define existing mechanisms, but just make sure that if existi > n > g ones exist (which I think they do BTW), that they are incorporated = into the unified plan somewhere. >>=20 >> =97Tom >>=20 >>=20 >>> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) = wrote: >>>=20 >>> I agree. If we start specifying every single transport we will spent = time that otherwise can be spent on SFC-focused work. >>>=20 >>> There is no problem for other groups to specify how they want to = encode SfC in their transport type and bring this to SFC for review. >>>=20 >>> Andrew >>>=20 >>>=20 >>>> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) = wrote: >>>>=20 >>>> Joel, >>>>=20 >>>> I concur: we don't want to start picking transports here, it = creates all kinds of issues and is clearly out of scope. >>>>=20 >>>> Rather, if there's a need for a transport to support NSH, then the = work can occur in the associated working group. So, if there's a need = for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, LISP, = etc. can all have NSH supporting drafts. This ensures both consistency = and proper layering within the scope of those protocols. >>>>=20 >>>> On the UDP front specifically, there's a clear move to a explicit = protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best = place way to have a proper protocol stack. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>>> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern = wrote: >>>>>=20 >>>>> This seems a reasonable course, but defining how the NSH header is = carried on various transports seems not to be in my reading of the WG = scope. >>>>>=20 >>>>> In particular, it seems a bit odd to define the mechanisms for = some randomly selected subset of transports. Thus, while the omission = is arguably a bug in the charter, it is equally a bug to decide we will = describe how to handle some transports. And do we really want to have = to produce documents for each and every transport? >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>>>>> Hello Chairs, >>>>>>=20 >>>>>> The hallmark of NSH is that it can be transported over many = different >>>>>> overlays. Towards that, we already have an ether-type that allows = us to >>>>>> carry NSH natively over Ethernet and non-natively over UDP =96 = via >>>>>> VXLAN-GPE. Given that UDP is the basic, simplest and most common = overlay >>>>>> transports, we should enable transporting NSH natively over UDP, = as well. >>>>>>=20 >>>>>> Is there a process for requesting a UDP port# for NSH for working = group >>>>>> drafts ? Alternatively, in the spirit of saving the UDP name = space, is >>>>>> it okay to transfer a pre-allocated but un-used UDP port# ? As = part of >>>>>> my work, I had UDP port# 6633 allocated a couple of years ago for = a >>>>>> similar purpose. This number is unused and I would be glad to = transfer >>>>>> this over to NSH. >>>>>>=20 >>>>>> Thanks, >>>>>> Surendra. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>=20 >=20 From nobody Thu Apr 23 07:23:12 2015 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 0F5231A899E for ; Thu, 23 Apr 2015 07:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 piE4MvuGWiI2 for ; Thu, 23 Apr 2015 07:23:07 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8E71A020B for ; Thu, 23 Apr 2015 07:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6069; q=dns/txt; s=iport; t=1429798941; x=1431008541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4hPZyHuo7t1xjOk+bAPYAV60uZlozTCif1+dCItW3zI=; b=gi78EX00FETppBWDgGWhkS0C51hkB7SCj/nmLpwE2V5H+XN1zeDEbvoD iK3h4L68ucZR7D07Ma/JlHeL8ciFoFw9ce+XrFmFr22uhXI9rodNsHVQZ u5g0asM/sZQ16Hk36JGTLD2B88ssNs1epIG3z8a4KGNMAZdxUTOjEtFTR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBAC4/jhV/51dJa1bgwxSXAXGHgmBRQqGBAKBNjgUAQEBAQEBAYEKhCEBAQQBAQEaSgcLEAIBCBguJwslAgQBCQQFiCsNzGYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs3hQQHhC0FkUGKMYEihVaHKINOg04jggYcgVFvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,631,1422921600"; d="scan'208";a="143786082" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 23 Apr 2015 14:22:20 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3NEMKhq027572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 14:22:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.235]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 09:22:20 -0500 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , "Thomas D. Nadeau" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAA== Date: Thu, 23 Apr 2015 14:22:19 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> In-Reply-To: <5538F7F6.9070502@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 14:23:10 -0000 Hi Joel, On 4/23/15, 9:47 AM, "Joel M. Halpern" wrote: >I think I am missing your point Thomas. We have an agreed common header >(or at least an agreed basis and expectation that we will complete the >rest expeditiously.) So I do not see any risk of ending up with a >different NSH header for each transport. > >The question is where / when do we specify the transport details. Jim> our charter does not call for us to work on the transport details; those should be addressed by the relevant WG for a given transport pointing to our SFC encapsulation work. > >If Surendra wants to take the existing, registered, code point, and >indicate that what it is to carry is NSH (and presumably update it again >when the RFC comes out) that is fine. I have no objection personally, >and I can see no grounds for the working group to object. Jim> from a chairs perspective I also have no objection. Likewise if other WG=B9s want to define in their transports how NSH is indicated then that is the right approach and I encourage it. > >Where I have some concern is with the description of the Ethernet code >point and the UDP port in the NSH document. That seems to be outside of >the agreed scope. > >Yours, >Joel > >On 4/23/15 7:09 AM, Thomas D. Nadeau wrote: >> >> In PWE3 we eventually did specify each one, we just did it a little >>here and a little there. We had a different PW header and transport >>encap depending on the transport for quite a while, which proved to be >>rather interesting if you were implementing any of it. Worse if you were >>an operator trying to deploy multiple types. Eventually (think years >>later) we settled on a common header format, but there were already some >>pretty good sized deployments out there which resisted unifying the >>header. The lesson: try to do it right from the beginning thinking that >>there will be multiple transport types. So while SFC might not define >>the transport encaps, we should define a common header format that works >>with at least a few representative/obvious ones to start, and have a >>plan to define others in collaboration with SFC using the same >>mechanism. Also consider OAM now, not halfway down the road. That >>doesn=B9t mean we need to re-define existing mechanisms, but just make >>sure that if existi > n >g ones exist (which I think they do BTW), that they are incorporated into >the unified plan somewhere. >> >> =8BTom >> >> >>> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) >>> wrote: >>> >>> I agree. If we start specifying every single transport we will spent >>>time that otherwise can be spent on SFC-focused work. >>> >>> There is no problem for other groups to specify how they want to >>>encode SfC in their transport type and bring this to SFC for review. >>> >>> Andrew >>> >>> >>>> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) >>>>wrote: >>>> >>>> Joel, >>>> >>>> I concur: we don't want to start picking transports here, it creates >>>>all kinds of issues and is clearly out of scope. >>>> >>>> Rather, if there's a need for a transport to support NSH, then the >>>>work can occur in the associated working group. So, if there's a need >>>>for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, >>>>LISP, etc. can all have NSH supporting drafts. This ensures both >>>>consistency and proper layering within the scope of those protocols. >>>> >>>> On the UDP front specifically, there's a clear move to a explicit >>>>protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best >>>>place way to have a proper protocol stack. >>>> >>>> Paul >>>> >>>> >>>>> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern >>>>>wrote: >>>>> >>>>> This seems a reasonable course, but defining how the NSH header is >>>>>carried on various transports seems not to be in my reading of the WG >>>>>scope. >>>>> >>>>> In particular, it seems a bit odd to define the mechanisms for some >>>>>randomly selected subset of transports. Thus, while the omission is >>>>>arguably a bug in the charter, it is equally a bug to decide we will >>>>>describe how to handle some transports. And do we really want to >>>>>have to produce documents for each and every transport? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>>>>> Hello Chairs, >>>>>> >>>>>> The hallmark of NSH is that it can be transported over many >>>>>>different >>>>>> overlays. Towards that, we already have an ether-type that allows >>>>>>us to >>>>>> carry NSH natively over Ethernet and non-natively over UDP =AD via >>>>>> VXLAN-GPE. Given that UDP is the basic, simplest and most common >>>>>>overlay >>>>>> transports, we should enable transporting NSH natively over UDP, as >>>>>>well. >>>>>> >>>>>> Is there a process for requesting a UDP port# for NSH for working >>>>>>group >>>>>> drafts ? Alternatively, in the spirit of saving the UDP name space, >>>>>>is >>>>>> it okay to transfer a pre-allocated but un-used UDP port# ? As part >>>>>>of >>>>>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>>>>> similar purpose. This number is unused and I would be glad to >>>>>>transfer >>>>>> this over to NSH. >>>>>> >>>>>> Thanks, >>>>>> Surendra. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 Apr 23 08:11:41 2015 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 9D8D21AC3EC for ; Thu, 23 Apr 2015 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y7WFyanLTXxX for ; Thu, 23 Apr 2015 08:11:38 -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 61D061AC3B1 for ; Thu, 23 Apr 2015 08:11:15 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 2831BDFF719E9; Thu, 23 Apr 2015 15:11:10 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t3NFB9KC024931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 11:11:10 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 11:11:09 -0400 From: "Dolganow, Andrew (Andrew)" To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , "Thomas D. Nadeau" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W0dCAgAJqwgCAAKgP9YAA0vqAgAAsEQCAAAm1gP//mEsA Date: Thu, 23 Apr 2015 15:11:09 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@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.4.8.150116 x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Surendra Kumar \(smkumar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 15:11:40 -0000 aW5saW5lDQoNCk9uIDIwMTUtMDQtMjMsIDc6MjIgQU0sICJKaW0gR3VpY2hhcmQgKGpndWljaGFy KSIgd3JvdGU6DQoNCj5IaSBKb2VsLA0KPg0KPk9uIDQvMjMvMTUsIDk6NDcgQU0sICJKb2VsIE0u IEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4NCj4+SSB0aGluayBJIGFt IG1pc3NpbmcgeW91ciBwb2ludCBUaG9tYXMuICBXZSBoYXZlIGFuIGFncmVlZCBjb21tb24gaGVh ZGVyDQo+PihvciBhdCBsZWFzdCBhbiBhZ3JlZWQgYmFzaXMgYW5kIGV4cGVjdGF0aW9uIHRoYXQg d2Ugd2lsbCBjb21wbGV0ZSB0aGUNCj4+cmVzdCBleHBlZGl0aW91c2x5LikgIFNvIEkgZG8gbm90 IHNlZSBhbnkgcmlzayBvZiBlbmRpbmcgdXAgd2l0aCBhDQo+PmRpZmZlcmVudCBOU0ggaGVhZGVy IGZvciBlYWNoIHRyYW5zcG9ydC4NCj4+DQo+PlRoZSBxdWVzdGlvbiBpcyB3aGVyZSAvIHdoZW4g ZG8gd2Ugc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGRldGFpbHMuDQo+DQo+SmltPiBvdXIgY2hhcnRl ciBkb2VzIG5vdCBjYWxsIGZvciB1cyB0byB3b3JrIG9uIHRoZSB0cmFuc3BvcnQgZGV0YWlsczsN Cj50aG9zZSBzaG91bGQgYmUgYWRkcmVzc2VkIGJ5IHRoZSByZWxldmFudCBXRyBmb3IgYSBnaXZl biB0cmFuc3BvcnQNCj5wb2ludGluZyB0byBvdXIgU0ZDIGVuY2Fwc3VsYXRpb24gd29yay4NCkFn cmVlLCBtYXliZSB3ZSBzaG91bGQgbW9yZSBleHBsaWN0IGluIHRoZSBTRkMgZHJhZnQgYW5kIHNh eSB0aGF0IE5TSA0KaGVhZGVyIG11c3QgcmVtYWluIHRyYW5zcG9ydCBhZ25vc3RpYywgc28gc29t ZW9uZSBpbiB0aGUgZnV0dXJlIGRvZXMgbm90DQp0cnkgdG8gcHV0IHRyYW5zcG9ydCBzcGVjaWZp Y3MgaW4gdGhlIE5TSCBoZWFkZXIuDQo+DQo+Pg0KPj5JZiBTdXJlbmRyYSB3YW50cyB0byB0YWtl IHRoZSBleGlzdGluZywgcmVnaXN0ZXJlZCwgY29kZSBwb2ludCwgYW5kDQo+PmluZGljYXRlIHRo YXQgd2hhdCBpdCBpcyB0byBjYXJyeSBpcyBOU0ggKGFuZCBwcmVzdW1hYmx5IHVwZGF0ZSBpdCBh Z2Fpbg0KPj53aGVuIHRoZSBSRkMgY29tZXMgb3V0KSB0aGF0IGlzIGZpbmUuICBJIGhhdmUgbm8g b2JqZWN0aW9uIHBlcnNvbmFsbHksDQo+PmFuZCBJIGNhbiBzZWUgbm8gZ3JvdW5kcyBmb3IgdGhl IHdvcmtpbmcgZ3JvdXAgdG8gb2JqZWN0Lg0KPg0KPkppbT4gZnJvbSBhIGNoYWlycyBwZXJzcGVj dGl2ZSBJIGFsc28gaGF2ZSBubyBvYmplY3Rpb24uIExpa2V3aXNlIGlmIG90aGVyDQo+V0fCuXMg d2FudCB0byBkZWZpbmUgaW4gdGhlaXIgdHJhbnNwb3J0cyBob3cgTlNIIGlzIGluZGljYXRlZCB0 aGVuIHRoYXQgaXMNCj50aGUgcmlnaHQgYXBwcm9hY2ggYW5kIEkgZW5jb3VyYWdlIGl0Lg0KQWdy ZWUNCg0KPg0KPj4NCj4+V2hlcmUgSSBoYXZlIHNvbWUgY29uY2VybiBpcyB3aXRoIHRoZSBkZXNj cmlwdGlvbiBvZiB0aGUgRXRoZXJuZXQgY29kZQ0KPj5wb2ludCBhbmQgdGhlIFVEUCBwb3J0IGlu IHRoZSBOU0ggZG9jdW1lbnQuICBUaGF0IHNlZW1zIHRvIGJlIG91dHNpZGUgb2YNCj4+dGhlIGFn cmVlZCBzY29wZS4NCg0KV2UgZGlkIG5lZWRlZCBhdCBsZWFzdCBzb21lIGZpcnN0IGFwcGxpY2F0 aW9uIGVuY29kaW5nIGp1c3Qgc28gd2UgaGF2ZSBhdA0KbGVhc3QgYSBzYW1wbGUgb2YgdHJhbnNw b3J0LiBNYXliZSB3ZSBzaG91bGQgcHV0IHNvbWUgZXhwbGFuYXRvcnkgbm90ZQ0KdG93YXJkcyB0 aGF0IGluIHRoZSBTRkMgZHJhZnQ/DQoNCkFuZHJldw0KPj4NCj4+WW91cnMsDQo+PkpvZWwNCj4+ DQo+Pk9uIDQvMjMvMTUgNzowOSBBTSwgVGhvbWFzIEQuIE5hZGVhdSB3cm90ZToNCj4+Pg0KPj4+ IAlJbiBQV0UzIHdlIGV2ZW50dWFsbHkgZGlkIHNwZWNpZnkgZWFjaCBvbmUsIHdlIGp1c3QgZGlk IGl0IGEgbGl0dGxlDQo+Pj5oZXJlIGFuZCBhIGxpdHRsZSB0aGVyZS4gV2UgaGFkIGEgZGlmZmVy ZW50IFBXIGhlYWRlciBhbmQgdHJhbnNwb3J0DQo+Pj5lbmNhcCBkZXBlbmRpbmcgb24gdGhlIHRy YW5zcG9ydCBmb3IgcXVpdGUgYSB3aGlsZSwgd2hpY2ggcHJvdmVkIHRvIGJlDQo+Pj5yYXRoZXIg aW50ZXJlc3RpbmcgaWYgeW91IHdlcmUgaW1wbGVtZW50aW5nIGFueSBvZiBpdC4gV29yc2UgaWYg eW91IHdlcmUNCj4+PmFuIG9wZXJhdG9yIHRyeWluZyB0byBkZXBsb3kgbXVsdGlwbGUgdHlwZXMu IEV2ZW50dWFsbHkgKHRoaW5rIHllYXJzDQo+Pj5sYXRlcikgd2Ugc2V0dGxlZCBvbiBhIGNvbW1v biBoZWFkZXIgZm9ybWF0LCBidXQgdGhlcmUgd2VyZSBhbHJlYWR5IHNvbWUNCj4+PnByZXR0eSBn b29kIHNpemVkIGRlcGxveW1lbnRzIG91dCB0aGVyZSB3aGljaCByZXNpc3RlZCB1bmlmeWluZyB0 aGUNCj4+PmhlYWRlci4gIFRoZSBsZXNzb246IHRyeSB0byBkbyBpdCByaWdodCBmcm9tIHRoZSBi ZWdpbm5pbmcgdGhpbmtpbmcgdGhhdA0KPj4+dGhlcmUgd2lsbCBiZSBtdWx0aXBsZSB0cmFuc3Bv cnQgdHlwZXMuICBTbyB3aGlsZSBTRkMgbWlnaHQgbm90IGRlZmluZQ0KPj4+dGhlIHRyYW5zcG9y dCBlbmNhcHMsIHdlIHNob3VsZCBkZWZpbmUgYSBjb21tb24gaGVhZGVyIGZvcm1hdCB0aGF0IHdv cmtzDQo+Pj53aXRoIGF0IGxlYXN0IGEgZmV3IHJlcHJlc2VudGF0aXZlL29idmlvdXMgb25lcyB0 byBzdGFydCwgYW5kIGhhdmUgYQ0KPj4+cGxhbiB0byBkZWZpbmUgb3RoZXJzIGluIGNvbGxhYm9y YXRpb24gd2l0aCBTRkMgdXNpbmcgdGhlIHNhbWUNCj4+Pm1lY2hhbmlzbS4gIEFsc28gY29uc2lk ZXIgT0FNIG5vdywgbm90IGhhbGZ3YXkgZG93biB0aGUgcm9hZC4gIFRoYXQNCj4+PmRvZXNuwrl0 IG1lYW4gd2UgbmVlZCB0byByZS1kZWZpbmUgZXhpc3RpbmcgbWVjaGFuaXNtcywgYnV0IGp1c3Qg bWFrZQ0KPj4+c3VyZSB0aGF0IGlmIGV4aXN0aQ0KPj4gbg0KPj5nIG9uZXMgZXhpc3QgKHdoaWNo IEkgdGhpbmsgdGhleSBkbyBCVFcpLCB0aGF0IHRoZXkgYXJlIGluY29ycG9yYXRlZCBpbnRvDQo+ PnRoZSB1bmlmaWVkIHBsYW4gc29tZXdoZXJlLg0KPj4+DQo+Pj4gCeKAuVRvbQ0KPj4+DQo+Pj4N Cj4+Pj4gT24gQXByIDIyLCAyMDE1OjEwOjM0IFBNLCBhdCAxMDozNCBQTSwgRG9sZ2Fub3csIEFu ZHJldyAoQW5kcmV3KQ0KPj4+PjxhbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1sdWNlbnQuY29tPiB3 cm90ZToNCj4+Pj4NCj4+Pj4gSSBhZ3JlZS4gSWYgd2Ugc3RhcnQgc3BlY2lmeWluZyBldmVyeSBz aW5nbGUgdHJhbnNwb3J0IHdlIHdpbGwgc3BlbnQNCj4+Pj50aW1lIHRoYXQgb3RoZXJ3aXNlIGNh biBiZSBzcGVudCBvbiBTRkMtZm9jdXNlZCB3b3JrLg0KPj4+Pg0KPj4+PiBUaGVyZSBpcyBubyBw cm9ibGVtIGZvciBvdGhlciBncm91cHMgdG8gc3BlY2lmeSBob3cgdGhleSB3YW50IHRvDQo+Pj4+ ZW5jb2RlIFNmQyBpbiB0aGVpciB0cmFuc3BvcnQgdHlwZSBhbmQgYnJpbmcgdGhpcyB0byBTRkMg Zm9yIHJldmlldy4NCj4+Pj4NCj4+Pj4gQW5kcmV3DQo+Pj4+DQo+Pj4+DQo+Pj4+PiBPbiBBcHIg MjIsIDIwMTUsIGF0IDU6MzMgQU0sIFBhdWwgUXVpbm4gKHBhdWxxKSA8cGF1bHFAY2lzY28uY29t Pg0KPj4+Pj53cm90ZToNCj4+Pj4+DQo+Pj4+PiBKb2VsLA0KPj4+Pj4NCj4+Pj4+IEkgY29uY3Vy OiB3ZSBkb24ndCB3YW50IHRvIHN0YXJ0IHBpY2tpbmcgdHJhbnNwb3J0cyBoZXJlLCBpdCBjcmVh dGVzDQo+Pj4+PmFsbCBraW5kcyBvZiBpc3N1ZXMgYW5kIGlzIGNsZWFybHkgb3V0IG9mIHNjb3Bl Lg0KPj4+Pj4NCj4+Pj4+IFJhdGhlciwgaWYgdGhlcmUncyBhIG5lZWQgZm9yIGEgdHJhbnNwb3J0 IHRvIHN1cHBvcnQgTlNILCB0aGVuIHRoZQ0KPj4+Pj53b3JrIGNhbiBvY2N1ciBpbiB0aGUgYXNz b2NpYXRlZCB3b3JraW5nIGdyb3VwLiAgU28sIGlmIHRoZXJlJ3MgYSBuZWVkDQo+Pj4+PmZvciBN UExTLCB0aGVuIGEgZHJhZnQgY2FuIGJlIHN1Ym1pdHRlZCB0byBNUExTLCBzaW1pbGFybHksIE5W TzMsDQo+Pj4+PkxJU1AsIGV0Yy4gY2FuIGFsbCBoYXZlIE5TSCBzdXBwb3J0aW5nIGRyYWZ0cy4g IFRoaXMgZW5zdXJlcyBib3RoDQo+Pj4+PmNvbnNpc3RlbmN5IGFuZCBwcm9wZXIgbGF5ZXJpbmcg d2l0aGluIHRoZSBzY29wZSBvZiB0aG9zZSBwcm90b2NvbHMuDQo+Pj4+Pg0KPj4+Pj4gT24gdGhl IFVEUCBmcm9udCBzcGVjaWZpY2FsbHksIHRoZXJlJ3MgYSBjbGVhciBtb3ZlIHRvIGEgZXhwbGlj aXQNCj4+Pj4+cHJvdG9jb2wgZGVtdXg6VlhMQU4tZ3BlLCBHVUUsIEdFTkVWRSBldGMuICBUaGF0 J3MgcHJvYmFibHkgdGhlIGJlc3QNCj4+Pj4+cGxhY2Ugd2F5IHRvIGhhdmUgYSBwcm9wZXIgcHJv dG9jb2wgc3RhY2suDQo+Pj4+Pg0KPj4+Pj4gUGF1bA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4gT24g QXByIDIwLCAyMDE1LCBhdCA3OjM4IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVy bi5jb20+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFRoaXMgc2VlbXMgYSByZWFzb25h YmxlIGNvdXJzZSwgYnV0IGRlZmluaW5nIGhvdyB0aGUgTlNIIGhlYWRlciBpcw0KPj4+Pj4+Y2Fy cmllZCBvbiB2YXJpb3VzIHRyYW5zcG9ydHMgc2VlbXMgbm90IHRvIGJlIGluIG15IHJlYWRpbmcg b2YgdGhlIFdHDQo+Pj4+Pj5zY29wZS4NCj4+Pj4+Pg0KPj4+Pj4+IEluIHBhcnRpY3VsYXIsIGl0 IHNlZW1zIGEgYml0IG9kZCB0byBkZWZpbmUgdGhlIG1lY2hhbmlzbXMgZm9yIHNvbWUNCj4+Pj4+ PnJhbmRvbWx5IHNlbGVjdGVkIHN1YnNldCBvZiB0cmFuc3BvcnRzLiAgVGh1cywgd2hpbGUgdGhl IG9taXNzaW9uIGlzDQo+Pj4+Pj5hcmd1YWJseSBhIGJ1ZyBpbiB0aGUgY2hhcnRlciwgaXQgaXMg ZXF1YWxseSBhIGJ1ZyB0byBkZWNpZGUgd2Ugd2lsbA0KPj4+Pj4+ZGVzY3JpYmUgaG93IHRvIGhh bmRsZSBzb21lIHRyYW5zcG9ydHMuICBBbmQgZG8gd2UgcmVhbGx5IHdhbnQgdG8NCj4+Pj4+Pmhh dmUgdG8gcHJvZHVjZSBkb2N1bWVudHMgZm9yIGVhY2ggYW5kIGV2ZXJ5IHRyYW5zcG9ydD8NCj4+ Pj4+Pg0KPj4+Pj4+IFlvdXJzLA0KPj4+Pj4+IEpvZWwNCj4+Pj4+Pg0KPj4+Pj4+PiBPbiA0LzIw LzE1IDc6MDIgUE0sIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSB3cm90ZToNCj4+Pj4+Pj4gSGVs bG8gQ2hhaXJzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGUgaGFsbG1hcmsgb2YgTlNIIGlzIHRoYXQg aXQgY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgbWFueQ0KPj4+Pj4+PmRpZmZlcmVudA0KPj4+Pj4+ PiBvdmVybGF5cy4gVG93YXJkcyB0aGF0LCB3ZSBhbHJlYWR5IGhhdmUgYW4gZXRoZXItdHlwZSB0 aGF0IGFsbG93cw0KPj4+Pj4+PnVzIHRvDQo+Pj4+Pj4+IGNhcnJ5IE5TSCBuYXRpdmVseSBvdmVy IEV0aGVybmV0IGFuZCBub24tbmF0aXZlbHkgb3ZlciBVRFAgwq0gdmlhDQo+Pj4+Pj4+IFZYTEFO LUdQRS4gR2l2ZW4gdGhhdCBVRFAgaXMgdGhlIGJhc2ljLCBzaW1wbGVzdCBhbmQgbW9zdCBjb21t b24NCj4+Pj4+Pj5vdmVybGF5DQo+Pj4+Pj4+IHRyYW5zcG9ydHMsIHdlIHNob3VsZCBlbmFibGUg dHJhbnNwb3J0aW5nIE5TSCBuYXRpdmVseSBvdmVyIFVEUCwgYXMNCj4+Pj4+Pj53ZWxsLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBJcyB0aGVyZSBhIHByb2Nlc3MgZm9yIHJlcXVlc3RpbmcgYSBVRFAgcG9y dCMgZm9yIE5TSCBmb3Igd29ya2luZw0KPj4+Pj4+Pmdyb3VwDQo+Pj4+Pj4+IGRyYWZ0cyA/IEFs dGVybmF0aXZlbHksIGluIHRoZSBzcGlyaXQgb2Ygc2F2aW5nIHRoZSBVRFAgbmFtZSBzcGFjZSwN Cj4+Pj4+Pj5pcw0KPj4+Pj4+PiBpdCBva2F5IHRvIHRyYW5zZmVyIGEgcHJlLWFsbG9jYXRlZCBi dXQgdW4tdXNlZCBVRFAgcG9ydCMgPyBBcyBwYXJ0DQo+Pj4+Pj4+b2YNCj4+Pj4+Pj4gbXkgd29y aywgSSBoYWQgVURQIHBvcnQjIDY2MzMgYWxsb2NhdGVkIGEgY291cGxlIG9mIHllYXJzIGFnbyBm b3IgYQ0KPj4+Pj4+PiBzaW1pbGFyIHB1cnBvc2UuIFRoaXMgbnVtYmVyIGlzIHVudXNlZCBhbmQg SSB3b3VsZCBiZSBnbGFkIHRvDQo+Pj4+Pj4+dHJhbnNmZXINCj4+Pj4+Pj4gdGhpcyBvdmVyIHRv IE5TSC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBTdXJlbmRyYS4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBzZmNAaWV0Zi5v cmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+ Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNm YyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4+Pj4NCj4+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Thu Apr 23 08:48:06 2015 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 08BB31ACC7F for ; Thu, 23 Apr 2015 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 OdC70Qo00l5r for ; Thu, 23 Apr 2015 08:48:03 -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 4D19F1AC411 for ; Thu, 23 Apr 2015 08:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6104; q=dns/txt; s=iport; t=1429804073; x=1431013673; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eubE1PrLJMWkpp94MWdgV6FOwzHRFbN0opHBJ+q9/fs=; b=QvoKGtCsQE3U45518pHVFakmq4cmsLP+k4bLvjGQEiaL7GT5+YAvvf56 ElNIVC3BHB/H0aNhtJt4/6mHPNYTyCjMgANDe5D9LRKjIDdah4lBDgxNh NOZ5zICF304YdlNhOnB0HQSZg1Q38IvGyS7jP5btrxG5okSqbgHQ6eYc0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBADIEzlV/4YNJK1bgwxSXAXGHwmBRwqGBAKBNjgUAQEBAQEBAYEKhCEBAQQBAQFkBwsQAgEIGC4nCyUCBAEJBAWIKw3MXwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizeEUTMHhC0FjyqCIIo1gSKFXIcqg1WDTiNggSccgVFvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143932045" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 23 Apr 2015 15:47:51 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t3NFlpKv026762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 15:47:51 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 10:47:50 -0500 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , "Thomas D. Nadeau" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//6w/AA== Date: Thu, 23 Apr 2015 15:47:50 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> In-Reply-To: <5538F7F6.9070502@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.10.206] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1B74F31B7A0A68418BC6C751A6F01AD9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 15:48:05 -0000 Joel, -- Where I have some concern is with the description of the Ethernet code point and the UDP port in the NSH document. That seems to be outside of the agreed scope. -- Based on this, we should remove section 11 altogether from the NSH draft. Then, that brings up the question of, why we are we even standardizing something we don=B9t know how to signal. It seems like an effort in the voi= d. Surendra. On 4/23/15, 6:47 AM, "Joel M. Halpern" wrote: >I think I am missing your point Thomas. We have an agreed common header >(or at least an agreed basis and expectation that we will complete the >rest expeditiously.) So I do not see any risk of ending up with a >different NSH header for each transport. > >The question is where / when do we specify the transport details. > >If Surendra wants to take the existing, registered, code point, and >indicate that what it is to carry is NSH (and presumably update it again >when the RFC comes out) that is fine. I have no objection personally, >and I can see no grounds for the working group to object. > >Where I have some concern is with the description of the Ethernet code >point and the UDP port in the NSH document. That seems to be outside of >the agreed scope. > >Yours, >Joel > >On 4/23/15 7:09 AM, Thomas D. Nadeau wrote: >> >> In PWE3 we eventually did specify each one, we just did it a little >>here and a little there. We had a different PW header and transport >>encap depending on the transport for quite a while, which proved to be >>rather interesting if you were implementing any of it. Worse if you were >>an operator trying to deploy multiple types. Eventually (think years >>later) we settled on a common header format, but there were already some >>pretty good sized deployments out there which resisted unifying the >>header. The lesson: try to do it right from the beginning thinking that >>there will be multiple transport types. So while SFC might not define >>the transport encaps, we should define a common header format that works >>with at least a few representative/obvious ones to start, and have a >>plan to define others in collaboration with SFC using the same >>mechanism. Also consider OAM now, not halfway down the road. That >>doesn=B9t mean we need to re-define existing mechanisms, but just make >>sure that if existi > n >g ones exist (which I think they do BTW), that they are incorporated into >the unified plan somewhere. >> >> =8BTom >> >> >>> On Apr 22, 2015:10:34 PM, at 10:34 PM, Dolganow, Andrew (Andrew) >>> wrote: >>> >>> I agree. If we start specifying every single transport we will spent >>>time that otherwise can be spent on SFC-focused work. >>> >>> There is no problem for other groups to specify how they want to >>>encode SfC in their transport type and bring this to SFC for review. >>> >>> Andrew >>> >>> >>>> On Apr 22, 2015, at 5:33 AM, Paul Quinn (paulq) >>>>wrote: >>>> >>>> Joel, >>>> >>>> I concur: we don't want to start picking transports here, it creates >>>>all kinds of issues and is clearly out of scope. >>>> >>>> Rather, if there's a need for a transport to support NSH, then the >>>>work can occur in the associated working group. So, if there's a need >>>>for MPLS, then a draft can be submitted to MPLS, similarly, NVO3, >>>>LISP, etc. can all have NSH supporting drafts. This ensures both >>>>consistency and proper layering within the scope of those protocols. >>>> >>>> On the UDP front specifically, there's a clear move to a explicit >>>>protocol demux:VXLAN-gpe, GUE, GENEVE etc. That's probably the best >>>>place way to have a proper protocol stack. >>>> >>>> Paul >>>> >>>> >>>>> On Apr 20, 2015, at 7:38 PM, Joel M. Halpern >>>>>wrote: >>>>> >>>>> This seems a reasonable course, but defining how the NSH header is >>>>>carried on various transports seems not to be in my reading of the WG >>>>>scope. >>>>> >>>>> In particular, it seems a bit odd to define the mechanisms for some >>>>>randomly selected subset of transports. Thus, while the omission is >>>>>arguably a bug in the charter, it is equally a bug to decide we will >>>>>describe how to handle some transports. And do we really want to >>>>>have to produce documents for each and every transport? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>>> On 4/20/15 7:02 PM, Surendra Kumar (smkumar) wrote: >>>>>> Hello Chairs, >>>>>> >>>>>> The hallmark of NSH is that it can be transported over many >>>>>>different >>>>>> overlays. Towards that, we already have an ether-type that allows >>>>>>us to >>>>>> carry NSH natively over Ethernet and non-natively over UDP =AD via >>>>>> VXLAN-GPE. Given that UDP is the basic, simplest and most common >>>>>>overlay >>>>>> transports, we should enable transporting NSH natively over UDP, as >>>>>>well. >>>>>> >>>>>> Is there a process for requesting a UDP port# for NSH for working >>>>>>group >>>>>> drafts ? Alternatively, in the spirit of saving the UDP name space, >>>>>>is >>>>>> it okay to transfer a pre-allocated but un-used UDP port# ? As part >>>>>>of >>>>>> my work, I had UDP port# 6633 allocated a couple of years ago for a >>>>>> similar purpose. This number is unused and I would be glad to >>>>>>transfer >>>>>> this over to NSH. >>>>>> >>>>>> Thanks, >>>>>> Surendra. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 Apr 23 09:07:57 2015 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 F17B41A1BCC for ; Thu, 23 Apr 2015 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 c7gIsTyrdaPc for ; Thu, 23 Apr 2015 09:07:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417931A1BA3 for ; Thu, 23 Apr 2015 09:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1597; q=dns/txt; s=iport; t=1429805259; x=1431014859; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z8a/OYhYtcac2iYEbmg2NF240CEgq4Ji6kpZF2ofIxs=; b=CgxCf49pKSuIrTeKtQi9Z14biF3xNDOnp7prMpZ7dl/piwBwgA3PwcSN QZO1vhBEubqfypYQy6ArNIAl5j4ZW5JtlNQnQT7SxA6OifTxYoHMeSLBD uYdgZweOoalXugBt0gElOSd4+9QLU48573kvQzlFGiGGT/pfzCs3N2SMK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQByFzlV/5NdJa1bgwyBLgXNfQKBNkwBAQEBAQGBC4QhAQEEeRACAQgYLjIlAgQBDQWIK8xdAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s3hCBkB4QtAQSLIoYoijWBIpBbg04jYIMUb4FEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="414239609" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 23 Apr 2015 16:07:38 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3NG7bX7024526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 16:07:37 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 11:07:37 -0500 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , Sumandra Majee , Dave Dolson , "Thomas D. Nadeau" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgIABCUKA//+w/gA= Date: Thu, 23 Apr 2015 16:07:36 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> In-Reply-To: <5538F89D.2000302@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.10.206] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <843EFF54B8B6DF43B061F57D72C39E5A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:07:56 -0000 Joel, I=B9ve always been saying that the strong point of NSH is that it is transport independent, unlike GENEVE (in nvo3 archives), for instance. Which in fact provides equivalent header capabilities, but has a specific transport . I agree we can=B9t enumerate all transports and go modify them all from SFC WG. As I showed in the the other diagram, we should demonstrate this transport independence in the fundamental layers of the IP stack. We have ether type that covers L2 and L3. We should have one for L4. To me, native ethernet and native UDP are foundational. The rest can be done in other working groups as you suggest. We have the demux in NSH just as GUE and GENEVE to signal payloads. Btw, I am no way tied to 6633. WG can allocate another one and that would be fine. Surendra. On 4/23/15, 6:50 AM, "Joel M. Halpern" wrote: >Your questions below are precisely why the charter calls for us to be >transport independent. We are not here to debate the benefits and >drawbacks of various transport. No one other than you has asked to >mandate or require anything about the transports. > >Yours, >Joel > >On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: >> Sumandra, >... >> It is fine to support SFC over VxLAN. However, why make that a >> requirement to deploy SFC ? >> Why are we requiring provisioning of VNIs to deploy SFC ? >> Why are we requiring VTEP functionality, etc to deploy SFC ? >> Why are we adding more cost to deploy SFC ? >> Why are we making it complex to deploy SFC in a simple L3 network ? >... From nobody Thu Apr 23 09:14:13 2015 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 CFEA81A1BE7 for ; Thu, 23 Apr 2015 09:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C4gcS6TgQfKl for ; Thu, 23 Apr 2015 09:14:10 -0700 (PDT) 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 820F01A1EF2 for ; Thu, 23 Apr 2015 09:13:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5054E24066E; Thu, 23 Apr 2015 09:13:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (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 64866250A29; Thu, 23 Apr 2015 09:13:54 -0700 (PDT) Message-ID: <55391A0F.5090506@joelhalpern.com> Date: Thu, 23 Apr 2015 12:13:03 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Surendra Kumar (smkumar)" , Sumandra Majee , Dave Dolson , "Thomas D. Nadeau" References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:14:12 -0000 One of the reasons why I appreciated the way the charter was drawn is that arguing about which transports are "foundational" does not actually help anyone. I understand why you consider those "foundational" Given that it is out of scope for the group, and provides no benefit to the group, I would prefer not to get into a series of debates about which ones are actually foundational. As a corollary, I see no reason to use a different UDP port than the one you have. I just don't see it as the WG job to pick. Yours, Joel On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote: > Joel, > > Ive always been saying that the strong point of NSH is that it is > transport independent, unlike GENEVE (in nvo3 archives), for instance. > Which in fact provides equivalent header capabilities, but has a specific > transport . > > I agree we cant enumerate all transports and go modify them all from SFC > WG. As I showed in the the other diagram, we should demonstrate this > transport independence in the fundamental layers of the IP stack. We have > ether type that covers L2 and L3. We should have one for L4. > > To me, native ethernet and native UDP are foundational. The rest can be > done in other working groups as you suggest. We have the demux in NSH just > as GUE and GENEVE to signal payloads. > > Btw, I am no way tied to 6633. WG can allocate another one and that would > be fine. > Surendra. > > On 4/23/15, 6:50 AM, "Joel M. Halpern" wrote: > >> Your questions below are precisely why the charter calls for us to be >> transport independent. We are not here to debate the benefits and >> drawbacks of various transport. No one other than you has asked to >> mandate or require anything about the transports. >> >> Yours, >> Joel >> >> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: >>> Sumandra, >> ... >>> It is fine to support SFC over VxLAN. However, why make that a >>> requirement to deploy SFC ? >>> Why are we requiring provisioning of VNIs to deploy SFC ? >>> Why are we requiring VTEP functionality, etc to deploy SFC ? >>> Why are we adding more cost to deploy SFC ? >>> Why are we making it complex to deploy SFC in a simple L3 network ? >> ... > > From nobody Thu Apr 23 09:32:23 2015 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 986131A9097 for ; Thu, 23 Apr 2015 09:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 GRCb75ltYmHC for ; Thu, 23 Apr 2015 09:32:21 -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 D3F901A8757 for ; Thu, 23 Apr 2015 09:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3524; q=dns/txt; s=iport; t=1429806735; x=1431016335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+ZPO/w+hM/rDMFiBK69ZjrEgfFpe091mNxZBmXXqAmk=; b=JMW/hfDOuP7Vy/nt2PmM3UrcZvCyzR2cPSSe/yRODOLsihc0QxF5PsKs aTpMuAB/f/9cV1ytq6R1hKquvQlt6DaeCcKvKz0b50Rft2XCrhCClJyXE idAJpCm+lujInP8H5Whgu4DIVSCxwcWtHDbYWpIuyzs8gIvmyfS4nPs6U k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQCQHTlV/5xdJa1bgwyBLgWDFcpoAhyBGkwBAQEBAQGBC4QhAQEENEUQAgEIGAQoAgIwJQIEAQ0FiCuaeZx6BpRrAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EbihyEIDEzB4JigUsBBI8qgiCKNYEikFuDTiNggxRvgUSBAAEBAQ X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="414240672" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 23 Apr 2015 16:32:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3NGWF70026604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 16:32:15 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 11:32:14 -0500 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , Sumandra Majee , Dave Dolson , "Thomas D. Nadeau" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgIABCUKA//+w/gCAAHbhgP//kACA Date: Thu, 23 Apr 2015 16:32:14 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> In-Reply-To: <55391A0F.5090506@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.10.206] Content-Type: text/plain; charset="euc-kr" Content-ID: <2925BB7EDDD40C4DA514912E1FF3179F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:32:22 -0000 SWYgdGhlIFdHIGFncmVlcyB3aXRoIHRoaXMsIHRoZW4gdGhlcmUgaXMgbm8gcGxhY2UgZm9yIHNl Y3Rpb24gMTEgaW4gTlNIDQpkcmFmdCBhbmQgd2Ugc2hvdWxkIHJlbW92ZSBpdCENCldoeSBkb2N1 bWVudCBhIHNwZWNpZmljIHNldCBvZiB0cmFuc3BvcnRzID8NCg0KU3VyZW5kcmEuDQoNCk9uIDQv MjMvMTUsIDk6MTMgQU0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3 cm90ZToNCg0KPk9uZSBvZiB0aGUgcmVhc29ucyB3aHkgSSBhcHByZWNpYXRlZCB0aGUgd2F5IHRo ZSBjaGFydGVyIHdhcyBkcmF3biBpcw0KPnRoYXQgYXJndWluZyBhYm91dCB3aGljaCB0cmFuc3Bv cnRzIGFyZSAiZm91bmRhdGlvbmFsIiBkb2VzIG5vdCBhY3R1YWxseQ0KPmhlbHAgYW55b25lLiAg SSB1bmRlcnN0YW5kIHdoeSB5b3UgY29uc2lkZXIgdGhvc2UgImZvdW5kYXRpb25hbCIgIEdpdmVu DQo+dGhhdCBpdCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBncm91cCwgYW5kIHByb3ZpZGVzIG5v IGJlbmVmaXQgdG8gdGhlDQo+Z3JvdXAsIEkgd291bGQgcHJlZmVyIG5vdCB0byBnZXQgaW50byBh IHNlcmllcyBvZiBkZWJhdGVzIGFib3V0IHdoaWNoDQo+b25lcyBhcmUgYWN0dWFsbHkgZm91bmRh dGlvbmFsLg0KPg0KPkFzIGEgY29yb2xsYXJ5LCBJIHNlZSBubyByZWFzb24gdG8gdXNlIGEgZGlm ZmVyZW50IFVEUCBwb3J0IHRoYW4gdGhlIG9uZQ0KPnlvdSBoYXZlLiAgSSBqdXN0IGRvbid0IHNl ZSBpdCBhcyB0aGUgV0cgam9iIHRvIHBpY2suDQo+DQo+WW91cnMsDQo+Sm9lbA0KPg0KPk9uIDQv MjMvMTUgMTI6MDcgUE0sIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSB3cm90ZToNCj4+IEpvZWws DQo+Pg0KPj4gSan2dmUgYWx3YXlzIGJlZW4gc2F5aW5nIHRoYXQgdGhlIHN0cm9uZyBwb2ludCBv ZiBOU0ggaXMgdGhhdCBpdCBpcw0KPj4gdHJhbnNwb3J0IGluZGVwZW5kZW50LCB1bmxpa2UgR0VO RVZFIChpbiBudm8zIGFyY2hpdmVzKSwgZm9yIGluc3RhbmNlLg0KPj4gV2hpY2ggaW4gZmFjdCBw cm92aWRlcyBlcXVpdmFsZW50IGhlYWRlciBjYXBhYmlsaXRpZXMsIGJ1dCBoYXMgYQ0KPj5zcGVj aWZpYw0KPj4gdHJhbnNwb3J0IC4NCj4+DQo+PiBJIGFncmVlIHdlIGNhbqn2dCBlbnVtZXJhdGUg YWxsIHRyYW5zcG9ydHMgYW5kIGdvIG1vZGlmeSB0aGVtIGFsbCBmcm9tDQo+PlNGQw0KPj4gV0cu IEFzIEkgc2hvd2VkIGluIHRoZSB0aGUgb3RoZXIgZGlhZ3JhbSwgd2Ugc2hvdWxkIGRlbW9uc3Ry YXRlIHRoaXMNCj4+IHRyYW5zcG9ydCBpbmRlcGVuZGVuY2UgaW4gdGhlIGZ1bmRhbWVudGFsIGxh eWVycyBvZiB0aGUgSVAgc3RhY2suIFdlDQo+PmhhdmUNCj4+IGV0aGVyIHR5cGUgdGhhdCBjb3Zl cnMgTDIgYW5kIEwzLiBXZSBzaG91bGQgaGF2ZSBvbmUgZm9yIEw0Lg0KPj4NCj4+IFRvIG1lLCBu YXRpdmUgZXRoZXJuZXQgYW5kIG5hdGl2ZSBVRFAgYXJlIGZvdW5kYXRpb25hbC4gVGhlIHJlc3Qg Y2FuIGJlDQo+PiBkb25lIGluIG90aGVyIHdvcmtpbmcgZ3JvdXBzIGFzIHlvdSBzdWdnZXN0LiBX ZSBoYXZlIHRoZSBkZW11eCBpbiBOU0gNCj4+anVzdA0KPj4gYXMgR1VFIGFuZCBHRU5FVkUgdG8g c2lnbmFsIHBheWxvYWRzLg0KPj4NCj4+IEJ0dywgSSBhbSBubyB3YXkgdGllZCB0byA2NjMzLiBX RyBjYW4gYWxsb2NhdGUgYW5vdGhlciBvbmUgYW5kIHRoYXQNCj4+d291bGQNCj4+IGJlIGZpbmUu DQo+PiBTdXJlbmRyYS4NCj4+DQo+PiBPbiA0LzIzLzE1LCA2OjUwIEFNLCAiSm9lbCBNLiBIYWxw ZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IFlvdXIgcXVlc3Rpb25z IGJlbG93IGFyZSBwcmVjaXNlbHkgd2h5IHRoZSBjaGFydGVyIGNhbGxzIGZvciB1cyB0byBiZQ0K Pj4+IHRyYW5zcG9ydCBpbmRlcGVuZGVudC4gIFdlIGFyZSBub3QgaGVyZSB0byBkZWJhdGUgdGhl IGJlbmVmaXRzIGFuZA0KPj4+IGRyYXdiYWNrcyBvZiB2YXJpb3VzIHRyYW5zcG9ydC4gIE5vIG9u ZSBvdGhlciB0aGFuIHlvdSBoYXMgYXNrZWQgdG8NCj4+PiBtYW5kYXRlIG9yIHJlcXVpcmUgYW55 dGhpbmcgYWJvdXQgdGhlIHRyYW5zcG9ydHMuDQo+Pj4NCj4+PiBZb3VycywNCj4+PiBKb2VsDQo+ Pj4NCj4+PiBPbiA0LzIzLzE1IDE6MDAgQU0sIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSB3cm90 ZToNCj4+Pj4gU3VtYW5kcmEsDQo+Pj4gLi4uDQo+Pj4+IEl0IGlzIGZpbmUgdG8gc3VwcG9ydCBT RkMgb3ZlciBWeExBTi4gSG93ZXZlciwgd2h5IG1ha2UgdGhhdCBhDQo+Pj4+IHJlcXVpcmVtZW50 IHRvIGRlcGxveSBTRkMgPw0KPj4+PiBXaHkgYXJlIHdlIHJlcXVpcmluZyBwcm92aXNpb25pbmcg b2YgVk5JcyB0byBkZXBsb3kgU0ZDID8NCj4+Pj4gV2h5IGFyZSB3ZSByZXF1aXJpbmcgVlRFUCBm dW5jdGlvbmFsaXR5LCBldGMgdG8gZGVwbG95IFNGQyA/DQo+Pj4+IFdoeSBhcmUgd2UgYWRkaW5n IG1vcmUgY29zdCB0byBkZXBsb3kgU0ZDID8NCj4+Pj4gV2h5IGFyZSB3ZSBtYWtpbmcgaXQgY29t cGxleCB0byBkZXBsb3kgU0ZDIGluIGEgc2ltcGxlIEwzIG5ldHdvcmsgPw0KPj4+IC4uLg0KPj4N Cj4+DQoNCg== From nobody Thu Apr 23 09:35:44 2015 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 363F61A854B for ; Thu, 23 Apr 2015 09:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 pD0NYjTMin4X for ; Thu, 23 Apr 2015 09:35:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F651A6EED for ; Thu, 23 Apr 2015 09:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8708; q=dns/txt; s=iport; t=1429806941; x=1431016541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F3ioomuPXh1ZNna3ek6lY4lKPyyln8shNFVBYtoYWDw=; b=Cb9jnWq+F9WFs92W47WC4poolPjicu89L7YWMb1sXREcDRLIODm67nnC AeO0lNmYHH/1s7pNV8e/gJ1UWA+gcjg+yD1WPJVRLtjHh+B+h+JBYmL2F H5zRWyRhZNvl5F4HCxQMCQKUkUfOodY5LjEgiZtPPYn0m5TqZmQ/ka98h Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBADSHjlV/51dJa1bgwxSXAWDFcMKCYFHCoYEAhyBGjgUAQEBAQEBAYEKhCEBAQQBAQEaBhEzBwsQAgEIGAICJgICAiULFRACBAEJBAWIKw23cJRpAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoWhFEYGweCaIFFBZFKijWBIoVchyqDVYNOI2CBJxyBUW+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143944088" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 23 Apr 2015 16:35:40 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3NGZdh7031339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 16:35:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 11:35:39 -0500 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , "Thomas D. Nadeau" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAP//8veA Date: Thu, 23 Apr 2015 16:35:39 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@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.4.8.150116 x-originating-ip: [10.24.10.206] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:35:43 -0000 DQoNCk9uIDQvMjMvMTUsIDc6MjIgQU0sICJKaW0gR3VpY2hhcmQgKGpndWljaGFyKSIgPGpndWlj aGFyQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSBKb2VsLA0KPg0KPk9uIDQvMjMvMTUsIDk6NDcg QU0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4NCj4+ SSB0aGluayBJIGFtIG1pc3NpbmcgeW91ciBwb2ludCBUaG9tYXMuICBXZSBoYXZlIGFuIGFncmVl ZCBjb21tb24gaGVhZGVyDQo+PihvciBhdCBsZWFzdCBhbiBhZ3JlZWQgYmFzaXMgYW5kIGV4cGVj dGF0aW9uIHRoYXQgd2Ugd2lsbCBjb21wbGV0ZSB0aGUNCj4+cmVzdCBleHBlZGl0aW91c2x5Likg IFNvIEkgZG8gbm90IHNlZSBhbnkgcmlzayBvZiBlbmRpbmcgdXAgd2l0aCBhDQo+PmRpZmZlcmVu dCBOU0ggaGVhZGVyIGZvciBlYWNoIHRyYW5zcG9ydC4NCj4+DQo+PlRoZSBxdWVzdGlvbiBpcyB3 aGVyZSAvIHdoZW4gZG8gd2Ugc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGRldGFpbHMuDQo+DQo+Smlt PiBvdXIgY2hhcnRlciBkb2VzIG5vdCBjYWxsIGZvciB1cyB0byB3b3JrIG9uIHRoZSB0cmFuc3Bv cnQgZGV0YWlsczsNCj50aG9zZSBzaG91bGQgYmUgYWRkcmVzc2VkIGJ5IHRoZSByZWxldmFudCBX RyBmb3IgYSBnaXZlbiB0cmFuc3BvcnQNCj5wb2ludGluZyB0byBvdXIgU0ZDIGVuY2Fwc3VsYXRp b24gd29yay4NClNLPiBMZXTigJlzIHJlbW92ZSBzZWN0aW9uIDExDQoNCj4NCj4+DQo+PklmIFN1 cmVuZHJhIHdhbnRzIHRvIHRha2UgdGhlIGV4aXN0aW5nLCByZWdpc3RlcmVkLCBjb2RlIHBvaW50 LCBhbmQNCj4+aW5kaWNhdGUgdGhhdCB3aGF0IGl0IGlzIHRvIGNhcnJ5IGlzIE5TSCAoYW5kIHBy ZXN1bWFibHkgdXBkYXRlIGl0IGFnYWluDQo+PndoZW4gdGhlIFJGQyBjb21lcyBvdXQpIHRoYXQg aXMgZmluZS4gIEkgaGF2ZSBubyBvYmplY3Rpb24gcGVyc29uYWxseSwNCj4+YW5kIEkgY2FuIHNl ZSBubyBncm91bmRzIGZvciB0aGUgd29ya2luZyBncm91cCB0byBvYmplY3QuDQo+DQo+SmltPiBm cm9tIGEgY2hhaXJzIHBlcnNwZWN0aXZlIEkgYWxzbyBoYXZlIG5vIG9iamVjdGlvbi4gTGlrZXdp c2UgaWYgb3RoZXINCj5XR8K5cyB3YW50IHRvIGRlZmluZSBpbiB0aGVpciB0cmFuc3BvcnRzIGhv dyBOU0ggaXMgaW5kaWNhdGVkIHRoZW4gdGhhdCBpcw0KPnRoZSByaWdodCBhcHByb2FjaCBhbmQg SSBlbmNvdXJhZ2UgaXQuDQpTSz4gc2FtZSBhcyBhYm92ZQ0KDQo+DQo+Pg0KPj5XaGVyZSBJIGhh dmUgc29tZSBjb25jZXJuIGlzIHdpdGggdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBFdGhlcm5ldCBj b2RlDQo+PnBvaW50IGFuZCB0aGUgVURQIHBvcnQgaW4gdGhlIE5TSCBkb2N1bWVudC4gIFRoYXQg c2VlbXMgdG8gYmUgb3V0c2lkZSBvZg0KPj50aGUgYWdyZWVkIHNjb3BlLg0KPj4NCj4+WW91cnMs DQo+PkpvZWwNCj4+DQo+Pk9uIDQvMjMvMTUgNzowOSBBTSwgVGhvbWFzIEQuIE5hZGVhdSB3cm90 ZToNCj4+Pg0KPj4+IAlJbiBQV0UzIHdlIGV2ZW50dWFsbHkgZGlkIHNwZWNpZnkgZWFjaCBvbmUs IHdlIGp1c3QgZGlkIGl0IGEgbGl0dGxlDQo+Pj5oZXJlIGFuZCBhIGxpdHRsZSB0aGVyZS4gV2Ug aGFkIGEgZGlmZmVyZW50IFBXIGhlYWRlciBhbmQgdHJhbnNwb3J0DQo+Pj5lbmNhcCBkZXBlbmRp bmcgb24gdGhlIHRyYW5zcG9ydCBmb3IgcXVpdGUgYSB3aGlsZSwgd2hpY2ggcHJvdmVkIHRvIGJl DQo+Pj5yYXRoZXIgaW50ZXJlc3RpbmcgaWYgeW91IHdlcmUgaW1wbGVtZW50aW5nIGFueSBvZiBp dC4gV29yc2UgaWYgeW91IHdlcmUNCj4+PmFuIG9wZXJhdG9yIHRyeWluZyB0byBkZXBsb3kgbXVs dGlwbGUgdHlwZXMuIEV2ZW50dWFsbHkgKHRoaW5rIHllYXJzDQo+Pj5sYXRlcikgd2Ugc2V0dGxl ZCBvbiBhIGNvbW1vbiBoZWFkZXIgZm9ybWF0LCBidXQgdGhlcmUgd2VyZSBhbHJlYWR5IHNvbWUN Cj4+PnByZXR0eSBnb29kIHNpemVkIGRlcGxveW1lbnRzIG91dCB0aGVyZSB3aGljaCByZXNpc3Rl ZCB1bmlmeWluZyB0aGUNCj4+PmhlYWRlci4gIFRoZSBsZXNzb246IHRyeSB0byBkbyBpdCByaWdo dCBmcm9tIHRoZSBiZWdpbm5pbmcgdGhpbmtpbmcgdGhhdA0KPj4+dGhlcmUgd2lsbCBiZSBtdWx0 aXBsZSB0cmFuc3BvcnQgdHlwZXMuICBTbyB3aGlsZSBTRkMgbWlnaHQgbm90IGRlZmluZQ0KPj4+ dGhlIHRyYW5zcG9ydCBlbmNhcHMsIHdlIHNob3VsZCBkZWZpbmUgYSBjb21tb24gaGVhZGVyIGZv cm1hdCB0aGF0IHdvcmtzDQo+Pj53aXRoIGF0IGxlYXN0IGEgZmV3IHJlcHJlc2VudGF0aXZlL29i dmlvdXMgb25lcyB0byBzdGFydCwgYW5kIGhhdmUgYQ0KPj4+cGxhbiB0byBkZWZpbmUgb3RoZXJz IGluIGNvbGxhYm9yYXRpb24gd2l0aCBTRkMgdXNpbmcgdGhlIHNhbWUNCj4+Pm1lY2hhbmlzbS4g IEFsc28gY29uc2lkZXIgT0FNIG5vdywgbm90IGhhbGZ3YXkgZG93biB0aGUgcm9hZC4gIFRoYXQN Cj4+PmRvZXNuwrl0IG1lYW4gd2UgbmVlZCB0byByZS1kZWZpbmUgZXhpc3RpbmcgbWVjaGFuaXNt cywgYnV0IGp1c3QgbWFrZQ0KPj4+c3VyZSB0aGF0IGlmIGV4aXN0aQ0KPj4gbg0KPj5nIG9uZXMg ZXhpc3QgKHdoaWNoIEkgdGhpbmsgdGhleSBkbyBCVFcpLCB0aGF0IHRoZXkgYXJlIGluY29ycG9y YXRlZCBpbnRvDQo+PnRoZSB1bmlmaWVkIHBsYW4gc29tZXdoZXJlLg0KPj4+DQo+Pj4gCeKAuVRv bQ0KPj4+DQo+Pj4NCj4+Pj4gT24gQXByIDIyLCAyMDE1OjEwOjM0IFBNLCBhdCAxMDozNCBQTSwg RG9sZ2Fub3csIEFuZHJldyAoQW5kcmV3KQ0KPj4+PjxhbmRyZXcuZG9sZ2Fub3dAYWxjYXRlbC1s dWNlbnQuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4gSSBhZ3JlZS4gSWYgd2Ugc3RhcnQgc3BlY2lm eWluZyBldmVyeSBzaW5nbGUgdHJhbnNwb3J0IHdlIHdpbGwgc3BlbnQNCj4+Pj50aW1lIHRoYXQg b3RoZXJ3aXNlIGNhbiBiZSBzcGVudCBvbiBTRkMtZm9jdXNlZCB3b3JrLg0KPj4+Pg0KPj4+PiBU aGVyZSBpcyBubyBwcm9ibGVtIGZvciBvdGhlciBncm91cHMgdG8gc3BlY2lmeSBob3cgdGhleSB3 YW50IHRvDQo+Pj4+ZW5jb2RlIFNmQyBpbiB0aGVpciB0cmFuc3BvcnQgdHlwZSBhbmQgYnJpbmcg dGhpcyB0byBTRkMgZm9yIHJldmlldy4NCj4+Pj4NCj4+Pj4gQW5kcmV3DQo+Pj4+DQo+Pj4+DQo+ Pj4+PiBPbiBBcHIgMjIsIDIwMTUsIGF0IDU6MzMgQU0sIFBhdWwgUXVpbm4gKHBhdWxxKSA8cGF1 bHFAY2lzY28uY29tPg0KPj4+Pj53cm90ZToNCj4+Pj4+DQo+Pj4+PiBKb2VsLA0KPj4+Pj4NCj4+ Pj4+IEkgY29uY3VyOiB3ZSBkb24ndCB3YW50IHRvIHN0YXJ0IHBpY2tpbmcgdHJhbnNwb3J0cyBo ZXJlLCBpdCBjcmVhdGVzDQo+Pj4+PmFsbCBraW5kcyBvZiBpc3N1ZXMgYW5kIGlzIGNsZWFybHkg b3V0IG9mIHNjb3BlLg0KPj4+Pj4NCj4+Pj4+IFJhdGhlciwgaWYgdGhlcmUncyBhIG5lZWQgZm9y IGEgdHJhbnNwb3J0IHRvIHN1cHBvcnQgTlNILCB0aGVuIHRoZQ0KPj4+Pj53b3JrIGNhbiBvY2N1 ciBpbiB0aGUgYXNzb2NpYXRlZCB3b3JraW5nIGdyb3VwLiAgU28sIGlmIHRoZXJlJ3MgYSBuZWVk DQo+Pj4+PmZvciBNUExTLCB0aGVuIGEgZHJhZnQgY2FuIGJlIHN1Ym1pdHRlZCB0byBNUExTLCBz aW1pbGFybHksIE5WTzMsDQo+Pj4+PkxJU1AsIGV0Yy4gY2FuIGFsbCBoYXZlIE5TSCBzdXBwb3J0 aW5nIGRyYWZ0cy4gIFRoaXMgZW5zdXJlcyBib3RoDQo+Pj4+PmNvbnNpc3RlbmN5IGFuZCBwcm9w ZXIgbGF5ZXJpbmcgd2l0aGluIHRoZSBzY29wZSBvZiB0aG9zZSBwcm90b2NvbHMuDQo+Pj4+Pg0K Pj4+Pj4gT24gdGhlIFVEUCBmcm9udCBzcGVjaWZpY2FsbHksIHRoZXJlJ3MgYSBjbGVhciBtb3Zl IHRvIGEgZXhwbGljaXQNCj4+Pj4+cHJvdG9jb2wgZGVtdXg6VlhMQU4tZ3BlLCBHVUUsIEdFTkVW RSBldGMuICBUaGF0J3MgcHJvYmFibHkgdGhlIGJlc3QNCj4+Pj4+cGxhY2Ugd2F5IHRvIGhhdmUg YSBwcm9wZXIgcHJvdG9jb2wgc3RhY2suDQo+Pj4+Pg0KPj4+Pj4gUGF1bA0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pj4gT24gQXByIDIwLCAyMDE1LCBhdCA3OjM4IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IFRoaXMgc2Vl bXMgYSByZWFzb25hYmxlIGNvdXJzZSwgYnV0IGRlZmluaW5nIGhvdyB0aGUgTlNIIGhlYWRlciBp cw0KPj4+Pj4+Y2FycmllZCBvbiB2YXJpb3VzIHRyYW5zcG9ydHMgc2VlbXMgbm90IHRvIGJlIGlu IG15IHJlYWRpbmcgb2YgdGhlIFdHDQo+Pj4+Pj5zY29wZS4NCj4+Pj4+Pg0KPj4+Pj4+IEluIHBh cnRpY3VsYXIsIGl0IHNlZW1zIGEgYml0IG9kZCB0byBkZWZpbmUgdGhlIG1lY2hhbmlzbXMgZm9y IHNvbWUNCj4+Pj4+PnJhbmRvbWx5IHNlbGVjdGVkIHN1YnNldCBvZiB0cmFuc3BvcnRzLiAgVGh1 cywgd2hpbGUgdGhlIG9taXNzaW9uIGlzDQo+Pj4+Pj5hcmd1YWJseSBhIGJ1ZyBpbiB0aGUgY2hh cnRlciwgaXQgaXMgZXF1YWxseSBhIGJ1ZyB0byBkZWNpZGUgd2Ugd2lsbA0KPj4+Pj4+ZGVzY3Jp YmUgaG93IHRvIGhhbmRsZSBzb21lIHRyYW5zcG9ydHMuICBBbmQgZG8gd2UgcmVhbGx5IHdhbnQg dG8NCj4+Pj4+PmhhdmUgdG8gcHJvZHVjZSBkb2N1bWVudHMgZm9yIGVhY2ggYW5kIGV2ZXJ5IHRy YW5zcG9ydD8NCj4+Pj4+Pg0KPj4+Pj4+IFlvdXJzLA0KPj4+Pj4+IEpvZWwNCj4+Pj4+Pg0KPj4+ Pj4+PiBPbiA0LzIwLzE1IDc6MDIgUE0sIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSB3cm90ZToN Cj4+Pj4+Pj4gSGVsbG8gQ2hhaXJzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGUgaGFsbG1hcmsgb2Yg TlNIIGlzIHRoYXQgaXQgY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgbWFueQ0KPj4+Pj4+PmRpZmZl cmVudA0KPj4+Pj4+PiBvdmVybGF5cy4gVG93YXJkcyB0aGF0LCB3ZSBhbHJlYWR5IGhhdmUgYW4g ZXRoZXItdHlwZSB0aGF0IGFsbG93cw0KPj4+Pj4+PnVzIHRvDQo+Pj4+Pj4+IGNhcnJ5IE5TSCBu YXRpdmVseSBvdmVyIEV0aGVybmV0IGFuZCBub24tbmF0aXZlbHkgb3ZlciBVRFAgwq0gdmlhDQo+ Pj4+Pj4+IFZYTEFOLUdQRS4gR2l2ZW4gdGhhdCBVRFAgaXMgdGhlIGJhc2ljLCBzaW1wbGVzdCBh bmQgbW9zdCBjb21tb24NCj4+Pj4+Pj5vdmVybGF5DQo+Pj4+Pj4+IHRyYW5zcG9ydHMsIHdlIHNo b3VsZCBlbmFibGUgdHJhbnNwb3J0aW5nIE5TSCBuYXRpdmVseSBvdmVyIFVEUCwgYXMNCj4+Pj4+ Pj53ZWxsLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJcyB0aGVyZSBhIHByb2Nlc3MgZm9yIHJlcXVlc3Rp bmcgYSBVRFAgcG9ydCMgZm9yIE5TSCBmb3Igd29ya2luZw0KPj4+Pj4+Pmdyb3VwDQo+Pj4+Pj4+ IGRyYWZ0cyA/IEFsdGVybmF0aXZlbHksIGluIHRoZSBzcGlyaXQgb2Ygc2F2aW5nIHRoZSBVRFAg bmFtZSBzcGFjZSwNCj4+Pj4+Pj5pcw0KPj4+Pj4+PiBpdCBva2F5IHRvIHRyYW5zZmVyIGEgcHJl LWFsbG9jYXRlZCBidXQgdW4tdXNlZCBVRFAgcG9ydCMgPyBBcyBwYXJ0DQo+Pj4+Pj4+b2YNCj4+ Pj4+Pj4gbXkgd29yaywgSSBoYWQgVURQIHBvcnQjIDY2MzMgYWxsb2NhdGVkIGEgY291cGxlIG9m IHllYXJzIGFnbyBmb3IgYQ0KPj4+Pj4+PiBzaW1pbGFyIHB1cnBvc2UuIFRoaXMgbnVtYmVyIGlz IHVudXNlZCBhbmQgSSB3b3VsZCBiZSBnbGFkIHRvDQo+Pj4+Pj4+dHJhbnNmZXINCj4+Pj4+Pj4g dGhpcyBvdmVyIHRvIE5TSC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBTdXJl bmRyYS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+ PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNmY0BpZXRm Lm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4NCj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxp bmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4+Pj4NCj4+Pg0KPg0KDQo= From nobody Thu Apr 23 09:36:19 2015 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 4DC961A6F34 for ; Thu, 23 Apr 2015 09:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 IM-ijCrypx85 for ; Thu, 23 Apr 2015 09:36:17 -0700 (PDT) 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 4C22E1A1B24 for ; Thu, 23 Apr 2015 09:36:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3B7A0250ADE for ; Thu, 23 Apr 2015 09:36:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-96-97.public.wayport.net [64.134.96.97]) (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 E837D250A6C for ; Thu, 23 Apr 2015 09:36:07 -0700 (PDT) Message-ID: <55391F44.10508@joelhalpern.com> Date: Thu, 23 Apr 2015 12:35:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 CC: "sfc@ietf.org" References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:36:18 -0000 That would be fine with me. Yours, Joel On 4/23/15 12:32 PM, Surendra Kumar (smkumar) wrote: > If the WG agrees with this, then there is no place for section 11 in NSH > draft and we should remove it! > Why document a specific set of transports ? > > Surendra. > > On 4/23/15, 9:13 AM, "Joel M. Halpern" wrote: > >> One of the reasons why I appreciated the way the charter was drawn is >> that arguing about which transports are "foundational" does not actually >> help anyone. I understand why you consider those "foundational" Given >> that it is out of scope for the group, and provides no benefit to the >> group, I would prefer not to get into a series of debates about which >> ones are actually foundational. >> >> As a corollary, I see no reason to use a different UDP port than the one >> you have. I just don't see it as the WG job to pick. >> >> Yours, >> Joel >> >> On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote: >>> Joel, >>> >>> Ive always been saying that the strong point of NSH is that it is >>> transport independent, unlike GENEVE (in nvo3 archives), for instance. >>> Which in fact provides equivalent header capabilities, but has a >>> specific >>> transport . >>> >>> I agree we cant enumerate all transports and go modify them all from >>> SFC >>> WG. As I showed in the the other diagram, we should demonstrate this >>> transport independence in the fundamental layers of the IP stack. We >>> have >>> ether type that covers L2 and L3. We should have one for L4. >>> >>> To me, native ethernet and native UDP are foundational. The rest can be >>> done in other working groups as you suggest. We have the demux in NSH >>> just >>> as GUE and GENEVE to signal payloads. >>> >>> Btw, I am no way tied to 6633. WG can allocate another one and that >>> would >>> be fine. >>> Surendra. >>> >>> On 4/23/15, 6:50 AM, "Joel M. Halpern" wrote: >>> >>>> Your questions below are precisely why the charter calls for us to be >>>> transport independent. We are not here to debate the benefits and >>>> drawbacks of various transport. No one other than you has asked to >>>> mandate or require anything about the transports. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: >>>>> Sumandra, >>>> ... >>>>> It is fine to support SFC over VxLAN. However, why make that a >>>>> requirement to deploy SFC ? >>>>> Why are we requiring provisioning of VNIs to deploy SFC ? >>>>> Why are we requiring VTEP functionality, etc to deploy SFC ? >>>>> Why are we adding more cost to deploy SFC ? >>>>> Why are we making it complex to deploy SFC in a simple L3 network ? >>>> ... >>> >>> > From nobody Thu Apr 23 09:45:23 2015 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 E8AD71AC3CD for ; Thu, 23 Apr 2015 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cntP1wn7M1uc for ; Thu, 23 Apr 2015 09:45:20 -0700 (PDT) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BE01AC431 for ; Thu, 23 Apr 2015 09:45:07 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0224.002; Thu, 23 Apr 2015 09:45:06 -0700 From: Ron Parker To: "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1XBBuAgADGDwCAAD09gIAA6O4A//+kgEOAAe4BgIAAk+eAgAAmWQCAAAGGgIAABVwAgAAA2QD//41msg== Date: Thu, 23 Apr 2015 16:45:05 +0000 Message-ID: <86CBC3A8-1040-4CB1-A1BC-C3E62E4E379C@affirmednetworks.com> References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> ,<55391F44.10508@joelhalpern.com> In-Reply-To: <55391F44.10508@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:45:22 -0000 Agree.=20 Ron > On Apr 23, 2015, at 6:36 PM, Joel M. Halpern wrote: >=20 > That would be fine with me. > Yours, > Joel >=20 >> On 4/23/15 12:32 PM, Surendra Kumar (smkumar) wrote: >> If the WG agrees with this, then there is no place for section 11 in NSH >> draft and we should remove it! >> Why document a specific set of transports ? >>=20 >> Surendra. >>=20 >>> On 4/23/15, 9:13 AM, "Joel M. Halpern" wrote: >>>=20 >>> One of the reasons why I appreciated the way the charter was drawn is >>> that arguing about which transports are "foundational" does not actuall= y >>> help anyone. I understand why you consider those "foundational" Given >>> that it is out of scope for the group, and provides no benefit to the >>> group, I would prefer not to get into a series of debates about which >>> ones are actually foundational. >>>=20 >>> As a corollary, I see no reason to use a different UDP port than the on= e >>> you have. I just don't see it as the WG job to pick. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote: >>>> Joel, >>>>=20 >>>> I=B9ve always been saying that the strong point of NSH is that it is >>>> transport independent, unlike GENEVE (in nvo3 archives), for instance. >>>> Which in fact provides equivalent header capabilities, but has a >>>> specific >>>> transport . >>>>=20 >>>> I agree we can=B9t enumerate all transports and go modify them all fro= m >>>> SFC >>>> WG. As I showed in the the other diagram, we should demonstrate this >>>> transport independence in the fundamental layers of the IP stack. We >>>> have >>>> ether type that covers L2 and L3. We should have one for L4. >>>>=20 >>>> To me, native ethernet and native UDP are foundational. The rest can b= e >>>> done in other working groups as you suggest. We have the demux in NSH >>>> just >>>> as GUE and GENEVE to signal payloads. >>>>=20 >>>> Btw, I am no way tied to 6633. WG can allocate another one and that >>>> would >>>> be fine. >>>> Surendra. >>>>=20 >>>>> On 4/23/15, 6:50 AM, "Joel M. Halpern" wrote: >>>>>=20 >>>>> Your questions below are precisely why the charter calls for us to be >>>>> transport independent. We are not here to debate the benefits and >>>>> drawbacks of various transport. No one other than you has asked to >>>>> mandate or require anything about the transports. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: >>>>>> Sumandra, >>>>> ... >>>>>> It is fine to support SFC over VxLAN. However, why make that a >>>>>> requirement to deploy SFC ? >>>>>> Why are we requiring provisioning of VNIs to deploy SFC ? >>>>>> Why are we requiring VTEP functionality, etc to deploy SFC ? >>>>>> Why are we adding more cost to deploy SFC ? >>>>>> Why are we making it complex to deploy SFC in a simple L3 network ? >>>>> ... >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Apr 23 09:51:41 2015 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 A46A41ACCFA for ; Thu, 23 Apr 2015 09:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 3iy0f6_Hwd83 for ; Thu, 23 Apr 2015 09:51:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E621ACC85 for ; Thu, 23 Apr 2015 09:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3810; q=dns/txt; s=iport; t=1429807897; x=1431017497; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zTMQe8Gj2BtjvLIYbFxDqB/oVRVSZgE8Sx5MrWHy/jo=; b=VUvD7vj+kEg7ixmxeWaSw67ElhZ1PT3FhSFdjBRrijmSLyIM2nXlN0bs D7p/+CBNqx1CzKqdQ5CWf5nuHRFHxWqo3lnYXJKjv1xINLhEznPP2hWka AiiDSXG3QY6oJu1CXAeXho3nc57E62xz186OKbsV3x04tyGBaWAU4kdfd A=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBQAWIjlV/5NdJa1bgwxSUAwFgxXCJII2CoYEAoE2TAEBAQEBAYELhCABAQEDAQEBASBLCwULAgEIGCoCAicLJQIEDgUOiBUIDbd5lGoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs3hCBkB4JoL4EWBZFKgXKBN4cMgSKQW4NOI2CDFG+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="asc'?scan'208";a="414313309" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 23 Apr 2015 16:51:36 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t3NGpaNk022104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 16:51:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 11:51:35 -0500 From: "Carlos Pignataro (cpignata)" To: "Surendra Kumar (smkumar)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgIABCUKA//+w/gCAAHbhgP//kACAgAB6xQA= Date: Thu, 23 Apr 2015 16:52:14 +0000 Message-ID: <88423CA0-502D-488A-9C96-75B73026D0ED@cisco.com> References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.58] Content-Type: multipart/signed; boundary="Apple-Mail=_10C80DAD-9DD5-40BB-9928-074D3F9F5AD3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Tom Nadeau , Sumandra Majee , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 16:51:39 -0000 --Apple-Mail=_10C80DAD-9DD5-40BB-9928-074D3F9F5AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =E2=80=9CThere is no place=E2=80=9D is incorrect. Section 11 is titled = =E2=80=9CNSH Encapsulation Examples=E2=80=9D. =E2=80=94 Carlos. > On Apr 23, 2015, at 12:32 PM, Surendra Kumar (smkumar) = wrote: >=20 > If the WG agrees with this, then there is no place for section 11 in = NSH > draft and we should remove it! > Why document a specific set of transports ? >=20 > Surendra. >=20 > On 4/23/15, 9:13 AM, "Joel M. Halpern" wrote: >=20 >> One of the reasons why I appreciated the way the charter was drawn is >> that arguing about which transports are "foundational" does not = actually >> help anyone. I understand why you consider those "foundational" = Given >> that it is out of scope for the group, and provides no benefit to the >> group, I would prefer not to get into a series of debates about which >> ones are actually foundational. >>=20 >> As a corollary, I see no reason to use a different UDP port than the = one >> you have. I just don't see it as the WG job to pick. >>=20 >> Yours, >> Joel >>=20 >> On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote: >>> Joel, >>>=20 >>> I=C2=B9ve always been saying that the strong point of NSH is that it = is >>> transport independent, unlike GENEVE (in nvo3 archives), for = instance. >>> Which in fact provides equivalent header capabilities, but has a >>> specific >>> transport . >>>=20 >>> I agree we can=C2=B9t enumerate all transports and go modify them = all from >>> SFC >>> WG. As I showed in the the other diagram, we should demonstrate this >>> transport independence in the fundamental layers of the IP stack. We >>> have >>> ether type that covers L2 and L3. We should have one for L4. >>>=20 >>> To me, native ethernet and native UDP are foundational. The rest can = be >>> done in other working groups as you suggest. We have the demux in = NSH >>> just >>> as GUE and GENEVE to signal payloads. >>>=20 >>> Btw, I am no way tied to 6633. WG can allocate another one and that >>> would >>> be fine. >>> Surendra. >>>=20 >>> On 4/23/15, 6:50 AM, "Joel M. Halpern" wrote: >>>=20 >>>> Your questions below are precisely why the charter calls for us to = be >>>> transport independent. We are not here to debate the benefits and >>>> drawbacks of various transport. No one other than you has asked to >>>> mandate or require anything about the transports. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: >>>>> Sumandra, >>>> ... >>>>> It is fine to support SFC over VxLAN. However, why make that a >>>>> requirement to deploy SFC ? >>>>> Why are we requiring provisioning of VNIs to deploy SFC ? >>>>> Why are we requiring VTEP functionality, etc to deploy SFC ? >>>>> Why are we adding more cost to deploy SFC ? >>>>> Why are we making it complex to deploy SFC in a simple L3 network = ? >>>> ... >>>=20 >>>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_10C80DAD-9DD5-40BB-9928-074D3F9F5AD3 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 iEYEARECAAYFAlU5IxcACgkQtfDPGTp3USyJvACgm2b5SF4EF7uTCDiXN/Yx94js ms4AnRGI1q9SPP31ZDQvQmsz9z7P3cKx =EDlT -----END PGP SIGNATURE----- --Apple-Mail=_10C80DAD-9DD5-40BB-9928-074D3F9F5AD3-- From nobody Thu Apr 23 10:10:23 2015 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 A3F241ACDB1 for ; Thu, 23 Apr 2015 10:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Ba4GYneBOeh7 for ; Thu, 23 Apr 2015 10:10:21 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AE61ACDAF for ; Thu, 23 Apr 2015 10:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4858; q=dns/txt; s=iport; t=1429809020; x=1431018620; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3CXKV/n0HeEhilHZvdJi7fCgYntudKO+wIZGYWLcn8A=; b=TNfbkhcDHZE5teMLMrNlYeL/9l3Td+Gw30EyctLNi2SVG6609D/ospHz eoGSNNniewylr6c6LJpMY0jqVGVce01FjWvDa/jfYN9LF5N3wYddYzFha ZSrExmRLSYmcAKtasp4MYaLEF/jCQQ7N8d/ilFlaF+dS3Y3Gu9rO0lbru 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBADNJjlV/4oNJK1bgwxSUAwFgxXDCgmBRwqGBAIcgRo4FAEBAQEBAQGBCoQhAQEEAQEBMToLEAIBCBgEKAICJQslAgQOBYgrDZp5nHoGlGwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEbihyEIDEzB4JigUsFjyqCIIo1gSKQW4NOI2CDFG+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,632,1422921600"; d="scan'208";a="143929621" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 23 Apr 2015 17:10:19 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3NHAJCs021917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 17:10:19 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 12:10:19 -0500 From: "Surendra Kumar (smkumar)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgIABCUKA//+w/gCAAHbhgP//kACAgAB6xQD//4/fAA== Date: Thu, 23 Apr 2015 17:10:18 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> <88423CA0-502D-488A-9C96-75B73026D0ED@cisco.com> In-Reply-To: <88423CA0-502D-488A-9C96-75B73026D0ED@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.10.206] Content-Type: text/plain; charset="euc-kr" Content-ID: <807C882D1EC17849BE8AEDF9DB11FA1C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Tom Nadeau , Sumandra Majee , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 17:10:22 -0000 VGhhdCBpcyBhIGNvbnZlbmllbmNlIGFyZ3VtZW50LiBUaGF0IGlzIGEgYmlhcyBpbiBpdHNlbGYu DQpUaGVuIEkgd291bGQgYXJndWUsIHJlcXVlc3QgYSBVRFAgcG9ydCMgZnJvbSBJQU5BIGFuZCBk b2N1bWVudCBpdCBpbiBOU0gNCmFuZCBzaG93IGFuIGV4YW1wbGUgb2YgaXQuDQoNClRoZXJlIGlz IHByb2JhYmx5IGEgcmVhc29uIGFsbCBvZiB0aGUgYmVsb3cgdXNlIE9OTFkgVURQIQ0KR0VORVYg ICAgOiBVRFAjIDYwODENCkdVRSAgICAgIDogVURQIyA2MDgwDQpWeExBTiAgICA6IFVEUCMgNDc5 MA0KVnhMQU4tZ3BlOiBVRFAjIDQ3ODkNCg0KQW5kIHlldCwgd2UgYXJlIGluIGRlbmlhbC4NCg0K U3VyZW5kcmEuDQoNCk9uIDQvMjMvMTUsIDk6NTIgQU0sICJDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkiIDxjcGlnbmF0YUBjaXNjby5jb20+DQp3cm90ZToNCg0KPqGwVGhlcmUgaXMgbm8gcGxh Y2WhsSBpcyBpbmNvcnJlY3QuIFNlY3Rpb24gMTEgaXMgdGl0bGVkIKGwTlNIIEVuY2Fwc3VsYXRp b24NCj5FeGFtcGxlc6GxLg0KPg0KPqGqIENhcmxvcy4NCj4NCj4+IE9uIEFwciAyMywgMjAxNSwg YXQgMTI6MzIgUE0sIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKQ0KPj48c21rdW1hckBjaXNjby5j b20+IHdyb3RlOg0KPj4gDQo+PiBJZiB0aGUgV0cgYWdyZWVzIHdpdGggdGhpcywgdGhlbiB0aGVy ZSBpcyBubyBwbGFjZSBmb3Igc2VjdGlvbiAxMSBpbiBOU0gNCj4+IGRyYWZ0IGFuZCB3ZSBzaG91 bGQgcmVtb3ZlIGl0IQ0KPj4gV2h5IGRvY3VtZW50IGEgc3BlY2lmaWMgc2V0IG9mIHRyYW5zcG9y dHMgPw0KPj4gDQo+PiBTdXJlbmRyYS4NCj4+IA0KPj4gT24gNC8yMy8xNSwgOToxMyBBTSwgIkpv ZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gT25l IG9mIHRoZSByZWFzb25zIHdoeSBJIGFwcHJlY2lhdGVkIHRoZSB3YXkgdGhlIGNoYXJ0ZXIgd2Fz IGRyYXduIGlzDQo+Pj4gdGhhdCBhcmd1aW5nIGFib3V0IHdoaWNoIHRyYW5zcG9ydHMgYXJlICJm b3VuZGF0aW9uYWwiIGRvZXMgbm90DQo+Pj5hY3R1YWxseQ0KPj4+IGhlbHAgYW55b25lLiAgSSB1 bmRlcnN0YW5kIHdoeSB5b3UgY29uc2lkZXIgdGhvc2UgImZvdW5kYXRpb25hbCIgIEdpdmVuDQo+ Pj4gdGhhdCBpdCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBncm91cCwgYW5kIHByb3ZpZGVzIG5v IGJlbmVmaXQgdG8gdGhlDQo+Pj4gZ3JvdXAsIEkgd291bGQgcHJlZmVyIG5vdCB0byBnZXQgaW50 byBhIHNlcmllcyBvZiBkZWJhdGVzIGFib3V0IHdoaWNoDQo+Pj4gb25lcyBhcmUgYWN0dWFsbHkg Zm91bmRhdGlvbmFsLg0KPj4+IA0KPj4+IEFzIGEgY29yb2xsYXJ5LCBJIHNlZSBubyByZWFzb24g dG8gdXNlIGEgZGlmZmVyZW50IFVEUCBwb3J0IHRoYW4gdGhlDQo+Pj5vbmUNCj4+PiB5b3UgaGF2 ZS4gIEkganVzdCBkb24ndCBzZWUgaXQgYXMgdGhlIFdHIGpvYiB0byBwaWNrLg0KPj4+IA0KPj4+ IFlvdXJzLA0KPj4+IEpvZWwNCj4+PiANCj4+PiBPbiA0LzIzLzE1IDEyOjA3IFBNLCBTdXJlbmRy YSBLdW1hciAoc21rdW1hcikgd3JvdGU6DQo+Pj4+IEpvZWwsDQo+Pj4+IA0KPj4+PiBJqfZ2ZSBh bHdheXMgYmVlbiBzYXlpbmcgdGhhdCB0aGUgc3Ryb25nIHBvaW50IG9mIE5TSCBpcyB0aGF0IGl0 IGlzDQo+Pj4+IHRyYW5zcG9ydCBpbmRlcGVuZGVudCwgdW5saWtlIEdFTkVWRSAoaW4gbnZvMyBh cmNoaXZlcyksIGZvciBpbnN0YW5jZS4NCj4+Pj4gV2hpY2ggaW4gZmFjdCBwcm92aWRlcyBlcXVp dmFsZW50IGhlYWRlciBjYXBhYmlsaXRpZXMsIGJ1dCBoYXMgYQ0KPj4+PiBzcGVjaWZpYw0KPj4+ PiB0cmFuc3BvcnQgLg0KPj4+PiANCj4+Pj4gSSBhZ3JlZSB3ZSBjYW6p9nQgZW51bWVyYXRlIGFs bCB0cmFuc3BvcnRzIGFuZCBnbyBtb2RpZnkgdGhlbSBhbGwgZnJvbQ0KPj4+PiBTRkMNCj4+Pj4g V0cuIEFzIEkgc2hvd2VkIGluIHRoZSB0aGUgb3RoZXIgZGlhZ3JhbSwgd2Ugc2hvdWxkIGRlbW9u c3RyYXRlIHRoaXMNCj4+Pj4gdHJhbnNwb3J0IGluZGVwZW5kZW5jZSBpbiB0aGUgZnVuZGFtZW50 YWwgbGF5ZXJzIG9mIHRoZSBJUCBzdGFjay4gV2UNCj4+Pj4gaGF2ZQ0KPj4+PiBldGhlciB0eXBl IHRoYXQgY292ZXJzIEwyIGFuZCBMMy4gV2Ugc2hvdWxkIGhhdmUgb25lIGZvciBMNC4NCj4+Pj4g DQo+Pj4+IFRvIG1lLCBuYXRpdmUgZXRoZXJuZXQgYW5kIG5hdGl2ZSBVRFAgYXJlIGZvdW5kYXRp b25hbC4gVGhlIHJlc3QgY2FuDQo+Pj4+YmUNCj4+Pj4gZG9uZSBpbiBvdGhlciB3b3JraW5nIGdy b3VwcyBhcyB5b3Ugc3VnZ2VzdC4gV2UgaGF2ZSB0aGUgZGVtdXggaW4gTlNIDQo+Pj4+IGp1c3QN Cj4+Pj4gYXMgR1VFIGFuZCBHRU5FVkUgdG8gc2lnbmFsIHBheWxvYWRzLg0KPj4+PiANCj4+Pj4g QnR3LCBJIGFtIG5vIHdheSB0aWVkIHRvIDY2MzMuIFdHIGNhbiBhbGxvY2F0ZSBhbm90aGVyIG9u ZSBhbmQgdGhhdA0KPj4+PiB3b3VsZA0KPj4+PiBiZSBmaW5lLg0KPj4+PiBTdXJlbmRyYS4NCj4+ Pj4gDQo+Pj4+IE9uIDQvMjMvMTUsIDY6NTAgQU0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9l bGhhbHBlcm4uY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+PiBZb3VyIHF1ZXN0aW9ucyBiZWxvdyBh cmUgcHJlY2lzZWx5IHdoeSB0aGUgY2hhcnRlciBjYWxscyBmb3IgdXMgdG8gYmUNCj4+Pj4+IHRy YW5zcG9ydCBpbmRlcGVuZGVudC4gIFdlIGFyZSBub3QgaGVyZSB0byBkZWJhdGUgdGhlIGJlbmVm aXRzIGFuZA0KPj4+Pj4gZHJhd2JhY2tzIG9mIHZhcmlvdXMgdHJhbnNwb3J0LiAgTm8gb25lIG90 aGVyIHRoYW4geW91IGhhcyBhc2tlZCB0bw0KPj4+Pj4gbWFuZGF0ZSBvciByZXF1aXJlIGFueXRo aW5nIGFib3V0IHRoZSB0cmFuc3BvcnRzLg0KPj4+Pj4gDQo+Pj4+PiBZb3VycywNCj4+Pj4+IEpv ZWwNCj4+Pj4+IA0KPj4+Pj4gT24gNC8yMy8xNSAxOjAwIEFNLCBTdXJlbmRyYSBLdW1hciAoc21r dW1hcikgd3JvdGU6DQo+Pj4+Pj4gU3VtYW5kcmEsDQo+Pj4+PiAuLi4NCj4+Pj4+PiBJdCBpcyBm aW5lIHRvIHN1cHBvcnQgU0ZDIG92ZXIgVnhMQU4uIEhvd2V2ZXIsIHdoeSBtYWtlIHRoYXQgYQ0K Pj4+Pj4+IHJlcXVpcmVtZW50IHRvIGRlcGxveSBTRkMgPw0KPj4+Pj4+IFdoeSBhcmUgd2UgcmVx dWlyaW5nIHByb3Zpc2lvbmluZyBvZiBWTklzIHRvIGRlcGxveSBTRkMgPw0KPj4+Pj4+IFdoeSBh cmUgd2UgcmVxdWlyaW5nIFZURVAgZnVuY3Rpb25hbGl0eSwgZXRjIHRvIGRlcGxveSBTRkMgPw0K Pj4+Pj4+IFdoeSBhcmUgd2UgYWRkaW5nIG1vcmUgY29zdCB0byBkZXBsb3kgU0ZDID8NCj4+Pj4+ PiBXaHkgYXJlIHdlIG1ha2luZyBpdCBjb21wbGV4IHRvIGRlcGxveSBTRkMgaW4gYSBzaW1wbGUg TDMgbmV0d29yayA/DQo+Pj4+PiAuLi4NCj4+Pj4gDQo+Pj4+IA0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPg0KDQo= From nobody Thu Apr 23 10:14:59 2015 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 002261ACDBC; Thu, 23 Apr 2015 10:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 xy2gqxZa2nZv; Thu, 23 Apr 2015 10:13:03 -0700 (PDT) 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 5311B1ACDA7; Thu, 23 Apr 2015 10:13:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRT49007; Thu, 23 Apr 2015 17:12:59 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Apr 2015 18:12:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 23 Apr 2015 10:12:53 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , "i2rs@ietf.org" , "netmod@ietf.org" , "sacm@ietf.org" , "pcp@ietf.org" , "sfc@ietf.org" , "dots@ietf.org" , "opsawg@ietf.org" , "ops-dir@ietf.org" , "ops-ads@tools.ietf.org" Thread-Topic: I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution Thread-Index: AQHQfeL7u793L89A7kyGIFebPlU0DZ1aykFw Date: Thu, 23 Apr 2015 17:12:53 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C09765@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 23 Apr 2015 10:14:57 -0700 Cc: "mile@ietf.org" Subject: [sfc] I2NSF: Interface to network security functions : problem-statement, framework, use cases, and potential solution 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, 23 Apr 2015 17:13:05 -0000 VGhlICJpMm5zZi1wcm9ibGVtLXN0YXRlbWVudCIgZHJhZnQgZGVzY3JpYmVzIHRoZSBtb3RpdmF0 aW9uIGFuZCB0aGUgcHJvYmxlbSBzcGFjZSBhc3NvY2lhdGVkIHdpdGggc2VydmljZSBwcm92aWRl cnMgcHJvdmlkaW5nIGhvc3RlZCBzZWN1cml0eSBzb2x1dGlvbnMgdG8gZGVsaXZlciBjb3N0LWVm ZmVjdGl2ZSBtYW5hZ2VkIHNlY3VyaXR5IHNlcnZpY2VzIHRvIGVudGVycHJpc2UgY3VzdG9tZXJz IHdobyBkb24ndCBvd24gb3IgaGF2ZSB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIG9uIHRoZWlyIHBy ZW1pc2VzLiANCg0KU2luY2UgdGhlIGkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAxIGRyYWZ0LCB0 aHJlZSBJMk5TRiB1c2UgY2FzZSBkcmFmdHMsIGEgZ2FwIGFuYWx5c2lzIGRyYWZ0LCBhbmQgYSBw YWNrZXQtYmFzZWQgcGFyYWRpZ20gZHJhZnQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4gDQpXZSByZW1v dmVkIHRoZSByZWR1bmRhbnQgY29udGVudCBmcm9tIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dCwgbWFraW5nIGl0IGZvY3VzIGV4Y2x1c2l2ZWx5IG9uIHRoZSBwcm9ibGVtIHNwYWNlIG9mIHNl Y3VyaXR5IGZ1bmN0aW9ucyBub3QgaG9zdGVkIG9uIGN1c3RvbWVyJ3MgcHJlbWlzZXMgYW5kIGJl aW5nIGRpc3RyaWJ1dGVkIChkcml2ZW4gYnkgTkZWIGFuZCBob3N0ZWQgc2VjdXJpdHkgc2Vydmlj ZXMpLg0KDQpJbiBjb25qdW5jdGlvbiB3aXRoIHRoZSAiaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnRz IiwgdGhlcmUgYXJlIGFsc28gSTJOU0YgZnJhbWV3b3JrIGRyYWZ0LCBwb3RlbnRpYWwgSTJOU0Yg c29sdXRpb24gZHJhZnQsIHVzZSBjYXNlIGRyYWZ0cyAodW5kZXIgcHJvY2VzcyBvZiBtZXJnaW5n KSwgZ2FwLWFuYWx5c2lzIGFuZCBkYXRhIG1vZGVsaW5nIGRyYWZ0Og0KDQpodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1lcmdlZC1pMm5zZi1mcmFtZXdvcmsvDQoNCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9wZXotaTJuc2YtcGFja2V0Lw0KDQpo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpYS1pMm5zZi1jYXBhYmlsaXR5 LWludGVyZmFjZS1pbS8gKG5ldyByZXZpc2lvbiBpcyB0byBiZSB1cGxvYWRlZCBzb29uIHRvIHJl ZmxlY3QgdGhlIGRpc2N1c3Npb24gb2YgRjJGIG1lZXRpbmdzIGF0IElFVEY5MiBEYWxsYXMpLiAN Cg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3ItaTJuc2YtYWNj ZXNzLXVzZWNhc2VzLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xaS1p Mm5zZi1hY2Nlc3MtbmV0d29yay11c2VjYXNlLw0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16YXJueS1pMm5zZi1kYXRhLWNlbnRlci11c2UtY2FzZXMvDQoNCmh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctZ2FwLWFuYWx5c2lzLw0KDQpJMk5T RiBpcyBhYm91dCBzZWN1cml0eSBmdW5jdGlvbnMgbWFuYWdlbWVudC4gVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2UgYnV0IGluc3RlYWQgaG9z dGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2ggaG93IHRvIGNvbW11 bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkgcG9saWNpZXMgdG8gTlNGIGFuZCBob3cgdG8gZ2V0IHBl cmZvcm1hbmNlIGRhdGEgb3IgcmVwb3J0IG91dCBvZiBOU0YuICANCg0KQWxzbyBjb3B5IHRvIHRo ZSBJMk5TRiByZWxldmFudCBJRVRGIFdHczogSTJSUywgTkVUTU9ELCBORVRDT05GLCBTQUNNLCBN SUxFLCBQQ1AsIERPVFMsIFNGQywgYW5kIE9wQXJlYXMsIGluIGhvcGUgdG8gZ2V0IGZlZWRiYWNr IGFuZCBzdWdnZXN0aW9ucyBmcm9tIHdpZGVyIGF1ZGllbmNlLiANCg0KVGhhbmtzIGluIGFkdmFu Y2UsIA0KDQpMaW5kYSBEdW5iYXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTE6MzEgQU0NClRvOiBNb2hhbWVk IEJvdWNhZGFpcjsgU2hhaWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBDaHJpc3RpYW4g SmFjcXVlbmV0OyBNeW8gWmFybnk7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE15byBaYXJueTsgU2hh aWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBNb2hhbWVkIEJvdWNhZGFpcg0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxl bS1zdGF0ZW1lbnQtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWR1bmJh ci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgTGluZGEgRHVuYmFyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudA0KUmV2aXNp b246CTAzDQpUaXRsZToJCUludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyAo STJOU0YpIFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE1LTA0LTIzDQpHcm91 cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9i bGVtLXN0YXRlbWVudC0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHVuYmFyLWkybnNm LXByb2JsZW0tc3RhdGVtZW50LTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTAzDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1vdGl2YXRpb24gYW5k IHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3INCiAgIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3Vy aXR5IEZ1bmN0aW9ucyAoSTJOU0YpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Thu Apr 23 10:33:58 2015 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 7CBFD1B30FB for ; Thu, 23 Apr 2015 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 fXaLeRGnAE7X for ; Thu, 23 Apr 2015 10:33:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370321B3108 for ; Thu, 23 Apr 2015 10:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5590; q=dns/txt; s=iport; t=1429810385; x=1431019985; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KGTNvGPZgY/GW4ireGR2LYpZvuxDJ528LQCm4/WfN8Y=; b=AIO9wvytzq4KFTKGTMebHxJoFFQ7rVjtVyZfoG93ChTef7NsCHTDNrXT GGiDQ2DBYN5hWj1NeF4FZSE32avWvbtIQTi9Wbp+N1O1Ccny+Oqv8Bu7g pEW1AZ3sf3wRFAdNVtaEW8LxpNKqpdCub79IaCaQ5+7iR1fZaBpl+fD0L Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBQBtLDlV/5JdJa1bgwxSUAwFgxXCJII2CoYEAoE2TAEBAQEBAYELhCABAQEDAQEBASBEBwsFCwIBCBgqAgInCyUCBA4FDogVCA23e5RuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4QgZAeCaC+BFgWHY4lngXKBN4cMgSKQW4NOI2CBJxyBUW+BRIEAAQEB X-IronPort-AV: E=Sophos; i="5.11,632,1422921600"; d="asc'?scan'208"; a="6415122" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP; 23 Apr 2015 17:33:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t3NHX33M013789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 17:33:03 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.188]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 12:33:03 -0500 From: "Carlos Pignataro (cpignata)" To: "Surendra Kumar (smkumar)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgIABCUKA//+w/gCAAHbhgP//kACAgAB6xQD//4/fAAAPdvQA Date: Thu, 23 Apr 2015 17:33:42 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> <88423CA0-502D-488A-9C96-75B73026D0ED@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.58] Content-Type: multipart/signed; boundary="Apple-Mail=_070AE5D0-7759-4574-A245-7EB0E69CDC9E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Tom Nadeau , Sumandra Majee , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] NSH and UDP Transport 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, 23 Apr 2015 17:33:57 -0000 --Apple-Mail=_070AE5D0-7759-4574-A245-7EB0E69CDC9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Surendra, The only argument I made is that your characterization was incorrect = (and, since you mention it, also biased). It is not for convenience, = simply for correctness. You said =E2=80=9Cthere is no place=E2=80=9D, = while actually there is place, that the WG can decide how to fill (from = =E2=80=9CNSH is transport agnostic, all details specified elsewhere=E2=80=9D= to something more explicit, including or not the encap you have in = mind, or =E2=80=9CNSH over Avian Carriers"). Now, who is =E2=80=9Cwe=E2=80=9D in =E2=80=9Cwe are in denial=E2=80=9D? = And is that because of your attempt at cataloging =E2=80=9Cfoundational=E2= =80=9D transports? Or your comparison of NSH with VxLAN as an attempt of = an argument? I do not follow either... The pragmatic in me says that the approach of MPLS in RFC 3032 of = documenting a couple deployed common ones was useful; too comprehensive, = not too useful. Thanks, =E2=80=94 Carlos. > On Apr 23, 2015, at 1:10 PM, Surendra Kumar (smkumar) = wrote: >=20 > That is a convenience argument. That is a bias in itself. > Then I would argue, request a UDP port# from IANA and document it in = NSH > and show an example of it. >=20 > There is probably a reason all of the below use ONLY UDP! > GENEV : UDP# 6081 > GUE : UDP# 6080 > VxLAN : UDP# 4790 > VxLAN-gpe: UDP# 4789 >=20 > And yet, we are in denial. >=20 > Surendra. >=20 > On 4/23/15, 9:52 AM, "Carlos Pignataro (cpignata)" = > wrote: >=20 >> =E2=80=9CThere is no place=E2=80=9D is incorrect. Section 11 is = titled =E2=80=9CNSH Encapsulation >> Examples=E2=80=9D. >>=20 >> =E2=80=95 Carlos. >>=20 >>> On Apr 23, 2015, at 12:32 PM, Surendra Kumar (smkumar) >>> wrote: >>>=20 >>> If the WG agrees with this, then there is no place for section 11 in = NSH >>> draft and we should remove it! >>> Why document a specific set of transports ? >>>=20 >>> Surendra. >>>=20 >>> On 4/23/15, 9:13 AM, "Joel M. Halpern" wrote: >>>=20 >>>> One of the reasons why I appreciated the way the charter was drawn = is >>>> that arguing about which transports are "foundational" does not >>>> actually >>>> help anyone. I understand why you consider those "foundational" = Given >>>> that it is out of scope for the group, and provides no benefit to = the >>>> group, I would prefer not to get into a series of debates about = which >>>> ones are actually foundational. >>>>=20 >>>> As a corollary, I see no reason to use a different UDP port than = the >>>> one >>>> you have. I just don't see it as the WG job to pick. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote: >>>>> Joel, >>>>>=20 >>>>> I=C2=B9ve always been saying that the strong point of NSH is that = it is >>>>> transport independent, unlike GENEVE (in nvo3 archives), for = instance. >>>>> Which in fact provides equivalent header capabilities, but has a >>>>> specific >>>>> transport . >>>>>=20 >>>>> I agree we can=C2=B9t enumerate all transports and go modify them = all from >>>>> SFC >>>>> WG. As I showed in the the other diagram, we should demonstrate = this >>>>> transport independence in the fundamental layers of the IP stack. = We >>>>> have >>>>> ether type that covers L2 and L3. We should have one for L4. >>>>>=20 >>>>> To me, native ethernet and native UDP are foundational. The rest = can >>>>> be >>>>> done in other working groups as you suggest. We have the demux in = NSH >>>>> just >>>>> as GUE and GENEVE to signal payloads. >>>>>=20 >>>>> Btw, I am no way tied to 6633. WG can allocate another one and = that >>>>> would >>>>> be fine. >>>>> Surendra. >>>>>=20 >>>>> On 4/23/15, 6:50 AM, "Joel M. Halpern" = wrote: >>>>>=20 >>>>>> Your questions below are precisely why the charter calls for us = to be >>>>>> transport independent. We are not here to debate the benefits = and >>>>>> drawbacks of various transport. No one other than you has asked = to >>>>>> mandate or require anything about the transports. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: >>>>>>> Sumandra, >>>>>> ... >>>>>>> It is fine to support SFC over VxLAN. However, why make that a >>>>>>> requirement to deploy SFC ? >>>>>>> Why are we requiring provisioning of VNIs to deploy SFC ? >>>>>>> Why are we requiring VTEP functionality, etc to deploy SFC ? >>>>>>> Why are we adding more cost to deploy SFC ? >>>>>>> Why are we making it complex to deploy SFC in a simple L3 = network ? >>>>>> ... >>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 --Apple-Mail=_070AE5D0-7759-4574-A245-7EB0E69CDC9E 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 iEYEARECAAYFAlU5LNAACgkQtfDPGTp3USxgNgCg2uZrj2aKNArXIVyA4HV+/zKv omEAn0mBFoPpHXM4ztO6mo3uBdoPqFmY =0aFi -----END PGP SIGNATURE----- --Apple-Mail=_070AE5D0-7759-4574-A245-7EB0E69CDC9E-- From nobody Thu Apr 23 19:01:41 2015 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 A03061A0242 for ; Thu, 23 Apr 2015 19:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 4lKO1CD_UDkN for ; Thu, 23 Apr 2015 19:01:38 -0700 (PDT) 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 2CC031A0022 for ; Thu, 23 Apr 2015 19:01:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVG75272; Fri, 24 Apr 2015 02:01:08 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Apr 2015 03:01:07 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 24 Apr 2015 10:01:01 +0800 From: Xuxiaohu To: "Joel M. Halpern" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1WCKaAgADGDwCAAD09gIAA6O4AgAAbWACAAXcpgIAAk+eAgAAmWQCAAAGGgIAABVwAgAAA2QCAASQNQA== Date: Fri, 24 Apr 2015 02:01:01 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08327D1E@NKGEML512-MBS.china.huawei.com> References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> <55391F44.10508@joelhalpern.com> In-Reply-To: <55391F44.10508@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 24 Apr 2015 02:01:40 -0000 +1 Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, April 24, 2015 12:35 AM > Cc: sfc@ietf.org > Subject: Re: [sfc] NSH and UDP Transport >=20 > That would be fine with me. > Yours, > Joel >=20 > On 4/23/15 12:32 PM, Surendra Kumar (smkumar) wrote: > > If the WG agrees with this, then there is no place for section 11 in > > NSH draft and we should remove it! > > Why document a specific set of transports ? > > > > Surendra. > > > > On 4/23/15, 9:13 AM, "Joel M. Halpern" wrote: > > > >> One of the reasons why I appreciated the way the charter was drawn is > >> that arguing about which transports are "foundational" does not > >> actually help anyone. I understand why you consider those > >> "foundational" Given that it is out of scope for the group, and > >> provides no benefit to the group, I would prefer not to get into a > >> series of debates about which ones are actually foundational. > >> > >> As a corollary, I see no reason to use a different UDP port than the > >> one you have. I just don't see it as the WG job to pick. > >> > >> Yours, > >> Joel > >> > >> On 4/23/15 12:07 PM, Surendra Kumar (smkumar) wrote: > >>> Joel, > >>> > >>> I=B9ve always been saying that the strong point of NSH is that it is > >>> transport independent, unlike GENEVE (in nvo3 archives), for instance= . > >>> Which in fact provides equivalent header capabilities, but has a > >>> specific transport . > >>> > >>> I agree we can=B9t enumerate all transports and go modify them all > >>> from SFC WG. As I showed in the the other diagram, we should > >>> demonstrate this transport independence in the fundamental layers of > >>> the IP stack. We have ether type that covers L2 and L3. We should > >>> have one for L4. > >>> > >>> To me, native ethernet and native UDP are foundational. The rest can > >>> be done in other working groups as you suggest. We have the demux in > >>> NSH just as GUE and GENEVE to signal payloads. > >>> > >>> Btw, I am no way tied to 6633. WG can allocate another one and that > >>> would be fine. > >>> Surendra. > >>> > >>> On 4/23/15, 6:50 AM, "Joel M. Halpern" wrote: > >>> > >>>> Your questions below are precisely why the charter calls for us to > >>>> be transport independent. We are not here to debate the benefits > >>>> and drawbacks of various transport. No one other than you has > >>>> asked to mandate or require anything about the transports. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 4/23/15 1:00 AM, Surendra Kumar (smkumar) wrote: > >>>>> Sumandra, > >>>> ... > >>>>> It is fine to support SFC over VxLAN. However, why make that a > >>>>> requirement to deploy SFC ? > >>>>> Why are we requiring provisioning of VNIs to deploy SFC ? > >>>>> Why are we requiring VTEP functionality, etc to deploy SFC ? > >>>>> Why are we adding more cost to deploy SFC ? > >>>>> Why are we making it complex to deploy SFC in a simple L3 network ? > >>>> ... > >>> > >>> > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Apr 23 19:58:25 2015 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 5AB311B2B4F for ; Thu, 23 Apr 2015 19:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZDjw9wQofBYv for ; Thu, 23 Apr 2015 19:58:23 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2ED1A8A41 for ; Thu, 23 Apr 2015 19:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7748; q=dns/txt; s=iport; t=1429844281; x=1431053881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mjor8xROVgyjBgnc9BUVop8/sfhl/QpJacwcUA0Wgts=; b=cKQ+IYNkwdEm67/Ky4eP1tiSqhzctL4WL5WU6verwP28ko4i8GhJ5ayl w6q4bq5/IC3UJ85Og+uzlHqpg085z2of3NDHHHoOSiqvbCyxRT6bp7aT3 RMrS4M8ZwupxPuDHa6xuyF6XlKz9dAgOIs0T+Evpwwk0ESRZPmxweqoD6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AWBQDgrzlV/4sNJK1bgwxSUAwFgxXEWwqGBAIcgRhMAQEBAQEBgQuEIQEBBAEBATEzBwsQAgEIGAQoAgIlCyUCBA4FiCsNmgCcegaVEwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgRuKHIQgZAeCYoFLBYdjh0eCIIo1gSKQW4NOI2CBJxyBUW+BRIEAAQEB X-IronPort-AV: E=Sophos;i="5.11,636,1422921600"; d="scan'208";a="6531075" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 24 Apr 2015 02:57:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3O2vwgX014640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Apr 2015 02:57:58 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 23 Apr 2015 21:57:58 -0500 From: "Surendra Kumar (smkumar)" To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgADGDwCAAD09gIAAc5KAgACQtACAAQHOgIABCUKA//+w/gCAAHbhgP//kACAgAB6xQD//4/fAAAPdvQAAAUPNgA= Date: Fri, 24 Apr 2015 02:57:58 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <1429684699272.32602@F5.com> <5538F89D.2000302@joelhalpern.com> <55391A0F.5090506@joelhalpern.com> <88423CA0-502D-488A-9C96-75B73026D0ED@cisco.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.4.8.150116 x-originating-ip: [10.24.111.175] Content-Type: text/plain; charset="euc-kr" Content-ID: <068B1F97B7C91C49AE9E432F6EA98BA0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Tom Nadeau , Sumandra Majee , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] NSH and UDP Transport 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, 24 Apr 2015 02:58:25 -0000 Q2FybG9zLA0KDQpUaGVyZSBpcyBhIGNvcnJlY3RuZXNzIGFuZCBpbmNvbnNpc3RlbmN5IHByb2Js ZW0gZ2l2ZW4gYWxsIHRoZSBkaXNjdXNzaW9uDQpzbyBmYXIuIEZpcnN0bHksIG1hbnkgb24gdGhp cyB0aHJlYWQsIGluY2x1ZGluZyB0aGUgY2hhaXIsIHRoaW5rIHRoYXQNCnRyYW5zcG9ydCBzdHVm ZiBzaG91bGQgYmUgdGFrZW4gb3V0c2lkZSB0aGUgU0ZDIFdHIGludG8gdHJhbnNwb3J0IFdHcy4N Cg0KSG93ZXZlciwNCjEuIEV0aGVyVHlwZT0weDg5NEYgaXMgZG9jdW1lbnRlZCwgd2l0aG91dCBh IHRyYW5zcG9ydCBXRyBkcmFmdCwgaW4NCnNlY3Rpb24gMTEgd2hpbGUgYXQgdGhlIHNhbWUgdGlt ZSBVRFAgaXMgbm90IGJlaW5nIGFsbG93ZWQgLSB0aGUNCmluY29uc2lzdGVuY3kgcGFydA0KMi4g U2luY2UgYWxsIHNpZ25hbGluZyBiZWxvbmdzIGluIHRyYW5zcG9ydCwgcHJvdG9jb2wtZmllbGQg KGRlbXV4KSBpbiBOU0gNCnNlZW1zIHRvIGJlIG91dCBvZiBzY29wZSAtIGNvcnJlY3RuZXNzIGlz c3VlLg0KDQpXZSBuZWVkIHRvIG1ha2UgYW1lbmRzIHRvIHRha2UgY2FyZSBvZiB0aGVzZS4gSSBw ZXJzb25hbGx5IGJlbGlldmUgdGhpcyBpcw0KdG9vIHJpZ2lkIGFuZCB3ZSBzaG91bGQgcmVsYXgg ZWl0aGVyIHRoZSBjaGFydGVyIGl0c2VsZiBvciB0aGUgZW5mb3JjZW1lbnQNCm9mIGl0IHRvIGFs bG93IHRoZSBwcm90b2NvbC1maWVsZCwgZXRoZXItdHlwZSBhbmQgVURQLCBpZiBub3Qgb3RoZXJz Lg0KDQpTdXJlbmRyYS4NCg0KT24gNC8yMy8xNSwgMTA6MzMgQU0sICJDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSkiIDxjcGlnbmF0YUBjaXNjby5jb20+DQp3cm90ZToNCg0KPlN1cmVuZHJhLA0K Pg0KPlRoZSBvbmx5IGFyZ3VtZW50IEkgbWFkZSBpcyB0aGF0IHlvdXIgY2hhcmFjdGVyaXphdGlv biB3YXMgaW5jb3JyZWN0DQo+KGFuZCwgc2luY2UgeW91IG1lbnRpb24gaXQsIGFsc28gYmlhc2Vk KS4gSXQgaXMgbm90IGZvciBjb252ZW5pZW5jZSwNCj5zaW1wbHkgZm9yIGNvcnJlY3RuZXNzLiBZ b3Ugc2FpZCChsHRoZXJlIGlzIG5vIHBsYWNlobEsIHdoaWxlIGFjdHVhbGx5DQo+dGhlcmUgaXMg cGxhY2UsIHRoYXQgdGhlIFdHIGNhbiBkZWNpZGUgaG93IHRvIGZpbGwgKGZyb20gobBOU0ggaXMN Cj50cmFuc3BvcnQgYWdub3N0aWMsIGFsbCBkZXRhaWxzIHNwZWNpZmllZCBlbHNld2hlcmWhsSB0 byBzb21ldGhpbmcgbW9yZQ0KPmV4cGxpY2l0LCBpbmNsdWRpbmcgb3Igbm90IHRoZSBlbmNhcCB5 b3UgaGF2ZSBpbiBtaW5kLCBvciChsE5TSCBvdmVyIEF2aWFuDQo+Q2FycmllcnMiKS4NCj4NCj5O b3csIHdobyBpcyChsHdlobEgaW4gobB3ZSBhcmUgaW4gZGVuaWFsobE/IEFuZCBpcyB0aGF0IGJl Y2F1c2Ugb2YgeW91cg0KPmF0dGVtcHQgYXQgY2F0YWxvZ2luZyChsGZvdW5kYXRpb25hbKGxIHRy YW5zcG9ydHM/IE9yIHlvdXIgY29tcGFyaXNvbiBvZg0KPk5TSCB3aXRoIFZ4TEFOIGFzIGFuIGF0 dGVtcHQgb2YgYW4gYXJndW1lbnQ/IEkgZG8gbm90IGZvbGxvdyBlaXRoZXIuLi4NCj4NCj5UaGUg cHJhZ21hdGljIGluIG1lIHNheXMgdGhhdCB0aGUgYXBwcm9hY2ggb2YgTVBMUyBpbiBSRkMgMzAz MiBvZg0KPmRvY3VtZW50aW5nIGEgY291cGxlIGRlcGxveWVkIGNvbW1vbiBvbmVzIHdhcyB1c2Vm dWw7IHRvbyBjb21wcmVoZW5zaXZlLA0KPm5vdCB0b28gdXNlZnVsLg0KPg0KPlRoYW5rcywNCj4N Cj6hqiBDYXJsb3MuDQo+DQo+PiBPbiBBcHIgMjMsIDIwMTUsIGF0IDE6MTAgUE0sIFN1cmVuZHJh IEt1bWFyIChzbWt1bWFyKQ0KPj48c21rdW1hckBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBU aGF0IGlzIGEgY29udmVuaWVuY2UgYXJndW1lbnQuIFRoYXQgaXMgYSBiaWFzIGluIGl0c2VsZi4N Cj4+IFRoZW4gSSB3b3VsZCBhcmd1ZSwgcmVxdWVzdCBhIFVEUCBwb3J0IyBmcm9tIElBTkEgYW5k IGRvY3VtZW50IGl0IGluIE5TSA0KPj4gYW5kIHNob3cgYW4gZXhhbXBsZSBvZiBpdC4NCj4+IA0K Pj4gVGhlcmUgaXMgcHJvYmFibHkgYSByZWFzb24gYWxsIG9mIHRoZSBiZWxvdyB1c2UgT05MWSBV RFAhDQo+PiBHRU5FViAgICA6IFVEUCMgNjA4MQ0KPj4gR1VFICAgICAgOiBVRFAjIDYwODANCj4+ IFZ4TEFOICAgIDogVURQIyA0NzkwDQo+PiBWeExBTi1ncGU6IFVEUCMgNDc4OQ0KPj4gDQo+PiBB bmQgeWV0LCB3ZSBhcmUgaW4gZGVuaWFsLg0KPj4gDQo+PiBTdXJlbmRyYS4NCj4+IA0KPj4gT24g NC8yMy8xNSwgOTo1MiBBTSwgIkNhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSIgPGNwaWduYXRh QGNpc2NvLmNvbT4NCj4+IHdyb3RlOg0KPj4gDQo+Pj4gobBUaGVyZSBpcyBubyBwbGFjZaGxIGlz IGluY29ycmVjdC4gU2VjdGlvbiAxMSBpcyB0aXRsZWQgobBOU0gNCj4+PkVuY2Fwc3VsYXRpb24N Cj4+PiBFeGFtcGxlc6GxLg0KPj4+IA0KPj4+IKGqIENhcmxvcy4NCj4+PiANCj4+Pj4gT24gQXBy IDIzLCAyMDE1LCBhdCAxMjozMiBQTSwgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpDQo+Pj4+IDxz bWt1bWFyQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBJZiB0aGUgV0cgYWdyZWVzIHdp dGggdGhpcywgdGhlbiB0aGVyZSBpcyBubyBwbGFjZSBmb3Igc2VjdGlvbiAxMSBpbg0KPj4+Pk5T SA0KPj4+PiBkcmFmdCBhbmQgd2Ugc2hvdWxkIHJlbW92ZSBpdCENCj4+Pj4gV2h5IGRvY3VtZW50 IGEgc3BlY2lmaWMgc2V0IG9mIHRyYW5zcG9ydHMgPw0KPj4+PiANCj4+Pj4gU3VyZW5kcmEuDQo+ Pj4+IA0KPj4+PiBPbiA0LzIzLzE1LCA5OjEzIEFNLCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpv ZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+Pj4gT25lIG9mIHRoZSByZWFzb25zIHdo eSBJIGFwcHJlY2lhdGVkIHRoZSB3YXkgdGhlIGNoYXJ0ZXIgd2FzIGRyYXduIGlzDQo+Pj4+PiB0 aGF0IGFyZ3VpbmcgYWJvdXQgd2hpY2ggdHJhbnNwb3J0cyBhcmUgImZvdW5kYXRpb25hbCIgZG9l cyBub3QNCj4+Pj4+IGFjdHVhbGx5DQo+Pj4+PiBoZWxwIGFueW9uZS4gIEkgdW5kZXJzdGFuZCB3 aHkgeW91IGNvbnNpZGVyIHRob3NlICJmb3VuZGF0aW9uYWwiDQo+Pj4+PkdpdmVuDQo+Pj4+PiB0 aGF0IGl0IGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIGdyb3VwLCBhbmQgcHJvdmlkZXMgbm8gYmVu ZWZpdCB0byB0aGUNCj4+Pj4+IGdyb3VwLCBJIHdvdWxkIHByZWZlciBub3QgdG8gZ2V0IGludG8g YSBzZXJpZXMgb2YgZGViYXRlcyBhYm91dCB3aGljaA0KPj4+Pj4gb25lcyBhcmUgYWN0dWFsbHkg Zm91bmRhdGlvbmFsLg0KPj4+Pj4gDQo+Pj4+PiBBcyBhIGNvcm9sbGFyeSwgSSBzZWUgbm8gcmVh c29uIHRvIHVzZSBhIGRpZmZlcmVudCBVRFAgcG9ydCB0aGFuIHRoZQ0KPj4+Pj4gb25lDQo+Pj4+ PiB5b3UgaGF2ZS4gIEkganVzdCBkb24ndCBzZWUgaXQgYXMgdGhlIFdHIGpvYiB0byBwaWNrLg0K Pj4+Pj4gDQo+Pj4+PiBZb3VycywNCj4+Pj4+IEpvZWwNCj4+Pj4+IA0KPj4+Pj4gT24gNC8yMy8x NSAxMjowNyBQTSwgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIHdyb3RlOg0KPj4+Pj4+IEpvZWws DQo+Pj4+Pj4gDQo+Pj4+Pj4gSan2dmUgYWx3YXlzIGJlZW4gc2F5aW5nIHRoYXQgdGhlIHN0cm9u ZyBwb2ludCBvZiBOU0ggaXMgdGhhdCBpdCBpcw0KPj4+Pj4+IHRyYW5zcG9ydCBpbmRlcGVuZGVu dCwgdW5saWtlIEdFTkVWRSAoaW4gbnZvMyBhcmNoaXZlcyksIGZvcg0KPj4+Pj4+aW5zdGFuY2Uu DQo+Pj4+Pj4gV2hpY2ggaW4gZmFjdCBwcm92aWRlcyBlcXVpdmFsZW50IGhlYWRlciBjYXBhYmls aXRpZXMsIGJ1dCBoYXMgYQ0KPj4+Pj4+IHNwZWNpZmljDQo+Pj4+Pj4gdHJhbnNwb3J0IC4NCj4+ Pj4+PiANCj4+Pj4+PiBJIGFncmVlIHdlIGNhbqn2dCBlbnVtZXJhdGUgYWxsIHRyYW5zcG9ydHMg YW5kIGdvIG1vZGlmeSB0aGVtIGFsbA0KPj4+Pj4+ZnJvbQ0KPj4+Pj4+IFNGQw0KPj4+Pj4+IFdH LiBBcyBJIHNob3dlZCBpbiB0aGUgdGhlIG90aGVyIGRpYWdyYW0sIHdlIHNob3VsZCBkZW1vbnN0 cmF0ZSB0aGlzDQo+Pj4+Pj4gdHJhbnNwb3J0IGluZGVwZW5kZW5jZSBpbiB0aGUgZnVuZGFtZW50 YWwgbGF5ZXJzIG9mIHRoZSBJUCBzdGFjay4gV2UNCj4+Pj4+PiBoYXZlDQo+Pj4+Pj4gZXRoZXIg dHlwZSB0aGF0IGNvdmVycyBMMiBhbmQgTDMuIFdlIHNob3VsZCBoYXZlIG9uZSBmb3IgTDQuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gVG8gbWUsIG5hdGl2ZSBldGhlcm5ldCBhbmQgbmF0aXZlIFVEUCBhcmUg Zm91bmRhdGlvbmFsLiBUaGUgcmVzdCBjYW4NCj4+Pj4+PiBiZQ0KPj4+Pj4+IGRvbmUgaW4gb3Ro ZXIgd29ya2luZyBncm91cHMgYXMgeW91IHN1Z2dlc3QuIFdlIGhhdmUgdGhlIGRlbXV4IGluDQo+ Pj4+Pj5OU0gNCj4+Pj4+PiBqdXN0DQo+Pj4+Pj4gYXMgR1VFIGFuZCBHRU5FVkUgdG8gc2lnbmFs IHBheWxvYWRzLg0KPj4+Pj4+IA0KPj4+Pj4+IEJ0dywgSSBhbSBubyB3YXkgdGllZCB0byA2NjMz LiBXRyBjYW4gYWxsb2NhdGUgYW5vdGhlciBvbmUgYW5kIHRoYXQNCj4+Pj4+PiB3b3VsZA0KPj4+ Pj4+IGJlIGZpbmUuDQo+Pj4+Pj4gU3VyZW5kcmEuDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gNC8yMy8x NSwgNjo1MCBBTSwgIkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+IHdyb3Rl Og0KPj4+Pj4+IA0KPj4+Pj4+PiBZb3VyIHF1ZXN0aW9ucyBiZWxvdyBhcmUgcHJlY2lzZWx5IHdo eSB0aGUgY2hhcnRlciBjYWxscyBmb3IgdXMgdG8NCj4+Pj4+Pj5iZQ0KPj4+Pj4+PiB0cmFuc3Bv cnQgaW5kZXBlbmRlbnQuICBXZSBhcmUgbm90IGhlcmUgdG8gZGViYXRlIHRoZSBiZW5lZml0cyBh bmQNCj4+Pj4+Pj4gZHJhd2JhY2tzIG9mIHZhcmlvdXMgdHJhbnNwb3J0LiAgTm8gb25lIG90aGVy IHRoYW4geW91IGhhcyBhc2tlZCB0bw0KPj4+Pj4+PiBtYW5kYXRlIG9yIHJlcXVpcmUgYW55dGhp bmcgYWJvdXQgdGhlIHRyYW5zcG9ydHMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBZb3VycywNCj4+Pj4+ Pj4gSm9lbA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gNC8yMy8xNSAxOjAwIEFNLCBTdXJlbmRyYSBL dW1hciAoc21rdW1hcikgd3JvdGU6DQo+Pj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+Pj4gLi4uDQo+ Pj4+Pj4+PiBJdCBpcyBmaW5lIHRvIHN1cHBvcnQgU0ZDIG92ZXIgVnhMQU4uIEhvd2V2ZXIsIHdo eSBtYWtlIHRoYXQgYQ0KPj4+Pj4+Pj4gcmVxdWlyZW1lbnQgdG8gZGVwbG95IFNGQyA/DQo+Pj4+ Pj4+PiBXaHkgYXJlIHdlIHJlcXVpcmluZyBwcm92aXNpb25pbmcgb2YgVk5JcyB0byBkZXBsb3kg U0ZDID8NCj4+Pj4+Pj4+IFdoeSBhcmUgd2UgcmVxdWlyaW5nIFZURVAgZnVuY3Rpb25hbGl0eSwg ZXRjIHRvIGRlcGxveSBTRkMgPw0KPj4+Pj4+Pj4gV2h5IGFyZSB3ZSBhZGRpbmcgbW9yZSBjb3N0 IHRvIGRlcGxveSBTRkMgPw0KPj4+Pj4+Pj4gV2h5IGFyZSB3ZSBtYWtpbmcgaXQgY29tcGxleCB0 byBkZXBsb3kgU0ZDIGluIGEgc2ltcGxlIEwzIG5ldHdvcmsNCj4+Pj4+Pj4+Pw0KPj4+Pj4+PiAu Li4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2Zj QGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4gDQo+PiANCj4NCg0K From nobody Sun Apr 26 13:36:03 2015 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 679D31A901C; Sun, 26 Apr 2015 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Z43OV1Cb82r5; Sun, 26 Apr 2015 13:36:01 -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 12B231A8FD5; Sun, 26 Apr 2015 13:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1797; q=dns/txt; s=iport; t=1430080561; x=1431290161; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=I/PFD5r02OHIGEwWmwJVv7H6RymeJT1AFwBqKSpNKuM=; b=YpdPPmfsz+JM3qLxgMfv3TOPwuJCDN7ZRfzXyQlmSmPkojZpURbsEKd+ wKb3Tw5SCEMNWZcp5IoGIAKpCVymJT8F2RxB5EC8rvwy4JaxRusBd/iCQ K+2h19K/06sfH5wk5okyN5B27GzZ+6x4loMa0VitlpSrq9jolWa2RCpzB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBABBSz1V/5xdJa1cgwxTXAXFNWYJgUgKhgQCgRw4FAEBAQEBAQGBCoQhAQEEAQEBNzQLEgEIEiQ3CxcEAQYDAgQBDQUJiCINxGoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiziFBQIFhC0FkVWEAYY4gSI9gwuKKYZOI4N0bwGBQ4EAAQEB X-IronPort-AV: E=Sophos;i="5.11,652,1422921600"; d="scan'208";a="144713730" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 26 Apr 2015 20:36:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3QKa0Qa021517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Apr 2015 20:36:00 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.90]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sun, 26 Apr 2015 15:36:00 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "ipfix@ietf.org" , "sfc@ietf.org" Thread-Topic: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt Thread-Index: AQHQgGCaz1YmKYTy8UWC225FKC3D+Q== Date: Sun, 26 Apr 2015 20:35:59 +0000 Message-ID: In-Reply-To: <20150309124951.25309.98356.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.250.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <13CF2017A7E0EF4498D11BAD7AECDEB1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-kumar-ipfix-sfc-extension@tools.ietf.org" Subject: [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-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: Sun, 26 Apr 2015 20:36:02 -0000 Hi, Below is the draft proposed on IPFIX information elements for SFC. We welcome any comments/feedbacks. Regards, Draft Authors. On 3/9/15, 8:49 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IPFIX Information Element extension for SFC > Authors : Nagendra Kumar > Carlos Pignataro > Paul Quinn > Filename : draft-kumar-ipfix-sfc-extension-00.txt > Pages : 11 > Date : 2015-03-09 > >Abstract: > Service Function Chaining (SFC) is an architecture that enables any > operator to apply selective set of services by steering the traffic > through an ordered set of service functions without any topology > dependency. > > This document defines the required Information Elements to represent > the details about service flows over any Service Function Path. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-00 > > >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/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Apr 26 15:40:52 2015 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 F2C1E1A882B; Sun, 26 Apr 2015 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yUN8ufYZpa2m; Sun, 26 Apr 2015 15:40:48 -0700 (PDT) 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 9D3021A8772; Sun, 26 Apr 2015 15:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6F7B724061E; Sun, 26 Apr 2015 15:40:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-97-72.public.wayport.net [64.134.97.72]) (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 D43B9240173; Sun, 26 Apr 2015 15:40:47 -0700 (PDT) Message-ID: <553D6926.40507@joelhalpern.com> Date: Sun, 26 Apr 2015 18:39:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Nagendra Kumar Nainar (naikumar)" , "ipfix@ietf.org" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-kumar-ipfix-sfc-extension@tools.ietf.org" Subject: Re: [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-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: Sun, 26 Apr 2015 22:40:50 -0000 I am wondering if the nextSFF fields really belong here? I see several problems with them. If the observation is being made before the SF, or between multiple local SF, then the information does not exist. Even if the observation is being made after the last local SF, the identification of the next SFF, as understood by this SFF, may well not be an IP address. What the local SFF knows may be an IP address, and Ethernet Address, an MPLS label, etc. So I am not sure this makes sense as a reportable. Otherwise, it looks quite reasonable and useful. Yours, Joel On 4/26/15 4:35 PM, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > Below is the draft proposed on IPFIX information elements for SFC. > > We welcome any comments/feedbacks. > > Regards, > Draft Authors. > > On 3/9/15, 8:49 AM, "internet-drafts@ietf.org" > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IPFIX Information Element extension for SFC >> Authors : Nagendra Kumar >> Carlos Pignataro >> Paul Quinn >> Filename : draft-kumar-ipfix-sfc-extension-00.txt >> Pages : 11 >> Date : 2015-03-09 >> >> Abstract: >> Service Function Chaining (SFC) is an architecture that enables any >> operator to apply selective set of services by steering the traffic >> through an ordered set of service functions without any topology >> dependency. >> >> This document defines the required Information Elements to represent >> the details about service flows over any Service Function Path. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-00 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Apr 27 18:46:11 2015 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 CE8B21ACE11 for ; Mon, 27 Apr 2015 18:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 07Mw7rT5vLSf for ; Mon, 27 Apr 2015 18:46:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C251ACE0B for ; Mon, 27 Apr 2015 18:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2336; q=dns/txt; s=iport; t=1430185569; x=1431395169; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vnnoLlNmH0jp9BFgAwj8VSWxfi7+tO5s8+mXxeLxyUA=; b=jF83cRo2cgesJUZ3XLGIahYTyX+75HgB1gLwntmlgCllSFy8A2nITF9A a/spmEBadJwCWOsrVIJsz58gsb+AysehgRog3m6ZFjOpke8mUw8I16f9I TzQ68iNTgnHTB/gQWHLzPAo+Czd5c6NnMZvj9juOrtHi+NapknSbWYf5O 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9BAC85T5V/4MNJK1cgwyBLwWDFcM5CYdWAhyBFjgUAQEBAQEBAYEKhCEBAQQdFzMiAgEIGAQoAgIwJQIEE4grlgycfAaUDQEBAQEBAQQBAQEBAR2BG4odhFI6gmKBSwWRVYo5gSKNGYNWg1AjYIMUb4FEgQABAQE X-IronPort-AV: E=Sophos;i="5.11,661,1422921600"; d="scan'208";a="144978173" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 28 Apr 2015 01:46:08 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3S1k8D0015365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Apr 2015 01:46:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.245]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 27 Apr 2015 20:46:08 -0500 From: "Larry Kreeger (kreeger)" To: "sfc@ietf.org" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heA Date: Tue, 28 Apr 2015 01:46:07 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@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.4.9.150325 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 01:46:11 -0000 SGkgSmltLA0KDQpJZiBzb21lb25lIHdhbnRlZCB0byB3cml0ZSBhIGRyYWZ0IHNwZWNpZnlpbmcg aG93IHRvIGNhcnJ5IE5TSCBvdmVyIFVEUCwNCndoYXQgV0cgd291bGQgaXQgYmUgc3VibWl0dGVk IHRvPyAgSSB1c3VhbGx5IHNlZSB0aGUgcHJvdG9jb2xzIHJ1bm5pbmcNCm92ZXIgVURQIHNwZWNp ZnkgdGhlaXIgVURQIHBvcnQgbnVtYmVyLCBub3QgdGhlIG90aGVyIHdheSBhcm91bmQgKFVEUA0K ZG9lc24ndCBzcGVjaWZ5IHdoYXQgcnVucyBvbiB0b3Agb2YgaXQpLiAgRm9yIGV4YW1wbGUsIFZY TEFOIHNwZWNpZmllcw0KdGhlIFVEUCBwb3J0IHVzZWQgdG8gY2FycnkgaXQuICBVRFAgZG9lcyBu b3Qgc3BlY2lmeSB3aGF0IHBvcnQgdG8gdXNlIHRvDQpjYXJyeSBWWExBTi4gIElzIHRoZXJlIGFu IFJGQyB5b3UgY2FuIHBvaW50IHRvIGFzIGFuIGV4YW1wbGUgdGhhdCBzaW1wbHkNCnNwZWNpZmll cyBhIFVEUCBwb3J0IGZvciBhbm90aGVyIHByb3RvY29sIHRvIGJlIGNhcnJpZWQ/DQoNClRoYW5r cywgTGFycnkNCg0KT24gNC8yMy8xNSA3OjIyIEFNLCAiSmltIEd1aWNoYXJkIChqZ3VpY2hhciki IDxqZ3VpY2hhckBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGkgSm9lbCwNCj4NCj5PbiA0LzIzLzE1 LCA5OjQ3IEFNLCAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6 DQo+DQo+PkkgdGhpbmsgSSBhbSBtaXNzaW5nIHlvdXIgcG9pbnQgVGhvbWFzLiAgV2UgaGF2ZSBh biBhZ3JlZWQgY29tbW9uIGhlYWRlcg0KPj4ob3IgYXQgbGVhc3QgYW4gYWdyZWVkIGJhc2lzIGFu ZCBleHBlY3RhdGlvbiB0aGF0IHdlIHdpbGwgY29tcGxldGUgdGhlDQo+PnJlc3QgZXhwZWRpdGlv dXNseS4pICBTbyBJIGRvIG5vdCBzZWUgYW55IHJpc2sgb2YgZW5kaW5nIHVwIHdpdGggYQ0KPj5k aWZmZXJlbnQgTlNIIGhlYWRlciBmb3IgZWFjaCB0cmFuc3BvcnQuDQo+Pg0KPj5UaGUgcXVlc3Rp b24gaXMgd2hlcmUgLyB3aGVuIGRvIHdlIHNwZWNpZnkgdGhlIHRyYW5zcG9ydCBkZXRhaWxzLg0K Pg0KPkppbT4gb3VyIGNoYXJ0ZXIgZG9lcyBub3QgY2FsbCBmb3IgdXMgdG8gd29yayBvbiB0aGUg dHJhbnNwb3J0IGRldGFpbHM7DQo+dGhvc2Ugc2hvdWxkIGJlIGFkZHJlc3NlZCBieSB0aGUgcmVs ZXZhbnQgV0cgZm9yIGEgZ2l2ZW4gdHJhbnNwb3J0DQo+cG9pbnRpbmcgdG8gb3VyIFNGQyBlbmNh cHN1bGF0aW9uIHdvcmsuDQo+DQo+Pg0KPj5JZiBTdXJlbmRyYSB3YW50cyB0byB0YWtlIHRoZSBl eGlzdGluZywgcmVnaXN0ZXJlZCwgY29kZSBwb2ludCwgYW5kDQo+PmluZGljYXRlIHRoYXQgd2hh dCBpdCBpcyB0byBjYXJyeSBpcyBOU0ggKGFuZCBwcmVzdW1hYmx5IHVwZGF0ZSBpdCBhZ2Fpbg0K Pj53aGVuIHRoZSBSRkMgY29tZXMgb3V0KSB0aGF0IGlzIGZpbmUuICBJIGhhdmUgbm8gb2JqZWN0 aW9uIHBlcnNvbmFsbHksDQo+PmFuZCBJIGNhbiBzZWUgbm8gZ3JvdW5kcyBmb3IgdGhlIHdvcmtp bmcgZ3JvdXAgdG8gb2JqZWN0Lg0KPg0KPkppbT4gZnJvbSBhIGNoYWlycyBwZXJzcGVjdGl2ZSBJ IGFsc28gaGF2ZSBubyBvYmplY3Rpb24uIExpa2V3aXNlIGlmIG90aGVyDQo+V0ep9nMgd2FudCB0 byBkZWZpbmUgaW4gdGhlaXIgdHJhbnNwb3J0cyBob3cgTlNIIGlzIGluZGljYXRlZCB0aGVuIHRo YXQgaXMNCj50aGUgcmlnaHQgYXBwcm9hY2ggYW5kIEkgZW5jb3VyYWdlIGl0Lg0KPg0KDQo= From nobody Mon Apr 27 19:04:06 2015 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 340DE1ACE15 for ; Mon, 27 Apr 2015 19:04:04 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3, 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 GF0crCci77Tx for ; Mon, 27 Apr 2015 19:04:02 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 624671ACDDA for ; Mon, 27 Apr 2015 19:04:02 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-2b-553e930e7cf6 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AC.05.32689.E039E355; Mon, 27 Apr 2015 21:50:39 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Mon, 27 Apr 2015 22:03:59 -0400 From: Jeff Tantsura To: "Larry Kreeger (kreeger)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAANo+AIAAj+yAgAAsEQCAAAm1gIAHCGGA///B8Ko= Date: Tue, 28 Apr 2015 02:03:58 +0000 Message-ID: <16408821-FA8E-4F02-B40D-675BD8F89935@ericsson.com> References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXSPty7/ZLtQg6+v2C0WvFnMYvHkwVZ2 ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSujecMM1oKFghU7bv5ibWC8ydvFyMkhIWAi 8ehuKwuELSZx4d56ti5GLg4hgaOMEp9u/2aBcJYzSjTc6gerYhMwkPj/7TiYLSJgKNF6/ToT iM0soCjx6NZvMFtYQEPi4NWZ7F2MHEA1mhLfOnUgypMk1q5tAGtlEVCVaFm2BaycV8Be4tDF DewQu14ySVz7sYUVJMEJtOv0wwOMIDYj0HXfT62B2iUucevJfCaIqwUkluw5zwxhi0q8fPyP FaJGT+LG1ClsELa2xLKFr5khlglKnJz5hGUCo+gsJKNmIWmZhaRlFpKWBYwsqxg5SotTy3LT jQw2MQLj4ZgEm+4Oxj0vLQ8xCnAwKvHwPoi3DRViTSwrrsw9xCjNwaIkzrvowcEQIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYzTQpT724JLRax2buCSSt1Vn/pxwdaSkGO+L+u7Qg8d/bG2 8qzlO/0dExU6mZU/Rvz14/1Sul79/u3XLhtuPeiQ9J/Z8FqHc12xkIminsLquMA8rcdvVvHL K5sIB4szsRxn+u++7o0j99rlPR5SKQqcGSctK9b6NkWffiyZYbeir3fH3y+L/ZVYijMSDbWY i4oTAZT384poAgAA Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 02:04:04 -0000 Larry, If you don't find a better home for it before Prague, potentially you could= present in rtgwg, we will dispatch it afterwards. Regards, Jeff > On Apr 27, 2015, at 9:46 PM, Larry Kreeger (kreeger) = wrote: >=20 > Hi Jim, >=20 > If someone wanted to write a draft specifying how to carry NSH over UDP, > what WG would it be submitted to? I usually see the protocols running > over UDP specify their UDP port number, not the other way around (UDP > doesn't specify what runs on top of it). For example, VXLAN specifies > the UDP port used to carry it. UDP does not specify what port to use to > carry VXLAN. Is there an RFC you can point to as an example that simply > specifies a UDP port for another protocol to be carried? >=20 > Thanks, Larry >=20 >> On 4/23/15 7:22 AM, "Jim Guichard (jguichar)" wrote= : >>=20 >> Hi Joel, >>=20 >>> On 4/23/15, 9:47 AM, "Joel M. Halpern" wrote: >>>=20 >>> I think I am missing your point Thomas. We have an agreed common heade= r >>> (or at least an agreed basis and expectation that we will complete the >>> rest expeditiously.) So I do not see any risk of ending up with a >>> different NSH header for each transport. >>>=20 >>> The question is where / when do we specify the transport details. >>=20 >> Jim> our charter does not call for us to work on the transport details; >> those should be addressed by the relevant WG for a given transport >> pointing to our SFC encapsulation work. >>=20 >>>=20 >>> If Surendra wants to take the existing, registered, code point, and >>> indicate that what it is to carry is NSH (and presumably update it agai= n >>> when the RFC comes out) that is fine. I have no objection personally, >>> and I can see no grounds for the working group to object. >>=20 >> Jim> from a chairs perspective I also have no objection. Likewise if oth= er >> WG=B9s want to define in their transports how NSH is indicated then that= is >> the right approach and I encourage it. >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 28 00:14:24 2015 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 A3D8F1A19F4 for ; Tue, 28 Apr 2015 00:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 GGfXr7fz8FHZ for ; Tue, 28 Apr 2015 00:14:21 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 322CC1A19E9 for ; Tue, 28 Apr 2015 00:14:21 -0700 (PDT) Received: by wgso17 with SMTP id o17so140756030wgs.1 for ; Tue, 28 Apr 2015 00:14:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qcP8pN5+DDoqHA3l6GaWg/AeK13AO7XUk2UD5/YDZ0s=; b=a3P+mh0URXZfpjVYwYFx6DoXYwcqqpQR94L0/phy5AOR6Kl16zXhT4Ccq6hfSKKppo ShSXppjCIxhFl8j2dSnPmXNQWTvv8X3N1ub7yrqKtg1YjdRh87ibyZL/luiPZI+sp9/T sZunjP0qKw0j3DHWp2ZTfWCjE6BzvHNlpwrOekbuk7mRbE8gsfd1sd6JJWwPtugjeXNP mje0HCPLFJJtwp2/1BJzg19/qrjJjtBzhIxw5bQtInJLytD+fpETB8/RYcZzW+DQd4sS oEjLUXCG4byO9Ec0WsrOKgrsiJHI0jseW/y9VWzsTwLljbMFe+QdrqiFz7ey7dtCAnBW 4Kew== X-Gm-Message-State: ALoCoQnbTS2I19jYNX9fU2j1aXVoWcbwR7HUcE60QrM82Aec8rQ+QqzR6MerRpEJbON034k2PZ5t X-Received: by 10.180.87.199 with SMTP id ba7mr27870034wib.81.1430205259956; Tue, 28 Apr 2015 00:14:19 -0700 (PDT) Received: from fallout-4.local ([31.55.16.78]) by mx.google.com with ESMTPSA id y7sm18652238wjw.16.2015.04.28.00.14.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 00:14:18 -0700 (PDT) Message-ID: <553F334D.2050907@queuefull.net> Date: Tue, 28 Apr 2015 08:14:21 +0100 From: Benson Schliesser User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Larry Kreeger (kreeger)" , "Jim Guichard (jguichar)" References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 07:14:22 -0000 Hi, Larry and Jim - Larry Kreeger (kreeger) wrote: > If someone wanted to write a draft specifying how to carry NSH over > UDP, what WG would it be submitted to? As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example of a NSH-capable transport. I think this is a good example of what Jim described as a "relevant WG for a given transport". But in the case of NSH carried directly in UDP, it seems to me that (as Larry described) this is normally described in the protocol document itself. Since NSH is intentionally flexible with regards to underlying transport, I can imagine this being a companion document rather than embedded in the NSH text. But in either case I think it makes the most sense for the SFC WG to be the home for such a definition. Cheers, -Benson From nobody Tue Apr 28 04:36:52 2015 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 F15341A00F5 for ; Mon, 27 Apr 2015 22:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Yr9q4cr4XhTO for ; Mon, 27 Apr 2015 22:54:28 -0700 (PDT) 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 024BC1A00CF for ; Mon, 27 Apr 2015 22:54:28 -0700 (PDT) Received: from localhost ([::1]:35144 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmyTS-0000Z4-UF; Mon, 27 Apr 2015 22:54:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 05:54:24 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/1 Message-ID: <066.8729fa05a3943e6aaf61d8346d4d1fc6@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.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: <20150428055428.024BC1A00CF@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 22:54:28 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 Cc: sfc@ietf.org Subject: [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: Tue, 28 Apr 2015 05:54:32 -0000 #1: Add a new field to include the SFC Identifier The current specification does only allow to indicate a SFP Identifier that is useful only for deployments that rely on a centralized path computation. This too restrictive. As a reminder, * a SFC may be bound to one or multiple SFPs. * A SFP does not uniquely identify a SFC Whether the path computation is fully distributed, fully centralized, or even a combination therefore is really implementation-specific. The correlation between a path identifier and a service chain is not evident from the reading of a packet. Including a SFC Identifier into the header is not only required for the distributed path model but also for cases where the path is partially determined (RSP). The minimum information to be included in the SFC header is the chain identifier itself not the path identifier. I suggest to add a new field that carries an SFC Identifier. FWIW, SFC Identifier is an index that ambiguously identifies a SFC instantiated within an SFC-enabled domain. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:36:54 2015 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 418CD1A0122 for ; Mon, 27 Apr 2015 23:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vJrHSrjUsH7q for ; Mon, 27 Apr 2015 23:08:38 -0700 (PDT) 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 D91C51A00CF for ; Mon, 27 Apr 2015 23:08:38 -0700 (PDT) Received: from localhost ([::1]:35591 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmyhA-000379-Ix; Mon, 27 Apr 2015 23:08:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:08:36 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/2 Message-ID: <066.57688ed370fb3d48421c401186ce86e2@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.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-architecture@ietf.org Resent-Message-Id: <20150428060838.D91C51A00CF@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:08:38 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 Cc: sfc@ietf.org Subject: [sfc] #2 (architecture): 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: Tue, 28 Apr 2015 06:08:40 -0000 #2: Remove "MD Type" field and the companion "MD-type 1" I already send an email back in February to ask about the following but I didn't got any answer == What is the rationale for defining two MD Types? Why MD Type#1 is mandatory to support? Wouldn’t the format in Section 3.5 enough for the SFC use cases? What is the rationale for defining these mandatory contexts headers? What is the motivation for defining mandatory context header? The current text does not explain those aspects. == For the sake of interoperability (mainly to avoid multiple implementations with distinct behaviors) and given no technical motivation is provided (e.g. why MD-type 1 is mandatory why not the other way around, etc. ), one header format should be specified. My personal point of view is that we need to choose. I’m personally for a minimalist header. Leaving both induces more complexity. I suggest to remove the "MD type" field and MD-type 1 from the specification. Moreover, I don’t understand from the draft what is the rationale for classifying the context into these four categories. What is meant by “platform-specific metadata” or “service platform specific”? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Platform Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Shared Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Platform Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Shared Context | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | architecture@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: architecture | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:36:55 2015 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 265381A0217 for ; Mon, 27 Apr 2015 23:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 53-5yMz38u7k for ; Mon, 27 Apr 2015 23:18:19 -0700 (PDT) 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 EABD11A01FC for ; Mon, 27 Apr 2015 23:18:19 -0700 (PDT) Received: from localhost ([::1]:36194 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmyqZ-0003CT-NO; Mon, 27 Apr 2015 23:18:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:18:19 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/3 Message-ID: <066.14ca8ce4f270e903788e6adeabbba119@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.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-architecture@ietf.org Resent-Message-Id: <20150428061819.EABD11A01FC@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:18:19 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 Cc: sfc@ietf.org Subject: [sfc] #3 (architecture): 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: Tue, 28 Apr 2015 06:18:21 -0000 #3: Critical Metadata The document defines two codepoint ranges: one for “critical” (128 to 255) and another one “no critical” metadata (0 to 127). This terminology is confusing given the “criticality” of a metadata is deployment-specific and SFC-specific. Thats is a piece of information may be required for a given chain but may not be critical for another one. The specification does not explain why there will be mandatory-to- implement metadata by design. Shouldn’t this be achieved by configuration locally to each SFC-aware element? Furthermore, the current text says: If a receiver receives an encapsulated packet containing a TLV with the Critical bit set in the Type field and it does not understand how to process the Type, it MUST drop the packet. Transit devices MUST NOT drop packets based on the setting of this bit. Dropping the packet without even sending a notification to the sender or a control element is too aggressive IMHO. Such behavior will lead to more service degradation when SFC in enabled compared to current service deployment schemes. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | architecture@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: architecture | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:36:56 2015 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 C28391A0302 for ; Mon, 27 Apr 2015 23:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9VThuHHFtniO for ; Mon, 27 Apr 2015 23:22:46 -0700 (PDT) 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 BC1B71A026A for ; Mon, 27 Apr 2015 23:22:46 -0700 (PDT) Received: from localhost ([::1]:36367 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ymyus-00086z-Hi; Mon, 27 Apr 2015 23:22:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:22:46 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/4 Message-ID: <066.3f738fef7fe087aec0f60795f1d4b3ad@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.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-architecture@ietf.org Resent-Message-Id: <20150428062246.BC1B71A026A@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:22:46 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 Cc: sfc@ietf.org Subject: [sfc] #4 (architecture): 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: Tue, 28 Apr 2015 06:22:47 -0000 #4: Reuse the IPFIX registry for identifying context types Given IPFIX defines a large set of attributes (https://www.ietf.org/assignments/ipfix/ipfix.xml), wouldn't be optimal to reuse that registery for SFC purposes? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | architecture@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: architecture | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:36:58 2015 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 58D0F1A0368 for ; Mon, 27 Apr 2015 23:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7FfbFugOvaFA for ; Mon, 27 Apr 2015 23:24:03 -0700 (PDT) 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 4FED51A034F for ; Mon, 27 Apr 2015 23:24:03 -0700 (PDT) Received: from localhost ([::1]:36436 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ymyw7-0004Mi-3d; Mon, 27 Apr 2015 23:24:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:24:03 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/5 Message-ID: <066.a8499ce61f6f39c3c1a400b86c706359@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.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-architecture@ietf.org Resent-Message-Id: <20150428062403.4FED51A034F@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:24:03 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 Cc: sfc@ietf.org Subject: [sfc] #5 (architecture): 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: Tue, 28 Apr 2015 06:24:04 -0000 #5: Support of SF Spirals Refer to this thread: http://www.ietf.org/mail- archive/web/sfc/current/msg03179.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | architecture@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: architecture | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:36:59 2015 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 AF6B51A026A for ; Mon, 27 Apr 2015 23:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 a8yqx1gE-U1W for ; Mon, 27 Apr 2015 23:24:22 -0700 (PDT) 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 4F8741A033A for ; Mon, 27 Apr 2015 23:24:22 -0700 (PDT) Received: from localhost ([::1]:36452 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmywQ-0005le-2h; Mon, 27 Apr 2015 23:24:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:24:22 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/5#comment:1 Message-ID: <081.da146c269aa2227c4c034758123d70f4@tools.ietf.org> References: <066.a8499ce61f6f39c3c1a400b86c706359@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <066.a8499ce61f6f39c3c1a400b86c706359@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, 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: <20150428062422.4F8741A033A@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:24:22 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 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: Tue, 28 Apr 2015 06:24:23 -0000 #5: Support of SF Spirals Changes (by mohamed.boucadair@orange.com): * owner: draft-ietf-sfc-architecture@tools.ietf.org => draft-ietf-sfc- nsh@tools.ietf.org * component: architecture => nsh -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:01 2015 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 A5CEF1A033A for ; Mon, 27 Apr 2015 23:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 latRnQsLDCuD for ; Mon, 27 Apr 2015 23:24:42 -0700 (PDT) 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 BA0A31A0302 for ; Mon, 27 Apr 2015 23:24:42 -0700 (PDT) Received: from localhost ([::1]:36472 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ymywk-0007D3-GP; Mon, 27 Apr 2015 23:24:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:24:42 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/4#comment:1 Message-ID: <081.abdce06a20c344f8de91d169ab58022e@tools.ietf.org> References: <066.3f738fef7fe087aec0f60795f1d4b3ad@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <066.3f738fef7fe087aec0f60795f1d4b3ad@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, 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: <20150428062442.BA0A31A0302@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:24:42 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 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: Tue, 28 Apr 2015 06:24:43 -0000 #4: Reuse the IPFIX registry for identifying context types Changes (by mohamed.boucadair@orange.com): * owner: draft-ietf-sfc-architecture@tools.ietf.org => draft-ietf-sfc- nsh@tools.ietf.org * component: architecture => nsh -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:02 2015 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 E49701A033A for ; Mon, 27 Apr 2015 23:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 qF1lnuIlvWs5 for ; Mon, 27 Apr 2015 23:25:01 -0700 (PDT) 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 EFB9C1A0302 for ; Mon, 27 Apr 2015 23:25:00 -0700 (PDT) Received: from localhost ([::1]:36491 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ymyx2-0000Bl-NQ; Mon, 27 Apr 2015 23:25:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:25:00 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/3#comment:1 Message-ID: <081.163c1686d9d4a6ae954c27ca5127e13e@tools.ietf.org> References: <066.14ca8ce4f270e903788e6adeabbba119@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <066.14ca8ce4f270e903788e6adeabbba119@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, 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: <20150428062500.EFB9C1A0302@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:25:00 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 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: Tue, 28 Apr 2015 06:25:02 -0000 #3: Critical Metadata Changes (by mohamed.boucadair@orange.com): * owner: draft-ietf-sfc-architecture@tools.ietf.org => draft-ietf-sfc- nsh@tools.ietf.org * component: architecture => nsh -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:05 2015 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 E00E01A0302 for ; Mon, 27 Apr 2015 23:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RPEFUH-qRSiP for ; Mon, 27 Apr 2015 23:25:14 -0700 (PDT) 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 DB04F1A026A for ; Mon, 27 Apr 2015 23:25:14 -0700 (PDT) Received: from localhost ([::1]:36513 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmyxG-0001Jt-IJ; Mon, 27 Apr 2015 23:25:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:25:14 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/2#comment:1 Message-ID: <081.4befa7e65666839fa07578ce23ec2be9@tools.ietf.org> References: <066.57688ed370fb3d48421c401186ce86e2@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <066.57688ed370fb3d48421c401186ce86e2@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, 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: <20150428062514.DB04F1A026A@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:25:14 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 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: Tue, 28 Apr 2015 06:25:16 -0000 #2: Remove "MD Type" field and the companion "MD-type 1" Changes (by mohamed.boucadair@orange.com): * owner: draft-ietf-sfc-architecture@tools.ietf.org => draft-ietf-sfc- nsh@tools.ietf.org * component: architecture => nsh -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:06 2015 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 935021A033A for ; Mon, 27 Apr 2015 23:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 xLz-TCcAxfLP for ; Mon, 27 Apr 2015 23:30:04 -0700 (PDT) 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 166221A0302 for ; Mon, 27 Apr 2015 23:30:04 -0700 (PDT) Received: from localhost ([::1]:36674 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ymz1v-00039V-PM; Mon, 27 Apr 2015 23:30:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:30:03 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/6 Message-ID: <066.8561377e24c78d3c8295cd0e6d7bd8c2@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.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: <20150428063004.166221A0302@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:30:04 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:48 -0700 Cc: sfc@ietf.org Subject: [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: Tue, 28 Apr 2015 06:30:05 -0000 #6: Version Handling Add text to specify the behavior to handle multiple versions. (this was initially discussed in this thread: http://www.ietf.org/mail- archive/web/sfc/current/msg03149.html) -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:07 2015 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 88E7E1A0371 for ; Mon, 27 Apr 2015 23:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 xEwdFQk65gd1 for ; Mon, 27 Apr 2015 23:38:47 -0700 (PDT) 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 6DED21A0368 for ; Mon, 27 Apr 2015 23:38:47 -0700 (PDT) Received: from localhost ([::1]:36928 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmzAM-0001yb-VF; Mon, 27 Apr 2015 23:38:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:38:46 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/7 Message-ID: <066.dafbe86a757020b74be2315dfebcbc54@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.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: <20150428063847.6DED21A0368@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:38:47 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:49 -0700 Cc: sfc@ietf.org Subject: [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: Tue, 28 Apr 2015 06:38:48 -0000 #7: reserved bits Add the following text to Section 3.2: "Reserved bits MUST each be sent as zero and MUST be ignored on receipt. These bits are for future assignments." -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:09 2015 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 A41A11A03A8 for ; Mon, 27 Apr 2015 23:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 MRCmwL9Dbnz8 for ; Mon, 27 Apr 2015 23:43:56 -0700 (PDT) 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 C42D41A0385 for ; Mon, 27 Apr 2015 23:43:56 -0700 (PDT) Received: from localhost ([::1]:37028 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmzFM-0002mz-Gp; Mon, 27 Apr 2015 23:43:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:43:56 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/8 Message-ID: <066.969ddfabf67e8a3073f055340f62e477@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.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: <20150428064356.C42D41A0385@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:43:56 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:49 -0700 Cc: sfc@ietf.org Subject: [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: Tue, 28 Apr 2015 06:43:57 -0000 #8: Use cases Refer to http://www.ietf.org/mail-archive/web/sfc/current/msg03298.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:10 2015 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 AD3FF1A0371 for ; Mon, 27 Apr 2015 23:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 2mff6ad531Ne for ; Mon, 27 Apr 2015 23:45:57 -0700 (PDT) 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 CA0F81A09C9 for ; Mon, 27 Apr 2015 23:45:40 -0700 (PDT) Received: from localhost ([::1]:37106 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmzH2-0003Bp-GN; Mon, 27 Apr 2015 23:45:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:45:40 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/9 Message-ID: <066.81933c034d2c9105bb9eaff8099e42b5@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.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: <20150428064540.CA0F81A09C9@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:45:40 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:49 -0700 Cc: sfc@ietf.org Subject: [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: Tue, 28 Apr 2015 06:45:57 -0000 #9: Remove Section 2.2 Replace this section with a reference to RFC7498. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: nsh | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 04:37:11 2015 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 49D7A1A03A8 for ; Mon, 27 Apr 2015 23:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 nstQGWZs7aD2 for ; Mon, 27 Apr 2015 23:47:43 -0700 (PDT) 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 18F621A0371 for ; Mon, 27 Apr 2015 23:47:43 -0700 (PDT) Received: from localhost ([::1]:37169 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YmzJ0-0004vi-Sh; Mon, 27 Apr 2015 23:47:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Tue, 28 Apr 2015 06:47:42 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/10 Message-ID: <066.4a7c25827b552bb17bd63ab15d1a3d06@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.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: <20150428064743.18F621A0371@ietfa.amsl.com> Resent-Date: Mon, 27 Apr 2015 23:47:43 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 04:36:49 -0700 Cc: sfc@ietf.org Subject: [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: Tue, 28 Apr 2015 06:47:44 -0000 #10: O bit The following text is underspecified: " O bit: Indicates that this packet is an operations and management (OAM) packet. SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. " Either you specify the exact behavior to follow when sending this bit and when receiving it or you clear the bit and mark it as reserved. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Tue Apr 28 07:36:28 2015 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 CBC661A7032 for ; Tue, 28 Apr 2015 07:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DXtBNcWbWKNl for ; Tue, 28 Apr 2015 07:36:22 -0700 (PDT) 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 A25271A01F9 for ; Tue, 28 Apr 2015 07:36:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 20425240609; Tue, 28 Apr 2015 07:36:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-97-72.public.wayport.net [64.134.97.72]) (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 D1ED22404F5; Tue, 28 Apr 2015 07:36:15 -0700 (PDT) Message-ID: <553F9AD6.7030708@joelhalpern.com> Date: Tue, 28 Apr 2015 10:36:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sfc issue tracker , draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com References: <066.57688ed370fb3d48421c401186ce86e2@tools.ietf.org> In-Reply-To: <066.57688ed370fb3d48421c401186ce86e2@tools.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #2 (architecture): Remove "MD Type" field and the companion "MD-type 1" 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, 28 Apr 2015 14:36:27 -0000 This is an NSH question, not an Architecture draft question. Yours, Joel On 4/28/15 2:08 AM, sfc issue tracker wrote: > #2: Remove "MD Type" field and the companion "MD-type 1" > > I already send an email back in February to ask about the following but I > didn't got any answer > > == > What is the rationale for defining two MD Types? Why MD Type#1 is > mandatory to support? Wouldn’t the format in Section 3.5 enough for the > SFC use cases? > What is the rationale for defining these mandatory contexts headers? What > is the motivation for defining mandatory context header? > > The current text does not explain those aspects. > == > > For the sake of interoperability (mainly to avoid multiple implementations > with distinct behaviors) and given no technical motivation is provided > (e.g. why MD-type 1 is mandatory why not the other way around, etc. ), one > header format should be specified. > > My personal point of view is that we need to choose. I’m personally for a > minimalist header. Leaving both induces more complexity. > > I suggest to remove the "MD type" field and MD-type 1 from the > specification. > > Moreover, I don’t understand from the draft what is the rationale for > classifying the context into these four categories. What is meant by > “platform-specific metadata” or “service platform specific”? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Network Platform Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Network Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Platform Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Shared Context | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > From nobody Tue Apr 28 07:37:07 2015 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 E4E481ACE49 for ; Tue, 28 Apr 2015 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Id5oAFf-QMMx for ; Tue, 28 Apr 2015 07:37:03 -0700 (PDT) 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 A27D61ACE2A for ; Tue, 28 Apr 2015 07:37:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7EABA24FEC2; Tue, 28 Apr 2015 07:37:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-97-72.public.wayport.net [64.134.97.72]) (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 068352404A0; Tue, 28 Apr 2015 07:36:54 -0700 (PDT) Message-ID: <553F9AFB.9000503@joelhalpern.com> Date: Tue, 28 Apr 2015 10:36:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sfc issue tracker , draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com References: <066.14ca8ce4f270e903788e6adeabbba119@tools.ietf.org> In-Reply-To: <066.14ca8ce4f270e903788e6adeabbba119@tools.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #3 (architecture): Critical 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: Tue, 28 Apr 2015 14:37:06 -0000 This is also an NSH quesiton, not an architecture question. The architecture does not define any codepoint ranges. Yours, Joel On 4/28/15 2:18 AM, sfc issue tracker wrote: > #3: Critical Metadata > > The document defines two codepoint ranges: one for “critical” (128 to 255) > and another one “no critical” metadata (0 to 127). > > This terminology is confusing given the “criticality” of a metadata is > deployment-specific and SFC-specific. Thats is a piece of information may > be required for a given chain but may not be critical for another one. > > The specification does not explain why there will be mandatory-to- > implement metadata by design. Shouldn’t this be achieved by configuration > locally to each SFC-aware element? > > Furthermore, the current text says: > > If a receiver receives an encapsulated packet containing a TLV with > the Critical bit set in the Type field and it does not understand how > to process the Type, it MUST drop the packet. Transit devices MUST > NOT drop packets based on the setting of this bit. > > Dropping the packet without even sending a notification to the sender or a > control element is too aggressive IMHO. Such behavior will lead to more > service degradation when SFC in enabled compared to current service > deployment schemes. > From nobody Tue Apr 28 07:38:56 2015 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 96C231ACE74 for ; Tue, 28 Apr 2015 07:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z2Yed9peuycG for ; Tue, 28 Apr 2015 07:38:53 -0700 (PDT) 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 1A55C1ACE1B for ; Tue, 28 Apr 2015 07:38:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0A036240652; Tue, 28 Apr 2015 07:38:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-97-72.public.wayport.net [64.134.97.72]) (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 2C2EE2404A0; Tue, 28 Apr 2015 07:38:48 -0700 (PDT) Message-ID: <553F9B6E.5000804@joelhalpern.com> Date: Tue, 28 Apr 2015 10:38:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sfc issue tracker , draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com References: <066.3f738fef7fe087aec0f60795f1d4b3ad@tools.ietf.org> In-Reply-To: <066.3f738fef7fe087aec0f60795f1d4b3ad@tools.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #4 (architecture): Reuse the IPFIX registry for identifying context types 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, 28 Apr 2015 14:38:55 -0000 And this is also an NSH issue, not an architecture issue. As an NSH issue, I have serious concerns with this proposed reuse. The two lists of things which need to be identified and the way such information is to be used are quite different, although they have a small overlap. Efforts to reuse other registries in the presence of small overlap have proven problematic. Yours, Joel On 4/28/15 2:22 AM, sfc issue tracker wrote: > #4: Reuse the IPFIX registry for identifying context types > > Given IPFIX defines a large set of attributes > (https://www.ietf.org/assignments/ipfix/ipfix.xml), wouldn't be optimal to > reuse that registery for SFC purposes? > From nobody Tue Apr 28 07:41:03 2015 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 2C7711ACE74 for ; Tue, 28 Apr 2015 07:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CX1vhb3EOlE9 for ; Tue, 28 Apr 2015 07:41:01 -0700 (PDT) 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 14E511A877B for ; Tue, 28 Apr 2015 07:41:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 049272402BF; Tue, 28 Apr 2015 07:41:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-97-72.public.wayport.net [64.134.97.72]) (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 5C36E240351; Tue, 28 Apr 2015 07:40:55 -0700 (PDT) Message-ID: <553F9BEC.3010301@joelhalpern.com> Date: Tue, 28 Apr 2015 10:40:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sfc issue tracker , draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com References: <066.a8499ce61f6f39c3c1a400b86c706359@tools.ietf.org> In-Reply-To: <066.a8499ce61f6f39c3c1a400b86c706359@tools.ietf.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #5 (architecture): Support of SF Spirals 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, 28 Apr 2015 14:41:02 -0000 The email pointed to is an NSH email, not an architecture email. As an NSH issue, I believe that the SFP Index addresses the technical requirement. The editorial question is whether it would be helpful to make it more clear that the NSH SFP Index provides what is needed. Yours, Joel On 4/28/15 2:24 AM, sfc issue tracker wrote: > #5: Support of SF Spirals > > Refer to this thread: http://www.ietf.org/mail- > archive/web/sfc/current/msg03179.html > From nobody Tue Apr 28 10:47:32 2015 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 5A8631A036F for ; Tue, 28 Apr 2015 10:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 egb7e7UyZ9EZ for ; Tue, 28 Apr 2015 10:47:29 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB6C1A1A8F for ; Tue, 28 Apr 2015 10:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1270; q=dns/txt; s=iport; t=1430243248; x=1431452848; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fcXFRnZOxaW+L1PV8msyVT9rCzyiWMOGtKRboV27jtc=; b=jwlX8q919Y+vNHvedWZMa1HVzOnFHEGaaV4wlF9Kijad2MLd4o1qHouu M+0ISOadg1bneGwLUXVZbBCZa3udBs56iz2eOlOs505w9mwK+N8IbASPu 61JssKACTm74Yk9AugQaTo5rIhQAjq+rBjVy9ZYW0QlpfdR6u84ITGQsx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DSBAB1xj9V/4kNJK1cgwxTXAXHEgmBSQqGBAKBOzgUAQEBAQEBAYEKhCEBAQQBAQE3LQcLEAIBCBgeECcLJQIEAQ0FiCsNx0sBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs4hQUHhC0BBI9CgiOKP5VsI2CBBYIPb4FEgQEBAQE X-IronPort-AV: E=Sophos;i="5.11,665,1422921600"; d="scan'208";a="145323010" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2015 17:47:27 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3SHlRVA013864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 17:47:27 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 12:47:27 -0500 From: "Surendra Kumar (smkumar)" To: Benson Schliesser , "Larry Kreeger (kreeger)" , "Jim Guichard (jguichar)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAADuJAA== Date: Tue, 28 Apr 2015 17:47:26 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: <553F334D.2050907@queuefull.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.80.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <18A9770812B47E42BA91DAF8AAA3E397@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 17:47:30 -0000 Thanks Benson, Larry! I will produce a draft for both the UDP port# and the ether-type and publish it within SFC WG based on the comments so far. The chairs can move it to the appropriate WG if they think otherwise. Surendra. On 4/28/15, 12:14 AM, "Benson Schliesser" wrote: >Hi, Larry and Jim - > >Larry Kreeger (kreeger) wrote: >> If someone wanted to write a draft specifying how to carry NSH over >> UDP, what WG would it be submitted to? > >As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example >of a NSH-capable transport. I think this is a good example of what Jim >described as a "relevant WG for a given transport". > >But in the case of NSH carried directly in UDP, it seems to me that (as >Larry described) this is normally described in the protocol document >itself. Since NSH is intentionally flexible with regards to underlying >transport, I can imagine this being a companion document rather than >embedded in the NSH text. But in either case I think it makes the most >sense for the SFC WG to be the home for such a definition. > >Cheers, >-Benson > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 28 11:05:58 2015 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 E236B1B2B54 for ; Tue, 28 Apr 2015 11:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 kYrXrrkogysY for ; Tue, 28 Apr 2015 11:05:54 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350AA1A8BC4 for ; Tue, 28 Apr 2015 11:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1344; q=dns/txt; s=iport; t=1430244354; x=1431453954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RWUkJA4xl3az3wwvg5fPD9WA0OOkRKL3pEzOMCc6tFE=; b=hVfpjzRbggDALoe6osBGKy/MaIqaS8qsklsswSuRd8gkmhiWc0dViMQn uPPwHONxhrnME54ONUz8+8E+5BdOZDNhyWFCTjIvBgfKnxDCJptKKvPF5 Eo44P42jirK1epwS1IwjLgTRvNrl21jW7WJNwArA2gg8/q+I2pPkpB8uE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CgBQB1yj9V/4ENJK1cgwyBLwXOcgKBO0wBAQEBAQGBC4QhAQEEZxIQAgEIGC4yJQIEAQ0FiCvHWgEBAQEBAQEBAQEBAQEBAQEBAQEZiziFBQeELQEEizaGL4o/lWwjYIEFgg9vgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,665,1422921600"; d="scan'208";a="412351938" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP; 28 Apr 2015 18:05:53 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3SI5qZt015844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 18:05:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.245]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 13:05:52 -0500 From: "Jim Guichard (jguichar)" To: Benson Schliesser , "Larry Kreeger (kreeger)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAAHL4AA== Date: Tue, 28 Apr 2015 18:05:51 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: <553F334D.2050907@queuefull.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 18:05:56 -0000 Hi Benson, I think a separate companion document is probably the right way forward in this case. RFC 7510 (MPLS in UDP) is perhaps a good example of how this has been dealt with before. The key here is that the SFC encapsulation remain transport independent and having a companion document for UDP and other encapsulations in their respective WG=B9s (such as VXLAN-GPE in NVO3 as you pointed out) satisfies this requirement. Jim On 4/28/15, 3:14 AM, "Benson Schliesser" wrote: >Hi, Larry and Jim - > >Larry Kreeger (kreeger) wrote: >> If someone wanted to write a draft specifying how to carry NSH over >> UDP, what WG would it be submitted to? > >As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example >of a NSH-capable transport. I think this is a good example of what Jim >described as a "relevant WG for a given transport". > >But in the case of NSH carried directly in UDP, it seems to me that (as >Larry described) this is normally described in the protocol document >itself. Since NSH is intentionally flexible with regards to underlying >transport, I can imagine this being a companion document rather than >embedded in the NSH text. But in either case I think it makes the most >sense for the SFC WG to be the home for such a definition. > >Cheers, >-Benson From nobody Tue Apr 28 12:27:39 2015 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 3B1EA1A1A7B for ; Tue, 28 Apr 2015 12:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 AeeZWV8YwWoy for ; Tue, 28 Apr 2015 12:27:36 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5481A1A55 for ; Tue, 28 Apr 2015 12:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2464; q=dns/txt; s=iport; t=1430249255; x=1431458855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Uy9AfiNCexOBno+5C+sUoNulFEdxbNI4o7WKfq1DXkY=; b=hgBtUQydJpe1n6yu/R13r0Xg7aESg58pICr2NaQN1r4xDei+cw1/HIZB J1bpn51kWQE2kgS9wiW5Q0CQWNF/42paYHPvzK+RF4YIDeTvQh5a2fH7L uU/IhixHnDFEwbEOlGC6ReSrqSA4LDgCM9Ai5JIK4vImEjgvE+KIFufdF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DUBADg3j9V/5tdJa1cgwxTXAWDFcN9CYFJCoYEAhyBHzgUAQEBAQEBAYEKhCEBAQQBAQExMwcLEAIBCBgEKAICJQslAgQBDQWIKw2WTpx8BpQHAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBG4odhQUHgmKBSwWPQoIjij+VbCNggQWCD2+BRIEBAQEB X-IronPort-AV: E=Sophos;i="5.11,665,1422921600"; d="scan'208";a="145305354" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 28 Apr 2015 19:27:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3SJRHee015017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 19:27:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.196]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 14:27:17 -0500 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , Benson Schliesser , "Larry Kreeger (kreeger)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAAHL4AP//5HYA Date: Tue, 28 Apr 2015 19:27:16 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.33.135] Content-Type: text/plain; charset="euc-kr" Content-ID: <9FFF02018FA7344CAAC39C807D444CBB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 19:27:37 -0000 DQpJIHRoYXQgc3Bpcml0LCB3ZSBzaG91bGQgbm90IGluY2x1ZGUgZXhhbXBsZXMgb2YgZW5jYXBz dWxhdGlvbiBpbiBOU0ggYW5kDQpsZXQgdGhlc2UgY29tcGFuaW9uIGRyYWZ0cyBkbyB0aGF0Lg0K U3BlY2lmaWNhbGx5LCBhcyBkaXNjdXNzZWQgbGFzdCB3ZWVrLCBzZWN0aW9uIDExIGNvbmZsaWN0 cyB3aXRoIHRoaXMNCnJlcXVpcmVtZW50Lg0KDQpTdXJlbmRyYS4NCg0KT24gNC8yOC8xNSwgMTE6 MDUgQU0sICJKaW0gR3VpY2hhcmQgKGpndWljaGFyKSIgPGpndWljaGFyQGNpc2NvLmNvbT4gd3Jv dGU6DQoNCj5IaSBCZW5zb24sDQo+DQo+SSB0aGluayBhIHNlcGFyYXRlIGNvbXBhbmlvbiBkb2N1 bWVudCBpcyBwcm9iYWJseSB0aGUgcmlnaHQgd2F5IGZvcndhcmQgaW4NCj50aGlzIGNhc2UuIFJG QyA3NTEwIChNUExTIGluIFVEUCkgaXMgcGVyaGFwcyBhIGdvb2QgZXhhbXBsZSBvZiBob3cgdGhp cw0KPmhhcyBiZWVuIGRlYWx0IHdpdGggYmVmb3JlLiBUaGUga2V5IGhlcmUgaXMgdGhhdCB0aGUg U0ZDIGVuY2Fwc3VsYXRpb24NCj5yZW1haW4gdHJhbnNwb3J0IGluZGVwZW5kZW50IGFuZCBoYXZp bmcgYSBjb21wYW5pb24gZG9jdW1lbnQgZm9yIFVEUCBhbmQNCj5vdGhlciBlbmNhcHN1bGF0aW9u cyBpbiB0aGVpciByZXNwZWN0aXZlIFdHqfZzIChzdWNoIGFzIFZYTEFOLUdQRSBpbiBOVk8zDQo+ YXMgeW91IHBvaW50ZWQgb3V0KSBzYXRpc2ZpZXMgdGhpcyByZXF1aXJlbWVudC4NCj4NCj5KaW0N Cj4NCj5PbiA0LzI4LzE1LCAzOjE0IEFNLCAiQmVuc29uIFNjaGxpZXNzZXIiIDxiZW5zb25zQHF1 ZXVlZnVsbC5uZXQ+IHdyb3RlOg0KPg0KPj5IaSwgTGFycnkgYW5kIEppbSAtDQo+Pg0KPj5MYXJy eSBLcmVlZ2VyIChrcmVlZ2VyKSB3cm90ZToNCj4+PiBJZiBzb21lb25lIHdhbnRlZCB0byB3cml0 ZSBhIGRyYWZ0IHNwZWNpZnlpbmcgaG93IHRvIGNhcnJ5IE5TSCBvdmVyDQo+Pj4gVURQLCB3aGF0 IFdHIHdvdWxkIGl0IGJlIHN1Ym1pdHRlZCB0bz8NCj4+DQo+PkFzIHlvdSBwcm9iYWJseSBrbm93 LCBOVk8zIFdHIGhhcyBhZG9wdGVkIFZYTEFOLUdQRSB3aGljaCBpcyBhbiBleGFtcGxlDQo+Pm9m IGEgTlNILWNhcGFibGUgdHJhbnNwb3J0LiBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIGV4YW1wbGUg b2Ygd2hhdCBKaW0NCj4+ZGVzY3JpYmVkIGFzIGEgInJlbGV2YW50IFdHIGZvciBhIGdpdmVuIHRy YW5zcG9ydCIuDQo+Pg0KPj5CdXQgaW4gdGhlIGNhc2Ugb2YgTlNIIGNhcnJpZWQgZGlyZWN0bHkg aW4gVURQLCBpdCBzZWVtcyB0byBtZSB0aGF0IChhcw0KPj5MYXJyeSBkZXNjcmliZWQpIHRoaXMg aXMgbm9ybWFsbHkgZGVzY3JpYmVkIGluIHRoZSBwcm90b2NvbCBkb2N1bWVudA0KPj5pdHNlbGYu IFNpbmNlIE5TSCBpcyBpbnRlbnRpb25hbGx5IGZsZXhpYmxlIHdpdGggcmVnYXJkcyB0byB1bmRl cmx5aW5nDQo+PnRyYW5zcG9ydCwgSSBjYW4gaW1hZ2luZSB0aGlzIGJlaW5nIGEgY29tcGFuaW9u IGRvY3VtZW50IHJhdGhlciB0aGFuDQo+PmVtYmVkZGVkIGluIHRoZSBOU0ggdGV4dC4gQnV0IGlu IGVpdGhlciBjYXNlIEkgdGhpbmsgaXQgbWFrZXMgdGhlIG1vc3QNCj4+c2Vuc2UgZm9yIHRoZSBT RkMgV0cgdG8gYmUgdGhlIGhvbWUgZm9yIHN1Y2ggYSBkZWZpbml0aW9uLg0KPj4NCj4+Q2hlZXJz LA0KPj4tQmVuc29uDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Tue Apr 28 13:43:25 2015 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 D64F21A8849 for ; Tue, 28 Apr 2015 13:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 weyriyxhKrTV for ; Tue, 28 Apr 2015 13:43:22 -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 E99C61A0068 for ; Tue, 28 Apr 2015 13:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1430253802; x=1431463402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3fdOUkUcHOFJk+3PKgEeIaKX6a8KIQBinVHVWSvU7mA=; b=Gw0SxlwJgzeyoZykX9fXlagmaVTDFw4vmcpQWGfyOp5IT/stiyf/Q3YC 3AtGv1FCOL5fED7V8J2+7AdqcnliVt5TJvKZw01MA1bUCly25GB8vW6Y7 qi3BBmmBPXkL97LyaRUAYYLnFjeuxR4rNpqsCNE8zHsndtGoBSnrrPlNf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DSBAAP8D9V/4kNJK1cgwxTXAXHEwmBSQqGBAKBOzgUAQEBAQEBAYEKhCABAQEDAQEBATctBwsFCwIBCBgeECcLJQIEDgWIIwgNxzgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs4hFIzB4MXgRYFkWWKP5VsI2CBBYIPb4FEgQEBAQE X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208";a="145391995" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 28 Apr 2015 20:43:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3SKhLN4008704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 20:43:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.216]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 15:43:21 -0500 From: "Paul Quinn (paulq)" To: Benson Schliesser Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAAOI/gA== Date: Tue, 28 Apr 2015 20:43:20 +0000 Message-ID: <79CF9269-9CC0-40B5-B988-B6903D24EAD4@cisco.com> References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: <553F334D.2050907@queuefull.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <50FA10602A513F46A55D1B11D1238953@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Larry Kreeger \(kreeger\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 20:43:24 -0000 Benson, We should keep the strict separation of NSH and the transports. So, in the= case of VXLAN-GPE, we submitted it to NVO3 since GPE falls under the chart= er of that group. If there's a need for a UDP only draft, it belongs eithe= r under transport, or as an individual submission, not SFC. To keep things consistent, I'm happy to remove the ethertype allocation fro= m draft-nsh, and simply leave that allocation with IEEE. I am surprised that having some examples in the draft is causing consternat= ion. In my experience having those examples helped explain the stack, was = something that folks asked about frequently and does not in any way promote= or advocate for a given transport. If the WG wants to give up that clarit= y then the draft can be updated accordingly. Thanks Paul > On Apr 28, 2015, at 3:14 AM, Benson Schliesser wr= ote: >=20 > Hi, Larry and Jim - >=20 > Larry Kreeger (kreeger) wrote: >> If someone wanted to write a draft specifying how to carry NSH over=20 >> UDP, what WG would it be submitted to? >=20 > As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example > of a NSH-capable transport. I think this is a good example of what Jim > described as a "relevant WG for a given transport". >=20 > But in the case of NSH carried directly in UDP, it seems to me that (as > Larry described) this is normally described in the protocol document > itself. Since NSH is intentionally flexible with regards to underlying > transport, I can imagine this being a companion document rather than > embedded in the NSH text. But in either case I think it makes the most > sense for the SFC WG to be the home for such a definition. >=20 > Cheers, > -Benson >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 28 13:59:14 2015 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 2C2061A899F for ; Tue, 28 Apr 2015 13:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N6zVpmg-n7PK for ; Tue, 28 Apr 2015 13:59:05 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 8DE401A8A85 for ; Tue, 28 Apr 2015 13:57:09 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id B6D9C36CBF6F8; Tue, 28 Apr 2015 20:57:04 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t3SKv5cX003732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 16:57:05 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 16:57:05 -0400 From: "Dolganow, Andrew (Andrew)" To: "Paul Quinn (paulq)" , Benson Schliesser Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W0dCAgAJqwgCAAKgP9YAA0vqAgAAsEQCAAAm1gIAHCGGAgABbtYCAAOIHAP//wMUA Date: Tue, 28 Apr 2015 20:57:05 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> <79CF9269-9CC0-40B5-B988-B6903D24EAD4@cisco.com> In-Reply-To: <79CF9269-9CC0-40B5-B988-B6903D24EAD4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <37C23AA400BE8144B092BE925EBB63DC@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Larry Kreeger \(kreeger\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 20:59:09 -0000 How about we mark the text as informational in the nsh draft, once drafts for transports are accpeted, we can refer to those as examples? Andrew On 2015-04-28, 4:43 PM, "Paul Quinn (paulq)" wrote: >Benson, > >We should keep the strict separation of NSH and the transports. So, in >the case of VXLAN-GPE, we submitted it to NVO3 since GPE falls under the >charter of that group. If there's a need for a UDP only draft, it >belongs either under transport, or as an individual submission, not SFC. > >To keep things consistent, I'm happy to remove the ethertype allocation >from draft-nsh, and simply leave that allocation with IEEE. > >I am surprised that having some examples in the draft is causing >consternation. In my experience having those examples helped explain the >stack, was something that folks asked about frequently and does not in >any way promote or advocate for a given transport. If the WG wants to >give up that clarity then the draft can be updated accordingly. > >Thanks >Paul > > >> On Apr 28, 2015, at 3:14 AM, Benson Schliesser >>wrote: >>=20 >> Hi, Larry and Jim - >>=20 >> Larry Kreeger (kreeger) wrote: >>> If someone wanted to write a draft specifying how to carry NSH over >>> UDP, what WG would it be submitted to? >>=20 >> As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example >> of a NSH-capable transport. I think this is a good example of what Jim >> described as a "relevant WG for a given transport". >>=20 >> But in the case of NSH carried directly in UDP, it seems to me that (as >> Larry described) this is normally described in the protocol document >> itself. Since NSH is intentionally flexible with regards to underlying >> transport, I can imagine this being a companion document rather than >> embedded in the NSH text. But in either case I think it makes the most >> sense for the SFC WG to be the home for such a definition. >>=20 >> Cheers, >> -Benson >>=20 >> _______________________________________________ >> 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 Tue Apr 28 14:04:05 2015 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 3C2501A88F1 for ; Tue, 28 Apr 2015 14:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 epLj02J-lNYI for ; Tue, 28 Apr 2015 14:04:02 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 EB0471A8927 for ; Tue, 28 Apr 2015 14:03:08 -0700 (PDT) Received: by wiun10 with SMTP id n10so43913987wiu.1 for ; Tue, 28 Apr 2015 14:03:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8NwSqWWwV1U6hKLGf64Fu2GfxkfVLR9SA7x6P7bBd1g=; b=H/tl3nzVErRpldigQWt9cG/M/hunrjlWIZEftrcFIj9xgAxqs3NQQ+KKTlIoAwOoan ukADnCTcfKwhotKlNjkPe0UXYCmOvf9nBdSc7zxICNYPB5Vv5a2ai2/agaSi/JttPzO1 vC9BUILlp8U2jAUcMnJr/rJWXZpqjuX4pHDLHMBFFpHZJDTcObwqA30wReeeVQkIIJyY gRq52Bk3bn0+q2Atev9PqcN6JPtvj9t/rAfFuTLavxjMz/Bel4JOdfDYrngwS7/Tw15v Nkk114aQAzMbg/Lppa8X3iv035A1lojbwpLNFF0h6D5a87CZjSj9Mw6kN38wr7KUXjBf oV4A== X-Gm-Message-State: ALoCoQlxvXd2RCH4n5JH0BJDtXppgkYHzAS/n60BXtXZG+3W2HclmfBgT/0bChNTT5v4xFRQPMXL X-Received: by 10.194.78.49 with SMTP id y17mr36551050wjw.131.1430254987718; Tue, 28 Apr 2015 14:03:07 -0700 (PDT) Received: from fallout-4.local ([109.144.233.47]) by mx.google.com with ESMTPSA id ei8sm35953508wjd.32.2015.04.28.14.03.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 14:03:06 -0700 (PDT) Message-ID: <553FF58D.8040401@queuefull.net> Date: Tue, 28 Apr 2015 22:03:09 +0100 From: Benson Schliesser User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Paul Quinn (paulq)" References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> <79CF9269-9CC0-40B5-B988-B6903D24EAD4@cisco.com> In-Reply-To: <79CF9269-9CC0-40B5-B988-B6903D24EAD4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Jim Guichard \(jguichar\)" , "Larry Kreeger \(kreeger\)" , "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 21:04:03 -0000 Hi, Paul. Paul Quinn (paulq) wrote: > We should keep the strict separation of NSH and the transports. So, > in the case of VXLAN-GPE, we submitted it to NVO3 since GPE falls > under the charter of that group. If there's a need for a UDP only > draft, it belongs either under transport, or as an individual > submission, not SFC. For whatever it's worth, I don't really have a strong opinion about this. My earlier comments were simply noting how it is sometimes done. As far as I'm concerned, any choice (of document and/or WG) is good as long as it gets the appropriate review and can be cleanly referenced. And I trust the SFC chairs and NSH authors to figure this out. Cheers, -Benson From nobody Tue Apr 28 15:03:51 2015 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 0A1F11A8AAA for ; Tue, 28 Apr 2015 15:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 0ZL9FjyqwcJV for ; Tue, 28 Apr 2015 15:03:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620021A8ABB for ; Tue, 28 Apr 2015 15:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2382; q=dns/txt; s=iport; t=1430258625; x=1431468225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oa8SlL/B+SYtFZ1nP1s9zcZxPOh97cGFrZg4lPRwsio=; b=SZfCPIE8zBxFes6DbJrJFUXbCGr3Gwlv3rorgDkDY3460ICevK6c/ew/ nvL1TG7FwqEMkqVlNW3v0MlMh6iZZQbPmpuOPJVyWJyr2MRDaNdtrP7ha u86n9+1MgD0C2+PMCB2viCdjEqU4ZThQP0QOMtdDjx/UPdW2e7q89dQbz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQBtA0BV/5RdJa1cgwyBLwWDFctkAhyBIUwBAQEBAQGBC4QhAQEENDMSEAIBCBgEKAICMCUCBAENBYgrlj2cfAaUFQEBAQEBAQEBAQEBAQEBAQEBAQEZgRuKHYRSMweCYoFLAQSRZYo/lWwjYIEFgg9vgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208";a="415525789" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 28 Apr 2015 22:03:44 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t3SM3iHQ012195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 22:03:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.245]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 17:03:44 -0500 From: "Larry Kreeger (kreeger)" To: "Jim Guichard (jguichar)" , Benson Schliesser Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAAHL4AIAAECsA Date: Tue, 28 Apr 2015 22:03:43 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="euc-kr" Content-ID: <355E0CD64200B2429256F79DF454EDD1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 22:03:50 -0000 SGkgSmltLA0KDQpXYXNuJ3QgUkZDNzUxMCBhZG9wdGVkIGJ5IHRoZSBNUExTIFdHPyAgSWYgc28s IHRoaXMgd2FzIHRoZSBXRyByZXNwb25zaWJsZQ0KZm9yIHRoZSBwcm90b2NvbCAoTVBMUykgcnVu bmluZyBvdmVyIFVEUC4gRG8geW91IGhhdmUgYW4gZXhhbXBsZSB3aGVyZSB0aGUNCnByb3RvY29s IHJ1bm5pbmcgb3ZlciBVRFAgd2FzIGFkb3B0ZWQgYnkgYSBXRyBub3QgcmVzcG9uc2libGUgZm9y IHRoZQ0KcHJvdG9jb2wgcnVubmluZyBvdmVyIFVEUD8NCg0KVGhhbmtzLCBMYXJyeQ0KDQpPbiA0 LzI4LzE1IDExOjA1IEFNLCAiSmltIEd1aWNoYXJkIChqZ3VpY2hhcikiIDxqZ3VpY2hhckBjaXNj by5jb20+IHdyb3RlOg0KDQo+SGkgQmVuc29uLA0KPg0KPkkgdGhpbmsgYSBzZXBhcmF0ZSBjb21w YW5pb24gZG9jdW1lbnQgaXMgcHJvYmFibHkgdGhlIHJpZ2h0IHdheSBmb3J3YXJkIGluDQo+dGhp cyBjYXNlLiBSRkMgNzUxMCAoTVBMUyBpbiBVRFApIGlzIHBlcmhhcHMgYSBnb29kIGV4YW1wbGUg b2YgaG93IHRoaXMNCj5oYXMgYmVlbiBkZWFsdCB3aXRoIGJlZm9yZS4gVGhlIGtleSBoZXJlIGlz IHRoYXQgdGhlIFNGQyBlbmNhcHN1bGF0aW9uDQo+cmVtYWluIHRyYW5zcG9ydCBpbmRlcGVuZGVu dCBhbmQgaGF2aW5nIGEgY29tcGFuaW9uIGRvY3VtZW50IGZvciBVRFAgYW5kDQo+b3RoZXIgZW5j YXBzdWxhdGlvbnMgaW4gdGhlaXIgcmVzcGVjdGl2ZSBXR6n2cyAoc3VjaCBhcyBWWExBTi1HUEUg aW4gTlZPMw0KPmFzIHlvdSBwb2ludGVkIG91dCkgc2F0aXNmaWVzIHRoaXMgcmVxdWlyZW1lbnQu DQo+DQo+SmltDQo+DQo+T24gNC8yOC8xNSwgMzoxNCBBTSwgIkJlbnNvbiBTY2hsaWVzc2VyIiA8 YmVuc29uc0BxdWV1ZWZ1bGwubmV0PiB3cm90ZToNCj4NCj4+SGksIExhcnJ5IGFuZCBKaW0gLQ0K Pj4NCj4+TGFycnkgS3JlZWdlciAoa3JlZWdlcikgd3JvdGU6DQo+Pj4gSWYgc29tZW9uZSB3YW50 ZWQgdG8gd3JpdGUgYSBkcmFmdCBzcGVjaWZ5aW5nIGhvdyB0byBjYXJyeSBOU0ggb3Zlcg0KPj4+ IFVEUCwgd2hhdCBXRyB3b3VsZCBpdCBiZSBzdWJtaXR0ZWQgdG8/DQo+Pg0KPj5BcyB5b3UgcHJv YmFibHkga25vdywgTlZPMyBXRyBoYXMgYWRvcHRlZCBWWExBTi1HUEUgd2hpY2ggaXMgYW4gZXhh bXBsZQ0KPj5vZiBhIE5TSC1jYXBhYmxlIHRyYW5zcG9ydC4gSSB0aGluayB0aGlzIGlzIGEgZ29v ZCBleGFtcGxlIG9mIHdoYXQgSmltDQo+PmRlc2NyaWJlZCBhcyBhICJyZWxldmFudCBXRyBmb3Ig YSBnaXZlbiB0cmFuc3BvcnQiLg0KPj4NCj4+QnV0IGluIHRoZSBjYXNlIG9mIE5TSCBjYXJyaWVk IGRpcmVjdGx5IGluIFVEUCwgaXQgc2VlbXMgdG8gbWUgdGhhdCAoYXMNCj4+TGFycnkgZGVzY3Jp YmVkKSB0aGlzIGlzIG5vcm1hbGx5IGRlc2NyaWJlZCBpbiB0aGUgcHJvdG9jb2wgZG9jdW1lbnQN Cj4+aXRzZWxmLiBTaW5jZSBOU0ggaXMgaW50ZW50aW9uYWxseSBmbGV4aWJsZSB3aXRoIHJlZ2Fy ZHMgdG8gdW5kZXJseWluZw0KPj50cmFuc3BvcnQsIEkgY2FuIGltYWdpbmUgdGhpcyBiZWluZyBh IGNvbXBhbmlvbiBkb2N1bWVudCByYXRoZXIgdGhhbg0KPj5lbWJlZGRlZCBpbiB0aGUgTlNIIHRl eHQuIEJ1dCBpbiBlaXRoZXIgY2FzZSBJIHRoaW5rIGl0IG1ha2VzIHRoZSBtb3N0DQo+PnNlbnNl IGZvciB0aGUgU0ZDIFdHIHRvIGJlIHRoZSBob21lIGZvciBzdWNoIGEgZGVmaW5pdGlvbi4NCj4+ DQo+PkNoZWVycywNCj4+LUJlbnNvbg0KPg0KDQo= From nobody Tue Apr 28 15:37:14 2015 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 E54FB1A1BC2 for ; Tue, 28 Apr 2015 15:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 2IIkyRO06wJo for ; Tue, 28 Apr 2015 15:37:11 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0F21A00F6 for ; Tue, 28 Apr 2015 15:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1430260631; x=1431470231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P3usAOSg8hbEGvgccW3Qisl0xUKb3fgS2hPJXVxviEs=; b=BfYY81j6mQ4q6DQbTy4+Tu+qP0hL0JdvzHZ/LQuEpSN8J0wpH8ydg3LW DpBX5GGVx47N0qAosdQoZCjjnzM5ranynoIs7b93mnEhqMvhzyFKeqImx JEs+uE0JysPb2Vix8NuwhMPEr416Nky/kQRzSlmyYrKCRXDDx7DyFU5Vo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBADiCkBV/5ldJa1cgwxTXAWDFcQFCYFJCoYEAhyBITgUAQEBAQEBAYEKhCEBAQQBAQEaFzMHCxACAQgYBCgCAiULJQIEDgWIKw2WBpx8BpQZAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBG4odhFIzB4JigUsFkWWKP4EjjR+DWoNQI2CDFG+BRIEBAQEB X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208";a="145372342" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2015 22:37:10 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3SMbAtr032154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 22:37:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.245]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 17:37:10 -0500 From: "Larry Kreeger (kreeger)" To: Jeff Tantsura Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgAB6WACAAOMxgA== Date: Tue, 28 Apr 2015 22:37:09 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <16408821-FA8E-4F02-B40D-675BD8F89935@ericsson.com> In-Reply-To: <16408821-FA8E-4F02-B40D-675BD8F89935@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="euc-kr" Content-ID: <635FAB769A9B604C8236AE4BF5EF7187@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH and UDP Transport 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, 28 Apr 2015 22:37:13 -0000 VGhhbmtzIEplZmYhICBXZSB3aWxsIGRvIHRoYXQgaWYgYSBiZXR0ZXIgaG9tZSBpcyBub3QgZm91 bmQgYmVmb3JlIFByYWd1ZS4NCiBQYXVsIFF1aW5uIHN1Z2dlc3RlZCBUcmFuc3BvcnQgKFRTViBX RykuICBJcyB0aGVyZSBhIHByZWNlZGVudCBmb3IgdGhlc2UNCnR5cGVzIG9mIGRyYWZ0cyBnb2lu ZyB0byBUU1YgV0c/DQoNCiAtIExhcnJ5DQoNCk9uIDQvMjcvMTUgNzowMyBQTSwgIkplZmYgVGFu dHN1cmEiIDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj5MYXJyeSwNCj4N Cj5JZiB5b3UgZG9uJ3QgZmluZCBhIGJldHRlciBob21lIGZvciBpdCBiZWZvcmUgUHJhZ3VlLCBw b3RlbnRpYWxseSB5b3UNCj5jb3VsZCBwcmVzZW50IGluIHJ0Z3dnLCB3ZSB3aWxsIGRpc3BhdGNo IGl0IGFmdGVyd2FyZHMuDQo+DQo+UmVnYXJkcywNCj5KZWZmDQo+DQo+PiBPbiBBcHIgMjcsIDIw MTUsIGF0IDk6NDYgUE0sIExhcnJ5IEtyZWVnZXIgKGtyZWVnZXIpDQo+PjxrcmVlZ2VyQGNpc2Nv LmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIEppbSwNCj4+IA0KPj4gSWYgc29tZW9uZSB3YW50ZWQg dG8gd3JpdGUgYSBkcmFmdCBzcGVjaWZ5aW5nIGhvdyB0byBjYXJyeSBOU0ggb3ZlciBVRFAsDQo+ PiB3aGF0IFdHIHdvdWxkIGl0IGJlIHN1Ym1pdHRlZCB0bz8gIEkgdXN1YWxseSBzZWUgdGhlIHBy b3RvY29scyBydW5uaW5nDQo+PiBvdmVyIFVEUCBzcGVjaWZ5IHRoZWlyIFVEUCBwb3J0IG51bWJl ciwgbm90IHRoZSBvdGhlciB3YXkgYXJvdW5kIChVRFANCj4+IGRvZXNuJ3Qgc3BlY2lmeSB3aGF0 IHJ1bnMgb24gdG9wIG9mIGl0KS4gIEZvciBleGFtcGxlLCBWWExBTiBzcGVjaWZpZXMNCj4+IHRo ZSBVRFAgcG9ydCB1c2VkIHRvIGNhcnJ5IGl0LiAgVURQIGRvZXMgbm90IHNwZWNpZnkgd2hhdCBw b3J0IHRvIHVzZSB0bw0KPj4gY2FycnkgVlhMQU4uICBJcyB0aGVyZSBhbiBSRkMgeW91IGNhbiBw b2ludCB0byBhcyBhbiBleGFtcGxlIHRoYXQgc2ltcGx5DQo+PiBzcGVjaWZpZXMgYSBVRFAgcG9y dCBmb3IgYW5vdGhlciBwcm90b2NvbCB0byBiZSBjYXJyaWVkPw0KPj4gDQo+PiBUaGFua3MsIExh cnJ5DQo+PiANCj4+PiBPbiA0LzIzLzE1IDc6MjIgQU0sICJKaW0gR3VpY2hhcmQgKGpndWljaGFy KSIgPGpndWljaGFyQGNpc2NvLmNvbT4NCj4+Pndyb3RlOg0KPj4+IA0KPj4+IEhpIEpvZWwsDQo+ Pj4gDQo+Pj4+IE9uIDQvMjMvMTUsIDk6NDcgQU0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9l bGhhbHBlcm4uY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEkgdGhpbmsgSSBhbSBtaXNzaW5nIHlv dXIgcG9pbnQgVGhvbWFzLiAgV2UgaGF2ZSBhbiBhZ3JlZWQgY29tbW9uDQo+Pj4+aGVhZGVyDQo+ Pj4+IChvciBhdCBsZWFzdCBhbiBhZ3JlZWQgYmFzaXMgYW5kIGV4cGVjdGF0aW9uIHRoYXQgd2Ug d2lsbCBjb21wbGV0ZSB0aGUNCj4+Pj4gcmVzdCBleHBlZGl0aW91c2x5LikgIFNvIEkgZG8gbm90 IHNlZSBhbnkgcmlzayBvZiBlbmRpbmcgdXAgd2l0aCBhDQo+Pj4+IGRpZmZlcmVudCBOU0ggaGVh ZGVyIGZvciBlYWNoIHRyYW5zcG9ydC4NCj4+Pj4gDQo+Pj4+IFRoZSBxdWVzdGlvbiBpcyB3aGVy ZSAvIHdoZW4gZG8gd2Ugc3BlY2lmeSB0aGUgdHJhbnNwb3J0IGRldGFpbHMuDQo+Pj4gDQo+Pj4g SmltPiBvdXIgY2hhcnRlciBkb2VzIG5vdCBjYWxsIGZvciB1cyB0byB3b3JrIG9uIHRoZSB0cmFu c3BvcnQgZGV0YWlsczsNCj4+PiB0aG9zZSBzaG91bGQgYmUgYWRkcmVzc2VkIGJ5IHRoZSByZWxl dmFudCBXRyBmb3IgYSBnaXZlbiB0cmFuc3BvcnQNCj4+PiBwb2ludGluZyB0byBvdXIgU0ZDIGVu Y2Fwc3VsYXRpb24gd29yay4NCj4+PiANCj4+Pj4gDQo+Pj4+IElmIFN1cmVuZHJhIHdhbnRzIHRv IHRha2UgdGhlIGV4aXN0aW5nLCByZWdpc3RlcmVkLCBjb2RlIHBvaW50LCBhbmQNCj4+Pj4gaW5k aWNhdGUgdGhhdCB3aGF0IGl0IGlzIHRvIGNhcnJ5IGlzIE5TSCAoYW5kIHByZXN1bWFibHkgdXBk YXRlIGl0DQo+Pj4+YWdhaW4NCj4+Pj4gd2hlbiB0aGUgUkZDIGNvbWVzIG91dCkgdGhhdCBpcyBm aW5lLiAgSSBoYXZlIG5vIG9iamVjdGlvbiBwZXJzb25hbGx5LA0KPj4+PiBhbmQgSSBjYW4gc2Vl IG5vIGdyb3VuZHMgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIG9iamVjdC4NCj4+PiANCj4+PiBK aW0+IGZyb20gYSBjaGFpcnMgcGVyc3BlY3RpdmUgSSBhbHNvIGhhdmUgbm8gb2JqZWN0aW9uLiBM aWtld2lzZSBpZg0KPj4+b3RoZXINCj4+PiBXR6n2cyB3YW50IHRvIGRlZmluZSBpbiB0aGVpciB0 cmFuc3BvcnRzIGhvdyBOU0ggaXMgaW5kaWNhdGVkIHRoZW4gdGhhdA0KPj4+aXMNCj4+PiB0aGUg cmlnaHQgYXBwcm9hY2ggYW5kIEkgZW5jb3VyYWdlIGl0Lg0KPj4gDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0K Pj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KDQo= From nobody Tue Apr 28 18:39:36 2015 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 430E91A92DC; Tue, 28 Apr 2015 18:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TgNn09jbppLm; Tue, 28 Apr 2015 18:39:33 -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 47EC21A92BD; Tue, 28 Apr 2015 18:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3221; q=dns/txt; s=iport; t=1430271573; x=1431481173; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+H9iX99PorxZEhEyo0HfMszKdPLcJJFvE08JUMBH1hk=; b=XETy1THzH+W6q1mlgQP8KaBiQSQJlt1ZP7SISmg+1rKR4CT/sB4kq4i0 o5gOdiH8e19SE2nrQ2lFVfUv8qoUefZktgOcaMYVQwxRcD1b7Yfmp+3bH 5gSaRnA+9749CyAmgAO/yMI6Xq1MOO/sD88MwTmea2AI6kCovn6mR0g37 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BBBQDYNUBV/4cNJK1cgwxTXAXGOII4CoYEAoE4TAEBAQEBAYELhCABAQEEAQEBNzQLEgEIEgYeNwsXBQkCBAENBQmIIg3HKwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOIUFAgUChCsFkWWEBIY7gSM9gwyJVliGUiODdG8BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,668,1422921600"; d="scan'208";a="415584702" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 29 Apr 2015 01:39:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3T1dWeL028262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 01:39:32 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.151]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 20:39:32 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Joel M. Halpern" , "ipfix@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt Thread-Index: AQHQgGCaz1YmKYTy8UWC225FKC3D+Z1gNswAgAMT3oA= Date: Wed, 29 Apr 2015 01:39:31 +0000 Message-ID: In-Reply-To: <553D6926.40507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.118.20.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D56CEC34BB17843886A2CDFDEB8B72A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-kumar-ipfix-sfc-extension@tools.ietf.org" Subject: Re: [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-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: Wed, 29 Apr 2015 01:39:35 -0000 Hi Joel, Thanks for the comments. Please see inline.. >I am wondering if the nextSFF fields really belong here? >I see several problems with them. If the observation is being made >before the SF, or between multiple local SF, then the information does >not exist. =20 I think unobserved field by metering process while generating flow record is not specific to SFC scenarios. This is discussed in below draft, https://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-03 I think the consensus can be applicable for SFC scenarios as well. >Even if the observation is being made after the last local >SF, the identification of the next SFF, as understood by this SFF, may >well not be an IP address. What the local SFF knows may be an IP >address, and Ethernet Address, an MPLS label, etc. So I am not sure >this makes sense as a reportable. Good point. I will check this and will include the update in next revision. > >Otherwise, it looks quite reasonable and useful. Thanks, Nagendra > > >On 4/26/15 4:35 PM, Nagendra Kumar Nainar (naikumar) wrote: >> Hi, >> >> Below is the draft proposed on IPFIX information elements for SFC. >> >> We welcome any comments/feedbacks. >> >> Regards, >> Draft Authors. >> >> On 3/9/15, 8:49 AM, "internet-drafts@ietf.org" >> >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : IPFIX Information Element extension for SFC >>> Authors : Nagendra Kumar >>> Carlos Pignataro >>> Paul Quinn >>> Filename : draft-kumar-ipfix-sfc-extension-00.txt >>> Pages : 11 >>> Date : 2015-03-09 >>> >>> Abstract: >>> Service Function Chaining (SFC) is an architecture that enables any >>> operator to apply selective set of services by steering the traffic >>> through an ordered set of service functions without any topology >>> dependency. >>> >>> This document defines the required Information Elements to represent >>> the details about service flows over any Service Function Path. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-00 >>> >>> >>> 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/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>