From nobody Thu Sep 1 06:51:51 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A7112DA4E; Thu, 1 Sep 2016 06:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9QKIyaxdovN9; Thu, 1 Sep 2016 06:51:37 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B85C12DB12; Thu, 1 Sep 2016 06:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=122962; q=dns/txt; s=iport; t=1472736154; x=1473945754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rv1LllWhJ910OMm4/x8/JYQfrM4CQhunbKWPl3r/p+I=; b=eGGpvhFjxN49scabzadTQPrkyoqCarytri4RWCNG+tyKjHL6K/yLTJ0U yGr17ib0A54lFOLnFg+3/12B2+OuaHPk0I+532KczKwvs+9iUzd2WbxcX Urckhyj6BVqOZxnxwIviIC0Yq64OTwxOnC9JIeqNyMbUAytPeUFdHAy1v s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgAVK8hX/4wNJK1dgx0zAQEBAQEeV?= =?us-ascii?q?3wHuCKCAiaFdgKBUjgUAQIBAQEBAQEBXieEYQEBBQEBGAFMBwsQAgEIEQMBAQE?= =?us-ascii?q?hAQYHJwIJFAkIAgQBDQUbBIgpDrpPAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYvh?= =?us-ascii?q?E2EHEMBBwUKhSYFiC0Di1mFRwGGH4MBgnpcgjqBbRc3hA+DNIVZjEiDeAEPDza?= =?us-ascii?q?CSRuBTXABhD0CJAeBAgF+AQEB?= X-IronPort-AV: E=Sophos;i="5.30,267,1470700800"; d="scan'208,217";a="318049809" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Sep 2016 13:22:32 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u81DMWot012050 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 13:22:32 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Sep 2016 08:22:31 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 1 Sep 2016 08:22:31 -0500 From: "Sashank Dara (sadara)" To: "Diego R. Lopez" , "Frank Brockners (fbrockne)" Thread-Topic: [sfc] Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgIAu5HmAgAomooA= Date: Thu, 1 Sep 2016 13:22:31 +0000 Message-ID: References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.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.6.7.160722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [72.163.210.120] Content-Type: multipart/alternative; boundary="_000_D3EE23757D65Bsadaraciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "draft-brockners-proof-of-transit@tools.ietf.org" , Tal Mizrahi Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 13:51:42 -0000 --_000_D3EE23757D65Bsadaraciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Diego , Thanks for bringing up an excellent point on the computational complexity. Fortunately the algorithm takes a cumulative approach which is agnostic of = the path length. 1. Controller performs few trivial steps like choosing long term secrets= , calculating the LPC values for each node and provisioning. 2. Each node only performs 2 additions, 1 multiplication and 1 mod(prime= ) operation per packet . 3. Verifier also performs step (2) and additionally performs 1 addition,= 1 mod(prime) and comparison to verify ! The above steps hold good for any length of nodes. A detailed example is provided for illustrative purposes in our draft (s= ection 3.3) that explains above operations. Would be happy to discuss more on the above, if needed. Regards, Sashank From: "Diego R. Lopez" > Date: Friday, 26 August 2016 at 6:21 PM To: "Frank Brockners (fbrockne)" > Cc: Tal Mizrahi >, sashank dara= >, "draft-brockners-proof-of-tra= nsit@tools.ietf.org= " >, "opsawg@ietf.org"= >, "nvo3@ietf.org" >, "sfc@ietf.org" > Subject: Re: [sfc] Question regarding Proof of Transit draft Hi Frank, This is a really interesting piece of work, and I must say we have been dis= cussing the PoT issue with some customers (though we used to call it =93ass= ured path traversal=94) and we have been exploring possible solutions, tryi= ng to combine good-enough security with a reasonable amount of computationa= l complexity, and I am glad to see a practical proposal addressing this pro= blem. I had a brief conversation with Carlos while in Berlin, but I am afra= id that the IETF week was too hectic for a detailed discussion. Let me add to Tal=92s analysis a third issue to consider. My understanding = of Shamir=92s polynomials is that they can be used to reconstruct a secret = from N pieces you need a polynomial of degree N-1, so that implies that the= verification is limited to a certain number of SFs (or SFFs), depending on= the degree of the applied polynomial. We=92d need and assessment on the co= mputational complexity associated with path length and the requirements for= adaptation of the PoT nodes (I guess SDN/NFV could play a role there=85) Be goode, On 20 Jul 2016, at 09:16 , Frank Brockners (fbrockne) > wrote: Hi Tal, well... if you could protect the integrity of the data stream between sourc= e and destination, you would not be able to swap the content of a packet = =96 which is what your attack is all about. Rather than continue arguing th= e point, let=92s acknowledge that it is a valid attack and let=92s look for= a solution :-). We=92ll need to couple POT to integrity protection of the = packet. Hence, I=92d like to come back to my question asked below: Do you (and the entire SFC team here) think it is worthwhile to provide a s= olution for a deployment which is expected to *not* alter the packet payloa= d? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 18:15 To: Frank Brockners (fbrockne) >; Sashank Dara (sadara) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We=92ll provide more details on 2. Per my earlier p= oint =96 1. is an interesting discussion, given that we don=92t claim to pr= ovide integrity protection for the packet payload. Or in other terms =96 to= be exact: What POT provides is a proof that the POT-header/meta-data trans= ited all the required nodes. There is no association (and thus proof) provi= ded for the additional data carried along with the POT-header =96 neither h= eader nor payload. As a consequence, attacks which change the packet payloa= d won=92t be detected/mitigated. We=92ll explicitly state this in the secur= ity considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar =96 but that way we=92d restrict the applicability to dep= loyments where the packet payload isn=92t changed across the path (which mi= ght not apply to certain deployment =96 e.g. WAN optimization / compression= schemes). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of =93proof-of-transit=94 is to prove the path packet has= taken exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with =93reconstructed=94 path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rou= ghly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_D3EE23757D65Bsadaraciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Diego , 

Thanks for bringing up an excellent point on the computational complex= ity. 
Fortunately the algorithm takes a cumulative approach which is agnosti= c of the path length. 
  1. Controller performs few trivial steps like choosing long term secrets, = calculating the LPC values for each node and provisioning.
  2. Each nod= e only performs 2 additions, 1 multiplication and 1 mod(prime) operation pe= r packet . 
  3. Verifier also performs step (2) and additionally p= erforms 1 addition, 1 mod(prime) and comparison to verify ! 
The above steps hold good for any length of nodes. 

A detailed example is provided for illustrative purposes in our draft  (section 3.3) that explains above operations. 

Would be happy to discuss more on the above, if needed. 

Regards,
Sashank


From: "Diego R. Lopez" &l= t;diego.r.lopez@telefonica.= com>
Date: Friday, 26 August 2016 at 6:2= 1 PM
To: "Frank Brockners (fbrockne= )" <fbrockne@cisco.com>= ;
Cc: Tal Mizrahi <talmi@marvell.com>, sashank dara <sadara@cisco.com>, "draft-brockners-proof-= of-transit@tools.ietf.org" <dra= ft-brockners-proof-of-transit@tools.ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "n= vo3@ietf.org" <nvo3@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Question regardi= ng Proof of Transit draft

Hi Frank,

This is a really interesting piece of work, and I must say = we have been discussing the PoT issue with some customers (though we used t= o call it =93assured path traversal=94) and we have been exploring possible= solutions, trying to combine good-enough security with a reasonable amount of computational complexity, and I am gl= ad to see a practical proposal addressing this problem. I had a brief conve= rsation with Carlos while in Berlin, but I am afraid that the IETF week was= too hectic for a detailed discussion.

Let me add to Tal=92s analysis a third issue to consider. M= y understanding of Shamir=92s polynomials is that they can be used to recon= struct a secret from N pieces you need a polynomial of degree N-1, so that = implies that the verification is limited to a certain number of SFs (or SFFs), depending on the degree of the appli= ed polynomial. We=92d need and assessment on the computational complexity a= ssociated with path length and the requirements for adaptation of the PoT n= odes (I guess SDN/NFV could play a role there=85)

Be goode,
 
On 20 Jul 2016, at 09:16 , Frank Brockners (fbrockne) <<= a href=3D"mailto:fbrockne@cisco.com" class=3D"">fbrockne@cisco.com> = wrote:

Hi Tal,
 
well... if you could protect the= integrity of the data stream between source and destination, you would not= be able to swap the content of a packet =96 which is what your attack is all about. Rather than continue arguing t= he point, let=92s acknowledge that it is a valid attack and let=92s look fo= r a solution :-). We=92ll need to couple POT to integrity protection of the= packet.
 
Hence, I=92d like to come back t= o my question asked below:  
Do you (and the entire SFC team = here) think it is worthwhile to provide a solution for a deployment which i= s expected to *not* alter the packet payload?
 
Thanks, Frank
 
From: Tal Mizrahi [mailto:talmi@marvell.com] 
Sent: D= ienstag, 19. Juli 2016 18:15
To: Fra= nk Brockners (fbrockne) <fbrockne@cisco.com>; Sashank Dara (sadara) <sadara@cisco.com= >; draft-brockners-proof-of-transit@t= ools.ietf.org
Cc: sfc@ietf.org;&n= bsp;opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Hi Frank,<= /span>
 
The POT replacement attack (1.) = is not an attack on the integrity. It is an attack on the path verification= .
This simple attack can cause the= verifier to accept a packet that did not go through the firewall SF (even = though it should). I believe this is exactly the problem you were aiming to address in this draft.
 
Thanks,
Tal.
 
From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] 
Sent: T= uesday, July 19, 2016 6:00 PM
To: Tal= Mizrahi; Sashank Dara (sadara); = ;draft-brock= ners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org;&n= bsp;opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Hi Tal,
 
thanks for the summary. We=92ll = provide more details on 2. Per my earlier point =96 1. is an interesting di= scussion, given that we don=92t claim to provide integrity protection for the packet payload. Or in other terms =96 to be e= xact: What POT provides is a proof that the POT-header/meta-data transited = all the required nodes. There is no association (and thus proof) provided f= or the additional data carried along with the POT-header =96 neither header nor payload. As a consequence, atta= cks which change the packet payload won=92t be detected/mitigated. We=92ll = explicitly state this in the security considerations in the next rev of the= document.
What we could consider is linkin= g the RND number to CRC across the packet payload or similar =96 but that w= ay we=92d restrict the applicability to deployments where the packet payload isn=92t changed across the path (which might not = apply to certain deployment =96 e.g. WAN optimization / compression schemes= ).
Do you think it is worthwhile to= provide a solution for a deployment which is expected to not alter the pac= ket payload?
 
Thanks,
Frank
 
From: Tal Mizrahi [mailto:talmi@marvell.com] 
Sent: D= ienstag, 19. Juli 2016 17:44
To: Sas= hank Dara (sadara) <sadara@cisco.com>; F= rank Brockners (fbrockne) <fbrockne@cisco.c= om>; draft-brockners-proof-of-transit= @tools.ietf.org
Cc: sfc@ietf.org;&n= bsp;opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Hi,=
 
To summarize my take on this thr= ead:
The proposed mechanism has two s= ignificant vulnerabilities that (in my understanding) are currently not add= ressed:
1.  &nb= sp;    A man-in-the-middle can replace the POT of packet A with the POT of packet B= .
2.  &nb= sp;    It is possible to replay POTs within a certain time window, whose length is d= etermined by the timestamp resolution.
 
Sashank, thanks for agreeing to = look into it further. I am looking forward to your insights on this.
 
Regards,
Tal.
 
Link to the draft: https://tools.ietf.org/html/draft-brockners-proo= f-of-transit-01
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 12:20 PM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
 
 
I want to ask a simple question:=
If the attacker attaches the POT= of packet A (indicating the path through 1,3,5,6) to packet B, will the ve= rifier accept packet B and believe that its path was indeed (1,3,5,6)?
 
[SD] If the verifier is programmed to just validate the= POT meta data against {1,3,5,6} then yes it accepts it. 
If the verifier is programmed to consult a policy datab= ase to cross check if the reconstructed path {1,3,5,6} is as per the polici= es then no , it drops it . 
 
But I see your point , that the parameters used in POT = data donot consider the path or node-ids etc . We shall discuss this intern= ally and get back.
 
Also, We shall get back with more concrete numbers of t= he timestamp resolution and cache sizes (or other better approaches). =
 
Thank you so much for all the inputs. 
 
 
 
From: Tal Mizrahi 
Sent: T= uesday, July 19, 2016 10:28 AM
To: 'Sa= shank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Dear Sashank,
 
I really appreciate the quick an= d detailed responses.
 
>>>Lets take correct path taken by Packet A &n= bsp;to be P= ath1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattach them to Path2 , 
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy 
>>>violations. POT does not enforce a particular path to be taken.=
>>So packet B skipped node= 5 (e.g. the firewall SF), but the verifier believes it went through the co= rrect path.
>>Would you agree?<= /span>
>[SD] The verifier only constructs the path the pack= et took accurately, it is upto
>the application to determine whether it violates an= y policies (I.e missing any function) 
>The bottom line is , an attacker taking a different= path cannot get away with it !
>The whole intent of =93proof-of-transit=94 is to pr= ove the path packet has taken exactly. 
>POT does not define whether it good/bad path. It is= upto high level applications on what
>do with =93reconstructed=94 path. 
 
 
 
I want to ask a simple question:=
If the attacker attaches the POT= of packet A (indicating the path through 1,3,5,6) to packet B, will the ve= rifier accept packet B and believe that its path was indeed (1,3,5,6)? =
 
 
>>Hmmm=85 Let=92s say we a= re talking about traffic at 10 Gbps, which is roughly 
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its 
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?
>[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !
 
My point is that assuming reason= able resources are used, the mechanism is vulnerable to a replay attack.
In order to prove me wrong, can = you present concrete numbers of the timestamp resolution and the cache size= ?
Otherwise, you may consider usin= g a sequence number + sliding window (e.g., as in IPsec).
 
 
Thanks,
Tal.
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 9:56 AM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
 
 
 
>[SD] Ok. This is an interesting attack.  <= /div>
> 
>Lets take correct path taken by Packet A  to b= e Path1=  - ( 1,3,5,6) nodes. 
>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
> 
>If the attacker could take values from Path1 and reattach them to Path2 , 
>the reconstruction for PacketB would result in= (1,3,5,6) instead of (1,2,3,6). 
>This could be compared with topology/policy db info= rmation for any policy
>violations. POT does not enforce a particular path = to be taken.
 
So packet B skipped node 5 (e.g.= the firewall SF), but the verifier believes it went through the correct pa= th.=
Would you agree?
 
[SD] The verifier only constructs the path the packet t= ook accurately, it is upto the application to determine whether it violates= any policies (I.e missing any function) =
The bottom line is , an attacker taking a different pat= h cannot get away with it ! The whole intent of =93proof-of-transit=94 is t= o prove the path packet has taken exactly. 
POT does not define whether it good/bad path. It is upt= o high level applications on what do with =93reconstructed=94 path. 
 
 
Hmmm=85 Let=92s say we are talki= ng about traffic at 10 Gbps, which is roughly 1 million packets per second.= That would mean the verifier has to store a million values of RND-2.
Moreover, every time a packet ar= rives, the verifier would have to compare its RND-2 value with the 1 millio= n stored values, in order to verify there is no replay.
That does not sound feasible.
Am I missing something here?
 
[SD] Second level precision is only an example, we could use as much = precision as we want to reduce the number of values to be cached !
 
 
Sashank 
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 8:33 AM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
Inline .. 
 
 
We have two consecutive packets,= A and B:=
- Packet A that went through the= correct path and has a correct POT.
- Packet B that did not go throu= gh the correct path and does not have a correct POT.
 Now the attacker performs = a =91mix and match=92 attack, by taking the correct POT from packet A and a= ttaching it to packet B.<= o:p class=3D"">
The attacker also terminates pac= ket A.
There is no replay here, because= the verifier receives the correct POT only once. The problem is that the c= orrect POT happens to arrive with packet B. L
Thus, packet B appears okay to t= he verifier, even though it did not go through the correct path.
 
Is there a way to mitigate this = attack?
 
[SD] Ok. This is an interesting attack.  
 
Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
 
If the attacker could take values from Path1 and reattach them to Pa= th2 , the reconstru= ction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =
This could be compared with topology/policy db informat= ion for any policy violations. POT does not enforce a particular path to be= taken.
 It just reconstructs the particular path taken by= the packets. 
 
Do you mean that there is a one-= second-vulnerability for replay attacks?
One second is practically foreve= r.<= /span>
 
[SD] Not really , the verifier could cache the RND-2 nu= mbers used in the time slice of one second and flush off after every second= . There is no one-second-vulnerability as such, if the verifier caches those values. 
 
Effective replay prevention is t= ypically performed using a sequence number, with a sliding window to allow = out-of-order packets. Wouldn=92t it be possible to incorporate such a sequence number into your mechanism?
 
[SD] Time stamp is essentially at high level sequence n= umber (at seconds level)! The challenge with using complete RND-2 as sequen= ce number is that the differential analysis of CML values (across packets) becomes very easy  and predictable.
that=92s reason we recommend using  ( Timestamp(/ = sequence number) + RND )
 
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 1:11 AM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
Dear Tal,
Thank you for your interest in our work. More inline wi= th [SD] .. 
 
 
Right, I am referring to the for= mer. The integrity check is not the issue.
Let=92s say we have:
- Packet A that went through the= correct path and has a correct POT.
- Packet B that did not go throu= gh the correct path and does not have a correct POT.
 
The attacker can =91launder=92 p= acket B by replacing the (incorrect) POT of packet B with the correct POT o= f packet A (and drop packet A).
Thus, packet B is verified corre= ctly, even though it did not go through the correct path.
 
[SD] This is valid scenario and we have certain in-buil= t mitigation techniques and recommendations for the same. 
There are two scenarios here 
 
Partial Replay of POT data (Replaying int= ermediate CMLs)
 
Attacker cannot reuse few intermediate node=92s POT val= ues (from older packet traces) as it would disrupt the POLY-3 construction.=  
On the other hand if the attacker tries to replay entir= e sequence of CML values, he cannot still , because notice that verifier al= so has a secret share of RND-1 and participates in the reconstruction of RND-3.
Verifier=92s share of RND-3 is never on wire , so attac= ker cannot just observe the packet traces to reuse and replay it. =
 
Total Replay of POT data (Replaying compl= ete RND-2)
 
Another trick, attacker could do is by completely reusi= ng RND-2 (but not intermediate CML values)
In order to prevent the =93Reply Attacks=94 , we recomm= end that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D = =93Time Stamp + RND number=94)
So in case a passive attacker tries to replay one of th= e correct but older RND-2, the verifier first could check the current times= tamp against the timestamp retrieved from RND-2.
If the retrieved timestamp is older than current timest= amp we drop/raise a flag ! 
 
There is still a small window , where the attacker coul= d replay it within the valid time slice itself but by carefully choosing th= e time slice we can make it nearly impossible for the attacker to replay.
For example , if the Time Stamp chosen is 32 bits , we = could get one seconds level precision in the time window . So it is highly = impossible for the attacker to replay within such a small time at such a high packet rates. 
 
Also , the verifier could cache, if needed, certain num= ber of previously used RND-2 to mitigate replay attacks. 
 
Hope this clarifies. 
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org= /mailman/listinfo/sfc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_D3EE23757D65Bsadaraciscocom_-- From nobody Tue Sep 6 03:55:37 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFBC12B192 for ; Tue, 6 Sep 2016 03:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l6TUQvogqt_y for ; Tue, 6 Sep 2016 03:55:33 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id DDE4512B5C2 for ; Tue, 6 Sep 2016 03:50:23 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id u86AoKxY004505; Tue, 6 Sep 2016 19:50:20 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 463A15F623; Tue, 6 Sep 2016 19:50:20 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 392825F612; Tue, 6 Sep 2016 19:50:20 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.13.28]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTP id 2E750400782; Tue, 6 Sep 2016 19:50:20 +0900 (JST) References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> From: Shunsuke Homma Message-ID: Date: Tue, 6 Sep 2016 19:50:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: "Jim Guichard (jguichar)" , "sfc@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 10:55:36 -0000 Hi Jim and editors, I've read the latest nsh draft, and I have a comment for the section 4. I think that "Update NSH" would be correct as sub-title of the third action in this section because the sentence includes an action related with update of context headers. Also, "Update NSH" is used in Figure 8. Best regards, Shunsuke On 2016/08/24 1:48, Jim Guichard (jguichar) wrote: > Dear WG: > > Please review this new version of the SFC encapsulation to make sure that your comments from the previous WGLC have been addressed. > > Any comments and/or concerns please post to the mailing list within the next two weeks so that this work can be progressed. > > As a heads up, if there are still substantive comments we plan to hold an interim meeting on September 15th to address any outstanding issues > > > Thanks! > > Jim, Martin, & Thomas > > > > > On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Service Function Chaining of the IETF. >> >> Title : Network Service Header >> Authors : Paul Quinn >> Uri Elzur >> Filename : draft-ietf-sfc-nsh-07.txt >> Pages : 37 >> Date : 2016-08-23 >> >> Abstract: >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> provides a mechanism for metadata exchange along the instantiated >> service path. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) Architecture (defined in RFC7665). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-07 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Sep 6 11:21:08 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E7E12B25B for ; Tue, 6 Sep 2016 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 d9oJIq7kexCd for ; Tue, 6 Sep 2016 11:21:06 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E8A12B2D7 for ; Tue, 6 Sep 2016 11:21:04 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 6 Sep 2016 14:21:02 -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.0294.000; Tue, 6 Sep 2016 14:21:03 -0400 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLA Date: Tue, 6 Sep 2016 18:21:02 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> In-Reply-To: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 18:21:07 -0000 I have a comment on the specification of Service Index (SI). The document says,=20 The initial classifier for a given SFP SHOULD set the SI to 255, howeve= r the=09 control plane MAY configure the initial value of SI as appropriate... If you read this literally, it seems to say that the classifier SHOULD set = the initial SI to 255 regardless of what the control plane tells it to do. It is perhaps implied that the classifier MAY do what the control plane tel= ls it to, but that's not what the words say. I think wording like this might help: The initial classifier MUST set the SI to the value specified by config= uration for the classification outcome. The initial SI configuration SHOULD= default to 255. However, the classifier MUST allow configuration of other = SI values. Similar wording should apply to the SPI; nothing is said about the classifi= er in the paragraph about SPI. I suggest: The initial classifier MUST set the SPI to the value specified by confi= guration for the classification outcome. Note, I've said "configuration" instead of "control plane". I'm assuming a = control plane will do configuration. If you just want to talk about control= plane, then there is no need for any default, just "The classifier MUST se= t the SET to the value specified by the control plane for the classificatio= n." -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, August 23, 2016 12:48 PM To: sfc@ietf.org Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Dear WG: Please review this new version of the SFC encapsulation to make sure that y= our comments from the previous WGLC have been addressed.=20 Any comments and/or concerns please post to the mailing list within the nex= t two weeks so that this work can be progressed. As a heads up, if there are still substantive comments we plan to hold an i= nterim meeting on September 15th to address any outstanding issues Thanks! Jim, Martin, & Thomas On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >This draft is a work item of the Service Function Chaining of the IETF. > > Title : Network Service Header > Authors : Paul Quinn > Uri Elzur > Filename : draft-ietf-sfc-nsh-07.txt > Pages : 37 > Date : 2016-08-23 > >Abstract: > This document describes a Network Service Header (NSH) inserted onto > packets or frames to realize service function paths. NSH also > provides a mechanism for metadata exchange along the instantiated > service path. NSH is the SFC encapsulation required to support the > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 > > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Sep 6 11:24:52 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EE612B378 for ; Tue, 6 Sep 2016 11:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 jTAXiKsvDKfk for ; Tue, 6 Sep 2016 11:24:49 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741CA12B37C for ; Tue, 6 Sep 2016 11:24:48 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Tue, 6 Sep 2016 14:24:46 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt Thread-Index: AQHR/UcBiQhx1l4jAUq5aGvg+Ua8YKBaFmMAgBLGkTA= Date: Tue, 6 Sep 2016 18:24:45 +0000 Message-ID: References: <147196046137.30731.1399811299254089080.idtracker@ietfa.amsl.com> <60F54D29-49F6-4962-963B-93FF6F4DF1A1@cisco.com> <787AE7BB302AE849A7480A190F8B933008E0952B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E0952B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 18:24:51 -0000 Do the authors have a response to this question? I'm also wondering about whether the 'C' flag might be for the administrato= r vs. IANA. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, August 25, 2016 11:40 AM To: Paul Quinn (paulq); sfc@ietf.org Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt Hi Paul, I have a comment about this text: Type: the Type field is split into two ranges - 0 to 127 for non- critical options and 128-255 for critical options. While the value allocation is the responsibility of the MD Class owner, critical options MUST NOT be allocated from the 0 to 127 range and non- critical options MUST NOT be allocated from the 128-255 range. * Do you have an example of metadata that is critical for all chains, all d= eployments? * Wouldn't be more appropriate to have one single registry for "type" with = C-bit be a configurable parameter to be set by the administrator of the SFC= -enabled domain? Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paulq) > Envoy=E9=A0: mardi 23 ao=FBt 2016 16:02 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt >=20 > Dear WG, >=20 > This version includes much of the feedback/review/comments from this list= . >=20 >=20 >=20 > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-06.txt > > Date: August 23, 2016 at 9:54:21 AM EDT > > To: > > Cc: sfc@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Service Function Chaining of the IETF. > > > > Title : Network Service Header > > Authors : Paul Quinn > > Uri Elzur > > Filename : draft-ietf-sfc-nsh-06.txt > > Pages : 37 > > Date : 2016-08-23 > > > > Abstract: > > This document describes a Network Service Header (NSH) inserted onto > > packets or frames to realize service function paths. NSH also > > provides a mechanism for metadata exchange along the instantiated > > service path. NSH is the SFC encapsulation required to support the > > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-sfc-nsh-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-06 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc >=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 Sep 6 18:52:55 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6134212B0ED for ; Tue, 6 Sep 2016 18:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ie4cJmdHkmHc for ; Tue, 6 Sep 2016 18:52:52 -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 E631312B09D for ; Tue, 6 Sep 2016 18:52:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQW11327; Wed, 07 Sep 2016 01:52:49 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 7 Sep 2016 02:52:48 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.6]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 7 Sep 2016 09:52:43 +0800 From: Youjianjie To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-song-sfc-legacy-sf-mapping-08.txt Thread-Index: AQHSCKaZk3Xqltp+80u4PW+zsaYBtaBtPVSw Date: Wed, 7 Sep 2016 01:52:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57CF72F2.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.6, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6bce5c30dc4250389288300e288142a0 Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-song-sfc-legacy-sf-mapping-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 01:52:54 -0000 SGksDQoNCldlJ3ZlIHJldmlzZWQgdGhlIGRyYWZ0IHRvIGFsaWduIHdpdGggdGhlIHJlY2VpdmVk IHN1Z2dlc3Rpb25zIGFuZCBjb21tZW50cywgbWFpbmx5IGluY2x1ZGluZzoNCjEpIGV4cGxhaW4g dGhlIGNoYWxsZW5nZXMgdG8gdXNlIFNGQyBwcm94eSB0byBzdXBwb3J0IGxlZ2FjeSBTRg0KMikg bGlzdCBzb21lIG1hcHBpbmdzIGFzIGV4YW1wbGUgdG8gZXhwcmVzcyB0aGUgb3BlcmF0aW9uIGZl YXNpYmxlDQoNClRoYW5rcywNCkppYW5qaWUNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R 5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0OeaciDfml6UgOToyNQ0K5pS25Lu25Lq6 OiBTb25naGFpYmluIChBKTsgbm9uZS1jaGFpcnNAaWV0Zi5vcmc7IFlvdWppYW5qaWU7IE5pY29s YXMgQm91dGhvcnM7IEx1Y3kgeW9uZzsgTmljb2xhcyBCb3V0aG9yczsgTGluZGEgRHVuYmFyOyBE YXZpZCBEb2xzb247IEppYW5neXVhbmxvbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wOC50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmctMDgudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppYW5qaWUgWW91IGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXNvbmctc2ZjLWxlZ2Fj eS1zZi1tYXBwaW5nDQpSZXZpc2lvbjoJMDgNClRpdGxlOgkJU0ZDIEhlYWRlciBNYXBwaW5nIGZv ciBMZWdhY3kgU0YNCkRvY3VtZW50IGRhdGU6CTIwMTYtMDktMDYNCkdyb3VwOgkJSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczoJCTEyDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLTA4 LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zb25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wOA0K RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1z b25nLXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wOA0KDQpBYnN0cmFjdDoNCiAgIEEgU2VydmljZSBG dW5jdGlvbiBDaGFpbiAoU0ZDKSBkZWZpbmVzIGEgc2V0IG9mIGFic3RyYWN0IFNlcnZpY2UNCiAg IEZ1bmN0aW9ucyAoU0YpIGFuZCBvcmRlcmluZyBjb25zdHJhaW50cyB0aGF0IG11c3QgYmUgYXBw bGllZCB0bw0KICAgcGFja2V0cyBhbmQvb3IgZnJhbWVzIHNlbGVjdGVkIGFzIGEgcmVzdWx0IG9m IGNsYXNzaWZpY2F0aW9uLiAgT25lDQogICBhc3N1bXB0aW9uIG9mIHRoaXMgZG9jdW1lbnQgaXMg dGhhdCBsZWdhY3kgc2VydmljZSBmdW5jdGlvbnMgY2FuDQogICBwYXJ0aWNpcGF0ZSBpbiBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWlucyB3aXRob3V0IHN1cHBvcnRpbmcgdGhlIFNGQw0KICAgaGVhZGVy LCBvciBldmVuIGJlaW5nIGF3YXJlIG9mIGl0LiAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBzb21l IG9mDQogICB0aGUgbWVjaGFuaXNtcyBiZXR3ZWVuIGFuIFNGQyBwcm94eSBhbmQgYW4gU0ZDLXVu YXdhcmUgc2VydmljZQ0KICAgZnVuY3Rpb24gKGhlcmVpbiB0ZXJtZWQgImxlZ2FjeSBTRiIpLCB0 byBpZGVudGlmeSB0aGUgU0ZDIGhlYWRlcg0KICAgYXNzb2NpYXRlZCB3aXRoIGEgcGFja2V0IHRo YXQgaXMgcmV0dXJuZWQgZnJvbSBhIGxlZ2FjeSBTRiwgd2l0aG91dA0KICAgYW4gU0ZDIGhlYWRl ciBiZWluZyBleHBsaWNpdGx5IGNhcnJpZWQgaW4gdGhlIHdpcmVkIHByb3RvY29sIGJldHdlZW4N CiAgIFNGQyBwcm94eSBhbmQgbGVnYWN5IFNGLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From nobody Wed Sep 7 09:31:57 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3FE12B3B7 for ; Wed, 7 Sep 2016 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8P_FfZ19hjxV for ; Wed, 7 Sep 2016 09:31:54 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E550B12B3D1 for ; Wed, 7 Sep 2016 09:31:53 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 07 Sep 2016 09:31:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,296,1470726000"; d="scan'208";a="1036639070" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 07 Sep 2016 09:31:40 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.204]) by IRSMSX101.ger.corp.intel.com ([169.254.1.183]) with mapi id 14.03.0248.002; Wed, 7 Sep 2016 17:31:39 +0100 From: "Duarte Cardoso, Igor" To: "sfc@ietf.org" Thread-Topic: WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAFtHPA= Date: Wed, 7 Sep 2016 16:31:39 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 16:31:56 -0000 Hi SFC WG, I have some comments and trivial corrections to provide to draft-ietf-sfc-n= sh-07. - "confidentially" should be "confidentiality" in both of its occurrences; - At the end of section 9: - "describe in" should be "described in" - "MD-2" should be "MD-Type 2" - Also consider converging to either "MD Type" or "MD-Type", as both seem t= o be used throughout the draft; - Section 3.3: - "SI SHOULD be used in conjunction with SPI for SFP selection and for dete= rmining the next SFF/SF in the path": Two comments: - The statement (and the rest of the paragraph) seems to be about the for= warding side of NSH (forwarding/SFFs) However, it also seems to be about th= e classification side of NSH (classification/Classifiers) as they are the l= ogical elements which, with the influence of different SPI+SI, choose the n= ext SFP (specifically, the next SPI). Can this perhaps be clarified? - Assuming SFP is the concrete network path that will be taken to reach t= he next SF, which may be 1 of many possible SFPs for the same SPI/SI combin= ation, then the statement seems to imply that SI+SPI allow for SFP selectio= n AND determining the next SFF/SF. However, the latter is a consequence of = the former. I believe the following would better reflect the intended objec= tive of the original statement: "SI SHOULD be used in conjunction with SPI for SFP selection and, consequ= ently, determining the next SFF/SF in the path". - "When an SPI and SI do not correspond to a valid next Service Function pa= th" If my above assumption regarding 1 of many possible SFPs being possible fo= r the same SPI/SI combination is incorrect, then this statement seems to im= ply that SPI and SIs together map to a SFP, but in reality they together ma= p to a SF. If so, I believe that the following would better reflect the intended obje= ctive of the original statement: "When an SPI and SI do not correspond to a valid next hop of a Service Fun= ction". Any questions or requests for clarifications, just ask. Best regards, Igor. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Tuesday, September 6, 2016 7:21 PM To: Jim Guichard (jguichar) ; sfc@ietf.org Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt I have a comment on the specification of Service Index (SI). The document says,=20 The initial classifier for a given SFP SHOULD set the SI to 255, howeve= r the=09 control plane MAY configure the initial value of SI as appropriate... If you read this literally, it seems to say that the classifier SHOULD set = the initial SI to 255 regardless of what the control plane tells it to do. It is perhaps implied that the classifier MAY do what the control plane tel= ls it to, but that's not what the words say. I think wording like this might help: The initial classifier MUST set the SI to the value specified by config= uration for the classification outcome. The initial SI configuration SHOULD= default to 255. However, the classifier MUST allow configuration of other = SI values. Similar wording should apply to the SPI; nothing is said about the classifi= er in the paragraph about SPI. I suggest: The initial classifier MUST set the SPI to the value specified by confi= guration for the classification outcome. Note, I've said "configuration" instead of "control plane". I'm assuming a = control plane will do configuration. If you just want to talk about control= plane, then there is no need for any default, just "The classifier MUST se= t the SET to the value specified by the control plane for the classificatio= n." -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, August 23, 2016 12:48 PM To: sfc@ietf.org Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Dear WG: Please review this new version of the SFC encapsulation to make sure that y= our comments from the previous WGLC have been addressed.=20 Any comments and/or concerns please post to the mailing list within the nex= t two weeks so that this work can be progressed. As a heads up, if there are still substantive comments we plan to hold an i= nterim meeting on September 15th to address any outstanding issues Thanks! Jim, Martin, & Thomas On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. >This draft is a work item of the Service Function Chaining of the IETF. > > Title : Network Service Header > Authors : Paul Quinn > Uri Elzur > Filename : draft-ietf-sfc-nsh-07.txt > Pages : 37 > Date : 2016-08-23 > >Abstract: > This document describes a Network Service Header (NSH) inserted onto > packets or frames to realize service function paths. NSH also > provides a mechanism for metadata exchange along the instantiated > service path. NSH is the SFC encapsulation required to support the > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at tools.ietf= .org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ 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 Sat Sep 10 10:29:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919FC12B133 for ; Sat, 10 Sep 2016 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 M3Z60CC7EKvC for ; Sat, 10 Sep 2016 10:29:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E438A12B122 for ; Sat, 10 Sep 2016 10:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10998; q=dns/txt; s=iport; t=1473528591; x=1474738191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z0p0Svea3ZzhmwdInS6Xk0eexCwCEQhGZG6aa/Bmy8E=; b=gl9KqVtNnKngT+BPb3szhVMgxfj0QVyyPjxxiZZMuEV5pF2SHbuSIA02 VrybkTqPkJphys3MkHmPeOoDlz/16tE06sDaVKf2AAPiMDL5nPqwK7RdD 2Js4dpK6F8W7Uk2Ufmi8fmp1EikjQdFN78vvXmydLPNBQLXQk7W6XD/rt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQDMQtRX/4oNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBgy0BAQEBAR5XfAeNLKsdggMmghyDWwKBOTgUAQIBAQEBAQEBXhwLhGEBAQE?= =?us-ascii?q?DAQ5XAhIFCwIBCBgVGTIlAgQOBYhCCA7BAgEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RcFhjCBeQiCT4QTEAIBGzINgm6CLwWIMYY2inwBhiSDAoYlgW6EYIkUhneFXoN?= =?us-ascii?q?6AR42hFtwAYVHK4ECfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,312,1470700800"; d="scan'208";a="147732811" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2016 17:29:46 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u8AHTkrc002028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 10 Sep 2016 17:29:46 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 10 Sep 2016 12:29:45 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Sat, 10 Sep 2016 12:29:45 -0500 From: "Paul Quinn (paulq)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Ba4oYggBiIaAA= Date: Sat, 10 Sep 2016 17:29:44 +0000 Message-ID: <6D3898EC-1CC4-4771-8F04-D6D1BAFE35AF@cisco.com> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <787AE7BB302AE849A7480A190F8B933008E099F0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E099F0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.19.171] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 17:29:57 -0000 Med, Med, as always, thank you for your review. > On Aug 26, 2016, at 5:31 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Jim, all, >=20 > Likewise, I would like to see this document progress as well.=20 >=20 > In addition to the comment raised in a separate message about the C-bit o= f TLVs, I have the following comments: >=20 > (1) Section 2: I suggest to delete the following sentence:=20 >=20 > NSH is designed to be easy to implement across a range of devices, > both physical and virtual, including hardware platforms. >=20 > Reason: the use of "easy to implement" should be justified if that text i= s maintained. Otherwise, this is subjective.=20 >=20 > or to reword it as follows:=20 >=20 > "NSH can be implemented in both physical and virtual platforms." PQ> The "easy to implement" is a reference to the nature of type-1 and how= , as noted by hardware implementors, this vastly simplifies implementation.= Further, the language is widely used in RFCs (e.g. 7321, 3160, etc.). >=20 > (2) Section 2.3: I suggest to change this OLD text: >=20 > The semantics of > the shared metadata is communicated via a control plane, which is > outside the scope of this document, to participating nodes. >=20 > NEW: >=20 > The semantics of=20 > the shared metadata is communicated via a control plane (Section 3.3 of [= I-D.ietf-sfc-control-plane]). >=20 PQ> Proposed text: "The semantics of the shared metadata is communicated v= ia a control plane, which is outside the scope of this document, to partici= pating nodes. [ietf-sfc-control-plane] provides an example of such in sect= ion 3.3. > (3) Section 2.3- Not sure I would maintain this text:=20 >=20 > 5. NSH offers a common and standards-based header for service > chaining to all network and service nodes. >=20 > "to all" is not accurate as "legacy" nodes are still there. =20 >=20 PQ> Given that "legacy" nodes are supported via proxy, this is indeed true= . > (4) Section 2.3: >=20 > OLD: > Transport Agnostic: NSH is transport independent and is often > carried via a network transport protocol, >=20 > NEW: > Transport Agnostic: NSH is transport independent. Any network transport p= rotocol can be used to transport NSH-encapsulated traffic. PQ> Proposed text: NSH is transport independent. An appropriate (for a giv= en deployment) network transport protocol can be used to transport NSH-enca= psulated traffic. >=20 > (5) Section 3.2: >=20 > NSH implementations MUST support MD-Type =3D 0x1, and SHOULD support > MD- Type =3D 0x2. >=20 > Because: > * of potential interoperability issues. > * MD#2 is more compact when no metadata is to be supplied > * MD#2 allows to convey more information compared to MD#1 >=20 > I suggest we revisit that sentence to have MD#2 be mandatory to be suppor= ted (my favorite option), or at least require that both MDs defined in this= spec MUST be supported.=20 >=20 PQ> As per the previous discussion, this MUST/SHOULD reflect the practical= reality of implementation and helps ensure deployability. =20 > (6) Section 3.2: >=20 > C bit: Indicates that a critical metadata TLV is present. This bit > acts as an indication for hardware implementers to decide how to > handle the presence of a critical TLV without necessarily needing to > parse all TLVs present. For an MD Type of 0x1 (i.e. no variable > length metadata is present), the C bit MUST be set to 0x0. >=20 > 6.1. What is the behavior of the implementation if C-bit is set but not c= ritical metadata is found in the payload? > 6.2. What is the behavior of the implementation if C-bit is unset but a c= ritical metadata is found in the payload? > 6.3. What is the behavior of the implementation with regards to this bit = if a critical metadata is added in-path? > 6.4. What is the behavior of the implementation with regards to this bit = if a critical metadata is stripped in-path? =20 > 6.5. Should the specification recommend an order of metadata so that crit= ical metadata are always positioned first? PQ> =20 6.1: essentially continue "as is" with an optional warning message 6.2: generate an warning error, possibly set C 6.3: the adder sets C 6.4: the remover clears C 6.5: no, this creates too many limitations/complexity. An implementation m= ight opt to optimize. =20 >=20 > (7) Section 3.3: The following text=20 >=20 > " ... however the > control plane MAY configure the initial value of SI as appropriate > (i.e. taking into account the length of the service function path). " >=20 > is not aligned with the outcome of the discussion we had during the WG LC= of draft-ietf-sfc-control-plane (https://www.ietf.org/mail-archive/web/sfc= /current/msg04594.html): >=20 > The control plane must instruct the classifier about the initial > values of the Service Index (SI). >=20 PQ> The control plane can assign but NSH provides a default value recommen= dation, I'm not sure there's a conflict. > 7.1. I suggest to modify NSH draft accordingly.=20 PQ> I'm not clear what you are suggesting? > 7.2. Please consider adding a reference to draft-ietf-sfc-control-plane PQ> I'll update. >=20 > (8) Section 3.4: I still do think this section is underspecified. E.g.,=20 >=20 > 8.1. The use of "Mandatory Context Header" conflicts with this text in Se= ction 3: >=20 > A Network Service Header (NSH) contains service path information and > optionally metadata that are added to a packet or frame and used to > ^^^^^^^^^^^^^^^^^^^ > create a service plane. >=20 > 8.2. The specification does not forbid that all context headers are set t= o zero. Otherwise, MD#2 should be used instead. PQ> In either care, 1 or 2, no metadata is valid: all zeroes in type 1 or = no data in type 2. =20 > 8.3. The specification does not specify how these context headers are to = be validated.=20 PQ> By validated, so you mean cryptographically asserted, or simply compar= ed to known value? In either case, that is outside of the scope of this dr= aft. > 8.4. I still don't understand why four headers are chosen. =20 PQ> As per previous discussions, based experience, use case and implementa= tion, four strikes a balance. The widespread implementations of type 1 supp= ort this. >=20 > (9) Section 3.5.1: >=20 > The length of "Metadata Class" is over-dimensioned. I suggest to reduce t= he length of this field and increase the length of "Type". >=20 > For example, let's consider the proposal in https://tools.ietf.org/html/d= raft-napper-sfc-nsh-broadband-allocation-00#section-4.2:=20 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class =3D 3GPP |C| Type |R|R|R| Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ... > +-+-+-+-+-+-+-+-+ >=20 > Figure 5: TLV Allocation >=20 > The intended use of the header is for TLVs associated with 3GPP Radio > Access Networks as described in [TS.29.230]. This TLV can be used by > 3GPP to extend the metadata as per use cases. Having this TLV helps > to carry more information that does not fit within the MD Type 0x01. >=20 > The list of codes in Table 7.1 of TS.29.230 cannot be conveyed with a "Ty= pe" field of 7 bits. PQ> At this point, the allocation seems reasonable, provides for a large r= ange of "owners", and the TLV schemes proposed work within this scope. >=20 > (10) Section 4:=20 >=20 > OLD: >=20 > +---------------+------------------+-------+----------------+---------+ > | | Insert |Select | Update |Service | > | | or remove NSH |Service| NSH |policy | > | | |Function| |selection| > | Component +--------+--------+Path +----------------+ | > | | | | | Dec. |Update | | > | | Insert | Remove | |Service |Context| | > | | | | | Index |Header | | > +----------------+--------+--------+-------+--------+-------+---------+ > | | + | + | | | + | | > |Classifier | | | | | | | > +--------------- +--------+--------+-------+--------+-------+---------+ > |Service Function| | + | + | | | | > |Forwarder(SFF) | | | | | | | > +--------------- +--------+--------+-------+--------+-------+---------+ > |Service | | | | + | + | + | > |Function (SF) | | | | | | | > +--------------- +--------+--------+-------+--------+-------+---------+ > |SFC Proxy | + | + | | + | | | > +----------------+--------+--------+-------+--------+-------+---------+ >=20 > NEW: >=20 > +---------------+------------------+-------+----------------+---------+ > | | Insert |Select | Update |Service | > | | or remove NSH |Service| NSH |policy | > | | |Function| |selection| > | Component +--------+--------+Path +----------------+ | > | | | | | Dec. |Update | | > | | Insert | Remove | |Service |Context| | > | | | | | Index |Header | | > +----------------+--------+--------+-------+--------+-------+---------+ > | | + | + | | | + | | > |Classifier | | | | | | | > +--------------- +--------+--------+-------+--------+-------+---------+ > |Service Function| | + | + | | | | > |Forwarder(SFF) | | | | | | | > +--------------- +--------+--------+-------+--------+-------+---------+ > |Service | | | | + | + | + | > |Function (SF) | | | | | | | > +--------------- +--------+--------+-------+--------+-------+---------+ > |SFC Proxy | + | + | | + | + | | > +----------------+--------+--------+-------+--------+-------+---------+ PQ> Just to be clear (formatting was a bit off in the email): In the last line, SFC Proxy, add "Update Context Header"? >=20 > (11) Section 7.2: Please consider adding an IPv6 example. PQ> Happily. = From nobody Tue Sep 13 13:34:17 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E14CF12B09A; Tue, 13 Sep 2016 13:34:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147379885191.25402.541589359832829101.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 13:34:11 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 20:34:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Dapeng Liu Ting Ao Vu Anh Vu Filename : draft-ietf-sfc-hierarchical-01.txt Pages : 25 Date : 2016-09-13 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to compartmentalize a large- scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to able support independent functional groups within large operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 13 13:41:25 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6606C12B092 for ; Tue, 13 Sep 2016 13:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 t-jHzTOjnC7z for ; Tue, 13 Sep 2016 13:41:22 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BBE12B08F for ; Tue, 13 Sep 2016 13:41:22 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Tue, 13 Sep 2016 16:41:20 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-hierarchical-01.txt Thread-Index: AQHSDf47DHLJe/5SB0m254hv98I3NaB34JVg Date: Tue, 13 Sep 2016 20:41:19 +0000 Message-ID: References: <147379885229.25402.3097712054841900860.idtracker@ietfa.amsl.com> In-Reply-To: <147379885229.25402.3097712054841900860.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-ietf-sfc-hierarchical-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 20:41:24 -0000 U0ZDIHdvcmtpbmcgZ3JvdXAsDQpXaXRoIHNvbWUgZmVlZGJhY2ssIHRoZSBhdXRob3JzIGhhdmUg bWFkZSBpbXByb3ZlbWVudHMgdG8gZHJhZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsLg0KSXQgaXMg bm93IGF2YWlsYWJsZSBoZXJlOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1zZmMtaGllcmFyY2hpY2FsLTAxDQoNCi0gYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mIGVkaXRv cmlhbCBhbmQgY2xhcmlmeWluZyBjaGFuZ2VzDQotIHNvbWUgbmV3IHBhcmFncmFwaHMgYWJvdXQg bWV0YWRhdGENCi0gYSBjb250cm9sLXBsYW5lIHNlY3Rpb24gaW4gU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KLURhdmUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNiA0OjM0IFBNDQpUbzogU2h1bnN1a2Ug SG9tbWE7IERpZWdvIExvcGV6OyBWdSBBbmggVnU7IERpZWdvIFIuIExvcGV6OyBUaW5nIEFvOyBE YXZlIERvbHNvbjsgc2ZjLWNoYWlyc0BpZXRmLm9yZzsgTW9oYW1lZCBCb3VjYWRhaXI7IERhcGVu ZyBMaXUNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1z ZmMtaGllcmFyY2hpY2FsLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1p ZXRmLXNmYy1oaWVyYXJjaGljYWwtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IERhdmlkIERvbHNvbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsDQpSZXZpc2lvbjoJMDENClRpdGxl OgkJSGllcmFyY2hpY2FsIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKGhTRkMpDQpEb2N1bWVu dCBkYXRlOgkyMDE2LTA5LTEzDQpHcm91cDoJCXNmYw0KUGFnZXM6CQkyNQ0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNmYy1o aWVyYXJjaGljYWwtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwt MDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsLTAxDQoNCkFic3RyYWN0Og0KICAgSGllcmFyY2hpY2Fs IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKGhTRkMpIGlzIGEgbmV0d29yaw0KICAgYXJjaGl0 ZWN0dXJlIGFsbG93aW5nIGFuIG9yZ2FuaXphdGlvbiB0byBjb21wYXJ0bWVudGFsaXplIGEgbGFy Z2UtDQogICBzY2FsZSBuZXR3b3JrIGludG8gbXVsdGlwbGUgZG9tYWlucyBvZiBhZG1pbmlzdHJh dGlvbi4NCg0KICAgVGhlIGdvYWxzIG9mIGhTRkMgYXJlIHRvIG1ha2UgYSBsYXJnZS1zY2FsZSBu ZXR3b3JrIGVhc2llciB0byByZWFzb24NCiAgIGFib3V0LCBzaW1wbGVyIHRvIGNvbnRyb2wgYW5k IHRvIGFibGUgc3VwcG9ydCBpbmRlcGVuZGVudCBmdW5jdGlvbmFsDQogICBncm91cHMgd2l0aGlu IGxhcmdlIG9wZXJhdG9ycy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Sep 14 09:33:55 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E41412B2C4 for ; Wed, 14 Sep 2016 09:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 AVfAj9bxkUxQ for ; Wed, 14 Sep 2016 09:33:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610A312B213 for ; Wed, 14 Sep 2016 09:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4787; q=dns/txt; s=iport; t=1473870829; x=1475080429; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EMbgjipiHUUsfAn2ijk2e+MUw6hq3ZgFucdyy8fB55Q=; b=LZwaTuvYrsEzLtWTdmvUAz3CpojPieL+o6R7/sw+CRacpIV93jmQ/jEn DVTbfxK+nRYqbT75l6luxzaHNbAXbBILYOkHJOLumCREJ/9BCoLbpuOC8 fJsFn9qNYuNLYZeUmKKmOhzFXOwyaB1cYvjozjQGF/Pz6XAoR8YdzoucG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAQDVetlX/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR5XfAeNLKslggMZC4V6AoFPOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwEBAQE3NAsFBwQCAQgOAwEDAQEBHgkHJwsUAwYIAgQOBYhCCA68QQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARyGMYF5glaEQIMtgi8FmWgBhiSJL4FuToQSgza?= =?us-ascii?q?EOYEljFuDegEeNoJ/G4FPcIYifwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,334,1470700800"; d="scan'208";a="148992447" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2016 16:33:48 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u8EGXm5D005121 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Sep 2016 16:33:48 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 11:33:47 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 14 Sep 2016 11:33:47 -0500 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4A= Date: Wed, 14 Sep 2016 16:33:47 +0000 Message-ID: <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.237] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 16:33:52 -0000 Dave, Thanks for these suggestions/clarifications, I can see how this might be mi= sinterpreted. My concern is with the work "configuration" in the first sentence since it = might imply the need for configuration vs default. So a minor tweak: "The initial classifier MUST set the appropriate SPI and SI values for a gi= ven classification result. The initial SI configuration SHOULD default to = 255. However, the classifier MUST allow configuration of other SI values." Paul > On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >=20 > I have a comment on the specification of Service Index (SI). > The document says,=20 > The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 > control plane MAY configure the initial value of SI as appropriate... >=20 > If you read this literally, it seems to say that the classifier SHOULD se= t the initial SI to 255 regardless of what the control plane tells it to do= . > It is perhaps implied that the classifier MAY do what the control plane t= ells it to, but that's not what the words say. >=20 > I think wording like this might help: > The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >=20 > Similar wording should apply to the SPI; nothing is said about the classi= fier in the paragraph about SPI. I suggest: > The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome. >=20 > Note, I've said "configuration" instead of "control plane". I'm assuming = a control plane will do configuration. If you just want to talk about contr= ol plane, then there is no need for any default, just "The classifier MUST = set the SET to the value specified by the control plane for the classificat= ion." >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguich= ar) > Sent: Tuesday, August 23, 2016 12:48 PM > To: sfc@ietf.org > Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Dear WG: >=20 > Please review this new version of the SFC encapsulation to make sure that= your comments from the previous WGLC have been addressed.=20 >=20 > Any comments and/or concerns please post to the mailing list within the n= ext two weeks so that this work can be progressed. >=20 > As a heads up, if there are still substantive comments we plan to hold an= interim meeting on September 15th to address any outstanding issues >=20 >=20 > Thanks! >=20 > Jim, Martin, & Thomas >=20 >=20 >=20 >=20 > On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Service Function Chaining of the IETF. >>=20 >> Title : Network Service Header >> Authors : Paul Quinn >> Uri Elzur >> Filename : draft-ietf-sfc-nsh-07.txt >> Pages : 37 >> Date : 2016-08-23 >>=20 >> Abstract: >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> provides a mechanism for metadata exchange along the instantiated >> service path. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Sep 14 10:08:11 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7842D12B35E for ; Wed, 14 Sep 2016 10:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 IiyLxduncgDN for ; Wed, 14 Sep 2016 10:08:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D223712B392 for ; Wed, 14 Sep 2016 10:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2556; q=dns/txt; s=iport; t=1473872888; x=1475082488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fqpcPMtmu7ABmT9QiaQO3kF1SXN5JBoEofpkcq6JZ8E=; b=G2lSpsU3b/GjHDEEl+KEGZ1MI1Ec00jTtAPK5E/CABj7dV+C7NXYrnK5 4dqjgswp8d+BHqmMdknT7m9seVtAl4jQ2BglBOiYVNrhlZgFrQ7t7w6T7 zVqfCZgKxz4kYuizD4T1X9hYUcIseWb6o5Foll7ZiOk76VZCZrx3fdG2q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAQDYgtlX/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR6BUweNLKslggOGHgKBUDgUAQIBAQEBAQEBXieEYQE?= =?us-ascii?q?BAQMBOj8FCwIBCBgeEDIlAgQOBYhCCLxYAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?IYxgXkIgk6EQIMtgi8FmWgBj1OBboRgiRSMW4N6AR42hGlwAYYhfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,334,1470700800"; d="scan'208";a="323524537" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 17:08:07 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u8EH87fk025826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Sep 2016 17:08:08 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 12:08:07 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 14 Sep 2016 12:08:07 -0500 From: "Paul Quinn (paulq)" To: "Duarte Cardoso, Igor" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAFtHPCAC2pGAA== Date: Wed, 14 Sep 2016 17:08:07 +0000 Message-ID: <953B5A05-B9B0-4209-B2E8-5A94E6121D73@cisco.com> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D85462571F4844698BF5E2519799F6B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:08:10 -0000 Igor, Thank you for your comments. Please see inline. > On Sep 7, 2016, at 12:31 PM, Duarte Cardoso, Igor wrote: >=20 > Hi SFC WG, >=20 > I have some comments and trivial corrections to provide to draft-ietf-sfc= -nsh-07. >=20 > - "confidentially" should be "confidentiality" in both of its occurrences= ; >=20 > - At the end of section 9: > - "describe in" should be "described in" > - "MD-2" should be "MD-Type 2" >=20 > - Also consider converging to either "MD Type" or "MD-Type", as both seem= to be used throughout the draft; >=20 PQ> Thank you, all of the above have been updated. >=20 > - Section 3.3: >=20 > - "SI SHOULD be used in conjunction with SPI for SFP selection and for de= termining the next SFF/SF in the path": >=20 > Two comments: >=20 > - The statement (and the rest of the paragraph) seems to be about the f= orwarding side of NSH (forwarding/SFFs) However, it also seems to be about = the classification side of NSH (classification/Classifiers) as they are the= logical elements which, with the influence of different SPI+SI, choose the= next SFP (specifically, the next SPI). Can this perhaps be clarified? >=20 > - Assuming SFP is the concrete network path that will be taken to reach= the next SF, which may be 1 of many possible SFPs for the same SPI/SI comb= ination, then the statement seems to imply that SI+SPI allow for SFP select= ion AND determining the next SFF/SF. However, the latter is a consequence o= f the former. I believe the following would better reflect the intended obj= ective of the original statement: >=20 > "SI SHOULD be used in conjunction with SPI for SFP selection and, conse= quently, determining the next SFF/SF in the path". PQ> I'm fine with this clarification. =20 >=20 > - "When an SPI and SI do not correspond to a valid next Service Function = path" >=20 > If my above assumption regarding 1 of many possible SFPs being possible = for the same SPI/SI combination is incorrect, then this statement seems to = imply that SPI and SIs together map to a SFP, but in reality they together = map to a SF. > If so, I believe that the following would better reflect the intended ob= jective of the original statement: >=20 > "When an SPI and SI do not correspond to a valid next hop of a Service F= unction". PQ> I think this has a slightly different meaning but I do see your point.= Perhaps: "When an SPI and SI do not correspond to a valid next hop in a SFP" From nobody Wed Sep 14 10:16:07 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C747C12B2E8 for ; Wed, 14 Sep 2016 10:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 Hrx7R5x6mw-C for ; Wed, 14 Sep 2016 10:16:04 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F326612B377 for ; Wed, 14 Sep 2016 10:16:02 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 14 Sep 2016 13:15:56 -0400 From: Dave Dolson To: "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4D//7c6oA== Date: Wed, 14 Sep 2016 17:15:54 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> In-Reply-To: <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:16:06 -0000 Yes, that is good. How do you feel about adding another "configured"? "The initial classifier MUST set the appropriate SPI and SI values configur= ed for a given classification result. The initial SI configuration SHOULD = default to 255. However, the classifier MUST allow configuration of other S= I values." -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, September 14, 2016 12:34 PM To: Dave Dolson Cc: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Dave, Thanks for these suggestions/clarifications, I can see how this might be mi= sinterpreted. My concern is with the work "configuration" in the first sentence since it = might imply the need for configuration vs default. So a minor tweak: "The initial classifier MUST set the appropriate SPI and SI values for a gi= ven classification result. The initial SI configuration SHOULD default to = 255. However, the classifier MUST allow configuration of other SI values." Paul > On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >=20 > I have a comment on the specification of Service Index (SI). > The document says,=20 > The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 > control plane MAY configure the initial value of SI as appropriate... >=20 > If you read this literally, it seems to say that the classifier SHOULD se= t the initial SI to 255 regardless of what the control plane tells it to do= . > It is perhaps implied that the classifier MAY do what the control plane t= ells it to, but that's not what the words say. >=20 > I think wording like this might help: > The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >=20 > Similar wording should apply to the SPI; nothing is said about the classi= fier in the paragraph about SPI. I suggest: > The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome. >=20 > Note, I've said "configuration" instead of "control plane". I'm assuming = a control plane will do configuration. If you just want to talk about contr= ol plane, then there is no need for any default, just "The classifier MUST = set the SET to the value specified by the control plane for the classificat= ion." >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguich= ar) > Sent: Tuesday, August 23, 2016 12:48 PM > To: sfc@ietf.org > Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Dear WG: >=20 > Please review this new version of the SFC encapsulation to make sure that= your comments from the previous WGLC have been addressed.=20 >=20 > Any comments and/or concerns please post to the mailing list within the n= ext two weeks so that this work can be progressed. >=20 > As a heads up, if there are still substantive comments we plan to hold an= interim meeting on September 15th to address any outstanding issues >=20 >=20 > Thanks! >=20 > Jim, Martin, & Thomas >=20 >=20 >=20 >=20 > On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Service Function Chaining of the IETF. >>=20 >> Title : Network Service Header >> Authors : Paul Quinn >> Uri Elzur >> Filename : draft-ietf-sfc-nsh-07.txt >> Pages : 37 >> Date : 2016-08-23 >>=20 >> Abstract: >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> provides a mechanism for metadata exchange along the instantiated >> service path. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Sep 14 10:18:27 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCD12B35E for ; Wed, 14 Sep 2016 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 CI_M1vxAFj4J for ; Wed, 14 Sep 2016 10:18:23 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0607F12B38E for ; Wed, 14 Sep 2016 10:18:19 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 14 Sep 2016 13:18:18 -0400 From: Dave Dolson To: Dave Dolson , "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4D//7c6oIAAAQNg Date: Wed, 14 Sep 2016 17:18:17 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:18:27 -0000 Sorry, I see I didn't properly read your concern about "configuration" in t= he first sentence. I guess I don't understand your concern. Surely the SPI= and SI are configured, although SI may default to 255. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, September 14, 2016 1:16 PM To: Paul Quinn (paulq) Cc: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Yes, that is good. How do you feel about adding another "configured"? "The initial classifier MUST set the appropriate SPI and SI values configur= ed for a given classification result. The initial SI configuration SHOULD = default to 255. However, the classifier MUST allow configuration of other S= I values." -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, September 14, 2016 12:34 PM To: Dave Dolson Cc: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Dave, Thanks for these suggestions/clarifications, I can see how this might be mi= sinterpreted. My concern is with the work "configuration" in the first sentence since it = might imply the need for configuration vs default. So a minor tweak: "The initial classifier MUST set the appropriate SPI and SI values for a gi= ven classification result. The initial SI configuration SHOULD default to = 255. However, the classifier MUST allow configuration of other SI values." Paul > On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >=20 > I have a comment on the specification of Service Index (SI). > The document says,=20 > The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 > control plane MAY configure the initial value of SI as appropriate... >=20 > If you read this literally, it seems to say that the classifier SHOULD se= t the initial SI to 255 regardless of what the control plane tells it to do= . > It is perhaps implied that the classifier MAY do what the control plane t= ells it to, but that's not what the words say. >=20 > I think wording like this might help: > The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >=20 > Similar wording should apply to the SPI; nothing is said about the classi= fier in the paragraph about SPI. I suggest: > The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome. >=20 > Note, I've said "configuration" instead of "control plane". I'm assuming = a control plane will do configuration. If you just want to talk about contr= ol plane, then there is no need for any default, just "The classifier MUST = set the SET to the value specified by the control plane for the classificat= ion." >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguich= ar) > Sent: Tuesday, August 23, 2016 12:48 PM > To: sfc@ietf.org > Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Dear WG: >=20 > Please review this new version of the SFC encapsulation to make sure that= your comments from the previous WGLC have been addressed.=20 >=20 > Any comments and/or concerns please post to the mailing list within the n= ext two weeks so that this work can be progressed. >=20 > As a heads up, if there are still substantive comments we plan to hold an= interim meeting on September 15th to address any outstanding issues >=20 >=20 > Thanks! >=20 > Jim, Martin, & Thomas >=20 >=20 >=20 >=20 > On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Service Function Chaining of the IETF. >>=20 >> Title : Network Service Header >> Authors : Paul Quinn >> Uri Elzur >> Filename : draft-ietf-sfc-nsh-07.txt >> Pages : 37 >> Date : 2016-08-23 >>=20 >> Abstract: >> This document describes a Network Service Header (NSH) inserted onto >> packets or frames to realize service function paths. NSH also >> provides a mechanism for metadata exchange along the instantiated >> service path. NSH is the SFC encapsulation required to support the >> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 >=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 Wed Sep 14 10:23:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C70012B3CC for ; Wed, 14 Sep 2016 10:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 W3UrS-K6P9U3 for ; Wed, 14 Sep 2016 10:23:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB89712B3A1 for ; Wed, 14 Sep 2016 10:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6658; q=dns/txt; s=iport; t=1473873826; x=1475083426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gPpv/drcsCEDp5vL3xJxjh+6GU+PlApnzAaaSphKQ9s=; b=d+eEaX08GdOyKb03Y51xAUHWY1FLhXXFjjyLuAKDCuVXaBweJGwkkM7b rwu8Monebkd4j+IMXJBPsTrTiuDY7IHMMHxc5kx91Kfpof567WukBEMXE 3/nty755RKZOWM8cUBIgjqBKNhDcDZHVt4vskoZih4iZd91SEQAFnwLJZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAQCYhtlX/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR5XfAeNLKslggMZC4V6AoFQOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwEBAQE3NAsFBwQCAQgOAwEDAQEBHgkHJwsUAwYIAgQOBYhCCA68RwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARyGMYF5glaEQIMtgi8FmWgBhiSJLwqBZE6EEoM?= =?us-ascii?q?2hDmBJYxbg3oBHjaCfxuBT3CGIn8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,334,1470700800"; d="scan'208";a="147188947" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2016 17:23:45 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u8EHNjtl028840 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Sep 2016 17:23:45 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 12:23:44 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 14 Sep 2016 12:23:44 -0500 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4D//7c6oIAAAQNggABVt4A= Date: Wed, 14 Sep 2016 17:23:44 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <899B5A67C9894C439F1875F23D04514B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:23:49 -0000 I suggest omitting that "configured" (i.e. the one in the first sentence) s= ince it implies an explicit configuration vs. a default (by which I mean be= havior absent of an explicit configuration). For SPI this isn't true (i.e.= you need explicit config) but the point the original text was trying to ma= ke was that, for SI, no explicitly config is needed, although it can be sup= plied. > On Sep 14, 2016, at 1:18 PM, Dave Dolson wrote: >=20 > Sorry, I see I didn't properly read your concern about "configuration" in= the first sentence. I guess I don't understand your concern. Surely the S= PI and SI are configured, although SI may default to 255. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Wednesday, September 14, 2016 1:16 PM > To: Paul Quinn (paulq) > Cc: Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Yes, that is good. How do you feel about adding another "configured"? >=20 > "The initial classifier MUST set the appropriate SPI and SI values config= ured for a given classification result. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values." >=20 >=20 > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 > Sent: Wednesday, September 14, 2016 12:34 PM > To: Dave Dolson > Cc: Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Dave, >=20 > Thanks for these suggestions/clarifications, I can see how this might be = misinterpreted. >=20 > My concern is with the work "configuration" in the first sentence since i= t might imply the need for configuration vs default. So a minor tweak: >=20 > "The initial classifier MUST set the appropriate SPI and SI values for a = given classification result. The initial SI configuration SHOULD default t= o 255. However, the classifier MUST allow configuration of other SI values.= " >=20 > Paul >=20 >> On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >>=20 >> I have a comment on the specification of Service Index (SI). >> The document says,=20 >> The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 >> control plane MAY configure the initial value of SI as appropriate... >>=20 >> If you read this literally, it seems to say that the classifier SHOULD s= et the initial SI to 255 regardless of what the control plane tells it to d= o. >> It is perhaps implied that the classifier MAY do what the control plane = tells it to, but that's not what the words say. >>=20 >> I think wording like this might help: >> The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >>=20 >> Similar wording should apply to the SPI; nothing is said about the class= ifier in the paragraph about SPI. I suggest: >> The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome. >>=20 >> Note, I've said "configuration" instead of "control plane". I'm assuming= a control plane will do configuration. If you just want to talk about cont= rol plane, then there is no need for any default, just "The classifier MUST= set the SET to the value specified by the control plane for the classifica= tion." >>=20 >>=20 >> -Dave >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguic= har) >> Sent: Tuesday, August 23, 2016 12:48 PM >> To: sfc@ietf.org >> Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>=20 >> Dear WG: >>=20 >> Please review this new version of the SFC encapsulation to make sure tha= t your comments from the previous WGLC have been addressed.=20 >>=20 >> Any comments and/or concerns please post to the mailing list within the = next two weeks so that this work can be progressed. >>=20 >> As a heads up, if there are still substantive comments we plan to hold a= n interim meeting on September 15th to address any outstanding issues >>=20 >>=20 >> Thanks! >>=20 >> Jim, Martin, & Thomas >>=20 >>=20 >>=20 >>=20 >> On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Service Function Chaining of the IETF. >>>=20 >>> Title : Network Service Header >>> Authors : Paul Quinn >>> Uri Elzur >>> Filename : draft-ietf-sfc-nsh-07.txt >>> Pages : 37 >>> Date : 2016-08-23 >>>=20 >>> Abstract: >>> This document describes a Network Service Header (NSH) inserted onto >>> packets or frames to realize service function paths. NSH also >>> provides a mechanism for metadata exchange along the instantiated >>> service path. NSH is the SFC encapsulation required to support the >>> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=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 >>=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 Sep 14 10:28:57 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07012B3D5 for ; Wed, 14 Sep 2016 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 dYCuL0r7m5MS for ; Wed, 14 Sep 2016 10:28:54 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA0F12B3D4 for ; Wed, 14 Sep 2016 10:28:54 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0294.000; Wed, 14 Sep 2016 13:28:52 -0400 From: Dave Dolson To: "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4D//7c6oIAAAQNggABVt4D//6zJ0A== Date: Wed, 14 Sep 2016 17:28:51 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:28:56 -0000 OK, I see, yes. This is in the paragraph describing the SI. Will you update the SPI section ? -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, September 14, 2016 1:24 PM To: Dave Dolson Cc: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt I suggest omitting that "configured" (i.e. the one in the first sentence) s= ince it implies an explicit configuration vs. a default (by which I mean be= havior absent of an explicit configuration). For SPI this isn't true (i.e.= you need explicit config) but the point the original text was trying to ma= ke was that, for SI, no explicitly config is needed, although it can be sup= plied. > On Sep 14, 2016, at 1:18 PM, Dave Dolson wrote: >=20 > Sorry, I see I didn't properly read your concern about "configuration" in= the first sentence. I guess I don't understand your concern. Surely the S= PI and SI are configured, although SI may default to 255. >=20 > -Dave >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Wednesday, September 14, 2016 1:16 PM > To: Paul Quinn (paulq) > Cc: Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Yes, that is good. How do you feel about adding another "configured"? >=20 > "The initial classifier MUST set the appropriate SPI and SI values config= ured for a given classification result. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values." >=20 >=20 > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 > Sent: Wednesday, September 14, 2016 12:34 PM > To: Dave Dolson > Cc: Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Dave, >=20 > Thanks for these suggestions/clarifications, I can see how this might be = misinterpreted. >=20 > My concern is with the work "configuration" in the first sentence since i= t might imply the need for configuration vs default. So a minor tweak: >=20 > "The initial classifier MUST set the appropriate SPI and SI values for a = given classification result. The initial SI configuration SHOULD default t= o 255. However, the classifier MUST allow configuration of other SI values.= " >=20 > Paul >=20 >> On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >>=20 >> I have a comment on the specification of Service Index (SI). >> The document says,=20 >> The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 >> control plane MAY configure the initial value of SI as appropriate... >>=20 >> If you read this literally, it seems to say that the classifier SHOULD s= et the initial SI to 255 regardless of what the control plane tells it to d= o. >> It is perhaps implied that the classifier MAY do what the control plane = tells it to, but that's not what the words say. >>=20 >> I think wording like this might help: >> The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >>=20 >> Similar wording should apply to the SPI; nothing is said about the class= ifier in the paragraph about SPI. I suggest: >> The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome.=09 >>=20 >> Note, I've said "configuration" instead of "control plane". I'm assuming= a control plane will do configuration. If you just want to talk about cont= rol plane, then there is no need for any default, just "The classifier MUST= set the SET to the value specified by the control plane for the classifica= tion." >>=20 >>=20 >> -Dave >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguic= har) >> Sent: Tuesday, August 23, 2016 12:48 PM >> To: sfc@ietf.org >> Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>=20 >> Dear WG: >>=20 >> Please review this new version of the SFC encapsulation to make sure tha= t your comments from the previous WGLC have been addressed.=20 >>=20 >> Any comments and/or concerns please post to the mailing list within the = next two weeks so that this work can be progressed. >>=20 >> As a heads up, if there are still substantive comments we plan to hold a= n interim meeting on September 15th to address any outstanding issues >>=20 >>=20 >> Thanks! >>=20 >> Jim, Martin, & Thomas >>=20 >>=20 >>=20 >>=20 >> On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Service Function Chaining of the IETF. >>>=20 >>> Title : Network Service Header >>> Authors : Paul Quinn >>> Uri Elzur >>> Filename : draft-ietf-sfc-nsh-07.txt >>> Pages : 37 >>> Date : 2016-08-23 >>>=20 >>> Abstract: >>> This document describes a Network Service Header (NSH) inserted onto >>> packets or frames to realize service function paths. NSH also >>> provides a mechanism for metadata exchange along the instantiated >>> service path. NSH is the SFC encapsulation required to support the >>> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>>=20 >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=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 >>=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 Sep 14 10:34:43 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E3712B3A8 for ; Wed, 14 Sep 2016 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 i3Hxy0cKGx8A for ; Wed, 14 Sep 2016 10:34:37 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9692112B373 for ; Wed, 14 Sep 2016 10:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7550; q=dns/txt; s=iport; t=1473874477; x=1475084077; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vsPEcEefNkEmPSoxAiD3ydWfvY2wDyURSrMsnIqBTeI=; b=l8Re35ikV2DiI0NW3pckuPy6gc6hj0ISf1hKgIQ0MZEnlPMmMpV9zAqj /J4I2rCZuV9v6DK35Cd74pzdmow66t4utllu9F6ghMvXEr9S/Uh4H1WcX S/BrVKF5rBzB9RNCaslanfMn+sh8U8nBnr/mwSQREoDMM3btIHpHzM4ST o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAQD3iNlX/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAR5XfAeNLKslggMZC4V6AoFQOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwEBAQE3NAsFBwQCAQgOAwEDAQEBHgkHJwsUAwYIAgQOBYhCCA68QAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARyGMYF5CIJOhECDLYIvBZloAYYkiS+Bbk6EEoM?= =?us-ascii?q?2hDmBJYZ6hWGDegEeNoJ/G4FPcIYifwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,334,1470700800"; d="scan'208";a="321744323" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 17:34:36 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8EHYavJ022579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Sep 2016 17:34:36 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Sep 2016 12:34:35 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 14 Sep 2016 12:34:35 -0500 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4D//7c6oIAAAQNggABVt4D//6zJ0IAAVj6A Date: Wed, 14 Sep 2016 17:34:35 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.32.237] Content-Type: text/plain; charset="us-ascii" Content-ID: <343C42267D3F2A48A4439C5B8D568BD7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:34:40 -0000 Yes, I think it's reasonable to add similar text there as well: "The initial classifier MUST set the appropriate SPI for a given classifica= tion result." I believe that encompasses configured vs. default which is appropriate, IMO= , in this section. > On Sep 14, 2016, at 1:28 PM, Dave Dolson wrote: >=20 > OK, I see, yes. This is in the paragraph describing the SI. >=20 > Will you update the SPI section ? >=20 >=20 >=20 > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 > Sent: Wednesday, September 14, 2016 1:24 PM > To: Dave Dolson > Cc: Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > I suggest omitting that "configured" (i.e. the one in the first sentence)= since it implies an explicit configuration vs. a default (by which I mean = behavior absent of an explicit configuration). For SPI this isn't true (i.= e. you need explicit config) but the point the original text was trying to = make was that, for SI, no explicitly config is needed, although it can be s= upplied. >=20 >=20 >=20 >=20 >> On Sep 14, 2016, at 1:18 PM, Dave Dolson wrote: >>=20 >> Sorry, I see I didn't properly read your concern about "configuration" i= n the first sentence. I guess I don't understand your concern. Surely the = SPI and SI are configured, although SI may default to 255. >>=20 >> -Dave >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Wednesday, September 14, 2016 1:16 PM >> To: Paul Quinn (paulq) >> Cc: Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>=20 >> Yes, that is good. How do you feel about adding another "configured"? >>=20 >> "The initial classifier MUST set the appropriate SPI and SI values confi= gured for a given classification result. The initial SI configuration SHOU= LD default to 255. However, the classifier MUST allow configuration of othe= r SI values." >>=20 >>=20 >> -----Original Message----- >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 >> Sent: Wednesday, September 14, 2016 12:34 PM >> To: Dave Dolson >> Cc: Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>=20 >> Dave, >>=20 >> Thanks for these suggestions/clarifications, I can see how this might be= misinterpreted. >>=20 >> My concern is with the work "configuration" in the first sentence since = it might imply the need for configuration vs default. So a minor tweak: >>=20 >> "The initial classifier MUST set the appropriate SPI and SI values for a= given classification result. The initial SI configuration SHOULD default = to 255. However, the classifier MUST allow configuration of other SI values= ." >>=20 >> Paul >>=20 >>> On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >>>=20 >>> I have a comment on the specification of Service Index (SI). >>> The document says,=20 >>> The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 >>> control plane MAY configure the initial value of SI as appropriate... >>>=20 >>> If you read this literally, it seems to say that the classifier SHOULD = set the initial SI to 255 regardless of what the control plane tells it to = do. >>> It is perhaps implied that the classifier MAY do what the control plane= tells it to, but that's not what the words say. >>>=20 >>> I think wording like this might help: >>> The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >>>=20 >>> Similar wording should apply to the SPI; nothing is said about the clas= sifier in the paragraph about SPI. I suggest: >>> The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome.=09 >>>=20 >>> Note, I've said "configuration" instead of "control plane". I'm assumin= g a control plane will do configuration. If you just want to talk about con= trol plane, then there is no need for any default, just "The classifier MUS= T set the SET to the value specified by the control plane for the classific= ation." >>>=20 >>>=20 >>> -Dave >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jgui= char) >>> Sent: Tuesday, August 23, 2016 12:48 PM >>> To: sfc@ietf.org >>> Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>>=20 >>> Dear WG: >>>=20 >>> Please review this new version of the SFC encapsulation to make sure th= at your comments from the previous WGLC have been addressed.=20 >>>=20 >>> Any comments and/or concerns please post to the mailing list within the= next two weeks so that this work can be progressed. >>>=20 >>> As a heads up, if there are still substantive comments we plan to hold = an interim meeting on September 15th to address any outstanding issues >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Jim, Martin, & Thomas >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Service Function Chaining of the IETF= . >>>>=20 >>>> Title : Network Service Header >>>> Authors : Paul Quinn >>>> Uri Elzur >>>> Filename : draft-ietf-sfc-nsh-07.txt >>>> Pages : 37 >>>> Date : 2016-08-23 >>>>=20 >>>> Abstract: >>>> This document describes a Network Service Header (NSH) inserted onto >>>> packets or frames to realize service function paths. NSH also >>>> provides a mechanism for metadata exchange along the instantiated >>>> service path. NSH is the SFC encapsulation required to support the >>>> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of subm= ission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=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 >>>=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 Wed Sep 14 10:38:03 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C7812B3C0 for ; Wed, 14 Sep 2016 10:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 YRq5QHMcDdIs for ; Wed, 14 Sep 2016 10:37:59 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9545D12B3CB for ; Wed, 14 Sep 2016 10:37:59 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Wed, 14 Sep 2016 13:37:57 -0400 From: Dave Dolson To: "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Bs1tLAgAzNy4D//7c6oIAAAQNggABVt4D//6zJ0IAAVj6A//+tHbA= Date: Wed, 14 Sep 2016 17:37:57 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <7BF086FE-BE2A-4CB6-9C8C-67432F40C414@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 17:38:02 -0000 Thanks -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Wednesday, September 14, 2016 1:35 PM To: Dave Dolson Cc: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Yes, I think it's reasonable to add similar text there as well: "The initial classifier MUST set the appropriate SPI for a given classifica= tion result." I believe that encompasses configured vs. default which is appropriate, IMO= , in this section. > On Sep 14, 2016, at 1:28 PM, Dave Dolson wrote: >=20 > OK, I see, yes. This is in the paragraph describing the SI. >=20 > Will you update the SPI section ? >=20 >=20 >=20 > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 > Sent: Wednesday, September 14, 2016 1:24 PM > To: Dave Dolson > Cc: Jim Guichard (jguichar); sfc@ietf.org > Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > I suggest omitting that "configured" (i.e. the one in the first sentence)= since it implies an explicit configuration vs. a default (by which I mean = behavior absent of an explicit configuration). For SPI this isn't true (i.= e. you need explicit config) but the point the original text was trying to = make was that, for SI, no explicitly config is needed, although it can be s= upplied. >=20 >=20 >=20 >=20 >> On Sep 14, 2016, at 1:18 PM, Dave Dolson wrote: >>=20 >> Sorry, I see I didn't properly read your concern about "configuration" i= n the first sentence. I guess I don't understand your concern. Surely the = SPI and SI are configured, although SI may default to 255. >>=20 >> -Dave >>=20 >>=20 >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Wednesday, September 14, 2016 1:16 PM >> To: Paul Quinn (paulq) >> Cc: Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>=20 >> Yes, that is good. How do you feel about adding another "configured"? >>=20 >> "The initial classifier MUST set the appropriate SPI and SI values confi= gured for a given classification result. The initial SI configuration SHOU= LD default to 255. However, the classifier MUST allow configuration of othe= r SI values." >>=20 >>=20 >> -----Original Message----- >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 >> Sent: Wednesday, September 14, 2016 12:34 PM >> To: Dave Dolson >> Cc: Jim Guichard (jguichar); sfc@ietf.org >> Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>=20 >> Dave, >>=20 >> Thanks for these suggestions/clarifications, I can see how this might be= misinterpreted. >>=20 >> My concern is with the work "configuration" in the first sentence since = it might imply the need for configuration vs default. So a minor tweak: >>=20 >> "The initial classifier MUST set the appropriate SPI and SI values for a= given classification result. The initial SI configuration SHOULD default = to 255. However, the classifier MUST allow configuration of other SI values= ." >>=20 >> Paul >>=20 >>> On Sep 6, 2016, at 2:21 PM, Dave Dolson wrote: >>>=20 >>> I have a comment on the specification of Service Index (SI). >>> The document says,=20 >>> The initial classifier for a given SFP SHOULD set the SI to 255, howev= er the=09 >>> control plane MAY configure the initial value of SI as appropriate... >>>=20 >>> If you read this literally, it seems to say that the classifier SHOULD = set the initial SI to 255 regardless of what the control plane tells it to = do. >>> It is perhaps implied that the classifier MAY do what the control plane= tells it to, but that's not what the words say. >>>=20 >>> I think wording like this might help: >>> The initial classifier MUST set the SI to the value specified by confi= guration for the classification outcome. The initial SI configuration SHOUL= D default to 255. However, the classifier MUST allow configuration of other= SI values. >>>=20 >>> Similar wording should apply to the SPI; nothing is said about the clas= sifier in the paragraph about SPI. I suggest: >>> The initial classifier MUST set the SPI to the value specified by conf= iguration for the classification outcome.=09 >>>=20 >>> Note, I've said "configuration" instead of "control plane". I'm assumin= g a control plane will do configuration. If you just want to talk about con= trol plane, then there is no need for any default, just "The classifier MUS= T set the SET to the value specified by the control plane for the classific= ation." >>>=20 >>>=20 >>> -Dave >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jgui= char) >>> Sent: Tuesday, August 23, 2016 12:48 PM >>> To: sfc@ietf.org >>> Subject: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >>>=20 >>> Dear WG: >>>=20 >>> Please review this new version of the SFC encapsulation to make sure th= at your comments from the previous WGLC have been addressed.=20 >>>=20 >>> Any comments and/or concerns please post to the mailing list within the= next two weeks so that this work can be progressed. >>>=20 >>> As a heads up, if there are still substantive comments we plan to hold = an interim meeting on September 15th to address any outstanding issues >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Jim, Martin, & Thomas >>>=20 >>>=20 >>>=20 >>>=20 >>> On 8/23/16, 11:47 AM, "sfc on behalf of internet-drafts@ietf.org" wrote: >>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Service Function Chaining of the IETF= . >>>>=20 >>>> Title : Network Service Header >>>> Authors : Paul Quinn >>>> Uri Elzur >>>> Filename : draft-ietf-sfc-nsh-07.txt >>>> Pages : 37 >>>> Date : 2016-08-23 >>>>=20 >>>> Abstract: >>>> This document describes a Network Service Header (NSH) inserted onto >>>> packets or frames to realize service function paths. NSH also >>>> provides a mechanism for metadata exchange along the instantiated >>>> service path. NSH is the SFC encapsulation required to support the >>>> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-07 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of subm= ission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=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 >>>=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 Sep 15 08:12:21 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9512B7E4; Thu, 15 Sep 2016 08:12:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147395233991.26707.10623510675365964226.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 08:12:19 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 15:12:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-08.txt Pages : 37 Date : 2016-09-15 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 15 10:03:09 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7315612B533 for ; Thu, 15 Sep 2016 10:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 y6jU-GUK7bLN for ; Thu, 15 Sep 2016 10:03:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176D212B31E for ; Thu, 15 Sep 2016 09:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1870; q=dns/txt; s=iport; t=1473956982; x=1475166582; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=l//euvMe1rRyXLorLVPEtPLk/WnjWnxb5nsVNn5rcKs=; b=W0s9tfkEqQb7jjgpRm/vlfkt6tHoE255/mRNoLjSNBXoYSO7UR/zy1eK jsUPOQ8kO5FA3IVOFaHRPRCwnUhy58VW+Kya/3PbgQPKZzLDjbKrXRqlF gCm7imrVYYxr7BBV2HI7zEc5ErztwNSUSRbMLr6G2nPt/Tq2kYw1eFk25 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQAkzNpX/5FdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzoBAQEBAR5XfAeNLKsoggMZC4V6AoFcOBQBAgEBAQEBAQFeHAuEYQE?= =?us-ascii?q?BAQMBAQEBNzQQCwIBGQECAQIfECcLFwQCCAIEE4hCCA7BewEBAQEBAQEDAQEBA?= =?us-ascii?q?QEBAQEBHoYxgXmCVodtgi8FlBWFUwGGJIk0gW5OhBSJFYxeg3oBHjaEZ3CGAn8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.30,339,1470700800"; d="scan'208";a="149564229" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2016 16:29:36 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u8FGTaRk024990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Sep 2016 16:29:36 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Sep 2016 11:29:35 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Thu, 15 Sep 2016 11:29:35 -0500 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-nsh-08.txt Thread-Index: AQHSD2P/MURDBZ7xYk2CsN847CBoPA== Date: Thu, 15 Sep 2016 16:29:35 +0000 Message-ID: References: <147395233991.26707.10623510675365964226.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.52] Content-Type: text/plain; charset="us-ascii" Content-ID: <35A699327C6AED4190BC4C6512B4A011@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:03:08 -0000 Dear WG and chairs, This version reflects comments received during last call. Thank you. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-08.txt > Date: September 15, 2016 at 11:12:19 AM EDT > To: > Cc: sfc@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Service Function Chaining of the IETF. >=20 > Title : Network Service Header > Authors : Paul Quinn > Uri Elzur > Filename : draft-ietf-sfc-nsh-08.txt > Pages : 37 > Date : 2016-09-15 >=20 > Abstract: > This document describes a Network Service Header (NSH) inserted onto > packets or frames to realize service function paths. NSH also > provides a mechanism for metadata exchange along the instantiated > service path. NSH is the SFC encapsulation required to support the > Service Function Chaining (SFC) Architecture (defined in RFC7665). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sfc-nsh-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Sep 15 10:24:20 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8DA12B216 for ; Thu, 15 Sep 2016 10:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gGtUl_kJxlVx for ; Thu, 15 Sep 2016 10:24:16 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1EB12B0D4 for ; Thu, 15 Sep 2016 10:24:00 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w11so79627136oia.2 for ; Thu, 15 Sep 2016 10:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=ZhF3SKnlqTv4xgJrZy2RiiI5FnUOAiZLs57ZsDMLvj8=; b=eS7gkpxyfdCUFtHJiM13GRMA8dF7CobpylosMMyfEk7bFkKOxTlgRJDUhwTP539vfA RKgeSCWGcxMYR8Q157g/44IuVCi7R0mF7Qr5XNikj4OHi1YiAFn3cgj9o+h1JApt4q+V FgzQxzb2vteewRVf5ldC38s7WQf5Cq6+GLAdX0YfSJn3a0X3K382RcdDi9YO+JICFGAb dyt/kBa7XCWUjn7UdRRWFMtXjuaPVyPHjFDvZJqwhvr9wnZOKLRPFr4aHeF9Y2n4kwyN 0fw0kr4UjJgzUBlDhpOpN98NGVjv3HE4AlZqbZpB70/7rr3QD4+ZSmh4tnfv+RtrLOPW pKkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ZhF3SKnlqTv4xgJrZy2RiiI5FnUOAiZLs57ZsDMLvj8=; b=bh/IrInq8JVxPpgglrVY5xOTRTn7gLPfoiNZenvKH5uUpkxwAInKgf2yYenq/juNPM VYSFoBsKy1UO59kasgMkcky7wEKyRawjAplGxef+gbwg6Ml+e/tu8P4VsS2LM3H4ae8N ZHoZ2yghIxyaeWEcZ774lmnxSQgeGKP94eGZK1P1XdXgc15y97w7ecvYGJ4rQg49wOPY eDIrlpuKDaewjEOlpNs3f3oAYXYgFw4KveIFcbvYXgj1NJt2Tfofi20YdU4L7f31fnkZ zaGCPT7MO/FsQIokyf3N3hwXLbrliR72OG8LCSNSgAu9uz2yn4ifitapx4KK6rfCCfLb Ubzg== X-Gm-Message-State: AE9vXwM3mu8l1M0t9zaY4gaL74uOAnQ19//68dGyWrvDi8rKJ4Td07EpHWH4yzsa3N3szhQJCFFlbOewSLPdSw== X-Received: by 10.157.34.132 with SMTP id y4mr7602096ota.41.1473960239828; Thu, 15 Sep 2016 10:23:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.247.71 with HTTP; Thu, 15 Sep 2016 10:23:39 -0700 (PDT) From: "Andrew G. Malis" Date: Thu, 15 Sep 2016 13:23:39 -0400 Message-ID: To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=94eb2c04d9c2824a96053c8f1cdb Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] Ignored comments regarding draft-ietf-sfc-nsh-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:24:18 -0000 --94eb2c04d9c2824a96053c8f1cdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, I made several comments on the list regarding draft-ietf-sfc-nsh-07 that were neither responded to nor fixed in draft-ietf-sfc-nsh-08. 1. I noticed an editing error, at the bottom of p. 12 it still discusses three reserved bits in fig. 6, but now there=E2=80=99s only one bit. [Note that this comment now pertains to p.13 of draft-ietf-sfc-nsh-08.] 2. In draft-ietf-sfc-nsh-07, draft-ietf-rtgwg-dt-encap-01 is referenced three times, but is not in the list of references. Also, section 6 of draft-ietf-sfc-nsh-07 specifically references section 6 of draft-ietf-rtgwg-dt-encap-01. I suspect that section 9 is what was actually intended. In any case, section 6 is obviously incorrect. [These comments still pertain to draft-ietf-sfc-nsh-08.] Thanks, Andy --94eb2c04d9c2824a96053c8f1cdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

I made several comments on the li= st regarding=C2=A0draft-ietf-sfc-nsh-07 that were neither responded to nor = fixed in=C2=A0draft-ietf-sfc-nsh-08.

1. I not= iced an editing error, at the bottom of p. 12 it still discusses three rese= rved bits in fig. 6, but now there=E2=80=99s only one bit.

[Note that this comment now pertains to p.13 of draft-ietf-sfc-nsh= -08.]

2. In draft-ietf-sfc-nsh-07, draft-ietf-rtgw= g-dt-encap-01 is referenced three times, but is not in the list of referenc= es.=C2=A0

Also, section 6 of draft-ietf-sfc-nsh-07= specifically references section 6 of draft-ietf-rtgwg-dt-encap-01. I suspe= ct that section 9 is what was actually intended. In any case, section 6 is = obviously incorrect.

[These comments still pertain= to draft-ietf-sfc-nsh-08.]

Thanks,
Andy

--94eb2c04d9c2824a96053c8f1cdb-- From nobody Thu Sep 15 10:34:27 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71C112B167 for ; Thu, 15 Sep 2016 10:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.03 X-Spam-Level: X-Spam-Status: No, score=-16.03 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 UhZrNzKY9Tj2 for ; Thu, 15 Sep 2016 10:34:25 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE43B12B1B2 for ; Thu, 15 Sep 2016 10:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1478; q=dns/txt; s=iport; t=1473960863; x=1475170463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rXU4uB+2FuDphvQUTDebFq4aGC9KExFM7LT4rYQSIZY=; b=N6+5nh9kt2h0zHSYw2O0YjgbE2JDTwTZX/5t2/Yvfr0Cn8DX6JaB40mh +taMXOWprwvOxD2FlSmSjBojy0vnzT0WBeSOHnHKKyl3lqM/D7o8NJk+C 3RNBGgSTFdzKjZnTFXugR9BeHKfcoDORMyBWjUQn5CMcjCD8lRDsOxXOP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAwAh29pX/4sNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzoBAQEBAR6BUwesFow+ggOGHgIcgUA5EwECAQEBAQEBAV4nhGEBAQE?= =?us-ascii?q?DASMRPwYFCwIBCBgCAiYCAgIfERUQAgQOBYgwAw8ItVOJBg2DKQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARyBBoUrgXkIgk6CQ4R/K4IvBZkzNQGMaYJvj2WIT4QPg3o?= =?us-ascii?q?BIAMxhGdwhgJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,340,1470700800"; d="scan'208";a="324136929" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2016 17:34:23 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u8FHYM1h000757 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Sep 2016 17:34:22 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Sep 2016 12:34:22 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Thu, 15 Sep 2016 12:34:21 -0500 From: "Paul Quinn (paulq)" To: "Andrew G. Malis" Thread-Topic: Ignored comments regarding draft-ietf-sfc-nsh-07 Thread-Index: AQHSD3X1rBKRmOqKM0GULDFVH6Vsv6B7I60A Date: Thu, 15 Sep 2016 17:34:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.52] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Ignored comments regarding draft-ietf-sfc-nsh-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:34:27 -0000 VGhhbmsgeW91IGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3LiAgTXkgc2luY2VyZSBhcG9sb2dpZXMs IHRoaXMgaXMgbXkgZmF1bHQsIGFuZCBsaWtlbHkgZHVlIHRvIHNvbWUgbG9jYWwgdmVyc2lvbiB0 cmFja2luZy4gIC0wOSwgdG8gYmUgcG9zdGVkIHNob3J0bHksIHdpbGwgYWRkcmVzcyB0aGVzZS4N Cg0KDQoNClBhdWwNCg0KPiBPbiBTZXAgMTUsIDIwMTYsIGF0IDE6MjMgUE0sIEFuZHJldyBHLiBN YWxpcyA8YWdtYWxpc0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gUGF1bCwNCj4gDQo+IEkgbWFk ZSBzZXZlcmFsIGNvbW1lbnRzIG9uIHRoZSBsaXN0IHJlZ2FyZGluZyBkcmFmdC1pZXRmLXNmYy1u c2gtMDcgdGhhdCB3ZXJlIG5laXRoZXIgcmVzcG9uZGVkIHRvIG5vciBmaXhlZCBpbiBkcmFmdC1p ZXRmLXNmYy1uc2gtMDguDQo+IA0KPiAxLiBJIG5vdGljZWQgYW4gZWRpdGluZyBlcnJvciwgYXQg dGhlIGJvdHRvbSBvZiBwLiAxMiBpdCBzdGlsbCBkaXNjdXNzZXMgdGhyZWUgcmVzZXJ2ZWQgYml0 cyBpbiBmaWcuIDYsIGJ1dCBub3cgdGhlcmXigJlzIG9ubHkgb25lIGJpdC4NCj4gDQo+IFtOb3Rl IHRoYXQgdGhpcyBjb21tZW50IG5vdyBwZXJ0YWlucyB0byBwLjEzIG9mIGRyYWZ0LWlldGYtc2Zj LW5zaC0wOC5dDQo+IA0KPiAyLiBJbiBkcmFmdC1pZXRmLXNmYy1uc2gtMDcsIGRyYWZ0LWlldGYt cnRnd2ctZHQtZW5jYXAtMDEgaXMgcmVmZXJlbmNlZCB0aHJlZSB0aW1lcywgYnV0IGlzIG5vdCBp biB0aGUgbGlzdCBvZiByZWZlcmVuY2VzLiANCj4gDQo+IEFsc28sIHNlY3Rpb24gNiBvZiBkcmFm dC1pZXRmLXNmYy1uc2gtMDcgc3BlY2lmaWNhbGx5IHJlZmVyZW5jZXMgc2VjdGlvbiA2IG9mIGRy YWZ0LWlldGYtcnRnd2ctZHQtZW5jYXAtMDEuIEkgc3VzcGVjdCB0aGF0IHNlY3Rpb24gOSBpcyB3 aGF0IHdhcyBhY3R1YWxseSBpbnRlbmRlZC4gSW4gYW55IGNhc2UsIHNlY3Rpb24gNiBpcyBvYnZp b3VzbHkgaW5jb3JyZWN0Lg0KPiANCj4gW1RoZXNlIGNvbW1lbnRzIHN0aWxsIHBlcnRhaW4gdG8g ZHJhZnQtaWV0Zi1zZmMtbnNoLTA4Ll0NCj4gDQo+IFRoYW5rcywNCj4gQW5keQ0KPiANCg0K From nobody Thu Sep 15 11:05:14 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87C12B304 for ; Thu, 15 Sep 2016 11:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 zOFRI5ruvO_3 for ; Thu, 15 Sep 2016 11:05:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6930812B2F6 for ; Thu, 15 Sep 2016 11:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3942; q=dns/txt; s=iport; t=1473962711; x=1475172311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=36HL37JnzIrdFmijgw6tdildIdbGBCUp/mm+4Zw6mWs=; b=GOJB2CbocBTo2IIMrM1GsL1oyutPzC9umdNYJFN85rgiGnluRZnnQLG2 xZ8GqEeVbTyu8VRU/OhSuxzT7QLHGGOAMkarUE3zyVtB4jsVfyFLyUwlz Fza5M/AKV46ETP2bKd+w8vvp77sJod43cn8IoDs7qEuMONAx0Eqyr9RXP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQBJ4tpX/4wNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzoBAQEBAR5XfAeNLKsoggMZC4V6AhyBQDgUAQIBAQEBAQEBXhwLhGE?= =?us-ascii?q?BAQEDAQEBASAEDToLBQsCAQYCEgYCAiYCAgIlCxUCDgIEDgWIQggOmDadJIw8A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHIEGhSuBeYJWhEAXgmsrgi8BBJloAYYkiTS?= =?us-ascii?q?Bbk6EFIkVjF6DegEeNoRncIYCfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,340,1470700800"; d="scan'208";a="323254473" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2016 18:05:10 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u8FI5AEx030552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Sep 2016 18:05:10 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Sep 2016 13:05:09 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Thu, 15 Sep 2016 13:05:09 -0500 From: "Paul Quinn (paulq)" To: "wang.cui1@zte.com.cn" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-nsh-07.txt Thread-Index: AQHSA2BaLr5YNm3VJke9w8FRNsXXxaB7RHWA Date: Thu, 15 Sep 2016 18:05:09 +0000 Message-ID: References: <147196725260.30794.10266895117462060916.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.118.52] Content-Type: text/plain; charset="utf-8" Content-ID: <1C4AECC56A20F74BB4D912B561C9B175@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 18:05:13 -0000 TGluZGEsDQoNClRoaXMgZXhhbXBsZSBpcyBzaW1wbHkgbWVhbnQgdG8gYmUgaWxsdXN0cmF0aXZl LiAgVGhlIGV4YWN0IG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0IGxvYWQgYmFsYW5jaW5nIGlzIGRl cGVuZGVudCBvbiB0aGUgaW1wbGVtZW50ZXIgYW5kIHRoZSB0cmFuc3BvcnQsIHRoZSBOU0ggZHJh ZnQgaXMgbm90IHByZXNjcmlwdGl2ZSBpbiB0aGlzIGFyZWEgdG8gYXZvaWQgY29uZnVzaW9uIGFu ZCBwZXIgdHJhbnNwb3J0IGRpc2N1c3Npb24uDQoNClRoYW5rIHlvdSwNClBhdWwNCg0KPiBPbiBB dWcgMzEsIDIwMTYsIGF0IDQ6MTkgQU0sIHdhbmcuY3VpMUB6dGUuY29tLmNuIHdyb3RlOg0KPiAN Cj4gSGkgZWRpdG9ycywgDQo+IA0KPiAgSSBoYXZlIGEgY2xhcmlmaWNhdGlvbiBjb21tZW50IGFi b3V0IHRoZSBmb2xsb3dpbmcgdGV4dDogDQo+IA0KPiAgICAgU2VjdGlvbiA3LjIgTWFwcGluZyBO U0ggdG8gTmV0d29yayBUcmFuc3BvcnQgDQo+ICAgICAuLi4uLi4gDQo+ICAgICAyLiBOZXh0IFNG IGlzIGxvY2F0ZWQgYXQgU0ZGYyB3aXRoIG11bHRpcGxlIG5ldHdvcmsgbG9jYXRvcnMgZm9yIGxv YWQgZGlzdHJpYnV0aW9uIHB1cnBvc2VzOiANCj4gICAgICAgICBTRkZiIG1hcHBpbmc6IFNQST0x MCAtLT4gVlhMQU4tZ3BlLCBkc3RfaXA6MjAzLjAuMTEzLjEsMjAzLjAuMTEzLjIsMjAzLjAuMTEz LjMsIGVxdWFsIGNvc3QgDQo+IA0KPiBDb3VsZCB5b3UgYWRkIHNvbWUgdGV4dCBvciBhZGQgYSBm aWd1cmUgdG8gaWxsdXN0cmF0ZSB0aGlzIGV4YW1wbGUgY2xlYXJseSA/IEl0IHNlZW0ga2luZCBv ZiBjb25mdXNpbmcgaG93IGEgU0ZGYyBoYXMgbXVsdGlwbGUgbmV0d29yayBsb2NhdG9ycyBmb3Ig TEIuIA0KPiANCj4gVGhhbmtzLCANCj4gDQo+IEJScywgDQo+IExpbmRhIFdhbmcgDQo+ICAgDQo+ ICJzZmMiIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIwMTYvMDgvMjMgMjM6NDc6MzI6 DQo+IA0KPiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCj4gPiDlj5Hku7bkuro6ICAic2Zj IiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+DQo+ID4gDQo+ID4gMjAxNi8wOC8yMyAyMzo0NyANCj4g PiANCj4gPiDmlLbku7bkurogDQo+ID4gDQo+ID4gPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4sIA0K PiA+IA0KPiA+IOaKhOmAgSANCj4gPiANCj4gPiBzZmNAaWV0Zi5vcmcgDQo+ID4gDQo+ID4g5Li7 6aKYIA0KPiA+IA0KPiA+IFtzZmNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNy50 eHQgDQo+ID4gDQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZy b20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPiA+IGRpcmVjdG9yaWVzLg0KPiA+IFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcg b2YgdGhlIElFVEYuDQo+ID4gDQo+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBOZXR3b3Jr IFNlcnZpY2UgSGVhZGVyDQo+ID4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBQYXVsIFF1aW5u DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBVcmkgRWx6dXINCj4gPiAgICBGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLXNmYy1uc2gtMDcudHh0DQo+ID4gICAgUGFnZXMgICAgICAg ICAgIDogMzcNCj4gPiAgICBEYXRlICAgICAgICAgICAgOiAyMDE2LTA4LTIzDQo+ID4gDQo+ID4g QWJzdHJhY3Q6DQo+ID4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBOZXR3b3JrIFNlcnZp Y2UgSGVhZGVyIChOU0gpIGluc2VydGVkIG9udG8NCj4gPiAgICBwYWNrZXRzIG9yIGZyYW1lcyB0 byByZWFsaXplIHNlcnZpY2UgZnVuY3Rpb24gcGF0aHMuICBOU0ggYWxzbw0KPiA+ICAgIHByb3Zp ZGVzIGEgbWVjaGFuaXNtIGZvciBtZXRhZGF0YSBleGNoYW5nZSBhbG9uZyB0aGUgaW5zdGFudGlh dGVkDQo+ID4gICAgc2VydmljZSBwYXRoLiAgTlNIIGlzIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBy ZXF1aXJlZCB0byBzdXBwb3J0IHRoZQ0KPiA+ICAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcg KFNGQykgQXJjaGl0ZWN0dXJlIChkZWZpbmVkIGluIFJGQzc2NjUpLg0KPiA+IA0KPiA+IA0KPiA+ IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC8NCj4g PiANCj4gPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4g PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtbnNoLTA3DQo+ID4g DQo+ID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1uc2gt MDcNCj4gPiANCj4gPiANCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cj4gPiANCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPiAN Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IHNmYyBtYWlsaW5nIGxpc3QNCj4gPiBzZmNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Thu Sep 15 17:17:36 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 298DA12B098; Thu, 15 Sep 2016 17:17:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147398505416.946.2203904469084071298.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 17:17:34 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-09.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 00:17:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-09.txt Pages : 37 Date : 2016-09-15 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 16 02:57:18 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F130A12B11B for ; Fri, 16 Sep 2016 02:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=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 i85ajE2_WLdS for ; Fri, 16 Sep 2016 02:57:13 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914F412B203 for ; Fri, 16 Sep 2016 02:57:12 -0700 (PDT) Received: from [192.168.0.102] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 1AEAB18015A1; Fri, 16 Sep 2016 11:57:10 +0200 (CEST) To: "Paul Quinn (paulq)" References: <147196725260.30794.10266895117462060916.idtracker@ietfa.amsl.com> From: Loa Andersson Message-ID: <19292012-0f19-988e-0387-c10401a82700@pi.nu> Date: Fri, 16 Sep 2016 11:57:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Elzur, Uri" , "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 09:57:17 -0000 Paul, I think this document is coming along quite nicely, one question though. The document say: 3.5.1. Optional Variable Length Metadata The format of the optional variable length context headers, is as described below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class |C| Type |R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Do I understand you correctly if I say that the "Variable Length TLV", starts from bit 16 in the "Optional Variable Length Metadata" and the reason that you want to define that TLV is that anyone that specifies "Variable Length Metadata Class" needds to define at least one "Variable Length TLV"? /Loa On 2016-09-15 20:05, Paul Quinn (paulq) wrote: > Linda, > > This example is simply meant to be illustrative. The exact mechanism for transport load balancing is dependent on the implementer and the transport, the NSH draft is not prescriptive in this area to avoid confusion and per transport discussion. > > Thank you, > Paul > >> On Aug 31, 2016, at 4:19 AM, wang.cui1@zte.com.cn wrote: >> >> Hi editors, >> >> I have a clarification comment about the following text: >> >> Section 7.2 Mapping NSH to Network Transport >> ...... >> 2. Next SF is located at SFFc with multiple network locators for load distribution purposes: >> SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1,203.0.113.2,203.0.113.3, equal cost >> >> Could you add some text or add a figure to illustrate this example clearly ? It seem kind of confusing how a SFFc has multiple network locators for LB. >> >> Thanks, >> >> BRs, >> Linda Wang >> >> "sfc" 写于 2016/08/23 23:47:32: >> >>> internet-drafts@ietf.org >>> 发件人: "sfc" >>> >>> 2016/08/23 23:47 >>> >>> 收件人 >>> >>> , >>> >>> 抄送 >>> >>> sfc@ietf.org >>> >>> 主题 >>> >>> [sfc] I-D Action: draft-ietf-sfc-nsh-07.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Service Function Chaining of the IETF. >>> >>> Title : Network Service Header >>> Authors : Paul Quinn >>> Uri Elzur >>> Filename : draft-ietf-sfc-nsh-07.txt >>> Pages : 37 >>> Date : 2016-08-23 >>> >>> Abstract: >>> This document describes a Network Service Header (NSH) inserted onto >>> packets or frames to realize service function paths. NSH also >>> provides a mechanism for metadata exchange along the instantiated >>> service path. NSH is the SFC encapsulation required to support the >>> Service Function Chaining (SFC) Architecture (defined in RFC7665). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-sfc-nsh-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Sep 16 05:58:58 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BFE12B0A9 for ; Fri, 16 Sep 2016 05:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o90CsghM5aI9 for ; Fri, 16 Sep 2016 05:58:54 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 A8C0D12B0E9 for ; Fri, 16 Sep 2016 05:58:53 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id r126so110478504oib.0 for ; Fri, 16 Sep 2016 05:58: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:from:date:message-id:subject:to :cc; bh=yBZRlU6p/f8w8Tvwg2cFBEzqnd4/Sc7IPKHsruJHHn4=; b=C68HgpRORcHxZflaTjwe7wsH2Y8mmrrNP5nAb4B4AsxgrctXeIIA0uVNGrVtkRlVS4 fLcXr7K3eqMu7u+o855xqItH87d4DiC/KbNz9Gt9uK566ELEJqPBhe39McxRyfX/plap RHSE8dL4g9XDI0eZimc4/EVr5B/+ITzp6r4DUPuBoPT1sNY9tCwNyaOwu04lDkl3PdEB NmG4El519f7NHq/B/71jji5WDsuRzEgGvFs60rOvtEo9p3ZlyZc1TlD7cBDA6rO+ArvM aZ4CH0cMG3kL0UgoCCEHZRTu45/ve9TplXXpF1RkvquD0yeaO6aoHewavoLz81tVf9Zf 9Qpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yBZRlU6p/f8w8Tvwg2cFBEzqnd4/Sc7IPKHsruJHHn4=; b=kj/3gsOxLX2JaS6RELs7t84Z4zfVhw9qf6Vi7sjd6W3tgX6CgvBuGgxi5fzr99htWR +cz42VBSyb1SopUi7ciOVXBSkWvYePOGoed7vY1XA8Rp3T3R1mKrEY1in5ApjpDXnzgY qskanbulGmjq9X/nPnWLopH0uxiVIJ4C1X4I42fM40H+OL1zeKBpGa/tlX9haoXV29HG 6wXEaiGD6Sq+joibHuCbcT7dvdaBpKhYcjJWH9LWhw9KIAQy3yswGxOgq1AVK7JraA5Z w8XSnWl2vLLesNp1BkUarIFwiA+MTwRkn0hKuFc6gpDuxwq9x4x/1ryOIrG/SzlXxuox 8mdw== X-Gm-Message-State: AE9vXwNZWtBPB8uRM5h2yU2RAmNvWc5R7C0Fi9KW6F5M6jHLq8HV49PWS4ovqI3nDbpq8iV1QbsMxSH2bfmFaw== X-Received: by 10.202.188.134 with SMTP id m128mr14068906oif.41.1474030733033; Fri, 16 Sep 2016 05:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.247.71 with HTTP; Fri, 16 Sep 2016 05:58:32 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 16 Sep 2016 08:58:32 -0400 Message-ID: To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=001a113dcc823b0683053c9f86ed Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Ignored comments regarding draft-ietf-sfc-nsh-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 12:58:56 -0000 --001a113dcc823b0683053c9f86ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, I=E2=80=99m just looking at -09. Thanks for incorporating my comments, howe= ver on p. 13 you fixed the the reserved bit in the first instance but left =E2=80= =9Cbits=E2=80=9D on the next line: Reserved bit: one reserved bit is present for future use. The reserved bits MUST be set to 0x0. You can mark removing the extra =E2=80=9Cs=E2=80=9D for your next update. Cheers, Andy On Thu, Sep 15, 2016 at 1:34 PM, Paul Quinn (paulq) wrote= : > Thank you for your careful review. My sincere apologies, this is my > fault, and likely due to some local version tracking. -09, to be posted > shortly, will address these. > > > > Paul > > > On Sep 15, 2016, at 1:23 PM, Andrew G. Malis wrote: > > > > Paul, > > > > I made several comments on the list regarding draft-ietf-sfc-nsh-07 tha= t > were neither responded to nor fixed in draft-ietf-sfc-nsh-08. > > > > 1. I noticed an editing error, at the bottom of p. 12 it still discusse= s > three reserved bits in fig. 6, but now there=E2=80=99s only one bit. > > > > [Note that this comment now pertains to p.13 of draft-ietf-sfc-nsh-08.] > > > > 2. In draft-ietf-sfc-nsh-07, draft-ietf-rtgwg-dt-encap-01 is referenced > three times, but is not in the list of references. > > > > Also, section 6 of draft-ietf-sfc-nsh-07 specifically references sectio= n > 6 of draft-ietf-rtgwg-dt-encap-01. I suspect that section 9 is what was > actually intended. In any case, section 6 is obviously incorrect. > > > > [These comments still pertain to draft-ietf-sfc-nsh-08.] > > > > Thanks, > > Andy > > > > --001a113dcc823b0683053c9f86ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

I=E2=80=99m just looking at -09. = Thanks for incorporating my comments, however on p. 13 you fixed the the re= served bit in the first instance but left =E2=80=9Cbits=E2=80=9D on the nex= t line:

   Reserved bit: on=
e reserved bit is present for future use.  The
   reserved bits MUST be set to 0x0.

You can mark removing the extra =E2=80=9Cs= =E2=80=9D for your next update.

Cheers,
= Andy





On Thu, Sep 15, = 2016 at 1:34 PM, Paul Quinn (paulq) <paulq@cisco.com> wrote:
Thank you for your careful review.=C2=A0 M= y sincere apologies, this is my fault, and likely due to some local version= tracking.=C2=A0 -09, to be posted shortly, will address these.



Paul

> On Sep 15, 2016, at 1:23 PM, Andrew G. Malis <agmalis@gmail.com> wrote:
>
> Paul,
>
> I made several comments on the list regarding draft-ietf-sfc-nsh-07 th= at were neither responded to nor fixed in draft-ietf-sfc-nsh-08.
>
> 1. I noticed an editing error, at the bottom of p. 12 it still discuss= es three reserved bits in fig. 6, but now there=E2=80=99s only one bit.
>
> [Note that this comment now pertains to p.13 of draft-ietf-sfc-nsh-08.= ]
>
> 2. In draft-ietf-sfc-nsh-07, draft-ietf-rtgwg-dt-encap-01 is reference= d three times, but is not in the list of references.
>
> Also, section 6 of draft-ietf-sfc-nsh-07 specifically references secti= on 6 of draft-ietf-rtgwg-dt-encap-01. I suspect that section 9 is what was = actually intended. In any case, section 6 is obviously incorrect.
>
> [These comments still pertain to draft-ietf-sfc-nsh-08.]
>
> Thanks,
> Andy
>


--001a113dcc823b0683053c9f86ed-- From nobody Tue Sep 20 11:07:13 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ED212B429; Tue, 20 Sep 2016 11:07:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147439482758.29089.9062545558400328675.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 11:07:07 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-10.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 18:07:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining of the IETF. Title : Network Service Header Authors : Paul Quinn Uri Elzur Filename : draft-ietf-sfc-nsh-10.txt Pages : 37 Date : 2016-09-20 Abstract: This document describes a Network Service Header (NSH) inserted onto packets or frames to realize service function paths. NSH also provides a mechanism for metadata exchange along the instantiated service path. NSH is the SFC encapsulation required to support the Service Function Chaining (SFC) Architecture (defined in RFC7665). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 21 08:18:41 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4012B4BB; Wed, 21 Sep 2016 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=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 xr45X8wXh-HP; Wed, 21 Sep 2016 08:18:33 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0114.outbound.protection.outlook.com [104.47.0.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775FA12B4CE; Wed, 21 Sep 2016 08:18:29 -0700 (PDT) Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com (10.168.57.26) by DB6PR0601MB2165.eurprd06.prod.outlook.com (10.168.57.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Wed, 21 Sep 2016 15:18:25 +0000 Received: from DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) by DB6PR0601MB2167.eurprd06.prod.outlook.com ([10.168.57.26]) with mapi id 15.01.0629.006; Wed, 21 Sep 2016 15:18:25 +0000 From: "Diego R. Lopez" To: "Sashank Dara (sadara)" Thread-Topic: [sfc] Question regarding Proof of Transit draft Thread-Index: AdHhBQ917gU76/XQTH2CT3yKdzjXlwADHvuwAABxXIAAI5PugAAI5TEAAAaOeYAAFZJgUP//aoIAgACsjACAAN3cAIABtddwgANl9tCABdCDgIAu5HmAgAomooCAHt8CgA== Date: Wed, 21 Sep 2016 15:18:25 +0000 Message-ID: <2CF6090E-89DE-4823-89D7-A0867DC92A8A@telefonica.com> References: <859929d79ea24e1b9df0f3cdccd66d31@IL-EXCH02.marvell.com> <0cae48f5873c48dc8f5cd17e22a3e032@XCH-RCD-008.cisco.com> <32e24976a2974b5bac63f39eec6bfe18@IL-EXCH02.marvell.com> <36c193705f0a4443b57ac984ed29161e@IL-EXCH02.marvell.com> <30883664facc48a5b1c4030c8ee9c81e@IL-EXCH02.marvell.com> <99c4c8222952442f9a8c99713cbbbffe@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.238.226.2] x-ms-office365-filtering-correlation-id: 29364f4c-f3e3-4abc-fe59-08d3e2328846 x-microsoft-exchange-diagnostics: 1; DB6PR0601MB2165; 6:AGb/DPJiJUkbQdVvMcIAhyc+p1EtEJJfY3YT3AUnKUi8OaV4Xb1FWnt70WA97pNeEByTFhqbbJiLFBr6ff6XR1YB1RvT3pRXdRnW3VXunWVYO3YAN+NN0T1A9tbnPJ3YxK3CMuTUbsj8W9OPkx1qv09fcZRL9J5CiMzvq+szX2GB56/ukB3X8zjhIdJMiq105I/0Eu8gtRapU/ie3y0pM95hmlJlLMKvp7+jAqaxdus9tQr7yrYTL+DVrBdZL8HTgcQ/N6mk/PYIkuPrrJYl3CoV8qYv1uLKFilftds9kXRX3TbgisuxpqBpgGIdT287b67x82MHyBSQrgaVuy0byw==; 5:j/T/3tUbw7JmaPi9LMbAja1iU/DExwEQroJpYqQfxWy860bIB6NO4qnxl/a58PtD36VRSG//QPdZKumDubSFXDrVKe3SSVlJ9XdfhAA9a22UZhj3Yf/h3Sh4HwDUiCYp0Kjc1uhrqa7/ZGZ0I305hA==; 24:n0ycKtTBo9WCbSi7SnoNeKLOGvY7kmZ7L3oR4ncjen+MZdX/xAYT2xFoyk2584ZmHqgMMJBFYp7BekXKzTIGiVlYLQ+Zlyr1yXk8ndfnlJM=; 7:RKvXgMw/r11te1dBIH+n18IOqcRBP0ebSjmY2k+CV9+NjooDpKS8GlsInhSPiydIUbLWlQ5BwoPtDYq7+dbOm9rsXkq7ihkxX2T+LGJLzCPWxr9Yp+rIRlAxagiL+9EyrscKvrXm+6exz7atTdX2ZmwWT5Y5BlPoYrSAJ8Bymvq1QFi6Mg9Pre14DpTEbEBGp2Q3N+gXegswJBsoZy1I6Fm/1tcGy3W6nnmk0Z+XQV094RsasEpkhbQKe8VLJXzqptRuyXWMUm0BjVjnGD1YEBwLwIfVszlbO8XZbCVCBDvrIDHxz+XWHYIOcVv3Arww x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB6PR0601MB2165; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(40392960112811)(278428928389397)(192374486261705)(788757137089)(95692535739014)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB6PR0601MB2165; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0601MB2165; x-forefront-prvs: 007271867D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(40134004)(377454003)(189002)(51914003)(25724002)(199003)(252514010)(11100500001)(3846002)(5002640100001)(189998001)(345774005)(19580395003)(92566002)(68736007)(82746002)(19580405001)(66066001)(36756003)(3660700001)(93886004)(10400500002)(87936001)(83716003)(3900700001)(2950100001)(77096005)(2900100001)(3280700002)(15975445007)(554214002)(54356999)(561944003)(101416001)(81166006)(50986999)(122556002)(110136003)(586003)(5660300001)(8676002)(102836003)(19617315012)(76176999)(6116002)(16236675004)(105586002)(33656002)(4326007)(86362001)(7906003)(5890100001)(7846002)(2906002)(7736002)(81156014)(97736004)(106356001)(8936002)(104396002)(579004)(559001)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0601MB2165; H:DB6PR0601MB2167.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2CF6090E89DE482389D7A0867DC92A8Atelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2016 15:18:25.1417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0601MB2165 Archived-At: Cc: Tal Mizrahi , "sfc@ietf.org" , "nvo3@ietf.org" , "Frank Brockners \(fbrockne\)" , "draft-brockners-proof-of-transit@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [sfc] Question regarding Proof of Transit draft X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 15:18:40 -0000 --_000_2CF6090E89DE482389D7A0867DC92A8Atelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sashank, (coming back to this as soon as my holidays and the backlog they caused all= ow me) Thanks! I must confess I attended Frank=92s presentation and went directly = to my interpretation of Shamir=92s polynomials, overlooking some of the opt= imizations you propose. And coming back to what Frank asked a couple of mes= sages before in the thread I fully agree it is worthwhile to pursue this in= SFC. I can think of applications in NFV-space, and in the scenario of the = hierarchical SFC some of us are proposing. In fact, I=92ve been discussing = this with other colleagues at the ETSI NFV meeting I am attending now. Be goode, On 1 Sep 2016, at 15:22 , Sashank Dara (sadara) > wrote: Hi Diego , Thanks for bringing up an excellent point on the computational complexity. Fortunately the algorithm takes a cumulative approach which is agnostic of = the path length. 1. Controller performs few trivial steps like choosing long term secrets= , calculating the LPC values for each node and provisioning. 2. Each node only performs 2 additions, 1 multiplication and 1 mod(prime= ) operation per packet . 3. Verifier also performs step (2) and additionally performs 1 addition,= 1 mod(prime) and comparison to verify ! The above steps hold good for any length of nodes. A detailed example is provided for illustrative purposes in our draft (s= ection 3.3) that explains above operations. Would be happy to discuss more on the above, if needed. Regards, Sashank From: "Diego R. Lopez" > Date: Friday, 26 August 2016 at 6:21 PM To: "Frank Brockners (fbrockne)" > Cc: Tal Mizrahi >, sashank dara= >, "draft-brockners-proof-of-tra= nsit@tools.ietf.org= " >, "opsawg@ietf.org"= >, "nvo3@ietf.org" >, "sfc@ietf.org" > Subject: Re: [sfc] Question regarding Proof of Transit draft Hi Frank, This is a really interesting piece of work, and I must say we have been dis= cussing the PoT issue with some customers (though we used to call it =93ass= ured path traversal=94) and we have been exploring possible solutions, tryi= ng to combine good-enough security with a reasonable amount of computationa= l complexity, and I am glad to see a practical proposal addressing this pro= blem. I had a brief conversation with Carlos while in Berlin, but I am afra= id that the IETF week was too hectic for a detailed discussion. Let me add to Tal=92s analysis a third issue to consider. My understanding = of Shamir=92s polynomials is that they can be used to reconstruct a secret = from N pieces you need a polynomial of degree N-1, so that implies that the= verification is limited to a certain number of SFs (or SFFs), depending on= the degree of the applied polynomial. We=92d need and assessment on the co= mputational complexity associated with path length and the requirements for= adaptation of the PoT nodes (I guess SDN/NFV could play a role there=85) Be goode, On 20 Jul 2016, at 09:16 , Frank Brockners (fbrockne) > wrote: Hi Tal, well... if you could protect the integrity of the data stream between sourc= e and destination, you would not be able to swap the content of a packet = =96 which is what your attack is all about. Rather than continue arguing th= e point, let=92s acknowledge that it is a valid attack and let=92s look for= a solution :-). We=92ll need to couple POT to integrity protection of the = packet. Hence, I=92d like to come back to my question asked below: Do you (and the entire SFC team here) think it is worthwhile to provide a s= olution for a deployment which is expected to *not* alter the packet payloa= d? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 18:15 To: Frank Brockners (fbrockne) >; Sashank Dara (sadara) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Frank, The POT replacement attack (1.) is not an attack on the integrity. It is an= attack on the path verification. This simple attack can cause the verifier to accept a packet that did not g= o through the firewall SF (even though it should). I believe this is exactl= y the problem you were aiming to address in this draft. Thanks, Tal. From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] Sent: Tuesday, July 19, 2016 6:00 PM To: Tal Mizrahi; Sashank Dara (sadara); draft-brockners-proof-of-transit@to= ols.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi Tal, thanks for the summary. We=92ll provide more details on 2. Per my earlier p= oint =96 1. is an interesting discussion, given that we don=92t claim to pr= ovide integrity protection for the packet payload. Or in other terms =96 to= be exact: What POT provides is a proof that the POT-header/meta-data trans= ited all the required nodes. There is no association (and thus proof) provi= ded for the additional data carried along with the POT-header =96 neither h= eader nor payload. As a consequence, attacks which change the packet payloa= d won=92t be detected/mitigated. We=92ll explicitly state this in the secur= ity considerations in the next rev of the document. What we could consider is linking the RND number to CRC across the packet p= ayload or similar =96 but that way we=92d restrict the applicability to dep= loyments where the packet payload isn=92t changed across the path (which mi= ght not apply to certain deployment =96 e.g. WAN optimization / compression= schemes). Do you think it is worthwhile to provide a solution for a deployment which = is expected to not alter the packet payload? Thanks, Frank From: Tal Mizrahi [mailto:talmi@marvell.com] Sent: Dienstag, 19. Juli 2016 17:44 To: Sashank Dara (sadara) >; Fran= k Brockners (fbrockne) >; dra= ft-brockners-proof-of-transit@tools.ietf.org Cc: sfc@ietf.org; opsawg@ietf.org; nvo3@ietf.org Subject: RE: Question regarding Proof of Transit draft Hi, To summarize my take on this thread: The proposed mechanism has two significant vulnerabilities that (in my unde= rstanding) are currently not addressed: 1. A man-in-the-middle can replace the POT of packet A with the POT o= f packet B. 2. It is possible to replay POTs within a certain time window, whose = length is determined by the timestamp resolution. Sashank, thanks for agreeing to look into it further. I am looking forward = to your insights on this. Regards, Tal. Link to the draft: https://tools.ietf.org/html/draft-brockners-proof-of-tra= nsit-01 From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 12:20 PM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? [SD] If the verifier is programmed to just validate the POT meta data again= st {1,3,5,6} then yes it accepts it. If the verifier is programmed to consult a policy database to cross check i= f the reconstructed path {1,3,5,6} is as per the policies then no , it drop= s it . But I see your point , that the parameters used in POT data donot consider = the path or node-ids etc . We shall discuss this internally and get back. Also, We shall get back with more concrete numbers of the timestamp resolut= ion and cache sizes (or other better approaches). Thank you so much for all the inputs. From: Tal Mizrahi Sent: Tuesday, July 19, 2016 10:28 AM To: 'Sashank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-pr= oof-of-transit@tools.ietf.org; sfc@ietf.org Subject: RE: Question regarding Proof of Transit draft Dear Sashank, I really appreciate the quick and detailed responses. >>>Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes= . >>>Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). >>> >>>If the attacker could take values from Path1 and reattach them to Path2 = , >>>the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2= ,3,6). >>>This could be compared with topology/policy db information for any polic= y >>>violations. POT does not enforce a particular path to be taken. >>So packet B skipped node 5 (e.g. the firewall SF), but the verifier belie= ves it went through the correct path. >>Would you agree? >[SD] The verifier only constructs the path the packet took accurately, it = is upto >the application to determine whether it violates any policies (I.e missing= any function) >The bottom line is , an attacker taking a different path cannot get away w= ith it ! >The whole intent of =93proof-of-transit=94 is to prove the path packet has= taken exactly. >POT does not define whether it good/bad path. It is upto high level applic= ations on what >do with =93reconstructed=94 path. I want to ask a simple question: If the attacker attaches the POT of packet A (indicating the path through 1= ,3,5,6) to packet B, will the verifier accept packet B and believe that its= path was indeed (1,3,5,6)? >>Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rou= ghly >>1 million packets per second. That would mean the verifier has to store a= million values of RND-2. >>Moreover, every time a packet arrives, the verifier would have to compare= its >>RND-2 value with the 1 million stored values, in order to verify there is= no replay. >>That does not sound feasible. >>Am I missing something here? >[SD] Second level precision is only an example, we could use as much preci= sion as we want to reduce the number of values to be cached ! My point is that assuming reasonable resources are used, the mechanism is v= ulnerable to a replay attack. In order to prove me wrong, can you present concrete numbers of the timesta= mp resolution and the cache size? Otherwise, you may consider using a sequence number + sliding window (e.g.,= as in IPsec). Thanks, Tal. From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 9:56 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft >[SD] Ok. This is an interesting attack. > >Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. >Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). > >If the attacker could take values from Path1 and reattach them to Path2 , >the reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3= ,6). >This could be compared with topology/policy db information for any policy >violations. POT does not enforce a particular path to be taken. So packet B skipped node 5 (e.g. the firewall SF), but the verifier believe= s it went through the correct path. Would you agree? [SD] The verifier only constructs the path the packet took accurately, it i= s upto the application to determine whether it violates any policies (I.e m= issing any function) The bottom line is , an attacker taking a different path cannot get away wi= th it ! The whole intent of =93proof-of-transit=94 is to prove the path pac= ket has taken exactly. POT does not define whether it good/bad path. It is upto high level applica= tions on what do with =93reconstructed=94 path. Hmmm=85 Let=92s say we are talking about traffic at 10 Gbps, which is rough= ly 1 million packets per second. That would mean the verifier has to store = a million values of RND-2. Moreover, every time a packet arrives, the verifier would have to compare i= ts RND-2 value with the 1 million stored values, in order to verify there i= s no replay. That does not sound feasible. Am I missing something here? [SD] Second level precision is only an example, we could use as much precis= ion as we want to reduce the number of values to be cached ! Sashank From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 8:33 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Inline .. We have two consecutive packets, A and B: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. Now the attacker performs a =91mix and match=92 attack, by taking the corr= ect POT from packet A and attaching it to packet B. The attacker also terminates packet A. There is no replay here, because the verifier receives the correct POT only= once. The problem is that the correct POT happens to arrive with packet B.= :( Thus, packet B appears okay to the verifier, even though it did not go thro= ugh the correct path. Is there a way to mitigate this attack? [SD] Ok. This is an interesting attack. Lets take correct path taken by Packet A to be Path1 - ( 1,3,5,6) nodes. Lets assume incorrect path to be Packet B i.e. Path2 - (1,2,3,6). If the attacker could take values from Path1 and reattach them to Path2 , t= he reconstruction for PacketB would result in (1,3,5,6) instead of (1,2,3,6= ). This could be compared with topology/policy db information for any policy v= iolations. POT does not enforce a particular path to be taken. It just reconstructs the particular path taken by the packets. Do you mean that there is a one-second-vulnerability for replay attacks? One second is practically forever. [SD] Not really , the verifier could cache the RND-2 numbers used in the ti= me slice of one second and flush off after every second. There is no one-se= cond-vulnerability as such, if the verifier caches those values. Effective replay prevention is typically performed using a sequence number,= with a sliding window to allow out-of-order packets. Wouldn=92t it be poss= ible to incorporate such a sequence number into your mechanism? [SD] Time stamp is essentially at high level sequence number (at seconds le= vel)! The challenge with using complete RND-2 as sequence number is that th= e differential analysis of CML values (across packets) becomes very easy a= nd predictable. that=92s reason we recommend using ( Timestamp(/ sequence number) + RND ) From: Sashank Dara (sadara) [mailto:sadara@cisco.com] Sent: Tuesday, July 19, 2016 1:11 AM To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-trans= it@tools.ietf.org; = sfc@ietf.org Subject: Re: Question regarding Proof of Transit draft Dear Tal, Thank you for your interest in our work. More inline with [SD] .. Right, I am referring to the former. The integrity check is not the issue. Let=92s say we have: - Packet A that went through the correct path and has a correct POT. - Packet B that did not go through the correct path and does not have a cor= rect POT. The attacker can =91launder=92 packet B by replacing the (incorrect) POT of= packet B with the correct POT of packet A (and drop packet A). Thus, packet B is verified correctly, even though it did not go through the= correct path. [SD] This is valid scenario and we have certain in-built mitigation techniq= ues and recommendations for the same. There are two scenarios here Partial Replay of POT data (Replaying intermediate CMLs) Attacker cannot reuse few intermediate node=92s POT values (from older pack= et traces) as it would disrupt the POLY-3 construction. On the other hand if the attacker tries to replay entire sequence of CML va= lues, he cannot still , because notice that verifier also has a secret shar= e of RND-1 and participates in the reconstruction of RND-3. Verifier=92s share of RND-3 is never on wire , so attacker cannot just obse= rve the packet traces to reuse and replay it. Total Replay of POT data (Replaying complete RND-2) Another trick, attacker could do is by completely reusing RND-2 (but not in= termediate CML values) In order to prevent the =93Reply Attacks=94 , we recommend that the RND-2 (= generated per packet) be a combination (I.e. RND2 =3D =93Time Stamp + RND n= umber=94) So in case a passive attacker tries to replay one of the correct but older = RND-2, the verifier first could check the current timestamp against the tim= estamp retrieved from RND-2. If the retrieved timestamp is older than current timestamp we drop/raise a = flag ! There is still a small window , where the attacker could replay it within t= he valid time slice itself but by carefully choosing the time slice we can = make it nearly impossible for the attacker to replay. For example , if the Time Stamp chosen is 32 bits , we could get one second= s level precision in the time window . So it is highly impossible for the a= ttacker to replay within such a small time at such a high packet rates. Also , the verifier could cache, if needed, certain number of previously us= ed RND-2 to mitigate replay attacks. Hope this clarifies. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- --_000_2CF6090E89DE482389D7A0867DC92A8Atelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <61EA7CB7DC031F43945BC55FBEC7BBCD@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Sashank,

(coming back to this as soon as my holidays and the backlog= they caused allow me)

Thanks! I must confess I attended Frank=92s presentation and went dire= ctly to my interpretation of Shamir=92s polynomials, overlooking some of th= e optimizations you propose. And coming back to what Frank asked a couple o= f messages before in the thread I fully agree it is worthwhile to pursue this in SFC. I can think of applications = in NFV-space, and in the scenario of the hierarchical SFC some of us are pr= oposing. In fact, I=92ve been discussing this with other colleagues at the = ETSI NFV meeting I am attending now.

Be goode,


On 1 Sep 2016, at 15:22 , Sashank Dara (sadara) <sadara@cisco.com> wrote:
Hi Diego , 

Thanks for bringing up an excellent point on the computatio= nal complexity. 
Fortunately the algorithm takes a cumulative approach which= is agnostic of the path length. 
  1. Controller performs few trivial steps like choosing long ter= m secrets, calculating the LPC values for each node and provisioning.
    2. <= li class=3D"">Each node only performs 2 additions, 1 multiplication and 1 m= od(prime) operation per packet . 
  2. Verifier also per= forms step (2) and additionally performs 1 addition, 1 mod(prime) and compa= rison to verify ! 
The above steps hold good for any length of nodes. 

A detailed example is provided for illustrative purposes in= our draft  (section 3.3) that explains above operations. 

Would be happy to discuss more on the above, if needed.&nbs= p;

Regards,
Sashank


From: "Diego R. Lop= ez" <die= go.r.lopez@telefonica.com>
Date: Friday, 26 August = 2016 at 6:21 PM
To: "Frank Brockner= s (fbrockne)" <fbr= ockne@cisco.com>
Cc: Tal Mizrahi <talmi@marvell.com>, sash= ank dara <sadara@cisco.co= m>, "draft-brockners-proof-of-transit@tools.ietf.org&quo= t; <draft-brockners-proof-of-transit@tools.ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "nvo3@ietf.org" = <nvo3@ietf.org>, &quo= t;sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Quest= ion regarding Proof of Transit draft

Hi Frank,

This is a really interesting piece of work, and I must say = we have been discussing the PoT issue with some customers (though we used t= o call it =93assured path traversal=94) and we have been exploring possible= solutions, trying to combine good-enough security with a reasonable amount of computational complexity, and I am gl= ad to see a practical proposal addressing this problem. I had a brief conve= rsation with Carlos while in Berlin, but I am afraid that the IETF week was= too hectic for a detailed discussion.

Let me add to Tal=92s analysis a third issue to consider. M= y understanding of Shamir=92s polynomials is that they can be used to recon= struct a secret from N pieces you need a polynomial of degree N-1, so that = implies that the verification is limited to a certain number of SFs (or SFFs), depending on the degree of the appli= ed polynomial. We=92d need and assessment on the computational complexity a= ssociated with path length and the requirements for adaptation of the PoT n= odes (I guess SDN/NFV could play a role there=85)

Be goode,
 
On 20 Jul 2016, at 09:16 , Frank Brockners (fbrockne) <<= a href=3D"mailto:fbrockne@cisco.com" class=3D"">fbrockne@cisco.com> = wrote:

Hi Tal,
 
well... if you could protect the= integrity of the data stream between source and destination, you would not= be able to swap the content of a packet =96 which is what your attack is all about. Rather than continue arguing t= he point, let=92s acknowledge that it is a valid attack and let=92s look fo= r a solution :-). We=92ll need to couple POT to integrity protection of the= packet.
 
Hence, I=92d like to come back t= o my question asked below:  
Do you (and the entire SFC team = here) think it is worthwhile to provide a solution for a deployment which i= s expected to *not* alter the packet payload?
 
Thanks, Frank
 
From: Tal Mizrahi [mailto:talmi@marvell.com] 
Sent: D= ienstag, 19. Juli 2016 18:15
To: Fra= nk Brockners (fbrockne) <fbrockne@cisco.com>; Sashank Dara (sadara) <sadara@cisco.com= >; draft-brockners-proof-of-transit@t= ools.ietf.org
Cc: sfc@ietf.org;&n= bsp;opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Hi Frank,<= /span>
 
The POT replacement attack (1.) = is not an attack on the integrity. It is an attack on the path verification= .
This simple attack can cause the= verifier to accept a packet that did not go through the firewall SF (even = though it should). I believe this is exactly the problem you were aiming to address in this draft.
 
Thanks,
Tal.
 
From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] 
Sent: T= uesday, July 19, 2016 6:00 PM
To: Tal= Mizrahi; Sashank Dara (sadara); = ;draft-brock= ners-proof-of-transit@tools.ietf.org
Cc: sfc@ietf.org;&n= bsp;opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Hi Tal,
 
thanks for the summary. We=92ll = provide more details on 2. Per my earlier point =96 1. is an interesting di= scussion, given that we don=92t claim to provide integrity protection for the packet payload. Or in other terms =96 to be e= xact: What POT provides is a proof that the POT-header/meta-data transited = all the required nodes. There is no association (and thus proof) provided f= or the additional data carried along with the POT-header =96 neither header nor payload. As a consequence, atta= cks which change the packet payload won=92t be detected/mitigated. We=92ll = explicitly state this in the security considerations in the next rev of the= document.
What we could consider is linkin= g the RND number to CRC across the packet payload or similar =96 but that w= ay we=92d restrict the applicability to deployments where the packet payload isn=92t changed across the path (which might not = apply to certain deployment =96 e.g. WAN optimization / compression schemes= ).
Do you think it is worthwhile to= provide a solution for a deployment which is expected to not alter the pac= ket payload?
 
Thanks,
Frank
 
From: Tal Mizrahi [mailto:talmi@marvell.com] 
Sent: D= ienstag, 19. Juli 2016 17:44
To: Sas= hank Dara (sadara) <sadara@cisco.com>; F= rank Brockners (fbrockne) <fbrockne@cisco.c= om>; draft-brockners-proof-of-transit= @tools.ietf.org
Cc: sfc@ietf.org;&n= bsp;opsawg@ietf.org; nvo3@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Hi,=
 
To summarize my take on this thr= ead:
The proposed mechanism has two s= ignificant vulnerabilities that (in my understanding) are currently not add= ressed:
1.  &nb= sp;    A man-in-the-middle can replace the POT of packet A with the POT of packet B= .
2.  &nb= sp;    It is possible to replay POTs within a certain time window, whose length is d= etermined by the timestamp resolution.
 
Sashank, thanks for agreeing to = look into it further. I am looking forward to your insights on this.
 
Regards,
Tal.
 
Link to the draft: https://tools.ietf.org/html/draft-brockners-proo= f-of-transit-01
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 12:20 PM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
 
 
I want to ask a simple question:=
If the attacker attaches the POT= of packet A (indicating the path through 1,3,5,6) to packet B, will the ve= rifier accept packet B and believe that its path was indeed (1,3,5,6)?
 
[SD] If the verifier is programmed to just validate the= POT meta data against {1,3,5,6} then yes it accepts it. 
If the verifier is programmed to consult a policy datab= ase to cross check if the reconstructed path {1,3,5,6} is as per the polici= es then no , it drops it . 
 
But I see your point , that the parameters used in POT = data donot consider the path or node-ids etc . We shall discuss this intern= ally and get back.
 
Also, We shall get back with more concrete numbers of t= he timestamp resolution and cache sizes (or other better approaches). =
 
Thank you so much for all the inputs. 
 
 
 
From: Tal Mizrahi 
Sent: T= uesday, July 19, 2016 10:28 AM
To: 'Sa= shank Dara (sadara)'; Frank Brockners (fbrockne); draft-brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: RE: Question regarding Proof of Transit draft
 
Dear Sashank,
 
I really appreciate the quick an= d detailed responses.
 
>>>Lets take correct path taken by Packet A &n= bsp;to be P= ath1 - ( 1,3,5,6) nodes. 
>>>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
>>> 
>>>If the attacker could take values from Path1 and reattach them to Path2 , 
>>>the reconstruction for PacketB would result in (1,3,5,= 6) instead of (1,2,3,6). 
>>>This could be compared with topology/policy db information for = any policy 
>>>violations. POT does not enforce a particular path to be taken.=
>>So packet B skipped node= 5 (e.g. the firewall SF), but the verifier believes it went through the co= rrect path.
>>Would you agree?<= /span>
>[SD] The verifier only constructs the path the pack= et took accurately, it is upto
>the application to determine whether it violates an= y policies (I.e missing any function) 
>The bottom line is , an attacker taking a different= path cannot get away with it !
>The whole intent of =93proof-of-transit=94 is to pr= ove the path packet has taken exactly. 
>POT does not define whether it good/bad path. It is= upto high level applications on what
>do with =93reconstructed=94 path. 
 
 
 
I want to ask a simple question:=
If the attacker attaches the POT= of packet A (indicating the path through 1,3,5,6) to packet B, will the ve= rifier accept packet B and believe that its path was indeed (1,3,5,6)? =
 
 
>>Hmmm=85 Let=92s say we a= re talking about traffic at 10 Gbps, which is roughly 
>>1 million packets per second. That would mean the verifier has to s= tore a million values of RND-2.
>>Moreover, every time a packet arrives, the verifier would have to c= ompare its 
>>RND-2 value with the 1 million stored values, in order to verify th= ere is no replay.
>>That does not sound feasible.
>>Am I missing something here?
>[SD] Second level precision is only an example, we could use as m= uch precision as we want to reduce the number of values to be cached !
 
My point is that assuming reason= able resources are used, the mechanism is vulnerable to a replay attack.
In order to prove me wrong, can = you present concrete numbers of the timestamp resolution and the cache size= ?
Otherwise, you may consider usin= g a sequence number + sliding window (e.g., as in IPsec).
 
 
Thanks,
Tal.
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 9:56 AM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
 
 
 
>[SD] Ok. This is an interesting attack.  <= /div>
> 
>Lets take correct path taken by Packet A  to b= e Path1=  - ( 1,3,5,6) nodes. 
>Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
> 
>If the attacker could take values from Path1 and reattach them to Path2 , 
>the reconstruction for PacketB would result in= (1,3,5,6) instead of (1,2,3,6). 
>This could be compared with topology/policy db info= rmation for any policy
>violations. POT does not enforce a particular path = to be taken.
 
So packet B skipped node 5 (e.g.= the firewall SF), but the verifier believes it went through the correct pa= th.=
Would you agree?
 
[SD] The verifier only constructs the path the packet t= ook accurately, it is upto the application to determine whether it violates= any policies (I.e missing any function) =
The bottom line is , an attacker taking a different pat= h cannot get away with it ! The whole intent of =93proof-of-transit=94 is t= o prove the path packet has taken exactly. 
POT does not define whether it good/bad path. It is upt= o high level applications on what do with =93reconstructed=94 path. 
 
 
Hmmm=85 Let=92s say we are talki= ng about traffic at 10 Gbps, which is roughly 1 million packets per second.= That would mean the verifier has to store a million values of RND-2.
Moreover, every time a packet ar= rives, the verifier would have to compare its RND-2 value with the 1 millio= n stored values, in order to verify there is no replay.
That does not sound feasible.
Am I missing something here?
 
[SD] Second level precision is only an example, we could use as much = precision as we want to reduce the number of values to be cached !
 
 
Sashank 
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 8:33 AM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
Inline .. 
 
 
We have two consecutive packets,= A and B:=
- Packet A that went through the= correct path and has a correct POT.
- Packet B that did not go throu= gh the correct path and does not have a correct POT.
 Now the attacker performs = a =91mix and match=92 attack, by taking the correct POT from packet A and a= ttaching it to packet B.<= o:p class=3D"">
The attacker also terminates pac= ket A.
There is no replay here, because= the verifier receives the correct POT only once. The problem is that the c= orrect POT happens to arrive with packet B. L
Thus, packet B appears okay to t= he verifier, even though it did not go through the correct path.
 
Is there a way to mitigate this = attack?
 
[SD] Ok. This is an interesting attack.  
 
Lets take correct path taken by Packet A  to be Path1 - ( 1,3,5,6) nodes. 
Lets assume incorrect path to be Packet B i.e. Path2 -  (1,2,3,6).
 
If the attacker could take values from Path1 and reattach them to Pa= th2 , the reconstru= ction for PacketB would result in (1,3,5,6) instead of (1,2,3,6). =
This could be compared with topology/policy db informat= ion for any policy violations. POT does not enforce a particular path to be= taken.
 It just reconstructs the particular path taken by= the packets. 
 
Do you mean that there is a one-= second-vulnerability for replay attacks?
One second is practically foreve= r.<= /span>
 
[SD] Not really , the verifier could cache the RND-2 nu= mbers used in the time slice of one second and flush off after every second= . There is no one-second-vulnerability as such, if the verifier caches those values. 
 
Effective replay prevention is t= ypically performed using a sequence number, with a sliding window to allow = out-of-order packets. Wouldn=92t it be possible to incorporate such a sequence number into your mechanism?
 
[SD] Time stamp is essentially at high level sequence n= umber (at seconds level)! The challenge with using complete RND-2 as sequen= ce number is that the differential analysis of CML values (across packets) becomes very easy  and predictable.
that=92s reason we recommend using  ( Timestamp(/ = sequence number) + RND )
 
 
 
 
From: Sashank Dara (sadara) [mailto:sadara@cisco.com] 
Sent: T= uesday, July 19, 2016 1:11 AM
To: Tal= Mizrahi; Frank Brockners (fbrockne);=  draft-= brockners-proof-of-transit@tools.ietf.org; sfc@ietf.org
Subject: Re: Question regarding Proof of Transit draft
 
Dear Tal,
Thank you for your interest in our work. More inline wi= th [SD] .. 
 
 
Right, I am referring to the for= mer. The integrity check is not the issue.
Let=92s say we have:
- Packet A that went through the= correct path and has a correct POT.
- Packet B that did not go throu= gh the correct path and does not have a correct POT.
 
The attacker can =91launder=92 p= acket B by replacing the (incorrect) POT of packet B with the correct POT o= f packet A (and drop packet A).
Thus, packet B is verified corre= ctly, even though it did not go through the correct path.
 
[SD] This is valid scenario and we have certain in-buil= t mitigation techniques and recommendations for the same. 
There are two scenarios here 
 
Partial Replay of POT data (Replaying int= ermediate CMLs)
 
Attacker cannot reuse few intermediate node=92s POT val= ues (from older packet traces) as it would disrupt the POLY-3 construction.=  
On the other hand if the attacker tries to replay entir= e sequence of CML values, he cannot still , because notice that verifier al= so has a secret share of RND-1 and participates in the reconstruction of RND-3.
Verifier=92s share of RND-3 is never on wire , so attac= ker cannot just observe the packet traces to reuse and replay it. =
 
Total Replay of POT data (Replaying compl= ete RND-2)
 
Another trick, attacker could do is by completely reusi= ng RND-2 (but not intermediate CML values)
In order to prevent the =93Reply Attacks=94 , we recomm= end that the RND-2 (generated per packet) be a combination (I.e. RND2 =3D = =93Time Stamp + RND number=94)
So in case a passive attacker tries to replay one of th= e correct but older RND-2, the verifier first could check the current times= tamp against the timestamp retrieved from RND-2.
If the retrieved timestamp is older than current timest= amp we drop/raise a flag ! 
 
There is still a small window , where the attacker coul= d replay it within the valid time slice itself but by carefully choosing th= e time slice we can make it nearly impossible for the attacker to replay.
For example , if the Time Stamp chosen is 32 bits , we = could get one seconds level precision in the time window . So it is highly = impossible for the attacker to replay within such a small time at such a high packet rates. 
 
Also , the verifier could cache, if needed, certain num= ber of previously used RND-2 to mitigate replay attacks. 
 
Hope this clarifies. 
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org= /mailman/listinfo/sfc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.= lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

--_000_2CF6090E89DE482389D7A0867DC92A8Atelefonicacom_-- From nobody Sat Sep 24 04:14:50 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD612B9CE for ; Sat, 24 Sep 2016 04:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YhQvZ_ZFxAAc for ; Sat, 24 Sep 2016 04:14:46 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 DEDE812B9B4 for ; Sat, 24 Sep 2016 04:14:45 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 197so11927499wmk.1 for ; Sat, 24 Sep 2016 04:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ozkv57AaW7muAz4zUd3JWZtntRlVL/NuxwexYZpbrjU=; b=cRmgMwtJ3T/Td4uGjzc8P6n51N81trDl5i95WEnB5uTSykY4Qb3hxJu2NneKCnRGJi X2oFS9LfpCEpfmzvojz5k7vMXlaw07mt2UeP3+CKHhbSAY9Cyd1sQGRYKTUpaVkd8HIa 4cLwYrGLJ+LvS4YbiYBJbWzykY/VWUeIgqOx0ibUA8onKvDMLAu9vu3MK52SxVIYhmjR qcBYHOr8N8iWjq7gGmmyGvuaBcILW0fAtKcFKZ5DZkfInDyQnjNqsXJ2RPdYxbizln09 p3q+9wohNf81mgWXafsJWQhXoGGpNE8+28CZvFmcExWZF67ZU/NuYnzRHmyAUQ8VHPvI cZ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ozkv57AaW7muAz4zUd3JWZtntRlVL/NuxwexYZpbrjU=; b=gqCEwATgQp/GV8leFYrJPktlNODGYN9MJcD9E/lQhIUevtSFjHvLO+yAQ2PKA3KEJ6 ctBEXLdeezqvq3dlBEFN0k13BTJec1snMS/6WldzQpHANvjbdpQY0Bb99r4lgMcw9Rmt qtGbeFuQkkmFF1pD5ZIc8+iXI0a/OCcl09MWVAVgS9g0cVXP4qEPx6CzX+sekRxQJ+m7 qLBs0pyJNOTUrrcqDCxQKDA2LjnCH/0H1rL8A9srJJuhOgiI5Qxr3fZByDoFZ5tOduN2 C4E+5dCMZSIl/knoG7MRxWfAAywYftAJdOoU0vxJ2BuL1lILuVFcLInTSjsPEQNNGU1A ws0A== X-Gm-Message-State: AA6/9Rm4hzp7kK4i7iW8min6/qGHVXR0StxgVh3L+1CyaLCO2ADP5V2dKju2K4Iaxhnnsw== X-Received: by 10.194.44.166 with SMTP id f6mr2613115wjm.141.1474715684038; Sat, 24 Sep 2016 04:14:44 -0700 (PDT) Received: from mn-mn0F-2.local ([2a01:598:a040:6fb2:605d:ff6:3d55:c04c]) by smtp.googlemail.com with ESMTPSA id m75sm581697wmi.0.2016.09.24.04.14.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Sep 2016 04:14:42 -0700 (PDT) To: sfc@ietf.org From: Martin Stiemerling Message-ID: <71aca9e7-ae20-e63a-33a0-1e52ec515ba9@gmail.com> Date: Sat, 24 Sep 2016 13:14:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] SFC virtual interim about Security and Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 11:14:48 -0000 Hi all, The SFC chairs are planning to hold a virtual interim meeting about the topics of SFC Security and Metadata. There is no fixed date yet, as I would like to get a poll from you about what date might be the best. Time-wise we will start at 10am EST which is - 10 pm Beijing - 4 pm Central Europe - 7 am US east coast. We have planned for 2 hours of meeting time and we will use Webex to run the meeting. Please use the doodle to indidcate what date is preferable by you until 09/29 10 am EST: http://doodle.com/poll/9sv9btwt3sgs8uin Regards, Martin From nobody Sat Sep 24 08:58:20 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0049A12B14A for ; Sat, 24 Sep 2016 08:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FVbnUAhjVMvE for ; Sat, 24 Sep 2016 08:58:16 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E2212B135 for ; Sat, 24 Sep 2016 08:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1274; q=dns/txt; s=iport; t=1474732696; x=1475942296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ovk5JYkdugMi81+h+TYdf8bdIMpbqGxaEO3XhzDUvtE=; b=VThBl9SXbVX/P4TY2tSSXCweGypmOZkYRlbX6u9wCI1+nEYZNzBwkRky xJ+i6x9jWuNIuZn/4MA74e0zGlXb6XV5EmZEP8A6np8pFfMSnw/jogJtO IRQBgR+scE2Z6CnR38aXAzptWmKeJ41fh4nMZRMKeAm4X5P3ilHEQdjMj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAQDkoeZX/4MNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzsBAQEBAR5XfAeNLJ8CjEeCBBkLhXoCHIEtOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBAwEBAQEgEToLBQsCAQgOCgICJgICAh8GCxUQAgQOBYgxAw8IDrBpiHsNg?= =?us-ascii?q?0IBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQaFMYF8gliCR4F9gwQrgi8FmUE1AYY?= =?us-ascii?q?mhkmCeIFuToQWiRmIXIQPg3sBHjaFBXKFcn8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,388,1470700800"; d="scan'208";a="327678758" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Sep 2016 15:58:15 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8OFwFsZ019488 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 24 Sep 2016 15:58:15 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 24 Sep 2016 10:58:14 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Sat, 24 Sep 2016 10:58:14 -0500 From: "Carlos Pignataro (cpignata)" To: Martin Stiemerling Thread-Topic: [sfc] SFC virtual interim about Security and Metadata Thread-Index: AQHSFlTj0xqwHuhdk0u8inR3v+LJE6CJIBKA Date: Sat, 24 Sep 2016 15:58:14 +0000 Message-ID: References: <71aca9e7-ae20-e63a-33a0-1e52ec515ba9@gmail.com> In-Reply-To: <71aca9e7-ae20-e63a-33a0-1e52ec515ba9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.233.218] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC virtual interim about Security and Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 15:58:19 -0000 DQo+IE9uIFNlcCAyNCwgMjAxNiwgYXQgNzoxNCBBTSwgTWFydGluIFN0aWVtZXJsaW5nIDxtbHMu aWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgYWxsLA0KPiANCj4gVGhlIFNGQyBjaGFp cnMgYXJlIHBsYW5uaW5nIHRvIGhvbGQgYSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBhYm91dCB0 aGUgdG9waWNzIG9mIFNGQyBTZWN1cml0eSBhbmQgTWV0YWRhdGEuDQo+IA0KPiBUaGVyZSBpcyBu byBmaXhlZCBkYXRlIHlldCwgYXMgSSB3b3VsZCBsaWtlIHRvIGdldCBhIHBvbGwgZnJvbSB5b3Ug YWJvdXQgd2hhdCBkYXRlIG1pZ2h0IGJlIHRoZSBiZXN0Lg0KPiANCj4gVGltZS13aXNlIHdlIHdp bGwgc3RhcnQgYXQgMTBhbSBFU1Qgd2hpY2ggaXMNCj4gLSAxMCBwbSBCZWlqaW5nDQo+IC0gNCBw bSBDZW50cmFsIEV1cm9wZQ0KPiAtIDcgYW0gVVMgZWFzdCBjb2FzdC4NCg0KU2VlbXMgeW91IG1l YW4gN2FtIFVTIHdlc3QgY29hc3QvUERULCAxMGFtIEVEVC4NCg0KQmVzdCwNCg0K4oCUIENhcmxv cy4NCg0KPiANCj4gV2UgaGF2ZSBwbGFubmVkIGZvciAyIGhvdXJzIG9mIG1lZXRpbmcgdGltZSBh bmQgd2Ugd2lsbCB1c2UgV2ViZXggdG8gcnVuIHRoZSBtZWV0aW5nLg0KPiANCj4gUGxlYXNlIHVz ZSB0aGUgZG9vZGxlIHRvIGluZGlkY2F0ZSB3aGF0IGRhdGUgaXMgcHJlZmVyYWJsZSBieSB5b3Ug dW50aWwgMDkvMjkgMTAgYW0gRVNUOg0KPiANCj4gaHR0cDovL2Rvb2RsZS5jb20vcG9sbC85c3Y5 YnR3dDNzZ3M4dWluDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+ICBNYXJ0aW4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWls aW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQoNCg== From nobody Tue Sep 27 05:50:57 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF9212B04F for ; Tue, 27 Sep 2016 05:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 ukkdT1yPsnTe for ; Tue, 27 Sep 2016 05:50:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9E812B137 for ; Tue, 27 Sep 2016 05:50:49 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id AB593A0621; Tue, 27 Sep 2016 14:50:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 7B6291A0067; Tue, 27 Sep 2016 14:50:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 14:50:45 +0200 From: To: "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Ba4oYggBiIaACAGhF1YA== Date: Tue, 27 Sep 2016 12:50:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E20A8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <787AE7BB302AE849A7480A190F8B933008E099F0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6D3898EC-1CC4-4771-8F04-D6D1BAFE35AF@cisco.com> In-Reply-To: <6D3898EC-1CC4-4771-8F04-D6D1BAFE35AF@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" , "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 12:50:56 -0000 Hi Paul,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Envoy=E9=A0: samedi 10 septembre 2016 19:30 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Jim Guichard (jguichar); sfc@ietf.org > Objet=A0: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt >=20 > Med, >=20 > Med, as always, thank you for your review. >=20 >=20 > > On Aug 26, 2016, at 5:31 AM, mohamed.boucadair@orange.com wrote: > > > > Hi Jim, all, > > > > Likewise, I would like to see this document progress as well. > > > > In addition to the comment raised in a separate message about the C-bit > of TLVs, I have the following comments: > > > > (1) Section 2: I suggest to delete the following sentence: > > > > NSH is designed to be easy to implement across a range of devices, > > both physical and virtual, including hardware platforms. > > > > Reason: the use of "easy to implement" should be justified if that text > is maintained. Otherwise, this is subjective. > > > > or to reword it as follows: > > > > "NSH can be implemented in both physical and virtual platforms." >=20 > PQ> The "easy to implement" is a reference to the nature of type-1 and > how, as noted by hardware implementors, this vastly simplifies > implementation. Further, the language is widely used in RFCs (e.g. 7321, > 3160, etc.). [Med] Unless that statement is backed with citations or arguments, I still = consider it as subjective. >=20 > > > > (2) Section 2.3: I suggest to change this OLD text: > > > > The semantics of > > the shared metadata is communicated via a control plane, which is > > outside the scope of this document, to participating nodes. > > > > NEW: > > > > The semantics of > > the shared metadata is communicated via a control plane (Section 3.3 of > [I-D.ietf-sfc-control-plane]). > > >=20 > PQ> Proposed text: "The semantics of the shared metadata is communicated > via a control plane, which is outside the scope of this document, to > participating nodes. [ietf-sfc-control-plane] provides an example of suc= h > in section 3.3. >=20 [Med] Works for me.=20 >=20 > > (3) Section 2.3- Not sure I would maintain this text: > > > > 5. NSH offers a common and standards-based header for service > > chaining to all network and service nodes. > > > > "to all" is not accurate as "legacy" nodes are still there. > > >=20 > PQ> Given that "legacy" nodes are supported via proxy, this is indeed > true. >=20 [Med] Please update the text to mention the proxy case. Thank you. >=20 > > (4) Section 2.3: > > > > OLD: > > Transport Agnostic: NSH is transport independent and is often > > carried via a network transport protocol, > > > > NEW: > > Transport Agnostic: NSH is transport independent. Any network transport > protocol can be used to transport NSH-encapsulated traffic. >=20 >=20 > PQ> Proposed text: NSH is transport independent. An appropriate (for a > given deployment) network transport protocol can be used to transport NSH= - > encapsulated traffic. >=20 [Med] OK. Thanks.=20 >=20 > > > > (5) Section 3.2: > > > > NSH implementations MUST support MD-Type =3D 0x1, and SHOULD support > > MD- Type =3D 0x2. > > > > Because: > > * of potential interoperability issues. > > * MD#2 is more compact when no metadata is to be supplied > > * MD#2 allows to convey more information compared to MD#1 > > > > I suggest we revisit that sentence to have MD#2 be mandatory to be > supported (my favorite option), or at least require that both MDs defined > in this spec MUST be supported. > > > PQ> As per the previous discussion, this MUST/SHOULD reflect the > practical reality of implementation and helps ensure deployability. >=20 [Med] the SHOULD for MD#2 does not help interoperability. I reiterate my co= mment to update the language to use MUST for MD#2. >=20 >=20 > > (6) Section 3.2: > > > > C bit: Indicates that a critical metadata TLV is present. This bit > > acts as an indication for hardware implementers to decide how to > > handle the presence of a critical TLV without necessarily needing to > > parse all TLVs present. For an MD Type of 0x1 (i.e. no variable > > length metadata is present), the C bit MUST be set to 0x0. > > > > 6.1. What is the behavior of the implementation if C-bit is set but not > critical metadata is found in the payload? > > 6.2. What is the behavior of the implementation if C-bit is unset but a > critical metadata is found in the payload? > > 6.3. What is the behavior of the implementation with regards to this bi= t > if a critical metadata is added in-path? > > 6.4. What is the behavior of the implementation with regards to this bi= t > if a critical metadata is stripped in-path? > > 6.5. Should the specification recommend an order of metadata so that > critical metadata are always positioned first? >=20 > PQ> >=20 > 6.1: essentially continue "as is" with an optional warning message > 6.2: generate an warning error, possibly set C > 6.3: the adder sets C > 6.4: the remover clears C > 6.5: no, this creates too many limitations/complexity. An implementation > might opt to optimize. >=20 [Med] This should be reflected in the specification. >=20 > > > > (7) Section 3.3: The following text > > > > " ... however the > > control plane MAY configure the initial value of SI as appropriate > > (i.e. taking into account the length of the service function path). " > > > > is not aligned with the outcome of the discussion we had during the WG > LC of draft-ietf-sfc-control-plane (https://www.ietf.org/mail- > archive/web/sfc/current/msg04594.html): > > > > The control plane must instruct the classifier about the initial > > values of the Service Index (SI). > > >=20 > PQ> The control plane can assign but NSH provides a default value > recommendation, I'm not sure there's a conflict. [Med] The default value in the text is a SHOULD not a MUST. =20 >=20 >=20 > > 7.1. I suggest to modify NSH draft accordingly. >=20 > PQ> I'm not clear what you are suggesting? [Med] The proposal is to use the same wording proposed by Jim for the CP dr= aft.=20 >=20 > > 7.2. Please consider adding a reference to draft-ietf-sfc-control-plane >=20 > PQ> I'll update. >=20 > > > > (8) Section 3.4: I still do think this section is underspecified. E.g., > > > > 8.1. The use of "Mandatory Context Header" conflicts with this text in > Section 3: > > > > A Network Service Header (NSH) contains service path information and > > optionally metadata that are added to a packet or frame and used to > > ^^^^^^^^^^^^^^^^^^^ > > create a service plane. > > > > 8.2. The specification does not forbid that all context headers are set > to zero. Otherwise, MD#2 should be used instead. >=20 >=20 > PQ> In either care, 1 or 2, no metadata is valid: all zeroes in type 1 o= r > no data in type 2. >=20 >=20 > > 8.3. The specification does not specify how these context headers are t= o > be validated. >=20 > PQ> By validated, so you mean cryptographically asserted, or simply > compared to known value? In either case, that is outside of the scope of > this draft. [Med] No. My concern is how an implementation will consider that a given ma= ndatory header is conveying what is supposed to include. Some validation ch= ecks are required. >=20 >=20 > > 8.4. I still don't understand why four headers are chosen. >=20 > PQ> As per previous discussions, based experience, use case and > implementation, four strikes a balance. The widespread implementations of > type 1 support this. [Med] I'm not aware of any public use case that requires 4 mandatory contex= t headers. Can you please provide a public link to a document where this is= discussed? >=20 >=20 > > > > (9) Section 3.5.1: > > > > The length of "Metadata Class" is over-dimensioned. I suggest to reduce > the length of this field and increase the length of "Type". > > > > For example, let's consider the proposal in > https://tools.ietf.org/html/draft-napper-sfc-nsh-broadband-allocation- > 00#section-4.2: > > > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | TLV Class =3D 3GPP |C| Type |R|R|R| Len | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Data ... > > +-+-+-+-+-+-+-+-+ > > > > Figure 5: TLV Allocation > > > > The intended use of the header is for TLVs associated with 3GPP Radio > > Access Networks as described in [TS.29.230]. This TLV can be used by > > 3GPP to extend the metadata as per use cases. Having this TLV helps > > to carry more information that does not fit within the MD Type 0x01. > > > > The list of codes in Table 7.1 of TS.29.230 cannot be conveyed with a > "Type" field of 7 bits. >=20 > PQ> At this point, the allocation seems reasonable, provides for a large > range of "owners", and the TLV schemes proposed work within this scope. [Med] "reasonable" compared to what? The example I provided above for the 3= GPP case shows clearly that 7-bits are not sufficient for TS.29.230. Furthe= r, 2^^16 is over dimensioned for owners. >=20 > > > > (10) Section 4: > > > > OLD: > > > > +---------------+------------------+-------+----------------+---------+ > > | | Insert |Select | Update |Service | > > | | or remove NSH |Service| NSH |policy | > > | | |Function| |selection| > > | Component +--------+--------+Path +----------------+ | > > | | | | | Dec. |Update | | > > | | Insert | Remove | |Service |Context| | > > | | | | | Index |Header | | > > +----------------+--------+--------+-------+--------+-------+---------+ > > | | + | + | | | + | | > > |Classifier | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |Service Function| | + | + | | | | > > |Forwarder(SFF) | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |Service | | | | + | + | + | > > |Function (SF) | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |SFC Proxy | + | + | | + | | | > > +----------------+--------+--------+-------+--------+-------+---------+ > > > > NEW: > > > > +---------------+------------------+-------+----------------+---------+ > > | | Insert |Select | Update |Service | > > | | or remove NSH |Service| NSH |policy | > > | | |Function| |selection| > > | Component +--------+--------+Path +----------------+ | > > | | | | | Dec. |Update | | > > | | Insert | Remove | |Service |Context| | > > | | | | | Index |Header | | > > +----------------+--------+--------+-------+--------+-------+---------+ > > | | + | + | | | + | | > > |Classifier | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |Service Function| | + | + | | | | > > |Forwarder(SFF) | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |Service | | | | + | + | + | > > |Function (SF) | | | | | | | > > +--------------- +--------+--------+-------+--------+-------+---------+ > > |SFC Proxy | + | + | | + | + | | > > +----------------+--------+--------+-------+--------+-------+---------+ >=20 > PQ> Just to be clear (formatting was a bit off in the email): >=20 > In the last line, SFC Proxy, add "Update Context Header"? [Med] Yes. >=20 > > > > (11) Section 7.2: Please consider adding an IPv6 example. >=20 > PQ> Happily. [Med] Thank you. From nobody Tue Sep 27 05:52:56 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D101812B04F for ; Tue, 27 Sep 2016 05:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 QxqWGJ5gL01y for ; Tue, 27 Sep 2016 05:52:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F7112B137 for ; Tue, 27 Sep 2016 05:52:53 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 458744063D; Tue, 27 Sep 2016 14:52:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 1CB911A0069; Tue, 27 Sep 2016 14:52:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 14:52:52 +0200 From: To: Dave Dolson , "Paul Quinn (paulq)" , "sfc@ietf.org" Thread-Topic: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt Thread-Index: AQHR/UcBiQhx1l4jAUq5aGvg+Ua8YKBaFmMAgBLGkTCAIKRYkA== Date: Tue, 27 Sep 2016 12:52:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008E20AB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <147196046137.30731.1399811299254089080.idtracker@ietfa.amsl.com> <60F54D29-49F6-4962-963B-93FF6F4DF1A1@cisco.com> <787AE7BB302AE849A7480A190F8B933008E0952B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 12:52:56 -0000 Re-, Unless I'm mistaken, I didn't see any follow-up for this issue.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9=A0: mardi 6 septembre 2016 20:25 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq); sfc@ietf.org > Objet=A0: RE: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt >=20 > Do the authors have a response to this question? > I'm also wondering about whether the 'C' flag might be for the > administrator vs. IANA. >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, August 25, 2016 11:40 AM > To: Paul Quinn (paulq); sfc@ietf.org > Subject: Re: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt >=20 > Hi Paul, >=20 > I have a comment about this text: >=20 > Type: the Type field is split into two ranges - 0 to 127 for non- > critical options and 128-255 for critical options. While the value > allocation is the responsibility of the MD Class owner, critical > options MUST NOT be allocated from the 0 to 127 range and non- > critical options MUST NOT be allocated from the 128-255 range. >=20 > * Do you have an example of metadata that is critical for all chains, all > deployments? > * Wouldn't be more appropriate to have one single registry for "type" wit= h > C-bit be a configurable parameter to be set by the administrator of the > SFC-enabled domain? >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Paul Quinn (paul= q) > > Envoy=E9=A0: mardi 23 ao=FBt 2016 16:02 > > =C0=A0: sfc@ietf.org > > Objet=A0: [sfc] Fwd: I-D Action: draft-ietf-sfc-nsh-06.txt > > > > Dear WG, > > > > This version includes much of the feedback/review/comments from this > list. > > > > > > > > > Begin forwarded message: > > > > > > From: internet-drafts@ietf.org > > > Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-06.txt > > > Date: August 23, 2016 at 9:54:21 AM EDT > > > To: > > > Cc: sfc@ietf.org > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Service Function Chaining of the > IETF. > > > > > > Title : Network Service Header > > > Authors : Paul Quinn > > > Uri Elzur > > > Filename : draft-ietf-sfc-nsh-06.txt > > > Pages : 37 > > > Date : 2016-08-23 > > > > > > Abstract: > > > This document describes a Network Service Header (NSH) inserted ont= o > > > packets or frames to realize service function paths. NSH also > > > provides a mechanism for metadata exchange along the instantiated > > > service path. NSH is the SFC encapsulation required to support the > > > Service Function Chaining (SFC) Architecture (defined in RFC7665). > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-sfc-nsh-06 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-nsh-06 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > 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 Sep 28 09:19:35 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A4012B207 for ; Wed, 28 Sep 2016 09:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 VxYfNjb5RNXk for ; Wed, 28 Sep 2016 09:19:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A216112B201 for ; Wed, 28 Sep 2016 09:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1824; q=dns/txt; s=iport; t=1475079572; x=1476289172; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lsGxdF/jDKFoAwbpUo5ZM3i1L3KNiqs+gImMgEJLyjc=; b=WhM7tZS/6rOhspuMKpJXp5WO6ntyemVJPgWYNpGuJ5/Iw8qfoGZKfUAC wJ6/mXZnMFuMZ6hEVKkRrgsHa/epkvUNKLIK98v80bxnBboo1wCB7UKPO qy1ykriJnn6CWRwdJslRjD7/3FV8g98K56NkEpm4erxhNU7HGsqRiRpRL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAQCg7OtX/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR5XfAeNK6sdggYghX4CHIFDOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?iAQEEIxFFEAIBCBoCERUCAgIwFRACBAENBYhNsBKMegEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARcFgQaFMYF8CIJQhCcBAVqCRSuCLwEEmXYBj2qBboRkiRqQaAEeNoU?= =?us-ascii?q?JcoUSgSCBAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,410,1470700800"; d="scan'208";a="152188866" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2016 16:19:31 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u8SGJVWM018502 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2016 16:19:31 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Sep 2016 11:19:30 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 28 Sep 2016 11:19:30 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Ba4oYggBiIaACAGhF1YIAB4dIA Date: Wed, 28 Sep 2016 16:19:30 +0000 Message-ID: <4DD2E17B-87D4-4323-AB52-02784895E27B@cisco.com> References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <787AE7BB302AE849A7480A190F8B933008E099F0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6D3898EC-1CC4-4771-8F04-D6D1BAFE35AF@cisco.com> <787AE7BB302AE849A7480A190F8B933008E20A8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E20A8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: text/plain; charset="utf-8" Content-ID: <9D74A2BC75894B4EA0B9ABF41275DAE5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 16:19:34 -0000 SGkgTWVkLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4uLg0KDQoNCg0KDQoNCk9uIDkvMjcvMTYsIDg6 NTAgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4gd3JvdGU6DQoNCj4NCj4NCj4+IA0KPj4gPg0KPj4gPiAoNykgU2VjdGlvbiAz LjM6IFRoZSBmb2xsb3dpbmcgdGV4dA0KPj4gPg0KPj4gPiAiIC4uLiBob3dldmVyIHRoZQ0KPj4g PiAgIGNvbnRyb2wgcGxhbmUgTUFZIGNvbmZpZ3VyZSB0aGUgaW5pdGlhbCB2YWx1ZSBvZiBTSSBh cyBhcHByb3ByaWF0ZQ0KPj4gPiAgIChpLmUuIHRha2luZyBpbnRvIGFjY291bnQgdGhlIGxlbmd0 aCBvZiB0aGUgc2VydmljZSBmdW5jdGlvbiBwYXRoKS4gIg0KPj4gPg0KPj4gPiBpcyBub3QgYWxp Z25lZCB3aXRoIHRoZSBvdXRjb21lIG9mIHRoZSBkaXNjdXNzaW9uIHdlIGhhZCBkdXJpbmcgdGhl IFdHDQo+PiBMQyBvZiBkcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lIChodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsLQ0KPj4gYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDQ1OTQuaHRtbCk6 DQo+PiA+DQo+PiA+ICAgVGhlIGNvbnRyb2wgcGxhbmUgbXVzdCBpbnN0cnVjdCB0aGUgY2xhc3Np ZmllciBhYm91dCB0aGUgaW5pdGlhbA0KPj4gPiAgIHZhbHVlcyBvZiB0aGUgU2VydmljZSBJbmRl eCAoU0kpLg0KPj4gPg0KPj4gDQo+PiBQUT4gIFRoZSBjb250cm9sIHBsYW5lIGNhbiBhc3NpZ24g YnV0IE5TSCBwcm92aWRlcyBhIGRlZmF1bHQgdmFsdWUNCj4+IHJlY29tbWVuZGF0aW9uLCBJJ20g bm90IHN1cmUgdGhlcmUncyBhIGNvbmZsaWN0Lg0KPg0KPltNZWRdIFRoZSBkZWZhdWx0IHZhbHVl IGluIHRoZSB0ZXh0IGlzIGEgU0hPVUxEIG5vdCBhIE1VU1QuICANCg0KSmltPiBJIGFtIG5vdCBz dXJlIHdoYXQgeW91IGFyZSBhc2tpbmcgZm9yIGhlcmUuIFRoZSBjdXJyZW50IHRleHQgaW4gc2Vj dGlvbiAzLjMgaXM6DQoNClNlcnZpY2UgSW5kZXggKFNJKTogcHJvdmlkZXMgbG9jYXRpb24gd2l0 aGluIHRoZSBTRlAuICBUaGUgaW5pdGlhbA0KICAgY2xhc3NpZmllciBNVVNUIHNldCB0aGUgYXBw cm9wcmlhdGUgU0kgdmFsdWUgZm9yIGEgZ2l2ZW4NCiAgIGNsYXNzaWZpY2F0aW9uIHJlc3VsdC4g IFRoZSBpbml0aWFsIFNJIHZhbHVlIFNIT1VMRCBkZWZhdWx0IHRvIDI1NS4NCiAgIEhvd2V2ZXIs IHRoZSBjbGFzc2lmaWVyIE1VU1QgYWxsb3cgY29uZmlndXJhdGlvbiBvZiBvdGhlciBTSSB2YWx1 ZXMuDQoNCg0KSmltPiBJcyB0aGVyZSBzb21ldGhpbmcgbWlzc2luZyBpbiB0aGUgYWJvdmUgdGV4 dD8NCg0KSmltDQoNCj4gDQo+IA0K From nobody Wed Sep 28 10:05:46 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6396612B241 for ; Wed, 28 Sep 2016 10:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SW2QRKzhNT92 for ; Wed, 28 Sep 2016 10:05:44 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67B612B239 for ; Wed, 28 Sep 2016 10:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1622; q=dns/txt; s=iport; t=1475082335; x=1476291935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GFBqerKoMWy1X/HumFNi69xs53mQXNMNL3QOxo1Me0U=; b=KmjVS+wHMKdh7Z1JTHKm/92WjdoB5cHt+7HjPu8wA78NGnukzr9w+XMQ lvXIwUagRV044Y+Nd0P4W6u828lNWzFpBDdbS8ZRPsAQHy/dCVNYFP6sN 7otcEQanmR9UGImlmAu3Yw0mi04UgtUQOIzgB00QcGonU/L2S1CmiNZlg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCh9+tX/5NdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgz8BAQEBAR6BWo0rqx2CBoYeAhyBQzgUAQIBAQEBAQEBXieEYgEBBCM?= =?us-ascii?q?RRRACAQgaAiYCAgIwFRACBAENiFKvQYx6AQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?IEGhTGBfIJYh0grgi8BBJl2AY9qgW6NfocJiV8BHjaDHRyBUIckgQABAQE?= X-IronPort-AV: E=Sophos;i="5.30,410,1470700800"; d="scan'208";a="329115445" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2016 17:05:35 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u8SH5ZQA005252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Sep 2016 17:05:35 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Sep 2016 12:05:34 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 28 Sep 2016 12:05:34 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Paul Quinn (paulq)" Thread-Topic: [sfc] WG review for draft-ietf-sfc-nsh-07.txt Thread-Index: AQHR/V4l7FibCE2gCkSX9qAjBx/2X6Ba4oYggBiIaACAGhF1YIAB7rCA Date: Wed, 28 Sep 2016 17:05:34 +0000 Message-ID: References: <98638C8E-3C9D-4C87-AA1F-90E95A3F001C@cisco.com> <787AE7BB302AE849A7480A190F8B933008E099F0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6D3898EC-1CC4-4771-8F04-D6D1BAFE35AF@cisco.com> <787AE7BB302AE849A7480A190F8B933008E20A8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E20A8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG review for draft-ietf-sfc-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 17:05:45 -0000 SGkgTWVkLA0KDQpJbmxpbmUgb24gdGhlIE1EIE1VU1QvU0hPVUxEIHF1ZXN0aW9uLg0KDQoNCg0K DQo+DQo+PiANCj4+ID4NCj4+ID4gKDUpIFNlY3Rpb24gMy4yOg0KPj4gPg0KPj4gPiAgIE5TSCBp bXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IE1ELVR5cGUgPSAweDEsIGFuZCBTSE9VTEQgc3Vw cG9ydA0KPj4gPiAgIE1ELSBUeXBlID0gMHgyLg0KPj4gPg0KPj4gPiBCZWNhdXNlOg0KPj4gPiAq IG9mIHBvdGVudGlhbCBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4NCj4+ID4gKiBNRCMyIGlzIG1v cmUgY29tcGFjdCB3aGVuIG5vIG1ldGFkYXRhIGlzIHRvIGJlIHN1cHBsaWVkDQo+PiA+ICogTUQj MiBhbGxvd3MgdG8gY29udmV5IG1vcmUgaW5mb3JtYXRpb24gY29tcGFyZWQgdG8gTUQjMQ0KPj4g Pg0KPj4gPiBJIHN1Z2dlc3Qgd2UgcmV2aXNpdCB0aGF0IHNlbnRlbmNlIHRvIGhhdmUgTUQjMiBi ZSBtYW5kYXRvcnkgdG8gYmUNCj4+IHN1cHBvcnRlZCAobXkgZmF2b3JpdGUgb3B0aW9uKSwgb3Ig YXQgbGVhc3QgcmVxdWlyZSB0aGF0IGJvdGggTURzIGRlZmluZWQNCj4+IGluIHRoaXMgc3BlYyBN VVNUIGJlIHN1cHBvcnRlZC4NCj4+ID4NCj4+IFBRPiAgQXMgcGVyIHRoZSBwcmV2aW91cyBkaXNj dXNzaW9uLCB0aGlzIE1VU1QvU0hPVUxEIHJlZmxlY3QgdGhlDQo+PiBwcmFjdGljYWwgcmVhbGl0 eSBvZiBpbXBsZW1lbnRhdGlvbiBhbmQgaGVscHMgZW5zdXJlIGRlcGxveWFiaWxpdHkuDQo+PiAN Cj4NCj5bTWVkXSB0aGUgU0hPVUxEIGZvciBNRCMyIGRvZXMgbm90IGhlbHAgaW50ZXJvcGVyYWJp bGl0eS4gSSByZWl0ZXJhdGUgbXkgY29tbWVudCB0byB1cGRhdGUgdGhlIGxhbmd1YWdlIHRvIHVz ZSBNVVNUIGZvciBNRCMyLg0KDQpKaW0+IGFzIHlvdSBrbm93IHRoZXJlIHdhcyBsb3RzIG9mIGRp c2N1c3Npb24gb24gdGhpcyB0b3BpYyBidXQgbm8gV0cgY29uc2Vuc3VzIHRvIGNoYW5nZSB0aGUg dGV4dCBmcm9tIFNIT1VMRCB0byBNVVNULiBIb3dldmVyLCB0ZXh0IHdhcyBhZGRlZCBhcyBhIGNv bXByb21pc2Ugc28gdGhhdCBhIHR5cGUtMSBpbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGFibGUgdG8g cGFyc2UgdGhlIGxlbmd0aCBhbmQgc2tpcCB0aGUgdHlwZS0yIG1ldGFkYXRhIGlmIGl0IGlzIHVu YWJsZSB0byBwcm9jZXNzIHNhaWQgbWV0YWRhdGEuDQoNCkppbQ0KDQo+Pg0K From nobody Fri Sep 30 06:04:57 2016 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9712B3A0 for ; Fri, 30 Sep 2016 06:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qOHgGS4Rh8BF for ; Fri, 30 Sep 2016 06:04:54 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE4612B38B for ; Fri, 30 Sep 2016 06:04:54 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p138so23915572wmb.1 for ; Fri, 30 Sep 2016 06:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/c4TJlb/9qcrLjaV4mIbp6pphPchbVonV0SyxPgJCU4=; b=jT0JVw50FVPXnvz6bZKmpEMzngr8OGGAFCA9Oo+jNG1ZPR3ZnSUN2YO5+FvtKt40Xm BaBsg1DmuIeaXnbe1tlyd/R0OydfP5LTuo+ATw/UfKUVLzrLW/C2u4/3pGvQI3qsUeba ALAf2UQPC6TRkMAdXnD/BUsBwQv6YiGG40NCVqzcW9Sl3L/8aRDsdpbPsGMxzN1FVw4r cazm90jhzsd80A/Xlebb29Kp+S9Vnw45MyQDAPtm2WpDbhyczkSaA4QOXeMCO9j+Eqc1 ITSK3yK5/+kt/nHe0542FX30FATeOZptVKA2A9hvsbIHakld9XFbxB7JiDMydUK/Uuwl QacQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/c4TJlb/9qcrLjaV4mIbp6pphPchbVonV0SyxPgJCU4=; b=XOLHtf+crRm6P6T9jDzZBbOPUJbEiT7gjheDQ3LiFOSsE1Cmpo5TS82la+BeP3yGaW vHENDawrbQtednWPzahIEgUHoZpkWiTY+lwQzIqzvRsfXvpChBqmBMYT/hD84C8IQ+Vd QEDenO2ZtdsvgjPk7oxSEVhsLMNZ4aYS8BLnHCd4F73MOjTsxz3MxoMIzfwRBPkSqpBg TH1AYRjUAK+F2CyCnDCL21gALybb2J9/4LyEP/KAuuFVfKvCLU4LsZLPDqlRfgJZFhuk 7+9BCmF4qLXv+Jrl2NQpn9YLwoB5gSRCeUaRK47PFYJ6wpd+lvI/2on7Ija/r/mXi+8I KqYw== X-Gm-Message-State: AA6/9RnH+hK4cvQakanin7dzAPMwiz2H61ks0A/nNlQ7QhVZszSyvB3zvvLHoTgV3FxNmA== X-Received: by 10.28.193.79 with SMTP id r76mr4130380wmf.41.1475240692387; Fri, 30 Sep 2016 06:04:52 -0700 (PDT) Received: from mn-mn0F-2.local ([2003:6:1125:8227:19f5:4efd:9986:32bc]) by smtp.googlemail.com with ESMTPSA id a1sm19603874wju.41.2016.09.30.06.04.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Sep 2016 06:04:51 -0700 (PDT) To: sfc@ietf.org References: <71aca9e7-ae20-e63a-33a0-1e52ec515ba9@gmail.com> From: Martin Stiemerling Message-ID: <581388b8-3f5f-87ec-0033-63e8a7d0b4f3@gmail.com> Date: Fri, 30 Sep 2016 15:04:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <71aca9e7-ae20-e63a-33a0-1e52ec515ba9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] SFC virtual interim about Security and Metadata X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 13:04:56 -0000 Hi all, Up to today we only have 12 people in the doodle... Please check your availability for the interim and enter your availability in the doodle until Wednesday, October 5th, 8 pm UTC. At this point, Friday Oct 14th looks like a good date, but let's see how many add their availability. Thanks, Martin Am 24.09.16 um 13:14 schrieb Martin Stiemerling: > Hi all, > > The SFC chairs are planning to hold a virtual interim meeting about the > topics of SFC Security and Metadata. > > There is no fixed date yet, as I would like to get a poll from you about > what date might be the best. > > Time-wise we will start at 10am EST which is > - 10 pm Beijing > - 4 pm Central Europe > - 7 am US east coast. > > We have planned for 2 hours of meeting time and we will use Webex to run > the meeting. > > Please use the doodle to indidcate what date is preferable by you until > 09/29 10 am EST: > > http://doodle.com/poll/9sv9btwt3sgs8uin > > > Regards, > > Martin From nobody Fri Sep 30 06:25:03 2016 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D550F12B119; Fri, 30 Sep 2016 06:25:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147524190183.20434.16742470610670655885.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 06:25:01 -0700 Archived-At: Cc: mls.ietf@gmail.com, sfc-chairs@ietf.org, sfc@ietf.org, akatlas@gmail.com Subject: [sfc] sfc - New Meeting Session Request for IETF 97 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 13:25:02 -0000 A new meeting session request has just been submitted by Martin Stiemerling, a Chair of the sfc working group. --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Martin Stiemerling Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: spring sdnrg rtgwg nvo3 mpls lisp idr i2rs bess Special Requests: Please add the quic bof (if approved to the 1st priority conflict list) ---------------------------------------------------------