From nobody Fri Apr 1 15:56:00 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 80CF712D6CC for ; Fri, 1 Apr 2016 15:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JDyCW9wx9h90 for ; Fri, 1 Apr 2016 15:55:56 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by ietfa.amsl.com (Postfix) with ESMTP id A267912D68E for ; Fri, 1 Apr 2016 15:55:56 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 01 Apr 2016 15:55:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,428,1455004800"; d="scan'208";a="923736326" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga001.jf.intel.com with ESMTP; 01 Apr 2016 15:55:56 -0700 Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 1 Apr 2016 15:55:55 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.18]) by ORSMSX111.amr.corp.intel.com ([169.254.12.9]) with mapi id 14.03.0248.002; Fri, 1 Apr 2016 15:55:55 -0700 From: "Elzur, Uri" To: Sunil Vallamkonda , "Joel M. Halpern" , Dave Dolson , "Bottorff, Paul" , "sfc@ietf.org" Thread-Topic: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt Thread-Index: AdGJ9+sCFkM+vCX4TPSmWI6TIKwl2QAVDRsAAA6aG/D//4/2AIAAMFYAgADrQYCAAAP0AIAAc1kw//+YKACAAAXRgIAAAi8AgAB1FkD//ZlyQA== Date: Fri, 1 Apr 2016 22:55:55 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDk2NjBlMjYtN2Y2NC00ZTVlLWJkNTctOTg0MWU4ZmI4NGE5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkttRWl5K3BaZlA0aEFpK29qbXVkU3lZU3plUjZrcUgxaTQ4QmxtM1czcGs9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.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, 01 Apr 2016 22:55:59 -0000 Sunil To advance your point, it may be of advantage, IMHO, if you provide a concr= ete example of what metadata can be shared, and requires interoperability a= mong vendors, in a specific example e.g. FW LB NAT (or choose your favorite= ). Notice some proposed directions in your draft. The thread reads very theoretical and suggests limited value for inter vend= or interaction. Seems like you wish to counter it. A specific example may h= elp bring the conversation down to ground level.=20 Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda Sent: Wednesday, March 30, 2016 11:04 AM To: Joel M. Halpern ; Dave Dolson ; Bottorff, Paul ; sfc@ietf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt Joel, Good point, we are not trying to enumerate all the possible algorithmic beh= aviors. Yes, the proposal addresses both vendor and standardized metadata, where la= tter could be a flavor of former. In below MD-2, ignoring all metadata is a simple implementation, though wit= h limited capabilities. However in all elements the sender and receiver nee= d to co-ordinate metadata in a dynamic and scalable way to take intelligent= actions.=20 Re: #1: Is there a definite limitation in framework for metadata to be same= for all packets ? It should not limit or mandate either way. Re: #2: If there is no need for receiver to understand the semantics across= vendors and products and releases, I do not believe it would be a scalabl= e solution. The code semantics and actions need to be aware by elements for= metadata, without which we might well use only 'reserved' part of header o= r just treat MD-2 as a 'reserved' header itself, IMHO. Again to clarify, the intent and focus is have the ability to understand an= d extend metadata semantics for deployment. The goal is not to enumerate ev= ery possible situation but to provide semantics to customize and support al= gorithmic and other situations as individual case may be. =20 Thanks, Sunil -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, March 30, 2016 10:56 AM To: Dave Dolson ; Sunil Vallamkonda ;= Bottorff, Paul ; sfc@ietf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt In terms of copied information, control tells the SF what to copy. It does= not matter what the granularity is. Given that "flow" does not have a consistent meaning (sometimes it means 5-= tuple, sometimes it means other things) trying to define control instructio= ns at other granularities than packet gets us into algorithmic behaviors. = And I do not think we want to try to enumerate all of the "supported" algor= ithmic behaviors. Similarly, if the information is not the same as that from the prompting pa= cket, we are again finding ourselves getting into algorithmic instructions = (maybe you complement this field, or add 100 to that field, or bounce the t= hird field off the roof.) If we neeed algorithmic behavior, it seems to me that the SF has to know wh= at it is doing. It can not rely on control to tell it. Yes, this places s= ome limits on generality of inserting metadata in produced packets. I woul= d be interested in improvement, but I have not seen one. Yours, Joel On 3/30/16 1:47 PM, Dave Dolson wrote: > Joel, > I'd like to examine this point of yours: >> 2) Metadata to be copied from a prompting packet. This would seem to=20 >> be provided by control as a list of type codes, with no need to=20 >> understand semantics. > > Yes, I think control should provide information about different type code= s. > But we believe there *is* some requirement to understand certain semantic= s. > E.g., > - is the metadata about the packet, about the flow or about the source or= destination end-point? > - is the metadata important enough to add to new packets, or is it option= al? > - is the metadata direction-specific, or can the value be cloned from a r= equest to a response? > > If we don't address different types of semantics, I think we need to=20 > agree there is only one type that works in all cases, or that certain=20 > types should not be used in an opaque manner, or that certain types shoul= d not be used with service functions that need to inject packets. > > > Personally, I think that per-packet opaque metadata is problematic and pr= obably to be avoided. > E.g., a metadata that is checksum of the packet. > If this is opaque to a function, the function may modify the packet or=20 > clone the metadata from one packet to another without being able to updat= e it. > > -Dave > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 30, 2016 1:27 PM > To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding=20 > draft-vallamkonda-sfc-metadata-model-00.txt > > I think you are mixing two concepts. > There is vendor metadata and standardized metadata. > > I do not think anything in the framework I have seen will make vendor=20 > metadata interoperate without coordination between vendors. > > And as far as I can tell, there is nothing needed from the framework=20 > to make standard metadata interoperate. > > That leaves the corner case of experimental or developmental metadata. > Experiments almost always need coordiantion. > > If we are talking about MD-2, it seems to me that SF and SFF will=20 > simply ignore any metadata that they do not understand. In the common=20 > case, SFF will ignore all metadata entirely. > > You have raised the question of what metadata shoudl go on packets=20 > originated by service functions. This seems to be a complex question,=20 > that is not helped by the framework. As far as I can tell, I can see=20 > the following cases: > 1) Metadata about the SF originating the packet. This is common=20 > across all packets, and can be provided to the SF by control means in=20 > an opaque blob. > 2) Metadata to be copied from a prompting packet. This would seem to=20 > be provided by control as a list of type codes, with no need to=20 > understand semantics. > 3) Metadata derived algorithmically from information available to the=20 > service function. This is hard. I do not see how the framework helps=20 > here at all. Is it needed? > > Yours, > Joel > > On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the quest= ions of interpretations. Without a framework for opaque metadata, the ambig= uity between vendor products in service chain makes it incompatible unless = the resolution is hardcoded across of releases and platforms, and vendor sp= ecific information encoded. The flexibility and ability for metadata to be= interoperable and scale are benefits that are much needed for rapid deploy= ments and adoption. >> >> >> Thanks, >> Sunil >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 9:46 AM >> To: Bottorff, Paul ; Dave Dolson=20 >> ; Sunil Vallamkonda ;=20 >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> I don't see why we would specify which metadata is of interest to a spec= ific SF. It is up to the SF what it is interested in, not up to service ch= aining to control that. >> As for preserving forwarding addresses, while I see value in doing so fo= r some transports, I don't see how SFC can mandate that since it is a trans= port dependent behavior. >> >> Yours, >> Joel >> >> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>> Hi Dave and Joel: >>> >>> IMHO the most important thing to standardize is how an SFs couple to a = chain. We are already implying that it would be desirable for SFs to pass b= oth chain forwarding addresses and meta-data from ingress to egress (proxy = forwarding always comes with a cost), however this alone does not provide e= nough guidance for SF network interfacing. We also have issues like how for= warding reversals are indicated at L4-Higher SFs and what meta-data is opaq= ue and what is for SF consumption. >>> >>> Cheers, >>> >>> Paul >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Tuesday, March 29, 2016 7:30 PM >>> To: Joel Halpern Direct ; Sunil=20 >>> Vallamkonda ; Joel M. Halpern ;=20 >>> sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> Joel, >>> Consider a Service Function that needs to inject a packet, such as=20 >>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>> The question arises, what metadata should be put in the NSH header of a= n injected packet? >>> >>> Without some kind of rigorous description of a type of metadata, I don'= t know how to program the Service Function to do it properly. >>> >>> The alternative is to hard-code each service function with the supporte= d types of metadata. >>> This wouldn't allow a function to handle metadata it wasn't programmed = for. >>> >>> >>> So unless there is some easier way of understanding this, there seems t= o be a gap in specifying Service Function behaviour. >>> This is one thing we're trying to figure out. >>> >>> >>> -Dave >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern=20 >>> Direct >>> Sent: Tuesday, March 29, 2016 7:37 PM >>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> It may help to see some use cases. >>> >>> But it sounds, at best, like a specific control plane solution to some = set of problems. >>> Specific control plane solutions, as distinct from descriptions of requ= irements, are out of scope for the working group. >>> >>> Yours, >>> Joel >>> >>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>> The focus is ability for vendor compatibility and extensibility in SF = eco-system without hardcoding and human guessing. >>>> The categorization and rest may or may not be a fallout of this. With= out such a framework, it makes interpretations harder across implementation= s. This would be normal case rather than exception, IMHO. The goal is not t= o standardize any vendor data, but provide a framework to promote vendor co= mpatibility and extensibility across systems. As a clarification we can wa= lk through use cases to understand the benefits. >>>> >>>> >>>> Thank you, >>>> Sunil. >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>> To: Sunil Vallamkonda ; sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> I am sorry. I don't see the value in this. >>>> >>>> Trying to categorize metadata does not seem to help anything. >>>> Trying to standardize a descriptive langauge for metadata seems to imp= ly something that can consume such a language. I can not imagine anything = that can usefully consume this. >>>> >>>> I can understand how a human being would use a registry (which we have= to have) to know what T codes are defined, and where to find descriptions = of their meaning. >>>> But that meaning description is going to be in English. A file that t= ells me that value 17 is the Dragaeran Corporate type code for Houses does = not tell me anything. >>>> >>>> The only corner case for the YANG is if my system has some understandi= ng of the semantics of various pieces of metadata, but wants to know what c= ode is associated with a particular usage. >>>> The problem is that we have mutliple different protocols that may want= to provide that information, so all that SFC can define is that the contro= l system must include a way to provide that information. >>>> >>>> Given that much of the metadata is not vendor specific, the structure = seems very odd. >>>> ANd it seems likely that any vendor specific metadata will need the se= mantics to already be known, since we can not standardize that. >>>> >>>> Yours in puzzlement, >>>> Joel >>>> >>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>> Metadata is a vital element of SFC and thus NFV. >>>>> >>>>> Additionally, interoperability and vendor support challenges need=20 >>>>> to be addressed in a scalable and adaptable way for rapid deployment. >>>>> >>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>> which proposes terminology for talking about metadata in an extensibl= e fashion. >>>>> >>>>> If there are no objections, we'd like to start pushing this=20 >>>>> terminology into drafts about NSH and the control-plane. >>>>> >>>>> Please let us know what you think. >>>>> >>>>> Thank you, >>>>> >>>>> Sunil. >>>>> >>>>> =3D=3D >>>>> >>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> has been successfully submitted by Sunil Vallamkonda and posted to=20 >>>>> the IETF repository. >>>>> >>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>> >>>>> Revision: 00 >>>>> >>>>> Title: Information Model for SFC Metadata >>>>> >>>>> Document date: 2016-01-28 >>>>> >>>>> Group: Individual Submission >>>>> >>>>> Pages: 9 >>>>> >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat >>>>> a- >>>>> m >>>>> o >>>>> del-00.txt >>>>> >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo >>>>> de >>>>> l >>>>> / >>>>> >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0 >>>>> 0 >>>>> >>>>> Abstract: >>>>> >>>>> Various types of metadata are applicable to Service=20 >>>>> Function Chaining >>>>> >>>>> (SFC). A Service Function (SF) needs information about=20 >>>>> all metadata >>>>> >>>>> passing through it. The metadata could be used to convey >>>>> >>>>> preprocessing information about the packet by other nodes=20 >>>>> and an SF >>>>> >>>>> can attach post processing information as deemed necessary. >>>>> >>>>> The purpose of this document is to rigorously define the=20 >>>>> classes of >>>>> >>>>> metadata and provide a vocabulary and information model for m= etadata. >>>>> >>>>> Each item of metadata refers to a subject, examples of=20 >>>>> which are IP >>>>> >>>>> endpoint, flow or individual packet. >>>>> >>>>> 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=20 >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Apr 3 16:19:31 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 ADEB212D17E for ; Sun, 3 Apr 2016 16:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 73oZKxfLrocE for ; Sun, 3 Apr 2016 16:19:26 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5742C12D0DE for ; Sun, 3 Apr 2016 16:19:26 -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.0195.001; Sun, 3 Apr 2016 19:19:25 -0400 From: Dave Dolson To: "Elzur, Uri" , Sunil Vallamkonda , "Joel M. Halpern" , "Bottorff, Paul" , "sfc@ietf.org" Thread-Topic: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.txt Thread-Index: AdGJ9+sCFkM+vCX4TPSmWI6TIKwl2QAOw8gAAAB1HwAAACPDAAAD636gAB+Hd4AAAH6DAAAAtJoAAAC7dQAACBKFAP//x2sAgAACVwCAA3Y7gP/9HGug Date: Sun, 3 Apr 2016 23:19:23 +0000 Message-ID: References: <56FB0D84.9050602@joelhalpern.com> <56FB1186.7070807@joelhalpern.com> <56FC02BC.8060203@joelhalpern.com> <880ca7e35d334ab48898aa4c78984ac1@SEAEXCHMBX06.olympus.F5Net.com> <56FC0C62.1050200@joelhalpern.com> <56FC1318.6070703@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B8995858932536C@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [190.111.246.156] 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] SFC Metadata: Comments regarding draft-vallamkonda-sfc-metadata-model-00.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: Sun, 03 Apr 2016 23:19:29 -0000 On a related note, draft-penno-sfc-packet discusses how to inject packets, with a section on metadata. I have proposed the following replacement section 7, adding these specific classes of metadata, with examples: 1- Service-Path-Invariant Metadata 2- Service-Path-Default Metadata 3- Bidirectional Clonable Metadata 4- Unidirectional Clonable Metadata-=20 5- Service-Function-Mastered Metadata 6- Metadata from Reclassification I believe draft-vallamkonda-sfc-metadata-model is useful in modeling metadata. Proposal for draft-penno-sfc-packet: ----------------------------- 7. Metadata A crucial consideration when generating a packet is which metadata should be included in the context headers. In some scenarios if the metadata is not present the packet will not reach its intended destination. Although one could think of many different ways to convey this information, we believe the solution should be simple and require little or no new Service Function functionality. We assume that a Service Function normally needs to know the semantics of the context headers in order to perform its functions. But clearly knowing the semantics of the metadata is not enough. The issue is that although the SF knows the semantics of the metadata when it receives a packet, it might not be able to generate or retrieve the correct metadata values to insert in the context headers when generating a packet. It is usually the classifier that inserts the initial metadata in the context headers. 7.1. Service-Path-Invariant Metadata =09 In order to solve this problem we propose the notion of service-path- invariant metadata. This is metadata that is the same for all packets traversing a certain path. For example, if all packets exiting a service-path need to be routed to a certain VPN, the VPN id would be a path-invariant metadata. To implement this, the controller needs to configure appropriate fixed values of the metadata present in the context headers for each path identifier in each Service Function that needs to inject packets. The Service Function must store this information so that when the Service Function generates a packet it can insert the minimum required metadata for a packet to reach its destination. A disadvantage to path-invariant metadata is that it is a type of metadata that adds no information beyond the information available in the path identifier itself. The corollary is that if different metadata is required, a different service paths must be created. 7.2. Service-Path-Default Metadata We also propose the notion of service-path-default metadata. This is metadata that could vary for different packets on a path but has a default value acceptable for any packet injected onto a certain path. For example, metadata might indicate a quality-of-service (QoS) treatment, and an operator considers it acceptable for injected packets to have a default QoS treatment. It might also be considered acceptable to not send a particular type of metadata. To implement this, the controller configures appropriate default metadata values for each path identifier in Service Functions that need to inject packets. The controller may also indicate a particular type may be omitted. The Service Function must store this information so that it can insert the minimum required metadata for a packet to reach its destination. The disadvantage of this approach is that it relies on the assumption that there is a meaningful default metadata value, which may not exist. 7.3. Bidirectional Clonable Metadata Some types of metadata may use values applicable to both directions of traffic. An example is routing domain, for which an identifier indicates a private network such that the value is the same for both directions of traffic and may be copied from one packet to another. To implement this, the controller must indicate to each Service Function that a particular metadata type is bidirectional-clonable. The Service Function can therefore clone the metadata value from one packet to a new packet that it creates, even in the reverse direction. For this type, it is also considered safe to save a copy of metadata for the transport flow. (E.g., to retransmit a TCP packet using metadata cloned from another TCP packet of the same connection.) Note that the Service Function need not know the meaning of the metadata; it just needs to know it is safe to clone in this manner. 7.4. Unidirectional Clonable Metadata Some types of metadata may use values applicable to only one direction of traffic, but a value may be cloned from one packet to another in the same direction. An example is a destination identifier, in which meatadata indicates a network egress point. Another example is metadata indicating a property of either the source or destination end-point of the packet. To implement this, the controller must indicate to each Service Function that a particular metadata type is unidirectional-clonable. A transport-layer-stateful Service Function can therefore save away metadata values that it has witnessed. An injected packet can therefore be assigned a clone of metadata taken from an earlier packet going in the same direction. For example, a Service Function can send a TCP packet using metadata cloned from another TCP packet of the same connection and direction. Note that the Service Function need not know the meaning of the metadata; it just needs to know it is safe to clone in this manner. A disadvantage of unidirectional clonable metadata is that a device cannot respond to a packet unless it has previously witnessed a packet for the same connection in the opposite direction. For example, a firewall cannot respond to the first packet of a connection (since both directions have not been witnessed). However, having seen a full hand-shake, a cache or optimizing proxy can inject or retransmit packets. 7.5. Service-Function-Mastered Metadata The easiest case to reason about is a type of metadata for which the Service Function can provide the appropriate values: specifically the metadata that it would be responsible for inserting for all packets as part of packet processing. We can assume this is configured by Service-Function-Specific methods. 7.6. Metadata from Reclassification Finally, if the packet needs crucial metadata values that cannot be supplied by the methods above then a reclassification is needed. This reclassification would need to be done by the classifier that would normally process packets in the reverse path or a SFF that had the same rules and capabilities. Ideally the first SFF that processes the generated packet. -----Original Message----- From: Elzur, Uri [mailto:uri.elzur@intel.com]=20 Sent: Friday, April 01, 2016 7:56 PM To: Sunil Vallamkonda; Joel M. Halpern; Dave Dolson; Bottorff, Paul; sfc@ie= tf.org Subject: RE: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt Sunil To advance your point, it may be of advantage, IMHO, if you provide a concr= ete example of what metadata can be shared, and requires interoperability a= mong vendors, in a specific example e.g. FW LB NAT (or choose your favorite= ). Notice some proposed directions in your draft. The thread reads very theoretical and suggests limited value for inter vend= or interaction. Seems like you wish to counter it. A specific example may h= elp bring the conversation down to ground level.=20 Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sunil Vallamkonda Sent: Wednesday, March 30, 2016 11:04 AM To: Joel M. Halpern ; Dave Dolson ; Bottorff, Paul ; sfc@ietf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt Joel, Good point, we are not trying to enumerate all the possible algorithmic beh= aviors. Yes, the proposal addresses both vendor and standardized metadata, where la= tter could be a flavor of former. In below MD-2, ignoring all metadata is a simple implementation, though wit= h limited capabilities. However in all elements the sender and receiver nee= d to co-ordinate metadata in a dynamic and scalable way to take intelligent= actions.=20 Re: #1: Is there a definite limitation in framework for metadata to be same= for all packets ? It should not limit or mandate either way. Re: #2: If there is no need for receiver to understand the semantics across= vendors and products and releases, I do not believe it would be a scalabl= e solution. The code semantics and actions need to be aware by elements for= metadata, without which we might well use only 'reserved' part of header o= r just treat MD-2 as a 'reserved' header itself, IMHO. Again to clarify, the intent and focus is have the ability to understand an= d extend metadata semantics for deployment. The goal is not to enumerate ev= ery possible situation but to provide semantics to customize and support al= gorithmic and other situations as individual case may be. =20 Thanks, Sunil -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, March 30, 2016 10:56 AM To: Dave Dolson ; Sunil Vallamkonda ;= Bottorff, Paul ; sfc@ietf.org Subject: Re: [sfc] SFC Metadata: Comments regarding draft-vallamkonda-sfc-m= etadata-model-00.txt In terms of copied information, control tells the SF what to copy. It does= not matter what the granularity is. Given that "flow" does not have a consistent meaning (sometimes it means 5-= tuple, sometimes it means other things) trying to define control instructio= ns at other granularities than packet gets us into algorithmic behaviors. = And I do not think we want to try to enumerate all of the "supported" algor= ithmic behaviors. Similarly, if the information is not the same as that from the prompting pa= cket, we are again finding ourselves getting into algorithmic instructions = (maybe you complement this field, or add 100 to that field, or bounce the t= hird field off the roof.) If we neeed algorithmic behavior, it seems to me that the SF has to know wh= at it is doing. It can not rely on control to tell it. Yes, this places s= ome limits on generality of inserting metadata in produced packets. I woul= d be interested in improvement, but I have not seen one. Yours, Joel On 3/30/16 1:47 PM, Dave Dolson wrote: > Joel, > I'd like to examine this point of yours: >> 2) Metadata to be copied from a prompting packet. This would seem to=20 >> be provided by control as a list of type codes, with no need to=20 >> understand semantics. > > Yes, I think control should provide information about different type code= s. > But we believe there *is* some requirement to understand certain semantic= s. > E.g., > - is the metadata about the packet, about the flow or about the source or= destination end-point? > - is the metadata important enough to add to new packets, or is it option= al? > - is the metadata direction-specific, or can the value be cloned from a r= equest to a response? > > If we don't address different types of semantics, I think we need to=20 > agree there is only one type that works in all cases, or that certain=20 > types should not be used in an opaque manner, or that certain types shoul= d not be used with service functions that need to inject packets. > > > Personally, I think that per-packet opaque metadata is problematic and pr= obably to be avoided. > E.g., a metadata that is checksum of the packet. > If this is opaque to a function, the function may modify the packet or=20 > clone the metadata from one packet to another without being able to updat= e it. > > -Dave > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, March 30, 2016 1:27 PM > To: Sunil Vallamkonda; Bottorff, Paul; Dave Dolson; sfc@ietf.org > Subject: Re: [sfc] SFC Metadata: Comments regarding=20 > draft-vallamkonda-sfc-metadata-model-00.txt > > I think you are mixing two concepts. > There is vendor metadata and standardized metadata. > > I do not think anything in the framework I have seen will make vendor=20 > metadata interoperate without coordination between vendors. > > And as far as I can tell, there is nothing needed from the framework=20 > to make standard metadata interoperate. > > That leaves the corner case of experimental or developmental metadata. > Experiments almost always need coordiantion. > > If we are talking about MD-2, it seems to me that SF and SFF will=20 > simply ignore any metadata that they do not understand. In the common=20 > case, SFF will ignore all metadata entirely. > > You have raised the question of what metadata shoudl go on packets=20 > originated by service functions. This seems to be a complex question,=20 > that is not helped by the framework. As far as I can tell, I can see=20 > the following cases: > 1) Metadata about the SF originating the packet. This is common=20 > across all packets, and can be provided to the SF by control means in=20 > an opaque blob. > 2) Metadata to be copied from a prompting packet. This would seem to=20 > be provided by control as a list of type codes, with no need to=20 > understand semantics. > 3) Metadata derived algorithmically from information available to the=20 > service function. This is hard. I do not see how the framework helps=20 > here at all. Is it needed? > > Yours, > Joel > > On 3/30/16 1:06 PM, Sunil Vallamkonda wrote: >> When metadata is exchanged between SFFs, SFs, SFCs, it begs to the quest= ions of interpretations. Without a framework for opaque metadata, the ambig= uity between vendor products in service chain makes it incompatible unless = the resolution is hardcoded across of releases and platforms, and vendor sp= ecific information encoded. The flexibility and ability for metadata to be= interoperable and scale are benefits that are much needed for rapid deploy= ments and adoption. >> >> >> Thanks, >> Sunil >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 30, 2016 9:46 AM >> To: Bottorff, Paul ; Dave Dolson=20 >> ; Sunil Vallamkonda ;=20 >> sfc@ietf.org >> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >> draft-vallamkonda-sfc-metadata-model-00.txt >> >> I don't see why we would specify which metadata is of interest to a spec= ific SF. It is up to the SF what it is interested in, not up to service ch= aining to control that. >> As for preserving forwarding addresses, while I see value in doing so fo= r some transports, I don't see how SFC can mandate that since it is a trans= port dependent behavior. >> >> Yours, >> Joel >> >> On 3/30/16 12:31 PM, Bottorff, Paul wrote: >>> Hi Dave and Joel: >>> >>> IMHO the most important thing to standardize is how an SFs couple to a = chain. We are already implying that it would be desirable for SFs to pass b= oth chain forwarding addresses and meta-data from ingress to egress (proxy = forwarding always comes with a cost), however this alone does not provide e= nough guidance for SF network interfacing. We also have issues like how for= warding reversals are indicated at L4-Higher SFs and what meta-data is opaq= ue and what is for SF consumption. >>> >>> Cheers, >>> >>> Paul >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Tuesday, March 29, 2016 7:30 PM >>> To: Joel Halpern Direct ; Sunil=20 >>> Vallamkonda ; Joel M. Halpern ;=20 >>> sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> Joel, >>> Consider a Service Function that needs to inject a packet, such as=20 >>> articulated in https://tools.ietf.org/html/draft-penno-sfc-packet-02 >>> The question arises, what metadata should be put in the NSH header of a= n injected packet? >>> >>> Without some kind of rigorous description of a type of metadata, I don'= t know how to program the Service Function to do it properly. >>> >>> The alternative is to hard-code each service function with the supporte= d types of metadata. >>> This wouldn't allow a function to handle metadata it wasn't programmed = for. >>> >>> >>> So unless there is some easier way of understanding this, there seems t= o be a gap in specifying Service Function behaviour. >>> This is one thing we're trying to figure out. >>> >>> >>> -Dave >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern=20 >>> Direct >>> Sent: Tuesday, March 29, 2016 7:37 PM >>> To: Sunil Vallamkonda; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>> draft-vallamkonda-sfc-metadata-model-00.txt >>> >>> It may help to see some use cases. >>> >>> But it sounds, at best, like a specific control plane solution to some = set of problems. >>> Specific control plane solutions, as distinct from descriptions of requ= irements, are out of scope for the working group. >>> >>> Yours, >>> Joel >>> >>> On 3/29/16 7:32 PM, Sunil Vallamkonda wrote: >>>> The focus is ability for vendor compatibility and extensibility in SF = eco-system without hardcoding and human guessing. >>>> The categorization and rest may or may not be a fallout of this. With= out such a framework, it makes interpretations harder across implementation= s. This would be normal case rather than exception, IMHO. The goal is not t= o standardize any vendor data, but provide a framework to promote vendor co= mpatibility and extensibility across systems. As a clarification we can wa= lk through use cases to understand the benefits. >>>> >>>> >>>> Thank you, >>>> Sunil. >>>> >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Tuesday, March 29, 2016 4:20 PM >>>> To: Sunil Vallamkonda ; sfc@ietf.org >>>> Subject: Re: [sfc] SFC Metadata: Comments regarding=20 >>>> draft-vallamkonda-sfc-metadata-model-00.txt >>>> >>>> I am sorry. I don't see the value in this. >>>> >>>> Trying to categorize metadata does not seem to help anything. >>>> Trying to standardize a descriptive langauge for metadata seems to imp= ly something that can consume such a language. I can not imagine anything = that can usefully consume this. >>>> >>>> I can understand how a human being would use a registry (which we have= to have) to know what T codes are defined, and where to find descriptions = of their meaning. >>>> But that meaning description is going to be in English. A file that t= ells me that value 17 is the Dragaeran Corporate type code for Houses does = not tell me anything. >>>> >>>> The only corner case for the YANG is if my system has some understandi= ng of the semantics of various pieces of metadata, but wants to know what c= ode is associated with a particular usage. >>>> The problem is that we have mutliple different protocols that may want= to provide that information, so all that SFC can define is that the contro= l system must include a way to provide that information. >>>> >>>> Given that much of the metadata is not vendor specific, the structure = seems very odd. >>>> ANd it seems likely that any vendor specific metadata will need the se= mantics to already be known, since we can not standardize that. >>>> >>>> Yours in puzzlement, >>>> Joel >>>> >>>> On 3/29/16 6:33 PM, Sunil Vallamkonda wrote: >>>>> Metadata is a vital element of SFC and thus NFV. >>>>> >>>>> Additionally, interoperability and vendor support challenges need=20 >>>>> to be addressed in a scalable and adaptable way for rapid deployment. >>>>> >>>>> In January we uploaded draft-vallamkonda-sfc-metadata-model-00, >>>>> which proposes terminology for talking about metadata in an extensibl= e fashion. >>>>> >>>>> If there are no objections, we'd like to start pushing this=20 >>>>> terminology into drafts about NSH and the control-plane. >>>>> >>>>> Please let us know what you think. >>>>> >>>>> Thank you, >>>>> >>>>> Sunil. >>>>> >>>>> =3D=3D >>>>> >>>>> A new version of I-D, draft-vallamkonda-sfc-metadata-model-00.txt >>>>> >>>>> has been successfully submitted by Sunil Vallamkonda and posted to=20 >>>>> the IETF repository. >>>>> >>>>> Name: draft-vallamkonda-sfc-metadata-model >>>>> >>>>> Revision: 00 >>>>> >>>>> Title: Information Model for SFC Metadata >>>>> >>>>> Document date: 2016-01-28 >>>>> >>>>> Group: Individual Submission >>>>> >>>>> Pages: 9 >>>>> >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-vallamkonda-sfc-metadat >>>>> a- >>>>> m >>>>> o >>>>> del-00.txt >>>>> >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-vallamkonda-sfc-metadata-mo >>>>> de >>>>> l >>>>> / >>>>> >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-0 >>>>> 0 >>>>> >>>>> Abstract: >>>>> >>>>> Various types of metadata are applicable to Service=20 >>>>> Function Chaining >>>>> >>>>> (SFC). A Service Function (SF) needs information about=20 >>>>> all metadata >>>>> >>>>> passing through it. The metadata could be used to convey >>>>> >>>>> preprocessing information about the packet by other nodes=20 >>>>> and an SF >>>>> >>>>> can attach post processing information as deemed necessary. >>>>> >>>>> The purpose of this document is to rigorously define the=20 >>>>> classes of >>>>> >>>>> metadata and provide a vocabulary and information model for m= etadata. >>>>> >>>>> Each item of metadata refers to a subject, examples of=20 >>>>> which are IP >>>>> >>>>> endpoint, flow or individual packet. >>>>> >>>>> 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=20 >>>>> tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 4 08:00: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 7BD8D12D7AA for ; Mon, 4 Apr 2016 07:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 NpPaP11vO0gD for ; Mon, 4 Apr 2016 07:59:46 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA16B12D7C9 for ; Mon, 4 Apr 2016 07:58:47 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-c7-57028101ba1a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 17.DD.22441.10182075; Mon, 4 Apr 2016 16:58:09 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 10:58:45 -0400 From: Daniel Migault To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-mglt-sfc-security-environment-req-01.txt Thread-Index: AQHRjnsqrfEUvmWtq06JyrlQ7ydOJJ952XBw Date: Mon, 4 Apr 2016 14:58:43 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11223EA52@eusaamb107.ericsson.se> References: <20160404140616.15654.90886.idtracker@ietfa.amsl.com> In-Reply-To: <20160404140616.15654.90886.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C11223EA52eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPoC5jI1O4walb5hYXO+eyWTx5sJXd gcnjx7/vbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4u3YtS8Gpgoq7a/kaGI/kdjFyckgImEgs bu9mhLDFJC7cW8/WxcjFISRwlFGia1Y/C4SzjFHi6PdGdpAqNgEjibZD/WC2iICixLmXE1hA bGYBd4mN/2+xgdjCAlESd9rWsUHUREu8OdTJBGEbSaz+eQwsziKgIjHl4k6wXl4BX4kf02aD xYUEHCXmzpwDVs8p4CTxcPYdsDgj0HXfT61hgtglLnHryXwmiKsFJJbsOc8MYYtKvHz8jxXC VpL4+Hs+O0R9vkTH189QuwQlTs58wjKBUXQWklGzkJTNQlI2i5EDKK4psX6XPkSJosSU7ofs ELaGROucuezI4gsY2VcxcpQWF+TkphsZbmIExtQxCTbHHYx7ez0PMQpwMCrx8C44xRguxJpY VlyZe4hRgoNZSYT3Ux1TuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe78h/YUIC6YklqdmpqQWp RTBZJg5OqQZG9ZlswnM+9KqdlbLqSP7DJ3fA44PDsmex3oFcAW/3m85g1I+8eubf0T1SJqaP A25v91m0hWfHsdzAKNerFq2ubJ+PTrs2pa1r1odJKmvPFIleNLQIjX5T+vJXwBl75qwv5y1F 3pxd/Ouef+ycNWvCHzZd+NFzcuWv5VsZCqIzOlwbM0p8QiQ0lViKMxINtZiLihMBtQSylqUC AAA= Archived-At: Cc: "sfc-sec-team@external.cisco.com" Subject: [sfc] FW: New Version Notification for draft-mglt-sfc-security-environment-req-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: Mon, 04 Apr 2016 14:59:50 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C11223EA52eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpPdXIgZGVlcCBhcG9sb2dpZXMgZm9yIHBvc3RpbmcgdGhpcyBuZXcgdmVyc2lv biBzbyBsYXRlLiBXZSBhZGRyZXNzZWQgcHJldHR5IHNob3J0bHkgdGhlIGNvbW1lbnRzIGFuZCBm ZWVkIGJhY2sgd2UgcmVjZWl2ZWQgZnJvbSB0aGUgbGFzdCBJRVRGLCBidXQgd2FudGVkIHRvIGJl IG1vcmUgZm9jdXNlZCBvbiB0aGUg4oCcTlNIIHNlY3VyaXR5IHJlcXVpcmVtZW50c+KAnSBmb3Ig dGhhdCBtZWV0aW5nIFsyXS4NCg0KUGxlYXNlIHNlZSB0aGUgY2hhbmdlcyB0aGF0IGhhdmUgYmVl biBjb25zaWRlcmVkIGhlcmU8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LW1nbHQtc2ZjLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcS0wMT4gWzFdLg0KDQoNCg0KQlIsDQoN ClRoZSBkZXNpZ24gVGVhbQ0KDQoNCg0KWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1tZ2x0LXNmYy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXEtMDENCg0KWzJdIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXNmYy1uc2gtc2VjdXJp dHktcmVxLw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6 IE1vbmRheSwgQXByaWwgMDQsIDIwMTYgMTE6MDYgQU0NClRvOiBDYXJsb3MgUGlnbmF0YXJvOyBE YW5pZWwgTWlnYXVsdDsgVGlydW1hbGVzd2FyIFJlZGR5OyBDaHJpc3RvcGhlciBJbmFjaW8NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWdsdC1zZmMtc2VjdXJp dHktZW52aXJvbm1lbnQtcmVxLTAxLnR4dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1tZ2x0LXNmYy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXEtMDEudHh0DQoNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFuaWVsIE1pZ2F1bHQgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgICAgICAgICBkcmFm dC1tZ2x0LXNmYy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXENCg0KUmV2aXNpb246ICAgICAgICAg ICAgICAwMQ0KDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgU0ZDIGVudmlyb25tZW50IFNl Y3VyaXR5IHJlcXVpcmVtZW50cw0KDQpEb2N1bWVudCBkYXRlOiAgICAgICAgICAgICAgIDIwMTYt MDQtMDQNCg0KR3JvdXA6ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoN ClBhZ2VzOiAgICAgICAgICAgICAgICAgICAyMQ0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1nbHQtc2ZjLXNlY3VyaXR5LWVudmly b25tZW50LXJlcS0wMS50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtc2ZjLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcS8NCg0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZ2x0LXNm Yy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXEtMDENCg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tZ2x0LXNmYy1zZWN1cml0eS1lbnZpcm9u bWVudC1yZXEtMDENCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVz IGVudmlyb25tZW50IHNlY3VyaXR5IHJlcXVpcmVtZW50cyBmb3IgdGhlIFNGQw0KDQogICBhcmNo aXRlY3R1cmUuICBFbnZpcm9ubWVudCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIGluZGVwZW5k ZW50IG9mDQoNCiAgIHRoZSBwcm90b2NvbHMgdXNlZCBmb3IgU0ZDIC0gc3VjaCBhcyBOU0ggZm9y IGV4YW1wbGUuICBBcyBhIHJlc3VsdCwNCg0KICAgdGhlIHJlcXVpcmVtZW50cyBwcm92aWRlZCBp biB0aGlzIGRvY3VtZW50IGFyZSBpbnRlbmRlZCB0byBwcm92aWRlDQoNCiAgIGdvb2Qgc2VjdXJp dHkgcHJhY3RpY2VzIHNvIFNGQyBjYW4gYmUgc2VjdXJlbHkgZGVwbG95ZWQgYW5kIG9wZXJhdGVk Lg0KDQogICBUaGVzZSBzZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIGRlc2lnbmF0ZWQgYXMgZW52 aXJvbm1lbnQgc2VjdXJpdHkNCg0KICAgcmVxdWlyZW1lbnRzIGFzIG9wcG9zZWQgdG8gdGhlIHBy b3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_2DD56D786E600F45AC6BDE7DA4E8A8C11223EA52eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1z b1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T3VyIGRlZXAg YXBvbG9naWVzIGZvciBwb3N0aW5nIHRoaXMgbmV3IHZlcnNpb24gc28gbGF0ZS4gV2UgYWRkcmVz c2VkIHByZXR0eSBzaG9ydGx5IHRoZSBjb21tZW50cyBhbmQgZmVlZCBiYWNrIHdlIHJlY2VpdmVk IGZyb20gdGhlIGxhc3QgSUVURiwgYnV0IHdhbnRlZCB0byBiZSBtb3JlIGZvY3VzZWQgb24gdGhl IOKAnE5TSCBzZWN1cml0eSByZXF1aXJlbWVudHPigJ0gZm9yIHRoYXQgbWVldGluZyBbMl0uDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFzZSBzZWUgdGhlIGNo YW5nZXMgdGhhdCBoYXZlIGJlZW4gY29uc2lkZXJlZCA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWdsdC1zZmMtc2VjdXJpdHktZW52aXJvbm1lbnQtcmVx LTAxIj4NCmhlcmU8L2E+IFsxXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QlIsIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGRlc2lnbiBUZWFtPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlsxXSBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtbWdsdC1zZmMtc2VjdXJpdHktZW52aXJvbm1lbnQtcmVxLTAxPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5bMl0gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktc2ZjLW5zaC1zZWN1cml0eS1yZXEvPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXSA8YnI+DQpTZW50OiBNb25kYXksIEFwcmlsIDA0LCAyMDE2IDExOjA2IEFNPGJyPg0KVG86 IENhcmxvcyBQaWduYXRhcm87IERhbmllbCBNaWdhdWx0OyBUaXJ1bWFsZXN3YXIgUmVkZHk7IENo cmlzdG9waGVyIEluYWNpbzxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbWdsdC1zZmMtc2VjdXJpdHktZW52aXJvbm1lbnQtcmVxLTAxLnR4dDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWdsdC1zZmMtc2VjdXJpdHktZW52aXJvbm1l bnQtcmVxLTAxLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW5pZWwgTWlnYXVsdCBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5h bWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LW1n bHQtc2ZjLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAxPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0ZDIGVu dmlyb25tZW50IFNlY3VyaXR5IHJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MjAxNi0wNC0wNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R3JvdXA6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwg U3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFnZXM6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIxPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5VUkw6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tZ2x0LXNmYy1z ZWN1cml0eS1lbnZpcm9ubWVudC1yZXEtMDEudHh0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbWdsdC1zZmMtc2VjdXJpdHktZW52aXJvbm1lbnQtcmVxLTAxLnR4dDwv c3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtc2ZjLXNlY3VyaXR5 LWVudmlyb25tZW50LXJlcS8iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1n bHQtc2ZjLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcS88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tZ2x0LXNmYy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXEtMDEiPg0KPHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1tZ2x0LXNmYy1zZWN1cml0eS1lbnZpcm9ubWVudC1yZXEtMDE8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGlmZjombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1nbHQtc2ZjLXNl Y3VyaXR5LWVudmlyb25tZW50LXJlcS0wMSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LW1nbHQtc2ZjLXNlY3VyaXR5LWVudmlyb25tZW50LXJlcS0wMTwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg ZW52aXJvbm1lbnQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciB0aGUgU0ZDPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXJjaGl0ZWN0dXJlLiZu YnNwOyBFbnZpcm9ubWVudCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXJlIGluZGVwZW5kZW50IG9m PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhl IHByb3RvY29scyB1c2VkIGZvciBTRkMgLSBzdWNoIGFzIE5TSCBmb3IgZXhhbXBsZS4mbmJzcDsg QXMgYSByZXN1bHQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgdGhlIHJlcXVpcmVtZW50cyBwcm92aWRlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBp bnRlbmRlZCB0byBwcm92aWRlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgZ29vZCBzZWN1cml0eSBwcmFjdGljZXMgc28gU0ZDIGNhbiBiZSBzZWN1 cmVseSBkZXBsb3llZCBhbmQgb3BlcmF0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhlc2Ugc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFyZSBk ZXNpZ25hdGVkIGFzIGVudmlyb25tZW50IHNlY3VyaXR5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVxdWlyZW1lbnRzIGFzIG9wcG9zZWQgdG8g dGhlIHByb3RvY29sIHNlY3VyaXR5IHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_2DD56D786E600F45AC6BDE7DA4E8A8C11223EA52eusaamb107erics_-- From nobody Mon Apr 4 13:09: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 2675D12D84B; Mon, 4 Apr 2016 13:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 tvIqW5OuejUy; Mon, 4 Apr 2016 13:09:08 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECF212D867; Mon, 4 Apr 2016 13:09:08 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-4e-5702c9bdda88 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id EB.E0.22441.DB9C2075; Mon, 4 Apr 2016 22:08:30 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 16:09:06 -0400 From: Gregory Mirsky To: "BIER (bier@ietf.org)" , "sfc@ietf.org" , "nvo3@ietf.org" , "rtg-ooam-dt@ietf.org" , "rtgwg@ietf.org" Thread-Topic: Comments to OOAM Requirements draft from Ron Bonica Thread-Index: AdGOoAAttrV3Hsn3QLugH0bP01WoGA== Date: Mon, 4 Apr 2016 20:09:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3CB8F@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/mixed; boundary="_004_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUyuXRPuO6+k0zhBjsWcVksnbGHyeLpfEmL A98dLP617mW1uPDmN7PFkwdb2R3YPJYs+cnkcb3pKnsAUxSXTUpqTmZZapG+XQJXRtvmdpaC niamiq0vz7I0MJ74wdjFyMkhIWAi0Xz+DAuELSZx4d56ti5GLg4hgaOMEt87FzBBOMsYJf5+ 2sMEUsUmYCTxYmMPO0hCROAAo8SKvavYQBLMAvoSb5t/go0SFrCRuLW6FaxBRMBRYvK2s4wQ tp7Ej8sv2EFsFgEViS1n3wLZHBy8Ar4SK76ng4QZga74fmoNE8RIcYlbT+YzQVwnIvHw4mk2 CFtU4uXjf6wQtpLEnNfXmCHqMyWmdD8Dq+EVEJQ4OfMJywRG4VlIRs1CUjYLSRlEPF/i9oLV zBC2jsSC3Z/YIGxtiWULXzPD2GcOPGZCFecAssMk5myMhAh7SLy+8J9xFjCEmAUuM0q8//ET ao4i0N6H7AsYeVYxcpQWF+TkphsZbmIExvExCTbHHYx7ez0PMQpwMCrx8C44xRguxJpYVlyZ e4hRBaj10YbVFxilWPLy81KVRHh3H2UKF+JNSaysSi3Kjy8qzUktPsQozcGiJM7rHfkvTEgg PbEkNTs1tSC1CCbLxMEp1cBoEiPA/jm4Xz321Meu2p06d94w39988UqWau6/S7pzHRmEPdSn KRq5SV+YeSt4vYxdveODhJxjDbtFdxSm/5ZsMXlQyrWh5cAi3kWHl1rH1PUe6JqfftF66c10 9aS1Ozeqeh08dojH0+lr/UunmU1RZ/vk50Rsf+V/5tz07XJyDckqKwxXC21RYinOSDTUYi4q TgQAy/ZBD+sCAAA= Archived-At: Cc: "rbonica@juniper.net" Subject: [sfc] Comments to OOAM Requirements draft from Ron Bonica 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: Mon, 04 Apr 2016 20:09:12 -0000 --_004_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_ Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_" --_000_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> = tag. The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Net= works: Gap Analysis. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

Ron reviewed the Overlay OAM Requirements draft and shared his comments under RB> tag= . The attached copy has my responses in under GIM> tag as well. We invit= e members of BIER, NVO3, SCC and RTG WGs to join in the discussion. Appreci= ate you review, comments on OOAM Requirements draft and OAM for Overlay Networks: Gap Analysis.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_-- --_004_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_ Content-Type: text/plain; name="draft-ooamdt-rtgwg-ooam-requirement-00-ron-greg.txt" Content-Description: draft-ooamdt-rtgwg-ooam-requirement-00-ron-greg.txt Content-Disposition: attachment; filename="draft-ooamdt-rtgwg-ooam-requirement-00-ron-greg.txt"; size=21115; creation-date="Sun, 03 Apr 2016 16:24:27 GMT"; modification-date="Sun, 03 Apr 2016 16:38:57 GMT" Content-Transfer-Encoding: base64 DQoNCg0KDQpydGd3ZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTi4gS3VtYXINCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEMuIFBpZ25hdGFybw0KSW50ZW5kZWQgc3RhdHVz OiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEQuIEt1bWFy DQpFeHBpcmVzOiBTZXB0ZW1iZXIgMjIsIDIwMTYgICAgICAgICAgICAgICAgICAgICAgICAgIENp c2NvIFN5c3RlbXMsIEluYy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEcuIE1pcnNreQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE0uIENoZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSHVhd2VpIFRlY2hub2xvZ2llcw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEUuIE5vcmRtYXJrDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcmlzdGEgTmV0 d29ya3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUy4gUGFsbGFnYXR0aQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVyIE5ldHdvcmtzDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gTW96ZXMN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWVsbGFub3gg VGVjaG5vbG9naWVzIEx0ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIxLCAyMDE2DQoNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgT3ZlcmxheSBPQU0gUmVxdWlyZW1lbnRzDQogICAgICAgICAgICAgICAgIGRyYWZ0LW9v YW1kdC1ydGd3Zy1vb2FtLXJlcXVpcmVtZW50LTAwDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGEgbGlzdCBvZiBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cyBmb3INCiAg IE9wZXJhdGlvbnMgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIChPQU0pIGluIHZhcmlv dXMgT3ZlcmxheQ0KICAgYW5kIFNlcnZpY2UgbmV0d29ya3MgbGlrZSBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluaW5nIChTRkMpLCBCaXQgSW5kZXgNCiAgIEV4cGxpY2l0IFJlcGxpY2F0aW9uIChCSUVS KSwgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBvdmVyIExheWVyIDMNCiAgIChOVk8zKS4NCg0KU3Rh dHVzIG9mIFRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQg QkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQogICBEcmFm dHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1iZXIgMjIsIDIwMTYuDQoNCg0K DQoNCg0KDQoNCkt1bWFyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjIsIDIw MTYgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgIE92 ZXJsYXkgT0FNIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgTWFyY2ggMjAxNg0KDQoNCkNvcHly aWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg dGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxl YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmli ZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBk b2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBw cm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZp ZWQgQlNEIExpY2Vuc2UuDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMg0K ICAgMi4gIFJlcXVpcmVtZW50cyBub3RhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzDQogICAzLiAgVGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMNCiAgIDQuICBEZXRhaWxlZCBSZXF1aXJl bWVudCBMaXN0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNA0KICAgICA0 LjEuICBGYXVsdCBNYW5hZ2VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA1DQogICAgICAgNC4xLjEuICBQcm8tYWN0aXZlIEZhdWx0IE1hbmFnZW1lbnQgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAgICA0LjEuMi4gIE9uLWRlbWFuZCBGYXVs dCBNYW5hZ2VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQ0KICAgICA0LjIuICBQ ZXJmb3JtYW5jZSBNYW5hZ2VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA1DQogICAgIDQuMy4gIEFsYXJtIEluZGljYXRpb24gU3VwcHJlc3Npb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDYNCiAgICAgNC40LiAgT3ZlcmxheSBOZXR3b3JrIFJlc2lsaWVu Y3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNg0KICAgNS4gIElBTkEgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQog ICA2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDYNCiAgIDcuICBBY2tub3dsZWRnZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KICAgOC4gIFJlZmVyZW5jZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3DQogICAgIDgu MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDcNCiAgICAgOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOA0KICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4DQoNCjEuICBJbnRyb2R1 Y3Rpb24NCg0KUlBCPiBUaGUgZmluYWwgcGFyYWdyYXBoIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGVs bHMgdXMgdGhlIGludGVudCBvZiB0aGUgZG9jdW1lbnRtZW50LiBJIGFtIG5vdCBzdXJlIHRoYXQg dGhlIHByZXZpb3VzIHBhcmFncmFwaHMgZG8gbXVjaCB0byBwcm9ncmVzcyB5b3VyIGdvYWxzLg0K DQpSUEI+IElmIHlvdSBkZWxldGUgZXZlcnl0aGluZyBleGNlcHQgdGhlIGZpbmFsIHBhcmFncmFw aCwgeW91IHdpbGwgaGF2ZSB0byB0ZWxsIHVzIHdoaWNoIGVuY2Fwc3VsYXRpb25zIHlvdSBhcmUg ZGVhbGluZyB3aXRoLiBJIHdvbmRlciB3aHkgeW91IGNob3NlIHRoZSBvbmVzIHRoYXQgeW91IGRp ZC4gV2h5IG5vdCBhZGQgc29tZSB0cmllZC1hbmQtdHJ1ZSBzdGFuZGFyZHMgdG8gdGhlIGxpc3Qg bGlrZSBHUkU/IFdoeSBhZGQgc29tZXRoaW5nIHNvIG5haXNjZW50IGFzIFNGQz8NCkdJTT4gVGhl IHNjb3BlIG9mIG91ciB3b3JrIGRldGVybWluZWQgYnkgdGhlIGNoYXJ0ZXIgb2YgdGhlIERlc2ln biBUZWFtLg0KUlBCPiBBbHNvLCB5b3UgbWF5IGJlIHNldHRpbmcgeW91cnNlbGYgZm9yIGZhaWx1 cmUgYnkgaW5jbHVkaW5nIEJJRVIuIE11c3RpY2FzdCBPQU0gaXMgb3JkZXJzIG9mIG1hZ25pdHVk ZSBtb3JlIGRpZmZpY3VsdCB0aGFuIHVuaWNhc3QuIExvb2sgYXQgbXVsdGljYXN0IHBpbmcgYW5k IHRyYWNlcm91dGUuIFlvdSB3aWxsIGdldCBhbiBpZGVhLg0KR0lNPiBQZXJoYXBzIGJ1dCB3ZSBj YW4gdHJ5Lg0KDQoNCiAgIFdlIGhhdmUgd2l0bmVzc2VkIGFuZCBwYXJ0aWNpcGF0ZWQgaW4gZGVz aWduIG9mIG5ldyBwYXJhZGlnbXMgaW4gdGhlDQogICBuZXR3b3JraW5nIHRoYXQgYXJlIGFpbWVk IHRvIGFkZHJlc3MgbmV0d29yayB2aXJ0dWFsaXphdGlvbiwgc2VydmljZQ0KICAgZnVuY3Rpb24g Y2hhaW5pbmcsIGFuZCBtdWx0aWNhc3Qgc2VydmljZXMuICBOZXcgcGFyYWRpZ21zIHJlcXVpcmUg bmV3DQogICBhcmNoaXRlY3R1cmFsIGNvbmNlcHRzLCBwcmluY2lwbGVzIGFuZCBjb21wb25lbnRz LiBbUkZDNzM2NV0gZGVmaW5lcw0KICAgYSBmcmFtZXdvcmsgZm9yIERhdGEgQ2VudGVyIE5ldHdv cmsgVmlydHVhbGl6YXRpb24gb3ZlciBMYXllciAzDQogICAoTlZPMykuICBbUkZDNzY2NV0gZGVz Y3JpYmVzIHRoZSBhcmNoaXRlY3R1cmUgZm9yIGNyZWF0aW5nIGFuZA0KICAgbWFpbnRhaW5pbmcg U2VydmljZSBGdW5jdGlvbiBDaGFpbnMgKFNGQ3MpIGluIGEgbmV0d29yay4NCiAgIFtJLUQuaWV0 Zi1iaWVyLWFyY2hpdGVjdHVyZV0gZGVmaW5lcyBhIHN0YXRlbGVzcyBtdWx0aWNhc3QNCiAgIGFy Y2hpdGVjdHVyZSBmb3Igb3B0aW1hbCBtdWx0aWNhc3QgcGFja2V0IGZvcndhcmRpbmcgdXNpbmcg IkJpdCBJbmRleA0KICAgRXhwbGljaXQgUmVwbGljYXRpb24iIChCSUVSKS4gVGhlc2UgZnJhbWV3 b3JrcyBhcmUgZGVmaW5lZCBpbiBhDQoNCg0KDQoNCkt1bWFyLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMjIsIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQoNCkludGVy bmV0LURyYWZ0ICAgICAgICAgIE92ZXJsYXkgT0FNIFJlcXVpcmVtZW50cyAgICAgICAgICAgICAg TWFyY2ggMjAxNg0KDQoNCiAgIGZsZXhpYmxlIG1hbm5lciB0aGF0IHRoZXkgYXJlIHRyYW5zcG9y dCBhZ25vc3RpYyBhbmQgbWF5IGJlIGRlcGxveWVkDQogICBvbiB2YXJpb3VzIHVuZGVybGF5IG5l dHdvcmtzIHN1Y2ggYXMgSVB2NCwgSVB2NiBhbmQgTVBMUy4NCg0KICAgVGhlIGFib3ZlIG1lbnRp b25lZCBuZXcgYXJjaGl0ZWN0dXJhbCBjb25jZXB0cyBhbmQgcHJpbmNpcGxlcyBoYXZlDQogICBi ZWVuIGNvbWJpbmVkIGludG8gbmV3IG5ldHdvcmsgbGF5ZXJzIHdpdGggZGlzdGluY3QgZW5jYXBz dWxhdGlvbg0KICAgaGVhZGVycy4gIEZvciBleGFtcGxlLCBbSS1ELmlldGYtc2ZjLW5zaF0gZGVm aW5lcyBhbiBlbmNhcHN1bGF0aW9uDQogICBoZWFkZXIgYXMgTmV0d29yayBTZXJ2aWNlIEhlYWRl ciAoTlNIKSB0byByZWFsaXplIFNlcnZpY2UgRnVuY3Rpb24NCiAgIFBhdGguICBXaGlsZSBbUkZD NzM0OF0gKFZ4TEFOKSBhbmQgW1JGQzc2MzddIChOVkdSRSkgYXJlIGRpZmZlcmVudA0KICAgZW5j YXBzdWxhdGlvbiBoZWFkZXIgcHJvcG9zZWQgZm9yIE5WTzMsIFtJLUQuaWV0Zi1udm8zLXZ4bGFu LWdwZV0NCiAgIGV4dGVuZHMgVnhMQU4gZnVydGhlciB0byBiZSB1c2VkIGZvciBTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluIChTRkMpLg0KICAgU2ltaWxhcmx5LCBbSS1ELmlldGYtYmllci1tcGxzLWVu Y2Fwc3VsYXRpb25dIGRlZmluZXMgdGhlIEJJRVINCiAgIGVuY2Fwc3VsYXRpb24gaGVhZGVyIG92 ZXIgTVBMUyBuZXR3b3JrIGFuZA0KICAgW0ktRC54dS1iaWVyLWVuY2Fwc3VsYXRpb25dIGRlc2Ny aWJlcyB0aGUgQklFUiBlbmNhcHN1bGF0aW9uIGhlYWRlcg0KICAgb3ZlciBJUCBuZXR3b3JrLg0K DQogICBJbnRyb2R1Y3Rpb24gb2YgdGhlIG5ldyBPdmVybGF5IG5ldHdvcmtzLCBzZXRzIGZvcnRo IG5ldyBPcGVyYXRpb25zLA0KICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIChPQU0p IHJlcXVpcmVtZW50cyB0aGF0IGNhbiBiZQ0KICAgYWRkcmVzc2VkIGJ5IGVuaGFuY2luZyB0aGUg ZXhpc3RpbmcgdG9vbHNldCBvciBkZXZlbG9waW5nIG5ldw0KICAgcHJvdG9jb2xzLiAgRm9yIGV4 YW1wbGUsIFtJLUQuaWV0Zi1zZmMtb2FtLWZyYW1ld29ya10gZGVmaW5lcyB0aGUNCiAgIGZyYW1l d29yayBmb3IgU0ZDIE9BTSwgW0ktRC5ub3JkbWFyay1udm8zLXRyYW5zY2VuZGluZy10cmFjZXJv dXRlXQ0KICAgcHJvcG9zZXMgYSB3YXkgdG8gcGVyZm9ybSB0cmFjZXJvdXRlIGluIE5WTzMgbmV0 d29ya3MgYW5kDQogICBbSS1ELmt1bWFyemhlbmctYmllci1waW5nXSBwcm9wb3NlcyBvbi1kZW1h bmQgY29ubmVjdGl2aXR5DQogICB2ZXJpZmljYXRpb24gYW5kIGZhdWx0IGlzb2xhdGlvbiBwcm9j ZWR1cmUgKFBpbmcgYW5kIFRyYWNlKSBvbiBCSUVSDQogICBuZXR3b3JrLg0KDQogICBUaGUgZ29h bCBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGlkZW50aWZ5IGFuZCBsaXN0IHRoZSBPQU0NCiAgIHJl cXVpcmVtZW50cyBjb21tb25seSBhcHBsaWNhYmxlIHRvIG5ldyBPdmVybGF5IG5ldHdvcmtzIHdo aWNoIGNhbg0KICAgZnVydGhlciBiZSB1c2VkIHRvIGFuYWx5emUgdGhlIGV4aXN0aW5nIE9BTSB0 b29scy4gIFRoZSBpZGVudGlmaWVkDQogICBnYXBzIGNhbiBiZSBhZGRyZXNzZWQsIGVpdGhlciB0 aHJvdWdoIGVuaGFuY2luZyBleGlzdGluZyBPQU0gdG9vbHMNCiAgIGFuZCBpZiBuZWNlc3Nhcnks IGNvbnN0cnVjdGluZyBuZXcgT0FNIHRvb2xzLCB0aGF0IGNhbiBiZSB1c2VkIGFzIGENCiAgIGNv bW1vbiB1bmlmaWVkIE9BTSB0b29sc2V0IHRvIHN1cHBvcnQgYW5kIHBlcmZvcm0gdmFyaW91cyBP QU0NCiAgIGZ1bmN0aW9ucyBpbmNsdWRpbmcgcHJvYWN0aXZlIGFuZCBvbi1kZW1hbmQgcGF0aCBt b25pdG9yaW5nIGFuZA0KICAgc2VydmljZSB2YWxpZGF0aW9uIG9uIHRoZSBuZXcgT3ZlcmxheSBu ZXR3b3JrLg0KDQoyLiAgUmVxdWlyZW1lbnRzIG5vdGF0aW9uDQoNCiAgIFRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAg ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3Jp YmVkIGluIFtSRkMyMTE5XS4NCg0KMy4gIFRlcm1pbm9sb2d5DQoNCiAgIEVDTVA6IEVxdWFsIENv c3QgTXVsdGlwYXRoDQoNCiAgIFVDTVA6IFVuZXF1YWwgQ29zdCBNdWx0aXBhdGgNCg0KICAgU0ZD OiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nDQoNCg0KDQoNCkt1bWFyLCBldCBhbC4gICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjIsIDIwMTYgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDQoN CkludGVybmV0LURyYWZ0ICAgICAgICAgIE92ZXJsYXkgT0FNIFJlcXVpcmVtZW50cyAgICAgICAg ICAgICAgTWFyY2ggMjAxNg0KDQoNCiAgIEJJRVI6IEJpdCBJbmRleCBFeHBsaWNpdCBSZXBsaWNh dGlvbg0KDQogICBOVk8zOiBOZXR3b3JrIFZpcnR1YWxpemF0aW9uIG92ZXIgTDMNCg0KICAgT0FN OiBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UNCg0KICAgTVBMUzog TXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcNCg0KICAgVnhMQU46IFZpcnR1YWwgRXh0ZW5z aWJsZSBMb2NhbCBBcmVhIE5ldHdvcmsNCg0KICAgTlZHUkU6IE5ldHdvcmsgVmlydHVhbGl6YXRp b24gVXNpbmcgR2VuZXJpYyBSb3V0aW5nIEVuY2Fwc3VsYXRpb24NCg0KNC4gIERldGFpbGVkIFJl cXVpcmVtZW50IExpc3QNCg0KICAgVGhpcyBzZWN0aW9uIGxpc3QgdGhlIE9BTSByZXF1aXJlbWVu dCBmb3IgZGlmZmVyZW50IE92ZXJsYXkgbmV0d29ya3MuDQogICBUaGUgYmVsb3cgbGlzdGVkIHJl cXVpcmVtZW50IE1VU1QgYmUgc3VwcG9ydGVkIHdpdGggYW55IHVuZGVybGF5DQogICB0cmFuc3Bv cnQgbmV0d29yazoNCg0KICAgUkVRIzE6ICBUaGUgbGlzdGVkIHJlcXVpcmVtZW50cyBNVVNUIGJl IHN1cHBvcnRlZCB3aXRoIGFueSB0eXBlIG9mDQogICAgICAgICAgICB0cmFuc3BvcnQgbGF5ZXIg b3ZlciB3aGljaCB0aGUgb3ZlcmxheSBuZXR3b3JrIGNhbiBiZQ0KICAgICAgICAgICAgcmVhbGl6 ZWQNCg0KICAgUkVRIzI6ICBJdCBNVVNUIGJlIHBvc3NpYmxlIHRvIGluaXRpYWxpemUgT3Zlcmxh eSBPQU0gc2Vzc2lvbiBmcm9tDQogICAgICAgICAgICBhbnkgbm9kZSBpbiB0aGUgb3ZlcmxheSBu ZXR3b3JrLg0KDQoNClJQQj4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgd2hhdCB5b3UgbWVh bnQgdG8gc2F5PyBNdXN0IEkgYmUgYWJsZSB0byBpbml0aWF0ZSBhIHNlc3Npb24gYmV0d2VlbiBu b2RlcyBBIGFuZCBCIGZyb20gbm9kZSBDPw0KR0lNPiBJbiBmYWN0IHN1cHBvcnQgb2YgcHJveHkg cGluZy90cmFjZXJvdXRlIGlzIGV4cGxpY2l0bHkgcmVxdWlyZWQgaW4gUmVxICMxNS4gVGhpcyBy ZXF1aXJlbWVudCB0YXJnZXRlZCB0b3dhcmRzIGxheWVycyB0aGF0IGhhdmUgaW50ZXJtZWRpYXRl IG5vZGVzIGxpa2UgQklFUi4NCg0KICAgUkVRIzM6ICBJdCBTSE9VTEQgYmUgcG9zc2libGUgdG8g aW5pdGlhbGl6ZSBhbiBPdmVybGF5IE9BTSBzZXNzaW9uDQogICAgICAgICAgICBmcm9tIGEgY2Vu dHJhbGl6ZWQgY29udHJvbGxlci4NCg0KUlBCPiBBbmQgYXMgYSBzaWRlIGVmZmVjdCwgdGhlIG5v ZGUgbXVzdCBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgcmVxdWVzdCBmcm9tIHRoZSBjb250 cm9sbGVyLg0KR0lNPiBHcmVhdCBzdWdnZXN0aW9uLCB0aGFuayB5b3UuDQoNCg0KICAgUkVRIzQ6 ICBPdmVybGF5IE9BTSBNVVNUIHN1cHBvcnQgcHJvYWN0aXZlIGFuZCBvbi1kZW1hbmQgT0FNDQog ICAgICAgICAgICBtb25pdG9yaW5nIGFuZCBtZWFzdXJlbWVudCBtZXRob2RzLg0KDQogICBSRVEj NTogIE92ZXJsYXkgT0FNIE1VU1Qgc3VwcG9ydCB1bmlkaXJlY3Rpb25hbCBPQU0gbWV0aG9kcywg Ym90aA0KICAgICAgICAgICAgY29udGludWl0eSBjaGVjayBhbmQgcGVyZm9ybWFuY2UgbWVhc3Vy ZW1lbnQuDQoNCg0KUlBCPiBFdmVuIEJJRVI/DQpHSU0+IFllcy4gSSBiZWxpZXZlIHRoYXQgQkZE IGZvciBtdWx0aXBvaW50IG5ldHdvcmtzLCB3aXRoIG9yIHdpdGhvdXQgYWN0aXZlIHRhaWwgbW9u aXRvcmluZywgd2lsbCBmaXQgdGhlIGJpbGwuIEFuZCBwYXNzaXZlIHBlcmZvcm1hbmNlIG1lYXN1 cmVtZW50IHVzaW5nIHRoZSBNYXJraW5nIE1ldGhvZCBtYXkgd29yayBhcyBwcm9wb3NlZCBpbiBk cmFmdC1taXJza3ktYmllci1wbW1tLW9hbSAod2lsbCBwcmVzZW50IGF0IEJJRVIgdGhpcyB3ZWVr KS4NCg0KICAgUkVRIzY6ICBPdmVybGF5IE9BTSBwYWNrZXRzIFNIT1VMRCBiZSBmYXRlIHNoYXJp bmcgd2l0aCBkYXRhIHRyYWZmaWMsDQogICAgICAgICAgICBpLmUuIGluLWJhbmQgd2l0aCB0aGUg bW9uaXRvcmVkIHRyYWZmaWMsIGkuZS4gZm9sbG93IGV4YWN0bHkNCiAgICAgICAgICAgIHRoZSBz YW1lIHBhdGggYXMgZGF0YSBwbGFuZSB0cmFmZmljLCBpbiBmb3J3YXJkIGRpcmVjdGlvbiwNCiAg ICAgICAgICAgIGkuZS4gZnJvbSBpbmdyZXNzIHRvd2FyZCBlZ3Jlc3MgZW5kIHBvaW50KHMpIG9m IHRoZSBPQU0gdGVzdA0KICAgICAgICAgICAgc2Vzc2lvbi4NCg0KDQpSUEI+IFNob3VsZCB0aGlz IGJlIGEgTVVTVD8NCkdJTT4gT3JpZ2luYWxseSBpdCB3YXMgYnV0IHBlciBDYXJsb3Mgc3VnZ2Vz dGlvbiBkb3duZ3JhZGVkIHRvIFNIT1VMRC4NCg0KICAgUkVRIzc6ICBPdmVybGF5IE9BTSBNVVNU IHN1cHBvcnQgYmktZGlyZWN0aW9uYWwgT0FNIG1ldGhvZHMuICBTdWNoDQogICAgICAgICAgICBP QU0gbWV0aG9kcyBNQVkgY29tYmluZSBpbi1iYW5kIG1vbml0b3Jpbmcgb3IgbWVhc3VyZW1lbnQg aW4NCiAgICAgICAgICAgIGZvcndhcmQgZGlyZWN0aW9uIGFuZCBvdXQtb2YtYmFuZCBub3RpZmlj YXRpb24gaW4gdGhlDQogICAgICAgICAgICByZXZlcnNlIGRpcmVjdGlvbiwgaS5lLiBmcm9tIGVn cmVzcyB0byBpbmdyZXNzIGVuZCBwb2ludCBvZg0KICAgICAgICAgICAgdGhlIE9BTSB0ZXN0IHNl c3Npb24uDQoNCg0KDQoNCg0KDQpLdW1hciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVt YmVyIDIyLCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCg0KDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICBPdmVybGF5IE9BTSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgIE1hcmNoIDIwMTYN Cg0KDQo0LjEuICBGYXVsdCBNYW5hZ2VtZW50DQoNCjQuMS4xLiAgUHJvLWFjdGl2ZSBGYXVsdCBN YW5hZ2VtZW50DQoNCiAgIEF2YWlsYWJpbGl0eSwgbm90IGFzIHBlcmZvcm1hbmNlIG1ldHJpYywg aXMgdW5kZXJzdG9vZCBhcyBhYmlsaXR5IHRvDQogICByZWFjaCB0aGUgbm9kZSwgaS5lLiB0aGUg ZmFjdCB0aGF0IHBhdGggYmV0d2VlbiBpbmdyZXNzIGFuZCBlZ3Jlc3MNCiAgIGRvZXMgZXhpc3Qu ICBTdWNoIE9BTSBtZWNoYW5pc20gYWxzbyByZWZlcnJlZCBhcyBDb250aW51aXR5IENoZWNrLg0K DQogICBSRVEjODogIE92ZXJsYXkgT0FNIE1VU1Qgc3VwcG9ydCBwcm8tYWN0aXZlIG1vbml0b3Jp bmcgb2YgYW55IHZpcnR1YWwNCiAgICAgICAgICAgIG5vZGUgYXZhaWxhYmlsaXR5IGluIHRoZSBn aXZlbiBvdmVybGF5IG5ldHdvcmsuDQoNCiAgIFJFUSM5OiAgT3ZlcmxheSBPQU0gTVVTVCBzdXBw b3J0IFJldmVyc2UgRGVmZWN0IEluZGljYXRpb24gKFJESSkNCiAgICAgICAgICAgIG5vdGlmaWNh dGlvbiBieSBlZ3Jlc3MgdG8gdGhlIGluZ3Jlc3MsIGkuZS4gc291cmNlIG9mDQogICAgICAgICAg ICBjb250aW51aXR5IGNoZWNraW5nLg0KDQogICBSRVEjMTA6IE92ZXJsYXkgT0FNIE1VU1Qgc3Vw cG9ydCBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLg0KICAgICAgICAgICAgRGVmaW5pdGlvbiBv ZiBtaXMtY29ubmVjdGl2aXR5IGRlZmVjdCBlbnRyeSBhbmQgZXhpdA0KICAgICAgICAgICAgY3Jp dGVyaWEgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNClJQQj4gSGVu Y2UgbXkgY29tbWVudCBvbiBSRVEgIzYuDQpHSU0+IFdvdWxkIGJlIGdyZWF0IHRvIHNlZSBpdCBv biB0aGUgbGlzdC4gT3IgSSBjYW4gcmVmZXIgdG8geW91ciB2aWV3IGFuZCB0cnkgdG8gY2hhbmdl IENhcmxvcyBQT1YuDQoNCjQuMS4yLiAgT24tZGVtYW5kIEZhdWx0IE1hbmFnZW1lbnQNCg0KICAg UkVRIzExOiBPdmVybGF5IE9BTSBNVVNUIHN1cHBvcnQgZmF1bHQgbG9jYWxpemF0aW9uIG9mIExv c3Mgb2YNCiAgICAgICAgICAgIENvbnRpbnVpdHkgY2hlY2suDQoNCiAgIFJFUSMxMjogT3Zlcmxh eSBPQU0gTVVTVCBzdXBwb3J0IHRyYWNpbmcgcGF0aCBpbiBvdmVybGF5IG5ldHdvcmsNCiAgICAg ICAgICAgIHRocm91Z2ggdGhlIHZpcnR1YWwgbm9kZXMuDQoNCiAgIFJFUSMxMzogT3ZlcmxheSBP QU0gTUFZIHN1cHBvcnQgdmVyaWZpY2F0aW9uIG9mIHRoZSBtYXBwaW5nIGJldHdlZW4NCiAgICAg ICAgICAgIGl0cyBkYXRhIHBsYW5lIHN0YXRlIGFuZCBjbGllbnQgbGF5ZXIgc2VydmljZXMuDQoN Cg0KUlBCPiBJbnRlcmVzdGluZy4gV2hhdCBkb2VzIHRoaXMgbWVhbj8NCkdJTT4gU2ltaWxhciB0 byB3aGF0IEVyaWuScyBUcmFuc2NlbmRpbmcgVHJhY2Vyb3V0ZSBkb2VzIGluIE5WTzMuDQoNCiAg IFJFUSMxNDogT3ZlcmxheSBPQU0gTVVTVCBoYXZlIHRoZSBhYmlsaXR5IHRvIGRpc2NvdmVyIGFu ZCBleGVyY2lzZQ0KICAgICAgICAgICAgZXF1YWwgY29zdCBtdWx0aXBhdGggKEVDTVApIHBhdGhz IGluIGl0cyB0cmFuc3BvcnQgbmV0d29yay4NCg0KICAgUkVRIzE1OiBPdmVybGF5IE9BTSBNVVNU IGJlIGFibGUgdG8gdHJpZ2dlciBvbi1kZW1hbmQgRk0gd2l0aA0KICAgICAgICAgICAgcmVzcG9u c2VzIGJlaW5nIGRpcmVjdGVkIHRvd2FyZHMgaW5pdGlhdG9yIG9mIHN1Y2ggcHJveHkNCiAgICAg ICAgICAgIHJlcXVlc3QuDQoNCjQuMi4gIFBlcmZvcm1hbmNlIE1hbmFnZW1lbnQNCg0KUlBCPiBZ b3UgbWlnaHQgd2FudCB0byBkZXNjcmliZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJhY3RpdmUi IGFuZCAicGFzc2l2ZSINCkdJTT4gVGhhbmsgeW91LCB3aWxsIGRvLg0KDQpSUEI+IFRoZSBwZXIg c2VnbWVudCBzdHVmZiBpcyBhIHN0cmVhY2guIEkgd2lzaCB0aGVyZSB3ZXJlIHNvbWV0aGluZyB3 ZWFrZXIgdGhhbiBTSE9VTEQuDQpHSU0+IEkgYmVsaWV2ZSB0aGF0IHdlIGRvbpJ0IGhhdmUgk3Nl Z21lbnSUIHdpdGggUkVRIzMuIEl0IHdhcyBub3QgbXkgb3JpZ2luYWwgcmVxdWlyZW1lbnQuIERl Y2lkZWQgdG8gbGVhdmUgaXQgZm9yIHRoZSBkaXNjdXNzaW9uLg0KDQogICBSRVEjMTY6ICBPdmVy bGF5IE9BTSBNVVNUIHN1cHBvcnQgYWN0aXZlIG9uZS13YXkgcGFja2V0IGRlbGF5DQogICAgICAg ICAgICBtZWFzdXJlbWVudC4NCg0KDQogICBSRVEjMTc6ICBPdmVybGF5IE9BTSBNVVNUIHN1cHBv cnQgcGFzc2l2ZSBvbmUtd2F5IHBhY2tldCBkZWxheQ0KICAgICAgICAgICAgbWVhc3VyZW1lbnQu DQoNCiAgIFJFUSMxODogIE92ZXJsYXkgT0FNIE1VU1Qgc3VwcG9ydCBhY3RpdmUgdHdvLXdheSBw YWNrZXQgZGVsYXkNCiAgICAgICAgICAgIG1lYXN1cmVtZW50Lg0KDQoNCg0KDQoNCg0KDQpLdW1h ciwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIyLCAyMDE2ICAgICAgICAgICAg ICAgW1BhZ2UgNV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBPdmVybGF5IE9BTSBSZXF1 aXJlbWVudHMgICAgICAgICAgICAgIE1hcmNoIDIwMTYNCg0KDQogICBSRVEjMTk6ICBPdmVybGF5 IE9BTSBNVVNUIHN1cHBvcnQgcGFja2V0IGRlbGF5IHZhcmlhdGlvbiBtZWFzdXJlbWVudC4NCg0K ICAgUkVRIzIwOiAgT3ZlcmxheSBPQU0gTVVTVCBzdXBwb3J0IGFjdGl2ZSBlbmQgdG8gZW5kIHBh Y2tldCBsb3NzDQogICAgICAgICAgICBtZWFzdXJlbWVudC4NCg0KICAgUkVRIzIxOiAgT3Zlcmxh eSBPQU0gTVVTVCBzdXBwb3J0IHBhc3NpdmUgZW5kIHRvIGVuZCBwYWNrZXQgbG9zcw0KICAgICAg ICAgICAgbWVhc3VyZW1lbnQuDQoNCiAgIFJFUSMyMjogIE92ZXJsYXkgT0FNIFNIT1VMRCBzdXBw b3J0IGFjdGl2ZSBwZXItc2VnbWVudCBwYWNrZXQgZGVsYXkNCiAgICAgICAgICAgIG1lYXN1cmVt ZW50Lg0KDQogICBSRVEjMjM6ICBPdmVybGF5IE9BTSBTSE9VTEQgc3VwcG9ydCBwYXNzaXZlIHBl ci1zZWdtZW50IHBhY2tldCBkZWxheQ0KICAgICAgICAgICAgbWVhc3VyZW1lbnQuDQoNCiAgIFJF USMyNDogIE92ZXJsYXkgT0FNIFNIT1VMRCBzdXBwb3J0IGFjdGl2ZSBwZXItc2VnbWVudCBwYWNr ZXQgbG9zcw0KICAgICAgICAgICAgbWVhc3VyZW1lbnQuDQoNCiAgIFJFUSMyNTogIE92ZXJsYXkg T0FNIFNIT1VMRCBzdXBwb3J0IHBhc3NpdmUgcGVyLXNlZ21lbnQgcGFja2V0IGxvc3MNCiAgICAg ICAgICAgIG1lYXN1cmVtZW50Lg0KDQogICBSRVEjMjY6ICBPdmVybGF5IE9BTSBNVVNUIHN1cHBv cnQgZGVsaXZlcmVkIHBhY2tldCB0aHJvdWdocHV0DQogICAgICAgICAgICBtZWFzdXJlbWVudC4N Cg0KNC4zLiAgQWxhcm0gSW5kaWNhdGlvbiBTdXBwcmVzc2lvbg0KDQogICBSRVEjMjc6IE92ZXJs YXkgT0FNIE1VU1Qgc3VwcG9ydCBkZWZlY3Qgbm90aWZpY2F0aW9uIG1lY2hhbmlzbSwgbGlrZQ0K ICAgICAgICAgICAgQWxhcm0gSW5kaWNhdGlvbiBTaWduYWwuDQoNCiAgIFJFUSMyODogQW55IHZp cnR1YWwgbm9kZSBpbiB0aGUgZ2l2ZW4gb3ZlcmxheSBuZXR3b3JrIE1BWSBvcmlnaW5hdGUgYQ0K ICAgICAgICAgICAgZGVmZWN0IG5vdGlmaWNhdGlvbiBhZGRyZXNzZWQgdG8gYW55IG5vZGUgaW4g dGhhdCBuZXR3b3JrLg0KDQo0LjQuICBPdmVybGF5IE5ldHdvcmsgUmVzaWxpZW5jeQ0KDQogICBS RVEjMjk6IE92ZXJsYXkgT0FNIE1VU1Qgc3VwcG9ydCBtZXRob2RzIHRvIGVuYWJsZSBzdXJ2aXZh YmlsaXR5IG9mDQogICAgICAgICAgICBhbiBvdmVybGF5IG5ldHdvcmsuICBUaGVzZSByZWNvdmVy eSBtZXRob2RzIE1BWSB1c2UNCiAgICAgICAgICAgIHByb3RlY3Rpb24gc3dpdGNoaW5nIGFuZCBy ZXN0b3JhdGlvbi4NCg0KNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVu dCBkb2VzIG5vdCBwcm9wb3NlIGFueSBJQU5BIGNvbnNpZGVyYXRpb24uDQoNCjYuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IGxpc3QgdGhlIE9BTSByZXF1aXJl bWVudCBmb3IgdmFyaW91cyBPdmVybGF5IG5ldHdvcmsNCiAgIGFuZCBkb2VzIG5vdCByYWlzZSBh bnkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCg0KDQoNCg0KDQpLdW1hciwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIyLCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2UgNl0N Cg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBPdmVybGF5IE9BTSBSZXF1aXJlbWVudHMgICAg ICAgICAgICAgIE1hcmNoIDIwMTYNCg0KDQo3LiAgQWNrbm93bGVkZ2VtZW50DQoNCiAgIFRCRA0K DQo4LiAgUmVmZXJlbmNlcw0KDQo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbSS1E LmlldGYtYmllci1hcmNoaXRlY3R1cmVdDQogICAgICAgICAgICAgIFdpam5hbmRzLCBJLiwgUm9z ZW4sIEUuLCBEb2xnYW5vdywgQS4sIFAsIFQuLCBhbmQgUy4NCiAgICAgICAgICAgICAgQWxkcmlu LCAiTXVsdGljYXN0IHVzaW5nIEJpdCBJbmRleCBFeHBsaWNpdCBSZXBsaWNhdGlvbiIsDQogICAg ICAgICAgICAgIGRyYWZ0LWlldGYtYmllci1hcmNoaXRlY3R1cmUtMDMgKHdvcmsgaW4gcHJvZ3Jl c3MpLA0KICAgICAgICAgICAgICBKYW51YXJ5IDIwMTYuDQoNCiAgIFtJLUQuaWV0Zi1iaWVyLW1w bHMtZW5jYXBzdWxhdGlvbl0NCiAgICAgICAgICAgICAgV2lqbmFuZHMsIEkuLCBSb3NlbiwgRS4s IERvbGdhbm93LCBBLiwgVGFudHN1cmEsIEouLCBhbmQNCiAgICAgICAgICAgICAgUy4gQWxkcmlu LCAiRW5jYXBzdWxhdGlvbiBmb3IgQml0IEluZGV4IEV4cGxpY2l0DQogICAgICAgICAgICAgIFJl cGxpY2F0aW9uIGluIE1QTFMgTmV0d29ya3MiLCBkcmFmdC1pZXRmLWJpZXItbXBscy0NCiAgICAg ICAgICAgICAgZW5jYXBzdWxhdGlvbi0wMyAod29yayBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5IDIw MTYuDQoNCiAgIFtJLUQuaWV0Zi1udm8zLXZ4bGFuLWdwZV0NCiAgICAgICAgICAgICAgUXVpbm4s IFAuLCBNYW51ciwgUi4sIEtyZWVnZXIsIEwuLCBMZXdpcywgRC4sIE1haW5vLCBGLiwNCiAgICAg ICAgICAgICAgU21pdGgsIE0uLCBBZ2Fyd2FsLCBQLiwgWW9uZywgTC4sIFh1LCBYLiwgRWx6dXIs IFUuLCBHYXJnLA0KICAgICAgICAgICAgICBQLiwgYW5kIEQuIE1lbG1hbiwgIkdlbmVyaWMgUHJv dG9jb2wgRXh0ZW5zaW9uIGZvciBWWExBTiIsDQogICAgICAgICAgICAgIGRyYWZ0LWlldGYtbnZv My12eGxhbi1ncGUtMDEgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBOb3ZlbWJlcg0KICAgICAgICAgICAg ICAyMDE1Lg0KDQogICBbSS1ELmlldGYtc2ZjLW5zaF0NCiAgICAgICAgICAgICAgUXVpbm4sIFAu IGFuZCBVLiBFbHp1ciwgIk5ldHdvcmsgU2VydmljZSBIZWFkZXIiLCBkcmFmdC0NCiAgICAgICAg ICAgICAgaWV0Zi1zZmMtbnNoLTAyICh3b3JrIGluIHByb2dyZXNzKSwgSmFudWFyeSAyMDE2Lg0K DQogICBbSS1ELmlldGYtc2ZjLW9hbS1mcmFtZXdvcmtdDQogICAgICAgICAgICAgIEFsZHJpbiwg Uy4sIEtyaXNobmFuLCBSLiwgQWtpeWEsIE4uLCBQaWduYXRhcm8sIEMuLCBhbmQgQS4NCiAgICAg ICAgICAgICAgR2hhbndhbmksICJTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIE9wZXJhdGlvbiwN CiAgICAgICAgICAgICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIEZyYW1ld29yayIs IGRyYWZ0LWlldGYtc2ZjLQ0KICAgICAgICAgICAgICBvYW0tZnJhbWV3b3JrLTAxICh3b3JrIGlu IHByb2dyZXNzKSwgRmVicnVhcnkgMjAxNi4NCg0KICAgW0ktRC5rdW1hcnpoZW5nLWJpZXItcGlu Z10NCiAgICAgICAgICAgICAgS3VtYXIsIE4uLCBQaWduYXRhcm8sIEMuLCBBa2l5YSwgTi4sIFpo ZW5nLCBMLiwgQ2hlbiwgTS4sDQogICAgICAgICAgICAgIGFuZCBHLiBNaXJza3ksICJCSUVSIFBp bmcgYW5kIFRyYWNlIiwgZHJhZnQta3VtYXJ6aGVuZy0NCiAgICAgICAgICAgICAgYmllci1waW5n LTAyICh3b3JrIGluIHByb2dyZXNzKSwgRGVjZW1iZXIgMjAxNS4NCg0KICAgW0ktRC5ub3JkbWFy ay1udm8zLXRyYW5zY2VuZGluZy10cmFjZXJvdXRlXQ0KICAgICAgICAgICAgICBOb3JkbWFyaywg RS4sIEFwcGFubmEsIEMuLCBhbmQgQS4gTG8sICJMYXllci1UcmFuc2NlbmRpbmcNCiAgICAgICAg ICAgICAgVHJhY2Vyb3V0ZSBmb3IgT3ZlcmxheSBOZXR3b3JrcyBsaWtlIFZYTEFOIiwgZHJhZnQt DQogICAgICAgICAgICAgIG5vcmRtYXJrLW52bzMtdHJhbnNjZW5kaW5nLXRyYWNlcm91dGUtMDEg KHdvcmsgaW4NCiAgICAgICAgICAgICAgcHJvZ3Jlc3MpLCBPY3RvYmVyIDIwMTUuDQoNCg0KDQoN Ckt1bWFyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjIsIDIwMTYgICAgICAg ICAgICAgICBbUGFnZSA3XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgIE92ZXJsYXkgT0FN IFJlcXVpcmVtZW50cyAgICAgICAgICAgICAgTWFyY2ggMjAxNg0KDQoNCiAgIFtJLUQueHUtYmll ci1lbmNhcHN1bGF0aW9uXQ0KICAgICAgICAgICAgICBYdSwgWC4sIFNvbWFzdW5kYXJhbSwgUy4s IEphY3F1ZW5ldCwgQy4sIGFuZCBSLiBSYXN6dWssDQogICAgICAgICAgICAgICJCSUVSIEVuY2Fw c3VsYXRpb24iLCBkcmFmdC14dS1iaWVyLWVuY2Fwc3VsYXRpb24tMDMgKHdvcmsNCiAgICAgICAg ICAgICAgaW4gcHJvZ3Jlc3MpLCBPY3RvYmVyIDIwMTUuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAg ICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksDQogICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LA0KICAgICAgICAgICAgICA8aHR0cDov L3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+Lg0KDQogICBbUkZDNzM0OF0gIE1haGFs aW5nYW0sIE0uLCBEdXR0LCBELiwgRHVkYSwgSy4sIEFnYXJ3YWwsIFAuLCBLcmVlZ2VyLA0KICAg ICAgICAgICAgICBMLiwgU3JpZGhhciwgVC4sIEJ1cnNlbGwsIE0uLCBhbmQgQy4gV3JpZ2h0LCAi VmlydHVhbA0KICAgICAgICAgICAgICBlWHRlbnNpYmxlIExvY2FsIEFyZWEgTmV0d29yayAoVlhM QU4pOiBBIEZyYW1ld29yayBmb3INCiAgICAgICAgICAgICAgT3ZlcmxheWluZyBWaXJ0dWFsaXpl ZCBMYXllciAyIE5ldHdvcmtzIG92ZXIgTGF5ZXIgMw0KICAgICAgICAgICAgICBOZXR3b3JrcyIs IFJGQyA3MzQ4LCBET0kgMTAuMTc0ODcvUkZDNzM0OCwgQXVndXN0IDIwMTQsDQogICAgICAgICAg ICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzM0OD4uDQoNCiAgIFtSRkM3 MzY1XSAgTGFzc2VycmUsIE0uLCBCYWx1cywgRi4sIE1vcmluLCBULiwgQml0YXIsIE4uLCBhbmQg WS4NCiAgICAgICAgICAgICAgUmVraHRlciwgIkZyYW1ld29yayBmb3IgRGF0YSBDZW50ZXIgKERD KSBOZXR3b3JrDQogICAgICAgICAgICAgIFZpcnR1YWxpemF0aW9uIiwgUkZDIDczNjUsIERPSSAx MC4xNzQ4Ny9SRkM3MzY1LCBPY3RvYmVyDQogICAgICAgICAgICAgIDIwMTQsIDxodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzM2NT4uDQoNCiAgIFtSRkM3NjM3XSAgR2FyZywgUC4s IEVkLiBhbmQgWS4gV2FuZywgRWQuLCAiTlZHUkU6IE5ldHdvcmsNCiAgICAgICAgICAgICAgVmly dHVhbGl6YXRpb24gVXNpbmcgR2VuZXJpYyBSb3V0aW5nIEVuY2Fwc3VsYXRpb24iLA0KICAgICAg ICAgICAgICBSRkMgNzYzNywgRE9JIDEwLjE3NDg3L1JGQzc2MzcsIFNlcHRlbWJlciAyMDE1LA0K ICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2Mzc+Lg0K DQogICBbUkZDNzY2NV0gIEhhbHBlcm4sIEouLCBFZC4gYW5kIEMuIFBpZ25hdGFybywgRWQuLCAi U2VydmljZSBGdW5jdGlvbg0KICAgICAgICAgICAgICBDaGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1 cmUiLCBSRkMgNzY2NSwNCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzc2NjUsIE9jdG9i ZXIgMjAxNSwNCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmM3NjY1Pi4NCg0KOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbSS1ELmlldGYt Ymllci1vYW0tcmVxdWlyZW1lbnRzXQ0KICAgICAgICAgICAgICBNaXJza3ksIEcuLCBOb3JkbWFy aywgRS4sIFBpZ25hdGFybywgQy4sIEt1bWFyLCBOLiwNCiAgICAgICAgICAgICAgQWxkcmluLCBT LiwgWmhlbmcsIEwuLCBDaGVuLCBNLiwgQWtpeWEsIE4uLCBhbmQgSi4NCiAgICAgICAgICAgICAg TmV0d29ya3MsICJPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiBhbmQgTWFpbnRlbmFuY2UNCiAg ICAgICAgICAgICAgKE9BTSkgUmVxdWlyZW1lbnRzIGZvciBCaXQgSW5kZXggRXhwbGljaXQgUmVw bGljYXRpb24NCiAgICAgICAgICAgICAgKEJJRVIpIExheWVyIiwgZHJhZnQtaWV0Zi1iaWVyLW9h bS1yZXF1aXJlbWVudHMtMDAgKHdvcmsNCiAgICAgICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBTZXB0 ZW1iZXIgMjAxNS4NCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCg0KDQoNCg0KDQoNCg0KS3VtYXIs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMiwgMjAxNiAgICAgICAgICAgICAg IFtQYWdlIDhdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgT3ZlcmxheSBPQU0gUmVxdWly ZW1lbnRzICAgICAgICAgICAgICBNYXJjaCAyMDE2DQoNCg0KICAgTmFnZW5kcmEgS3VtYXINCiAg IENpc2NvIFN5c3RlbXMsIEluYy4NCiAgIDcyMDAgS2l0IENyZWVrIFJvYWQNCiAgIFJlc2VhcmNo IFRyaWFuZ2xlIFBhcmssIE5DICAyNzcwOQ0KICAgVVMNCg0KICAgRW1haWw6IG5haWt1bWFyQGNp c2NvLmNvbQ0KDQoNCiAgIENhcmxvcyBQaWduYXRhcm8NCiAgIENpc2NvIFN5c3RlbXMsIEluYy4N CiAgIDcyMDAgS2l0IENyZWVrIFJvYWQNCiAgIFJlc2VhcmNoIFRyaWFuZ2xlIFBhcmssIE5DICAy NzcwOS00OTg3DQogICBVUw0KDQogICBFbWFpbDogY3BpZ25hdGFAY2lzY28uY29tDQoNCg0KICAg RGVlcGFrIEt1bWFyDQogICBDaXNjbyBTeXN0ZW1zLCBJbmMuDQogICAzNzAwIENpc2NvIFdheQ0K ICAgU0oNCiAgIFVTDQoNCiAgIEVtYWlsOiBkZWt1bWFyQGNpc2NvLmNvbQ0KDQoNCiAgIEdyZWcg TWlyc2t5DQogICBFcmljc3Nvbg0KDQogICBFbWFpbDogZ3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tDQoNCg0KICAgTWFjaCBDaGVuDQogICBIdWF3ZWkgVGVjaG5vbG9naWVzDQoNCiAgIEVtYWls OiBtYWNoLmNoZW5AaHVhd2VpLmNvbQ0KDQoNCiAgIEVyaWMgTm9yZG1hcmsNCiAgIEFyaXN0YSBO ZXR3b3Jrcw0KDQogICBFbWFpbDogbm9yZG1hcmtAYWNtLm9yZw0KDQoNCg0KDQoNCg0KDQoNCkt1 bWFyLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjIsIDIwMTYgICAgICAgICAg ICAgICBbUGFnZSA5XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgIE92ZXJsYXkgT0FNIFJl cXVpcmVtZW50cyAgICAgICAgICAgICAgTWFyY2ggMjAxNg0KDQoNCiAgIFNhbnRvc2ggUGFsbGFn YXR0aQ0KICAgSnVuaXBlciBOZXR3b3Jrcw0KDQogICBFbWFpbDogc2FudG9zaC5wYWxsYWdhdHRp QGdtYWlsLmNvbQ0KDQoNCiAgIERhdmlkIE1vemVzDQogICBNZWxsYW5veCBUZWNobm9sb2dpZXMg THRkDQoNCiAgIEVtYWlsOiBkYXZpZG1AbWVsbGFub3guY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KS3VtYXIsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMiwgMjAxNiAg ICAgICAgICAgICAgW1BhZ2UgMTBdDQoNCg== --_004_7347100B5761DC41A166AC17F22DF11221A3CB8Feusaamb103erics_-- From nobody Tue Apr 5 06:37: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 B45EA12D724 for ; Mon, 4 Apr 2016 16:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 r308GVN1t1Uw for ; Mon, 4 Apr 2016 16:20:03 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66CC12D126 for ; Mon, 4 Apr 2016 16:20:02 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u34JhcxU022897; Mon, 4 Apr 2016 15:45:03 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 223wk1j1ss-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Apr 2016 15:45:01 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u34JiupY023792; Mon, 4 Apr 2016 15:44:58 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u34Jikc1023632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Apr 2016 15:44:50 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 4 Apr 2016 19:44:33 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.181]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 15:44:33 -0400 From: "UTTARO, JAMES" To: Xuxiaohu , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH Thread-Index: AQHRgGIWkanorO4w3UWxkHFtF58Aq59dP1yAgAF9ZiCABNXngIABJ6ZAgABDfACAAU4y8IAUAxgg Date: Mon, 4 Apr 2016 19:44:32 +0000 Message-ID: References: <56E68706.7090505@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5331C8@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5337B6@NKGEML515-MBX.china.huawei.com> <56EACDC7.7060000@gmail.com> <56EACF91.6070703@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D533D68@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D534964@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D534D9F@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D534D9F@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.207.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: DAM Allow Patterns, public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604040283 Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 06:37:53 -0700 Cc: Ron Parker , "sfc@ietf.org" , "EXT Bottorff, Paul" , "Jim Guichard \(jguichar\)" , "Dolganow, Andrew \(Nokia - SG\)" , "ao.ting@zte.com.cn" , Stewart Bryant , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH 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: Mon, 04 Apr 2016 23:20:06 -0000 U28sIEkgZm91bmQgdGltZSB0byByZWFkIHRoZSBOU0ggZHJhZnQgaW4gaXRzIGVudGlyZXR5LiBB IGZldyBzdWdnZXN0aW9uczoNCg0KSWRlbnRpZnkgc3BlY2lmaWMgdXNlIGNhc2VzIHRoYXQgcmVx dWlyZSBOU0ggU2VjIDIuMiBsaXN0cyA3IGJyb2FkIGFyZWFzIHRoYXQgYXJlIHRvbyBoaWdoIGxl dmVsLiANCg0KIEV4YW1wbGVzDQoNCkJ1bGxldCAyICJTZXJ2aWNlIENoYWluIENvbnN0cnVjdGlv biIgY2l0ZXMgdGhlIG5vdGlvbiB0aGF0IG1vc3QgY2hhaW5zIGFyZSBidWlsdCB0aHJvdWdoIG1h bnVhbCBjb25maWcgd2hpY2ggaXMgc2xvdyBhbmQgZXJyb3IgcHJvbmUuIFdvdWxkIGEgcHJvY2Vz cyB0aGF0IHJlbGllcyBvbiBhIGNvbnRyb2xsZXIgdG8gY29uZmlndXJlIHRoZXNlIGNoYWlucyBj b3JyZWN0IHRoaXMgZGVmaWNpZW5jeSBvciBjYW4gaXQgb25seSBiZSBmaXhlZCB3aXRoIE5TSC4N Cg0KQnVsbGV0IDQgIlBlciBTZXJ2aWNlIChyZSkgQ2xhc3NpZmljYXRpb24iICBIb3cgbmVlZGVk IGlzIHRoaXMgPyBXaGF0IHBlcmNlbnRhZ2Ugb2YgY2hhaW5zIHdpbGwgcmVxdWlyZSBpdD8gTW9y ZSBzcGVjaWZpYyBleGFtcGxlcywgd2hhdCBhcmUgdGhlIGFsdGVybmF0aXZlcyBzdWNoIGFzIHRo ZSBub3QgcmVkaXJlY3QgdGhlIHRvIGEgbmV3IGNoYWluIGJ1dCB0YWtlIHRlcm1pbmFsIGFjdGlv biB0aGVyZSBvciBzZW5kIHRvIGEgY2VudHJhbGl6ZWQgY29udHJvbGxlciAuLi4uDQoNCkJ1bGxl dCA2ICJMaW1pdGVkIEVuZC10by1FbmQgU2VydmljZSBWaXNpYmlsaXR5IiAgQSBiaXQgY29uZnVz ZWQgaGVyZS4gRG8gd2UgYW50aWNpcGF0ZSBjaGFpbnMgc3Bhbm5pbmcgbXVsdGlwbGUgZGF0YSBj ZW50ZXJzPyBUaGlzIHdvdWxkIHNlZW0gdG8gcmVxdWlyZSBxdWl0ZSBhIGJpdCBvZiBlZmZvcnQg Zm9yIHRoZSB0cmFuc3BvcnQgbGF5ZXIgaS5lIE1QTFMuDQogDQpJTU8gdGhpcyBlbnRpcmUgc2Vj dGlvbiBuZWVkcyB0byBiZSBtYWRlIGZvciBtb3JlIHNwZWNpZmljLiBZb3UgbWF5IGNvbnNpZGVy IHB1bGxpbmcgaXQgb3V0IGludG8gYSByZXFzL3VzZSBjYXNlIGRyYWZ0Lg0KDQpTZWMgMi4zIGlk ZW50aWZpZXMgaG93IGFsbCBvZiB0aGUgaXNzdWVzIGluIFNlYyAyLjIgYXJlIGFtZWxpb3JhdGVk LiBOZWVkIGEgYmV0dGVyIGRlZmluaXRpb24gb2YgU2VjIDIuMiBwcmlvciB0byBhc3NpZ25pbmcg dGhlIE5TSCByZW1lZHkgaW4gU2VjIDIuMw0KDQpBbHRob3VnaCBJIHJlYWQgdGhlIHJlc3Qgb2Yg dGhlIGRvY3VtZW50IEkgd2lsbCBub3QgY29tbWVudCBhcyB0aGUgZHJpdmVycyBmb3IgdGhpcyBu ZXcgZGF0YSBwbGFuZSBlbmNhcCBpcyBub3QgY2xlYXIgdG8gbWUuIEhhdmUgeW91IHJlYWNoZWQg b3V0IHRvIHRoZSBXR3MgdGhhdCBkZWFsIHdpdGggZGF0YSBwbGFuZSBlbmNhcCB0byBzZWUgaWYg dGhleSBjYW4gbWVldCB0aGUgcmVxcz8NCg0KSXQgd291bGQgYmUgdXNlZnVsIHRvIHNlZSBhIG1h dHJpeCBvZiBkYXRhIHBsYW5lIGVuY2FwcyBjdXJyZW50bHkgaW4gdXNlIGFuZCB3aGF0IGZ1bmN0 aW9ucyByZXF1aXJlZCBieSBTRkMgYXJlIHN1cHBvcnRlZC4gVGhpcyBtYXkgbGVhZCB0byBhIHNv bHV0aW9uIHRoYXQgZG9lcyBub3QgY3JlYXRlIGEgbmV3IGRhdGEgZW5jYXAgYnV0IGV4dGVuZHMg b25lIG9mIHRoZSBjdXJyZW50IHNldC4NCg0KSWYgdGhlIG5vdGlvbiBoZXJlIGlzIHRvIGFic3Ry YWN0IGRhdGEgcGxhbmUgZW5jYXAgYXMgdGhlcmUgYXJlIHRvbyBtYW55LCB0aGVuIGl0IG1heSBi ZSBiZXN0IHRvIHBpY2sgdGhlIG9uZSB0aGF0IG1vc3Qgc2F0aXNmaWVzIHRoZSBTRkMgbmVlZCBh bmQgcHV0IGEgc3Rha2UgaW4gdGhlIGdyb3VuZC4gDQoNCkppbSBVdHRhcm8NCg0KDQoiVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIEFUJlQgcHJvcGVydHks IGFyZSBjb25maWRlbnRpYWwsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoaXMgZW1haWwgaXMgYWRkcmVzc2Vk LiBJZiB5b3UgYXJlIG5vdCBvbmUgb2YgdGhlIG5hbWVkIHJlY2lwaWVudChzKSBvciBvdGhlcndp c2UgaGF2ZSByZWFzb24gdG8gYmVsaWV2ZSB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVz c2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGltbWVkaWF0ZWx5IGZyb20geW91ciBjb21wdXRlci4gQW55IG90aGVyIHVzZSwgcmV0 ZW50aW9uLCBkaXNzZW1pbmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywgb3IgY29weWluZyBv ZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21d IA0KU2VudDogVHVlc2RheSwgTWFyY2ggMjIsIDIwMTYgOTo1OSBQTQ0KVG86IENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPg0KQ2M6IEppbSBHdWljaGFyZCAo amd1aWNoYXIpIDxqZ3VpY2hhckBjaXNjby5jb20+OyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2Vs aGFscGVybi5jb20+OyBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tPjsg VVRUQVJPLCBKQU1FUyA8anUxNzM4QGF0dC5jb20+OyBSb24gUGFya2VyIDxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPjsgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPjsg RG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+ OyBFWFQgQm90dG9yZmYsIFBhdWwgPHBhdWwuYm90dG9yZmZAaHBlLmNvbT47IGFvLnRpbmdAenRl LmNvbS5jbjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NmY10gW0dSQVlNQUlMXSBSZTog QWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlciB0eXBlIG9mIE5TSA0KDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21h aWx0bzpjcGlnbmF0YUBjaXNjby5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIyLCAyMDE2 IDk6NTQgUE0NCj4gVG86IFh1eGlhb2h1DQo+IENjOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsg Sm9lbCBNLiBIYWxwZXJuOyBTdGV3YXJ0IEJyeWFudDsgVVRUQVJPLCBKQU1FUzsNCj4gUm9uIFBh cmtlcjsgRGF2ZSBEb2xzb247IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBFWFQgQm90 dG9yZmYsIFBhdWw7DQo+IGFvLnRpbmdAenRlLmNvbS5jbjsgc2ZjQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyIHR5 cGUgb2YgTlNIDQo+IA0KPiANCj4gPiBPbiBNYXIgMjEsIDIwMTYsIGF0IDk6NTYgUE0sIFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hh cikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNo IDIyLCAyMDE2IDEyOjE1IEFNDQo+ID4+IFRvOiBYdXhpYW9odTsgSm9lbCBNLiBIYWxwZXJuOyBT dGV3YXJ0IEJyeWFudDsgVVRUQVJPLCBKQU1FUzsgUm9uDQo+ID4+IFBhcmtlcjsgRGF2ZSBEb2xz b247IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBFWFQgQm90dG9yZmYsDQo+ID4+IFBh dWw7IGFvLnRpbmdAenRlLmNvbS5jbg0KPiA+PiBDYzogc2ZjQGlldGYub3JnDQo+ID4+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyIHR5 cGUgb2YNCj4gPj4gTlNIDQo+ID4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gU28gZXZl biBpZiB3ZSBoYWQgd2FudGVkIHRvIHVzZSBhIGxhYmVsIHN0YWNrIGZvciBwYXRoDQo+ID4+Pj4g aWRlbnRpZmljYXRpb24sIGFzIGZhciBhcyBJICBjYW4gdGVsbCB3ZSB3b3VsZCBzdGlsbCBuZWVk IGEgaGVhZGVyDQo+ID4+Pj4gdG8gY2FycnkgdGhlIG1ldGFkYXRhLg0KPiA+Pj4NCj4gPj4+IFll cy4gSG93ZXZlciwgaWYgbWV0YWRhdGEgaXMgbm90IGEgbWFuZGF0b3J5IGNvbXBvbmVudCBpbiBh bnkNCj4gPj4+IHNlcnZpY2UgY2hhaW4sIGl0J2QgYmV0dGVyIHRvIGRlY291cGxlIHRoZSBwYXRo IGlkZW50aWZpY2F0aW9uDQo+ID4+PiBoZWFkZXIgZnJvbSB0aGUgbWV0YWRhdGEgaGVhZGVyLCBJ TUhPLg0KPiA+Pg0KPiA+PiBJbiB3aGljaCBjYXNlIHlvdSBjYW4gdXNlIE1ELXR5cGUgMiB3aXRo IGxlbmd0aCBzZXQgdG8gMHgyLg0KPiA+DQo+ID4gV2hhdCBhYm91dCBpZiB3ZSBqdXN0IHdhbnQg dGhlIE5TSCB0byBhY3QgYXMgYSBtZXRhZGF0YSBjb250YWluZXI/DQo+ID4NCj4gDQo+IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjY1DQo+IA0KPiAgICBTRkMgRW5jYXBzdWxhdGlv bjogIFRoZSBTRkMgZW5jYXBzdWxhdGlvbiBwcm92aWRlcywgYXQgYSBtaW5pbXVtLCBTRlANCj4g ICAgICAgICBpZGVudGlmaWNhdGlvbiwgYW5kIGlzIHVzZWQgYnkgdGhlIFNGQy1hd2FyZSBmdW5j dGlvbnMsIHN1Y2ggYXMNCj4gICAgICAgICB0aGUgU0ZGIGFuZCBTRkMtYXdhcmUgU0ZzLiAgVGhl IFNGQyBlbmNhcHN1bGF0aW9uIGlzIG5vdCB1c2VkDQo+ICAgICAgICAgZm9yIG5ldHdvcmsgcGFj a2V0IGZvcndhcmRpbmcuICBJbiBhZGRpdGlvbiB0byBTRlANCj4gICAgICAgICBpZGVudGlmaWNh dGlvbiwgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGNhcnJpZXMgbWV0YWRhdGEgaW5jbHVkaW5nDQo+ ICAgICAgICAgZGF0YS1wbGFuZSBjb250ZXh0IGluZm9ybWF0aW9uLg0KDQpNeSBwb2ludCBpczog d2hlbiB0aGUgU0ZQIGlkZW50aWZpY2F0aW9uIGNvdWxkIGJlIGltcGxlbWVudGVkIGJ5IHVzaW5n IGEgZ2l2ZW4gZXhpc3RpbmcgZm9yd2FyZGluZyBwYXJhZGlnbSwgd2hhdCB3ZSByZWFsbHkgbmVl ZCB0byBpbnZlbnQgaXMganVzdCBhIG1ldGFkYXRhIGNvbnRhaW5lci4NCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4g4oCUIENhcmxvcy4NCj4gDQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhp YW9odQ0KPiA+DQo+ID4+IEppbQ0KPiA+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gQW5kIHRoYXQg bWVhbnMgdGhhdCBhbnl0aGluZyB0aGF0IG5lZWRlZCB0aGUgbWV0YWRhdGEgb3IgaW5uZXINCj4g Pj4+PiBwYWNrZXQgd291bGQgIGhhdmUgdG8gcGFyc2UgdGhlIGxhYmVsIHN0YWNrLg0KPiA+Pj4+ IEF0IHdoaWNoIHBvaW50IC4uLg0KPiA+Pj4NCj4gPj4+IEF0IHRoZSBib3R0b20gb2YgdGhlIGxh YmVsIHN0YWNrLg0KPiA+Pj4NCj4gPj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+IFhpYW9odQ0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pj4gWW91cnMsDQo+ID4+Pj4gSm9lbA0KPiA+Pj4+DQo+ID4+Pj4gT24g My8xNy8xNiAxMTozMSBBTSwgU3Rld2FydCBCcnlhbnQgd3JvdGU6DQo+ID4+Pj4+IFllcywgdGhl IE1QTFMgbGFiZWwgc2hvdWxkIGJlIHNlZW4gYXMgYW4gaW5zdHJ1Y3Rpb24gLSB3aGljaCBpcw0K PiA+Pj4+PiBleGFjdGx5IHdoYXQgaXQgaXMsIGFuZCBhbHdheXMgaGFzIGJlZW4uDQo+ID4+Pj4+ DQo+ID4+Pj4+IFlvdSBjYW4gdHJpdmlhbGx5IGNhcnJ5IE1QTFMgb3ZlciBJUC4NCj4gPj4+Pj4N Cj4gPj4+Pj4gV2UgZG8gY2FycnkgTVBMUyBvdmVyIEV0aGVybmV0Lg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBJbiB0aGUgYWJvdmUgY2FzZXMgTVBMUyBpcyB0aGUgaW5zdHJ1Y3Rpb24sIGFuZCBJUCBhbmQg RXRoZXJuZXQNCj4gPj4+Pj4gYXJlIHRoZSBwb2ludCB0byBwb2ludCB0cmFuc3BvcnRzLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiBXaGF0IGlzIG1vcmUgaW50ZXJlc3RpbmcgaXMgaG93IHdlIGNhcnJ5IHRo ZSBtZXRhZGF0YSwgc2luY2UgdGhlcmUNCj4gPj4+Pj4gbWF5IG5lZWQgdG8gYmUgc2V2ZXJhbCBp bnN0YW5jZXMgb2YgdGhlIG1ldGFkYXRhIGluIHRoZSBwYWNrZXQuDQo+ID4+Pj4+DQo+ID4+Pj4+ IFN0ZXdhcnQNCj4gPj4+Pj4NCj4gPj4+Pj4gT24gMTcvMDMvMjAxNiAxMjozMCwgVVRUQVJPLCBK QU1FUyB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqL1JvbiwvKg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICovLyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqL0hhdmUgbm90IGJlZW4gZm9sbG93aW5nIHRo ZSBTRkMgV0cgdGhhdCBjbG9zZWx5IGR1ZSB0byBvdGhlcg0KPiA+Pj4+Pj4gbW9yZSBwcmVzc2lu ZyBuZWVkcyBmb3IgbXkgbmV0d29yay4gVGhhdCBiZWluZyBzYWlkLCBpdCB3b3VsZA0KPiA+Pj4+ Pj4gc2VlbSB0aGF0IGFuIE1QTFMgbGFiZWwgY291bGQgYmUgdXNlZCBhcyB0aGUgYmFzaXMgZm9y IHdoYXQgeW91DQo+ID4+Pj4+PiBhcmUgbG9va2luZyBmb3IgYW4gdGh1cyBjb3VsZCBiZSBhcHBs aWVkIHRvIGFsbCBuZXR3b3JrIHR5cGVzLg0KPiA+Pj4+Pj4gVXNpbmcgdGhlIE1QTFMgbGFiZWwg Zm9ybWF0IGRvZXMgbm90IGZvcmNlIHlvdSB0byBoYXZlIGFuIE1QTFMNCj4gPj4+Pj4+IGVuYWJs ZWQgbmV0d29yayBhbGwgdGhhdCBpcyBuZWVkZWQgaXMgdGhlIHJlcXVpcmVkIGluZm8gdG8gYmUN Cj4gPj4+Pj4+IHBvcHVsYXRlZCBpbiB0aGUgbGFiZWwuIEl0IHNlZW1zIHRoYXQgdGhlIGFyZ3Vt ZW50IGlzIGZvcg0KPiA+Pj4+Pj4gaW5kZXBlbmRlbmNlIG9mIG5ldHdvcmsgdGh1cyBpbnZlbnRp bmcgYSBuZXcgbGFiZWwgaXMgYmFzZWQgb24gYW4NCj4gPj4+Pj4+IGFzc3VtcHRpb24gdGhhdCB1 c2luZyBNUExTIGxhYmVscyBpbXBvc2VzIGFuIE1QTFMgY29udHJvbCBwbGFuZS4NCj4gPj4+Pj4+ IElzIHRoYXQgcmlnaHQ/LyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqLy8qDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gKi9KaW0gVXR0YXJvLyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqLy8qDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gIi9UaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgQVQmVCBwcm9wZXJ0eSwNCj4gPj4+Pj4+IGFyZSBjb25maWRlbnRpYWwsIGFuZCBhcmUgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZQ0KPiA+Pj4+Pj4gaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGlzIGVtYWlsIGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZQ0KPiA+Pj4+ Pj4gbm90IG9uZSBvZiB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9yIG90aGVyd2lzZSBoYXZlIHJl YXNvbiB0bw0KPiA+Pj4+Pj4gYmVsaWV2ZSB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVz c2FnZSBpbiBlcnJvciwgcGxlYXNlDQo+ID4+Pj4+PiBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgbWVzc2FnZSBpbW1lZGlhdGVseSBmcm9tIHlvdXINCj4gPj4+Pj4+IGNvbXB1dGVy LiBBbnkgb3RoZXIgdXNlLCByZXRlbnRpb24sIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsDQo+ ID4+Pj4+PiBwcmludGluZywgb3IgY29weWluZyBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQvLiIqLy8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206Klh1eGlhb2h1IFttYWls dG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPj4+Pj4+ICpTZW50OiogVGh1cnNkYXksIE1hcmNo IDE3LCAyMDE2IDM6NDcgQU0NCj4gPj4+Pj4+ICpUbzoqIFJvbiBQYXJrZXIgPFJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb20+OyBVVFRBUk8sDQo+ID4+IEpBTUVTDQo+ID4+Pj4+PiA8anUx NzM4QGF0dC5jb20+OyBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+Ow0KPiBEb2xn YW5vdywNCj4gPj4+Pj4+IEFuZHJldyAoTm9raWEgLSBTRykgPGFuZHJldy5kb2xnYW5vd0Bub2tp YS5jb20+OyBFWFQgQm90dG9yZmYsDQo+ID4+Pj4+PiBQYXVsIDxwYXVsLmJvdHRvcmZmQGhwZS5j b20+OyBTdGV3YXJ0IEJyeWFudA0KPiA+Pj4+Pj4gPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT47 IGFvLnRpbmdAenRlLmNvbS5jbg0KPiA+Pj4+Pj4gKkNjOiogc2ZjQGlldGYub3JnDQo+ID4+Pj4+ PiAqU3ViamVjdDoqIFJFOiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQt aGVhZGVyDQo+ID4+Pj4+PiB0eXBlIG9mIE5TSA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFJvbiwNCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBUaGUgU0ZDIGFwcHJvYWNoIG9mIGVuY29kaW5nIHRoZSBTRlAgaW5m b3JtYXRpb24gYnkgYW4gTVBMUyBsYWJlbA0KPiA+Pj4+Pj4gc3RhY2sgY2FuIG1lZXQgdGhlIHRy YW5zcG9ydC1pbmRlcGVuZGVuY3kgcmVxdWlyZW1lbnQgdmVyeSB3ZWxsLg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiAqRnJvbToqUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRu ZXR3b3Jrcy5jb21dDQo+ID4+Pj4+PiAqU2VudDoqIFdlZG5lc2RheSwgTWFyY2ggMTYsIDIwMTYg MTE6MjAgUE0NCj4gPj4+Pj4+ICpUbzoqIFVUVEFSTywgSkFNRVM7IERhdmUgRG9sc29uOyBYdXhp YW9odTsgRG9sZ2Fub3csIEFuZHJldw0KPiA+Pj4+Pj4gKE5va2lhIC0gU0cpOyBFWFQgQm90dG9y ZmYsIFBhdWw7IFN0ZXdhcnQgQnJ5YW50Ow0KPiA+Pj4+Pj4gYW8udGluZ0B6dGUuY29tLmNuIDxt YWlsdG86YW8udGluZ0B6dGUuY29tLmNuPg0KPiA+Pj4+Pj4gKkNjOiogc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiA+Pj4+Pj4gKlN1YmplY3Q6KiBSRTogW3NmY10gW0dSQVlN QUlMXSBSZTogQWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlcg0KPiA+Pj4+Pj4gdHlwZSBvZiBOU0gN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBKYW1lcywNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJIGNhbuKAmXQg c3BlYWsgZm9yIHRoZSBlbnRpcmUgZ3JvdXAsIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlDQo+ID4+ Pj4+PiBkZWNpc2lvbiBub3QgdG8gc3RhbmRhcmRpemUgb24gTVBMUyBhcyB0aGUgZm9yd2FyZGlu ZyBwYXJhZGlnbQ0KPiA+Pj4+Pj4gd2FzIHRvIG1ha2UgU0ZDIGJyb2FkZXIgc3VjaCB0aGF0IGl0 IGNvdWxkIHV0aWxpemUgTUFDIGJhc2VkDQo+ID4+Pj4+PiBuZXR3b3JrcywgSVAgYmFzZWQgbmV0 d29ya3MsIGFuZCBJUC1vdmVyLU1QTFMgYmFzZWQgbmV0d29ya3MuDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gUm9uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206KlVUVEFSTywgSkFNRVMgW21haWx0bzpq dTE3MzhAYXR0LmNvbV0NCj4gPj4+Pj4+ICpTZW50OiogV2VkbmVzZGF5LCBNYXJjaCAxNiwgMjAx NiAxMToxMSBBTQ0KPiA+Pj4+Pj4gKlRvOiogUm9uIFBhcmtlciA8Um9uX1BhcmtlckBhZmZpcm1l ZG5ldHdvcmtzLmNvbQ0KPiA+Pj4+Pj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPj47IERhdmUgRG9sc29uDQo+ID4+Pj4+PiA8ZGRvbHNvbkBzYW5kdmluZS5jb20gPG1h aWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+OyBYdXhpYW9odQ0KPiA+Pj4+Pj4gPHh1eGlhb2h1 QGh1YXdlaS5jb20gPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj47IERvbGdhbm93LA0KPiA+ Pj4+IEFuZHJldw0KPiA+Pj4+Pj4gKE5va2lhIC0gU0cpDQo+ID4+Pj4+Pg0KPiA+PiA8PG1haWx0 bzphbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+Ow0K PiA+Pj4+IEVYVA0KPiA+Pj4+Pj4gQm90dG9yZmYsIFBhdWwgPHBhdWwuYm90dG9yZmZAaHBlLmNv bQ0KPiA+Pj4+Pj4gPG1haWx0bzpwYXVsLmJvdHRvcmZmQGhwZS5jb20+PjsgU3Rld2FydCBCcnlh bnQNCj4gPj4+Pj4+IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20gPG1haWx0bzpzdGV3YXJ0LmJy eWFudEBnbWFpbC5jb20+PjsNCj4gPj4+Pj4+IGFvLnRpbmdAenRlLmNvbS5jbiA8bWFpbHRvOmFv LnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNm Y0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICpTdWJqZWN0OiogUkU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6 IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXINCj4gPj4+Pj4+IHR5cGUgb2YgTlNIDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gKi9Db21tZW50cyBJbi1MaW5lLyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqLy8q DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKi9KaW0gVXR0YXJvLyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAq Ly8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gIi9UaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgQVQmVCBwcm9wZXJ0eSwNCj4gPj4+Pj4+IGFyZSBjb25maWRlbnRp YWwsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZQ0KPiA+Pj4+Pj4g aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGlzIGVtYWlsIGlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZQ0KPiA+Pj4+Pj4gbm90IG9uZSBvZiB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9yIG90 aGVyd2lzZSBoYXZlIHJlYXNvbiB0bw0KPiA+Pj4+Pj4gYmVsaWV2ZSB0aGF0IHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlDQo+ID4+Pj4+PiBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBpbW1lZGlhdGVseSBmcm9tIHlvdXINCj4g Pj4+Pj4+IGNvbXB1dGVyLiBBbnkgb3RoZXIgdXNlLCByZXRlbnRpb24sIGRpc3NlbWluYXRpb24s IGZvcndhcmRpbmcsDQo+ID4+Pj4+PiBwcmludGluZywgb3IgY29weWluZyBvZiB0aGlzIGVtYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQvLiIqLy8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206 KlJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPiA+ Pj4+Pj4gKlNlbnQ6KiBXZWRuZXNkYXksIE1hcmNoIDE2LCAyMDE2IDEwOjAxIEFNDQo+ID4+Pj4+ PiAqVG86KiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20NCj4gPj4+Pj4+IDxtYWls dG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PjsgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20N Cj4gPj4+Pj4+IDxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+OyBVVFRBUk8sIEpBTUVTIDxq dTE3MzhAYXR0LmNvbQ0KPiA+Pj4+Pj4gPG1haWx0bzpqdTE3MzhAYXR0LmNvbT4+OyBEb2xnYW5v dywgQW5kcmV3IChOb2tpYSAtIFNHKQ0KPiA+Pj4+Pj4NCj4gPj4gPDxtYWlsdG86YW5kcmV3LmRv bGdhbm93QG5va2lhLmNvbT5hbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsNCj4gPj4+PiBFWFQN Cj4gPj4+Pj4+IEJvdHRvcmZmLCBQYXVsIDxwYXVsLmJvdHRvcmZmQGhwZS5jb20NCj4gPj4+Pj4+ IDxtYWlsdG86cGF1bC5ib3R0b3JmZkBocGUuY29tPj47IFN0ZXdhcnQgQnJ5YW50DQo+ID4+Pj4+ PiA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tIDxtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwu Y29tPj47DQo+ID4+Pj4+PiBhby50aW5nQHp0ZS5jb20uY24gPG1haWx0bzphby50aW5nQHp0ZS5j b20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJFOiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBBZGRpbmcgYW4g TlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+PiB0eXBlIG9mIE5TSA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IE15IHJlY29sbGVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbiBhbmQgYW5hbHlzaXMgb2YgTVBMUyBm b3J3YXJkaW5nDQo+ID4+Pj4+PiB0byBzdXBwb3J0IFNGQyB3YXMgbm90IG9yaWVudGVkIGFyb3Vu ZCBoaWVyYXJjaGljYWwgU0ZDIGRvbWFpbnMuDQo+ID4+Pj4+PiBJbnN0ZWFkLCBJIHRob3VnaHQg dGhlIGRpc2N1c3Npb24gd2FzIGFyb3VuZCBhbiBNUExTIGxhYmVsIHBlciBTRg0KPiA+Pj4+Pj4g aW5zdGFuY2Ugc28gdGhhdCB0aGUgc3RhY2sgb2YgTVBMUyBsYWJlbHMgcHJvdmlkZWQgdGhlIGZ1 bGwgU0ZQL1JTUA0KPiA+Pj4+Pj4gZGVzY3JpcHRpb24uICAgIEFuIGVsZWdhbnQgYXBwcm9hY2gs IGZvciBzdXJlLCBidXQgbm90IG9uZSBhZG9wdGVkIGJ5DQo+ID4+Pj4+PiB0aGUgV0cuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gKi9bSmltIFU+XSBXYXMgdGhpcyBkZWNpc2lvbiBiYXNlZCBvbiB0aGUg bm90aW9uIHRoYXQgYWxsIGZhYnJpY3MNCj4gPj4+Pj4+IGFyZSBJUCBvbmx5Pz8gSU1PIHRoZSBt b2RlbCBvZiBhbGwgRENzIGJlaW5nIGxhcmdlIGFuZCBJUCBvbmx5IGlzDQo+ID4+Pj4+PiBub3Qg YSBjb3JyZWN0IGFzc3VtcHRpb24uLyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGUgY3VycmVudCBk aXNjdXNzaW9uIG9mIE1QTFMgaXMgbW9yZSBvZiB0aGUgaGllcmFyY2hpY2FsIG5hdHVyZQ0KPiA+ Pj4+Pj4g4oCTIGEgc3RhY2sgb2YgbGFiZWxzIGluIHRoZSBnZW5lcmFsIGNhc2UgcmVwcmVzZW50 cyBhIHNldCBvZiBuZXN0ZWQgTFNQcy4NCj4gPj4+Pj4+IEZvciBTRkMsIHRoZSBkaXNjdXNzaW9u IGlzIHRoYXQgYSBzdGFjayBvZiBOU0ggcmVwcmVzZW50cyBhIHN0YWNrDQo+ID4+Pj4+PiBvZiBw ZXItU0ZDLWRvbWFpbiBTRlBzLiBCdXQgYW4gaW5kaXZpZHVhbCBOU0ggZG9lcyBub3QNCj4gPj4+ Pj4+IHNlbGYtZGVzY3JpYmUgdGhlIFNGUC9SU1AgYXQgaXRzIG93biBkb21haW4gbGV2ZWwsIHJl bHlpbmcNCj4gPj4+Pj4+IGluc3RlYWQgb24gYSBmbGF0IGlkZW50aWZpZXIgKFNGUCBJRCkgdGhh dCBpcyB1c2VkIHRvIGxvb2t1cCB0aGUgZnVsbA0KPiBTRlAvUlNQLg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IFJvbg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICpGcm9tOipEYXZlIERvbHNvbiBbbWFpbHRvOmRk b2xzb25Ac2FuZHZpbmUuY29tXQ0KPiA+Pj4+Pj4gKlNlbnQ6KiBXZWRuZXNkYXksIE1hcmNoIDE2 LCAyMDE2IDk6NDggQU0NCj4gPj4+Pj4+ICpUbzoqIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWku Y29tDQo+ID4+IDxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+Ow0KPiA+Pj4+Pj4gVVRUQVJP LCBKQU1FUyA8anUxNzM4QGF0dC5jb20gPG1haWx0bzpqdTE3MzhAYXR0LmNvbT4+Ow0KPiA+PiBE b2xnYW5vdywNCj4gPj4+Pj4+IEFuZHJldyAoTm9raWEgLSBTRykNCj4gPj4+Pj4+DQo+ID4+IDw8 bWFpbHRvOmFuZHJldy5kb2xnYW5vd0Bub2tpYS5jb20+YW5kcmV3LmRvbGdhbm93QG5va2lhLmNv bT47DQo+ID4+Pj4gRVhUDQo+ID4+Pj4+PiBCb3R0b3JmZiwgUGF1bCA8cGF1bC5ib3R0b3JmZkBo cGUuY29tDQo+ID4+Pj4+PiA8bWFpbHRvOnBhdWwuYm90dG9yZmZAaHBlLmNvbT4+OyBSb24gUGFy a2VyDQo+ID4+Pj4+PiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPiA+Pj4+Pj4g PG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj47IFN0ZXdhcnQgQnJ5YW50 DQo+ID4+Pj4+PiA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tIDxtYWlsdG86c3Rld2FydC5icnlh bnRAZ21haWwuY29tPj47DQo+ID4+Pj4+PiBhby50aW5nQHp0ZS5jb20uY24gPG1haWx0bzphby50 aW5nQHp0ZS5jb20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJFOiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBB ZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+PiB0eXBlIG9mIE5TSA0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+IFJlY2FsbCB0aGF0IGRyYWZ0LWhvbW1hLXNmYy1mb3J3YXJkaW5nLW1ldGhvZHMt YW5hbHlzaXMgY29tcGFyZXMNCj4gPj4+Pj4+IHRoZSBkaWZmZXJlbnQgYXBwcm9hY2hlcy4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvbW1h LXNmYy1mb3J3YXJkaW5nLW1ldGhvZHMtYQ0KPiA+Pj4+Pj4gbg0KPiA+Pj4+Pj4gYWx5DQo+ID4+ Pj4+PiBzaXMtMDU+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvbW1hLXNmYy1m b3J3YXJkaW5nLW1ldA0KPiA+Pj4+Pj4gc2lzLTA1PmgNCj4gPj4+Pj4+IHNpcy0wNT5vZHMNCj4g Pj4+Pj4+IC1hbmFseXNpcy0wNQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBNUExTIGFwcHJvYWNo IGZhbGxzIGludG8gdGhlIGNhdGVnb3J5IGRpc2N1c3NlZCBpbiBzZWN0aW9uDQo+ID4+Pj4+PiAz LjEuMiwg4oCcTWV0aG9kIDI6IEZvcndhcmRpbmcgd2l0aCBTdGFja2VkIEhlYWRlcnPigJ0sDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gd2hlcmVhcyB0aGUgTlNIIGFwcHJvYWNoIGZhbGxzIGludG8gc2Vj dGlvbiAzLjEuMywg4oCcTWV0aG9kMzoNCj4gPj4+Pj4+IEZvcndhcmRpbmcgYmFzZWQgb24gU2Vy dmljZSBDaGFpbiBJZGVudGlmaWVyc+KAnS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBTZWN0aW9uIDQg YW5hbHl6ZXMgdGhlIGRpZmZlcmVudCBtZXRob2RzLCB3aXRoIHByb3MgYW5kIGNvbnMgZm9yDQo+ ID4+Pj4+PiBhbGwgb2YgdGhlIGFwcHJvYWNoZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gLURhdmUN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddICpPbiBCZWhhbGYgT2YgKlh1eGlhb2h1DQo+ID4+Pj4+PiAqU2VudDoqIFR1ZXNkYXksIE1h cmNoIDE1LCAyMDE2IDg6MjEgUE0NCj4gPj4+Pj4+ICpUbzoqIFVUVEFSTywgSkFNRVM7IERvbGdh bm93LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBFWFQgQm90dG9yZmYsDQo+ID4+Pj4+PiBQYXVsOyBS b24gUGFya2VyOyBTdGV3YXJ0IEJyeWFudDsgYW8udGluZ0B6dGUuY29tLmNuDQo+ID4+Pj4+PiA8 bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ICpDYzoqIHNmY0BpZXRmLm9yZyA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICpTdWJqZWN0OiogUmU6IFtzZmNdIFtHUkFZ TUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXINCj4gPj4+Pj4+IHR5cGUgb2YgTlNI DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gV2hlbiBhcHBseWluZyBhIHBhcnRpY3VsYXIgU0ZDIChpLmUu LCBhbiBvcmRlcmVkIGxpc3Qgb2YgU0ZzKSB0bw0KPiA+Pj4+Pj4gdGhlIHNlbGVjdGVkIHRyYWZm aWMsIHRoZSB0cmFmZmljIG5lZWRzIHRvIGJlIHN0ZWVyZWQgdGhyb3VnaCB0aGUNCj4gPj4+Pj4+ IGNvcnJlc3BvbmRpbmcgU0ZQIChpLmUuLCBhbiBvcmRlcmVkIGxpc3Qgb2YgU0ZGcyBhbmQgU0Zz KSBpbiB0aGUNCj4gPj4+Pj4+IFNGQy1lbmFibGVkIG5ldHdvcmsuIE1QTFMtU1BSSU5HIGlzIGEg cGFydGljdWxhciBNUExTIHNvdXJjZQ0KPiA+Pj4+Pj4gcm91dGluZyBwYXJhZGlnbSB3aGVyZSB0 aGUgZXhwbGljaXQgcGF0aCBpbmZvcm1hdGlvbiAoaS5lLiwgYW4NCj4gPj4+Pj4+IG9yZGVyZWQg bGlzdCBvZiBleHBsaWNpdCBob3BzKSBpcyBlbmNvZGVkIGFzIGEgbGFiZWwgc3RhY2sgKGkuZS4s DQo+ID4+Pj4+PiBhbiBvcmRlcmVkIGxpc3Qgb2YgbGFiZWxzIHdpdGggZWFjaCBpbmRpY2F0aW5n IGEgcGFydGljdWxhcg0KPiA+Pj4+Pj4gZXhwbGljaXQgaG9wKSBhbmQgdGhlbiBwaWdneWJhY2tl ZCBvbiB0aGUgc291cmNlIHJvdXRlZCBwYWNrZXRzLg0KPiA+Pj4+Pj4gVGhlIE1QTFMtU1BSSU5H IHBhcmFkaWdtIGNhbiBiZSBlYXNpbHkgbGV2ZXJhZ2VkIHRvIHN0ZWVyIHRoZQ0KPiA+Pj4+Pj4g c2VsZWN0ZWQgdHJhZmZpYyB0aHJvdWdoIGEgcGFydGljdWxhciBTRlAgYnkgZW5jb2RpbmcgdGhl IFNGUA0KPiA+Pj4+Pj4gaW5mb3JtYXRpb24gYXMgYW4gTVBMUyBsYWJlbCBzdGFjayAoaS5lLiwg YW4gb3JkZXJlZCBsaXN0IG9mDQo+ID4+Pj4+PiBsYWJlbHMgd2l0aCBlYWNoIGluZGljYXRpbmcg YSBwYXJ0aWN1bGFyDQo+ID4+Pj4gU0ZGIG9yIFNGKS4NCj4gPj4+Pj4+IEluIHRoaXMgd2F5LCBT RkZzIGNvdWxkIGJlIGltcGxlbWVudGVkIG9uIGV4aXN0aW5nIE1QTFMgc3dpdGNoZXMNCj4gPj4+ Pj4+IHdpdGhvdXQgYW55IGNoYW5nZSB0byB0aGUgZGF0YS1wbGFuZSBwcm92aWRlZCB0aGF0IFNG cyBhcmUNCj4gPj4+Pj4+IGNhcGFibGUgb2YgcmVjb2duaXppbmcgTVBMUyBwYWNrZXRzLiAgQXMg cG9pbnRlZCBvdXQgYnkgc29tZWJvZHkNCj4gPj4+Pj4+IGVsc2UsIGl04oCZcyBtdWNoIHN0cmFp Z2h0Zm9yd2FyZCB0byBzdXBwb3J0IHRoZSBzdGFjayBvZiBTRkMNCj4gPj4+Pj4+IGVuY2Fwc3Vs YXRpb25zIGlmIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBpcyBpbXBsZW1lbnRlZCBpbiB0aGUNCj4g Pj4+Pj4+IGZvcm0gb2YgYW4NCj4gPj4gTVBMUyBsYWJlbCBzdGFjay4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gWGlhb2h1DQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVo YWxmIE9mICpVVFRBUk8sDQo+ID4+Pj4+PiBKQU1FUw0KPiA+Pj4+Pj4gKlNlbnQ6KiBUdWVzZGF5 LCBNYXJjaCAxNSwgMjAxNiA4OjQ2IFBNDQo+ID4+Pj4+PiAqVG86KiBEb2xnYW5vdywgQW5kcmV3 IChOb2tpYSAtIFNHKTsgRVhUIEJvdHRvcmZmLCBQYXVsOyBSb24NCj4gPj4+Pj4+IFBhcmtlcjsg U3Rld2FydCBCcnlhbnQ7IGFvLnRpbmdAenRlLmNvbS5jbg0KPiA+Pj4+Pj4gPG1haWx0bzphby50 aW5nQHp0ZS5jb20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBB ZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+PiB0eXBlIG9mIE5TSA0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+ICovSWYgd2UgaGF2ZSBhbiBNUExTIGVuYWJsZWQgZmFicmljIHdvdWxkbuKAmXQg aXQgYmUgc2ltcGxlciB0bw0KPiA+Pj4+Pj4gd2VhdmUgTlNIIGludG8gaXQgaWYgaXQgYWxsIHVz ZXMgTVBMUz8gSWYgbm90IGhvdyB3b3VsZCB0aGUNCj4gPj4+Pj4+IGludGVyYWN0aW9uIGJldHdl ZW4gdGhlIHR3byBlbnZpcm9ubWVudHMgd29yaz8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICovLyoN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiAqL0ppbSBVdHRhcm8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICov LyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAiL1RoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBBVCZUIHByb3BlcnR5LA0KPiA+Pj4+Pj4gYXJlIGNvbmZpZGVudGlh bCwgYW5kIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlDQo+ID4+Pj4+PiBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoaXMgZW1haWwgaXMgYWRkcmVzc2VkLiBJZiB5 b3UgYXJlDQo+ID4+Pj4+PiBub3Qgb25lIG9mIHRoZSBuYW1lZCByZWNpcGllbnQocykgb3Igb3Ro ZXJ3aXNlIGhhdmUgcmVhc29uIHRvDQo+ID4+Pj4+PiBiZWxpZXZlIHRoYXQgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UNCj4gPj4+Pj4+IG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGltbWVkaWF0ZWx5IGZyb20geW91cg0KPiA+ Pj4+Pj4gY29tcHV0ZXIuIEFueSBvdGhlciB1c2UsIHJldGVudGlvbiwgZGlzc2VtaW5hdGlvbiwg Zm9yd2FyZGluZywNCj4gPj4+Pj4+IHByaW50aW5nLCBvciBjb3B5aW5nIG9mIHRoaXMgZW1haWwg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC8uIiovLyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqRnJvbToq c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkRvbGdhbm93 LA0KPiA+Pj4+Pj4gQW5kcmV3IChOb2tpYSAtIFNHKQ0KPiA+Pj4+Pj4gKlNlbnQ6KiBNb25kYXks IE1hcmNoIDE0LCAyMDE2IDExOjUyIFBNDQo+ID4+Pj4+PiAqVG86KiBFWFQgQm90dG9yZmYsIFBh dWwNCj4gPj4+Pj4+IDw8bWFpbHRvOnBhdWwuYm90dG9yZmZAaHBlLmNvbT5wYXVsLmJvdHRvcmZm QGhwZS5jb20+OyBSb24NCj4gUGFya2VyDQo+ID4+Pj4+PiA8Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbQ0KPiA+Pj4+Pj4gPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tPj47IFN0ZXdhcnQgQnJ5YW50DQo+ID4+Pj4+PiA8c3Rld2FydC5icnlhbnRAZ21haWwuY29t IDxtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tPj47DQo+ID4+Pj4+PiBhby50aW5nQHp0 ZS5jb20uY24gPG1haWx0bzphby50aW5nQHp0ZS5jb20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBzZmNA aWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJlOiBb c2ZjXSBbR1JBWU1BSUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+PiB0 eXBlIG9mIE5TSA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEZvbGxvd2luZyDigJxuZXh0IGhlYWRlcuKA nSBhcHByb2FjaCAgaXMgc2ltcGxlIGFuZCB0aGUgTlNIIGhlYWRlciBpcw0KPiA+Pj4+Pj4gYWxy ZWFkeSBidWlsdCBsaWtlIHRoYXQuIEludHJvZHVjaW5nIE1QTFMgbGlrZSBhcHByb2FjaCB3b3Vs ZCBhZGQNCj4gPj4+Pj4+IHlldCBhbm90aGVyIG1lY2hhbmlzbSB0byB0cmF2ZXJzZSB0aGUgaGVh ZGVycywgd2hpY2ggd291bGQgbWFrZQ0KPiA+Pj4+Pj4gaC93IG1vcmUgY29tcGxleC4NCj4gPj4+ Pj4+DQo+ID4+Pj4+PiBJdCBpcyB0cnVlIHRoYXQgaC93IGNhbiBvbmx5IGxvb2sgYXQgWCBCeXRl cyAoWCBkZXBlbmRpbmcgb24gaC93KS4NCj4gPj4+Pj4+IFRoaXMgaXMgdHJ1ZSBmb3IgbWFueSBo ZWFkZXJzIG5vdCBvbmx5IHRoaXMgYW5kIGV2ZW4gdG9kYXkNCj4gPj4+Pj4+ICh3aXRob3V0DQo+ ID4+Pj4+PiBOU0gpIHlvdSBjYW4gZW5kLXVwIHdpdGggcGF5bG9hZCBiZWluZyB2ZXJ5IGRlZXAg aW4gYSBwYWNrZXQuIEF0DQo+ID4+Pj4+PiB0aGUgZW5kIHdlIG5lZWQgdG8gaGF2ZSBhIGZsZXhp YmxlIG1lY2hhbmlzbSB3aGljaCBOU0ggbmVzdGluZw0KPiA+Pj4+Pj4gd291bGQgcHJvdmlkZS4g SWYgc29tZW9uZSDigJxhYnVzZXMgaXTigJ0gdGhpcyBjYW4gbGVhZCB0byB2YXJpb3VzDQo+ID4+ Pj4+PiBpc3N1ZXMuIEl0IGlzIHByb2JhYmx5IHdvcnRoIG5vdGluZyB0aGF0IGluIHRoZSBkcmFm dCBpbmNsdWRpbmcNCj4gPj4+Pj4+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIChieSBhZGRpbmcg bGFyZ2UgaGVhZGVycyBpdCB3aWxsIGJlDQo+ID4+Pj4+PiBoYXJkZXIgdG8gcGVyZm9ybSBwYXls b2FkIGJhc2VkIEFDTCBERG9TIHByb3RlY3Rpb24gaW4gcm91dGVycyBmb3INCj4gZXhhbXBsZSku DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQW5kcmV3DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gMjAxNi0w My0xNSwgMzowMyBBTSwgInNmYyBvbiBiZWhhbGYgb2YgRVhUIEJvdHRvcmZmLCBQYXVsIiB3cm90 ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBKdXN0IG9uZSBtb3JlIGNvbmNlcm4gYWJvdXQgdGhl IHN0YWNrIGlzIGhvdyBkZWVwIGl0IHdpbGwgbmVzdC4NCj4gPj4+Pj4+ICAgIEhhcmR3YXJlIHN3 aXRjaCBpbXBsZW1lbnRhdGlvbnMgYXJlIHR5cGljYWxseSBsaW1pdGVkIGluIHRoZQ0KPiA+Pj4+ IGRlcHRoDQo+ID4+Pj4+PiAgICB0aGV5IGxvb2sgaW50byB0aGUgcGFja2V0LiBJZiB0aGUgaGFy ZHdhcmUgbmVlZHMgdG8gbG9vayBhdCB0aGUNCj4gPj4+Pj4+ICAgIG9yaWdpbmFsIHBhY2tldCBo ZWFkZXJzLCB0aGVuIGhhcmR3YXJlIHdvdWxkIG5lZWQgdG8gc2tpcCBvdmVyDQo+ID4+Pj4gdGhl DQo+ID4+Pj4+PiAgICBzdGFjayBvZiBOU0ggaGVhZGVycyB0byByZWFjaCB0aGUgb3JpZ2luYWwg cGFja2V0LiBJZiB0aGUgTlNIDQo+ID4+Pj4+PiAgICBzdGFjayBpcyB0b28gZGVlcCBpdCBtYXkg ZXhjZWVkIHRoZSBoYXJkd2FyZSBkZXB0aCBsaW1pdHMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAg Q2hlZXJzLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBQYXVsDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gICAgKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqT24g QmVoYWxmIE9mICpSb24NCj4gPj4+PiBQYXJrZXINCj4gPj4+Pj4+ICAgICpTZW50OiogTW9uZGF5 LCBNYXJjaCAxNCwgMjAxNiAxMTo0NSBBTQ0KPiA+Pj4+Pj4gICAgKlRvOiogU3Rld2FydCBCcnlh bnQNCj4gPj4+Pj4+DQo+IDw8bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT5zdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb20+Ow0KPiA+Pj4+Pj4gICAgYW8udGluZ0B6dGUuY29tLmNuIDxtYWls dG86YW8udGluZ0B6dGUuY29tLmNuPg0KPiA+Pj4+Pj4gICAgKkNjOiogc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiA+Pj4+Pj4gICAgKlN1YmplY3Q6KiBSZTogW3NmY10gW0dS QVlNQUlMXSBSZTogQWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlcg0KPiA+Pj4+IHR5cGUNCj4gPj4+ Pj4+ICAgIG9mIE5TSA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgIEkgbGlrZSB0aGUgc2VsZiBkZXNj cmliaW5nIHN0YWNrIG9mIE5TSCBoZWFkZXJzIGFuZCBJIGxpa2UgdGhlDQo+ID4+Pj4+PiAgICBm aXJzdCBvbmUgYmVpbmcgdGhlIOKAnGN1cnJlbnTigJ0gc2NvcGluZy4gICBCdXQsIG9uZSBkaWZm ZXJlbmNlDQo+ID4+Pj4+PiAgICBiZXR3ZWVuIE1QTFMgYW5kIE5TSOKApiAgIE1QTFMgZm9yd2Fy ZGluZyBpcyBnZW5lcmFsbHkgaGFuZGxlZA0KPiA+PiBieQ0KPiA+Pj4+Pj4gICAgbG9va2luZyBv bmx5IGF0IHRoZSBNUExTIGxhYmVscyB0aGF0IGFyZSDigJxpbiBzY29wZeKAnSBmb3IgdGhlDQo+ ID4+Pj4+PiAgICBjdXJyZW50IG5vZGUgKGkuZS4sIHN0YXJ0aW5nIGF0IHRoZSB0b3Atb2Ytc3Rh Y2spIGFuZCBub3QgbmVlZGluZw0KPiA+Pj4+Pj4gICAgdG8gbG9jYXRlIGFuZCBwcm9jZXNzIHRo ZSDigJxwYXlsb2Fk4oCdIGJleW9uZCB0aGUgYm90dG9tLW9mLXN0YWNrLg0KPiA+Pj4+Pj4gICAg QnV0LCBpbiBOU0gsIG1vc3QgcHJvY2Vzc2luZyB3aWxsIHJlcXVpcmUgbG9jYXRpb24gb2YgdGhl DQo+ID4+Pj4+PiAgICDigJxwYXlsb2Fk4oCdIGJleW9uZCB0aGUgbGFzdCBOU0ggaGVhZGVyLiAg IEl0IGlzIGluZWZmaWNpZW50IHRvIGhhdmUNCj4gPj4+Pj4+ICAgIHRvIHdhbGsgdGhlIHN0YWNr IG9mIE5TSCBoZWFkZXJzIGluIG9yZGVyIHRvIGxvY2F0ZSB0aGF0DQo+ID4+Pj4+PiAgICBwYXls b2FkLiAgICBJZiBlYWNoIE5TSCBoZWFkZXIgdGhhdCB3YXMgcHVzaGVkIG9udG8gdGhlIHN0YWNr DQo+ID4+Pj4gYWxzbw0KPiA+Pj4+Pj4gICAgaW5jbHVkZWQgYW4gb2Zmc2V0IHRvIGRpcmVjdGx5 IGxvY2F0ZSB0aGUgcGF5bG9hZCAoZWFjaCBuZXcgb25lDQo+ID4+Pj4+PiAgICBzaW1wbHkgYWRk cyBpdHMgb3duIGJ5dGUgc2l6ZSksIHRoZW4gdGhpcyBwcm9jZXNzaW5nIGluZWZmaWNpZW5jeQ0K PiA+Pj4+Pj4gICAgd291bGQgYmUgbWl0aWdhdGVkLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgIFJv bg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gKk9uIEJlaGFsZiBPZg0KPiA+Pj4+Pj4gKlN0ZXdhcnQNCj4gPj4+PiBCcnlhbnQN Cj4gPj4+Pj4+ICAgICpTZW50OiogTW9uZGF5LCBNYXJjaCAxNCwgMjAxNiA1OjQwIEFNDQo+ID4+ Pj4+PiAgICAqVG86KiBhby50aW5nQHp0ZS5jb20uY24gPG1haWx0bzphby50aW5nQHp0ZS5jb20u Y24+DQo+ID4+Pj4+PiAgICAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4+Pj4+PiAgICAqU3ViamVjdDoqIFtHUkFZTUFJTF0gUmU6IFtzZmNdIEFkZGluZyBhbiBO U0gubmV4dC1oZWFkZXIgdHlwZQ0KPiA+Pj4+Pj4gb2YgTlNIDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+ICAgIEhhdmluZyByZW1pbmRlZCBteXNlbGYgb2YgdGhlIE5TSCBoZWFkZXIgc3Ry dWN0dXJlLCBJIHNlZSB0aGF0DQo+ID4+Pj4gdGhpcw0KPiA+Pj4+Pj4gICAgaXMgbm90IHN0cmlj dGx5IG5lZWRlZCBzaW5jZSB0aGlzIG5hdHVyYWxseSBmaXRzIHdpdGggdGhlIG5leHQNCj4gPj4+ Pj4+ICAgIHByb3RvY29sIGNvbXBvbmVudCBvZiB0aGUgYmFzZSBoZWFkZXIuIFRodXMgc3RhdGlu ZyB0aGF0IHRoZQ0KPiA+Pj4+IHRoZXJlDQo+ID4+Pj4+PiAgICBpcyBubyBhcmNoaXRlY3R1cmFs IGxpbWl0IG9uIHRoZSBudW1iZXIgb2YgU0ZIIGhlYWRlcnMgaW4gYQ0KPiA+Pj4+IHBhY2tldA0K PiA+Pj4+Pj4gICAgaXMgdGhlIG5lY2Vzc2FyeSBhbmQgc3VmZmljaWVudCByZXF1aXJlbWVudCB0 byBhbGxvdyBhbiBhcmJpdGF0cnkNCj4gPj4+Pj4+ICAgIHN0YWNrIG9mIE5TSCBoZWFkZXJzLiBT dGF0aW5nIHRoYXQgbmV3IE5TSCBoZWFkZXJzIGFyZSBhZGRlZCBhdA0KPiA+Pj4+Pj4gICAgdGhl IGZyb250DQo+ID4+Pj4+PiAgICBvZiB0aGUgcGFja2V0LCBhbmQgcHJvY2Vzc2VkIGZpcnN0IGFu ZCBkaXNjYXJkZWQgZmlyc3QgaXMNCj4gPj4+PiBzdWZmaWNpZW50DQo+ID4+Pj4+PiAgICB0byBy ZW1vdmUgYW55IHByb2Nlc3NpbmcgYW1iaWd1aXR5LiBQcm9jZXNzaW5nIHdvdWxkIGFsc28gYmUN Cj4gPj4+PiBzaW1wbGVyDQo+ID4+Pj4+PiAgICBpcyB5b3UgZm9sbG93ZWQgdGhlIE1QTFMgcnVs ZSB0aGF0IHRoZSBvdXRlciBoZWFkZXIgaXMgdGhlDQo+ID4+Pj4+PiBvbmx5DQo+ID4+Pj4gb25l DQo+ID4+Pj4+PiAgICBpbiBzY29wZSB1bnRpbCB0aGF0IGhlYWRlciBpcyBkaXNjYXJkZWQgKHBv cHBlZCkuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgSSBkbyBob3dldmVyIHdvbmRlciB3aGV0aGVy IHRoZSBJRVRGJ3MgYXJjaGl0ZXR1cmFsIHByZWZlcmVuY2UNCj4gPj4+PiBmb3INCj4gPj4+Pj4+ ICAgIHNlbGYgZGVzY3JpYmluZyBwYWNrZXRzIChNUExTIGJlaW5nIHRoZSBleGNlcHRpb24pIGxl YWRzIHVzIHRvDQo+ID4+Pj4gbW9yZQ0KPiA+Pj4+Pj4gICAgY29tcGxleCBhbmQgdGh1cyBsZXNz IGVmZmljZW50IGRhdGFwbGFuZSBkZXNpZ25zIHRoYW4gd2UgY291bGQNCj4gPj4+Pj4+ICAgIG90 aGVyd2lzZQ0KPiA+Pj4+Pj4gICAgYWNoaWV2ZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAtIFN0 ZXdhcnQNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBPbiAxNC8wMy8yMDE2IDAxOjQ0LCBhby50aW5n QHp0ZS5jb20uY24NCj4gPj4+Pj4+ICAgIDxtYWlsdG86YW8udGluZ0B6dGUuY29tLmNuPiB3cm90 ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgU3Rld2FydCwNCj4gPj4+Pj4+DQo+ID4+Pj4+ PiAgICAgICAgVGhhbmtzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICAgICBEbyB5b3UgbWVhbiB3 ZSBzaG91bGQgYWRkIGFuIGluZGljYXRvciBmb3IgdGhlIG5lc3RlZCBOU0g/DQo+ID4+IEkNCj4g Pj4+Pj4+ICAgICAgICBhZ3JlZSBhbnl0aGluZyBuZXcgc2hvdWxkIGJlIGNvbnNpZGVyZWQgY2Fy ZWZ1bGx5LiBBbmQgdGhhdCdzDQo+ID4+Pj4+PiAgICAgICAgd2hhdCB3ZSBhcmUgZG9pbmcgcmln aHQgbm93LjopDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAg5Y+R5Lu25Lq6OiBTdGV3YXJ0IEJyeWFudCA8 c3Rld2FydC5icnlhbnRAZ21haWwuY29tPg0KPiA+Pj4+Pj4gICAgICAgIDxtYWlsdG86c3Rld2Fy dC5icnlhbnRAZ21haWwuY29tPg0KPiA+Pj4+Pj4gICAgICAgIOaUtuS7tuS6ujoNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4ic2ZjQGlldGYub3JnIjxtYWlsdG86c2Zj QGlldGYub3JnPjxzZmNAaWV0Zi4NCj4gPj4+Pj4+IG9yZw0KPiA+Pj4+Pj4+ICwNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiAgICAgICAg5pel5pyfOiAyMDE2LzAzLzExIDE3OjI1DQo+ID4+Pj4+PiAgICAg ICAg5Li76aKYOiBSZTogW3NmY10gQWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlciB0eXBlIG9mIE5T SA0KPiA+Pj4+Pj4gICAgICAgIOWPkeS7tuS6ujogInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3Jn Pg0KPiA+Pj4+Pj4gPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4NCj4gPj4+Pj4+DQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4+IC0NCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+ Pj4gLS0tDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4N Cj4gPj4+Pj4+ICAgICAgICBUaGUgcHJvdG9jb2wgdGhhdCBjaG9zZSB0aGUgbW9zdCBlbGVnYW50 IGFwcHJvYWNoIHRvIGxheWVyaW5nDQo+ID4+Pj4+PiAgICAgICAgb25lIGhlYWRlciBvbiBhbm90 aGVyIHdhcyBNUExTLCB3aXRoIGl0cyBzdGFja2luZyBhcHByb2FjaA0KPiA+Pj4+Pj4gICAgICAg IGFuZCBvbmUgYml0IGVuZCBvZiBzdGFjayBpbmRpY2F0b3IuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g ICAgICAgIFN1Y2ggYSBzaW1wbGUgZ2VuZXJhbCBhcHByb2FjaCBoYXMgbXVjaCB0byBjb21tZW5k IGl0DQo+ID4+Pj4+PiAgICAgICAgYW5kIHlvdSBtaWdodCB0aGluayBzZXJpb3VzbHkgYWJvdXQg YXBwbHlpbmcgaXQgaGVyZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgU3Rld2FydA0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+Pj4+Pj4gICAgICAgIHNmYyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ ICAgICAgICBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPmh0dHBzOi8v d3d3LmlldGYub3JnL20NCj4gPj4+Pj4+IGENCj4gPj4+Pj4+IGlsbQ0KPiA+Pj4+Pj4gYW4vbGlz dGluZm8vc2ZjDQo+ID4+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBz ZmMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+IHNmY0BpZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiA+Pj4+Pg0KPiA+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IHNmYyBtYWlsaW5n IGxpc3QNCj4gPj4+IHNmY0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+IHNmY0BpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Tue Apr 5 06:37:59 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 C4CDA12D951 for ; Tue, 5 Apr 2016 06:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 n3JQQPl7D0Am for ; Tue, 5 Apr 2016 06:33:28 -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 852D912D974 for ; Tue, 5 Apr 2016 06:32:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLP43048; Tue, 05 Apr 2016 13:32:38 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 5 Apr 2016 14:32:32 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 5 Apr 2016 21:32:18 +0800 From: Xuxiaohu To: "UTTARO, JAMES" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH Thread-Index: AQHRgGIbhNHv82pdBEmnzsTX6DSc4Z9dP1yAgAF9ZiCABNXngIABJ6ZAgABDfACAAU4y8IATgfMAgAGu3yo= Date: Tue, 5 Apr 2016 13:32:18 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D537A3F@NKGEML515-MBX.china.huawei.com> References: <56E68706.7090505@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5331C8@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5337B6@NKGEML515-MBX.china.huawei.com> <56EACDC7.7060000@gmail.com> <56EACF91.6070703@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D533D68@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D534964@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D534D9F@NKGEML515-MBX.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.133] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5703BE78.0310, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 753fd124a36cb84618dc75ee40a7c856 Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 06:37:53 -0700 Cc: Ron Parker , "sfc@ietf.org" , "EXT Bottorff, Paul" , "Jim Guichard \(jguichar\)" , "Dolganow, Andrew \(Nokia - SG\)" , "ao.ting@zte.com.cn" , Stewart Bryant , "Joel M. Halpern" , Dave Dolson Subject: Re: [sfc] [GRAYMAIL] Re: Adding an NSH.next-header type of NSH 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, 05 Apr 2016 13:33:36 -0000 SSBmdWxseSBhZ3JlZSB0aGF0IGEgbWF0cml4IG9mIGRhdGEgcGxhbmUgZW5jYXBzIGN1cnJlbnRs eSBpbiB1c2UgYW5kIHdoYXQgZnVuY3Rpb25zIHJlcXVpcmVkIGJ5IFNGQyBhcmUgc3VwcG9ydGVk IHNob3VsZCBiZSBhIG11c3QgYmVmb3JlIGRlc2lnbmluZyBhIG5ldyBkYXRhIHBsYW5lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kt6K8/sjLOiBVVFRBUk8sIEpBTUVTIFtqdTE3MzhAYXR0LmNvbV0NCreiy83Ksbzk OiAyMDE2xOo01MI1yNUgMzo0NA0KytW8/sjLOiBYdXhpYW9odTsgQ2FybG9zIFBpZ25hdGFybyAo Y3BpZ25hdGEpDQqzrcvNOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgSm9lbCBNLiBIYWxwZXJu OyBTdGV3YXJ0IEJyeWFudDsgUm9uIFBhcmtlcjsgRGF2ZSBEb2xzb247IERvbGdhbm93LCBBbmRy ZXcgKE5va2lhIC0gU0cpOyBFWFQgQm90dG9yZmYsIFBhdWw7IGFvLnRpbmdAenRlLmNvbS5jbjsg c2ZjQGlldGYub3JnDQrW98ziOiBSRTogW3NmY10gW0dSQVlNQUlMXSBSZTogQWRkaW5nIGFuIE5T SC5uZXh0LWhlYWRlciB0eXBlIG9mIE5TSA0KDQpTbywgSSBmb3VuZCB0aW1lIHRvIHJlYWQgdGhl IE5TSCBkcmFmdCBpbiBpdHMgZW50aXJldHkuIEEgZmV3IHN1Z2dlc3Rpb25zOg0KDQpJZGVudGlm eSBzcGVjaWZpYyB1c2UgY2FzZXMgdGhhdCByZXF1aXJlIE5TSCBTZWMgMi4yIGxpc3RzIDcgYnJv YWQgYXJlYXMgdGhhdCBhcmUgdG9vIGhpZ2ggbGV2ZWwuDQoNCiBFeGFtcGxlcw0KDQpCdWxsZXQg MiAiU2VydmljZSBDaGFpbiBDb25zdHJ1Y3Rpb24iIGNpdGVzIHRoZSBub3Rpb24gdGhhdCBtb3N0 IGNoYWlucyBhcmUgYnVpbHQgdGhyb3VnaCBtYW51YWwgY29uZmlnIHdoaWNoIGlzIHNsb3cgYW5k IGVycm9yIHByb25lLiBXb3VsZCBhIHByb2Nlc3MgdGhhdCByZWxpZXMgb24gYSBjb250cm9sbGVy IHRvIGNvbmZpZ3VyZSB0aGVzZSBjaGFpbnMgY29ycmVjdCB0aGlzIGRlZmljaWVuY3kgb3IgY2Fu IGl0IG9ubHkgYmUgZml4ZWQgd2l0aCBOU0guDQoNCkJ1bGxldCA0ICJQZXIgU2VydmljZSAocmUp IENsYXNzaWZpY2F0aW9uIiAgSG93IG5lZWRlZCBpcyB0aGlzID8gV2hhdCBwZXJjZW50YWdlIG9m IGNoYWlucyB3aWxsIHJlcXVpcmUgaXQ/IE1vcmUgc3BlY2lmaWMgZXhhbXBsZXMsIHdoYXQgYXJl IHRoZSBhbHRlcm5hdGl2ZXMgc3VjaCBhcyB0aGUgbm90IHJlZGlyZWN0IHRoZSB0byBhIG5ldyBj aGFpbiBidXQgdGFrZSB0ZXJtaW5hbCBhY3Rpb24gdGhlcmUgb3Igc2VuZCB0byBhIGNlbnRyYWxp emVkIGNvbnRyb2xsZXIgLi4uLg0KDQpCdWxsZXQgNiAiTGltaXRlZCBFbmQtdG8tRW5kIFNlcnZp Y2UgVmlzaWJpbGl0eSIgIEEgYml0IGNvbmZ1c2VkIGhlcmUuIERvIHdlIGFudGljaXBhdGUgY2hh aW5zIHNwYW5uaW5nIG11bHRpcGxlIGRhdGEgY2VudGVycz8gVGhpcyB3b3VsZCBzZWVtIHRvIHJl cXVpcmUgcXVpdGUgYSBiaXQgb2YgZWZmb3J0IGZvciB0aGUgdHJhbnNwb3J0IGxheWVyIGkuZSBN UExTLg0KDQpJTU8gdGhpcyBlbnRpcmUgc2VjdGlvbiBuZWVkcyB0byBiZSBtYWRlIGZvciBtb3Jl IHNwZWNpZmljLiBZb3UgbWF5IGNvbnNpZGVyIHB1bGxpbmcgaXQgb3V0IGludG8gYSByZXFzL3Vz ZSBjYXNlIGRyYWZ0Lg0KDQpTZWMgMi4zIGlkZW50aWZpZXMgaG93IGFsbCBvZiB0aGUgaXNzdWVz IGluIFNlYyAyLjIgYXJlIGFtZWxpb3JhdGVkLiBOZWVkIGEgYmV0dGVyIGRlZmluaXRpb24gb2Yg U2VjIDIuMiBwcmlvciB0byBhc3NpZ25pbmcgdGhlIE5TSCByZW1lZHkgaW4gU2VjIDIuMw0KDQpB bHRob3VnaCBJIHJlYWQgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IEkgd2lsbCBub3QgY29tbWVu dCBhcyB0aGUgZHJpdmVycyBmb3IgdGhpcyBuZXcgZGF0YSBwbGFuZSBlbmNhcCBpcyBub3QgY2xl YXIgdG8gbWUuIEhhdmUgeW91IHJlYWNoZWQgb3V0IHRvIHRoZSBXR3MgdGhhdCBkZWFsIHdpdGgg ZGF0YSBwbGFuZSBlbmNhcCB0byBzZWUgaWYgdGhleSBjYW4gbWVldCB0aGUgcmVxcz8NCg0KSXQg d291bGQgYmUgdXNlZnVsIHRvIHNlZSBhIG1hdHJpeCBvZiBkYXRhIHBsYW5lIGVuY2FwcyBjdXJy ZW50bHkgaW4gdXNlIGFuZCB3aGF0IGZ1bmN0aW9ucyByZXF1aXJlZCBieSBTRkMgYXJlIHN1cHBv cnRlZC4gVGhpcyBtYXkgbGVhZCB0byBhIHNvbHV0aW9uIHRoYXQgZG9lcyBub3QgY3JlYXRlIGEg bmV3IGRhdGEgZW5jYXAgYnV0IGV4dGVuZHMgb25lIG9mIHRoZSBjdXJyZW50IHNldC4NCg0KSWYg dGhlIG5vdGlvbiBoZXJlIGlzIHRvIGFic3RyYWN0IGRhdGEgcGxhbmUgZW5jYXAgYXMgdGhlcmUg YXJlIHRvbyBtYW55LCB0aGVuIGl0IG1heSBiZSBiZXN0IHRvIHBpY2sgdGhlIG9uZSB0aGF0IG1v c3Qgc2F0aXNmaWVzIHRoZSBTRkMgbmVlZCBhbmQgcHV0IGEgc3Rha2UgaW4gdGhlIGdyb3VuZC4N Cg0KSmltIFV0dGFybw0KDQoNCiJUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgQVQmVCBwcm9wZXJ0eSwgYXJlIGNvbmZpZGVudGlhbCwgYW5kIGFyZSBpbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhpcyBlbWFpbCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IG9uZSBvZiB0aGUgbmFt ZWQgcmVjaXBpZW50KHMpIG9yIG90aGVyd2lzZSBoYXZlIHJlYXNvbiB0byBiZWxpZXZlIHRoYXQg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgaW1tZWRpYXRlbHkgZnJvbSB5b3VyIGNv bXB1dGVyLiBBbnkgb3RoZXIgdXNlLCByZXRlbnRpb24sIGRpc3NlbWluYXRpb24sIGZvcndhcmRp bmcsIHByaW50aW5nLCBvciBjb3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4iDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFh1eGlhb2h1IFtt YWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIyLCAyMDE2 IDk6NTkgUE0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2Nv LmNvbT4NCkNjOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSA8amd1aWNoYXJAY2lzY28uY29tPjsg Sm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsgU3Rld2FydCBCcnlhbnQgPHN0 ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT47IFVUVEFSTywgSkFNRVMgPGp1MTczOEBhdHQuY29tPjsg Um9uIFBhcmtlciA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT47IERhdmUgRG9sc29u IDxkZG9sc29uQHNhbmR2aW5lLmNvbT47IERvbGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpIDxh bmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsgRVhUIEJvdHRvcmZmLCBQYXVsIDxwYXVsLmJvdHRv cmZmQGhwZS5jb20+OyBhby50aW5nQHp0ZS5jb20uY247IHNmY0BpZXRmLm9yZw0KU3ViamVjdDog UkU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXIgdHlwZSBv ZiBOU0gNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBNYXJjaCAyMiwgMjAxNiA5OjU0IFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzog SmltIEd1aWNoYXJkIChqZ3VpY2hhcik7IEpvZWwgTS4gSGFscGVybjsgU3Rld2FydCBCcnlhbnQ7 IFVUVEFSTywgSkFNRVM7DQo+IFJvbiBQYXJrZXI7IERhdmUgRG9sc29uOyBEb2xnYW5vdywgQW5k cmV3IChOb2tpYSAtIFNHKTsgRVhUIEJvdHRvcmZmLCBQYXVsOw0KPiBhby50aW5nQHp0ZS5jb20u Y247IHNmY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NmY10gW0dSQVlNQUlMXSBSZTogQWRk aW5nIGFuIE5TSC5uZXh0LWhlYWRlciB0eXBlIG9mIE5TSA0KPg0KPg0KPiA+IE9uIE1hciAyMSwg MjAxNiwgYXQgOTo1NiBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0K PiA+DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj4g Pj4gU2VudDogVHVlc2RheSwgTWFyY2ggMjIsIDIwMTYgMTI6MTUgQU0NCj4gPj4gVG86IFh1eGlh b2h1OyBKb2VsIE0uIEhhbHBlcm47IFN0ZXdhcnQgQnJ5YW50OyBVVFRBUk8sIEpBTUVTOyBSb24N Cj4gPj4gUGFya2VyOyBEYXZlIERvbHNvbjsgRG9sZ2Fub3csIEFuZHJldyAoTm9raWEgLSBTRyk7 IEVYVCBCb3R0b3JmZiwNCj4gPj4gUGF1bDsgYW8udGluZ0B6dGUuY29tLmNuDQo+ID4+IENjOiBz ZmNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGlu ZyBhbiBOU0gubmV4dC1oZWFkZXIgdHlwZSBvZg0KPiA+PiBOU0gNCj4gPj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+PiBTbyBldmVuIGlmIHdlIGhhZCB3YW50ZWQgdG8gdXNlIGEgbGFiZWwg c3RhY2sgZm9yIHBhdGgNCj4gPj4+PiBpZGVudGlmaWNhdGlvbiwgYXMgZmFyIGFzIEkgIGNhbiB0 ZWxsIHdlIHdvdWxkIHN0aWxsIG5lZWQgYSBoZWFkZXINCj4gPj4+PiB0byBjYXJyeSB0aGUgbWV0 YWRhdGEuDQo+ID4+Pg0KPiA+Pj4gWWVzLiBIb3dldmVyLCBpZiBtZXRhZGF0YSBpcyBub3QgYSBt YW5kYXRvcnkgY29tcG9uZW50IGluIGFueQ0KPiA+Pj4gc2VydmljZSBjaGFpbiwgaXQnZCBiZXR0 ZXIgdG8gZGVjb3VwbGUgdGhlIHBhdGggaWRlbnRpZmljYXRpb24NCj4gPj4+IGhlYWRlciBmcm9t IHRoZSBtZXRhZGF0YSBoZWFkZXIsIElNSE8uDQo+ID4+DQo+ID4+IEluIHdoaWNoIGNhc2UgeW91 IGNhbiB1c2UgTUQtdHlwZSAyIHdpdGggbGVuZ3RoIHNldCB0byAweDIuDQo+ID4NCj4gPiBXaGF0 IGFib3V0IGlmIHdlIGp1c3Qgd2FudCB0aGUgTlNIIHRvIGFjdCBhcyBhIG1ldGFkYXRhIGNvbnRh aW5lcj8NCj4gPg0KPg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzY2NQ0KPg0K PiAgICBTRkMgRW5jYXBzdWxhdGlvbjogIFRoZSBTRkMgZW5jYXBzdWxhdGlvbiBwcm92aWRlcywg YXQgYSBtaW5pbXVtLCBTRlANCj4gICAgICAgICBpZGVudGlmaWNhdGlvbiwgYW5kIGlzIHVzZWQg YnkgdGhlIFNGQy1hd2FyZSBmdW5jdGlvbnMsIHN1Y2ggYXMNCj4gICAgICAgICB0aGUgU0ZGIGFu ZCBTRkMtYXdhcmUgU0ZzLiAgVGhlIFNGQyBlbmNhcHN1bGF0aW9uIGlzIG5vdCB1c2VkDQo+ICAg ICAgICAgZm9yIG5ldHdvcmsgcGFja2V0IGZvcndhcmRpbmcuICBJbiBhZGRpdGlvbiB0byBTRlAN Cj4gICAgICAgICBpZGVudGlmaWNhdGlvbiwgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGNhcnJpZXMg bWV0YWRhdGEgaW5jbHVkaW5nDQo+ICAgICAgICAgZGF0YS1wbGFuZSBjb250ZXh0IGluZm9ybWF0 aW9uLg0KDQpNeSBwb2ludCBpczogd2hlbiB0aGUgU0ZQIGlkZW50aWZpY2F0aW9uIGNvdWxkIGJl IGltcGxlbWVudGVkIGJ5IHVzaW5nIGEgZ2l2ZW4gZXhpc3RpbmcgZm9yd2FyZGluZyBwYXJhZGln bSwgd2hhdCB3ZSByZWFsbHkgbmVlZCB0byBpbnZlbnQgaXMganVzdCBhIG1ldGFkYXRhIGNvbnRh aW5lci4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4goaogQ2FybG9zLg0KPg0KPiA+IEJl c3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBKaW0NCj4gPj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4+IEFuZCB0aGF0IG1lYW5zIHRoYXQgYW55dGhpbmcgdGhhdCBuZWVkZWQgdGhlIG1l dGFkYXRhIG9yIGlubmVyDQo+ID4+Pj4gcGFja2V0IHdvdWxkICBoYXZlIHRvIHBhcnNlIHRoZSBs YWJlbCBzdGFjay4NCj4gPj4+PiBBdCB3aGljaCBwb2ludCAuLi4NCj4gPj4+DQo+ID4+PiBBdCB0 aGUgYm90dG9tIG9mIHRoZSBsYWJlbCBzdGFjay4NCj4gPj4+DQo+ID4+PiBCZXN0IHJlZ2FyZHMs DQo+ID4+PiBYaWFvaHUNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IFlvdXJzLA0KPiA+Pj4+IEpvZWwN Cj4gPj4+Pg0KPiA+Pj4+IE9uIDMvMTcvMTYgMTE6MzEgQU0sIFN0ZXdhcnQgQnJ5YW50IHdyb3Rl Og0KPiA+Pj4+PiBZZXMsIHRoZSBNUExTIGxhYmVsIHNob3VsZCBiZSBzZWVuIGFzIGFuIGluc3Ry dWN0aW9uIC0gd2hpY2ggaXMNCj4gPj4+Pj4gZXhhY3RseSB3aGF0IGl0IGlzLCBhbmQgYWx3YXlz IGhhcyBiZWVuLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBZb3UgY2FuIHRyaXZpYWxseSBjYXJyeSBNUExT IG92ZXIgSVAuDQo+ID4+Pj4+DQo+ID4+Pj4+IFdlIGRvIGNhcnJ5IE1QTFMgb3ZlciBFdGhlcm5l dC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSW4gdGhlIGFib3ZlIGNhc2VzIE1QTFMgaXMgdGhlIGluc3Ry dWN0aW9uLCBhbmQgSVAgYW5kIEV0aGVybmV0DQo+ID4+Pj4+IGFyZSB0aGUgcG9pbnQgdG8gcG9p bnQgdHJhbnNwb3J0cy4NCj4gPj4+Pj4NCj4gPj4+Pj4gV2hhdCBpcyBtb3JlIGludGVyZXN0aW5n IGlzIGhvdyB3ZSBjYXJyeSB0aGUgbWV0YWRhdGEsIHNpbmNlIHRoZXJlDQo+ID4+Pj4+IG1heSBu ZWVkIHRvIGJlIHNldmVyYWwgaW5zdGFuY2VzIG9mIHRoZSBtZXRhZGF0YSBpbiB0aGUgcGFja2V0 Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTdGV3YXJ0DQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIDE3LzAzLzIw MTYgMTI6MzAsIFVUVEFSTywgSkFNRVMgd3JvdGU6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKi9Sb24s LyoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqLy8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKi9IYXZlIG5v dCBiZWVuIGZvbGxvd2luZyB0aGUgU0ZDIFdHIHRoYXQgY2xvc2VseSBkdWUgdG8gb3RoZXINCj4g Pj4+Pj4+IG1vcmUgcHJlc3NpbmcgbmVlZHMgZm9yIG15IG5ldHdvcmsuIFRoYXQgYmVpbmcgc2Fp ZCwgaXQgd291bGQNCj4gPj4+Pj4+IHNlZW0gdGhhdCBhbiBNUExTIGxhYmVsIGNvdWxkIGJlIHVz ZWQgYXMgdGhlIGJhc2lzIGZvciB3aGF0IHlvdQ0KPiA+Pj4+Pj4gYXJlIGxvb2tpbmcgZm9yIGFu IHRodXMgY291bGQgYmUgYXBwbGllZCB0byBhbGwgbmV0d29yayB0eXBlcy4NCj4gPj4+Pj4+IFVz aW5nIHRoZSBNUExTIGxhYmVsIGZvcm1hdCBkb2VzIG5vdCBmb3JjZSB5b3UgdG8gaGF2ZSBhbiBN UExTDQo+ID4+Pj4+PiBlbmFibGVkIG5ldHdvcmsgYWxsIHRoYXQgaXMgbmVlZGVkIGlzIHRoZSBy ZXF1aXJlZCBpbmZvIHRvIGJlDQo+ID4+Pj4+PiBwb3B1bGF0ZWQgaW4gdGhlIGxhYmVsLiBJdCBz ZWVtcyB0aGF0IHRoZSBhcmd1bWVudCBpcyBmb3INCj4gPj4+Pj4+IGluZGVwZW5kZW5jZSBvZiBu ZXR3b3JrIHRodXMgaW52ZW50aW5nIGEgbmV3IGxhYmVsIGlzIGJhc2VkIG9uIGFuDQo+ID4+Pj4+ PiBhc3N1bXB0aW9uIHRoYXQgdXNpbmcgTVBMUyBsYWJlbHMgaW1wb3NlcyBhbiBNUExTIGNvbnRy b2wgcGxhbmUuDQo+ID4+Pj4+PiBJcyB0aGF0IHJpZ2h0Py8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g Ki8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICovSmltIFV0dGFyby8qDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gKi8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICIvVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIEFUJlQgcHJvcGVydHksDQo+ID4+Pj4+PiBhcmUgY29uZmlk ZW50aWFsLCBhbmQgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUNCj4gPj4+ Pj4+IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhpcyBlbWFpbCBpcyBhZGRyZXNzZWQu IElmIHlvdSBhcmUNCj4gPj4+Pj4+IG5vdCBvbmUgb2YgdGhlIG5hbWVkIHJlY2lwaWVudChzKSBv ciBvdGhlcndpc2UgaGF2ZSByZWFzb24gdG8NCj4gPj4+Pj4+IGJlbGlldmUgdGhhdCB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZQ0KPiA+Pj4+Pj4gbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgaW1tZWRpYXRlbHkgZnJvbSB5b3Vy DQo+ID4+Pj4+PiBjb21wdXRlci4gQW55IG90aGVyIHVzZSwgcmV0ZW50aW9uLCBkaXNzZW1pbmF0 aW9uLCBmb3J3YXJkaW5nLA0KPiA+Pj4+Pj4gcHJpbnRpbmcsIG9yIGNvcHlpbmcgb2YgdGhpcyBl bWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLy4iKi8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICpG cm9tOipYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4+Pj4+PiAqU2Vu dDoqIFRodXJzZGF5LCBNYXJjaCAxNywgMjAxNiAzOjQ3IEFNDQo+ID4+Pj4+PiAqVG86KiBSb24g UGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPjsgVVRUQVJPLA0KPiA+PiBK QU1FUw0KPiA+Pj4+Pj4gPGp1MTczOEBhdHQuY29tPjsgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2Fu ZHZpbmUuY29tPjsNCj4gRG9sZ2Fub3csDQo+ID4+Pj4+PiBBbmRyZXcgKE5va2lhIC0gU0cpIDxh bmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPjsgRVhUIEJvdHRvcmZmLA0KPiA+Pj4+Pj4gUGF1bCA8 cGF1bC5ib3R0b3JmZkBocGUuY29tPjsgU3Rld2FydCBCcnlhbnQNCj4gPj4+Pj4+IDxzdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb20+OyBhby50aW5nQHp0ZS5jb20uY24NCj4gPj4+Pj4+ICpDYzoqIHNm Y0BpZXRmLm9yZw0KPiA+Pj4+Pj4gKlN1YmplY3Q6KiBSRTogW3NmY10gW0dSQVlNQUlMXSBSZTog QWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlcg0KPiA+Pj4+Pj4gdHlwZSBvZiBOU0gNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBSb24sDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIFNGQyBhcHByb2FjaCBvZiBl bmNvZGluZyB0aGUgU0ZQIGluZm9ybWF0aW9uIGJ5IGFuIE1QTFMgbGFiZWwNCj4gPj4+Pj4+IHN0 YWNrIGNhbiBtZWV0IHRoZSB0cmFuc3BvcnQtaW5kZXBlbmRlbmN5IHJlcXVpcmVtZW50IHZlcnkg d2VsbC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gWGlhb2h1DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206KlJvbiBQYXJrZXIgW21haWx0bzpS b25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPiA+Pj4+Pj4gKlNlbnQ6KiBXZWRuZXNk YXksIE1hcmNoIDE2LCAyMDE2IDExOjIwIFBNDQo+ID4+Pj4+PiAqVG86KiBVVFRBUk8sIEpBTUVT OyBEYXZlIERvbHNvbjsgWHV4aWFvaHU7IERvbGdhbm93LCBBbmRyZXcNCj4gPj4+Pj4+IChOb2tp YSAtIFNHKTsgRVhUIEJvdHRvcmZmLCBQYXVsOyBTdGV3YXJ0IEJyeWFudDsNCj4gPj4+Pj4+IGFv LnRpbmdAenRlLmNvbS5jbiA8bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ICpD YzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICpTdWJqZWN0 OiogUkU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXINCj4g Pj4+Pj4+IHR5cGUgb2YgTlNIDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSmFtZXMsDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gSSBjYW6hr3Qgc3BlYWsgZm9yIHRoZSBlbnRpcmUgZ3JvdXAsIG15IHVuZGVyc3Rh bmRpbmcgb2YgdGhlDQo+ID4+Pj4+PiBkZWNpc2lvbiBub3QgdG8gc3RhbmRhcmRpemUgb24gTVBM UyBhcyB0aGUgZm9yd2FyZGluZyBwYXJhZGlnbQ0KPiA+Pj4+Pj4gd2FzIHRvIG1ha2UgU0ZDIGJy b2FkZXIgc3VjaCB0aGF0IGl0IGNvdWxkIHV0aWxpemUgTUFDIGJhc2VkDQo+ID4+Pj4+PiBuZXR3 b3JrcywgSVAgYmFzZWQgbmV0d29ya3MsIGFuZCBJUC1vdmVyLU1QTFMgYmFzZWQgbmV0d29ya3Mu DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUm9uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206KlVUVEFS TywgSkFNRVMgW21haWx0bzpqdTE3MzhAYXR0LmNvbV0NCj4gPj4+Pj4+ICpTZW50OiogV2VkbmVz ZGF5LCBNYXJjaCAxNiwgMjAxNiAxMToxMSBBTQ0KPiA+Pj4+Pj4gKlRvOiogUm9uIFBhcmtlciA8 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbQ0KPiA+Pj4+Pj4gPG1haWx0bzpSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj47IERhdmUgRG9sc29uDQo+ID4+Pj4+PiA8ZGRvbHNv bkBzYW5kdmluZS5jb20gPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+OyBYdXhpYW9odQ0K PiA+Pj4+Pj4gPHh1eGlhb2h1QGh1YXdlaS5jb20gPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29t Pj47IERvbGdhbm93LA0KPiA+Pj4+IEFuZHJldw0KPiA+Pj4+Pj4gKE5va2lhIC0gU0cpDQo+ID4+ Pj4+Pg0KPiA+PiA8PG1haWx0bzphbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPmFuZHJldy5kb2xn YW5vd0Bub2tpYS5jb20+Ow0KPiA+Pj4+IEVYVA0KPiA+Pj4+Pj4gQm90dG9yZmYsIFBhdWwgPHBh dWwuYm90dG9yZmZAaHBlLmNvbQ0KPiA+Pj4+Pj4gPG1haWx0bzpwYXVsLmJvdHRvcmZmQGhwZS5j b20+PjsgU3Rld2FydCBCcnlhbnQNCj4gPj4+Pj4+IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20g PG1haWx0bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+PjsNCj4gPj4+Pj4+IGFvLnRpbmdAenRl LmNvbS5jbiA8bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ICpDYzoqIHNmY0Bp ZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICpTdWJqZWN0OiogUkU6IFtz ZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXINCj4gPj4+Pj4+IHR5 cGUgb2YgTlNIDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKi9Db21tZW50cyBJbi1MaW5lLyoNCj4gPj4+ Pj4+DQo+ID4+Pj4+PiAqLy8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKi9KaW0gVXR0YXJvLyoNCj4g Pj4+Pj4+DQo+ID4+Pj4+PiAqLy8qDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gIi9UaGlzIGVtYWlsIGFu ZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgQVQmVCBwcm9wZXJ0eSwNCj4gPj4+ Pj4+IGFyZSBjb25maWRlbnRpYWwsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZQ0KPiA+Pj4+Pj4gaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGlzIGVtYWls IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZQ0KPiA+Pj4+Pj4gbm90IG9uZSBvZiB0aGUgbmFtZWQg cmVjaXBpZW50KHMpIG9yIG90aGVyd2lzZSBoYXZlIHJlYXNvbiB0bw0KPiA+Pj4+Pj4gYmVsaWV2 ZSB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlDQo+ ID4+Pj4+PiBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBpbW1lZGlh dGVseSBmcm9tIHlvdXINCj4gPj4+Pj4+IGNvbXB1dGVyLiBBbnkgb3RoZXIgdXNlLCByZXRlbnRp b24sIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsDQo+ID4+Pj4+PiBwcmludGluZywgb3IgY29w eWluZyBvZiB0aGlzIGVtYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQvLiIqLy8qDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gKkZyb206KlJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tXQ0KPiA+Pj4+Pj4gKlNlbnQ6KiBXZWRuZXNkYXksIE1hcmNoIDE2LCAyMDE2 IDEwOjAxIEFNDQo+ID4+Pj4+PiAqVG86KiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5j b20NCj4gPj4+Pj4+IDxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PjsgWHV4aWFvaHUgPHh1 eGlhb2h1QGh1YXdlaS5jb20NCj4gPj4+Pj4+IDxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+ OyBVVFRBUk8sIEpBTUVTIDxqdTE3MzhAYXR0LmNvbQ0KPiA+Pj4+Pj4gPG1haWx0bzpqdTE3MzhA YXR0LmNvbT4+OyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKQ0KPiA+Pj4+Pj4NCj4gPj4g PDxtYWlsdG86YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbT5hbmRyZXcuZG9sZ2Fub3dAbm9raWEu Y29tPjsNCj4gPj4+PiBFWFQNCj4gPj4+Pj4+IEJvdHRvcmZmLCBQYXVsIDxwYXVsLmJvdHRvcmZm QGhwZS5jb20NCj4gPj4+Pj4+IDxtYWlsdG86cGF1bC5ib3R0b3JmZkBocGUuY29tPj47IFN0ZXdh cnQgQnJ5YW50DQo+ID4+Pj4+PiA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tIDxtYWlsdG86c3Rl d2FydC5icnlhbnRAZ21haWwuY29tPj47DQo+ID4+Pj4+PiBhby50aW5nQHp0ZS5jb20uY24gPG1h aWx0bzphby50aW5nQHp0ZS5jb20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcgPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJFOiBbc2ZjXSBbR1JBWU1B SUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+PiB0eXBlIG9mIE5TSA0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IE15IHJlY29sbGVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbiBhbmQg YW5hbHlzaXMgb2YgTVBMUyBmb3J3YXJkaW5nDQo+ID4+Pj4+PiB0byBzdXBwb3J0IFNGQyB3YXMg bm90IG9yaWVudGVkIGFyb3VuZCBoaWVyYXJjaGljYWwgU0ZDIGRvbWFpbnMuDQo+ID4+Pj4+PiBJ bnN0ZWFkLCBJIHRob3VnaHQgdGhlIGRpc2N1c3Npb24gd2FzIGFyb3VuZCBhbiBNUExTIGxhYmVs IHBlciBTRg0KPiA+Pj4+Pj4gaW5zdGFuY2Ugc28gdGhhdCB0aGUgc3RhY2sgb2YgTVBMUyBsYWJl bHMgcHJvdmlkZWQgdGhlIGZ1bGwgU0ZQL1JTUA0KPiA+Pj4+Pj4gZGVzY3JpcHRpb24uICAgIEFu IGVsZWdhbnQgYXBwcm9hY2gsIGZvciBzdXJlLCBidXQgbm90IG9uZSBhZG9wdGVkIGJ5DQo+ID4+ Pj4+PiB0aGUgV0cuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKi9bSmltIFU+XSBXYXMgdGhpcyBkZWNp c2lvbiBiYXNlZCBvbiB0aGUgbm90aW9uIHRoYXQgYWxsIGZhYnJpY3MNCj4gPj4+Pj4+IGFyZSBJ UCBvbmx5Pz8gSU1PIHRoZSBtb2RlbCBvZiBhbGwgRENzIGJlaW5nIGxhcmdlIGFuZCBJUCBvbmx5 IGlzDQo+ID4+Pj4+PiBub3QgYSBjb3JyZWN0IGFzc3VtcHRpb24uLyoNCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBUaGUgY3VycmVudCBkaXNjdXNzaW9uIG9mIE1QTFMgaXMgbW9yZSBvZiB0aGUgaGllcmFy Y2hpY2FsIG5hdHVyZQ0KPiA+Pj4+Pj4gqEMgYSBzdGFjayBvZiBsYWJlbHMgaW4gdGhlIGdlbmVy YWwgY2FzZSByZXByZXNlbnRzIGEgc2V0IG9mIG5lc3RlZCBMU1BzLg0KPiA+Pj4+Pj4gRm9yIFNG QywgdGhlIGRpc2N1c3Npb24gaXMgdGhhdCBhIHN0YWNrIG9mIE5TSCByZXByZXNlbnRzIGEgc3Rh Y2sNCj4gPj4+Pj4+IG9mIHBlci1TRkMtZG9tYWluIFNGUHMuIEJ1dCBhbiBpbmRpdmlkdWFsIE5T SCBkb2VzIG5vdA0KPiA+Pj4+Pj4gc2VsZi1kZXNjcmliZSB0aGUgU0ZQL1JTUCBhdCBpdHMgb3du IGRvbWFpbiBsZXZlbCwgcmVseWluZw0KPiA+Pj4+Pj4gaW5zdGVhZCBvbiBhIGZsYXQgaWRlbnRp ZmllciAoU0ZQIElEKSB0aGF0IGlzIHVzZWQgdG8gbG9va3VwIHRoZSBmdWxsDQo+IFNGUC9SU1Au DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUm9uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206KkRhdmUg RG9sc29uIFttYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb21dDQo+ID4+Pj4+PiAqU2VudDoqIFdl ZG5lc2RheSwgTWFyY2ggMTYsIDIwMTYgOTo0OCBBTQ0KPiA+Pj4+Pj4gKlRvOiogWHV4aWFvaHUg PHh1eGlhb2h1QGh1YXdlaS5jb20NCj4gPj4gPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj47 DQo+ID4+Pj4+PiBVVFRBUk8sIEpBTUVTIDxqdTE3MzhAYXR0LmNvbSA8bWFpbHRvOmp1MTczOEBh dHQuY29tPj47DQo+ID4+IERvbGdhbm93LA0KPiA+Pj4+Pj4gQW5kcmV3IChOb2tpYSAtIFNHKQ0K PiA+Pj4+Pj4NCj4gPj4gPDxtYWlsdG86YW5kcmV3LmRvbGdhbm93QG5va2lhLmNvbT5hbmRyZXcu ZG9sZ2Fub3dAbm9raWEuY29tPjsNCj4gPj4+PiBFWFQNCj4gPj4+Pj4+IEJvdHRvcmZmLCBQYXVs IDxwYXVsLmJvdHRvcmZmQGhwZS5jb20NCj4gPj4+Pj4+IDxtYWlsdG86cGF1bC5ib3R0b3JmZkBo cGUuY29tPj47IFJvbiBQYXJrZXINCj4gPj4+Pj4+IDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tDQo+ID4+Pj4+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+ PjsgU3Rld2FydCBCcnlhbnQNCj4gPj4+Pj4+IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20gPG1h aWx0bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+PjsNCj4gPj4+Pj4+IGFvLnRpbmdAenRlLmNv bS5jbiA8bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ICpDYzoqIHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICpTdWJqZWN0OiogUkU6IFtzZmNd IFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXINCj4gPj4+Pj4+IHR5cGUg b2YgTlNIDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUmVjYWxsIHRoYXQgZHJhZnQtaG9tbWEtc2ZjLWZv cndhcmRpbmctbWV0aG9kcy1hbmFseXNpcyBjb21wYXJlcw0KPiA+Pj4+Pj4gdGhlIGRpZmZlcmVu dCBhcHByb2FjaGVzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaG9tbWEtc2ZjLWZvcndhcmRpbmctbWV0aG9kcy1hDQo+ID4+Pj4+PiBuDQo+ ID4+Pj4+PiBhbHkNCj4gPj4+Pj4+IHNpcy0wNT5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaG9tbWEtc2ZjLWZvcndhcmRpbmctbWV0DQo+ID4+Pj4+PiBzaXMtMDU+aA0KPiA+Pj4+ Pj4gc2lzLTA1Pm9kcw0KPiA+Pj4+Pj4gLWFuYWx5c2lzLTA1DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g VGhlIE1QTFMgYXBwcm9hY2ggZmFsbHMgaW50byB0aGUgY2F0ZWdvcnkgZGlzY3Vzc2VkIGluIHNl Y3Rpb24NCj4gPj4+Pj4+IDMuMS4yLCChsE1ldGhvZCAyOiBGb3J3YXJkaW5nIHdpdGggU3RhY2tl ZCBIZWFkZXJzobEsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gd2hlcmVhcyB0aGUgTlNIIGFwcHJvYWNo IGZhbGxzIGludG8gc2VjdGlvbiAzLjEuMywgobBNZXRob2QzOg0KPiA+Pj4+Pj4gRm9yd2FyZGlu ZyBiYXNlZCBvbiBTZXJ2aWNlIENoYWluIElkZW50aWZpZXJzobEuDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gU2VjdGlvbiA0IGFuYWx5emVzIHRoZSBkaWZmZXJlbnQgbWV0aG9kcywgd2l0aCBwcm9zIGFu ZCBjb25zIGZvcg0KPiA+Pj4+Pj4gYWxsIG9mIHRoZSBhcHByb2FjaGVzLg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IC1EYXZlDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpYdXhpYW9odQ0KPiA+Pj4+Pj4gKlNlbnQ6 KiBUdWVzZGF5LCBNYXJjaCAxNSwgMjAxNiA4OjIxIFBNDQo+ID4+Pj4+PiAqVG86KiBVVFRBUk8s IEpBTUVTOyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRVhUIEJvdHRvcmZmLA0KPiA+ Pj4+Pj4gUGF1bDsgUm9uIFBhcmtlcjsgU3Rld2FydCBCcnlhbnQ7IGFvLnRpbmdAenRlLmNvbS5j bg0KPiA+Pj4+Pj4gPG1haWx0bzphby50aW5nQHp0ZS5jb20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJl OiBbc2ZjXSBbR1JBWU1BSUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+ PiB0eXBlIG9mIE5TSA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFdoZW4gYXBwbHlpbmcgYSBwYXJ0aWN1 bGFyIFNGQyAoaS5lLiwgYW4gb3JkZXJlZCBsaXN0IG9mIFNGcykgdG8NCj4gPj4+Pj4+IHRoZSBz ZWxlY3RlZCB0cmFmZmljLCB0aGUgdHJhZmZpYyBuZWVkcyB0byBiZSBzdGVlcmVkIHRocm91Z2gg dGhlDQo+ID4+Pj4+PiBjb3JyZXNwb25kaW5nIFNGUCAoaS5lLiwgYW4gb3JkZXJlZCBsaXN0IG9m IFNGRnMgYW5kIFNGcykgaW4gdGhlDQo+ID4+Pj4+PiBTRkMtZW5hYmxlZCBuZXR3b3JrLiBNUExT LVNQUklORyBpcyBhIHBhcnRpY3VsYXIgTVBMUyBzb3VyY2UNCj4gPj4+Pj4+IHJvdXRpbmcgcGFy YWRpZ20gd2hlcmUgdGhlIGV4cGxpY2l0IHBhdGggaW5mb3JtYXRpb24gKGkuZS4sIGFuDQo+ID4+ Pj4+PiBvcmRlcmVkIGxpc3Qgb2YgZXhwbGljaXQgaG9wcykgaXMgZW5jb2RlZCBhcyBhIGxhYmVs IHN0YWNrIChpLmUuLA0KPiA+Pj4+Pj4gYW4gb3JkZXJlZCBsaXN0IG9mIGxhYmVscyB3aXRoIGVh Y2ggaW5kaWNhdGluZyBhIHBhcnRpY3VsYXINCj4gPj4+Pj4+IGV4cGxpY2l0IGhvcCkgYW5kIHRo ZW4gcGlnZ3liYWNrZWQgb24gdGhlIHNvdXJjZSByb3V0ZWQgcGFja2V0cy4NCj4gPj4+Pj4+IFRo ZSBNUExTLVNQUklORyBwYXJhZGlnbSBjYW4gYmUgZWFzaWx5IGxldmVyYWdlZCB0byBzdGVlciB0 aGUNCj4gPj4+Pj4+IHNlbGVjdGVkIHRyYWZmaWMgdGhyb3VnaCBhIHBhcnRpY3VsYXIgU0ZQIGJ5 IGVuY29kaW5nIHRoZSBTRlANCj4gPj4+Pj4+IGluZm9ybWF0aW9uIGFzIGFuIE1QTFMgbGFiZWwg c3RhY2sgKGkuZS4sIGFuIG9yZGVyZWQgbGlzdCBvZg0KPiA+Pj4+Pj4gbGFiZWxzIHdpdGggZWFj aCBpbmRpY2F0aW5nIGEgcGFydGljdWxhcg0KPiA+Pj4+IFNGRiBvciBTRikuDQo+ID4+Pj4+PiBJ biB0aGlzIHdheSwgU0ZGcyBjb3VsZCBiZSBpbXBsZW1lbnRlZCBvbiBleGlzdGluZyBNUExTIHN3 aXRjaGVzDQo+ID4+Pj4+PiB3aXRob3V0IGFueSBjaGFuZ2UgdG8gdGhlIGRhdGEtcGxhbmUgcHJv dmlkZWQgdGhhdCBTRnMgYXJlDQo+ID4+Pj4+PiBjYXBhYmxlIG9mIHJlY29nbml6aW5nIE1QTFMg cGFja2V0cy4gIEFzIHBvaW50ZWQgb3V0IGJ5IHNvbWVib2R5DQo+ID4+Pj4+PiBlbHNlLCBpdKGv cyBtdWNoIHN0cmFpZ2h0Zm9yd2FyZCB0byBzdXBwb3J0IHRoZSBzdGFjayBvZiBTRkMNCj4gPj4+ Pj4+IGVuY2Fwc3VsYXRpb25zIGlmIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBpcyBpbXBsZW1lbnRl ZCBpbiB0aGUNCj4gPj4+Pj4+IGZvcm0gb2YgYW4NCj4gPj4gTVBMUyBsYWJlbCBzdGFjay4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gWGlhb2h1 DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gKkZyb206KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSAqT24gQmVoYWxmIE9mICpVVFRBUk8sDQo+ID4+Pj4+PiBKQU1FUw0KPiA+Pj4+Pj4gKlNl bnQ6KiBUdWVzZGF5LCBNYXJjaCAxNSwgMjAxNiA4OjQ2IFBNDQo+ID4+Pj4+PiAqVG86KiBEb2xn YW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRVhUIEJvdHRvcmZmLCBQYXVsOyBSb24NCj4gPj4+ Pj4+IFBhcmtlcjsgU3Rld2FydCBCcnlhbnQ7IGFvLnRpbmdAenRlLmNvbS5jbg0KPiA+Pj4+Pj4g PG1haWx0bzphby50aW5nQHp0ZS5jb20uY24+DQo+ID4+Pj4+PiAqQ2M6KiBzZmNAaWV0Zi5vcmcg PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+Pj4+PiAqU3ViamVjdDoqIFJlOiBbc2ZjXSBbR1JB WU1BSUxdIFJlOiBBZGRpbmcgYW4gTlNILm5leHQtaGVhZGVyDQo+ID4+Pj4+PiB0eXBlIG9mIE5T SA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICovSWYgd2UgaGF2ZSBhbiBNUExTIGVuYWJsZWQgZmFicmlj IHdvdWxkbqGvdCBpdCBiZSBzaW1wbGVyIHRvDQo+ID4+Pj4+PiB3ZWF2ZSBOU0ggaW50byBpdCBp ZiBpdCBhbGwgdXNlcyBNUExTPyBJZiBub3QgaG93IHdvdWxkIHRoZQ0KPiA+Pj4+Pj4gaW50ZXJh Y3Rpb24gYmV0d2VlbiB0aGUgdHdvIGVudmlyb25tZW50cyB3b3JrPy8qDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gKi8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICovSmltIFV0dGFyby8qDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gKi8vKg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICIvVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIEFUJlQgcHJvcGVydHksDQo+ID4+Pj4+PiBhcmUg Y29uZmlkZW50aWFsLCBhbmQgYXJlIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUN Cj4gPj4+Pj4+IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhpcyBlbWFpbCBpcyBhZGRy ZXNzZWQuIElmIHlvdSBhcmUNCj4gPj4+Pj4+IG5vdCBvbmUgb2YgdGhlIG5hbWVkIHJlY2lwaWVu dChzKSBvciBvdGhlcndpc2UgaGF2ZSByZWFzb24gdG8NCj4gPj4+Pj4+IGJlbGlldmUgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZQ0KPiA+Pj4+Pj4g bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgaW1tZWRpYXRlbHkgZnJv bSB5b3VyDQo+ID4+Pj4+PiBjb21wdXRlci4gQW55IG90aGVyIHVzZSwgcmV0ZW50aW9uLCBkaXNz ZW1pbmF0aW9uLCBmb3J3YXJkaW5nLA0KPiA+Pj4+Pj4gcHJpbnRpbmcsIG9yIGNvcHlpbmcgb2Yg dGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLy4iKi8vKg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBP ZiAqRG9sZ2Fub3csDQo+ID4+Pj4+PiBBbmRyZXcgKE5va2lhIC0gU0cpDQo+ID4+Pj4+PiAqU2Vu dDoqIE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgMTE6NTIgUE0NCj4gPj4+Pj4+ICpUbzoqIEVYVCBC b3R0b3JmZiwgUGF1bA0KPiA+Pj4+Pj4gPDxtYWlsdG86cGF1bC5ib3R0b3JmZkBocGUuY29tPnBh dWwuYm90dG9yZmZAaHBlLmNvbT47IFJvbg0KPiBQYXJrZXINCj4gPj4+Pj4+IDxSb25fUGFya2Vy QGFmZmlybWVkbmV0d29ya3MuY29tDQo+ID4+Pj4+PiA8bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb20+PjsgU3Rld2FydCBCcnlhbnQNCj4gPj4+Pj4+IDxzdGV3YXJ0LmJyeWFu dEBnbWFpbC5jb20gPG1haWx0bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+PjsNCj4gPj4+Pj4+ IGFvLnRpbmdAenRlLmNvbS5jbiA8bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ ICpDYzoqIHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICpTdWJq ZWN0OiogUmU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXIN Cj4gPj4+Pj4+IHR5cGUgb2YgTlNIDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRm9sbG93aW5nIKGwbmV4 dCBoZWFkZXKhsSBhcHByb2FjaCAgaXMgc2ltcGxlIGFuZCB0aGUgTlNIIGhlYWRlciBpcw0KPiA+ Pj4+Pj4gYWxyZWFkeSBidWlsdCBsaWtlIHRoYXQuIEludHJvZHVjaW5nIE1QTFMgbGlrZSBhcHBy b2FjaCB3b3VsZCBhZGQNCj4gPj4+Pj4+IHlldCBhbm90aGVyIG1lY2hhbmlzbSB0byB0cmF2ZXJz ZSB0aGUgaGVhZGVycywgd2hpY2ggd291bGQgbWFrZQ0KPiA+Pj4+Pj4gaC93IG1vcmUgY29tcGxl eC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJdCBpcyB0cnVlIHRoYXQgaC93IGNhbiBvbmx5IGxvb2sg YXQgWCBCeXRlcyAoWCBkZXBlbmRpbmcgb24gaC93KS4NCj4gPj4+Pj4+IFRoaXMgaXMgdHJ1ZSBm b3IgbWFueSBoZWFkZXJzIG5vdCBvbmx5IHRoaXMgYW5kIGV2ZW4gdG9kYXkNCj4gPj4+Pj4+ICh3 aXRob3V0DQo+ID4+Pj4+PiBOU0gpIHlvdSBjYW4gZW5kLXVwIHdpdGggcGF5bG9hZCBiZWluZyB2 ZXJ5IGRlZXAgaW4gYSBwYWNrZXQuIEF0DQo+ID4+Pj4+PiB0aGUgZW5kIHdlIG5lZWQgdG8gaGF2 ZSBhIGZsZXhpYmxlIG1lY2hhbmlzbSB3aGljaCBOU0ggbmVzdGluZw0KPiA+Pj4+Pj4gd291bGQg cHJvdmlkZS4gSWYgc29tZW9uZSChsGFidXNlcyBpdKGxIHRoaXMgY2FuIGxlYWQgdG8gdmFyaW91 cw0KPiA+Pj4+Pj4gaXNzdWVzLiBJdCBpcyBwcm9iYWJseSB3b3J0aCBub3RpbmcgdGhhdCBpbiB0 aGUgZHJhZnQgaW5jbHVkaW5nDQo+ID4+Pj4+PiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAoYnkg YWRkaW5nIGxhcmdlIGhlYWRlcnMgaXQgd2lsbCBiZQ0KPiA+Pj4+Pj4gaGFyZGVyIHRvIHBlcmZv cm0gcGF5bG9hZCBiYXNlZCBBQ0wgRERvUyBwcm90ZWN0aW9uIGluIHJvdXRlcnMgZm9yDQo+IGV4 YW1wbGUpLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFuZHJldw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE9u IDIwMTYtMDMtMTUsIDM6MDMgQU0sICJzZmMgb24gYmVoYWxmIG9mIEVYVCBCb3R0b3JmZiwgUGF1 bCIgd3JvdGU6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgSnVzdCBvbmUgbW9yZSBjb25jZXJuIGFi b3V0IHRoZSBzdGFjayBpcyBob3cgZGVlcCBpdCB3aWxsIG5lc3QuDQo+ID4+Pj4+PiAgICBIYXJk d2FyZSBzd2l0Y2ggaW1wbGVtZW50YXRpb25zIGFyZSB0eXBpY2FsbHkgbGltaXRlZCBpbiB0aGUN Cj4gPj4+PiBkZXB0aA0KPiA+Pj4+Pj4gICAgdGhleSBsb29rIGludG8gdGhlIHBhY2tldC4gSWYg dGhlIGhhcmR3YXJlIG5lZWRzIHRvIGxvb2sgYXQgdGhlDQo+ID4+Pj4+PiAgICBvcmlnaW5hbCBw YWNrZXQgaGVhZGVycywgdGhlbiBoYXJkd2FyZSB3b3VsZCBuZWVkIHRvIHNraXAgb3Zlcg0KPiA+ Pj4+IHRoZQ0KPiA+Pj4+Pj4gICAgc3RhY2sgb2YgTlNIIGhlYWRlcnMgdG8gcmVhY2ggdGhlIG9y aWdpbmFsIHBhY2tldC4gSWYgdGhlIE5TSA0KPiA+Pj4+Pj4gICAgc3RhY2sgaXMgdG9vIGRlZXAg aXQgbWF5IGV4Y2VlZCB0aGUgaGFyZHdhcmUgZGVwdGggbGltaXRzLg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICAgIENoZWVycywNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgUGF1bA0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+ICAgICpGcm9tOipzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gKk9uIEJlaGFsZiBPZiAqUm9uDQo+ID4+Pj4gUGFya2VyDQo+ID4+Pj4+PiAgICAqU2VudDoq IE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgMTE6NDUgQU0NCj4gPj4+Pj4+ICAgICpUbzoqIFN0ZXdh cnQgQnJ5YW50DQo+ID4+Pj4+Pg0KPiA8PG1haWx0bzpzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+ c3Rld2FydC5icnlhbnRAZ21haWwuY29tPjsNCj4gPj4+Pj4+ICAgIGFvLnRpbmdAenRlLmNvbS5j biA8bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4NCj4gPj4+Pj4+ICAgICpDYzoqIHNmY0BpZXRm Lm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4+ICAgICpTdWJqZWN0OiogUmU6IFtz ZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXINCj4gPj4+PiB0eXBl DQo+ID4+Pj4+PiAgICBvZiBOU0gNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBJIGxpa2UgdGhlIHNl bGYgZGVzY3JpYmluZyBzdGFjayBvZiBOU0ggaGVhZGVycyBhbmQgSSBsaWtlIHRoZQ0KPiA+Pj4+ Pj4gICAgZmlyc3Qgb25lIGJlaW5nIHRoZSChsGN1cnJlbnShsSBzY29waW5nLiAgIEJ1dCwgb25l IGRpZmZlcmVuY2UNCj4gPj4+Pj4+ICAgIGJldHdlZW4gTVBMUyBhbmQgTlNIoa0gICBNUExTIGZv cndhcmRpbmcgaXMgZ2VuZXJhbGx5IGhhbmRsZWQNCj4gPj4gYnkNCj4gPj4+Pj4+ICAgIGxvb2tp bmcgb25seSBhdCB0aGUgTVBMUyBsYWJlbHMgdGhhdCBhcmUgobBpbiBzY29wZaGxIGZvciB0aGUN Cj4gPj4+Pj4+ICAgIGN1cnJlbnQgbm9kZSAoaS5lLiwgc3RhcnRpbmcgYXQgdGhlIHRvcC1vZi1z dGFjaykgYW5kIG5vdCBuZWVkaW5nDQo+ID4+Pj4+PiAgICB0byBsb2NhdGUgYW5kIHByb2Nlc3Mg dGhlIKGwcGF5bG9hZKGxIGJleW9uZCB0aGUgYm90dG9tLW9mLXN0YWNrLg0KPiA+Pj4+Pj4gICAg QnV0LCBpbiBOU0gsIG1vc3QgcHJvY2Vzc2luZyB3aWxsIHJlcXVpcmUgbG9jYXRpb24gb2YgdGhl DQo+ID4+Pj4+PiAgICChsHBheWxvYWShsSBiZXlvbmQgdGhlIGxhc3QgTlNIIGhlYWRlci4gICBJ dCBpcyBpbmVmZmljaWVudCB0byBoYXZlDQo+ID4+Pj4+PiAgICB0byB3YWxrIHRoZSBzdGFjayBv ZiBOU0ggaGVhZGVycyBpbiBvcmRlciB0byBsb2NhdGUgdGhhdA0KPiA+Pj4+Pj4gICAgcGF5bG9h ZC4gICAgSWYgZWFjaCBOU0ggaGVhZGVyIHRoYXQgd2FzIHB1c2hlZCBvbnRvIHRoZSBzdGFjaw0K PiA+Pj4+IGFsc28NCj4gPj4+Pj4+ICAgIGluY2x1ZGVkIGFuIG9mZnNldCB0byBkaXJlY3RseSBs b2NhdGUgdGhlIHBheWxvYWQgKGVhY2ggbmV3IG9uZQ0KPiA+Pj4+Pj4gICAgc2ltcGx5IGFkZHMg aXRzIG93biBieXRlIHNpemUpLCB0aGVuIHRoaXMgcHJvY2Vzc2luZyBpbmVmZmljaWVuY3kNCj4g Pj4+Pj4+ICAgIHdvdWxkIGJlIG1pdGlnYXRlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBSb24N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAqRnJvbToqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4gPj4+Pj4+ICpTdGV3YXJ0DQo+ID4+Pj4gQnJ5YW50DQo+ ID4+Pj4+PiAgICAqU2VudDoqIE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgNTo0MCBBTQ0KPiA+Pj4+ Pj4gICAgKlRvOiogYW8udGluZ0B6dGUuY29tLmNuIDxtYWlsdG86YW8udGluZ0B6dGUuY29tLmNu Pg0KPiA+Pj4+Pj4gICAgKkNjOiogc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0K PiA+Pj4+Pj4gICAgKlN1YmplY3Q6KiBbR1JBWU1BSUxdIFJlOiBbc2ZjXSBBZGRpbmcgYW4gTlNI Lm5leHQtaGVhZGVyIHR5cGUNCj4gPj4+Pj4+IG9mIE5TSA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ ID4+Pj4+PiAgICBIYXZpbmcgcmVtaW5kZWQgbXlzZWxmIG9mIHRoZSBOU0ggaGVhZGVyIHN0cnVj dHVyZSwgSSBzZWUgdGhhdA0KPiA+Pj4+IHRoaXMNCj4gPj4+Pj4+ICAgIGlzIG5vdCBzdHJpY3Rs eSBuZWVkZWQgc2luY2UgdGhpcyBuYXR1cmFsbHkgZml0cyB3aXRoIHRoZSBuZXh0DQo+ID4+Pj4+ PiAgICBwcm90b2NvbCBjb21wb25lbnQgb2YgdGhlIGJhc2UgaGVhZGVyLiBUaHVzIHN0YXRpbmcg dGhhdCB0aGUNCj4gPj4+PiB0aGVyZQ0KPiA+Pj4+Pj4gICAgaXMgbm8gYXJjaGl0ZWN0dXJhbCBs aW1pdCBvbiB0aGUgbnVtYmVyIG9mIFNGSCBoZWFkZXJzIGluIGENCj4gPj4+PiBwYWNrZXQNCj4g Pj4+Pj4+ICAgIGlzIHRoZSBuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQgcmVxdWlyZW1lbnQgdG8g YWxsb3cgYW4gYXJiaXRhdHJ5DQo+ID4+Pj4+PiAgICBzdGFjayBvZiBOU0ggaGVhZGVycy4gU3Rh dGluZyB0aGF0IG5ldyBOU0ggaGVhZGVycyBhcmUgYWRkZWQgYXQNCj4gPj4+Pj4+ICAgIHRoZSBm cm9udA0KPiA+Pj4+Pj4gICAgb2YgdGhlIHBhY2tldCwgYW5kIHByb2Nlc3NlZCBmaXJzdCBhbmQg ZGlzY2FyZGVkIGZpcnN0IGlzDQo+ID4+Pj4gc3VmZmljaWVudA0KPiA+Pj4+Pj4gICAgdG8gcmVt b3ZlIGFueSBwcm9jZXNzaW5nIGFtYmlndWl0eS4gUHJvY2Vzc2luZyB3b3VsZCBhbHNvIGJlDQo+ ID4+Pj4gc2ltcGxlcg0KPiA+Pj4+Pj4gICAgaXMgeW91IGZvbGxvd2VkIHRoZSBNUExTIHJ1bGUg dGhhdCB0aGUgb3V0ZXIgaGVhZGVyIGlzIHRoZQ0KPiA+Pj4+Pj4gb25seQ0KPiA+Pj4+IG9uZQ0K PiA+Pj4+Pj4gICAgaW4gc2NvcGUgdW50aWwgdGhhdCBoZWFkZXIgaXMgZGlzY2FyZGVkIChwb3Bw ZWQpLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgIEkgZG8gaG93ZXZlciB3b25kZXIgd2hldGhlciB0 aGUgSUVURidzIGFyY2hpdGV0dXJhbCBwcmVmZXJlbmNlDQo+ID4+Pj4gZm9yDQo+ID4+Pj4+PiAg ICBzZWxmIGRlc2NyaWJpbmcgcGFja2V0cyAoTVBMUyBiZWluZyB0aGUgZXhjZXB0aW9uKSBsZWFk cyB1cyB0bw0KPiA+Pj4+IG1vcmUNCj4gPj4+Pj4+ICAgIGNvbXBsZXggYW5kIHRodXMgbGVzcyBl ZmZpY2VudCBkYXRhcGxhbmUgZGVzaWducyB0aGFuIHdlIGNvdWxkDQo+ID4+Pj4+PiAgICBvdGhl cndpc2UNCj4gPj4+Pj4+ICAgIGFjaGlldmUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgLSBTdGV3 YXJ0DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgT24gMTQvMDMvMjAxNiAwMTo0NCwgYW8udGluZ0B6 dGUuY29tLmNuDQo+ID4+Pj4+PiAgICA8bWFpbHRvOmFvLnRpbmdAenRlLmNvbS5jbj4gd3JvdGU6 DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgIFN0ZXdhcnQsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g ICAgICAgIFRoYW5rcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgRG8geW91IG1lYW4gd2Ug c2hvdWxkIGFkZCBhbiBpbmRpY2F0b3IgZm9yIHRoZSBuZXN0ZWQgTlNIPw0KPiA+PiBJDQo+ID4+ Pj4+PiAgICAgICAgYWdyZWUgYW55dGhpbmcgbmV3IHNob3VsZCBiZSBjb25zaWRlcmVkIGNhcmVm dWxseS4gQW5kIHRoYXQncw0KPiA+Pj4+Pj4gICAgICAgIHdoYXQgd2UgYXJlIGRvaW5nIHJpZ2h0 IG5vdy46KQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgILeivP7IyzogU3Rld2FydCBCcnlhbnQgPHN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbT4NCj4gPj4+Pj4+ICAgICAgICA8bWFpbHRvOnN0ZXdhcnQuYnJ5 YW50QGdtYWlsLmNvbT4NCj4gPj4+Pj4+ICAgICAgICDK1bz+yMs6DQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+InNmY0BpZXRmLm9yZyI8bWFpbHRvOnNmY0BpZXRmLm9y Zz48c2ZjQGlldGYuDQo+ID4+Pj4+PiBvcmcNCj4gPj4+Pj4+PiAsDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gICAgICAgIMjVxto6IDIwMTYvMDMvMTEgMTc6MjUNCj4gPj4+Pj4+ICAgICAgICDW98ziOiBS ZTogW3NmY10gQWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlciB0eXBlIG9mIE5TSA0KPiA+Pj4+Pj4g ICAgICAgILeivP7IyzogInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3JnPg0KPiA+Pj4+Pj4gPG1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+Pj4+IC0NCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+Pj4gLS0tDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICAg ICBUaGUgcHJvdG9jb2wgdGhhdCBjaG9zZSB0aGUgbW9zdCBlbGVnYW50IGFwcHJvYWNoIHRvIGxh eWVyaW5nDQo+ID4+Pj4+PiAgICAgICAgb25lIGhlYWRlciBvbiBhbm90aGVyIHdhcyBNUExTLCB3 aXRoIGl0cyBzdGFja2luZyBhcHByb2FjaA0KPiA+Pj4+Pj4gICAgICAgIGFuZCBvbmUgYml0IGVu ZCBvZiBzdGFjayBpbmRpY2F0b3IuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgIFN1Y2ggYSBz aW1wbGUgZ2VuZXJhbCBhcHByb2FjaCBoYXMgbXVjaCB0byBjb21tZW5kIGl0DQo+ID4+Pj4+PiAg ICAgICAgYW5kIHlvdSBtaWdodCB0aGluayBzZXJpb3VzbHkgYWJvdXQgYXBwbHlpbmcgaXQgaGVy ZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgU3Rld2FydA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+Pj4+Pj4gICAgICAgIHNmYyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ICAgICAgICBzZmNAaWV0 Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gPGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPmh0dHBzOi8vd3d3LmlldGYub3JnL20N Cj4gPj4+Pj4+IGENCj4gPj4+Pj4+IGlsbQ0KPiA+Pj4+Pj4gYW4vbGlzdGluZm8vc2ZjDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBzZmMgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+IHNmY0BpZXRmLm9yZw0KPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPiA+Pj4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4gPj4+IHNm Y0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+IHNmY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj From nobody Tue Apr 5 06:59: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 BB5A912D18F for ; Tue, 5 Apr 2016 06:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-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 V4A8IuFtNEi7 for ; Tue, 5 Apr 2016 06:56:08 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id B149A12D11B for ; Tue, 5 Apr 2016 06:56:08 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 09:56:07 -0400 From: Dave Dolson To: Xuxiaohu , "UTTARO, JAMES" , "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] Comments on draft-ietf-sfc-nsh [was Adding an NSH.next-header type of NSH] Thread-Index: AdGPQtdy/i1AdXCZT2K2Ny8kyOdMFQ== Date: Tue, 5 Apr 2016 13:56:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.161.186] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 05 Apr 2016 06:59:54 -0700 Cc: Ron Parker , "sfc@ietf.org" , "EXT Bottorff, Paul" , "Jim Guichard \(jguichar\)" , "Dolganow, Andrew \(Nokia - SG\)" , "ao.ting@zte.com.cn" , Stewart Bryant , "Joel M. Halpern" Subject: Re: [sfc] Comments on draft-ietf-sfc-nsh [was Adding an NSH.next-header type of NSH] 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, 05 Apr 2016 13:56:10 -0000 Rml4ZWQgdG9waWMgb2YgdGhyZWFkIGFuZCByZW1vdmVkIHRyYWlsaW5nIG90aGVyIHRvcGljLg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhp YW9odUBodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDEwOjMyIEFN DQpUbzogVVRUQVJPLCBKQU1FUzsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQpDYzogSmlt IEd1aWNoYXJkIChqZ3VpY2hhcik7IEpvZWwgTS4gSGFscGVybjsgU3Rld2FydCBCcnlhbnQ7IFJv biBQYXJrZXI7IERhdmUgRG9sc29uOyBEb2xnYW5vdywgQW5kcmV3IChOb2tpYSAtIFNHKTsgRVhU IEJvdHRvcmZmLCBQYXVsOyBhby50aW5nQHp0ZS5jb20uY247IHNmY0BpZXRmLm9yZw0KU3ViamVj dDogcmU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEFkZGluZyBhbiBOU0gubmV4dC1oZWFkZXIgdHlw ZSBvZiBOU0gNCg0KSSBmdWxseSBhZ3JlZSB0aGF0IGEgbWF0cml4IG9mIGRhdGEgcGxhbmUgZW5j YXBzIGN1cnJlbnRseSBpbiB1c2UgYW5kIHdoYXQgZnVuY3Rpb25zIHJlcXVpcmVkIGJ5IFNGQyBh cmUgc3VwcG9ydGVkIHNob3VsZCBiZSBhIG11c3QgYmVmb3JlIGRlc2lnbmluZyBhIG5ldyBkYXRh IHBsYW5lLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBVVFRBUk8sIEpBTUVTIFtqdTE3MzhAYXR0LmNv bV0NCreiy83KsbzkOiAyMDE2xOo01MI1yNUgMzo0NA0KytW8/sjLOiBYdXhpYW9odTsgQ2FybG9z IFBpZ25hdGFybyAoY3BpZ25hdGEpDQqzrcvNOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgSm9l bCBNLiBIYWxwZXJuOyBTdGV3YXJ0IEJyeWFudDsgUm9uIFBhcmtlcjsgRGF2ZSBEb2xzb247IERv bGdhbm93LCBBbmRyZXcgKE5va2lhIC0gU0cpOyBFWFQgQm90dG9yZmYsIFBhdWw7IGFvLnRpbmdA enRlLmNvbS5jbjsgc2ZjQGlldGYub3JnDQrW98ziOiBSRTogW3NmY10gW0dSQVlNQUlMXSBSZTog QWRkaW5nIGFuIE5TSC5uZXh0LWhlYWRlciB0eXBlIG9mIE5TSA0KDQpTbywgSSBmb3VuZCB0aW1l IHRvIHJlYWQgdGhlIE5TSCBkcmFmdCBpbiBpdHMgZW50aXJldHkuIEEgZmV3IHN1Z2dlc3Rpb25z Og0KDQpJZGVudGlmeSBzcGVjaWZpYyB1c2UgY2FzZXMgdGhhdCByZXF1aXJlIE5TSCBTZWMgMi4y IGxpc3RzIDcgYnJvYWQgYXJlYXMgdGhhdCBhcmUgdG9vIGhpZ2ggbGV2ZWwuDQoNCiBFeGFtcGxl cw0KDQpCdWxsZXQgMiAiU2VydmljZSBDaGFpbiBDb25zdHJ1Y3Rpb24iIGNpdGVzIHRoZSBub3Rp b24gdGhhdCBtb3N0IGNoYWlucyBhcmUgYnVpbHQgdGhyb3VnaCBtYW51YWwgY29uZmlnIHdoaWNo IGlzIHNsb3cgYW5kIGVycm9yIHByb25lLiBXb3VsZCBhIHByb2Nlc3MgdGhhdCByZWxpZXMgb24g YSBjb250cm9sbGVyIHRvIGNvbmZpZ3VyZSB0aGVzZSBjaGFpbnMgY29ycmVjdCB0aGlzIGRlZmlj aWVuY3kgb3IgY2FuIGl0IG9ubHkgYmUgZml4ZWQgd2l0aCBOU0guDQoNCkJ1bGxldCA0ICJQZXIg U2VydmljZSAocmUpIENsYXNzaWZpY2F0aW9uIiAgSG93IG5lZWRlZCBpcyB0aGlzID8gV2hhdCBw ZXJjZW50YWdlIG9mIGNoYWlucyB3aWxsIHJlcXVpcmUgaXQ/IE1vcmUgc3BlY2lmaWMgZXhhbXBs ZXMsIHdoYXQgYXJlIHRoZSBhbHRlcm5hdGl2ZXMgc3VjaCBhcyB0aGUgbm90IHJlZGlyZWN0IHRo ZSB0byBhIG5ldyBjaGFpbiBidXQgdGFrZSB0ZXJtaW5hbCBhY3Rpb24gdGhlcmUgb3Igc2VuZCB0 byBhIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIgLi4uLg0KDQpCdWxsZXQgNiAiTGltaXRlZCBFbmQt dG8tRW5kIFNlcnZpY2UgVmlzaWJpbGl0eSIgIEEgYml0IGNvbmZ1c2VkIGhlcmUuIERvIHdlIGFu dGljaXBhdGUgY2hhaW5zIHNwYW5uaW5nIG11bHRpcGxlIGRhdGEgY2VudGVycz8gVGhpcyB3b3Vs ZCBzZWVtIHRvIHJlcXVpcmUgcXVpdGUgYSBiaXQgb2YgZWZmb3J0IGZvciB0aGUgdHJhbnNwb3J0 IGxheWVyIGkuZSBNUExTLg0KDQpJTU8gdGhpcyBlbnRpcmUgc2VjdGlvbiBuZWVkcyB0byBiZSBt YWRlIGZvciBtb3JlIHNwZWNpZmljLiBZb3UgbWF5IGNvbnNpZGVyIHB1bGxpbmcgaXQgb3V0IGlu dG8gYSByZXFzL3VzZSBjYXNlIGRyYWZ0Lg0KDQpTZWMgMi4zIGlkZW50aWZpZXMgaG93IGFsbCBv ZiB0aGUgaXNzdWVzIGluIFNlYyAyLjIgYXJlIGFtZWxpb3JhdGVkLiBOZWVkIGEgYmV0dGVyIGRl ZmluaXRpb24gb2YgU2VjIDIuMiBwcmlvciB0byBhc3NpZ25pbmcgdGhlIE5TSCByZW1lZHkgaW4g U2VjIDIuMw0KDQpBbHRob3VnaCBJIHJlYWQgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IEkgd2ls bCBub3QgY29tbWVudCBhcyB0aGUgZHJpdmVycyBmb3IgdGhpcyBuZXcgZGF0YSBwbGFuZSBlbmNh cCBpcyBub3QgY2xlYXIgdG8gbWUuIEhhdmUgeW91IHJlYWNoZWQgb3V0IHRvIHRoZSBXR3MgdGhh dCBkZWFsIHdpdGggZGF0YSBwbGFuZSBlbmNhcCB0byBzZWUgaWYgdGhleSBjYW4gbWVldCB0aGUg cmVxcz8NCg0KSXQgd291bGQgYmUgdXNlZnVsIHRvIHNlZSBhIG1hdHJpeCBvZiBkYXRhIHBsYW5l IGVuY2FwcyBjdXJyZW50bHkgaW4gdXNlIGFuZCB3aGF0IGZ1bmN0aW9ucyByZXF1aXJlZCBieSBT RkMgYXJlIHN1cHBvcnRlZC4gVGhpcyBtYXkgbGVhZCB0byBhIHNvbHV0aW9uIHRoYXQgZG9lcyBu b3QgY3JlYXRlIGEgbmV3IGRhdGEgZW5jYXAgYnV0IGV4dGVuZHMgb25lIG9mIHRoZSBjdXJyZW50 IHNldC4NCg0KSWYgdGhlIG5vdGlvbiBoZXJlIGlzIHRvIGFic3RyYWN0IGRhdGEgcGxhbmUgZW5j YXAgYXMgdGhlcmUgYXJlIHRvbyBtYW55LCB0aGVuIGl0IG1heSBiZSBiZXN0IHRvIHBpY2sgdGhl IG9uZSB0aGF0IG1vc3Qgc2F0aXNmaWVzIHRoZSBTRkMgbmVlZCBhbmQgcHV0IGEgc3Rha2UgaW4g dGhlIGdyb3VuZC4NCg0KSmltIFV0dGFybw0KDQoNCiJUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgQVQmVCBwcm9wZXJ0eSwgYXJlIGNvbmZpZGVudGlhbCwg YW5kIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhpcyBlbWFpbCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IG9u ZSBvZiB0aGUgbmFtZWQgcmVjaXBpZW50KHMpIG9yIG90aGVyd2lzZSBoYXZlIHJlYXNvbiB0byBi ZWxpZXZlIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgaW1tZWRpYXRlbHkg ZnJvbSB5b3VyIGNvbXB1dGVyLiBBbnkgb3RoZXIgdXNlLCByZXRlbnRpb24sIGRpc3NlbWluYXRp b24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvciBjb3B5aW5nIG9mIHRoaXMgZW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4iDQoNCg== From nobody Tue Apr 5 18:44:01 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 648C612D173 for ; Tue, 5 Apr 2016 18:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 758EpqmVfcOe for ; Tue, 5 Apr 2016 18:43:57 -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 3F6A412D59C for ; Tue, 5 Apr 2016 18:43:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLP93511; Wed, 06 Apr 2016 01:43:54 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 02:43:52 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 09:43:46 +0800 From: Youjianjie To: "sfc@ietf.org" Thread-Topic: Legacy SF Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3OOASgga+w3SA= Date: Wed, 6 Apr 2016 01:43:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.148] Content-Type: multipart/alternative; boundary="_000_F6C28B32DA084644BB6C8D0BD65B669DBDFB2ANKGEML515MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.570469DA.00C9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 578413445d7edf4f2ce797e8c4077d31 Archived-At: Subject: [sfc] Legacy SF 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, 06 Apr 2016 01:43:59 -0000 --_000_F6C28B32DA084644BB6C8D0BD65B669DBDFB2ANKGEML515MBXchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXb3VsZCB5b3UgbGlrZSB0byByZXZpZXcgbGVnYWN5LVNGIGRyYWZ0Pw0KDQpU aGFua3MsDQpKaWFuamllDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNvbmctc2Zj LWxlZ2FjeS1zZi1tYXBwaW5nLTA3LnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEppYW5qaWUgWW91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K DQoNCk5hbWU6ICAgICAgICAgICAgICAgZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmcN Cg0KUmV2aXNpb246ICAwNw0KDQpUaXRsZTogICAgICAgICAgICAgICAgICBTRkMgSGVhZGVyIE1h cHBpbmcgZm9yIExlZ2FjeSBTRg0KDQpEb2N1bWVudCBkYXRlOiAgICAgICAyMDE2LTA0LTA1DQoN Ckdyb3VwOiAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAg ICAgICAgICAgICAxNw0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXNvbmctc2ZjLWxlZ2FjeS1zZi1tYXBwaW5nLTA3LnR4dA0KDQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc29u Zy1zZmMtbGVnYWN5LXNmLW1hcHBpbmcvDQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBpbmctMDcNCg0KRGlm ZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zb25n LXNmYy1sZWdhY3ktc2YtbWFwcGluZy0wNw0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIEEgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKSBkZWZpbmVzIGEgc2V0IG9mIGFic3RyYWN0IFNlcnZpY2UN Cg0KICAgRnVuY3Rpb25zIChTRikgYW5kIG9yZGVyaW5nIGNvbnN0cmFpbnRzIHRoYXQgbXVzdCBi ZSBhcHBsaWVkIHRvDQoNCiAgIHBhY2tldHMgYW5kL29yIGZyYW1lcyBzZWxlY3RlZCBhcyBhIHJl c3VsdCBvZiBjbGFzc2lmaWNhdGlvbi4gIE9uZQ0KDQogICBhc3N1bXB0aW9uIG9mIHRoaXMgZG9j dW1lbnQgaXMgdGhhdCBsZWdhY3kgc2VydmljZSBmdW5jdGlvbnMgY2FuDQoNCiAgIHBhcnRpY2lw YXRlIGluIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5zIHdpdGhvdXQgaGF2aW5nIHN1cHBvcnQgZm9y IHRoZQ0KDQogICBTRkMgaGVhZGVyLCBvciBldmVuIGJlaW5nIGF3YXJlIG9mIGl0LiAgVGhpcyBk b2N1bWVudCBwcm92aWRlcyBhDQoNCiAgIG1lY2hhbmlzbSBiZXR3ZWVuIGFuIFNGQyBwcm94eSBh bmQgYW4gU0ZDLXVuYXdhcmUgc2VydmljZSBmdW5jdGlvbg0KDQogICAoaGVyZWluIHRlcm1lZCAi bGVnYWN5IFNGIiksIHRvIGlkZW50aWZ5IHRoZSBTRkMgaGVhZGVyIGFzc29jaWF0ZWQNCg0KICAg d2l0aCBhIHBhY2tldCB0aGF0IGlzIHJldHVybmVkIGZyb20gYSBsZWdhY3kgU0YsIHdpdGhvdXQg YW4gU0ZDDQoNCiAgIGhlYWRlciBiZWluZyBleHBsaWNpdGx5IGNhcnJpZWQgaW4gdGhlIHdpcmVk IHByb3RvY29sIGJldHdlZW4gU0ZDDQoNCiAgIHByb3h5IGFuZCBsZWdhY3kgU0YuDQoNCg0Kt6K8 /sjLOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBTb25naGFpYmluIChB KQ0Kt6LLzcqxvOQ6IDIwMTXE6jfUwjbI1SAxNzoyNA0KytW8/sjLOiBKaW0gR3VpY2hhcmQgKGpn dWljaGFyKTsgc2ZjQGlldGYub3JnDQrW98ziOiBSZTogW3NmY10gU0ZDIFdHIGFnZW5kYSBzbG90 cyAtIFByYWd1ZQ0KDQpIaSBKaW0sDQoNCkkgd291bGQgbGlrZSB0byByZXF1ZXN0IGEgdmVyeSBz aG9ydCBzbG90IHByZXNlbnRhdGlvbiBmb3IgZHJhZnQtc29uZy1zZmMtbGVnYWN5LXNmLW1hcHBp bmctMDUuIFRoaXMgZG9jdW1lbnQgc2VydmVzIHRoZSBwdXJwb3NlIGhvdyBsZWdhY3kgc2Vydmlj ZSBmdW5jdGlvbnMgY2FuIHBhcnRpY2lwYXRlIGluIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu aW5nLiBUaGVyZSBhcmUgc29tZSB1cGRhdGVzLiBXZSBtYWtlIGl0IGluZm9ybWF0aW9uYWwgYW5k IHJlbW92ZSBSRkMgMjExOSBsYW5ndWFnZSwgYW5kIGFkZCBhIGxpdHRsZSBtb3JlIGRlcGxveW1l bnQgY29uc2lkZXJhdGlvbnMsIGFuZCBhbHNvIGNsYXJpZnkgb24gdGhlIG1ldGEgZGF0YSBwcm9i bGVtLg0KDQpCZXN0IFJlZ2FyZHMhDQotSGFpYmluDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNClNl bnQ6IFNhdHVyZGF5LCBKdW5lIDI3LCAyMDE1IDEwOjU4IFBNDQpUbzogc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2ZjXSBTRkMgV0cgYWdlbmRhIHNsb3RzIC0g UHJhZ3VlDQoNCkdyZWV0aW5ncyBXRzoNCg0KT3VyIG1lZXRpbmcgaW4gUHJhZ3VlIGlzIGZhc3Qg YXBwcm9hY2hpbmcuIEFzIGFsd2F5cyB0aGUgZ29hbCBvZiB0aGUgbWVldGluZyB3aWxsIGJlIHRv IG1ha2UgdGhlIGJlc3QgdXNlIG9mIG91ciBsaW1pdGVkIGZhY2UtdG8tZmFjZSB0aW1lLiBXaXRo IHRoYXQgaW4gbWluZCB3ZSB3ZWxjb21lIHJlcXVlc3RzIGZvciBhZ2VuZGEgdGltZS4NCg0KQXMg d2UgYnVpbGQgdGhlIG1lZXRpbmcgYWdlbmRhIG91ciBnb2FsIHdpbGwgYmUgdG8gc2VsZWN0IHBy ZXNlbnRhdGlvbnMgdGhhdCBiZXN0IGZ1cnRoZXIgdGhlIHdvcmsgb2YgdGhlIFdHLCBhbmQgdGhh dCBnZW5lcmFsbHkgbWVhbnMgZm9jdXNpbmcgb24ga2V5IGNoYXJ0ZXIgZGVsaXZlcmFibGVzIGFu ZCB0b3BpY3Mgd2l0aCBpbXBvcnRhbnQgb3BlbiBpc3N1ZXMgdG8gcmVzb2x2ZS4gV2hlbiBtYWtp bmcgYSByZXF1ZXN0IHBsZWFzZSBjb25zaWRlciB3aGF0IHlvdSB0aGluayB0aGUgV0cgc2hvdWxk IGRvIHdpdGggaXRzIGNvbnRlbnQgqEMgZm9yIGV4YW1wbGU6DQoNCiAgKiAgIERvZXMgdGhlIGRv Y3VtZW50IGhhdmUgdXNlZnVsIGNvbnRlbnQgdGhhdCBzaG91bGQgYmUgbW92ZWQgaW50byBhbm90 aGVyIFdHIGRvY3VtZW50IG9yIHByb2dyZXNzIG9uIGl0cyBvd24gbWVyaXQNCiAgKiAgIERvZXMg dGhlIGNvbnRlbnQgaGF2ZSBhIGdvb2QgYmFzaXMgZm9yIG9uZSBvZiB0aGUgV0cgZG9jdW1lbnRz IHBlciB0aGUgY2hhcnRlcg0KICAqICAgU2hvdWxkIHRoZSBkb2N1bWVudCBjb250ZW50IGJlIG1l cmdlZCB3aXRoIG9uZSBvciBtb3JlIG90aGVyIGRvY3VtZW50cywgc28gdGhhdCBhIGNvbWJpbmVk IGRvY3VtZW50IGNvdWxkIGJlY29tZSBhIFdHIGRvY3VtZW50DQpKaW0gJiBUaG9tYXMNCg== --_000_F6C28B32DA084644BB6C8D0BD65B669DBDFB2ANKGEML515MBXchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

Would you = like to review legacy-SF draft?

 = ;

Thanks,

Jianjie

 = ;

A new version of I-D, draft-= song-sfc-legacy-sf-mapping-07.txt

has been successfully submit= ted by Jianjie You and posted to the IETF repository.

 

Name:    = ;           draft-song-sf= c-legacy-sf-mapping

Revision:  07

Title:   &nbs= p;            &= nbsp; SFC Header Mapping for Legacy SF

Document date:  &n= bsp;    2016-04-05

Group:   &nbs= p;           Individual S= ubmission

Pages:   &nbs= p;           17

URL:    =         https://www.ietf.org/internet-drafts/draft-song-sfc-legacy-sf-mapping-07.tx= t

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/=

Htmlized:   &= nbsp;   https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-07

Diff:    = ;       https://www.ietf.org/rfcdiff?url2=3Ddraft-song-sfc-legacy-sf-mapping-07=

 

Abstract:<= /p>

   A Service Funct= ion Chain (SFC) defines a set of abstract Service

   Functions (SF) = and ordering constraints that must be applied to

   packets and/or = frames selected as a result of classification.  One<= /p>

   assumption of t= his document is that legacy service functions can

   participate in = service function chains without having support for the

   SFC header, or = even being aware of it.  This document provides a

   mechanism betwe= en an SFC proxy and an SFC-unaware service function

   (herein termed = "legacy SF"), to identify the SFC header associated

   with a packet t= hat is returned from a legacy SF, without an SFC

   header being ex= plicitly carried in the wired protocol between SFC

   proxy and legac= y SF.

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: sfc [mailto:sfc-bounc= es@ietf.org] =B4=FA=B1=ED = Songhaibin (A)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2015=C4=EA7=D4=C2<= span lang=3D"EN-US">6=C8=D5 17:24
=CA=D5=BC=FE=C8=CB: Jim Guichard (jguichar); sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] SFC WG agenda slots - Prague

 

Hi Jim,

 = ;

I would like to request a ver= y short slot presentation for draft-song-sfc-legacy-sf-mapping-05. This doc= ument serves the purpose how legacy service functions can participate in the service function chaining. There are some updates. We m= ake it informational and remove RFC 2119 language, and add a little more de= ployment considerations, and also clarify on the meta data problem.

 = ;

Best Regards!

-Haibin

 = ;

From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, June 27, 2015 10:58 PM
To: sfc@ietf.org
Subject: [sfc] SFC WG agenda slots - Prague

 

Greetings WG= :

 <= /o:p>

Our meeting = in Prague is fast approaching. As always the goal of the meeting will be to= make the best use of our limited face-to-face time. With that in mind we welcome requests for agenda time. <= /p>

 <= /o:p>

As we build = the meeting agenda our goal will be to select presentations that best furth= er the work of the WG, and that generally means focusing on key charter deliverables and topics with important open issues to resolve.= When making a request please consider what you think the WG should do with= its content =A8C for example:

  • Does the document have useful content that shou= ld be moved into another WG document or progress on its own merit
  • Does the content have a good basis for one of t= he WG documents per the charter
  • Should the document content be merged with one = or more other documents, so that a combined document could become a WG docu= ment

Jim & Th= omas

--_000_F6C28B32DA084644BB6C8D0BD65B669DBDFB2ANKGEML515MBXchina_-- From nobody Wed Apr 6 07:13:31 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 7017612D1C7 for ; Wed, 6 Apr 2016 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 rHXg91u1llbJ for ; Wed, 6 Apr 2016 07:13:29 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 0524512D5E6 for ; Wed, 6 Apr 2016 07:13:29 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 6 Apr 2016 10:13:27 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Wed, 6 Apr 2016 10:13:27 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71w== Date: Wed, 6 Apr 2016 14:13:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.162.97] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F0AC6Dwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 14:13:30 -0000 --_000_E8355113905631478EFF04F5AA706E9830F0AC6Dwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To those authors of metadata allocations, I have a request. I believe many types of service functions are going to want to distinguish = up-link traffic from down-link traffic. E.g., a security device treats in-bound to the protected device differently= from out-bound. E.g., an accounting system needs to know whether to charge the source or de= stination node. So my request is to allocate a bit for up-link/down-link discrimination. I think the alternative is to configure each SF about each path whether it = is up or down, or to use something like an even/odd path ID scheme. Does anyone else see this as useful? I believe all of the allocation drafts have reserved bits. David Dolson Senior Software Architect Sandvine --_000_E8355113905631478EFF04F5AA706E9830F0AC6Dwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To those authors of metadata allocations, I have a r= equest.

I believe many types of service functions are going = to want to distinguish up-link traffic from down-link traffic.

E.g., a security device treats in-bound to the prote= cted device differently from out-bound.

E.g., an accounting system needs to know whether to = charge the source or destination node.

 

So my request is to allocate a bit for up-link/down-= link discrimination.

I think the alternative is to configure each SF abou= t each path whether it is up or down, or to use something like an even/odd = path ID scheme.

 

Does anyone else see this as useful?

 

I believe all of the allocation drafts have reserved= bits.

 

 

David Dolson

Senior Software Architect

Sandvine

 

--_000_E8355113905631478EFF04F5AA706E9830F0AC6Dwtlexchp2sandvi_-- From nobody Wed Apr 6 07:23:39 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 6384812D525 for ; Wed, 6 Apr 2016 07:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BS80JZb8NquG for ; Wed, 6 Apr 2016 07:23:24 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (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 6524C12D0B4 for ; Wed, 6 Apr 2016 07:23:18 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id w85so60170722oiw.0 for ; Wed, 06 Apr 2016 07:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=waPFI5j/70jCLXjjMb5x9l+byKGkLmVP8svzXBM3gbU=; b=b3yg7BbRrVnEtRVU+49nNbO7VxghYhNgC93CkmL9jBxaGnXVeZVak1qjhxGnzB76YR xM00hRqIZxbLPZufMPtX/LAnayQ6EPINTCl96efnyCYtV0jysIo119bbYvdYK1FnASVS usUxcF60fVwveamYyM9ORXcyXn2HjTxDFL3Q147kGOu/NfcIxb08snyy+m7CmqWYBqNu C0yEZ8HhsVRLW8XdlHHHtHkWw16wVSD67eUpDhOOVf7vF2k9rB431wnNonItnNMm2lKJ uiGiB0rKTwXladUywxM/U94f/Bwz36Rtf8ssVBszMQbhK52smfg9KtjoVfUqKRl/bz+X i2Kg== X-Gm-Message-State: AD7BkJIQrUmwbsNWL8bXD+SRm8MFLVQlCCQEP6dbdmJuGtstisFOcqohun0zomigdDAwlQqW X-Received: by 10.157.14.183 with SMTP id 52mr10294760otj.83.1459952597719; Wed, 06 Apr 2016 07:23:17 -0700 (PDT) Received: from [10.199.103.180] ([64.129.172.15]) by smtp.gmail.com with ESMTPSA id u2sm853053obz.24.2016.04.06.07.23.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 07:23:16 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5D82F98D-0656-422F-88FE-2AFA2901B74E Content-Transfer-Encoding: 7bit Message-Id: <8FE30018-9F2B-448E-AB70-B1EC5EE3F39D@redhat.com> X-Mailer: iPhone Mail (13D15) From: Azhar Sayeed Date: Wed, 6 Apr 2016 09:23:14 -0500 To: Dave Dolson Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 14:23:31 -0000 --Apple-Mail-5D82F98D-0656-422F-88FE-2AFA2901B74E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Dave, Why would you need a bit to distinguish the upstream and downstream traffic -= the traffic stream can be determined from SA/DA pair at the classifier and t= he classifier can map the traffic to a service chain May be I don't understand the use case you are describing. Moreover upstream and downstream is relative to the point of view=20 Regards Azhar > On Apr 6, 2016, at 9:13 AM, Dave Dolson wrote: >=20 > To those authors of metadata allocations, I have a request. > I believe many types of service functions are going to want to distinguish= up-link traffic from down-link traffic. > E.g., a security device treats in-bound to the protected device differentl= y from out-bound. > E.g., an accounting system needs to know whether to charge the source or d= estination node. > =20 > So my request is to allocate a bit for up-link/down-link discrimination. > I think the alternative is to configure each SF about each path whether it= is up or down, or to use something like an even/odd path ID scheme. > =20 > Does anyone else see this as useful? > =20 > I believe all of the allocation drafts have reserved bits. > =20 > =20 > David Dolson > Senior Software Architect > Sandvine > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-5D82F98D-0656-422F-88FE-2AFA2901B74E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Why would you need a bit to d= istinguish the upstream and downstream traffic - the traffic stream can be d= etermined from SA/DA pair at the classifier and the classifier can map the t= raffic to a service chain

May be I don't understand the use case you are de= scribing.

Moreover upstream and downstream is relative to the point of view=  


Regards
Azhar



On Apr 6, 2016, at 9:13 AM, Dave Dolson <ddolson@sandvine.com> wrote:

=

To those authors of metadata allocations, I have a re= quest.

I believe many types of service functions are going t= o want to distinguish up-link traffic from down-link traffic.

=

E.g., a security device treats in-bound to the protec= ted device differently from out-bound.

E.g., an accounting system needs to know whether to c= harge the source or destination node.

 

So my request is to allocate a bit for up-link/down-l= ink discrimination.

I think the alternative is to configure each SF about= each path whether it is up or down, or to use something like an even/odd pa= th ID scheme.

 

Does anyone else see this as useful?

 

I believe all of the allocation drafts have reserved b= its.

 

 

David Dolson

Senior Software Architect

Sandvine

 

____________________= ___________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc
= --Apple-Mail-5D82F98D-0656-422F-88FE-2AFA2901B74E-- From nobody Wed Apr 6 07:41: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 9B97D12D5C7 for ; Wed, 6 Apr 2016 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-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 rUyiKu12gB9k for ; Wed, 6 Apr 2016 07:41:46 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2353A12D0C0 for ; Wed, 6 Apr 2016 07:41:46 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 10:41:44 -0400 From: Dave Dolson To: Azhar Sayeed Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wAI8rQAAAfmFdA= Date: Wed, 6 Apr 2016 14:41:44 +0000 Message-ID: References: <8FE30018-9F2B-448E-AB70-B1EC5EE3F39D@redhat.com> In-Reply-To: <8FE30018-9F2B-448E-AB70-B1EC5EE3F39D@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.162.97] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F0AE5Bwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 14:41:48 -0000 --_000_E8355113905631478EFF04F5AA706E9830F0AE5Bwtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIGlubGluZSBbRERdDQoNCkZyb206IEF6aGFyIFNheWVlZCBbbWFpbHRvOmFzYXllZWRAcmVk aGF0LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDYsIDIwMTYgMTE6MjMgQU0NClRvOiBE YXZlIERvbHNvbg0KQ2M6IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIEEgcmVxdWVz dCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNCkhpIERhdmUsDQoNCldoeSB3b3Vs ZCB5b3UgbmVlZCBhIGJpdCB0byBkaXN0aW5ndWlzaCB0aGUgdXBzdHJlYW0gYW5kIGRvd25zdHJl YW0gdHJhZmZpYyAtIHRoZSB0cmFmZmljIHN0cmVhbSBjYW4gYmUgZGV0ZXJtaW5lZCBmcm9tIFNB L0RBIHBhaXIgYXQgdGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBjbGFzc2lmaWVyIGNhbiBtYXAgdGhl IHRyYWZmaWMgdG8gYSBzZXJ2aWNlIGNoYWluDQpbRERdIFllcywgdGhlIGNsYXNzaWZpZXIgc2hv dWxkIGtub3c7IEnigJltIGxvb2tpbmcgZm9yIGEgd2F5IGZvciB0aGUgY2xhc3NpZmllciB0byBj b252ZXkgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLg0KDQpNYXkgYmUg SSBkb24ndCB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3UgYXJlIGRlc2NyaWJpbmcuDQoNCk1v cmVvdmVyIHVwc3RyZWFtIGFuZCBkb3duc3RyZWFtIGlzIHJlbGF0aXZlIHRvIHRoZSBwb2ludCBv ZiB2aWV3DQpbRERdIFllcywgYnV0IEkgYmVsaWV2ZSBmZXcgYXBwbGljYXRpb25zIGFyZSBwcm92 aWRpbmcgc2VydmljZSB0byBib3RoIG5vZGVzIGluIHRoZSBjb252ZXJzYXRpb24uIERhdGFjZW50 ZXIgbm9kZXMgYXJlIHdvcmtpbmcgZm9yIHRoZSBzZXJ2ZXJzLCBhbmQgSVNQIG5vZGVzIHRha2Ug dGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBpbnRlcm5ldCBzdWJzY3JpYmVyLg0KU2VydmljZSBGdW5j dGlvbnMgdGhhdCBkb27igJl0IGNhcmUgY2FuIGlnbm9yZSB0aGUgYml0Lg0KDQoNCg0KUmVnYXJk cw0KQXpoYXINCg0KDQpPbiBBcHIgNiwgMjAxNiwgYXQgOToxMyBBTSwgRGF2ZSBEb2xzb24gPGRk b2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOg0K VG8gdGhvc2UgYXV0aG9ycyBvZiBtZXRhZGF0YSBhbGxvY2F0aW9ucywgSSBoYXZlIGEgcmVxdWVz dC4NCkkgYmVsaWV2ZSBtYW55IHR5cGVzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBnb2luZyB0 byB3YW50IHRvIGRpc3Rpbmd1aXNoIHVwLWxpbmsgdHJhZmZpYyBmcm9tIGRvd24tbGluayB0cmFm ZmljLg0KRS5nLiwgYSBzZWN1cml0eSBkZXZpY2UgdHJlYXRzIGluLWJvdW5kIHRvIHRoZSBwcm90 ZWN0ZWQgZGV2aWNlIGRpZmZlcmVudGx5IGZyb20gb3V0LWJvdW5kLg0KRS5nLiwgYW4gYWNjb3Vu dGluZyBzeXN0ZW0gbmVlZHMgdG8ga25vdyB3aGV0aGVyIHRvIGNoYXJnZSB0aGUgc291cmNlIG9y IGRlc3RpbmF0aW9uIG5vZGUuDQoNClNvIG15IHJlcXVlc3QgaXMgdG8gYWxsb2NhdGUgYSBiaXQg Zm9yIHVwLWxpbmsvZG93bi1saW5rIGRpc2NyaW1pbmF0aW9uLg0KSSB0aGluayB0aGUgYWx0ZXJu YXRpdmUgaXMgdG8gY29uZmlndXJlIGVhY2ggU0YgYWJvdXQgZWFjaCBwYXRoIHdoZXRoZXIgaXQg aXMgdXAgb3IgZG93biwgb3IgdG8gdXNlIHNvbWV0aGluZyBsaWtlIGFuIGV2ZW4vb2RkIHBhdGgg SUQgc2NoZW1lLg0KDQpEb2VzIGFueW9uZSBlbHNlIHNlZSB0aGlzIGFzIHVzZWZ1bD8NCg0KSSBi ZWxpZXZlIGFsbCBvZiB0aGUgYWxsb2NhdGlvbiBkcmFmdHMgaGF2ZSByZXNlcnZlZCBiaXRzLg0K DQoNCkRhdmlkIERvbHNvbg0KU2VuaW9yIFNvZnR3YXJlIEFyY2hpdGVjdA0KU2FuZHZpbmUNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_E8355113905631478EFF04F5AA706E9830F0AE5Bwtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNl ZSBpbmxpbmUgW0REXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEF6aGFyIFNheWVlZCBbbWFpbHRvOmFzYXllZWRAcmVkaGF0LmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDE2IDExOjIzIEFN PGJyPg0KPGI+VG86PC9iPiBEYXZlIERvbHNvbjxicj4NCjxiPkNjOjwvYj4gc2ZjQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFs bG9jYXRpb24gc2NoZW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBEYXZlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJB cHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XaHkgd291bGQgeW91IG5lZWQgYSBiaXQgdG8gZGlzdGluZ3Vpc2ggdGhlIHVw c3RyZWFtIGFuZCBkb3duc3RyZWFtIHRyYWZmaWMgLSB0aGUgdHJhZmZpYyBzdHJlYW0gY2FuIGJl IGRldGVybWluZWQgZnJvbSBTQS9EQSBwYWlyIGF0IHRoZSBjbGFzc2lmaWVyIGFuZCB0aGUgY2xh c3NpZmllciBjYW4gbWFwIHRoZSB0cmFmZmljIHRvIGEgc2VydmljZSBjaGFpbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltE RF0gWWVzLCB0aGUgY2xhc3NpZmllciBzaG91bGQga25vdzsgSeKAmW0gbG9va2luZyBmb3IgYSB3 YXkgZm9yIHRoZSBjbGFzc2lmaWVyIHRvIGNvbnZleSB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIHNl cnZpY2UgZnVuY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJB cHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NYXkgYmUgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSB5b3UgYXJl IGRlc2NyaWJpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1vcmVvdmVyIHVwc3RyZWFtIGFuZCBkb3duc3RyZWFtIGlzIHJlbGF0aXZlIHRvIHRoZSBwb2lu dCBvZiB2aWV3Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0REXSBZZXMsIGJ1dCBJIGJlbGlldmUgZmV3IGFwcGxp Y2F0aW9ucyBhcmUgcHJvdmlkaW5nIHNlcnZpY2UgdG8gYm90aCBub2RlcyBpbiB0aGUgY29udmVy c2F0aW9uLiBEYXRhY2VudGVyIG5vZGVzIGFyZSB3b3JraW5nIGZvciB0aGUgc2VydmVycywgYW5k IElTUCBub2RlcyB0YWtlIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUgaW50ZXJuZXQgc3Vic2NyaWJl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+U2VydmljZSBGdW5jdGlvbnMgdGhhdCBkb27igJl0IGNhcmUgY2Fu IGlnbm9yZSB0aGUgYml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWls U2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXpoYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIEFwciA2LCAyMDE2LCBhdCA5OjEzIEFNLCBEYXZlIERvbHNvbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tIj5kZG9sc29uQHNhbmR2aW5lLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UbyB0aG9zZSBhdXRob3JzIG9mIG1ldGFkYXRhIGFsbG9jYXRpb25zLCBJIGhhdmUg YSByZXF1ZXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZl IG1hbnkgdHlwZXMgb2Ygc2VydmljZSBmdW5jdGlvbnMgYXJlIGdvaW5nIHRvIHdhbnQgdG8gZGlz dGluZ3Vpc2ggdXAtbGluayB0cmFmZmljIGZyb20gZG93bi1saW5rIHRyYWZmaWMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FLmcuLCBhIHNlY3VyaXR5IGRldmljZSB0cmVh dHMgaW4tYm91bmQgdG8gdGhlIHByb3RlY3RlZCBkZXZpY2UgZGlmZmVyZW50bHkgZnJvbSBvdXQt Ym91bmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FLmcuLCBhbiBhY2Nv dW50aW5nIHN5c3RlbSBuZWVkcyB0byBrbm93IHdoZXRoZXIgdG8gY2hhcmdlIHRoZSBzb3VyY2Ug b3IgZGVzdGluYXRpb24gbm9kZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbXkgcmVxdWVz dCBpcyB0byBhbGxvY2F0ZSBhIGJpdCBmb3IgdXAtbGluay9kb3duLWxpbmsgZGlzY3JpbWluYXRp b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBhbHRl cm5hdGl2ZSBpcyB0byBjb25maWd1cmUgZWFjaCBTRiBhYm91dCBlYWNoIHBhdGggd2hldGhlciBp dCBpcyB1cCBvciBkb3duLCBvciB0byB1c2Ugc29tZXRoaW5nIGxpa2UgYW4gZXZlbi9vZGQgcGF0 aCBJRCBzY2hlbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgYW55b25lIGVsc2Ugc2Vl IHRoaXMgYXMgdXNlZnVsPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgYWxsIG9m IHRoZSBhbGxvY2F0aW9uIGRyYWZ0cyBoYXZlIHJlc2VydmVkIGJpdHMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2 aWQgRG9sc29uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW5pb3IgU29m dHdhcmUgQXJjaGl0ZWN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYW5k dmluZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E8355113905631478EFF04F5AA706E9830F0AE5Bwtlexchp2sandvi_-- From nobody Wed Apr 6 09:34: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 45C6912D52C for ; Wed, 6 Apr 2016 09:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QewkRQ6b3EmD for ; Wed, 6 Apr 2016 09:34:53 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (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 6EBC412D162 for ; Wed, 6 Apr 2016 09:34:53 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id j9so34869425obd.3 for ; Wed, 06 Apr 2016 09:34:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=e65IzZSn6ZHChuNvQ/FQRHrRUsd7EenmS4uirwjed0o=; b=O+40TmDuOkCGEzDGUB52fuZli/sJJcxPVgl8/1BXxJ7VoT8oJGStlAJVrmXw3W0eCm B32yoaSaKyBdIBiCp7o0m9h91OLuWa4oGF1m9bHmBK425vMrY7KOAGh+5dhjjScYgJ5w 3p0G6eVC8KnOhrF3eMFdk3I6Xb7QownvSwhKANzAdrXYknYXFDoVxQv1/Q6TUexqh+hx Gm251oApVRkDiKVP9t6kYFu9Gul2Lnca4SsSe1PsLWU0F3gco5BBtJR22XgX3bh/uAvf Iil9+a1AYwJ6xynlTI75riXnmA7mlE+VSomTa+IHFeES7DYwrbGEXGc/hSvhvcLR8qYk JUkg== X-Gm-Message-State: AD7BkJL4JB3c0nMj9/2wed3+mlPqs2YVNfVUnj1lBmdrm2hjPwdhg/Ai7OEm37Li9v4+Ac8B X-Received: by 10.60.51.135 with SMTP id k7mr9356626oeo.42.1459960492765; Wed, 06 Apr 2016 09:34:52 -0700 (PDT) Received: from [10.199.102.157] ([64.129.172.15]) by smtp.gmail.com with ESMTPSA id i5sm1029609obe.14.2016.04.06.09.34.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 09:34:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F45254EA-0824-4074-8170-7EAF8C633FFB" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Azhar Sayeed In-Reply-To: Date: Wed, 6 Apr 2016 11:34:50 -0500 Message-Id: <7140F7F5-EE1F-4492-A145-C88A2609945C@redhat.com> References: <8FE30018-9F2B-448E-AB70-B1EC5EE3F39D@redhat.com> To: Dave Dolson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 16:34:55 -0000 --Apple-Mail=_F45254EA-0824-4074-8170-7EAF8C633FFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline please > Why would you need a bit to distinguish the upstream and downstream = traffic - the traffic stream can be determined from SA/DA pair at the = classifier and the classifier can map the traffic to a service chain > [DD] Yes, the classifier should know; I=E2=80=99m looking for a way = for the classifier to convey the information to the service function. Azhar> The question is why would an SF care about upstream vs downstream = unless the SF is also doing accounting in which case it may be possible = - Even if you need to identify upstream vs downstream wouldn=E2=80=99t = the sub-id/accounting id be different for upstream vs downstream = traffic? Azhar --Apple-Mail=_F45254EA-0824-4074-8170-7EAF8C633FFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Inline please

Why would you need a = bit to distinguish the upstream and downstream traffic - the traffic = stream can be determined from SA/DA pair at the classifier and the = classifier can map the traffic to a service chain
[DD] Yes, the classifier = should know; I=E2=80=99m looking for a way for the classifier to convey = the information to the service = function.


Azhar> The question = is why would an SF care about upstream vs downstream unless the SF is = also doing accounting in which case it may be possible - Even if you = need to identify upstream vs downstream wouldn=E2=80=99t the = sub-id/accounting id be different for upstream vs downstream = traffic?

<snip>

Azhar

= --Apple-Mail=_F45254EA-0824-4074-8170-7EAF8C633FFB-- From nobody Wed Apr 6 10:41: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 B5E2612D703 for ; Wed, 6 Apr 2016 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-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 nooCeezvOyS3 for ; Wed, 6 Apr 2016 10:41:24 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8B07A12D0F3 for ; Wed, 6 Apr 2016 10:41:24 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 13:41:18 -0400 From: Dave Dolson To: Azhar Sayeed Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wAI8rQAAAfmFdD//+WUAIAANmJw Date: Wed, 6 Apr 2016 17:41:17 +0000 Message-ID: References: <8FE30018-9F2B-448E-AB70-B1EC5EE3F39D@redhat.com> <7140F7F5-EE1F-4492-A145-C88A2609945C@redhat.com> In-Reply-To: <7140F7F5-EE1F-4492-A145-C88A2609945C@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.162.97] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F0BA5Ewtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 17:41:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830F0BA5Ewtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXpoYXIsDQoNCkkgZ3Vlc3MgYnkgc3ViLWlkL2FjY291bnRpbmctaWQgeW91IGFyZSByZWZlcnJp bmcgdG8gc29tZSBtZXRhZGF0YT8NCk5vbmV0aGVsZXNzLCB0aGUgY2hhcmdpbmcgc2NoZW1lcyB0 aGF0IEnigJltIGZhbWlsaWFyIHdpdGggZGlzY3JpbWluYXRlIHVwbG9hZCBieXRlcyBmcm9tIGRv d25sb2FkIGJ5dGVzLg0KKEUuZy4sIFJGQzQwMDYgKGFuZCAzR1BQIEd5KSwgd2hpY2ggcmVmZXJz IHRvIENDLUlucHV0LU9jdGV0cyBhbmQgQ0MtT3V0cHV0LU9jdGV0cyBmb3IgdXAvZG93biB0cmFm ZmljDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDAwNiNzZWN0aW9uLTguMjQpDQoN CkFsc28gdGhpbmsgYWJvdXQgYSBmaXJld2FsbCwgd2hpY2ggbmVlZHMgdG8ga25vdyB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIGFuIGluLWJvdW5kIFNZTiBhbmQgb3V0LWJvdW5kIFNZTi4NCg0KSSBh c3N1cmUgeW91IGRpcmVjdGlvbiBpcyBpbXBvcnRhbnQsIGFuZCB3aWxsIGJlIGFjY29tcGxpc2hl ZCBzb21laG93Lg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBhIGJpdCBpbiBtZXRhZGF0YSBtaWdodCBi ZSBhIGdvb2QgYXBwcm9hY2guDQoNCi1EYXZlDQoNCg0KDQpGcm9tOiBBemhhciBTYXllZWQgW21h aWx0bzphc2F5ZWVkQHJlZGhhdC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAyMDE2 IDE6MzUgUE0NClRvOiBEYXZlIERvbHNvbg0KQ2M6IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzZmNdIEEgcmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNCklubGlu ZSBwbGVhc2UNCg0KV2h5IHdvdWxkIHlvdSBuZWVkIGEgYml0IHRvIGRpc3Rpbmd1aXNoIHRoZSB1 cHN0cmVhbSBhbmQgZG93bnN0cmVhbSB0cmFmZmljIC0gdGhlIHRyYWZmaWMgc3RyZWFtIGNhbiBi ZSBkZXRlcm1pbmVkIGZyb20gU0EvREEgcGFpciBhdCB0aGUgY2xhc3NpZmllciBhbmQgdGhlIGNs YXNzaWZpZXIgY2FuIG1hcCB0aGUgdHJhZmZpYyB0byBhIHNlcnZpY2UgY2hhaW4NCltERF0gWWVz LCB0aGUgY2xhc3NpZmllciBzaG91bGQga25vdzsgSeKAmW0gbG9va2luZyBmb3IgYSB3YXkgZm9y IHRoZSBjbGFzc2lmaWVyIHRvIGNvbnZleSB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIHNlcnZpY2Ug ZnVuY3Rpb24uDQoNCg0KQXpoYXI+IFRoZSBxdWVzdGlvbiBpcyB3aHkgd291bGQgYW4gU0YgY2Fy ZSBhYm91dCB1cHN0cmVhbSB2cyBkb3duc3RyZWFtIHVubGVzcyB0aGUgU0YgaXMgYWxzbyBkb2lu ZyBhY2NvdW50aW5nIGluIHdoaWNoIGNhc2UgaXQgbWF5IGJlIHBvc3NpYmxlIC0gRXZlbiBpZiB5 b3UgbmVlZCB0byBpZGVudGlmeSB1cHN0cmVhbSB2cyBkb3duc3RyZWFtIHdvdWxkbuKAmXQgdGhl IHN1Yi1pZC9hY2NvdW50aW5nIGlkIGJlIGRpZmZlcmVudCBmb3IgdXBzdHJlYW0gdnMgZG93bnN0 cmVhbSB0cmFmZmljPw0KDQo8c25pcD4NCg0KQXpoYXINCg0K --_000_E8355113905631478EFF04F5AA706E9830F0BA5Ewtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NzI2MTcxMjk7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEwNjA1MjExOTYgLTgzNDIxODAzMCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjU7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjIwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp bi1sZWZ0OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI4LjI1cHQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjE2NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoy MDAuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzYuMjVwdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy Z2luLWxlZnQ6MjcyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMwOC4yNXB0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bemhhciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgYnkg c3ViLWlkL2FjY291bnRpbmctaWQgeW91IGFyZSByZWZlcnJpbmcgdG8gc29tZSBtZXRhZGF0YT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm9uZXRoZWxlc3MsIHRoZSBjaGFyZ2luZyBz Y2hlbWVzIHRoYXQgSeKAmW0gZmFtaWxpYXIgd2l0aCBkaXNjcmltaW5hdGUgdXBsb2FkIGJ5dGVz IGZyb20gZG93bmxvYWQgYnl0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihFLmcu LCBSRkM0MDA2IChhbmQgM0dQUCBHeSksIHdoaWNoIHJlZmVycyB0byBDQy1JbnB1dC1PY3RldHMg YW5kIENDLU91dHB1dC1PY3RldHMgZm9yIHVwL2Rvd24gdHJhZmZpYzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDAw NiNzZWN0aW9uLTguMjQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MDA2I3NlY3Rp b24tOC4yNDwvYT4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvIHRoaW5rIGFib3V0IGEgZmlyZXdhbGwsIHdoaWNo IG5lZWRzIHRvIGtub3cgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBpbi1ib3VuZCBTWU4gYW5k IG91dC1ib3VuZCBTWU4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjI1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFzc3VyZSB5b3UgZGlyZWN0aW9uIGlzIGltcG9ydGFu dCwgYW5kIHdpbGwgYmUgYWNjb21wbGlzaGVkIHNvbWVob3cuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMjVwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHNlZW1zIHRvIG1lIHRoYXQg YSBiaXQgaW4gbWV0YWRhdGEgbWlnaHQgYmUgYSBnb29kIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjI1cHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 Mi4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LURhdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEF6aGFyIFNheWVlZCBbbWFpbHRv OmFzYXllZWRAcmVkaGF0LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmls IDA2LCAyMDE2IDE6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgRG9sc29uPGJyPg0KPGI+Q2M6 PC9iPiBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZmNdIEEgcmVxdWVz dCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklubGluZSBwbGVhc2U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoeSB3b3VsZCB5b3UgbmVlZCBh IGJpdCB0byBkaXN0aW5ndWlzaCB0aGUgdXBzdHJlYW0gYW5kIGRvd25zdHJlYW0gdHJhZmZpYyAt IHRoZSB0cmFmZmljIHN0cmVhbSBjYW4gYmUgZGV0ZXJtaW5lZCBmcm9tIFNBL0RBIHBhaXIgYXQg dGhlIGNsYXNzaWZpZXIgYW5kIHRoZSBjbGFzc2lmaWVyIGNhbg0KIG1hcCB0aGUgdHJhZmZpYyB0 byBhIHNlcnZpY2UgY2hhaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+W0REXSBZZXMsIHRoZSBjbGFzc2lmaWVyIHNob3VsZCBrbm93OyBJ4oCZbSBsb29raW5n IGZvciBhIHdheSBmb3IgdGhlIGNsYXNzaWZpZXIgdG8gY29udmV5IHRoZSBpbmZvcm1hdGlvbiB0 byB0aGUgc2VydmljZSBmdW5jdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF6aGFyJmd0OyBUaGUgcXVl c3Rpb24gaXMgd2h5IHdvdWxkIGFuIFNGIGNhcmUgYWJvdXQgdXBzdHJlYW0gdnMgZG93bnN0cmVh bSB1bmxlc3MgdGhlIFNGIGlzIGFsc28gZG9pbmcgYWNjb3VudGluZyBpbiB3aGljaCBjYXNlIGl0 IG1heSBiZSBwb3NzaWJsZSAtIEV2ZW4gaWYgeW91IG5lZWQgdG8gaWRlbnRpZnkgdXBzdHJlYW0g dnMgZG93bnN0cmVhbSB3b3VsZG7igJl0IHRoZSBzdWItaWQvYWNjb3VudGluZyBpZCBiZQ0KIGRp ZmZlcmVudCBmb3IgdXBzdHJlYW0gdnMgZG93bnN0cmVhbSB0cmFmZmljPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkF6aGFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_E8355113905631478EFF04F5AA706E9830F0BA5Ewtlexchp2sandvi_-- From nobody Wed Apr 6 10:54: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 483F112D608 for ; Wed, 6 Apr 2016 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 q1stAFYADCsv for ; Wed, 6 Apr 2016 10:54:53 -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 8DEBA12D0E1 for ; Wed, 6 Apr 2016 10:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6161; q=dns/txt; s=iport; t=1459965293; x=1461174893; h=from:to:subject:date:message-id:mime-version; bh=t/jd9hSATF06uslCA98MrGp/kKY1U5zVBIGgfUNOX/Y=; b=a8Bd6eUfguibFYhq4IVia4vdwxDXDWAQd9L6NgZHoVjSljECHoYAz3EW vNwPU54p5YxdS2egjvObc+eVUyk4FUTrZdFx6G/DvZlBuAo5xfgMsrdx5 cdp6S5LITqGA8gteOGazJ0mbsDV1iPT15WBqAzNryJ/hkCCFqSM0jG4PE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgAhTAVX/4wNJK1cgmtMU30GukYBD?= =?us-ascii?q?YFzgl2DMIFPOBQBAQEBAQEBZSeEQQECBC1eAQgOAwMBAig5FAkKBAESiCfBIQE?= =?us-ascii?q?BAQEBBQEBAQEBG4YhhEuEX4U2BY4FiXwBjgqPDo8gAR4BAUKDZ2yHdX4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,447,1454976000"; d="scan'208,217"; a="90748611" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 17:54:52 +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 u36HsqVZ013145 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 17:54:52 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 12:54:51 -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.1104.009; Wed, 6 Apr 2016 12:54:51 -0500 From: "Jim Guichard (jguichar)" To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AQHRkC1rTdVZJQBlYEu6cpTINhuWWQ== Date: Wed, 6 Apr 2016 17:54:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D32AC5804ACC8jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 17:54:55 -0000 --_000_D32AC5804ACC8jguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, I guess my initial questions would be how do SF's achieve this today and wh= y does NSH make that any different (except for the offset to the original p= ayload in the packet changes) ? Jim From: sfc > on behalf of = Dave Dolson > Date: Wednesday, April 6, 2016 at 10:13 AM To: "sfc@ietf.org" > Subject: [sfc] A request for Metadata allocation schemes To those authors of metadata allocations, I have a request. I believe many types of service functions are going to want to distinguish = up-link traffic from down-link traffic. E.g., a security device treats in-bound to the protected device differently= from out-bound. E.g., an accounting system needs to know whether to charge the source or de= stination node. So my request is to allocate a bit for up-link/down-link discrimination. I think the alternative is to configure each SF about each path whether it = is up or down, or to use something like an even/odd path ID scheme. Does anyone else see this as useful? I believe all of the allocation drafts have reserved bits. David Dolson Senior Software Architect Sandvine --_000_D32AC5804ACC8jguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6DFCC314A7D37249AB7F4BDCF38134B7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Dave,

I guess my initial questions would be how do SF’s achieve this t= oday and why does NSH make that any different (except for the offset to the= original payload in the packet changes) ?

Jim

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson &l= t;ddolson@sandvine.com>
Date: Wednesday, April 6, 2016 at 1= 0:13 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] A request for Metada= ta allocation schemes

To those authors of metadata allocations, I have a r= equest.

I believe many types of service functions are going = to want to distinguish up-link traffic from down-link traffic.

E.g., a security device treats in-bound to the prote= cted device differently from out-bound.

E.g., an accounting system needs to know whether to = charge the source or destination node.

 

So my request is to allocate a bit for up-link/down-= link discrimination.

I think the alternative is to configure each SF abou= t each path whether it is up or down, or to use something like an even/odd = path ID scheme.

 

Does anyone else see this as useful?

 

I believe all of the allocation drafts have reserved= bits.

 

 

David Dolson

Senior Software Architect

Sandvine

 

 --_000_D32AC5804ACC8jguicharciscocom_-- From nobody Wed Apr 6 11:01:29 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 5B74412D6BC for ; Wed, 6 Apr 2016 11:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 9ZZNtdNmRMVG for ; Wed, 6 Apr 2016 11:01:24 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 056B612D6F1 for ; Wed, 6 Apr 2016 11:01:24 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 6 Apr 2016 14:01:23 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Wed, 6 Apr 2016 14:01:23 -0400 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AQHRkC1rnpioWvGORw+Jt9cutzS71599O1hA Date: Wed, 6 Apr 2016 18:01:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.162.97] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F0BC2Fwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A request for Metadata allocation schemes 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, 06 Apr 2016 18:01:26 -0000 --_000_E8355113905631478EFF04F5AA706E9830F0BC2Fwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm familiar with methods: - Service function has two physical interfaces, each with an "up" = or "down" role; - A bit in the path identifier indicates direction From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, April 06, 2016 2:55 PM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] A request for Metadata allocation schemes Hi Dave, I guess my initial questions would be how do SF's achieve this today and wh= y does NSH make that any different (except for the offset to the original p= ayload in the packet changes) ? Jim From: sfc > on behalf of = Dave Dolson > Date: Wednesday, April 6, 2016 at 10:13 AM To: "sfc@ietf.org" > Subject: [sfc] A request for Metadata allocation schemes To those authors of metadata allocations, I have a request. I believe many types of service functions are going to want to distinguish = up-link traffic from down-link traffic. E.g., a security device treats in-bound to the protected device differently= from out-bound. E.g., an accounting system needs to know whether to charge the source or de= stination node. So my request is to allocate a bit for up-link/down-link discrimination. I think the alternative is to configure each SF about each path whether it = is up or down, or to use something like an even/odd path ID scheme. Does anyone else see this as useful? I believe all of the allocation drafts have reserved bits. David Dolson Senior Software Architect Sandvine --_000_E8355113905631478EFF04F5AA706E9830F0BC2Fwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m familiar wit= h methods:

-&nb= sp;         Service functi= on has two physical interfaces, each with an “up” or “dow= n” role;

-&nb= sp;         A bit in the p= ath identifier indicates direction

 

 

 

From: Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, April 06, 2016 2:55 PM
To: Dave Dolson; sfc@ietf.org
Subject: Re: [sfc] A request for Metadata allocation schemes

 

Hi Dave= ,

&n= bsp;

I guess= my initial questions would be how do SF’s achieve this today and why= does NSH make that any different (except for the offset to the original pa= yload in the packet changes) ?

&n= bsp;

Jim

&n= bsp;

From: sfc <sfc= -bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Wednesday, April 6, 2016 at 10:13 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] A request for Metadata allocation schemes<= /span>

&n= bsp;

To those authors of meta= data allocations, I have a request.

I believe many types of = service functions are going to want to distinguish up-link traffic from dow= n-link traffic.

E.g., a security device = treats in-bound to the protected device differently from out-bound.

E.g., an accounting syst= em needs to know whether to charge the source or destination node.

 =

So my request is to allo= cate a bit for up-link/down-link discrimination.

I think the alternative = is to configure each SF about each path whether it is up or down, or to use= something like an even/odd path ID scheme.

 =

Does anyone else see thi= s as useful?

 =

I believe all of the all= ocation drafts have reserved bits.

 =

 =

David Dolson<= /span>

Senior Software Architec= t

Sandvine

 =

--_000_E8355113905631478EFF04F5AA706E9830F0BC2Fwtlexchp2sandvi_-- From nobody Wed Apr 6 11:49:26 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 962E412D0C6 for ; Wed, 6 Apr 2016 11:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 aANP-pKqw_eO for ; Wed, 6 Apr 2016 11:49:22 -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 F219D12D13D for ; Wed, 6 Apr 2016 11:49:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLR05654; Wed, 06 Apr 2016 18:49:09 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 19:49:08 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 11:48:55 -0700 From: Lucy yong To: "sfc@ietf.org" Thread-Topic: comments to NSH draft Thread-Index: AdGQNOwEDGPh+h+ERsq4ibKx/si6JA== Date: Wed, 6 Apr 2016 18:48:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5727259F@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.145] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D5727259Fdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57055A26.0020, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b2538258c919575ebe6337d38800c2e6 Archived-At: Subject: [sfc] comments to NSH 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, 06 Apr 2016 18:49:25 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D5727259Fdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * NSH draft defines NSH Proxy that is used by an NSH-unaware SF. RF= C7665 already defined and specified SFC Proxy (4.6). NSH draft should use S= FC proxy term to describe it and cites the RFC. * For NSH encapsulation example, UDP+GRE+NSH is better example than= GRE+NSH. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D5727259Fdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

·         NSH draft defines NSH Proxy that is used by = an NSH-unaware SF. RFC7665 already defined and specified SFC Proxy (4.6). N= SH draft should use SFC proxy term to describe it  and cites the RFC.

·         For NSH encapsulation example, UDP+GRE&#= 43;NSH is better example than GRE+NSH.  

 

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D5727259Fdfweml501mbb_-- From nobody Thu Apr 7 08:33:26 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 B337212D1EB for ; Thu, 7 Apr 2016 08:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.03 X-Spam-Level: X-Spam-Status: No, score=-7.03 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 B38YdldRxEYS for ; Thu, 7 Apr 2016 08:33:24 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0890A12D504 for ; Thu, 7 Apr 2016 08:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1460042845; x=1491578845; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Z/qt5E5RMky66S26N6TAHh2Zo2u1kBkamxU/lKggaI0=; b=k/GOC3wyri8OUsQDPXi7bume0Ei4thtUQTgeeK0YFigXV5gD/O+A1spr lKc5sBlMXsUmnOcj22Vu5K5tT3tp+5TdXczvtJ4Es+1pCs+b/Y/c15BIX TerYSfGODLzuUzypwEiBpul8MgqiehxOMSPGrV1gxLhriw7f/8f1utbT3 Y=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="211784068" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 07 Apr 2016 15:27:25 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 7 Apr 2016 08:27:24 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1156.000; Thu, 7 Apr 2016 08:27:24 -0700 From: Sumandra Majee To: Dave Dolson , "sfc@ietf.org" Thread-Topic: A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wA06k3B Date: Thu, 7 Apr 2016 15:27:23 +0000 Message-ID: <1460042865963.25707@F5.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_146004286596325707F5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A request for Metadata allocation schemes 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, 07 Apr 2016 15:33:25 -0000 --_000_146004286596325707F5com_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ?Dave, The use case you have defined is supported by most devices by binding polic= ies explicitly on, a) interface or equivalent b) flow direction. Most flow aware devices has to detect to and from cor= rectly to do lot of thngs correctly. So the question is what do we get by adding this bit? I am opposed to the t= erm UP and DOWN (from show point of view?), rather forward and reverse (eve= n that is confusing). Sumandra ________________________________ From: sfc on behalf of Dave Dolson Sent: Wednesday, April 6, 2016 7:13 AM To: sfc@ietf.org Subject: [sfc] A request for Metadata allocation schemes To those authors of metadata allocations, I have a request. I believe many types of service functions are going to want to distinguish = up-link traffic from down-link traffic. E.g., a security device treats in-bound to the protected device differently= from out-bound. E.g., an accounting system needs to know whether to charge the source or de= stination node. So my request is to allocate a bit for up-link/down-link discrimination. I think the alternative is to configure each SF about each path whether it = is up or down, or to use something like an even/odd path ID scheme. Does anyone else see this as useful? I believe all of the allocation drafts have reserved bits. David Dolson Senior Software Architect Sandvine --_000_146004286596325707F5com_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As for the first nibble issue, will it violate the layering principle of= network protocol stacks if the first nibble of any new encapsulation heade= r (which could be an MPLS payload) is used as the "MPLS payload t= ype" field? wouldn't it  be more reasonable and sustainable to fix the problem (i.e., the lack of a protocol= field in the MPLS header) by the MPLS header itself?

 

By the way, since it's claimed that the NSH is transport-independant, it= means the NSH should be able to be transported over MPLS. However, it seem= s that the first nibble issue has not be considered in the current NSH= draft. As a result, when encapsulating NSH over MPLS, the NSH may be mis-interpreted as IP header.

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8=CB: BIER [bier-bounces@iet= f.org] =B4=FA=B1=ED Tony Przygienda [tonysietf@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA4=D4=C25=C8=D5 22:36
=CA=D5=BC=FE=C8=CB: bier@ietf.org
=D6=F7=CC=E2: [Bier] comments on draft-wang-bier-ethernet-01

after reading 

a) first nibble: refer to MPLS encaps as "the same value" to= keep in sync 
b) refer to all other possible fields to MPLS encaps to keep in sync w= hen describing instead of repeating 
c) you need to describe which kind of ether MACs are allowed, especial= ly on broadcast media, i.e. is it always p2p or can you take advantage of t= he broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don't = invent a new one 
e) who will obtain a new ether type from IEEE? As far I understand, no= t a trivial process albeit we have several liaisons with IEEE 

--
We=A1= =AFve heard that a million monkeys at a million keyboards could produce the= complete works of Shakespeare; now, thanks to the Internet, we know that i= s not true.
= =A1=AARobert Wilensky
--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871CNKGEML515MBXchi_-- From nobody Thu Apr 7 19:12:06 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 6619312D1E0 for ; Thu, 7 Apr 2016 19:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-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 hQPqTyuOofxP for ; Thu, 7 Apr 2016 19:12:02 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3929412D1DA for ; Thu, 7 Apr 2016 19:12:02 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 22:12:00 -0400 From: Dave Dolson To: Sumandra Majee , "sfc@ietf.org" Thread-Topic: A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wA06k3BABaJqpA= Date: Fri, 8 Apr 2016 02:11:59 +0000 Message-ID: References: <1460042865963.25707@F5.com> In-Reply-To: <1460042865963.25707@F5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [190.111.246.156] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F11EA7wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A request for Metadata allocation schemes 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, 08 Apr 2016 02:12:04 -0000 --_000_E8355113905631478EFF04F5AA706E9830F11EA7wtlexchp2sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VtYW5kcmEgKGFuZCBvdGhlcnMgd2hvIGhhdmUgcXVlc3Rpb25lZCB0aGlzKSwNCldoYXQgZG8g eW91IG1lYW4gYnkgZGV0ZWN0aW5nIGRpcmVjdGlvbiBmcm9tIHRoZSBlbmNhcHN1bGF0ZWQgcGFj a2V0Pw0KSeKAmW0gaGF2aW5nIHRyb3VibGUgdW5kZXJzdGFuZGluZyBob3cgb25lIGNvdWxkIHRl bGwgZnJvbSBhbiBhcmJpdHJhcnkgSVAgcGFja2V0IHdoaWNoIGRpcmVjdGlvbiBpdCBpcyBnb2lu Zy4NCihVbmxlc3Mga25vd2luZyB0aGUgSVAgYWRkcmVzcyBhbGxvY2F0aW9uIHNjaGVtZSBpbiB0 aGUgaW5uZXIgbmV0d29ya+KApj8gIFRoYXQgd291bGQgYmUgYXJkdW91cy4pDQoNCkFuZCBwb3Nz aWJseSBpbi1ib3VuZCwgb3V0LWJvdW5kIGFyZSBiZXR0ZXIgbmFtZXM/DQpJIGRvbuKAmXQgbGlr ZSBmb3J3YXJkL3JldmVyc2UgYmVjYXVzZSBJIGNhbuKAmXQgZ3Vlc3Mgd2hpY2ggaXMgd2hpY2gu DQoNCi1EYXZlDQoNCkZyb206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21d DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgMTI6MjcgUE0NClRvOiBEYXZlIERvbHNv bjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxv Y2F0aW9uIHNjaGVtZXMNCg0KDQrigItEYXZlLA0KDQoNCg0KVGhlIHVzZSBjYXNlIHlvdSBoYXZl IGRlZmluZWQgaXMgc3VwcG9ydGVkIGJ5IG1vc3QgZGV2aWNlcyBieSBiaW5kaW5nIHBvbGljaWVz IGV4cGxpY2l0bHkgb24sDQoNCiAgIGEpIGludGVyZmFjZSBvciBlcXVpdmFsZW50DQoNCiAgIGIp IGZsb3cgZGlyZWN0aW9uLiBNb3N0IGZsb3cgYXdhcmUgZGV2aWNlcyBoYXMgdG8gZGV0ZWN0IHRv IGFuZCBmcm9tIGNvcnJlY3RseSB0byBkbyBsb3Qgb2YgdGhuZ3MgY29ycmVjdGx5Lg0KDQoNCg0K U28gdGhlIHF1ZXN0aW9uIGlzIHdoYXQgZG8gd2UgZ2V0IGJ5IGFkZGluZyB0aGlzIGJpdD8gSSBh bSBvcHBvc2VkIHRvIHRoZSB0ZXJtIFVQIGFuZCBET1dOIChmcm9tIHNob3cgcG9pbnQgb2Ygdmll dz8pLCByYXRoZXIgZm9yd2FyZCBhbmQgcmV2ZXJzZSAoZXZlbiB0aGF0IGlzIGNvbmZ1c2luZyku DQoNCg0KDQpTdW1hbmRyYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpk ZG9sc29uQHNhbmR2aW5lLmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDYsIDIwMTYgNzox MyBBTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogW3Nm Y10gQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0KVG8gdGhvc2Ug YXV0aG9ycyBvZiBtZXRhZGF0YSBhbGxvY2F0aW9ucywgSSBoYXZlIGEgcmVxdWVzdC4NCkkgYmVs aWV2ZSBtYW55IHR5cGVzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBnb2luZyB0byB3YW50IHRv IGRpc3Rpbmd1aXNoIHVwLWxpbmsgdHJhZmZpYyBmcm9tIGRvd24tbGluayB0cmFmZmljLg0KRS5n LiwgYSBzZWN1cml0eSBkZXZpY2UgdHJlYXRzIGluLWJvdW5kIHRvIHRoZSBwcm90ZWN0ZWQgZGV2 aWNlIGRpZmZlcmVudGx5IGZyb20gb3V0LWJvdW5kLg0KRS5nLiwgYW4gYWNjb3VudGluZyBzeXN0 ZW0gbmVlZHMgdG8ga25vdyB3aGV0aGVyIHRvIGNoYXJnZSB0aGUgc291cmNlIG9yIGRlc3RpbmF0 aW9uIG5vZGUuDQoNClNvIG15IHJlcXVlc3QgaXMgdG8gYWxsb2NhdGUgYSBiaXQgZm9yIHVwLWxp bmsvZG93bi1saW5rIGRpc2NyaW1pbmF0aW9uLg0KSSB0aGluayB0aGUgYWx0ZXJuYXRpdmUgaXMg dG8gY29uZmlndXJlIGVhY2ggU0YgYWJvdXQgZWFjaCBwYXRoIHdoZXRoZXIgaXQgaXMgdXAgb3Ig ZG93biwgb3IgdG8gdXNlIHNvbWV0aGluZyBsaWtlIGFuIGV2ZW4vb2RkIHBhdGggSUQgc2NoZW1l Lg0KDQpEb2VzIGFueW9uZSBlbHNlIHNlZSB0aGlzIGFzIHVzZWZ1bD8NCg0KSSBiZWxpZXZlIGFs bCBvZiB0aGUgYWxsb2NhdGlvbiBkcmFmdHMgaGF2ZSByZXNlcnZlZCBiaXRzLg0KDQoNCkRhdmlk IERvbHNvbg0KU2VuaW9yIFNvZnR3YXJlIEFyY2hpdGVjdA0KU2FuZHZpbmUNCg0K --_000_E8355113905631478EFF04F5AA706E9830F11EA7wtlexchp2sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5tc29jaHBkZWZhdWx0LCBs aS5tc29jaHBkZWZhdWx0LCBkaXYubXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTptc29j aHBkZWZhdWx0Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LmVtYWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTplbWFpbHN0eWxlMTc7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5TdW1hbmRyYSAoYW5kIG90aGVycyB3aG8gaGF2ZSBxdWVzdGlvbmVkIHRoaXMpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5XaGF0IGRvIHlvdSBtZWFuIGJ5IGRldGVjdGluZyBkaXJlY3Rpb24gZnJv bSB0aGUgZW5jYXBzdWxhdGVkIHBhY2tldD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SeKAmW0gaGF2aW5nIHRy b3VibGUgdW5kZXJzdGFuZGluZyBob3cgb25lIGNvdWxkIHRlbGwgZnJvbSBhbiBhcmJpdHJhcnkg SVAgcGFja2V0IHdoaWNoIGRpcmVjdGlvbiBpdCBpcyBnb2luZy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+KFVu bGVzcyBrbm93aW5nIHRoZSBJUCBhZGRyZXNzIGFsbG9jYXRpb24gc2NoZW1lIGluIHRoZSBpbm5l ciBuZXR3b3Jr4oCmPyZuYnNwOyBUaGF0IHdvdWxkIGJlIGFyZHVvdXMuKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW5kIHBvc3NpYmx5IGluLWJvdW5kLCBvdXQtYm91bmQg YXJlIGJldHRlciBuYW1lcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBkb27igJl0IGxpa2UgZm9yd2FyZC9y ZXZlcnNlIGJlY2F1c2UgSSBjYW7igJl0IGd1ZXNzIHdoaWNoIGlzIHdoaWNoLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LURhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdW1hbmRyYSBNYWplZSBbbWFp bHRvOlMuTWFqZWVARjUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAw NywgMjAxNiAxMjoyNyBQTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb247IHNmY0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0 aW9uIHNjaGVtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj7igItEYXZlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlRoZSB1c2UgY2FzZSB5b3UgaGF2ZSBkZWZpbmVkIGlzIHN1cHBvcnRlZCBieSBt b3N0IGRldmljZXMgYnkgYmluZGluZyBwb2xpY2llcyBleHBsaWNpdGx5IG9uLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDthKSBp bnRlcmZhY2Ugb3IgZXF1aXZhbGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDtiKSBmbG93IGRpcmVjdGlvbi4gTW9zdCBmbG93 IGF3YXJlIGRldmljZXMgaGFzIHRvIGRldGVjdCB0byBhbmQgZnJvbSBjb3JyZWN0bHkgdG8gZG8g bG90IG9mIHRobmdzIGNvcnJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5TbyB0aGUgcXVlc3Rpb24gaXMgd2hhdCBkbyB3ZSBnZXQgYnkgYWRk aW5nIHRoaXMgYml0PyBJIGFtIG9wcG9zZWQgdG8gdGhlIHRlcm0gVVAgYW5kIERPV04gKGZyb20g c2hvdyBwb2ludCBvZiB2aWV3PyksIHJhdGhlciBmb3J3YXJkIGFuZCByZXZlcnNlIChldmVuIHRo YXQgaXMgY29uZnVzaW5nKS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+U3VtYW5kcmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiMyMTIxMjEiPg0KPGhy IHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRp diBpZD0iZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiBzZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNvbkBzYW5kdmluZS5jb208L2E+Jmd0 Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDYsIDIwMTYgNzoxMyBBTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2ZjXSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9j YXRpb24gc2NoZW1lczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjoj MjEyMTIxIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojMjEyMTIxIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+VG8gdGhvc2UgYXV0 aG9ycyBvZiBtZXRhZGF0YSBhbGxvY2F0aW9ucywgSSBoYXZlIGEgcmVxdWVzdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIx MjEyMSI+SSBiZWxpZXZlIG1hbnkgdHlwZXMgb2Ygc2VydmljZSBmdW5jdGlvbnMgYXJlIGdvaW5n IHRvIHdhbnQgdG8gZGlzdGluZ3Vpc2ggdXAtbGluayB0cmFmZmljIGZyb20gZG93bi1saW5rIHRy YWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMyMTIxMjEiPkUuZy4sIGEgc2VjdXJpdHkgZGV2aWNlIHRyZWF0cyBpbi1i b3VuZCB0byB0aGUgcHJvdGVjdGVkIGRldmljZSBkaWZmZXJlbnRseSBmcm9tIG91dC1ib3VuZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzIxMjEyMSI+RS5nLiwgYW4gYWNjb3VudGluZyBzeXN0ZW0gbmVlZHMgdG8ga25vdyB3 aGV0aGVyIHRvIGNoYXJnZSB0aGUgc291cmNlIG9yIGRlc3RpbmF0aW9uIG5vZGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMy MTIxMjEiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5TbyBteSByZXF1ZXN0IGlzIHRvIGFsbG9jYXRl IGEgYml0IGZvciB1cC1saW5rL2Rvd24tbGluayBkaXNjcmltaW5hdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+SSB0aGluayB0aGUgYWx0ZXJuYXRpdmUgaXMgdG8gY29uZmlndXJlIGVhY2ggU0YgYWJvdXQg ZWFjaCBwYXRoIHdoZXRoZXIgaXQgaXMgdXAgb3IgZG93biwgb3IgdG8gdXNlIHNvbWV0aGluZyBs aWtlIGFuIGV2ZW4vb2RkIHBhdGggSUQgc2NoZW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzIxMjEyMSI+RG9lcyBhbnlvbmUgZWxzZSBzZWUgdGhpcyBhcyB1c2VmdWw/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMy MTIxMjEiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5JIGJlbGlldmUgYWxsIG9mIHRoZSBhbGxvY2F0 aW9uIGRyYWZ0cyBoYXZlIHJlc2VydmVkIGJpdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMjEyMTIxIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+RGF2aWQgRG9sc29uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIx MjEiPlNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+U2FuZHZpbmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzIxMjEyMSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E8355113905631478EFF04F5AA706E9830F11EA7wtlexchp2sandvi_-- From nobody Thu Apr 7 21:52:29 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 26BB012D1E0 for ; Thu, 7 Apr 2016 21:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.03 X-Spam-Level: X-Spam-Status: No, score=-7.03 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 0PxYmkeBgg8x for ; Thu, 7 Apr 2016 21:52:25 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B5112D124 for ; Thu, 7 Apr 2016 21:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1460091146; x=1491627146; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yyVEEZi4tv1H53MtewarpTNrS0u0zPZHeRGqj27g3O8=; b=oMV3JUlHebTZ2m7NbDR4nmV9hs9LHAMoUmTLqh8y260WDyOFgY61FEMV uOaWWxH+ED31M3/KV3nm406ySFuVJTE/3gIx6ohNUmxt68KjEtenU4hOl i+SFSd5KE9O90IHZQTeoKZAQ1HY1c2cUsG2krTOysQqFkDcDp5LwV34FM Q=; X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="212699469" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 08 Apr 2016 04:51:45 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 7 Apr 2016 21:51:43 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1156.000; Thu, 7 Apr 2016 21:51:43 -0700 From: Sumandra Majee To: Dave Dolson , "sfc@ietf.org" Thread-Topic: A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wA06k3BABaJqpAABVdClw== Date: Fri, 8 Apr 2016 04:51:42 +0000 Message-ID: <1460091126273.230@F5.com> References: <1460042865963.25707@F5.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_1460091126273230F5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A request for Metadata allocation schemes 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, 08 Apr 2016 04:52:28 -0000 --_000_1460091126273230F5com_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ?I think the part of the problem lies in the definition of UP and DOWN. So = lets take some use cases. a) In case of service provider many functions sits at the border between ne= twork/internet and subscriber/user. Typically the two sides of the border = is defined by way of configuration, this interface/tunnel point to subscrib= er side and that points to the internet. Anything ingress on subscriber sid= e is FROM subscriber and vice versa. The UP or DOWN is not so useful. b) Consider a typical client server. Assuming you mean UP: client ->server= /final destination and DOWN the other way. A flow aware service would have = state SIP->DIP as UP and DIP->SIP as DOWN. Others like router etc. may not = care at all and that is fine. In case of security device the inbound and outbound (or zones) are defined = by configuration that is local to that entity. So having a classifier say I= N or OUT would be wrong in that case. Sumandra ________________________________ From: Dave Dolson Sent: Thursday, April 7, 2016 7:11 PM To: Sumandra Majee; sfc@ietf.org Subject: RE: A request for Metadata allocation schemes Sumandra (and others who have questioned this), What do you mean by detecting direction from the encapsulated packet? I'm having trouble understanding how one could tell from an arbitrary IP pa= cket which direction it is going. (Unless knowing the IP address allocation scheme in the inner network...? = That would be arduous.) And possibly in-bound, out-bound are better names? I don't like forward/reverse because I can't guess which is which. -Dave From: Sumandra Majee [mailto:S.Majee@F5.com] Sent: Thursday, April 07, 2016 12:27 PM To: Dave Dolson; sfc@ietf.org Subject: Re: A request for Metadata allocation schemes ?Dave, The use case you have defined is supported by most devices by binding polic= ies explicitly on, a) interface or equivalent b) flow direction. Most flow aware devices has to detect to and from cor= rectly to do lot of thngs correctly. So the question is what do we get by adding this bit? I am opposed to the t= erm UP and DOWN (from show point of view?), rather forward and reverse (eve= n that is confusing). Sumandra ________________________________ From: sfc > on behalf of = Dave Dolson > Sent: Wednesday, April 6, 2016 7:13 AM To: sfc@ietf.org Subject: [sfc] A request for Metadata allocation schemes To those authors of metadata allocations, I have a request. I believe many types of service functions are going to want to distinguish = up-link traffic from down-link traffic. E.g., a security device treats in-bound to the protected device differently= from out-bound. E.g., an accounting system needs to know whether to charge the source or de= stination node. So my request is to allocate a bit for up-link/down-link discrimination. I think the alternative is to configure each SF about each path whether it = is up or down, or to use something like an even/odd path ID scheme. Does anyone else see this as useful? I believe all of the allocation drafts have reserved bits. David Dolson Senior Software Architect Sandvine --_000_1460091126273230F5com_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Regarding the TLV Class of variable-length metadata,= https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1

It is common for such fields to reserve ranges, allo= wing for future growth into unanticipated uses.

 

E.g., off the top of my head,

classes 0 to 0x1ff --> types allocated by IETF

classes 0x200 to 0x7fff --> allocated by IANA

Classes 0x8000 to 0xbfff --> reserved, do not use=

classes 0xc000 to 0xefff --> locally administered=

classes 0xf000 to 0xffff --> experimental

 

Or similar? I’m not sure what the best practic= e for this is.

 

Generally, I’d want to try something experimen= tally before requesting IANA allocation for it (experimental),

or maybe types are too specific to warrant IANA allo= cation (locally administered).

 

Can something like this be added to draft-ietf-sfc-n= sh ?

 

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830F20CDAwtlexchp2sandvi_-- From nobody Thu Apr 14 08:30:12 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 7DB7D12E102 for ; Thu, 14 Apr 2016 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CXCCu0v4QLxp for ; Thu, 14 Apr 2016 08:30:08 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D5912DBF1 for ; Thu, 14 Apr 2016 08:30:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 110FC461876; Thu, 14 Apr 2016 08:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460647808; bh=gu2Jje4gn5/x4TPkpTdfidSmxOn8To0Oc04EZvuV9QM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VIUVdT4JD0iRPmkel178DaUX9JIXo6voQoN9DKTUI7D/lI4bxnc22hKKWAGNQv7HZ +OQDl/tUn2CPrcmyUF++xH3QaNnQJn8E8ra5M4z5X0+grTFF0W5/7Yi4DhePfPi8R6 zI1zztIPBRZriMKGlz3wZaGiHVZVZv9UFc5U7lf8= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 90B81461870; Thu, 14 Apr 2016 08:30:07 -0700 (PDT) To: Dave Dolson , "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <570FB777.4020202@joelhalpern.com> Date: Thu, 14 Apr 2016 11:29:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 14 Apr 2016 15:30:10 -0000 That seems sensible. (I am not sure why we need such a large range of classes, but I suspect I am missing something there.) Yours, Joel On 4/14/16 11:24 AM, Dave Dolson wrote: > Regarding the TLV Class of variable-length metadata, > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1 > > It is common for such fields to reserve ranges, allowing for future > growth into unanticipated uses. > > E.g., off the top of my head, > > classes 0 to 0x1ff --> types allocated by IETF > > classes 0x200 to 0x7fff --> allocated by IANA > > Classes 0x8000 to 0xbfff --> reserved, do not use > > classes 0xc000 to 0xefff --> locally administered > > classes 0xf000 to 0xffff --> experimental > > Or similar? I’m not sure what the best practice for this is. > > Generally, I’d want to try something experimentally before requesting > IANA allocation for it (experimental), > > or maybe types are too specific to warrant IANA allocation (locally > administered). > > Can something like this be added to draft-ietf-sfc-nsh ? > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Apr 14 08:32: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 6FCF812E660 for ; Thu, 14 Apr 2016 08:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 fU_CaXQg4H26 for ; Thu, 14 Apr 2016 08:32:49 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id DDDE512E65B for ; Thu, 14 Apr 2016 08:32:48 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 14 Apr 2016 11:32:48 -0400 From: Dave Dolson To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AdGWYcf4eX5Az/rjTQOEcq50WzDr6QAIkBaAAAhSecA= Date: Thu, 14 Apr 2016 15:32:48 +0000 Message-ID: References: <570FB777.4020202@joelhalpern.com> In-Reply-To: <570FB777.4020202@joelhalpern.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] TLV class of variable-length metadata should have a restricted range 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, 14 Apr 2016 15:32:51 -0000 I was just brainstorming some classes. I expect more experienced contributo= rs can make arguments to whittle it down. -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, April 14, 2016 11:30 AM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] TLV class of variable-length metadata should have a rest= ricted range That seems sensible. (I am not sure why we need such a large range of=20 classes, but I suspect I am missing something there.) Yours, Joel On 4/14/16 11:24 AM, Dave Dolson wrote: > Regarding the TLV Class of variable-length metadata, > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1 > > It is common for such fields to reserve ranges, allowing for future > growth into unanticipated uses. > > E.g., off the top of my head, > > classes 0 to 0x1ff --> types allocated by IETF > > classes 0x200 to 0x7fff --> allocated by IANA > > Classes 0x8000 to 0xbfff --> reserved, do not use > > classes 0xc000 to 0xefff --> locally administered > > classes 0xf000 to 0xffff --> experimental > > Or similar? I'm not sure what the best practice for this is. > > Generally, I'd want to try something experimentally before requesting > IANA allocation for it (experimental), > > or maybe types are too specific to warrant IANA allocation (locally > administered). > > Can something like this be added to draft-ietf-sfc-nsh ? > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Apr 14 10:03: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 9275612DB67 for ; Thu, 14 Apr 2016 10:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 v8bS5qjvJ1g2 for ; Thu, 14 Apr 2016 10:03:40 -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 E870B12D96F for ; Thu, 14 Apr 2016 10:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1460653419; x=1461863019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vrPoOc0l6Vf2FdkOqYFfS+Aec7lEQNJ1hHdVwKeRFM4=; b=USU5q4Pxe2sOfbnQPfnHbll2q9lRzI4e1KiX6qiH88Me52RReXVjtSa8 U5Uc1foIgmZSQrcMGgkE1YetZDOgLYyGAG6+hPTJpxLnklFTp72BqB10a XiFiH3wDrKOsEjLnP6EAo8QlFzVEiDsAZiLIEBwXaTcahBOciy2u20UXp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgDYzA9X/5NdJa1egziBUAa6KQENg?= =?us-ascii?q?XGGDgKBPDgUAQEBAQEBAWUnhEEBAQEDAR0dPwUHBAIBCA4DBAEBAR4JBzIUCQg?= =?us-ascii?q?CBA4FiCEIwmwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdYJWhD2DLYIrAQSHc?= =?us-ascii?q?IcUiQcBjgyBZ4ROiFuGIYkHAR4BAUKDZ2yISH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="260687867" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 17:03:39 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3EH3dx8008225 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 17:03:39 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 12:03:38 -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.1104.009; Thu, 14 Apr 2016 12:03:38 -0500 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfXi0m0zbDrFUiQMfrqrpCL9J+HIR6AgAADWICAAFnogIAAy/MAgAGYJgCAADqXAA== Date: Thu, 14 Apr 2016 17:03:38 +0000 Message-ID: <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com> References: <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@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.131.118.100] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "uri.elzur@intel.com" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 14 Apr 2016 17:03:41 -0000 Hi Dave, Sorry, I was traveling yesterday. In principal I don't have any issues wit= h the text since it doesn't impose requirements but rather clarifies a poss= ible behavior. I do wonder about how common this will be: a control of sorts is needed for= semantic meaning -- in type 1 or type 2 cases. Paul > On Apr 14, 2016, at 9:33 AM, Dave Dolson wrote: >=20 > Paul and Uri, can you please comment as to whether you agree or disagree = with this wording? >=20 > I feel that it allows the actual content to be opaque while giving guidan= ce for > service functions that create or replay packets in the chain. >=20 > From my point of view, this is how such devices will work anyhow. >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Wednesday, April 13, 2016 9:13 AM > To: Paul Quinn (paulq); Ron Parker > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Paul, > Are you unhappy with the metadata constraints I suggested below? > Perhaps qualified by "In the absence of out-of-band configuration..." ? >=20 > I believe that the schemes proposed in these drafts satisfy the constrain= ts: > - draft-sfc-nsh-dc-allocation-4,=20 > - draft-napper-sfc-nsh-broadband-allocation-00=20 >=20 > (I thought there were more allocation schemes, but I guess they expired.) >=20 > I'll update it here: >=20 > In the absence of out-of-band configuration to indicate otherwise, > metadata used in NSH headers must meet the condition that > a transport-layer-stateful Service Function can save away > metadata values that it has witnessed. An injected packet can > therefore be assigned a clone of metadata taken from an earlier > packet going in the same direction. For example, a Service Function > can send a TCP packet using metadata cloned from another TCP packet > of the same connection and direction. >=20 > Note that the Service Function need not know the meaning of the > metadata; it just needs to know it is safe to clone in this manner. >=20 >=20 > -Dave >=20 >=20 From nobody Thu Apr 14 10:20: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 3F74B12DD5D for ; Thu, 14 Apr 2016 10:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 HCjYCtN_wb-V for ; Thu, 14 Apr 2016 10:20:34 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E50812DD29 for ; Thu, 14 Apr 2016 10:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4897; q=dns/txt; s=iport; t=1460654434; x=1461864034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sbJwnbKNi8PNixI8BUNcmOa2NqicS/WAioOSM1LbxjM=; b=kNCYBNXSzFKE0bI/arrOIkTKYgEAGaB4mo9uZcwPJB7pIVTr6ykBECsp gCGLaxCPEwQ+lQl8yML6MFeAi7OPKUaPG3D62rglzJ+OZPTg71+oSEo1G h3PhUhh7qLGxKFsP9nZCQyakXDKQSxKgeGbJUZMKzVWw4bQS7sbCsEqIV o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgC+0A9X/4QNJK1egziBUAa6KQENg?= =?us-ascii?q?XGGDgKBPTgUAQEBAQEBAWUnhEEBAQEDAR0dMQ4FCwIBCBgeEDIlAgQOBRuIBgj?= =?us-ascii?q?CbAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYF1glaEDi+DLYIrBZMdhG4BjgwKg?= =?us-ascii?q?V2ETohbhiGJBwEeAQFCg2dsiEh+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="260006594" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 17:20:33 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3EHKX4j024041 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 17:20:33 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 12:20:33 -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.1104.009; Thu, 14 Apr 2016 12:20:32 -0500 From: "Paul Quinn (paulq)" To: "Bottorff, Paul" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfXi0m0zbDrFUiQMfrqrpCL9J+I3xSAgAFCswA= Date: Thu, 14 Apr 2016 17:20:32 +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.100] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AA2C6232E3B6F4D9889A2658C3EDCFB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 14 Apr 2016 17:20:36 -0000 Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a num= ber of deficiencies which lead to transport dependencies and to layer viola= tions, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 > 2)there is no resolution to forward/reverse addressing necessary for supp= ort of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. > 3)there is no resolution to encoding hierarchies which are of importance = to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. > 4)the draft needs a transport service interface and a description of the = mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function.= From nobody Thu Apr 14 11:27:54 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 C0EA812DE8F for ; Thu, 14 Apr 2016 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 Oitbc4Jl0u1C for ; Thu, 14 Apr 2016 11:27:50 -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 75FB612DE8B for ; Thu, 14 Apr 2016 11:27:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHL06968; Thu, 14 Apr 2016 18:27:47 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 19:27:46 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.126]) by SJCEML702-CHM.china.huawei.com ([169.254.4.137]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 11:27:42 -0700 From: Henry Fourie To: "Paul Quinn (paulq)" , "Bottorff, Paul" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivgDMsOkopwHd0anrI1vjTQhzZ+JAJuAgAFCswD//5tbsA== Date: Thu, 14 Apr 2016 18:27:40 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559A09559A80@SJCEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.570FE123.0269, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.126, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f00e12aefba01234b913f67e0c7526fe Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 14 Apr 2016 18:27:53 -0000 Paul, Updating SFF forwarding entries on all downstream SFFs can introduce dis= ruption of traffic on the service path. It would help if there is a mechanism where= a=20 chain update to add/remove an SF can be localized to its subtending SFF onl= y. - Louis=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, April 14, 2016 10:21 AM To: Bottorff, Paul Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a num= ber of deficiencies which lead to transport dependencies and to layer viola= tions, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 > 2)there is no resolution to forward/reverse addressing necessary for supp= ort of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. > 3)there is no resolution to encoding hierarchies which are of importance = to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. > 4)the draft needs a transport service interface and a description of the = mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 15 09:42:59 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 CA6AC12DE03 for ; Fri, 15 Apr 2016 09:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 P_AqgpY3osxO for ; Fri, 15 Apr 2016 09:42:53 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBE612DDDB for ; Fri, 15 Apr 2016 09:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1460738573; x=1492274573; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OmTfBIzenWQKwVPClcLv/49/J88s2FymX6UO+4VRn5o=; b=LxbY5F498/0tMPeQoTx3gY7R/iK4RbdRdDMXNV3tb0iqagGEp48cH/Sp NI2WfLD/3d6po48hoCEy2RYjbMPKavYbG7mIpEdPALNR+p2rq5bj3iwr1 COb0UVkVgOuoypfFiQmRSnWVZbR/2BT3HRh8HrR8oCaTwqidVSqjRM3dG M=; X-IronPort-AV: E=Sophos;i="5.24,488,1454976000"; d="scan'208";a="213981343" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 15 Apr 2016 16:42:53 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX08.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 15 Apr 2016 09:42:52 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1156.000; Fri, 15 Apr 2016 09:42:52 -0700 From: Sumandra Majee To: "Bottorff, Paul" , Nilanjan Sarkar Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wA06k3BABaJqpAABVdClwAYRqoAAAgzRgABWIwR5Q== Date: Fri, 15 Apr 2016 16:42:52 +0000 Message-ID: <1460738575691.54747@F5.com> References: <1460042865963.25707@F5.com>, , <1460091126273.230@F5.com> <1D15709113D6B34BAE5E128F392059CA01268568BE@blr-exch-1.sandvine.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] A request for Metadata allocation schemes 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, 15 Apr 2016 16:42:56 -0000 RGF2ZSwgUGF1bCBhbmQgTmlsYW5qYW4sCgpJIGFtIG5vdCBvcHBvc2VkIHRvIGhhdmluZyBhIGRp cmVjdGlvbiBiaXQgaW4gdGhlIG1ldGFkYXRhLCB5ZXMgaXQgbWlnaHQgYmVjb21lIG5lY2Vzc2l0 eSBpbiBjZXJ0YWluIHNpdHVhdGlvbi4gSSBhbSBub3Qgc3VyZSBpZiB3ZSBuZWVkIHRoaXMgc2Vu c2Ugb2YgZGlyZWN0aW9uIGZvciBtYWpvcml0eSBvZiB1c2UgY2FzZXMuCgpJIGFtIGdlbmVyYWxs eSBvcHBvc2VkIHRvIHN0YW5kYXJkaXppbmcgbWV0YWRhdGEgYWxsb2NhdGlvbiB0aGlzIGVhcmx5 LgoKV2hhdCBJIHdvdWxkIHJlYWxseSBsaWtlIHRvIGhhdmUgYSBtZXRhZGF0YSByZWdpc3RyeSBh bmQgYSBzY2hlbWUgZm9yIHRoYXQuICAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpGcm9tOiBCb3R0b3JmZiwgUGF1bCA8cGF1bC5ib3R0b3JmZkBocGUuY29tPgpTZW50 OiBGcmlkYXksIEFwcmlsIDgsIDIwMTYgNjoxMCBBTQpUbzogTmlsYW5qYW4gU2Fya2FyOyBTdW1h bmRyYSBNYWplZQpDYzogRGF2ZSBEb2xzb247IHNmY0BpZXRmLm9yZwpTdWJqZWN0OiBSRTogW3Nm Y10gQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMKCkhpIE5pbGFuamFu LCBTdW1hbmRyYSwgRGF2ZToKCkFncmVlZCwgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJlIHR3byBw b3J0cyAob3IgdHdvIHZOSUNzKSwgdGhlbiB3ZSBjYW4gdXNlIHRoZSBTQSAob3IgU0lQKSB0byBk ZXRlcm1pbmUgdGhlIGRpcmVjdGlvbi4KClRob3VnaCB0aGlzIGRvZXMgbm90IHdvcmsgZm9yIGEg c2luZ2xlIGFybWVkIFNGIEkgc3VzcGVjdCB0aGUgU0ZzIHdoaWNoIG5lZWQgdG8gZm9ybSByZXZl cnNlIHBhdGhzIGFyZSBkdWFsIGFybWVkIHRvZGF5LiBJZiB3ZSBzaW1wbHkgc2F5IHRoYXQgU0Zz IHdoaWNoIG5lZWQgdG8gcmV2ZXJzZSBkaXJlY3Rpb25zIGFsc28gbmVlZCB0byBiZSBkdWFsIGFy bWVkLCB0aGVuIHRoaXMgY291bGQgYmUgYSB1bml2ZXJzYWwgc29sdXRpb24uIFRoZSBvdGhlciBu aWNlIHRoaW5nIGFib3V0IGl0IGlzIHRoYXQgaXQgd29ya3MgZm9yIG11bHRpLWFybWVkIGJyYW5j aGluZyBhbHNvLiBTbyBpZiBJIGhhdmUgYW4gU0Ygd2l0aCBOIGVncmVzcyBwb3J0cyAob3Igdk5J Q3MpIHRoZW4gdGhlIFNGIGNhbiBicmFuY2ggTiB3YXlzIHNpbXBseSBieSBzZW5kaW5nIHRvIHRo ZSBjb3JyZWN0IGVncmVzcyBwb3J0LiBUaGlzIHNlZW1zIG5hdHVyYWwgZnJvbSBhbiBTRiBjb2Rp bmcgcG9pbnQgb2Ygdmlldy4KCkNoZWVycywKClBhdWwKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TmlsYW5qYW4gU2Fya2FyClNlbnQ6IEZyaWRheSwgQXByaWwgMDgsIDIwMTYgMjoxNiBBTQpUbzog U3VtYW5kcmEgTWFqZWUgPFMuTWFqZWVARjUuY29tPgpDYzogRGF2ZSBEb2xzb24gPGRkb2xzb25A c2FuZHZpbmUuY29tPjsgc2ZjQGlldGYub3JnClN1YmplY3Q6IFJlOiBbc2ZjXSBBIHJlcXVlc3Qg Zm9yIE1ldGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcwoKV2lsbCBhIFNGIGRldmljZSBoYXZlIDIg cG9ydHM/IFByb2JsZW0gd2FzIHRvIGZpbmQgYW4gIElQIHBhY2tldCBkaXJlY3Rpb24gaW4gYSBz aW5nbGUgcG9ydCBTRiBkZXZpY2UuIEluIGNhc2UgdGhlcmUgYXJlIDIgcG9ydHMsIG9uZSBpcyBj b25uZWN0ZWQgdG8gc3Vic2NyaWJlcnMgYW5kIGFub3RoZXIgaXMgY29ubmVjdGVkIHRvIGludGVy bmV0LCB0aGVuIHRoZXJlIGlzIG5vIGlzc3VlLgoKUmVnYXJkcywKTmlsYW5qYW4KKHNlbnQgZnJv bSBteSBtb2JpbGUgcGhvbmUpCgpPbiA4IEFwciAyMDE2IDEwOjIyLCBTdW1hbmRyYSBNYWplZSA8 Uy5NYWplZUBGNS5jb20+IHdyb3RlOgoK4oCLSSB0aGluayB0aGUgcGFydCBvZiB0aGUgcHJvYmxl bSBsaWVzIGluIHRoZSBkZWZpbml0aW9uIG9mIFVQIGFuZCBET1dOLiBTbyBsZXRzIHRha2Ugc29t ZSB1c2UgY2FzZXMuCgoKYSkgSW4gY2FzZSBvZiBzZXJ2aWNlIHByb3ZpZGVyIG1hbnkgZnVuY3Rp b25zIHNpdHMgYXQgdGhlIGJvcmRlciBiZXR3ZWVuIG5ldHdvcmsvaW50ZXJuZXQgIGFuZCBzdWJz Y3JpYmVyL3VzZXIuIFR5cGljYWxseSB0aGUgdHdvIHNpZGVzIG9mIHRoZSBib3JkZXIgaXMgZGVm aW5lZCBieSB3YXkgb2YgY29uZmlndXJhdGlvbiwgdGhpcyBpbnRlcmZhY2UvdHVubmVsIHBvaW50 IHRvIHN1YnNjcmliZXIgc2lkZSBhbmQgdGhhdCBwb2ludHMgdG8gdGhlIGludGVybmV0LiBBbnl0 aGluZyBpbmdyZXNzIG9uIHN1YnNjcmliZXIgc2lkZSBpcyBGUk9NIHN1YnNjcmliZXIgYW5kIHZp Y2UgdmVyc2EuIFRoZSBVUCBvciBET1dOIGlzIG5vdCBzbyB1c2VmdWwuCgoKYikgQ29uc2lkZXIg YSB0eXBpY2FsIGNsaWVudCBzZXJ2ZXIuICBBc3N1bWluZyB5b3UgbWVhbiBVUDogY2xpZW50IC0+ c2VydmVyL2ZpbmFsIGRlc3RpbmF0aW9uIGFuZCBET1dOIHRoZSBvdGhlciB3YXkuIEEgZmxvdyBh d2FyZSBzZXJ2aWNlIHdvdWxkIGhhdmUgc3RhdGUgU0lQLT5ESVAgYXMgVVAgYW5kIERJUC0+U0lQ IGFzIERPV04uIE90aGVycyBsaWtlIHJvdXRlciBldGMuIG1heSBub3QgY2FyZSBhdCBhbGwgYW5k IHRoYXQgaXMgZmluZS4KCgpJbiBjYXNlIG9mIHNlY3VyaXR5IGRldmljZSB0aGUgaW5ib3VuZCBh bmQgb3V0Ym91bmQgKG9yIHpvbmVzKSBhcmUgZGVmaW5lZCBieSBjb25maWd1cmF0aW9uIHRoYXQg aXMgbG9jYWwgdG8gdGhhdCBlbnRpdHkuIFNvIGhhdmluZyBhIGNsYXNzaWZpZXIgc2F5IElOIG9y IE9VVCB3b3VsZCBiZSB3cm9uZyBpbiB0aGF0IGNhc2UuCgoKU3VtYW5kcmEKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCkZyb206IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5l LmNvbT4KU2VudDogVGh1cnNkYXksIEFwcmlsIDcsIDIwMTYgNzoxMSBQTQpUbzogU3VtYW5kcmEg TWFqZWU7IHNmY0BpZXRmLm9yZwpTdWJqZWN0OiBSRTogQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBh bGxvY2F0aW9uIHNjaGVtZXMKClN1bWFuZHJhIChhbmQgb3RoZXJzIHdobyBoYXZlIHF1ZXN0aW9u ZWQgdGhpcyksIFdoYXQgZG8geW91IG1lYW4gYnkgZGV0ZWN0aW5nIGRpcmVjdGlvbiBmcm9tIHRo ZSBlbmNhcHN1bGF0ZWQgcGFja2V0PwpJ4oCZbSBoYXZpbmcgdHJvdWJsZSB1bmRlcnN0YW5kaW5n IGhvdyBvbmUgY291bGQgdGVsbCBmcm9tIGFuIGFyYml0cmFyeSBJUCBwYWNrZXQgd2hpY2ggZGly ZWN0aW9uIGl0IGlzIGdvaW5nLgooVW5sZXNzIGtub3dpbmcgdGhlIElQIGFkZHJlc3MgYWxsb2Nh dGlvbiBzY2hlbWUgaW4gdGhlIGlubmVyIG5ldHdvcmvigKY/ICBUaGF0IHdvdWxkIGJlIGFyZHVv dXMuKQoKQW5kIHBvc3NpYmx5IGluLWJvdW5kLCBvdXQtYm91bmQgYXJlIGJldHRlciBuYW1lcz8K SSBkb27igJl0IGxpa2UgZm9yd2FyZC9yZXZlcnNlIGJlY2F1c2UgSSBjYW7igJl0IGd1ZXNzIHdo aWNoIGlzIHdoaWNoLgoKLURhdmUKCkZyb206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86Uy5NYWpl ZUBGNS5jb21dClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiAxMjoyNyBQTQpUbzogRGF2 ZSBEb2xzb247IHNmY0BpZXRmLm9yZwpTdWJqZWN0OiBSZTogQSByZXF1ZXN0IGZvciBNZXRhZGF0 YSBhbGxvY2F0aW9uIHNjaGVtZXMKCgrigItEYXZlLAoKCgpUaGUgdXNlIGNhc2UgeW91IGhhdmUg ZGVmaW5lZCBpcyBzdXBwb3J0ZWQgYnkgbW9zdCBkZXZpY2VzIGJ5IGJpbmRpbmcgcG9saWNpZXMg ZXhwbGljaXRseSBvbiwKCiAgIGEpIGludGVyZmFjZSBvciBlcXVpdmFsZW50CgogICBiKSBmbG93 IGRpcmVjdGlvbi4gTW9zdCBmbG93IGF3YXJlIGRldmljZXMgaGFzIHRvIGRldGVjdCB0byBhbmQg ZnJvbSBjb3JyZWN0bHkgdG8gZG8gbG90IG9mIHRobmdzIGNvcnJlY3RseS4KCgoKU28gdGhlIHF1 ZXN0aW9uIGlzIHdoYXQgZG8gd2UgZ2V0IGJ5IGFkZGluZyB0aGlzIGJpdD8gSSBhbSBvcHBvc2Vk IHRvIHRoZSB0ZXJtIFVQIGFuZCBET1dOIChmcm9tIHNob3cgcG9pbnQgb2Ygdmlldz8pLCByYXRo ZXIgZm9yd2FyZCBhbmQgcmV2ZXJzZSAoZXZlbiB0aGF0IGlzIGNvbmZ1c2luZykuCgoKClN1bWFu ZHJhCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBzZmMgPHNmYy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBE YXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUu Y29tPj4KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA2LCAyMDE2IDc6MTMgQU0KVG86IHNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPgpTdWJqZWN0OiBbc2ZjXSBBIHJlcXVlc3QgZm9yIE1l dGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcwoKVG8gdGhvc2UgYXV0aG9ycyBvZiBtZXRhZGF0YSBh bGxvY2F0aW9ucywgSSBoYXZlIGEgcmVxdWVzdC4KSSBiZWxpZXZlIG1hbnkgdHlwZXMgb2Ygc2Vy dmljZSBmdW5jdGlvbnMgYXJlIGdvaW5nIHRvIHdhbnQgdG8gZGlzdGluZ3Vpc2ggdXAtbGluayB0 cmFmZmljIGZyb20gZG93bi1saW5rIHRyYWZmaWMuCkUuZy4sIGEgc2VjdXJpdHkgZGV2aWNlIHRy ZWF0cyBpbi1ib3VuZCB0byB0aGUgcHJvdGVjdGVkIGRldmljZSBkaWZmZXJlbnRseSBmcm9tIG91 dC1ib3VuZC4KRS5nLiwgYW4gYWNjb3VudGluZyBzeXN0ZW0gbmVlZHMgdG8ga25vdyB3aGV0aGVy IHRvIGNoYXJnZSB0aGUgc291cmNlIG9yIGRlc3RpbmF0aW9uIG5vZGUuCgpTbyBteSByZXF1ZXN0 IGlzIHRvIGFsbG9jYXRlIGEgYml0IGZvciB1cC1saW5rL2Rvd24tbGluayBkaXNjcmltaW5hdGlv bi4KSSB0aGluayB0aGUgYWx0ZXJuYXRpdmUgaXMgdG8gY29uZmlndXJlIGVhY2ggU0YgYWJvdXQg ZWFjaCBwYXRoIHdoZXRoZXIgaXQgaXMgdXAgb3IgZG93biwgb3IgdG8gdXNlIHNvbWV0aGluZyBs aWtlIGFuIGV2ZW4vb2RkIHBhdGggSUQgc2NoZW1lLgoKRG9lcyBhbnlvbmUgZWxzZSBzZWUgdGhp cyBhcyB1c2VmdWw/CgpJIGJlbGlldmUgYWxsIG9mIHRoZSBhbGxvY2F0aW9uIGRyYWZ0cyBoYXZl IHJlc2VydmVkIGJpdHMuCgoKRGF2aWQgRG9sc29uClNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QK U2FuZHZpbmUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CnNmYyBtYWlsaW5nIGxpc3QKc2ZjQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjCg== From nobody Fri Apr 15 09:49:47 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 298B512D5D4 for ; Fri, 15 Apr 2016 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 FYbvkLVOcJy5 for ; Fri, 15 Apr 2016 09:49:43 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE512D194 for ; Fri, 15 Apr 2016 09:49:42 -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.0195.001; Fri, 15 Apr 2016 12:49:41 -0400 From: Dave Dolson To: Sumandra Majee Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wA06k3BABaJqpAABVdClwAR/VYAAAgzRwABZ3a4AAAIWBNg Date: Fri, 15 Apr 2016 16:49:40 +0000 Message-ID: References: <1460042865963.25707@F5.com>, , <1460091126273.230@F5.com> <1D15709113D6B34BAE5E128F392059CA01268568BE@blr-exch-1.sandvine.com>, <1460738575691.54747@F5.com> In-Reply-To: <1460738575691.54747@F5.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: Cc: "sfc@ietf.org" Subject: Re: [sfc] A request for Metadata allocation schemes 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, 15 Apr 2016 16:49:45 -0000 U3VtYW5kcmEsDQoNCj4gSSBhbSBnZW5lcmFsbHkgb3Bwb3NlZCB0byBzdGFuZGFyZGl6aW5nIG1l dGFkYXRhIGFsbG9jYXRpb24gdGhpcyBlYXJseS4NCg0KUmVmZXJyaW5nIGJhY2sgdG8gbXkgb3Jp Z2luYWwgZW1haWwsIEkgbWFkZSB0aGUgcmVxdWVzdCB0byB0aG9zZSB3aG8gYXJlIHByb3Bvc2lu ZyBtZXRhZGF0YSBzY2hlbWVzIGluIGRyYWZ0czsgSSBhbSBub3QgYXNraW5nIGZvciBhIGRpcmVj dGlvbiBpbmRpY2F0aW9uIGluIHRoZSBOU0ggYmFzZSBwcm90b2NvbC4NCg0KSW4gZWFjaCBvZiB0 aGUgYWxsb2NhdGlvbiBzY2hlbWVzIHRoZXJlIGFyZSAicmVzZXJ2ZWQiIGJpdHMgdGhhdCBjb3Vs ZCBiZSB1c2VkLg0KDQotRGF2ZQ0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0gDQpTZW50OiBGcmlk YXksIEFwcmlsIDE1LCAyMDE2IDEyOjQzIFBNDQpUbzogQm90dG9yZmYsIFBhdWw7IE5pbGFuamFu IFNhcmthcg0KQ2M6IERhdmUgRG9sc29uOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2Zj XSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcw0KDQpEYXZlLCBQYXVs IGFuZCBOaWxhbmphbiwNCg0KSSBhbSBub3Qgb3Bwb3NlZCB0byBoYXZpbmcgYSBkaXJlY3Rpb24g Yml0IGluIHRoZSBtZXRhZGF0YSwgeWVzIGl0IG1pZ2h0IGJlY29tZSBuZWNlc3NpdHkgaW4gY2Vy dGFpbiBzaXR1YXRpb24uIEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCB0aGlzIHNlbnNlIG9mIGRp cmVjdGlvbiBmb3IgbWFqb3JpdHkgb2YgdXNlIGNhc2VzLg0KDQpJIGFtIGdlbmVyYWxseSBvcHBv c2VkIHRvIHN0YW5kYXJkaXppbmcgbWV0YWRhdGEgYWxsb2NhdGlvbiB0aGlzIGVhcmx5Lg0KDQpX aGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8gaGF2ZSBhIG1ldGFkYXRhIHJlZ2lzdHJ5IGFuZCBh IHNjaGVtZSBmb3IgdGhhdC4gIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogQm90dG9yZmYsIFBhdWwgPHBhdWwuYm90dG9yZmZAaHBlLmNvbT4NClNlbnQ6 IEZyaWRheSwgQXByaWwgOCwgMjAxNiA2OjEwIEFNDQpUbzogTmlsYW5qYW4gU2Fya2FyOyBTdW1h bmRyYSBNYWplZQ0KQ2M6IERhdmUgRG9sc29uOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBb c2ZjXSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcw0KDQpIaSBOaWxh bmphbiwgU3VtYW5kcmEsIERhdmU6DQoNCkFncmVlZCwgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgYXJl IHR3byBwb3J0cyAob3IgdHdvIHZOSUNzKSwgdGhlbiB3ZSBjYW4gdXNlIHRoZSBTQSAob3IgU0lQ KSB0byBkZXRlcm1pbmUgdGhlIGRpcmVjdGlvbi4NCg0KVGhvdWdoIHRoaXMgZG9lcyBub3Qgd29y ayBmb3IgYSBzaW5nbGUgYXJtZWQgU0YgSSBzdXNwZWN0IHRoZSBTRnMgd2hpY2ggbmVlZCB0byBm b3JtIHJldmVyc2UgcGF0aHMgYXJlIGR1YWwgYXJtZWQgdG9kYXkuIElmIHdlIHNpbXBseSBzYXkg dGhhdCBTRnMgd2hpY2ggbmVlZCB0byByZXZlcnNlIGRpcmVjdGlvbnMgYWxzbyBuZWVkIHRvIGJl IGR1YWwgYXJtZWQsIHRoZW4gdGhpcyBjb3VsZCBiZSBhIHVuaXZlcnNhbCBzb2x1dGlvbi4gVGhl IG90aGVyIG5pY2UgdGhpbmcgYWJvdXQgaXQgaXMgdGhhdCBpdCB3b3JrcyBmb3IgbXVsdGktYXJt ZWQgYnJhbmNoaW5nIGFsc28uIFNvIGlmIEkgaGF2ZSBhbiBTRiB3aXRoIE4gZWdyZXNzIHBvcnRz IChvciB2TklDcykgdGhlbiB0aGUgU0YgY2FuIGJyYW5jaCBOIHdheXMgc2ltcGx5IGJ5IHNlbmRp bmcgdG8gdGhlIGNvcnJlY3QgZWdyZXNzIHBvcnQuIFRoaXMgc2VlbXMgbmF0dXJhbCBmcm9tIGFu IFNGIGNvZGluZyBwb2ludCBvZiB2aWV3Lg0KDQpDaGVlcnMsDQoNClBhdWwNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTmlsYW5qYW4gU2Fya2FyDQpTZW50OiBGcmlkYXksIEFwcmlsIDA4LCAy MDE2IDI6MTYgQU0NClRvOiBTdW1hbmRyYSBNYWplZSA8Uy5NYWplZUBGNS5jb20+DQpDYzogRGF2 ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3NmY10gQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0KV2ls bCBhIFNGIGRldmljZSBoYXZlIDIgcG9ydHM/IFByb2JsZW0gd2FzIHRvIGZpbmQgYW4gIElQIHBh Y2tldCBkaXJlY3Rpb24gaW4gYSBzaW5nbGUgcG9ydCBTRiBkZXZpY2UuIEluIGNhc2UgdGhlcmUg YXJlIDIgcG9ydHMsIG9uZSBpcyBjb25uZWN0ZWQgdG8gc3Vic2NyaWJlcnMgYW5kIGFub3RoZXIg aXMgY29ubmVjdGVkIHRvIGludGVybmV0LCB0aGVuIHRoZXJlIGlzIG5vIGlzc3VlLg0KDQpSZWdh cmRzLA0KTmlsYW5qYW4NCihzZW50IGZyb20gbXkgbW9iaWxlIHBob25lKQ0KDQpPbiA4IEFwciAy MDE2IDEwOjIyLCBTdW1hbmRyYSBNYWplZSA8Uy5NYWplZUBGNS5jb20+IHdyb3RlOg0KDQrigItJ IHRoaW5rIHRoZSBwYXJ0IG9mIHRoZSBwcm9ibGVtIGxpZXMgaW4gdGhlIGRlZmluaXRpb24gb2Yg VVAgYW5kIERPV04uIFNvIGxldHMgdGFrZSBzb21lIHVzZSBjYXNlcy4NCg0KDQphKSBJbiBjYXNl IG9mIHNlcnZpY2UgcHJvdmlkZXIgbWFueSBmdW5jdGlvbnMgc2l0cyBhdCB0aGUgYm9yZGVyIGJl dHdlZW4gbmV0d29yay9pbnRlcm5ldCAgYW5kIHN1YnNjcmliZXIvdXNlci4gVHlwaWNhbGx5IHRo ZSB0d28gc2lkZXMgb2YgdGhlIGJvcmRlciBpcyBkZWZpbmVkIGJ5IHdheSBvZiBjb25maWd1cmF0 aW9uLCB0aGlzIGludGVyZmFjZS90dW5uZWwgcG9pbnQgdG8gc3Vic2NyaWJlciBzaWRlIGFuZCB0 aGF0IHBvaW50cyB0byB0aGUgaW50ZXJuZXQuIEFueXRoaW5nIGluZ3Jlc3Mgb24gc3Vic2NyaWJl ciBzaWRlIGlzIEZST00gc3Vic2NyaWJlciBhbmQgdmljZSB2ZXJzYS4gVGhlIFVQIG9yIERPV04g aXMgbm90IHNvIHVzZWZ1bC4NCg0KDQpiKSBDb25zaWRlciBhIHR5cGljYWwgY2xpZW50IHNlcnZl ci4gIEFzc3VtaW5nIHlvdSBtZWFuIFVQOiBjbGllbnQgLT5zZXJ2ZXIvZmluYWwgZGVzdGluYXRp b24gYW5kIERPV04gdGhlIG90aGVyIHdheS4gQSBmbG93IGF3YXJlIHNlcnZpY2Ugd291bGQgaGF2 ZSBzdGF0ZSBTSVAtPkRJUCBhcyBVUCBhbmQgRElQLT5TSVAgYXMgRE9XTi4gT3RoZXJzIGxpa2Ug cm91dGVyIGV0Yy4gbWF5IG5vdCBjYXJlIGF0IGFsbCBhbmQgdGhhdCBpcyBmaW5lLg0KDQoNCklu IGNhc2Ugb2Ygc2VjdXJpdHkgZGV2aWNlIHRoZSBpbmJvdW5kIGFuZCBvdXRib3VuZCAob3Igem9u ZXMpIGFyZSBkZWZpbmVkIGJ5IGNvbmZpZ3VyYXRpb24gdGhhdCBpcyBsb2NhbCB0byB0aGF0IGVu dGl0eS4gU28gaGF2aW5nIGEgY2xhc3NpZmllciBzYXkgSU4gb3IgT1VUIHdvdWxkIGJlIHdyb25n IGluIHRoYXQgY2FzZS4NCg0KDQpTdW1hbmRyYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPg0KU2VudDog VGh1cnNkYXksIEFwcmlsIDcsIDIwMTYgNzoxMSBQTQ0KVG86IFN1bWFuZHJhIE1hamVlOyBzZmNA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9jYXRpb24g c2NoZW1lcw0KDQpTdW1hbmRyYSAoYW5kIG90aGVycyB3aG8gaGF2ZSBxdWVzdGlvbmVkIHRoaXMp LCBXaGF0IGRvIHlvdSBtZWFuIGJ5IGRldGVjdGluZyBkaXJlY3Rpb24gZnJvbSB0aGUgZW5jYXBz dWxhdGVkIHBhY2tldD8NCknigJltIGhhdmluZyB0cm91YmxlIHVuZGVyc3RhbmRpbmcgaG93IG9u ZSBjb3VsZCB0ZWxsIGZyb20gYW4gYXJiaXRyYXJ5IElQIHBhY2tldCB3aGljaCBkaXJlY3Rpb24g aXQgaXMgZ29pbmcuDQooVW5sZXNzIGtub3dpbmcgdGhlIElQIGFkZHJlc3MgYWxsb2NhdGlvbiBz Y2hlbWUgaW4gdGhlIGlubmVyIG5ldHdvcmvigKY/ICBUaGF0IHdvdWxkIGJlIGFyZHVvdXMuKQ0K DQpBbmQgcG9zc2libHkgaW4tYm91bmQsIG91dC1ib3VuZCBhcmUgYmV0dGVyIG5hbWVzPw0KSSBk b27igJl0IGxpa2UgZm9yd2FyZC9yZXZlcnNlIGJlY2F1c2UgSSBjYW7igJl0IGd1ZXNzIHdoaWNo IGlzIHdoaWNoLg0KDQotRGF2ZQ0KDQpGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFq ZWVARjUuY29tXQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDEyOjI3IFBNDQpUbzog RGF2ZSBEb2xzb247IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEEgcmVxdWVzdCBmb3IgTWV0 YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNCg0K4oCLRGF2ZSwNCg0KDQoNClRoZSB1c2UgY2Fz ZSB5b3UgaGF2ZSBkZWZpbmVkIGlzIHN1cHBvcnRlZCBieSBtb3N0IGRldmljZXMgYnkgYmluZGlu ZyBwb2xpY2llcyBleHBsaWNpdGx5IG9uLA0KDQogICBhKSBpbnRlcmZhY2Ugb3IgZXF1aXZhbGVu dA0KDQogICBiKSBmbG93IGRpcmVjdGlvbi4gTW9zdCBmbG93IGF3YXJlIGRldmljZXMgaGFzIHRv IGRldGVjdCB0byBhbmQgZnJvbSBjb3JyZWN0bHkgdG8gZG8gbG90IG9mIHRobmdzIGNvcnJlY3Rs eS4NCg0KDQoNClNvIHRoZSBxdWVzdGlvbiBpcyB3aGF0IGRvIHdlIGdldCBieSBhZGRpbmcgdGhp cyBiaXQ/IEkgYW0gb3Bwb3NlZCB0byB0aGUgdGVybSBVUCBhbmQgRE9XTiAoZnJvbSBzaG93IHBv aW50IG9mIHZpZXc/KSwgcmF0aGVyIGZvcndhcmQgYW5kIHJldmVyc2UgKGV2ZW4gdGhhdCBpcyBj b25mdXNpbmcpLg0KDQoNCg0KU3VtYW5kcmENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNv bTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCA2 LCAyMDE2IDc6MTMgQU0NClRvOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFtzZmNdIEEgcmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoN ClRvIHRob3NlIGF1dGhvcnMgb2YgbWV0YWRhdGEgYWxsb2NhdGlvbnMsIEkgaGF2ZSBhIHJlcXVl c3QuDQpJIGJlbGlldmUgbWFueSB0eXBlcyBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgZ29pbmcg dG8gd2FudCB0byBkaXN0aW5ndWlzaCB1cC1saW5rIHRyYWZmaWMgZnJvbSBkb3duLWxpbmsgdHJh ZmZpYy4NCkUuZy4sIGEgc2VjdXJpdHkgZGV2aWNlIHRyZWF0cyBpbi1ib3VuZCB0byB0aGUgcHJv dGVjdGVkIGRldmljZSBkaWZmZXJlbnRseSBmcm9tIG91dC1ib3VuZC4NCkUuZy4sIGFuIGFjY291 bnRpbmcgc3lzdGVtIG5lZWRzIHRvIGtub3cgd2hldGhlciB0byBjaGFyZ2UgdGhlIHNvdXJjZSBv ciBkZXN0aW5hdGlvbiBub2RlLg0KDQpTbyBteSByZXF1ZXN0IGlzIHRvIGFsbG9jYXRlIGEgYml0 IGZvciB1cC1saW5rL2Rvd24tbGluayBkaXNjcmltaW5hdGlvbi4NCkkgdGhpbmsgdGhlIGFsdGVy bmF0aXZlIGlzIHRvIGNvbmZpZ3VyZSBlYWNoIFNGIGFib3V0IGVhY2ggcGF0aCB3aGV0aGVyIGl0 IGlzIHVwIG9yIGRvd24sIG9yIHRvIHVzZSBzb21ldGhpbmcgbGlrZSBhbiBldmVuL29kZCBwYXRo IElEIHNjaGVtZS4NCg0KRG9lcyBhbnlvbmUgZWxzZSBzZWUgdGhpcyBhcyB1c2VmdWw/DQoNCkkg YmVsaWV2ZSBhbGwgb2YgdGhlIGFsbG9jYXRpb24gZHJhZnRzIGhhdmUgcmVzZXJ2ZWQgYml0cy4N Cg0KDQpEYXZpZCBEb2xzb24NClNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QNClNhbmR2aW5lDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo= From nobody Fri Apr 15 14:36:44 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 D8B2F12D507 for ; Fri, 15 Apr 2016 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 aCe3UthfxGED for ; Fri, 15 Apr 2016 14:36:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE8D12D5BD for ; Fri, 15 Apr 2016 14:36:37 -0700 (PDT) Received: from TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM (10.162.187.152) by TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM (10.162.187.152) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 15 Apr 2016 21:36:21 +0000 Received: from TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM ([10.162.187.152]) by TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM ([10.162.187.152]) with mapi id 15.01.0453.030; Fri, 15 Apr 2016 21:36:21 +0000 From: "Bottorff, Paul" To: "Paul Quinn (paulq)" , "Elzur, Uri" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivflTl8PyB805kuSkB1naNwin5+IdPDQgAFZBQCAAcu2oA== Date: Fri, 15 Apr 2016 21:36:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.211.195.7] x-ms-office365-filtering-correlation-id: e4a09ae7-e0a2-4ffa-eb91-08d36575fc7a x-microsoft-exchange-diagnostics: 1; TU4PR84MB0159; 5:WOuWip4XIb2mOyytI4kVjis8ejor46KbWvjIwLBNNPgjD4qiu5kJLIR8zFPYyAxwvHFtooQ3sJM5GjDkMTG1iNc6GisAXZ9wTr6O2oEHHxBIySdqbiICKmuKsFO2qMRdX+wrWaU1+Qm0EWQ0+PDyuA==; 24:kAaosUdsqyFGkWjeFVs4n3DYbroiGrhgFEdu2SEpTvjNuKk2unPdV7qNCN9fSmyOmdO+eMCWe0SN8XknnWAzfWkC0m+9majpPItkh7zS0lU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TU4PR84MB0159; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:TU4PR84MB0159; BCL:0; PCL:0; RULEID:; SRVR:TU4PR84MB0159; x-forefront-prvs: 0913EA1D60 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(2900100001)(9686002)(2906002)(2950100001)(106116001)(5003600100002)(586003)(4326007)(33656002)(81166005)(86362001)(5002640100001)(102836003)(50986999)(6116002)(3846002)(99286002)(122556002)(87936001)(3280700002)(3660700001)(11100500001)(5004730100002)(5001770100001)(5008740100001)(230783001)(19580395003)(19580405001)(76176999)(1096002)(77096005)(54356999)(1220700001)(92566002)(189998001)(10400500002)(66066001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:TU4PR84MB0159; H:TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2016 21:36:20.9458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR84MB0159 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 15 Apr 2016 21:36:43 -0000 Hi Paul Q. Some responses to comments. Cheers, Paul -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Thursday, April 14, 2016 10:21 AM To: Bottorff, Paul Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a num= ber of deficiencies which lead to transport dependencies and to layer viola= tions, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 PB> I have never asserted that SPI+SI for a "transport" address. Please don= 't confuse what I've said. The modeling of SPI+SI as a service layer addres= s is very soundly rooted in classic network layer modeling. It is the asser= tion that that the service layer is independent from the "transport" layer = below that indicates the SPI+SI form the address used by the service layer = dialog. This address is mapped into the "transport" by mapping the SPI+SI i= nto a transport tunnel and destination address. > 2)there is no resolution to forward/reverse addressing necessary for supp= ort of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. PB>We have a lot of work on both L4-higher SFs and proxy forwarders for L4-= higher SFs for MAC Chaining and understand this problem in a lot of detail.= Having two unidirectional chains don't solve the forward/reverse traffic p= roblem because the reverse path SPI/SI are not included in the NSH header a= nd therefore not available at the time we need to reverse the forwarding di= rection. Are you mandating every SF and Proxy be provisioned with the forwa= rd and reverse SPI/SI? If so the solution is unacceptable to me. =20 > 3)there is no resolution to encoding hierarchies which are of importance = to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. PB> A general stacking solution will require some type of support which I b= elieve should be in the base header so the context words are kept clear for= pure meta-data. > 4)the draft needs a transport service interface and a description of the = mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. PB>You are trying to specify a "transport" independent layer, however have = not specified what services the transport must provide to support the SFC l= ayer. A service interface is one of the formalized ways to specify the feat= ure requirements of the underlying layer. > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. PB> This is always the last resort dodge we use in standards, however it al= ways comes at the price of some market confusion and delay. Even though I c= an accept this if no middle ground is possible, I don't think we have pushe= d the parties hard enough toward a converged solution to give it up on it y= et. >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 PB> Agreed, I stand corrected. > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 PB> I both disagree that SI is useful for loop squeltching or that "transpo= rt" TTL can stop service layer looping. To use the "transport" TTL the fie= ld would need to be copied from one "transport" to the next "transport" ove= r the SFC service layer. Disregarding the fact that this operation is build= ing a dependency between the "transport" and service layers, which we expre= ssly are trying to avoid, the TTL fields of the transports are not sized to= allow for the expanded path lengths which could be created in chains. In a= ddition, some of the transports like Ethernet only support TTL for in speci= al cases (Ethernet only supports TTL when using F-Tag forwarding). > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 PB> Just the opposite, failing to add QoS to the NSH header is blurring the= lines between the service layer and the "transport" layer. Consider an a c= hain which uses both a best effort and an expedited service. Next consider = building the chain where each hop uses a different type of "transport". As = we map from one "transport" to the next we may over some hops have less QoS= information than others. As we continue to the next "transport" we retain = the integrity of the end-to-end communication by regenerating QoS from the = original QoS contained at the service layer a driven down into the "transpo= rt".=20 > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function. PB> In a multi-manager situation I need a way to avoid collision in the all= ocation of the SPI/SI space which is being independently allocated by diffe= rent managers. From nobody Fri Apr 15 14:54: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 BDEBA12D835 for ; Fri, 15 Apr 2016 14:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 zhhmmicaHaPb for ; Fri, 15 Apr 2016 14:54:53 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0ED12D8C6 for ; Fri, 15 Apr 2016 14:54:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 695405A10EE; Fri, 15 Apr 2016 14:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1460757292; bh=Y6QZ7MrT9FYwQSlo6/qHp26xheWhZAnDRDQztz9Av/M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qqAINKl6hkQ+xOnJfyj5c+XF76ZH1IQN44CpwrwL/WXZIuUW0VO1mOg1fKeD6ElBO T1VW0Tli/ThesJmGyBY2yuWC18C+RxfIo7GHoze64AW1wK2WP7c+pBMR2394KPj+3+ Z5JvYFuax7Bn3EkB2FXeqCIlL2jLesCe779haMPw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 584861C013B; Fri, 15 Apr 2016 14:54:51 -0700 (PDT) To: "Bottorff, Paul" , "Paul Quinn (paulq)" , "Elzur, Uri" References: From: "Joel M. Halpern" Message-ID: <5711631F.6000006@joelhalpern.com> Date: Fri, 15 Apr 2016 17:54:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 15 Apr 2016 21:54:55 -0000 Paul B., just to make sure I am reading you correctly, on the issue of reverse direction SFPs, I believe the issue you are referring to is specifically the case of SFs which need to originate a packet back to the source of a packet the SF has processed? While I think SFs can do better, it would seem that a properly configured classifier at the SFF service that SF can take care of that case. Requiring that it be encoded in the SPI seems overkill. Yours, Joel On 4/15/16 5:36 PM, Bottorff, Paul wrote: > Hi Paul Q. > > Some responses to comments. > > Cheers, > > Paul > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Thursday, April 14, 2016 10:21 AM > To: Bottorff, Paul > Cc: Thomas Narten ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Paul B. > > Some comments inline. > > > >> On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote: >> >> Hi Thomas: >> >> I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing to close a format before we have clear agreement on the forwarding principles and features is just too high. >> >> The major problems with the current draft are: >> 1)the service address formed by the combined SPI+SI appears to have a number of deficiencies which lead to transport dependencies and to layer violations, > > PQ> You draw this broad stoke, however, it is relatively unsubstantiated with technical facts. The WG discussed the representation of the SPI/SI prior to NSH adoption. The SPI/SI are not transport values -- and please don't conflate transport (and the associated requirements) with address family. > PB> I have never asserted that SPI+SI for a "transport" address. Please don't confuse what I've said. The modeling of SPI+SI as a service layer address is very soundly rooted in classic network layer modeling. It is the assertion that that the service layer is independent from the "transport" layer below that indicates the SPI+SI form the address used by the service layer dialog. This address is mapped into the "transport" by mapping the SPI+SI into a transport tunnel and destination address. > >> 2)there is no resolution to forward/reverse addressing necessary for support of many L4-high service functions, > > PQ> That is factually incorrect and I think derives from your opinion that SPI/SI == address family: in general, you can create two unidirectional chains and use them for forward and reverse traffic. This has been reviewed with /by L4+ vendors/experts. > PB>We have a lot of work on both L4-higher SFs and proxy forwarders for L4-higher SFs for MAC Chaining and understand this problem in a lot of detail. Having two unidirectional chains don't solve the forward/reverse traffic problem because the reverse path SPI/SI are not included in the NSH header and therefore not available at the time we need to reverse the forwarding direction. Are you mandating every SF and Proxy be provisioned with the forward and reverse SPI/SI? If so the solution is unacceptable to me. > > >> 3)there is no resolution to encoding hierarchies which are of importance to SFC applications in NFV environments, > > PQ> Encoding hierarchies is an optimization of the base protocol to support scaling in a large deployment; in any case such optimization does not require changes to the base SFC encapsulation. > PB> A general stacking solution will require some type of support which I believe should be in the base header so the context words are kept clear for pure meta-data. > >> 4)the draft needs a transport service interface and a description of the mappings used for the service layer onto the transport layer, > > PQ> I am not sure what you mean by "transport service interface" - it is true that the SPI/SI need to map to a transport layer forwarding entry but I don't know what you are implying. > PB>You are trying to specify a "transport" independent layer, however have not specified what services the transport must provide to support the SFC layer. A service interface is one of the formalized ways to specify the feature requirements of the underlying layer. > >> 5)the draft specifies two independent formats for encoding the NSH header which is likely to divide the market slowing the deployment of NSH. > > PQ> The draft actually specifies two metadata formats for flexibility and the market will decide which is most appropriate based on specific use cases. The evidence is clear: a wide-range of _implementations_ already exist. In fact, the real impediment to deployment is esoteric opinion. > PB> This is always the last resort dodge we use in standards, however it always comes at the price of some market confusion and delay. Even though I can accept this if no middle ground is possible, I don't think we have pushed the parties hard enough toward a converged solution to give it up on it yet. > >> >>> From my point of view the SFC formed service plane layer network with a peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) forms the address for this service plane. As it stands there is an attempt to overload the function of the SI as both the SF identifier with the Service Path and as a form of loop detection, however the coupling has resulted in two problems: >> 1)Since every SF in a path must have a sequential SI, in the event we need to insert or delete a SF it is necessary to update the SFF forwarding entries for the entire chain. To fix this either the SI should be allowed to take non-sequential values along the chain or should not be used for SF addressing. > > PQ> This is not a true statement; if an SF needs to be added or deleted then it is necessary to update the SFF forwarding entries for all SFFs downstream of where the change occurs. > PB> Agreed, I stand corrected. > > >> 2)Since the SI is only decremented on SF hops it can't guard against a loop between SFFs or SCFs, hence SI is not a reliable method for loop squelching. If a TTL is needed it needs to be separated from SI. Given that there is no clear alternative to TTL for loop squelching at the service layer I believe we do need to include an effective TTL to go forward. > > PQ> The SI can provide a simple loop check within the serivce plane but it's primary semantic value is one of location. The transport itself can provide loop detection as well as SFF verification of SPI/SI + source. > PB> I both disagree that SI is useful for loop squeltching or that "transport" TTL can stop service layer looping. To use the "transport" TTL the field would need to be copied from one "transport" to the next "transport" over the SFC service layer. Disregarding the fact that this operation is building a dependency between the "transport" and service layers, which we expressly are trying to avoid, the TTL fields of the transports are not sized to allow for the expanded path lengths which could be created in chains. In addition, some of the transports like Ethernet only support TTL for in special cases (Ethernet only supports TTL when using F-Tag forwarding). > >> 3)Every other successful address space has needed to add a few bits to support QoS options. I would suggest taking 3-4 bits from the MD-type and to reserve for QoS handling. > > PQ> Again, this is blurring the lines: QoS is handled, as expected by the selection transport. This is a feature, not a bug, architecturally speaking. > PB> Just the opposite, failing to add QoS to the NSH header is blurring the lines between the service layer and the "transport" layer. Consider an a chain which uses both a best effort and an expedited service. Next consider building the chain where each hop uses a different type of "transport". As we map from one "transport" to the next we may over some hops have less QoS information than others. As we continue to the next "transport" we retain the integrity of the end-to-end communication by regenerating QoS from the original QoS contained at the service layer a driven down into the "transport". > >> 4)In may data centers we have multi-vendor deployments. In these environments we may have different managers assigning chains. There should to be some convention for splitting the address space between these vendors. The most desirable solution to this is to add an assigned organization ID to the address space. An alternative would be to separate the SPI into a 4 and 20 bit field designating the high 4 bits as a local manager ID. >> > > PQ> You are conflating federation/configuration and frame format. The multi-manager scenario is a control-plane/management-plane function. > PB> In a multi-manager situation I need a way to avoid collision in the allocation of the SPI/SI space which is being independently allocated by different managers. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Apr 15 17:00:53 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 4B81A12D922 for ; Fri, 15 Apr 2016 17:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 fgMg7bpDi_SG for ; Fri, 15 Apr 2016 17:00:50 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id C2E1712D914 for ; Fri, 15 Apr 2016 17:00:50 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 15 Apr 2016 17:00:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,489,1455004800"; d="scan'208";a="956036757" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga002.jf.intel.com with ESMTP; 15 Apr 2016 17:00:50 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX102.amr.corp.intel.com ([169.254.3.42]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 17:00:50 -0700 From: "Elzur, Uri" To: "Paul Quinn (paulq)" , Dave Dolson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfOQCYv/wVVMUagOUO32rRCGp+GxnOggAB/ioCAAFnrgIAAy/AAgAGYJwCAADqXAIABkJJg Date: Sat, 16 Apr 2016 00:00:50 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958589365584@ORSMSX114.amr.corp.intel.com> References: <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@cisco.com> <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com> In-Reply-To: <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDY1NGEzMjQtZWQwMy00MDU0LWE0MTEtN2QzM2Y0Y2I5NTBkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjVFMVZFem9pZFwvWWx3bmFBNDhtdXZ2NXJTOGZpc0I4Y2ZCakFzQjZcL1F6RT0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 16 Apr 2016 00:00:52 -0000 Catching up (was traveling myself, sigh) I'm ok with the added text too. I think it may solve your need/case, not s= ure how broad it is, but see no harm. It also requires some control plane i= nteraction as the metadata is not guaranteed to stay constant for the durat= ion, so the disclaimer you propose is necessary Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, April 14, 2016 10:04 AM To: Dave Dolson Cc: Elzur, Uri ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Dave, Sorry, I was traveling yesterday. In principal I don't have any issues wit= h the text since it doesn't impose requirements but rather clarifies a poss= ible behavior. I do wonder about how common this will be: a control of sorts is needed for= semantic meaning -- in type 1 or type 2 cases. Paul > On Apr 14, 2016, at 9:33 AM, Dave Dolson wrote: >=20 > Paul and Uri, can you please comment as to whether you agree or disagree = with this wording? >=20 > I feel that it allows the actual content to be opaque while giving=20 > guidance for service functions that create or replay packets in the chain= . >=20 > From my point of view, this is how such devices will work anyhow. >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Wednesday, April 13, 2016 9:13 AM > To: Paul Quinn (paulq); Ron Parker > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Paul, > Are you unhappy with the metadata constraints I suggested below? > Perhaps qualified by "In the absence of out-of-band configuration..." ? >=20 > I believe that the schemes proposed in these drafts satisfy the constrain= ts: > - draft-sfc-nsh-dc-allocation-4, > - draft-napper-sfc-nsh-broadband-allocation-00 >=20 > (I thought there were more allocation schemes, but I guess they=20 > expired.) >=20 > I'll update it here: >=20 > In the absence of out-of-band configuration to indicate otherwise, > metadata used in NSH headers must meet the condition that > a transport-layer-stateful Service Function can save away > metadata values that it has witnessed. An injected packet can > therefore be assigned a clone of metadata taken from an earlier > packet going in the same direction. For example, a Service Function > can send a TCP packet using metadata cloned from another TCP packet > of the same connection and direction. >=20 > Note that the Service Function need not know the meaning of the > metadata; it just needs to know it is safe to clone in this manner. >=20 >=20 > -Dave >=20 >=20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 15 18:30:26 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 E482412DE5E for ; Fri, 15 Apr 2016 18:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 e7PWmzO3lqi5 for ; Fri, 15 Apr 2016 18:30:22 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4245A12DB1F for ; Fri, 15 Apr 2016 18:30:22 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 15 Apr 2016 18:30:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,489,1455004800"; d="scan'208";a="687073419" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 15 Apr 2016 18:30:18 -0700 Received: from orsmsx162.amr.corp.intel.com (10.22.240.85) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 15 Apr 2016 18:30:18 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX162.amr.corp.intel.com ([169.254.3.111]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 18:30:18 -0700 From: "Elzur, Uri" To: "Bottorff, Paul" , "Paul Quinn (paulq)" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt PaulB thread Thread-Index: AdGXfY3x41WguKLXSGe1s9NgcX8guw== Date: Sat, 16 Apr 2016 01:30:17 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958589365614@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTM3N2NkZDktNWM5OC00YTdjLWJhZDYtOTNhMmJiOTI1Mjg4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Img3OEgxSWdVOUVVWlNHUkNEaVVKdzdPUU5ybWtjeVwvT3E0MDFEZnIrR2prPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt PaulB thread 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, 16 Apr 2016 01:30:25 -0000 Some comments below [UE] Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Bottorff, Paul Sent: Friday, April 15, 2016 2:36 PM To: Paul Quinn (paulq) ; Elzur, Uri Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Paul Q. Some responses to comments. Cheers, Paul -----Original Message----- From: Paul Quinn (paulq) [mailto:paulq@cisco.com]=20 Sent: Thursday, April 14, 2016 10:21 AM To: Bottorff, Paul Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a num= ber of deficiencies which lead to transport dependencies and to layer viola= tions, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 PB> I have never asserted that SPI+SI for a "transport" address. Please don= 't confuse what I've said. The modeling of SPI+SI as a service layer addres= s is very soundly rooted in classic network layer modeling. It is the asser= tion that that the service layer is independent from the "transport" layer = below that indicates the SPI+SI form the address used by the service layer = dialog. This address is mapped into the "transport" by mapping the SPI+SI i= nto a transport tunnel and destination address. [UE] the WG has long recognized the need and advantages of the "service" as= a sort of an overlay on top of whatever transport is deployed underneath, = to enable e2e and seamless stitching over various transports. I'm not sure = I see why the "Service" amounts to a full transport on top of an underlying= transport - this seems like duplication. To me SFC/NSH is more of a specia= lized form of an overlay. If we look into overlays, we find no QoS, no loop= detection, just an identifier unique to that overlay... > 2)there is no resolution to forward/reverse addressing necessary for supp= ort of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. PB>We have a lot of work on both L4-higher SFs and proxy forwarders for L4-= higher SFs for MAC Chaining and understand this problem in a lot of detail.= Having two unidirectional chains don't solve the forward/reverse traffic p= roblem because the reverse path SPI/SI are not included in the NSH header a= nd therefore not available at the time we need to reverse the forwarding di= rection. Are you mandating every SF and Proxy be provisioned with the forwa= rd and reverse SPI/SI? If so the solution is unacceptable to me. =20 > 3)there is no resolution to encoding hierarchies which are of importance = to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. PB> A general stacking solution will require some type of support which I b= elieve should be in the base header so the context words are kept clear for= pure meta-data. > 4)the draft needs a transport service interface and a description of the = mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. PB>You are trying to specify a "transport" independent layer, however have = not specified what services the transport must provide to support the SFC l= ayer. A service interface is one of the formalized ways to specify the feat= ure requirements of the underlying layer. [UE] like in other cases, it implies one can choose the most appropriate tr= ansport for the app needs. In absence of underlying transport, I see this a= s a valid concern, but as mentioned above NSH is not a transport > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. PB> This is always the last resort dodge we use in standards, however it al= ways comes at the price of some market confusion and delay. Even though I c= an accept this if no middle ground is possible, I don't think we have pushe= d the parties hard enough toward a converged solution to give it up on it y= et. [UE] we have waited more than 2 years, we have multiple implementations. Li= ke you, I'd love to see more convergence, but the drawback is larger. If we= keep dragging standards on, for years, rather than recognizing the higher = pace of innovation and technology shifts in the market, we end up as accomp= lices to the diminishing value of std in the industry. It is a delicate bal= ance. Not sure it will be resloved in a short time to justify holding NSH b= ack for this =20 >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 PB> Agreed, I stand corrected. > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 PB> I both disagree that SI is useful for loop squeltching or that "transpo= rt" TTL can stop service layer looping. To use the "transport" TTL the fie= ld would need to be copied from one "transport" to the next "transport" ove= r the SFC service layer. Disregarding the fact that this operation is build= ing a dependency between the "transport" and service layers, which we expre= ssly are trying to avoid, the TTL fields of the transports are not sized to= allow for the expanded path lengths which could be created in chains. In a= ddition, some of the transports like Ethernet only support TTL for in speci= al cases (Ethernet only supports TTL when using F-Tag forwarding). [UE] the SI role is - mapping and identification of the SF to be used. Lik= e the arguments above, there is no attempt to duplicate each and every tran= sport service in an SFC/NSH "service" layer. An implementer can benefit fro= m a smart allocation of the SI space to assist in loop detection, but it is= the right choice of the underlying transport that is in charge of providin= g transport services e.g. loop detection/prevention. If we take the above = argument one step forward we will need to provide windowing, congestion con= trol, etc. etc. I do not see this as the role of this form of an overlay... > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 PB> Just the opposite, failing to add QoS to the NSH header is blurring the= lines between the service layer and the "transport" layer. Consider an a c= hain which uses both a best effort and an expedited service. Next consider = building the chain where each hop uses a different type of "transport". As = we map from one "transport" to the next we may over some hops have less QoS= information than others. As we continue to the next "transport" we retain = the integrity of the end-to-end communication by regenerating QoS from the = original QoS contained at the service layer a driven down into the "transpo= rt".=20 [UE] this suggest the "service" layer has a role of inter-transport or supe= r-transport. I disagree. It is the NSH notion of "mapping from NSH to the t= ransport", that gives the user the perfect control over these phenomenon. A= user concerned about this, should pick homogenous transport or most suitab= le transports. The cost of providing such assurance in a "service" layer is= duplicating the transport functionality (and even that will not solve the = issue if the underlying transport is lagging...) > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function. PB> In a multi-manager situation I need a way to avoid collision in the all= ocation of the SPI/SI space which is being independently allocated by diffe= rent managers. [UE] same goes to a VXLAN....no such field is present there either. Agree w= PaulQ - this is a Control Plane aspect _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 15 18:35:29 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 919CD12D765 for ; Fri, 15 Apr 2016 18:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 4gRUSw5hpmSJ for ; Fri, 15 Apr 2016 18:35:26 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 15C3312D80D for ; Fri, 15 Apr 2016 18:35:26 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 15 Apr 2016 18:35:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,489,1455004800"; d="scan'208";a="786012386" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga003.jf.intel.com with ESMTP; 15 Apr 2016 18:35:25 -0700 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 15 Apr 2016 18:35:25 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX156.amr.corp.intel.com ([169.254.8.159]) with mapi id 14.03.0248.002; Fri, 15 Apr 2016 18:35:25 -0700 From: "Elzur, Uri" To: Henry Fourie , "Paul Quinn (paulq)" , "Bottorff, Paul" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivflQCYv/wVVMUagOUO32rRCGp+IdPDQgAHOXgCAABLCAIABk7Ig Date: Sat, 16 Apr 2016 01:35:23 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958589365644@ORSMSX114.amr.corp.intel.com> References: <0F8583BBE82FA449A8B78417CC07559A09559A80@SJCEML701-CHM.china.huawei.com> In-Reply-To: <0F8583BBE82FA449A8B78417CC07559A09559A80@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmE5OTQ2MzctOTY0Mi00ZjliLTgxZjktMmVkZmIzNDg3ZjM1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlV0b0pmeUdaMVdWVk8waDNQZ0tPcEF0RWtxelo2WlI2NnVmZTVyZzdXTm89In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 16 Apr 2016 01:35:27 -0000 And what is a symmetric return path is desired? Now that poor SFF need to b= e the traffic cop for the benefit of the downstream SFFs If we assume that the LB/HA are accomplished by control Plane or by means o= ther than direct insert/remove, this is not a common case Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henry Fourie Sent: Thursday, April 14, 2016 11:28 AM To: Paul Quinn (paulq) ; Bottorff, Paul Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul, Updating SFF forwarding entries on all downstream SFFs can introduce dis= ruption of traffic on the service path. It would help if there is a mechani= sm where a chain update to add/remove an SF can be localized to its subtend= ing SFF only. - Louis=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, April 14, 2016 10:21 AM To: Bottorff, Paul Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a=20 > number of deficiencies which lead to transport dependencies and to=20 > layer violations, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 > 2)there is no resolution to forward/reverse addressing necessary for=20 > support of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. > 3)there is no resolution to encoding hierarchies which are of=20 > importance to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. > 4)the draft needs a transport service interface and a description of=20 > the mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function. _______________________________________________ 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 Fri Apr 15 21:49:13 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 3F6AD12E053 for ; Fri, 15 Apr 2016 21:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 kiXryC1wN_kA for ; Fri, 15 Apr 2016 21:49:10 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAA112D5A1 for ; Fri, 15 Apr 2016 21:49:09 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-ec-5711c41be75e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.EC.03614.C14C1175; Sat, 16 Apr 2016 06:48:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Sat, 16 Apr 2016 00:49:08 -0400 From: Gregory Mirsky To: "Elzur, Uri" , Henry Fourie , "Paul Quinn (paulq)" , "Bottorff, Paul" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfQNgeSRwVuekuk7duaTmjRXJ+IzlGAgAFCswCAABLBAIACCdaA///vvDA= Date: Sat, 16 Apr 2016 04:49:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A480B3@eusaamb103.ericsson.se> References: <0F8583BBE82FA449A8B78417CC07559A09559A80@SJCEML701-CHM.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B89958589365644@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958589365644@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXSPt67MEcFwg98vhC0OLLzDZHGibyqL xc6GfkaL/a+Wslo8ebCV3WLSnrNMDmweU35vZPXYtauR3aPlyFtWjyVLfjJ5LN7zksnj3LU+ 5gC2KC6blNSczLLUIn27BK6MH7feMhassKjYdeYXYwPjDt0uRk4OCQETiW27JjBB2GISF+6t Z+ti5OIQEjjKKPF61gtGCGc5o8Tzq1vYQarYBIwkXmzsYQdJiAgsYZT4+KaFFSTBLOAi8WL3 JEYQW1jAVmLegrvMILaIgJ3E4UsTmSBsP4lr7Y/AalgEVCWW71wL1ssr4Ctxc99XFohtJ5kk Fk46BtbMKRAiceX3NBYQmxHovu+n1jBBLBOXuPVkPtTdAhJL9pxnhrBFJV4+/scKYStJzHl9 jRmiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYOUqLC3Jy 040MNzECY++YBJvjDsa9vZ6HGAU4GJV4eBOaBcKFWBPLiitzDzFKcDArifB+2y0YLsSbklhZ lVqUH19UmpNafIhRmoNFSZzXO/JfmJBAemJJanZqakFqEUyWiYNTqoFRNzh11uXSw0e2rb39 uph1t+QyrzU7fJ6pXhSIsje7eKhpzpWtaaFHzs//WbOu0vy1jLfJ2diW/8u//RQ+GKBR3p6T HCL8OfW796dGo0JTntT/d2JkLaXVjR8XvLE79u2VY27/yYX9e0pPLPu4bO6KH8XG/+d7qB++ +Py2V/rKy98qJoldyyvLU2Ipzkg01GIuKk4EAAG5kkq5AgAA Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 16 Apr 2016 04:49:12 -0000 Hi Uri, bi-directional path presumes that the service layer is terminated at egress= and ingress, not that client data circle, that may be characteristic of a = ring or routing loop. And if there's classifier at ingress, then, wouldn't = there be a classifier at egress? If there's no classifier at the turning SF= , then isn't that rather case of unidirectional path that is terminated at = its very ingress? Regards, Greg -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri Sent: Friday, April 15, 2016 6:35 PM To: Henry Fourie; Paul Quinn (paulq); Bottorff, Paul Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt And what is a symmetric return path is desired? Now that poor SFF need to b= e the traffic cop for the benefit of the downstream SFFs If we assume that the LB/HA are accomplished by control Plane or by means o= ther than direct insert/remove, this is not a common case Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henry Fourie Sent: Thursday, April 14, 2016 11:28 AM To: Paul Quinn (paulq) ; Bottorff, Paul Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul, Updating SFF forwarding entries on all downstream SFFs can introduce dis= ruption of traffic on the service path. It would help if there is a mechani= sm where a chain update to add/remove an SF can be localized to its subtend= ing SFF only. - Louis=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, April 14, 2016 10:21 AM To: Bottorff, Paul Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a=20 > number of deficiencies which lead to transport dependencies and to=20 > layer violations, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 > 2)there is no resolution to forward/reverse addressing necessary for=20 > support of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. > 3)there is no resolution to encoding hierarchies which are of=20 > importance to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. > 4)the draft needs a transport service interface and a description of=20 > the mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function. _______________________________________________ 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 Sun Apr 17 00:27: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 AE31612D9E6; Sun, 17 Apr 2016 00:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 Vruwt1fmRWeI; Sun, 17 Apr 2016 00:27:53 -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 625F612D94D; Sun, 17 Apr 2016 00:27:53 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 5E8131802ADA; Sun, 17 Apr 2016 09:27:50 +0200 (CEST) From: Loa Andersson To: "sfc@ietf.org" , draft-ietf-sfc-nsh@ietf.org Message-ID: <57133AED.4080005@pi.nu> Date: Sun, 17 Apr 2016 15:27:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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: Sun, 17 Apr 2016 07:27:55 -0000 Working Group, authors, I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read it before now) and have a question on how the TLV concept is understood in the draft. For example in LDP TLV were defined as Type, Length Value, e.g. (from RFC 5036 section 3.3): LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of the information carried in LDP messages. An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length field, followed by a variable length Value field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated and I'm struggling a bit to understand if the "name" TLV should be used. From draft-ietf-sfc-nsh-04 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Variable Context Headers The draft is not entirely clear in this respect, but I think this is what you call a TLV. Should I understand this way? Type = TLV Class + C + Type (24 bits) Length = len (5 bits) Value = Variable Metadata A convention we used in MPLS when we have variable length fields is to use a ~ instead of the |, like this:. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Variable Metadata ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I suggest that this is a good practice that could be adopted here also. Two more questions: If the metadata does not align exactly with the 32 bit/4 byte structure, what is the rules for padding? A last, but a bit different question, do you need indicators like the U and F flags in an to indicate what should happen if the node does not recognize the (TLV Class, C, Type)-field? /Loa PS I will also have a few more editorial comments that will be sent to the authors within a day or two. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Apr 17 00:48:29 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 F098112DE4E for ; Sun, 17 Apr 2016 00:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 r-GcB8P-CIqm for ; Sun, 17 Apr 2016 00:48:26 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B1012DE3A for ; Sun, 17 Apr 2016 00:48:25 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3H7eG14024563; Sun, 17 Apr 2016 00:48:24 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 22bjrk2685-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Apr 2016 00:48:19 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 17 Apr 2016 10:48:16 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Sun, 17 Apr 2016 10:48:16 +0300 From: David Melman To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivflQCYv/wVVMUagOUO32rRCGp+IdPDQgAR4SKA= Date: Sun, 17 Apr 2016 07:48:16 +0000 Message-ID: <1f074df2928a4050afa7c3c775536574@IL-EXCH01.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-17_05:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604170113 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Sun, 17 Apr 2016 07:48:28 -0000 Hi Thomas: I support last call on draft-ietf-sfc-nsh-04. Regarding MPLS transport, I agree this is not an issue for this draft, whic= h defines NSH as transport independent. NSH-over-MPLS should be addressed= by the MPLS WG, where a solution needs to be found to resolve the nibble i= ssue, e.g. CW-like solution. Regarding MD type 1, 16B opaque context data is a good generic approach. M= etadata will evolve over time and be standardized. David -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Wednesday, March 30, 2016 7:48 PM To: sfc@ietf.org Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear WG: This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datat= racker.ietf.org/doc/draft-ietf-sfc-nsh/). The editors of the NSH document have indicated that they have addressed all= known comments and that there are no open issues with the current version = of the document. Substantive comments to the list please, editorial comments can go directly= to the document editors. We'll also get a brief update from the editors at next week's meeting. If t= here are any remaining issues with the document, raising them before the me= eting would be especially helpful. For the chairs, Thomas _______________________________________________ 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 Sun Apr 17 17:05:23 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 8688112D17B for ; Sun, 17 Apr 2016 17:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 zVG-jbxiJyOM for ; Sun, 17 Apr 2016 17:05:19 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by ietfa.amsl.com (Postfix) with ESMTP id C45EE12D109 for ; Sun, 17 Apr 2016 17:05:19 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 17 Apr 2016 17:05:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,499,1455004800"; d="scan'208";a="86864788" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by fmsmga004.fm.intel.com with ESMTP; 17 Apr 2016 17:05:19 -0700 Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 17 Apr 2016 17:05:17 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX151.amr.corp.intel.com ([169.254.7.222]) with mapi id 14.03.0248.002; Sun, 17 Apr 2016 17:05:17 -0700 From: "Elzur, Uri" To: Gregory Mirsky , Henry Fourie , "Paul Quinn (paulq)" , "Bottorff, Paul" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivflQCYv/wVVMUagOUO32rRCGp+IdPDQgAHOXgCAABLCAIABk7IggACsRICAAkEycA== Date: Mon, 18 Apr 2016 00:05:16 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B899585893677C0@ORSMSX114.amr.corp.intel.com> References: <0F8583BBE82FA449A8B78417CC07559A09559A80@SJCEML701-CHM.china.huawei.com> <7E05C330D7FD6D4FAD0728C46B89958589365644@ORSMSX114.amr.corp.intel.com> <7347100B5761DC41A166AC17F22DF11221A480B3@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A480B3@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGEwODU4M2MtNTM5OS00ZTBhLWI4YWEtZDFjOTcwOWU2Mjc3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlBsYWlWdHprcExzbm9zK2o4RDhJcm5kRWZYNVwvUjYrOUZyZzF2VFwvY2Fzcz0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 18 Apr 2016 00:05:21 -0000 Hi Greg My comment was towards the "inefficiency" stated with the need to update al= l downstream SFF in case of insertion/removal It was suggested that a mechanism where "a localized" mechanism may be bett= er My comment was that in case of any returning traffic (and the graph may be = complex...) the affected SFF will know what to do with any returning traffi= c on any branch of the graph... so it may not be a bad choice to notify all= downstream SFFs The second comment is that in case LB/HA are accomplished by/with control P= lane, the SFF involved in the LB, for example, may hide these actions (or l= ocalize them) rendering this to a more rare event=20 Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Friday, April 15, 2016 9:49 PM To: Elzur, Uri ; Henry Fourie ; Paul Quinn (paulq) ; Bottorff, Paul Cc: Thomas Narten ; sfc@ietf.org Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Uri, bi-directional path presumes that the service layer is terminated at egress= and ingress, not that client data circle, that may be characteristic of a = ring or routing loop. And if there's classifier at ingress, then, wouldn't = there be a classifier at egress? If there's no classifier at the turning SF= , then isn't that rather case of unidirectional path that is terminated at = its very ingress? Regards, Greg -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Elzur, Uri Sent: Friday, April 15, 2016 6:35 PM To: Henry Fourie; Paul Quinn (paulq); Bottorff, Paul Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt And what is a symmetric return path is desired? Now that poor SFF need to b= e the traffic cop for the benefit of the downstream SFFs If we assume that the LB/HA are accomplished by control Plane or by means o= ther than direct insert/remove, this is not a common case Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henry Fourie Sent: Thursday, April 14, 2016 11:28 AM To: Paul Quinn (paulq) ; Bottorff, Paul Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul, Updating SFF forwarding entries on all downstream SFFs can introduce dis= ruption of traffic on the service path. It would help if there is a mechani= sm where a chain update to add/remove an SF can be localized to its subtend= ing SFF only. - Louis=20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, April 14, 2016 10:21 AM To: Bottorff, Paul Cc: Thomas Narten; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B. Some comments inline. > On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrote= : >=20 > Hi Thomas: >=20 > I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing = to close a format before we have clear agreement on the forwarding principl= es and features is just too high. >=20 > The major problems with the current draft are:=20 > 1)the service address formed by the combined SPI+SI appears to have a=20 > number of deficiencies which lead to transport dependencies and to=20 > layer violations, PQ> You draw this broad stoke, however, it is relatively unsubstantiated w= ith technical facts. The WG discussed the representation of the SPI/SI pri= or to NSH adoption. The SPI/SI are not transport values -- and please don'= t conflate transport (and the associated requirements) with address family.= =20 > 2)there is no resolution to forward/reverse addressing necessary for=20 > support of many L4-high service functions, PQ> That is factually incorrect and I think derives from your opinion that = SPI/SI =3D=3D address family: in general, you can create two unidirectional= chains and use them for forward and reverse traffic. This has been review= ed with /by L4+ vendors/experts. > 3)there is no resolution to encoding hierarchies which are of=20 > importance to SFC applications in NFV environments, PQ> Encoding hierarchies is an optimization of the base protocol to support= scaling in a large deployment; in any case such optimization does not requ= ire changes to the base SFC encapsulation. > 4)the draft needs a transport service interface and a description of=20 > the mappings used for the service layer onto the transport layer, PQ> I am not sure what you mean by "transport service interface" - it is tr= ue that the SPI/SI need to map to a transport layer forwarding entry but I = don't know what you are implying. > 5)the draft specifies two independent formats for encoding the NSH header= which is likely to divide the market slowing the deployment of NSH. PQ> The draft actually specifies two metadata formats for flexibility and = the market will decide which is most appropriate based on specific use case= s. The evidence is clear: a wide-range of _implementations_ already exist.= In fact, the real impediment to deployment is esoteric opinion. >=20 >> From my point of view the SFC formed service plane layer network with a = peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI) = forms the address for this service plane. As it stands there is an attempt = to overload the function of the SI as both the SF identifier with the Servi= ce Path and as a form of loop detection, however the coupling has resulted = in two problems:=20 > 1)Since every SF in a path must have a sequential SI, in the event we nee= d to insert or delete a SF it is necessary to update the SFF forwarding ent= ries for the entire chain. To fix this either the SI should be allowed to t= ake non-sequential values along the chain or should not be used for SF addr= essing. PQ> This is not a true statement; if an SF needs to be added or deleted the= n it is necessary to update the SFF forwarding entries for all SFFs downstr= eam of where the change occurs.=20 > 2)Since the SI is only decremented on SF hops it can't guard against a lo= op between SFFs or SCFs, hence SI is not a reliable method for loop squelch= ing. If a TTL is needed it needs to be separated from SI. Given that there = is no clear alternative to TTL for loop squelching at the service layer I b= elieve we do need to include an effective TTL to go forward. PQ> The SI can provide a simple loop check within the serivce plane but it'= s primary semantic value is one of location. The transport itself can prov= ide loop detection as well as SFF verification of SPI/SI + source. =20 > 3)Every other successful address space has needed to add a few bits to su= pport QoS options. I would suggest taking 3-4 bits from the MD-type and to = reserve for QoS handling. PQ> Again, this is blurring the lines: QoS is handled, as expected by the = selection transport. This is a feature, not a bug, architecturally speakin= g. =20 > 4)In may data centers we have multi-vendor deployments. In these environm= ents we may have different managers assigning chains. There should to be so= me convention for splitting the address space between these vendors. The mo= st desirable solution to this is to add an assigned organization ID to the = address space. An alternative would be to separate the SPI into a 4 and 20 = bit field designating the high 4 bits as a local manager ID. >=20 PQ> You are conflating federation/configuration and frame format. The mul= ti-manager scenario is a control-plane/management-plane function. _______________________________________________ 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 Sun Apr 17 19:25:21 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 A92BB12DF5E for ; Sun, 17 Apr 2016 19:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 m3hnOQDVlzx7 for ; Sun, 17 Apr 2016 19:25:17 -0700 (PDT) Received: from COL004-OMC2S5.hotmail.com (col004-omc2s5.hotmail.com [65.55.34.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C373A12DD7E for ; Sun, 17 Apr 2016 19:25:17 -0700 (PDT) Received: from COL402-EAS238 ([65.55.34.72]) by COL004-OMC2S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 17 Apr 2016 19:25:17 -0700 X-TMN: [KDojuPRw94xAC7SQZIvEXh//fe9yhDT3] X-Originating-Email: [dm.ietf@outlook.com] Message-ID: MIME-Version: 1.0 To: "sfc@ietf.org" From: David May Date: Sun, 17 Apr 2016 22:25:12 -0400 Importance: normal X-Priority: 3 Thread-Topic: Content-Type: multipart/alternative; boundary="_2985B387-46A9-4F9A-BCA0-4C3833BB88CF_" X-OriginalArrivalTime: 18 Apr 2016 02:25:17.0041 (UTC) FILETIME=[8BE02610:01D19919] Archived-At: Subject: Re: [sfc] regarding NSH draft last call 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: Mon, 18 Apr 2016 02:25:19 -0000 --_2985B387-46A9-4F9A-BCA0-4C3833BB88CF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I support this draft As an operator, we plan to use a standardized way of classifying and carryi= ng metadata across various transport options and look to use the metadata f= or not only service function chaining, but actual policy enforcement in rel= ation to the transported metadata. Although still much work in other areas= , the draft for NSH is sufficient to meet the intent. =20 -Dave May- -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Wednesday, March 30, 2016 7:48 PM To: sfc@ietf.org Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear WG: This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datat= racker.ietf.org/doc/draft-ietf-sfc-nsh/). The editors of the NSH document have indicated that they have addressed all= known comments and that there are no open issues with the current version = of the document. Substantive comments to the list please, editorial comments can go directly= to the document editors. We'll also get a brief update from the editors at next week's meeting. If t= here are any remaining issues with the document, raising them before the me= eting would be especially helpful. For the chairs, Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_2985B387-46A9-4F9A-BCA0-4C3833BB88CF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I support this draft

 

As an operator, we plan = to use a standardized way of classifying and carrying metadata across vario= us transport options and look to use the metadata for not only service func= tion chaining, but actual policy enforcement in relation to the transported= metadata.=C2=A0 Although still much work in other areas, the draft for NSH= is sufficient to meet the intent.=C2=A0

 

-Dave May-

 

-----Original Message-----
From:= sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten
Sent: Wednesday, March 30, 2016 7:48 PMTo: sfc@ietf.org
Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04= .txt

Dear WG:

This note begins a WG last call on draft-ietf-s= fc-nsh-04.txt (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/).

The = editors of the NSH document have indicated that they have addressed all kno= wn comments and that there are no open issues with the current version of t= he document.

Substantive comments to the list please, editorial comm= ents can go directly to the document editors.

We'll also get a brief= update from the editors at next week's meeting. If there are any remaining= issues with the document, raising them before the meeting would be especia= lly helpful.

For the chairs,
Thomas

______________________= _________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/li= stinfo/sfc


= --_2985B387-46A9-4F9A-BCA0-4C3833BB88CF_-- From nobody Mon Apr 18 04:39: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 3BDCC12B055 for ; Mon, 18 Apr 2016 04:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CUSnPNa4779y for ; Mon, 18 Apr 2016 04:39:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FB312D104 for ; Mon, 18 Apr 2016 04:39:21 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E8A832DC086; Mon, 18 Apr 2016 13:39:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1160235C076; Mon, 18 Apr 2016 13:39:19 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Mon, 18 Apr 2016 13:39:18 +0200 From: To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AdGWYcf4eX5Az/rjTQOEcq50WzDr6QC8LclA Date: Mon, 18 Apr 2016 11:39:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D5BB09OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.18.100316 Archived-At: Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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: Mon, 18 Apr 2016 11:39:24 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D5BB09OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, all, Thank you for raising this point. IANA considerations should be sketched in reference to RFC5226 (see https:/= /tools.ietf.org/html/rfc5226#section-4.1). IMO, it is reasonable to define ranges: =B7 assigned via Standards Action =B7 assigned via Specification Required =B7 reserved for Private Use =B7 reserved for Experimental Use Note that the ranges you are proposing are not aligned with the current TLV= encoding (Type is encoded in 7 bits). Saying that, I still do see value in reusing existing rich registries such = as IPFIX. Doing so allows to use immediately a code point while ensuring in= teroperability. A dedicated field in the encoding of the TLV can be defined= (or adjust TLV Class?) to point to the registry in use. BTW, the IANA section should include more details about "TLV Class". Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : jeudi 14 avril 2016 17:25 =C0 : sfc@ietf.org Objet : [sfc] TLV class of variable-length metadata should have a restricte= d range Regarding the TLV Class of variable-length metadata, https://tools.ietf.org= /html/draft-ietf-sfc-nsh-04#section-3.5.1 It is common for such fields to reserve ranges, allowing for future growth = into unanticipated uses. E.g., off the top of my head, classes 0 to 0x1ff --> types allocated by IETF classes 0x200 to 0x7fff --> allocated by IANA Classes 0x8000 to 0xbfff --> reserved, do not use classes 0xc000 to 0xefff --> locally administered classes 0xf000 to 0xffff --> experimental Or similar? I'm not sure what the best practice for this is. Generally, I'd want to try something experimentally before requesting IANA = allocation for it (experimental), or maybe types are too specific to warrant IANA allocation (locally adminis= tered). Can something like this be added to draft-ietf-sfc-nsh ? David Dolson Senior Software Architect, Sandvine Inc. --_000_787AE7BB302AE849A7480A190F8B933008D5BB09OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave, all,

 

Thank you for raising this poin= t.

 

IANA considerations should be s= ketched in reference to RFC5226 (see https://tools.i= etf.org/html/rfc5226#section-4.1).

 

IMO, it is reasonable to define= ranges:

=B7    &n= bsp;    assigned via Standards = Action

=B7    &n= bsp;    assigned via Specificat= ion Required

=B7    &n= bsp;    reserved for Private Us= e

=B7    &n= bsp;    reserved for Experiment= al Use

 

Note that the ranges you are pr= oposing are not aligned with the current TLV encoding (Type is encoded in 7= bits).

 

Saying that, I still do see val= ue in reusing existing rich registries such as IPFIX. Doing so allows to us= e immediately a code point while ensuring interoperability. A dedicated field in the encoding of the TLV can be defined (or adjust TLV= Class?) to point to the registry in use.

 

BTW, the IANA section should in= clude more details about “TLV Class”.

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : jeudi 14 avril 2016 17:25
=C0 : sfc@ietf.org
Objet : [sfc] TLV class of variable-length metadata should have= a restricted range

 

Regarding the TLV Class of vari= able-length metadata, https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1

It is common for such fields to= reserve ranges, allowing for future growth into unanticipated uses.

 

E.g., off the top of my head,

classes 0 to 0x1ff --> types= allocated by IETF

classes 0x200 to 0x7fff --> = allocated by IANA

Classes 0x8000 to 0xbfff -->= reserved, do not use

classes 0xc000 to 0xefff -->= locally administered

classes 0xf000 to 0xffff -->= experimental

 

Or similar? I’m not sure = what the best practice for this is.

 

Generally, I’d want to tr= y something experimentally before requesting IANA allocation for it (experi= mental),

or maybe types are too specific= to warrant IANA allocation (locally administered).

 

Can something like this be adde= d to draft-ietf-sfc-nsh ?

 

 

David Dolson<= /p>

Senior Software Architect, Sand= vine Inc.

 

--_000_787AE7BB302AE849A7480A190F8B933008D5BB09OPEXCLILMA3corp_-- From nobody Mon Apr 18 07:33:05 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 22BC512E032 for ; Mon, 18 Apr 2016 07:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OMgrFUJ8QZe5 for ; Mon, 18 Apr 2016 07:33:02 -0700 (PDT) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) (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 3A34112E02E for ; Mon, 18 Apr 2016 07:33:02 -0700 (PDT) Received: by mail-qk0-f180.google.com with SMTP id n63so45479910qkf.0 for ; Mon, 18 Apr 2016 07:33:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OnzERlxkl9pPjc4fM9b5o4ndHIuyB13nQqBRidvl4NE=; b=JQrTNnGabRjHabmAfrhmFEuc+895CfD6UbNqK+YwVBNgVreFj1VAczksuP3KwCuCAV gLe8dfAXrUkwWO4ktoUNANQBhfysjvr6cH+tSi7t3bStH7e1kJiWzrII+3J3LTk3riBj TgcJEFvT1YeHytRmqFFn82owKkZMyjfi5QPjVajo8MSiFT0FuvrnYE5SxnDozsyR7e1M kKKN0zct7uk6HJkDc6L7Om5hQTVttdG9gGMRIYRSWn2QcMXAoVQE6Be6htXx6BT0rW7F K6tAcFxiJZwPHiUVOkzKmIne1jEyEajm5Yguw8ndjoZaOEc5vi7H2jRT9oyBW84kwcE1 8oHQ== X-Gm-Message-State: AOPr4FW0cD8wWeJZl68oegRfAXlQpMcNr0IdiACLmMPuJLmY0TmvRy5YX2gUUnQJAF/zKgl5 X-Received: by 10.55.77.206 with SMTP id a197mr44406571qkb.43.1460989981183; Mon, 18 Apr 2016 07:33:01 -0700 (PDT) Received: from wlan-196-77.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id d192sm6328111qkc.24.2016.04.18.07.32.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Apr 2016 07:33:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Azhar Sayeed In-Reply-To: <57133AED.4080005@pi.nu> Date: Mon, 18 Apr 2016 10:33:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> References: <57133AED.4080005@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-sfc-nsh@ietf.org, "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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: Mon, 18 Apr 2016 14:33:04 -0000 Loa, +1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs have the = same structure - This should also be consistent..the question then is = can the current TLV structure in draft-~nsh-04 be re-configured to align = with all the other TLV=E2=80=99s structure?=20 Azhar > On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >=20 > Working Group, authors, >=20 > I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read > it before now) and have a question on how the TLV concept is = understood > in the draft. >=20 > For example in LDP TLV were defined as Type, Length Value, e.g. (from > RFC 5036 section 3.3): >=20 > LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of > the information carried in LDP messages. >=20 > An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify > a Type and 2 bits to specify behavior when an LSR doesn't recognize > the Type, followed by a 2 octet Length field, followed by a variable > length Value field. >=20 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Value | > ~ ~ > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated > and I'm struggling a bit to understand if the "name" TLV should be = used. >=20 > =46rom draft-ietf-sfc-nsh-04 >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Metadata = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Figure 6: Variable Context Headers >=20 > The draft is not entirely clear in this respect, but I think this is = what you call a TLV. >=20 > Should I understand this way? >=20 > Type =3D TLV Class + C + Type (24 bits) > Length =3D len (5 bits) > Value =3D Variable Metadata >=20 > A convention we used in MPLS when we have variable length fields is > to use a ~ instead of the |, like this:. >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Variable Metadata = ~ > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > I suggest that this is a good practice that could be adopted here = also. >=20 > Two more questions: >=20 > If the metadata does not align exactly with the 32 bit/4 byte = structure, > what is the rules for padding? >=20 > A last, but a bit different question, do you need indicators like the = U > and F flags in an to indicate what should happen if the node does not > recognize the (TLV Class, C, Type)-field? >=20 > /Loa >=20 >=20 > PS >=20 > I will also have a few more editorial comments that will be sent to > the authors within a day or two. >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 18 07:58:44 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 00D8D12DD16; Mon, 18 Apr 2016 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 qD1sZDltoRGe; Mon, 18 Apr 2016 07:58:40 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 443B912DCF0; Mon, 18 Apr 2016 07:58:40 -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.0195.001; Mon, 18 Apr 2016 10:58:38 -0400 From: Dave Dolson To: Loa Andersson , "sfc@ietf.org" , "draft-ietf-sfc-nsh@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqs0gacCRpZF0y3tTXhX+Qh65+P0xzw Date: Mon, 18 Apr 2016 14:58:38 +0000 Message-ID: References: <57133AED.4080005@pi.nu> In-Reply-To: <57133AED.4080005@pi.nu> 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 last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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: Mon, 18 Apr 2016 14:58:43 -0000 On the point of rules for padding, I raised this some time ago (first bullet in https://mailarchive.ietf.org/arch/msg/sfc/Ag5JBto2inEbAuYI= nyUh2kK3VYg) It would be more useful to have length specified in bytes, with padding to = 4-byte alignment. Otherwise, I guess variable metadata must have a second length field within= it? -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Sunday, April 17, 2016 3:28 AM To: sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TL= Vs in draft-ietf-sfc-nsh Working Group, authors, I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read it before now) and have a question on how the TLV concept is understood in the draft. For example in LDP TLV were defined as Type, Length Value, e.g. (from RFC 5036 section 3.3): LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of the information carried in LDP messages. An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length field, followed by a variable length Value field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated and I'm struggling a bit to understand if the "name" TLV should be used. From draft-ietf-sfc-nsh-04 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Variable Context Headers The draft is not entirely clear in this respect, but I think this is=20 what you call a TLV. Should I understand this way? Type =3D TLV Class + C + Type (24 bits) Length =3D len (5 bits) Value =3D Variable Metadata A convention we used in MPLS when we have variable length fields is to use a ~ instead of the |, like this:. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Variable Metadata ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I suggest that this is a good practice that could be adopted here also. Two more questions: If the metadata does not align exactly with the 32 bit/4 byte structure, what is the rules for padding? A last, but a bit different question, do you need indicators like the U and F flags in an to indicate what should happen if the node does not recognize the (TLV Class, C, Type)-field? /Loa PS I will also have a few more editorial comments that will be sent to the authors within a day or two. --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 18 08:21:06 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 9598A12D98D for ; Mon, 18 Apr 2016 08:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 A5ik34W-4vag for ; Mon, 18 Apr 2016 08:21:02 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8E27A12D9AB for ; Mon, 18 Apr 2016 08:21:02 -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.0195.001; Mon, 18 Apr 2016 11:21:01 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRmWb0PGjqacyz9EidOrx7rW39tJ+P1pwA Date: Mon, 18 Apr 2016 15:21:00 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5BB09@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F2A80Bwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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: Mon, 18 Apr 2016 15:21:04 -0000 --_000_E8355113905631478EFF04F5AA706E9830F2A80Bwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Med, I was discussing the "TLV Class" field, which is 16 bits. But thank you for finding the BCP for writing IANA considerations. -Dave From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, April 18, 2016 7:39 AM To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] TLV class of variable-length metadata should have a rest= ricted range Hi Dave, all, Thank you for raising this point. IANA considerations should be sketched in reference to RFC5226 (see https:/= /tools.ietf.org/html/rfc5226#section-4.1). IMO, it is reasonable to define ranges: =B7 assigned via Standards Action =B7 assigned via Specification Required =B7 reserved for Private Use =B7 reserved for Experimental Use Note that the ranges you are proposing are not aligned with the current TLV= encoding (Type is encoded in 7 bits). Saying that, I still do see value in reusing existing rich registries such = as IPFIX. Doing so allows to use immediately a code point while ensuring in= teroperability. A dedicated field in the encoding of the TLV can be defined= (or adjust TLV Class?) to point to the registry in use. BTW, the IANA section should include more details about "TLV Class". Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : jeudi 14 avril 2016 17:25 =C0 : sfc@ietf.org Objet : [sfc] TLV class of variable-length metadata should have a restricte= d range Regarding the TLV Class of variable-length metadata, https://tools.ietf.org= /html/draft-ietf-sfc-nsh-04#section-3.5.1 It is common for such fields to reserve ranges, allowing for future growth = into unanticipated uses. E.g., off the top of my head, classes 0 to 0x1ff --> types allocated by IETF classes 0x200 to 0x7fff --> allocated by IANA Classes 0x8000 to 0xbfff --> reserved, do not use classes 0xc000 to 0xefff --> locally administered classes 0xf000 to 0xffff --> experimental Or similar? I'm not sure what the best practice for this is. Generally, I'd want to try something experimentally before requesting IANA = allocation for it (experimental), or maybe types are too specific to warrant IANA allocation (locally adminis= tered). Can something like this be added to draft-ietf-sfc-nsh ? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F2A80Bwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Med,=

I was discussing the &= #8220;TLV Class” field, which is 16 bits.

 

But thank you for find= ing the BCP for writing IANA considerations.

 

 

 

-Dave

 

 

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, April 18, 2016 7:39 AM
To: Dave Dolson; sfc@ietf.org
Subject: RE: [sfc] TLV class of variable-length metadata should have= a restricted range

 

Hi Dave, all,

 

Thank you for raising this point.

 

IANA considerations should be sketched in refe= rence to RFC5226 (see https://tools.i= etf.org/html/rfc5226#section-4.1).

 

IMO, it is reasonable to define ranges:

=B7       =   assigned via Standards Action

=B7       =   assigned via Specification Required

=B7       =   reserved for Private Use

=B7       =   reserved for Experimental Use

 

Note that the ranges you are proposing are not= aligned with the current TLV encoding (Type is encoded in 7 bits).

 

Saying that, I still do see value in reusing e= xisting rich registries such as IPFIX. Doing so allows to use immediately a= code point while ensuring interoperability. A dedicated field in the encoding of the TLV can be defined (or adjust TLV C= lass?) to point to the registry in use.

 

BTW, the IANA section should include more deta= ils about “TLV Class”.

 

Cheers,

Med

 

De : sfc [mailto:sfc= -bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : jeudi 14 avril 2016 17:25
=C0 : sfc@ietf.org
Objet : [sfc] TLV class of variable-length metadata should have= a restricted range

 

Regarding the TLV Class of variable-length metadata,= https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1

It is common for such fields to reserve ranges, allo= wing for future growth into unanticipated uses.

 

E.g., off the top of my head,

classes 0 to 0x1ff --> types allocated by IETF

classes 0x200 to 0x7fff --> allocated by IANA

Classes 0x8000 to 0xbfff --> reserved, do not use=

classes 0xc000 to 0xefff --> locally administered=

classes 0xf000 to 0xffff --> experimental

 

Or similar? I’m not sure what the best practic= e for this is.

 

Generally, I’d want to try something experimen= tally before requesting IANA allocation for it (experimental),

or maybe types are too specific to warrant IANA allo= cation (locally administered).

 

Can something like this be added to draft-ietf-sfc-n= sh ?

 

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830F2A80Bwtlexchp2sandvi_-- From nobody Mon Apr 18 11:04:42 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 8D0EF12E457 for ; Mon, 18 Apr 2016 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-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 4O55M27Dv1WH for ; Mon, 18 Apr 2016 11:04:38 -0700 (PDT) Received: from g1t5424.austin.hp.com (g1t5424.austin.hp.com [15.216.225.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D9D12E456 for ; Mon, 18 Apr 2016 11:04:37 -0700 (PDT) Received: from G1W8108.americas.hpqcorp.net (g1w8108.austin.hp.com [16.193.72.60]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by g1t5424.austin.hp.com (Postfix) with ESMTPS id 7F2A85B; Mon, 18 Apr 2016 18:04:35 +0000 (UTC) Received: from G9W8456.americas.hpqcorp.net (16.216.161.95) by G1W8108.americas.hpqcorp.net (16.193.72.60) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 18 Apr 2016 18:04:25 +0000 Received: from G9W8456.americas.hpqcorp.net (2002:10df:2d9::10df:2d9) by G9W8456.americas.hpqcorp.net (2002:10df:2d9::10df:2d9) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 18 Apr 2016 18:04:25 +0000 Received: from G9W3616.americas.hpqcorp.net (16.216.186.51) by G9W8456.americas.hpqcorp.net (16.216.161.95) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Mon, 18 Apr 2016 18:04:25 +0000 Received: from G4W3293.americas.hpqcorp.net ([169.254.2.173]) by G9W3616.americas.hpqcorp.net ([16.216.186.51]) with mapi id 14.03.0169.001; Mon, 18 Apr 2016 18:04:22 +0000 From: "Fedyk, Don" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfQ9ZjlrPWHUEW4Ok49bydgVZ+IUfhwgAAV1QCAAAB/UIAAAnuAgAACFbCAAB+GAIAGmV1Q Date: Mon, 18 Apr 2016 18:04:21 +0000 Message-ID: References: <570EA4EE.8040203@joelhalpern.com> <570EA76D.8080000@joelhalpern.com> <570EC39E.6050201@joelhalpern.com> In-Reply-To: <570EC39E.6050201@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 18 Apr 2016 18:04:40 -0000 Hi Joel > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, April 13, 2016 6:10 PM > To: Fedyk, Don ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 =20 > So the question I have is what wording in the NSH draft causes you concer= n. > Is there wording in the NSH draft that gives the impression that the SPI = / SI is > only an "identifier"? Is there wording that we could add that would help= ? [Don] - Since you bring it up: Short answer yes when you get to section 7.= 4 Figure 14.=20 The wording around service forwarding is a bit disconnected spread over a f= ew sections as I understand it there are 3 modes of forwarding operations i= nvolving SFFs and SFs that I can see. It was initially discussions on the l= ist about identifiers that made me look more deeply at the forwarding. I'= ll keep my comments to service forwarding even though these sections also d= iscuss the mapping to transport I'll focus on SPI and SI handling text.=20 Also note there are two occurrences of SPI/ID and 4 occurrences of SPI/SI w= hich I assume are both Service Path Identifier and Service Index. ID is ne= ver defined but SI is equated to node ID or location. I think SPI/ID is a = typo. With respect to SF and SFF service forwarding=20 Section 4 and Sections 7.1 - 7.3=20 1) SF NSH Aware using SI decrement. The SFF sends to an SF that does its = thing, and has access to any metadata and passes the packet back (to the sa= me SFF) with a decremented SI. The SFF then looks up the next hop based o= n the SPI/SI that maps to another SF optionally via a Network transport map= ping. =20 2) SF NSH Unaware - A proxy does the decrementing of the SI.=20 Observation: The decrementing of SI keeps the forwarding through an SF to = a simplistic form. The text describing this mode implies SF tracking using = SI and uses a programmed lookup of the next SPI/SI.=20 Note: The text about decrementing to zero seems unnecessary given that any = SFF that receives an SPI with any SI value that is unexpected is a forwardi= ng mistake. Zero is just a specific example of the general case of chain = programming where SPI/SI must make sense at each hop. SI of zero does not m= ake sense but neither do any other values of SI that are not programmed for= that SPI/SI combination. =20 We have always assumed that a control plane/management plane are used to se= tup/verify chains and some form of OAM should be used to verify chains.=20 Since the simplistic form does not allow the more complex chains, in Sectio= n 7.4 you have the third mode.=20 3) SF NSH Aware with reclassification - This mode allows an SF to do anythi= ng to SPI/SI - not specified exactly what, just that reclassification is al= lowed and presumably SPI and or SI can be changed/reset. One might imply = from reading and figure 14 that this is based on "identifier" (SPI ) lookup= and context (or Class) in this example. It seems to follow that SFs are l= ess concerned with SI actual values. This sections implies SPI can be chan= ged and does not describe what happens to SI. Presumably the SI is set to s= ome "new' value since an initial classifier would not know what SI should b= e for all combinations of chains so SI is location only with respect to a = specific SPI.=20 Is it true that SI is not consulted when reclassification takes place? =20 Cheers Don=20 >=20 > Thanks, > Joel >=20 > On 4/13/16 4:39 PM, Fedyk, Don wrote: > > Joel > > > > I think that > > https://tools.ietf.org/html/draft-kumar-sfc-nsh-forwarding-00 > > clarifies Service Forwarding (along the chain) versus Packet > > forwarding (elsewhere). But this draft points out that the NSH > > draft is "confusing" with respect to some parts of service > > forwarding. And when I and others have asked on the list about > > subtleties of Service forwarding behaviors and the relationship of > > chain ID with various packet formats; the answers were NSH SID and SI > > were just identifiers. So while there is not a statement they are > > non-forwarding identifiers the confusion still exists because the > > behavior is not clear. I still think NSH SID and SI behave as an > > address space - receive a packet; lookup the address; if recognized > > process; then place the next hop address (includes not modifying the > > address in some cases) on the packet and forward on. If the fields > > don't match expected values; drop or exception process. > > > > Cheers Don > > > > > >> -----Original Message----- From: Joel M. Halpern > >> [mailto:jmh@joelhalpern.com] Sent: Wednesday, April 13, 2016 4:09 PM > >> To: Fedyk, Don ; Thomas Narten > >> ; sfc@ietf.org Subject: Re: [sfc] WG last call for > >> draft-ietf-sfc-nsh-04.txt > >> > >> Given that the draft describes how to use the SFP ID and Index for > >> forwarding, it would seem very strange to argue that it does not > >> describe a forwarding behavior, or that those fields are not for use > >> by forwarding. It is not REQUIRED that they be used for forwarding > >> at an SFF, but it is certainly permitted. > >> > >> Is there wording in the draft that says that these are non-forwarding > >> identifiers? If so, we really should fix that. > >> > >> Yours, Joel > >> > >> On 4/13/16 4:05 PM, Fedyk, Don wrote: > >>> Hi Joel > >>> > >>> The argument has been put forward that NSH is only carrying > >>> identifiers. When I look at NSH service forwarding that I know I > >>> disagree with that statement. I think that NSH SID + SI is an > >>> address space and hence is not completely independent of forwarding. > >>> The only way I can reason it out is to see other examples of > >>> complete packet headers and operations per hop. > >>> There has been a lot of hand waving. > >>> > >>> Cheers Don > >>> > >>>> -----Original Message----- From: Joel M. Halpern > >>>> [mailto:jmh@joelhalpern.com] Sent: Wednesday, April 13, 2016 > >>>> 3:59 PM To: Fedyk, Don ; Thomas Narten > >>>> ; sfc@ietf.org Subject: Re: [sfc] WG last call > >>>> for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> I am having trouble following your argument about forwarding in > >>>> this email. > >>>> > >>>> Yes, transports can carry forwarding information. The SFC > >>>> archtiecture allows it. that does not make including service paht > >>>> identification in ht NSH header either redundant or incorrect. > >>>> > >>>> I do not know what you mean by needing more examples of the > >>>> forwarding. The draft itself describes how the NSH header SFP ID > >>>> and index can be used for the SFF forwarding decision. That > >>>> description seems quite clear to me. If there is ambiguity or > >>>> unclarity, please let the WG know, so we can improve it. > >>>> > >>>> Yours, Joel > >>>> > >>>> On 4/13/16 3:05 PM, Fedyk, Don wrote: > >>>>> Hi Thomas > >>>>> > >>>>> At this point I do not support a last call on the NSH header. > >>>>> There is a lot of > >>>> comments and I don't think it is at a point where it is last call > >>>> ready. > >>>>> > >>>>> I have be banging my head against the wall on this one because I > >>>>> would like > >>>> more concrete around the forwarding aspects. I do accept that > >>>> there is a draft (draft-kumar-sfc-nsh-forwarding-00 ) now that > >>>> addresses some the confusion in NSH on forwarding and it helps. > >>>> Although it seems odd to let a NSH draft progress as confusing and > >>>> to clarify it later in another draft. > >>>>> > >>>>> My main objection is related to the fact that for a draft that > >>>>> claims it is > >>>> independent of forwarding it simply has not been proven. That does > >>>> not mean we need to specify forwarding but I'd still like to see > >>>> the data formats of what are being "prototyped" today so I can > >>>> compare with the other data formats that I know today. > >>>> For example the MAC chaining draft we authored would like to use > >>>> NSH for metadata but the MAC chaining local MACs bear a > >>>> relationship with the NSH SDI & SI. In fact without these fields as > >>>> mandatory it would be more independent in my case. > >>>> I'm sure there are similar aspects with other transports types but > >>>> until I see them and the operations I can't assess transport > >>>> independence claims. > >>>>> > >>>>> There are other inconsistencies that I could live with in the > >>>>> draft relating to > >>>> the logic of the MD types etc. (A length field seems to be the only > >>>> thing that is really needed and local context will determine the > >>>> contents). But we have made these comments more than once and > I've > >>>> seen little acknowledgment that if the NSH data is basically > >>>> context driven fixed fields and TLVs could be mixed. > >>>>> > >>>>> So in short I support of the drafts goals as a way to carry > >>>>> metadata but it is > >>>> not ready for last call yet in my opinion. > >>>>> > >>>>> Thanks Don > >>>>> > >>>>>> -----Original Message----- From: sfc > >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten > >>>>>> Sent: Wednesday, March 30, 2016 10:48 PM To: sfc@ietf.org > >>>>>> Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Dear WG: > >>>>>> > >>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > >>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>>> > >>>>>> The editors of the NSH document have indicated that they have > >>>>>> addressed all known comments and that there are no open issues > >>>>>> with the current version of the document. > >>>>>> > >>>>>> Substantive comments to the list please, editorial comments can > >>>>>> go directly to the document editors. > >>>>>> > >>>>>> We'll also get a brief update from the editors at next week's > >>>>>> meeting. If there are any remaining issues with the document, > >>>>>> raising them before the meeting would be especially helpful. > >>>>>> > >>>>>> For the chairs, Thomas > >>>>>> > >>>>>> _______________________________________________ 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 Mon Apr 18 11:25: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 8408512E4F7 for ; Mon, 18 Apr 2016 11:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 kJPeFmrixq7V for ; Mon, 18 Apr 2016 11:25:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C91512E4F6 for ; Mon, 18 Apr 2016 11:25:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5F1C8240996; Mon, 18 Apr 2016 11:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461003903; bh=74Q7/Aa8tF3EdWiy/xMR9Lw7NfJNxq+mRAI6/wS6UEA=; h=Date:Subject:From:To:From; b=Z4Wl+1UeJUJuT2zbz+TKIEpAVp1419KiJWm4p7LqXAThLVOIzpFhFSeZIhEvQLUkI fax9u/4QziILnxyK9XN7OlZrsuoYBiKD81qBua/2Cpz5kVA1DpCmijXDyogdLaTCo3 2qFl8JgbfA43amS1m0XlnN0ojVW3knU7BbVYTJJU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.97.251.27] (unknown [166.170.32.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D3F7F240828; Mon, 18 Apr 2016 11:25:00 -0700 (PDT) Date: Mon, 18 Apr 2016 14:24:57 -0400 Message-ID: Importance: normal From: "jmh.direct" To: "Fedyk, Don" , "Joel M. Halpern" , "sfc@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_5635133258029360" Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 18 Apr 2016 18:25:06 -0000 ----_com.samsung.android.email_5635133258029360 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB3aWxsIGhhdmUgdG8gbG9vayBtb3JlIGNsb3NlbHkgYXQgeW91ciBjb21tZW50cyBvdmVyIGFs bC4KUmVnYXJkaW5nIHJlY2xhc3NpZmljYXRpb24sIGNsYXNzaWZpZXJzIGNhbiBsb29rIGF0IGFu eSB0aGluZyB0aGV5IHdhbnQuIMKgTG9va2luZyBhdCBTSUQgd291bGQgc2VlbSB2ZXJ5IHJhcmUs IGJ1dCBub3QgaW1wb3NzaWJsZS4KWW91cnMsSm9lbAoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2Fs YXh5IFPCriA2LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLUZyb206ICJGZWR5aywgRG9uIiA8ZG9uLmZlZHlrQGhwZS5jb20+IERhdGU6 IDQvMTgvMjAxNiAgMjowNCBQTSAgKEdNVC0wNTowMCkgVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxq bWhAam9lbGhhbHBlcm4uY29tPiwgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJFOiBbc2ZjXSBXRyBs YXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQgCkhpIEpvZWwKCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tXQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMsIDIwMTYgNjoxMCBQ TQo+IFRvOiBGZWR5aywgRG9uIDxkb24uZmVkeWtAaHBlLmNvbT47IHNmY0BpZXRmLm9yZwo+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50 eHQKPiAKPFNuaXA+wqAgCj4gU28gdGhlIHF1ZXN0aW9uIEkgaGF2ZSBpcyB3aGF0IHdvcmRpbmcg aW4gdGhlIE5TSCBkcmFmdCBjYXVzZXMgeW91IGNvbmNlcm4uCj4gSXMgdGhlcmUgd29yZGluZyBp biB0aGUgTlNIIGRyYWZ0IHRoYXQgZ2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgU1BJIC8g U0kgaXMKPiBvbmx5IGFuICJpZGVudGlmaWVyIj/CoCBJcyB0aGVyZSB3b3JkaW5nIHRoYXQgd2Ug Y291bGQgYWRkIHRoYXQgd291bGQgaGVscD8KW0Rvbl3CoCAtIFNpbmNlIHlvdSBicmluZyBpdCB1 cDogU2hvcnQgYW5zd2VyIHllcyB3aGVuIHlvdSBnZXQgdG8gc2VjdGlvbiA3LjQgRmlndXJlIDE0 LiAKClRoZSB3b3JkaW5nIGFyb3VuZCBzZXJ2aWNlIGZvcndhcmRpbmcgaXMgYSBiaXQgZGlzY29u bmVjdGVkIHNwcmVhZCBvdmVyIGEgZmV3IHNlY3Rpb25zIGFzIEkgdW5kZXJzdGFuZCBpdCB0aGVy ZSBhcmUgMyBtb2RlcyBvZiBmb3J3YXJkaW5nIG9wZXJhdGlvbnMgaW52b2x2aW5nIFNGRnMgYW5k IFNGcyB0aGF0IEkgY2FuIHNlZS4gSXQgd2FzIGluaXRpYWxseSBkaXNjdXNzaW9ucyBvbiB0aGUg bGlzdCBhYm91dCBpZGVudGlmaWVycyB0aGF0IG1hZGUgbWUgbG9vayBtb3JlIGRlZXBseSBhdCB0 aGUgZm9yd2FyZGluZy7CoMKgIEknbGwga2VlcCBteSBjb21tZW50cyB0byBzZXJ2aWNlIGZvcndh cmRpbmcgZXZlbiB0aG91Z2ggdGhlc2Ugc2VjdGlvbnMgYWxzbyBkaXNjdXNzIHRoZSBtYXBwaW5n IHRvIHRyYW5zcG9ydCBJJ2xsIGZvY3VzIG9uIFNQSSBhbmQgU0kgaGFuZGxpbmcgdGV4dC4gCgpB bHNvIG5vdGUgdGhlcmUgYXJlIHR3byBvY2N1cnJlbmNlcyBvZiBTUEkvSUQgYW5kIDQgb2NjdXJy ZW5jZXMgb2YgU1BJL1NJIHdoaWNoIEkgYXNzdW1lIGFyZSBib3RoIFNlcnZpY2UgUGF0aCBJZGVu dGlmaWVyIGFuZCBTZXJ2aWNlIEluZGV4LsKgIElEIGlzIG5ldmVyIGRlZmluZWQgYnV0IFNJIGlz IGVxdWF0ZWQgdG8gbm9kZSBJRCBvciBsb2NhdGlvbi7CoCBJIHRoaW5rIFNQSS9JRCBpcyBhIHR5 cG8uCgpXaXRoIHJlc3BlY3QgdG8gU0YgYW5kIFNGRiBzZXJ2aWNlIGZvcndhcmRpbmcgClNlY3Rp b24gNCBhbmQgU2VjdGlvbnMgNy4xIC0gNy4zIAoxKSBTRiBOU0ggQXdhcmUgdXNpbmcgU0kgZGVj cmVtZW50LsKgwqAgVGhlIFNGRiBzZW5kcyB0byBhbiBTRiB0aGF0IGRvZXMgaXRzIHRoaW5nLCBh bmQgaGFzIGFjY2VzcyB0byBhbnkgbWV0YWRhdGEgYW5kIHBhc3NlcyB0aGUgcGFja2V0IGJhY2sg KHRvIHRoZSBzYW1lIFNGRikgd2l0aCBhIGRlY3JlbWVudGVkIFNJLsKgwqAgVGhlIFNGRiB0aGVu IGxvb2tzIHVwIHRoZSBuZXh0IGhvcCBiYXNlZCBvbiB0aGUgU1BJL1NJIHRoYXQgbWFwcyB0byBh bm90aGVyIFNGIG9wdGlvbmFsbHkgdmlhIGEgTmV0d29yayB0cmFuc3BvcnQgbWFwcGluZy7CoCAK MikgU0YgTlNIIFVuYXdhcmUgLSBBIHByb3h5IGRvZXMgdGhlIGRlY3JlbWVudGluZyBvZiB0aGUg U0kuIAoKT2JzZXJ2YXRpb246wqAgVGhlIGRlY3JlbWVudGluZyBvZiBTSSBrZWVwcyB0aGUgZm9y d2FyZGluZyB0aHJvdWdoIGFuIFNGIHRvIGEgc2ltcGxpc3RpYyBmb3JtLiBUaGUgdGV4dCBkZXNj cmliaW5nIHRoaXMgbW9kZSBpbXBsaWVzIFNGIHRyYWNraW5nIHVzaW5nIFNJIGFuZCB1c2VzIGEg cHJvZ3JhbW1lZCBsb29rdXAgb2YgdGhlIG5leHQgU1BJL1NJLiAKCk5vdGU6IFRoZSB0ZXh0IGFi b3V0IGRlY3JlbWVudGluZyB0byB6ZXJvIHNlZW1zIHVubmVjZXNzYXJ5IGdpdmVuIHRoYXQgYW55 IFNGRiB0aGF0IHJlY2VpdmVzIGFuIFNQSSB3aXRoIGFueSBTSSB2YWx1ZSB0aGF0IGlzIHVuZXhw ZWN0ZWQgaXMgYSBmb3J3YXJkaW5nIG1pc3Rha2UuwqDCoCBaZXJvIGlzIGp1c3QgYSBzcGVjaWZp YyBleGFtcGxlIG9mIHRoZSBnZW5lcmFsIGNhc2Ugb2YgY2hhaW4gcHJvZ3JhbW1pbmcgd2hlcmUg U1BJL1NJIG11c3QgbWFrZSBzZW5zZSBhdCBlYWNoIGhvcC4gU0kgb2YgemVybyBkb2VzIG5vdCBt YWtlIHNlbnNlIGJ1dCBuZWl0aGVyIGRvIGFueSBvdGhlciB2YWx1ZXMgb2YgU0kgdGhhdCBhcmUg bm90IHByb2dyYW1tZWQgZm9yIHRoYXQgU1BJL1NJIGNvbWJpbmF0aW9uLsKgwqAgCldlIGhhdmUg YWx3YXlzIGFzc3VtZWQgdGhhdCBhIGNvbnRyb2wgcGxhbmUvbWFuYWdlbWVudCBwbGFuZSBhcmUg dXNlZCB0byBzZXR1cC92ZXJpZnkgY2hhaW5zIGFuZCBzb21lIGZvcm0gb2YgT0FNIHNob3VsZCBi ZSB1c2VkIHRvIHZlcmlmeSBjaGFpbnMuIAoKU2luY2UgdGhlIHNpbXBsaXN0aWMgZm9ybSBkb2Vz IG5vdCBhbGxvdyB0aGUgbW9yZSBjb21wbGV4IGNoYWlucywgaW4gU2VjdGlvbiA3LjQgeW91IGhh dmUgdGhlIHRoaXJkIG1vZGUuIAozKSBTRiBOU0ggQXdhcmUgd2l0aCByZWNsYXNzaWZpY2F0aW9u IC0gVGhpcyBtb2RlIGFsbG93cyBhbiBTRiB0byBkbyBhbnl0aGluZyB0byBTUEkvU0kgLSBub3Qg c3BlY2lmaWVkIGV4YWN0bHkgd2hhdCwganVzdCB0aGF0IHJlY2xhc3NpZmljYXRpb24gaXMgYWxs b3dlZCBhbmQgcHJlc3VtYWJseSBTUEkgYW5kIG9yIFNJIGNhbiBiZSBjaGFuZ2VkL3Jlc2V0LsKg wqAgT25lIG1pZ2h0IGltcGx5IGZyb20gcmVhZGluZyBhbmQgZmlndXJlIDE0IHRoYXQgdGhpcyBp cyBiYXNlZCBvbiAiaWRlbnRpZmllciIgKFNQSSApIGxvb2t1cCBhbmQgY29udGV4dCAob3IgQ2xh c3MpIGluIHRoaXMgZXhhbXBsZS7CoCBJdCBzZWVtcyB0byBmb2xsb3cgdGhhdCBTRnMgYXJlIGxl c3MgY29uY2VybmVkIHdpdGggU0kgYWN0dWFsIHZhbHVlcy7CoCBUaGlzIHNlY3Rpb25zIGltcGxp ZXMgU1BJIGNhbiBiZSBjaGFuZ2VkIGFuZCBkb2VzIG5vdCBkZXNjcmliZSB3aGF0IGhhcHBlbnMg dG8gU0kuIFByZXN1bWFibHkgdGhlIFNJIGlzIHNldCB0byBzb21lICJuZXcnIHZhbHVlIHNpbmNl IGFuIGluaXRpYWwgY2xhc3NpZmllciB3b3VsZCBub3Qga25vdyB3aGF0IFNJIHNob3VsZCBiZSBm b3IgYWxsIGNvbWJpbmF0aW9ucyBvZiBjaGFpbnMgc28gU0kgaXPCoCBsb2NhdGlvbiBvbmx5IHdp dGggcmVzcGVjdCB0byBhIHNwZWNpZmljIFNQSS4gCgpJcyBpdCB0cnVlIHRoYXQgU0kgaXMgbm90 IGNvbnN1bHRlZCB3aGVuIHJlY2xhc3NpZmljYXRpb24gdGFrZXMgcGxhY2U/wqDCoCAKCkNoZWVy cwpEb24gCgo+IAo+IFRoYW5rcywKPiBKb2VsCj4gCj4gT24gNC8xMy8xNiA0OjM5IFBNLCBGZWR5 aywgRG9uIHdyb3RlOgo+ID4gSm9lbAo+ID4KPiA+IEkgdGhpbmsgdGhhdAo+ID4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt1bWFyLXNmYy1uc2gtZm9yd2FyZGluZy0wMAo+ID4g Y2xhcmlmaWVzIFNlcnZpY2UgRm9yd2FyZGluZyAoYWxvbmcgdGhlIGNoYWluKSB2ZXJzdXMgUGFj a2V0Cj4gPiBmb3J3YXJkaW5nIChlbHNld2hlcmUpLsKgwqDCoCBCdXQgdGhpcyBkcmFmdCBwb2lu dHMgb3V0IHRoYXQgdGhlIE5TSAo+ID4gZHJhZnQgaXMgImNvbmZ1c2luZyIgd2l0aCByZXNwZWN0 IHRvIHNvbWUgcGFydHMgb2Ygc2VydmljZQo+ID4gZm9yd2FyZGluZy7CoMKgIEFuZCB3aGVuIEkg YW5kIG90aGVycyBoYXZlIGFza2VkIG9uIHRoZSBsaXN0IGFib3V0Cj4gPiBzdWJ0bGV0aWVzIG9m IFNlcnZpY2UgZm9yd2FyZGluZ8KgIGJlaGF2aW9ycyBhbmQgdGhlIHJlbGF0aW9uc2hpcCBvZgo+ ID4gY2hhaW4gSUQgd2l0aCB2YXJpb3VzIHBhY2tldCBmb3JtYXRzO8KgIHRoZSBhbnN3ZXJzIHdl cmUgTlNIIFNJRCBhbmQgU0kKPiA+IHdlcmUganVzdCBpZGVudGlmaWVycy7CoCBTbyB3aGlsZSB0 aGVyZSBpcyBub3QgYSBzdGF0ZW1lbnQgdGhleSBhcmUKPiA+IG5vbi1mb3J3YXJkaW5nIGlkZW50 aWZpZXJzIHRoZSBjb25mdXNpb24gc3RpbGwgZXhpc3RzIGJlY2F1c2UgdGhlCj4gPiBiZWhhdmlv ciBpcyBub3QgY2xlYXIuIEkgc3RpbGwgdGhpbmsgTlNIIFNJRCBhbmQgU0nCoCBiZWhhdmUgYXMg YW4KPiA+IGFkZHJlc3Mgc3BhY2UgLSByZWNlaXZlIGEgcGFja2V0OyBsb29rdXAgdGhlIGFkZHJl c3M7IGlmIHJlY29nbml6ZWQKPiA+IHByb2Nlc3M7IHRoZW4gcGxhY2UgdGhlIG5leHQgaG9wIGFk ZHJlc3MgKGluY2x1ZGVzIG5vdCBtb2RpZnlpbmcgdGhlCj4gPiBhZGRyZXNzIGluIHNvbWUgY2Fz ZXMpIG9uIHRoZSBwYWNrZXQgYW5kIGZvcndhcmQgb24uwqAgSWYgdGhlIGZpZWxkcwo+ID4gZG9u J3QgbWF0Y2ggZXhwZWN0ZWQgdmFsdWVzO8KgIGRyb3Agb3IgZXhjZXB0aW9uIHByb2Nlc3MuCj4g Pgo+ID4gQ2hlZXJzIERvbgo+ID4KPiA+Cj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0g RnJvbTogSm9lbCBNLiBIYWxwZXJuCj4gPj4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDEzLCAyMDE2IDQ6MDkgUE0KPiA+PiBUbzogRmVkeWssIERv biA8ZG9uLmZlZHlrQGhwZS5jb20+OyBUaG9tYXMgTmFydGVuCj4gPj4gPG5hcnRlbkB1cy5pYm0u Y29tPjsgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yCj4g Pj4gZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dAo+ID4+Cj4gPj4gR2l2ZW4gdGhhdCB0aGUgZHJh ZnQgZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhlIFNGUCBJRCBhbmQgSW5kZXggZm9yCj4gPj4gZm9y d2FyZGluZywgaXQgd291bGQgc2VlbSB2ZXJ5IHN0cmFuZ2UgdG8gYXJndWUgdGhhdCBpdCBkb2Vz IG5vdAo+ID4+IGRlc2NyaWJlIGEgZm9yd2FyZGluZyBiZWhhdmlvciwgb3IgdGhhdCB0aG9zZSBm aWVsZHMgYXJlIG5vdCBmb3IgdXNlCj4gPj4gYnkgZm9yd2FyZGluZy7CoCBJdCBpcyBub3QgUkVR VUlSRUQgdGhhdCB0aGV5IGJlIHVzZWQgZm9yIGZvcndhcmRpbmcKPiA+PiBhdCBhbiBTRkYsIGJ1 dCBpdCBpcyBjZXJ0YWlubHkgcGVybWl0dGVkLgo+ID4+Cj4gPj4gSXMgdGhlcmUgd29yZGluZyBp biB0aGUgZHJhZnQgdGhhdCBzYXlzIHRoYXQgdGhlc2UgYXJlIG5vbi1mb3J3YXJkaW5nCj4gPj4g aWRlbnRpZmllcnM/wqAgSWYgc28sIHdlIHJlYWxseSBzaG91bGQgZml4IHRoYXQuCj4gPj4KPiA+ PiBZb3VycywgSm9lbAo+ID4+Cj4gPj4gT24gNC8xMy8xNiA0OjA1IFBNLCBGZWR5aywgRG9uIHdy b3RlOgo+ID4+PiBIaSBKb2VsCj4gPj4+Cj4gPj4+IFRoZSBhcmd1bWVudCBoYXMgYmVlbiBwdXQg Zm9yd2FyZCB0aGF0IE5TSCBpcyBvbmx5IGNhcnJ5aW5nCj4gPj4+IGlkZW50aWZpZXJzLsKgIFdo ZW4gSSBsb29rIGF0IE5TSCBzZXJ2aWNlIGZvcndhcmRpbmcgdGhhdCBJIGtub3cgSQo+ID4+PiBk aXNhZ3JlZSB3aXRoIHRoYXQgc3RhdGVtZW50LsKgIEkgdGhpbmsgdGhhdCBOU0ggU0lEICsgU0kg aXMgYW4KPiA+Pj4gYWRkcmVzcyBzcGFjZSBhbmQgaGVuY2UgaXMgbm90IGNvbXBsZXRlbHkgaW5k ZXBlbmRlbnQgb2YgZm9yd2FyZGluZy4KPiA+Pj4gVGhlIG9ubHkgd2F5IEkgY2FuIHJlYXNvbiBp dCBvdXQgaXMgdG8gc2VlIG90aGVyIGV4YW1wbGVzIG9mCj4gPj4+IGNvbXBsZXRlIHBhY2tldCBo ZWFkZXJzIGFuZCBvcGVyYXRpb25zIHBlciBob3AuCj4gPj4+IFRoZXJlIGhhcyBiZWVuIGEgbG90 IG9mIGhhbmQgd2F2aW5nLgo+ID4+Pgo+ID4+PiBDaGVlcnMgRG9uCj4gPj4+Cj4gPj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBKb2VsIE0uIEhhbHBlcm4KPiA+Pj4+IFttYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbV0gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxNgo+ ID4+Pj4gMzo1OSBQTSBUbzogRmVkeWssIERvbiA8ZG9uLmZlZHlrQGhwZS5jb20+OyBUaG9tYXMg TmFydGVuCj4gPj4+PiA8bmFydGVuQHVzLmlibS5jb20+OyBzZmNAaWV0Zi5vcmcgU3ViamVjdDog UmU6IFtzZmNdIFdHIGxhc3QgY2FsbAo+ID4+Pj4gZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50 eHQKPiA+Pj4+Cj4gPj4+PiBJIGFtIGhhdmluZyB0cm91YmxlIGZvbGxvd2luZyB5b3VyIGFyZ3Vt ZW50IGFib3V0IGZvcndhcmRpbmcgaW4KPiA+Pj4+IHRoaXMgZW1haWwuCj4gPj4+Pgo+ID4+Pj4g WWVzLCB0cmFuc3BvcnRzIGNhbiBjYXJyeSBmb3J3YXJkaW5nIGluZm9ybWF0aW9uLsKgIFRoZSBT RkMKPiA+Pj4+IGFyY2h0aWVjdHVyZSBhbGxvd3MgaXQuwqAgdGhhdCBkb2VzIG5vdCBtYWtlIGlu Y2x1ZGluZyBzZXJ2aWNlIHBhaHQKPiA+Pj4+IGlkZW50aWZpY2F0aW9uIGluIGh0IE5TSCBoZWFk ZXIgZWl0aGVyIHJlZHVuZGFudCBvciBpbmNvcnJlY3QuCj4gPj4+Pgo+ID4+Pj4gSSBkbyBub3Qg a25vdyB3aGF0IHlvdSBtZWFuIGJ5IG5lZWRpbmcgbW9yZSBleGFtcGxlcyBvZiB0aGUKPiA+Pj4+ IGZvcndhcmRpbmcuIFRoZSBkcmFmdCBpdHNlbGYgZGVzY3JpYmVzIGhvdyB0aGUgTlNIIGhlYWRl ciBTRlAgSUQKPiA+Pj4+IGFuZCBpbmRleCBjYW4gYmUgdXNlZCBmb3IgdGhlIFNGRiBmb3J3YXJk aW5nIGRlY2lzaW9uLsKgIFRoYXQKPiA+Pj4+IGRlc2NyaXB0aW9uIHNlZW1zIHF1aXRlIGNsZWFy IHRvIG1lLsKgIElmIHRoZXJlIGlzIGFtYmlndWl0eSBvcgo+ID4+Pj4gdW5jbGFyaXR5LCBwbGVh c2UgbGV0IHRoZSBXRyBrbm93LCBzbyB3ZSBjYW4gaW1wcm92ZSBpdC4KPiA+Pj4+Cj4gPj4+PiBZ b3VycywgSm9lbAo+ID4+Pj4KPiA+Pj4+IE9uIDQvMTMvMTYgMzowNSBQTSwgRmVkeWssIERvbiB3 cm90ZToKPiA+Pj4+PiBIaSBUaG9tYXMKPiA+Pj4+Pgo+ID4+Pj4+IEF0IHRoaXMgcG9pbnQgSSBk byBub3Qgc3VwcG9ydCBhIGxhc3QgY2FsbCBvbiB0aGUgTlNIIGhlYWRlci4KPiA+Pj4+PiBUaGVy ZSBpcyBhIGxvdCBvZgo+ID4+Pj4gY29tbWVudHMgYW5kIEkgZG9uJ3QgdGhpbmsgaXQgaXMgYXQg YSBwb2ludCB3aGVyZSBpdCBpcyBsYXN0IGNhbGwKPiA+Pj4+IHJlYWR5Lgo+ID4+Pj4+Cj4gPj4+ Pj4gSSBoYXZlIGJlIGJhbmdpbmcgbXkgaGVhZCBhZ2FpbnN0IHRoZSB3YWxsIG9uIHRoaXMgb25l IGJlY2F1c2UgSQo+ID4+Pj4+IHdvdWxkIGxpa2UKPiA+Pj4+IG1vcmUgY29uY3JldGUgYXJvdW5k IHRoZSBmb3J3YXJkaW5nIGFzcGVjdHMuwqAgSSBkbyBhY2NlcHQgdGhhdAo+ID4+Pj4gdGhlcmUg aXMgYSBkcmFmdCAoZHJhZnQta3VtYXItc2ZjLW5zaC1mb3J3YXJkaW5nLTAwICkgbm93IHRoYXQK PiA+Pj4+IGFkZHJlc3NlcyBzb21lIHRoZSBjb25mdXNpb24gaW4gTlNIIG9uIGZvcndhcmRpbmcg YW5kIGl0IGhlbHBzLgo+ID4+Pj4gQWx0aG91Z2ggaXQgc2VlbXMgb2RkIHRvIGxldCBhIE5TSCBk cmFmdCBwcm9ncmVzcyBhcyBjb25mdXNpbmcgYW5kCj4gPj4+PiB0byBjbGFyaWZ5IGl0IGxhdGVy IGluIGFub3RoZXIgZHJhZnQuCj4gPj4+Pj4KPiA+Pj4+PiBNeSBtYWluIG9iamVjdGlvbiBpcyBy ZWxhdGVkIHRvIHRoZSBmYWN0IHRoYXQgZm9yIGEgZHJhZnQgdGhhdAo+ID4+Pj4+IGNsYWltcyBp dCBpcwo+ID4+Pj4gaW5kZXBlbmRlbnQgb2YgZm9yd2FyZGluZyBpdCBzaW1wbHkgaGFzIG5vdCBi ZWVuIHByb3Zlbi7CoCBUaGF0IGRvZXMKPiA+Pj4+IG5vdCBtZWFuIHdlIG5lZWQgdG8gc3BlY2lm eSBmb3J3YXJkaW5nIGJ1dCBJJ2Qgc3RpbGwgbGlrZSB0byBzZWUKPiA+Pj4+IHRoZSBkYXRhIGZv cm1hdHMgb2Ygd2hhdCBhcmUgYmVpbmcgInByb3RvdHlwZWQiIHRvZGF5IHNvIEkgY2FuCj4gPj4+ PiBjb21wYXJlIHdpdGggdGhlIG90aGVyIGRhdGEgZm9ybWF0cyB0aGF0IEkga25vdyB0b2RheS4K PiA+Pj4+IEZvciBleGFtcGxlIHRoZSBNQUMgY2hhaW5pbmcgZHJhZnQgd2UgYXV0aG9yZWQgd291 bGQgbGlrZSB0byB1c2UKPiA+Pj4+IE5TSCBmb3IgbWV0YWRhdGEgYnV0IHRoZSBNQUMgY2hhaW5p bmcgbG9jYWwgTUFDcyBiZWFyIGEKPiA+Pj4+IHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBOU0ggU0RJ ICYgU0kuIEluIGZhY3Qgd2l0aG91dCB0aGVzZSBmaWVsZHMgYXMKPiA+Pj4+IG1hbmRhdG9yeSBp dCB3b3VsZCBiZSBtb3JlIGluZGVwZW5kZW50IGluIG15IGNhc2UuCj4gPj4+PiBJJ20gc3VyZSB0 aGVyZSBhcmUgc2ltaWxhciBhc3BlY3RzIHdpdGggb3RoZXIgdHJhbnNwb3J0cyB0eXBlcyBidXQK PiA+Pj4+IHVudGlsIEkgc2VlIHRoZW0gYW5kIHRoZSBvcGVyYXRpb25zIEkgY2FuJ3QgYXNzZXNz IHRyYW5zcG9ydAo+ID4+Pj4gaW5kZXBlbmRlbmNlIGNsYWltcy4KPiA+Pj4+Pgo+ID4+Pj4+IFRo ZXJlIGFyZSBvdGhlciBpbmNvbnNpc3RlbmNpZXMgdGhhdCBJIGNvdWxkIGxpdmUgd2l0aCBpbiB0 aGUKPiA+Pj4+PiBkcmFmdCByZWxhdGluZyB0bwo+ID4+Pj4gdGhlIGxvZ2ljIG9mIHRoZSBNRCB0 eXBlcyBldGMuIChBIGxlbmd0aCBmaWVsZCBzZWVtcyB0byBiZSB0aGUgb25seQo+ID4+Pj4gdGhp bmcgdGhhdCBpcyByZWFsbHkgbmVlZGVkIGFuZCBsb2NhbCBjb250ZXh0IHdpbGwgZGV0ZXJtaW5l IHRoZQo+ID4+Pj4gY29udGVudHMpLsKgIEJ1dCB3ZSBoYXZlIG1hZGUgdGhlc2UgY29tbWVudHMg bW9yZSB0aGFuIG9uY2UgYW5kCj4gSSd2ZQo+ID4+Pj4gc2VlbiBsaXR0bGUgYWNrbm93bGVkZ21l bnQgdGhhdCBpZiB0aGUgTlNIIGRhdGEgaXMgYmFzaWNhbGx5Cj4gPj4+PiBjb250ZXh0IGRyaXZl biBmaXhlZCBmaWVsZHMgYW5kIFRMVnMgY291bGQgYmUgbWl4ZWQuCj4gPj4+Pj4KPiA+Pj4+PiBT byBpbiBzaG9ydCBJIHN1cHBvcnQgb2YgdGhlIGRyYWZ0cyBnb2FscyBhcyBhIHdheSB0byBjYXJy eQo+ID4+Pj4+IG1ldGFkYXRhIGJ1dCBpdCBpcwo+ID4+Pj4gbm90IHJlYWR5IGZvciBsYXN0IGNh bGwgeWV0IGluIG15IG9waW5pb24uCj4gPj4+Pj4KPiA+Pj4+PiBUaGFua3MgRG9uCj4gPj4+Pj4K PiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogc2ZjCj4gPj4+Pj4+IFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMgTmFydGVuCj4g Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMzAsIDIwMTYgMTA6NDggUE0gVG86IHNmY0Bp ZXRmLm9yZwo+ID4+Pj4+PiBTdWJqZWN0OiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWll dGYtc2ZjLW5zaC0wNC50eHQKPiA+Pj4+Pj4KPiA+Pj4+Pj4gRGVhciBXRzoKPiA+Pj4+Pj4KPiA+ Pj4+Pj4gVGhpcyBub3RlIGJlZ2lucyBhIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLXNmYy1u c2gtMDQudHh0Cj4gPj4+Pj4+IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXNmYy1uc2gvKS4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gVGhlIGVkaXRvcnMgb2YgdGhlIE5T SCBkb2N1bWVudCBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZQo+ID4+Pj4+PiBhZGRyZXNz ZWQgYWxsIGtub3duIGNvbW1lbnRzIGFuZCB0aGF0IHRoZXJlIGFyZSBubyBvcGVuIGlzc3Vlcwo+ ID4+Pj4+PiB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Lgo+ID4+Pj4+ Pgo+ID4+Pj4+PiBTdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUgbGlzdCBwbGVhc2UsIGVkaXRv cmlhbCBjb21tZW50cyBjYW4KPiA+Pj4+Pj4gZ28gZGlyZWN0bHkgdG8gdGhlIGRvY3VtZW50IGVk aXRvcnMuCj4gPj4+Pj4+Cj4gPj4+Pj4+IFdlJ2xsIGFsc28gZ2V0IGEgYnJpZWYgdXBkYXRlIGZy b20gdGhlIGVkaXRvcnMgYXQgbmV4dCB3ZWVrJ3MKPiA+Pj4+Pj4gbWVldGluZy4gSWYgdGhlcmUg YXJlIGFueSByZW1haW5pbmcgaXNzdWVzIHdpdGggdGhlIGRvY3VtZW50LAo+ID4+Pj4+PiByYWlz aW5nIHRoZW0gYmVmb3JlIHRoZSBtZWV0aW5nIHdvdWxkIGJlIGVzcGVjaWFsbHkgaGVscGZ1bC4K PiA+Pj4+Pj4KPiA+Pj4+Pj4gRm9yIHRoZSBjaGFpcnMsIFRob21hcwo+ID4+Pj4+Pgo+ID4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMKPiA+ PiBtYWlsaW5nIGxpc3QKPiA+Pj4+Pj4gc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjCj4gPj4+Pj4KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBzZmMKPiBtYWlsaW5nCj4gPj4gbGlzdAo+ID4+ Pj4+IHNmY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Ywo+ID4+Pj4+Cj4gPgo= ----_com.samsung.android.email_5635133258029360 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pkkgd2lsbCBoYXZlIHRvIGxv b2sgbW9yZSBjbG9zZWx5IGF0IHlvdXIgY29tbWVudHMgb3ZlciBhbGwuPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5SZWdhcmRpbmcgcmVjbGFzc2lmaWNhdGlvbiwgY2xhc3NpZmllcnMgY2FuIGxv b2sgYXQgYW55IHRoaW5nIHRoZXkgd2FudC4gJm5ic3A7TG9va2luZyBhdCBTSUQgd291bGQgc2Vl bSB2ZXJ5IHJhcmUsIGJ1dCBub3QgaW1wb3NzaWJsZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PllvdXJzLDwvZGl2PjxkaXY+Sm9lbDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtj b2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFUJmFt cDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEw MCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBP cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiAiRmVkeWssIERvbiIgJmx0 O2Rvbi5mZWR5a0BocGUuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDQvMTgvMjAxNiAgMjowNCBQ TSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBq b2VsaGFscGVybi5jb20mZ3Q7LCBzZmNAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSRTog W3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0IDwvZGl2Pjxk aXY+PGJyPjwvZGl2PjwvZGl2PkhpIEpvZWw8YnI+PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+Jmd0OyBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tXTxicj4mZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTMsIDIwMTYgNjoxMCBQ TTxicj4mZ3Q7IFRvOiBGZWR5aywgRG9uICZsdDtkb24uZmVkeWtAaHBlLmNvbSZndDs7IHNmY0Bp ZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0 LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+Jmd0OyA8YnI+Jmx0O1NuaXAmZ3Q7Jm5ic3A7IDxicj4m Z3Q7IFNvIHRoZSBxdWVzdGlvbiBJIGhhdmUgaXMgd2hhdCB3b3JkaW5nIGluIHRoZSBOU0ggZHJh ZnQgY2F1c2VzIHlvdSBjb25jZXJuLjxicj4mZ3Q7IElzIHRoZXJlIHdvcmRpbmcgaW4gdGhlIE5T SCBkcmFmdCB0aGF0IGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIFNQSSAvIFNJIGlzPGJy PiZndDsgb25seSBhbiAiaWRlbnRpZmllciI/Jm5ic3A7IElzIHRoZXJlIHdvcmRpbmcgdGhhdCB3 ZSBjb3VsZCBhZGQgdGhhdCB3b3VsZCBoZWxwPzxicj5bRG9uXSZuYnNwOyAtIFNpbmNlIHlvdSBi cmluZyBpdCB1cDogU2hvcnQgYW5zd2VyIHllcyB3aGVuIHlvdSBnZXQgdG8gc2VjdGlvbiA3LjQg RmlndXJlIDE0LiA8YnI+PGJyPlRoZSB3b3JkaW5nIGFyb3VuZCBzZXJ2aWNlIGZvcndhcmRpbmcg aXMgYSBiaXQgZGlzY29ubmVjdGVkIHNwcmVhZCBvdmVyIGEgZmV3IHNlY3Rpb25zIGFzIEkgdW5k ZXJzdGFuZCBpdCB0aGVyZSBhcmUgMyBtb2RlcyBvZiBmb3J3YXJkaW5nIG9wZXJhdGlvbnMgaW52 b2x2aW5nIFNGRnMgYW5kIFNGcyB0aGF0IEkgY2FuIHNlZS4gSXQgd2FzIGluaXRpYWxseSBkaXNj dXNzaW9ucyBvbiB0aGUgbGlzdCBhYm91dCBpZGVudGlmaWVycyB0aGF0IG1hZGUgbWUgbG9vayBt b3JlIGRlZXBseSBhdCB0aGUgZm9yd2FyZGluZy4mbmJzcDsmbmJzcDsgSSdsbCBrZWVwIG15IGNv bW1lbnRzIHRvIHNlcnZpY2UgZm9yd2FyZGluZyBldmVuIHRob3VnaCB0aGVzZSBzZWN0aW9ucyBh bHNvIGRpc2N1c3MgdGhlIG1hcHBpbmcgdG8gdHJhbnNwb3J0IEknbGwgZm9jdXMgb24gU1BJIGFu ZCBTSSBoYW5kbGluZyB0ZXh0LiA8YnI+PGJyPkFsc28gbm90ZSB0aGVyZSBhcmUgdHdvIG9jY3Vy cmVuY2VzIG9mIFNQSS9JRCBhbmQgNCBvY2N1cnJlbmNlcyBvZiBTUEkvU0kgd2hpY2ggSSBhc3N1 bWUgYXJlIGJvdGggU2VydmljZSBQYXRoIElkZW50aWZpZXIgYW5kIFNlcnZpY2UgSW5kZXguJm5i c3A7IElEIGlzIG5ldmVyIGRlZmluZWQgYnV0IFNJIGlzIGVxdWF0ZWQgdG8gbm9kZSBJRCBvciBs b2NhdGlvbi4mbmJzcDsgSSB0aGluayBTUEkvSUQgaXMgYSB0eXBvLjxicj48YnI+V2l0aCByZXNw ZWN0IHRvIFNGIGFuZCBTRkYgc2VydmljZSBmb3J3YXJkaW5nIDxicj5TZWN0aW9uIDQgYW5kIFNl Y3Rpb25zIDcuMSAtIDcuMyA8YnI+MSkgU0YgTlNIIEF3YXJlIHVzaW5nIFNJIGRlY3JlbWVudC4m bmJzcDsmbmJzcDsgVGhlIFNGRiBzZW5kcyB0byBhbiBTRiB0aGF0IGRvZXMgaXRzIHRoaW5nLCBh bmQgaGFzIGFjY2VzcyB0byBhbnkgbWV0YWRhdGEgYW5kIHBhc3NlcyB0aGUgcGFja2V0IGJhY2sg KHRvIHRoZSBzYW1lIFNGRikgd2l0aCBhIGRlY3JlbWVudGVkIFNJLiZuYnNwOyZuYnNwOyBUaGUg U0ZGIHRoZW4gbG9va3MgdXAgdGhlIG5leHQgaG9wIGJhc2VkIG9uIHRoZSBTUEkvU0kgdGhhdCBt YXBzIHRvIGFub3RoZXIgU0Ygb3B0aW9uYWxseSB2aWEgYSBOZXR3b3JrIHRyYW5zcG9ydCBtYXBw aW5nLiZuYnNwOyA8YnI+MikgU0YgTlNIIFVuYXdhcmUgLSBBIHByb3h5IGRvZXMgdGhlIGRlY3Jl bWVudGluZyBvZiB0aGUgU0kuIDxicj48YnI+T2JzZXJ2YXRpb246Jm5ic3A7IFRoZSBkZWNyZW1l bnRpbmcgb2YgU0kga2VlcHMgdGhlIGZvcndhcmRpbmcgdGhyb3VnaCBhbiBTRiB0byBhIHNpbXBs aXN0aWMgZm9ybS4gVGhlIHRleHQgZGVzY3JpYmluZyB0aGlzIG1vZGUgaW1wbGllcyBTRiB0cmFj a2luZyB1c2luZyBTSSBhbmQgdXNlcyBhIHByb2dyYW1tZWQgbG9va3VwIG9mIHRoZSBuZXh0IFNQ SS9TSS4gPGJyPjxicj5Ob3RlOiBUaGUgdGV4dCBhYm91dCBkZWNyZW1lbnRpbmcgdG8gemVybyBz ZWVtcyB1bm5lY2Vzc2FyeSBnaXZlbiB0aGF0IGFueSBTRkYgdGhhdCByZWNlaXZlcyBhbiBTUEkg d2l0aCBhbnkgU0kgdmFsdWUgdGhhdCBpcyB1bmV4cGVjdGVkIGlzIGEgZm9yd2FyZGluZyBtaXN0 YWtlLiZuYnNwOyZuYnNwOyBaZXJvIGlzIGp1c3QgYSBzcGVjaWZpYyBleGFtcGxlIG9mIHRoZSBn ZW5lcmFsIGNhc2Ugb2YgY2hhaW4gcHJvZ3JhbW1pbmcgd2hlcmUgU1BJL1NJIG11c3QgbWFrZSBz ZW5zZSBhdCBlYWNoIGhvcC4gU0kgb2YgemVybyBkb2VzIG5vdCBtYWtlIHNlbnNlIGJ1dCBuZWl0 aGVyIGRvIGFueSBvdGhlciB2YWx1ZXMgb2YgU0kgdGhhdCBhcmUgbm90IHByb2dyYW1tZWQgZm9y IHRoYXQgU1BJL1NJIGNvbWJpbmF0aW9uLiZuYnNwOyZuYnNwOyA8YnI+V2UgaGF2ZSBhbHdheXMg YXNzdW1lZCB0aGF0IGEgY29udHJvbCBwbGFuZS9tYW5hZ2VtZW50IHBsYW5lIGFyZSB1c2VkIHRv IHNldHVwL3ZlcmlmeSBjaGFpbnMgYW5kIHNvbWUgZm9ybSBvZiBPQU0gc2hvdWxkIGJlIHVzZWQg dG8gdmVyaWZ5IGNoYWlucy4gPGJyPjxicj5TaW5jZSB0aGUgc2ltcGxpc3RpYyBmb3JtIGRvZXMg bm90IGFsbG93IHRoZSBtb3JlIGNvbXBsZXggY2hhaW5zLCBpbiBTZWN0aW9uIDcuNCB5b3UgaGF2 ZSB0aGUgdGhpcmQgbW9kZS4gPGJyPjMpIFNGIE5TSCBBd2FyZSB3aXRoIHJlY2xhc3NpZmljYXRp b24gLSBUaGlzIG1vZGUgYWxsb3dzIGFuIFNGIHRvIGRvIGFueXRoaW5nIHRvIFNQSS9TSSAtIG5v dCBzcGVjaWZpZWQgZXhhY3RseSB3aGF0LCBqdXN0IHRoYXQgcmVjbGFzc2lmaWNhdGlvbiBpcyBh bGxvd2VkIGFuZCBwcmVzdW1hYmx5IFNQSSBhbmQgb3IgU0kgY2FuIGJlIGNoYW5nZWQvcmVzZXQu Jm5ic3A7Jm5ic3A7IE9uZSBtaWdodCBpbXBseSBmcm9tIHJlYWRpbmcgYW5kIGZpZ3VyZSAxNCB0 aGF0IHRoaXMgaXMgYmFzZWQgb24gImlkZW50aWZpZXIiIChTUEkgKSBsb29rdXAgYW5kIGNvbnRl eHQgKG9yIENsYXNzKSBpbiB0aGlzIGV4YW1wbGUuJm5ic3A7IEl0IHNlZW1zIHRvIGZvbGxvdyB0 aGF0IFNGcyBhcmUgbGVzcyBjb25jZXJuZWQgd2l0aCBTSSBhY3R1YWwgdmFsdWVzLiZuYnNwOyBU aGlzIHNlY3Rpb25zIGltcGxpZXMgU1BJIGNhbiBiZSBjaGFuZ2VkIGFuZCBkb2VzIG5vdCBkZXNj cmliZSB3aGF0IGhhcHBlbnMgdG8gU0kuIFByZXN1bWFibHkgdGhlIFNJIGlzIHNldCB0byBzb21l ICJuZXcnIHZhbHVlIHNpbmNlIGFuIGluaXRpYWwgY2xhc3NpZmllciB3b3VsZCBub3Qga25vdyB3 aGF0IFNJIHNob3VsZCBiZSBmb3IgYWxsIGNvbWJpbmF0aW9ucyBvZiBjaGFpbnMgc28gU0kgaXMm bmJzcDsgbG9jYXRpb24gb25seSB3aXRoIHJlc3BlY3QgdG8gYSBzcGVjaWZpYyBTUEkuIDxicj48 YnI+SXMgaXQgdHJ1ZSB0aGF0IFNJIGlzIG5vdCBjb25zdWx0ZWQgd2hlbiByZWNsYXNzaWZpY2F0 aW9uIHRha2VzIHBsYWNlPyZuYnNwOyZuYnNwOyA8YnI+PGJyPkNoZWVyczxicj5Eb24gPGJyPjxi cj4mZ3Q7IDxicj4mZ3Q7IFRoYW5rcyw8YnI+Jmd0OyBKb2VsPGJyPiZndDsgPGJyPiZndDsgT24g NC8xMy8xNiA0OjM5IFBNLCBGZWR5aywgRG9uIHdyb3RlOjxicj4mZ3Q7ICZndDsgSm9lbDxicj4m Z3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdDxicj4mZ3Q7ICZndDsgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt1bWFyLXNmYy1uc2gtZm9yd2FyZGluZy0wMDxicj4m Z3Q7ICZndDsgY2xhcmlmaWVzIFNlcnZpY2UgRm9yd2FyZGluZyAoYWxvbmcgdGhlIGNoYWluKSB2 ZXJzdXMgUGFja2V0PGJyPiZndDsgJmd0OyBmb3J3YXJkaW5nIChlbHNld2hlcmUpLiZuYnNwOyZu YnNwOyZuYnNwOyBCdXQgdGhpcyBkcmFmdCBwb2ludHMgb3V0IHRoYXQgdGhlIE5TSDxicj4mZ3Q7 ICZndDsgZHJhZnQgaXMgImNvbmZ1c2luZyIgd2l0aCByZXNwZWN0IHRvIHNvbWUgcGFydHMgb2Yg c2VydmljZTxicj4mZ3Q7ICZndDsgZm9yd2FyZGluZy4mbmJzcDsmbmJzcDsgQW5kIHdoZW4gSSBh bmQgb3RoZXJzIGhhdmUgYXNrZWQgb24gdGhlIGxpc3QgYWJvdXQ8YnI+Jmd0OyAmZ3Q7IHN1YnRs ZXRpZXMgb2YgU2VydmljZSBmb3J3YXJkaW5nJm5ic3A7IGJlaGF2aW9ycyBhbmQgdGhlIHJlbGF0 aW9uc2hpcCBvZjxicj4mZ3Q7ICZndDsgY2hhaW4gSUQgd2l0aCB2YXJpb3VzIHBhY2tldCBmb3Jt YXRzOyZuYnNwOyB0aGUgYW5zd2VycyB3ZXJlIE5TSCBTSUQgYW5kIFNJPGJyPiZndDsgJmd0OyB3 ZXJlIGp1c3QgaWRlbnRpZmllcnMuJm5ic3A7IFNvIHdoaWxlIHRoZXJlIGlzIG5vdCBhIHN0YXRl bWVudCB0aGV5IGFyZTxicj4mZ3Q7ICZndDsgbm9uLWZvcndhcmRpbmcgaWRlbnRpZmllcnMgdGhl IGNvbmZ1c2lvbiBzdGlsbCBleGlzdHMgYmVjYXVzZSB0aGU8YnI+Jmd0OyAmZ3Q7IGJlaGF2aW9y IGlzIG5vdCBjbGVhci4gSSBzdGlsbCB0aGluayBOU0ggU0lEIGFuZCBTSSZuYnNwOyBiZWhhdmUg YXMgYW48YnI+Jmd0OyAmZ3Q7IGFkZHJlc3Mgc3BhY2UgLSByZWNlaXZlIGEgcGFja2V0OyBsb29r dXAgdGhlIGFkZHJlc3M7IGlmIHJlY29nbml6ZWQ8YnI+Jmd0OyAmZ3Q7IHByb2Nlc3M7IHRoZW4g cGxhY2UgdGhlIG5leHQgaG9wIGFkZHJlc3MgKGluY2x1ZGVzIG5vdCBtb2RpZnlpbmcgdGhlPGJy PiZndDsgJmd0OyBhZGRyZXNzIGluIHNvbWUgY2FzZXMpIG9uIHRoZSBwYWNrZXQgYW5kIGZvcndh cmQgb24uJm5ic3A7IElmIHRoZSBmaWVsZHM8YnI+Jmd0OyAmZ3Q7IGRvbid0IG1hdGNoIGV4cGVj dGVkIHZhbHVlczsmbmJzcDsgZHJvcCBvciBleGNlcHRpb24gcHJvY2Vzcy48YnI+Jmd0OyAmZ3Q7 PGJyPiZndDsgJmd0OyBDaGVlcnMgRG9uPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDs8YnI+Jmd0 OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBKb2VsIE0uIEhhbHBl cm48YnI+Jmd0OyAmZ3Q7Jmd0OyBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dIFNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgMTMsIDIwMTYgNDowOSBQTTxicj4mZ3Q7ICZndDsmZ3Q7IFRvOiBGZWR5 aywgRG9uICZsdDtkb24uZmVkeWtAaHBlLmNvbSZndDs7IFRob21hcyBOYXJ0ZW48YnI+Jmd0OyAm Z3Q7Jmd0OyAmbHQ7bmFydGVuQHVzLmlibS5jb20mZ3Q7OyBzZmNAaWV0Zi5vcmcgU3ViamVjdDog UmU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+Jmd0OyAmZ3Q7Jmd0OyBkcmFmdC1pZXRmLXNm Yy1uc2gtMDQudHh0PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyBHaXZlbiB0aGF0 IHRoZSBkcmFmdCBkZXNjcmliZXMgaG93IHRvIHVzZSB0aGUgU0ZQIElEIGFuZCBJbmRleCBmb3I8 YnI+Jmd0OyAmZ3Q7Jmd0OyBmb3J3YXJkaW5nLCBpdCB3b3VsZCBzZWVtIHZlcnkgc3RyYW5nZSB0 byBhcmd1ZSB0aGF0IGl0IGRvZXMgbm90PGJyPiZndDsgJmd0OyZndDsgZGVzY3JpYmUgYSBmb3J3 YXJkaW5nIGJlaGF2aW9yLCBvciB0aGF0IHRob3NlIGZpZWxkcyBhcmUgbm90IGZvciB1c2U8YnI+ Jmd0OyAmZ3Q7Jmd0OyBieSBmb3J3YXJkaW5nLiZuYnNwOyBJdCBpcyBub3QgUkVRVUlSRUQgdGhh dCB0aGV5IGJlIHVzZWQgZm9yIGZvcndhcmRpbmc8YnI+Jmd0OyAmZ3Q7Jmd0OyBhdCBhbiBTRkYs IGJ1dCBpdCBpcyBjZXJ0YWlubHkgcGVybWl0dGVkLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsgSXMgdGhlcmUgd29yZGluZyBpbiB0aGUgZHJhZnQgdGhhdCBzYXlzIHRoYXQgdGhl c2UgYXJlIG5vbi1mb3J3YXJkaW5nPGJyPiZndDsgJmd0OyZndDsgaWRlbnRpZmllcnM/Jm5ic3A7 IElmIHNvLCB3ZSByZWFsbHkgc2hvdWxkIGZpeCB0aGF0Ljxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZn dDsgJmd0OyZndDsgWW91cnMsIEpvZWw8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7 IE9uIDQvMTMvMTYgNDowNSBQTSwgRmVkeWssIERvbiB3cm90ZTo8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsgSGkgSm9lbDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUg YXJndW1lbnQgaGFzIGJlZW4gcHV0IGZvcndhcmQgdGhhdCBOU0ggaXMgb25seSBjYXJyeWluZzxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyBpZGVudGlmaWVycy4mbmJzcDsgV2hlbiBJIGxvb2sgYXQgTlNI IHNlcnZpY2UgZm9yd2FyZGluZyB0aGF0IEkga25vdyBJPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGRp c2FncmVlIHdpdGggdGhhdCBzdGF0ZW1lbnQuJm5ic3A7IEkgdGhpbmsgdGhhdCBOU0ggU0lEICsg U0kgaXMgYW48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsgYWRkcmVzcyBzcGFjZSBhbmQgaGVuY2UgaXMg bm90IGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgb2YgZm9yd2FyZGluZy48YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsgVGhlIG9ubHkgd2F5IEkgY2FuIHJlYXNvbiBpdCBvdXQgaXMgdG8gc2VlIG90aGVyIGV4 YW1wbGVzIG9mPGJyPiZndDsgJmd0OyZndDsmZ3Q7IGNvbXBsZXRlIHBhY2tldCBoZWFkZXJzIGFu ZCBvcGVyYXRpb25zIHBlciBob3AuPGJyPiZndDsgJmd0OyZndDsmZ3Q7IFRoZXJlIGhhcyBiZWVu IGEgbG90IG9mIGhhbmQgd2F2aW5nLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyBDaGVlcnMgRG9uPGJyPiZndDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBKb2VsIE0uIEhhbHBlcm48 YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0gU2Vu dDogV2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxNjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgMzo1 OSBQTSBUbzogRmVkeWssIERvbiAmbHQ7ZG9uLmZlZHlrQGhwZS5jb20mZ3Q7OyBUaG9tYXMgTmFy dGVuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bmFydGVuQHVzLmlibS5jb20mZ3Q7OyBz ZmNAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtzZmNdIFdHIGxhc3QgY2FsbDxicj4mZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIGhhdmluZyB0cm91YmxlIGZv bGxvd2luZyB5b3VyIGFyZ3VtZW50IGFib3V0IGZvcndhcmRpbmcgaW48YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoaXMgZW1haWwuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgWWVzLCB0cmFuc3BvcnRzIGNhbiBjYXJyeSBmb3J3YXJkaW5nIGluZm9y bWF0aW9uLiZuYnNwOyBUaGUgU0ZDPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcmNodGllY3R1 cmUgYWxsb3dzIGl0LiZuYnNwOyB0aGF0IGRvZXMgbm90IG1ha2UgaW5jbHVkaW5nIHNlcnZpY2Ug cGFodDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaWRlbnRpZmljYXRpb24gaW4gaHQgTlNIIGhl YWRlciBlaXRoZXIgcmVkdW5kYW50IG9yIGluY29ycmVjdC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIGRvIG5vdCBrbm93IHdoYXQgeW91IG1lYW4g YnkgbmVlZGluZyBtb3JlIGV4YW1wbGVzIG9mIHRoZTxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg Zm9yd2FyZGluZy4gVGhlIGRyYWZ0IGl0c2VsZiBkZXNjcmliZXMgaG93IHRoZSBOU0ggaGVhZGVy IFNGUCBJRDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYW5kIGluZGV4IGNhbiBiZSB1c2VkIGZv ciB0aGUgU0ZGIGZvcndhcmRpbmcgZGVjaXNpb24uJm5ic3A7IFRoYXQ8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGRlc2NyaXB0aW9uIHNlZW1zIHF1aXRlIGNsZWFyIHRvIG1lLiZuYnNwOyBJZiB0 aGVyZSBpcyBhbWJpZ3VpdHkgb3I8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHVuY2xhcml0eSwg cGxlYXNlIGxldCB0aGUgV0cga25vdywgc28gd2UgY2FuIGltcHJvdmUgaXQuPGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWW91cnMsIEpvZWw8YnI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBPbiA0LzEzLzE2IDM6 MDUgUE0sIEZlZHlrLCBEb24gd3JvdGU6PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkg VGhvbWFzPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBdCB0aGlzIHBvaW50IEkgZG8gbm90IHN1cHBvcnQgYSBsYXN0IGNhbGwgb24gdGhl IE5TSCBoZWFkZXIuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgaXMgYSBsb3Qg b2Y8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbW1lbnRzIGFuZCBJIGRvbid0IHRoaW5rIGl0 IGlzIGF0IGEgcG9pbnQgd2hlcmUgaXQgaXMgbGFzdCBjYWxsPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyByZWFkeS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBiZSBiYW5naW5nIG15IGhlYWQgYWdhaW5zdCB0aGUgd2FsbCBv biB0aGlzIG9uZSBiZWNhdXNlIEk8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3VsZCBs aWtlPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBtb3JlIGNvbmNyZXRlIGFyb3VuZCB0aGUgZm9y d2FyZGluZyBhc3BlY3RzLiZuYnNwOyBJIGRvIGFjY2VwdCB0aGF0PGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyB0aGVyZSBpcyBhIGRyYWZ0IChkcmFmdC1rdW1hci1zZmMtbnNoLWZvcndhcmRpbmct MDAgKSBub3cgdGhhdDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYWRkcmVzc2VzIHNvbWUgdGhl IGNvbmZ1c2lvbiBpbiBOU0ggb24gZm9yd2FyZGluZyBhbmQgaXQgaGVscHMuPGJyPiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBBbHRob3VnaCBpdCBzZWVtcyBvZGQgdG8gbGV0IGEgTlNIIGRyYWZ0IHBy b2dyZXNzIGFzIGNvbmZ1c2luZyBhbmQ8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGNsYXJp ZnkgaXQgbGF0ZXIgaW4gYW5vdGhlciBkcmFmdC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE15IG1haW4gb2JqZWN0aW9uIGlzIHJlbGF0 ZWQgdG8gdGhlIGZhY3QgdGhhdCBmb3IgYSBkcmFmdCB0aGF0PGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgY2xhaW1zIGl0IGlzPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpbmRlcGVuZGVu dCBvZiBmb3J3YXJkaW5nIGl0IHNpbXBseSBoYXMgbm90IGJlZW4gcHJvdmVuLiZuYnNwOyBUaGF0 IGRvZXM8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCBtZWFuIHdlIG5lZWQgdG8gc3BlY2lm eSBmb3J3YXJkaW5nIGJ1dCBJJ2Qgc3RpbGwgbGlrZSB0byBzZWU8YnI+Jmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoZSBkYXRhIGZvcm1hdHMgb2Ygd2hhdCBhcmUgYmVpbmcgInByb3RvdHlwZWQiIHRv ZGF5IHNvIEkgY2FuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBjb21wYXJlIHdpdGggdGhlIG90 aGVyIGRhdGEgZm9ybWF0cyB0aGF0IEkga25vdyB0b2RheS48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IEZvciBleGFtcGxlIHRoZSBNQUMgY2hhaW5pbmcgZHJhZnQgd2UgYXV0aG9yZWQgd291bGQg bGlrZSB0byB1c2U8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE5TSCBmb3IgbWV0YWRhdGEgYnV0 IHRoZSBNQUMgY2hhaW5pbmcgbG9jYWwgTUFDcyBiZWFyIGE8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBOU0ggU0RJICZhbXA7IFNJLiBJbiBmYWN0IHdpdGhv dXQgdGhlc2UgZmllbGRzIGFzPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBtYW5kYXRvcnkgaXQg d291bGQgYmUgbW9yZSBpbmRlcGVuZGVudCBpbiBteSBjYXNlLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgSSdtIHN1cmUgdGhlcmUgYXJlIHNpbWlsYXIgYXNwZWN0cyB3aXRoIG90aGVyIHRyYW5z cG9ydHMgdHlwZXMgYnV0PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB1bnRpbCBJIHNlZSB0aGVt IGFuZCB0aGUgb3BlcmF0aW9ucyBJIGNhbid0IGFzc2VzcyB0cmFuc3BvcnQ8YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGluZGVwZW5kZW5jZSBjbGFpbXMuPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSBhcmUgb3RoZXIgaW5jb25z aXN0ZW5jaWVzIHRoYXQgSSBjb3VsZCBsaXZlIHdpdGggaW4gdGhlPGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZHJhZnQgcmVsYXRpbmcgdG88YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRo ZSBsb2dpYyBvZiB0aGUgTUQgdHlwZXMgZXRjLiAoQSBsZW5ndGggZmllbGQgc2VlbXMgdG8gYmUg dGhlIG9ubHk8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5nIHRoYXQgaXMgcmVhbGx5IG5l ZWRlZCBhbmQgbG9jYWwgY29udGV4dCB3aWxsIGRldGVybWluZSB0aGU8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGNvbnRlbnRzKS4mbmJzcDsgQnV0IHdlIGhhdmUgbWFkZSB0aGVzZSBjb21tZW50 cyBtb3JlIHRoYW4gb25jZSBhbmQ8YnI+Jmd0OyBJJ3ZlPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBzZWVuIGxpdHRsZSBhY2tub3dsZWRnbWVudCB0aGF0IGlmIHRoZSBOU0ggZGF0YSBpcyBiYXNp Y2FsbHk8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRleHQgZHJpdmVuIGZpeGVkIGZpZWxk cyBhbmQgVExWcyBjb3VsZCBiZSBtaXhlZC48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNvIGluIHNob3J0IEkgc3VwcG9ydCBvZiB0aGUg ZHJhZnRzIGdvYWxzIGFzIGEgd2F5IHRvIGNhcnJ5PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgbWV0YWRhdGEgYnV0IGl0IGlzPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBub3QgcmVhZHkg Zm9yIGxhc3QgY2FsbCB5ZXQgaW4gbXkgb3Bpbmlvbi48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyBEb248YnI+Jmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBzZmM8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBO YXJ0ZW48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogV2VkbmVzZGF5LCBN YXJjaCAzMCwgMjAxNiAxMDo0OCBQTSBUbzogc2ZjQGlldGYub3JnPGJyPiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0 Zi1zZmMtbnNoLTA0LnR4dDxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEZWFyIFdHOjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIG5vdGUgYmVn aW5zIGEgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+Jmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtc2ZjLW5zaC8pLjxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZWRpdG9ycyBvZiB0aGUgTlNIIGRv Y3VtZW50IGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSBoYXZlPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGFkZHJlc3NlZCBhbGwga25vd24gY29tbWVudHMgYW5kIHRoYXQgdGhlcmUg YXJlIG5vIG9wZW4gaXNzdWVzPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdpdGgg dGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuPGJyPiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN1YnN0YW50aXZl IGNvbW1lbnRzIHRvIHRoZSBsaXN0IHBsZWFzZSwgZWRpdG9yaWFsIGNvbW1lbnRzIGNhbjxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBnbyBkaXJlY3RseSB0byB0aGUgZG9jdW1lbnQg ZWRpdG9ycy48YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgV2UnbGwgYWxzbyBnZXQgYSBicmllZiB1cGRhdGUgZnJvbSB0aGUg ZWRpdG9ycyBhdCBuZXh0IHdlZWsnczxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBt ZWV0aW5nLiBJZiB0aGVyZSBhcmUgYW55IHJlbWFpbmluZyBpc3N1ZXMgd2l0aCB0aGUgZG9jdW1l bnQsPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJhaXNpbmcgdGhlbSBiZWZvcmUg dGhlIG1lZXRpbmcgd291bGQgYmUgZXNwZWNpYWxseSBoZWxwZnVsLjxicj4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGb3IgdGhl IGNoYWlycywgVGhvbWFzPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHNmYzxicj4mZ3Q7ICZndDsmZ3Q7IG1haWxpbmcgbGlzdDxicj4mZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHNmYzxicj4mZ3Q7IG1haWxpbmc8YnI+Jmd0OyAmZ3Q7Jmd0OyBsaXN0 PGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_5635133258029360-- From nobody Mon Apr 18 11:39: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 13CEB12E53F for ; Mon, 18 Apr 2016 11:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 SoAID_EiiIMA for ; Mon, 18 Apr 2016 11:38:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCBB12E539 for ; Mon, 18 Apr 2016 11:38:59 -0700 (PDT) Received: from TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM (10.162.187.152) by TU4PR84MB0160.NAMPRD84.PROD.OUTLOOK.COM (10.162.187.153) with Microsoft SMTP Server (TLS) id 15.1.466.19; Mon, 18 Apr 2016 18:38:41 +0000 Received: from TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM ([10.162.187.152]) by TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM ([10.162.187.152]) with mapi id 15.01.0466.022; Mon, 18 Apr 2016 18:38:41 +0000 From: "Bottorff, Paul" To: "Joel M. Halpern" , "Paul Quinn (paulq)" , "Elzur, Uri" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivflTl8PyB805kuSkB1naNwin5+IdPDQgAFZBQCAAcu2oIAAEzaAgAR+egA= Date: Mon, 18 Apr 2016 18:38:41 +0000 Message-ID: References: <5711631F.6000006@joelhalpern.com> In-Reply-To: <5711631F.6000006@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.211.195.7] x-ms-office365-filtering-correlation-id: 8775bd7c-7138-41d7-70e5-08d367b8aa13 x-microsoft-exchange-diagnostics: 1; TU4PR84MB0160; 5:EF3e6f6nBNeSyTxc98nN5n/GHxtGS/pj3gMM09cdRfslh1tJhdZ+yxFMgnm7GU1dczFu+8fWHIDwWZVFa5OENaqxAM6TfruxLfb4dB2G7QrotXRxAhydTHi3k0biwiG0FWMzxhrfqJ5XC6j4zdVGF20ksX1QaZQu46z3Adp2ygwetgWvGZM+plpZQNA8mz/f; 24:vr8xX8tscHGuqDzyOfQEGSNQx5FOdWHzQOzQs4JHPEB+Z5Guagiz7wmTL41kDCNFYJUWgzTfGVcAPG8XdtYSuEUIm8u+znDJ+XhEbFpVXVY=; 7:gJj241s4WitgkrHybqIlQsq2UONmoR2O5fixiZUqX3/OnhAjAiOSZUxpVpOvq/fMNuzEtmyc8r1x6owkvtBunzd9bR2jBOlXhvd/kYZVr9KSKcHpGfmjEQmOaCTLFF3C7CJMpQZv+f0NgScvhzXPtdAKx9cTNTZM44BuwBLOZVNhpPpXOaLtFTgzQjWZvsIXUR6/5CqUZLIzXBb8aZ2QbE9zp3eRe+wMY+JQ7aVE6C4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TU4PR84MB0160; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:TU4PR84MB0160; BCL:0; PCL:0; RULEID:; SRVR:TU4PR84MB0160; x-forefront-prvs: 0916FC3A18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(43544003)(15975445007)(2900100001)(2906002)(6116002)(102836003)(3846002)(586003)(86362001)(92566002)(5001770100001)(10400500002)(2950100001)(93886004)(11100500001)(122556002)(1096002)(5008740100001)(189998001)(77096005)(1220700001)(50986999)(230783001)(76176999)(33656002)(19580405001)(19580395003)(66066001)(4326007)(81166005)(106116001)(5002640100001)(9686002)(54356999)(87936001)(5003600100002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:TU4PR84MB0160; H:TU4PR84MB0159.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2016 18:38:41.3319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR84MB0160 Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 18 Apr 2016 18:39:03 -0000 Hi Joel: Some comments below, Cheers, Paul -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, April 15, 2016 2:55 PM To: Bottorff, Paul ; Paul Quinn (paulq) ; Elzur, Uri Cc: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Paul B., just to make sure I am reading you correctly, on the issue of reve= rse direction SFPs, I believe the issue you are referring to is specificall= y the case of SFs which need to originate a packet back to the source of a = packet the SF has processed? PB>Yes, this is the original reference. This is also something which OAM so= metimes depends on since an OAM may generate a reply. While I think SFs can do better, it would seem that a properly configured c= lassifier at the SFF service that SF can take care of that case. Requiring= that it be encoded in the SPI seems overkill. PB>Fixing this at the SFF requires some indication for flag from the SF to = indicate the frame is traveling (or is to travel) in the reverse direction.= I have proposed that using the transport source address could be used at t= he SFF to make this determination, however have received pushback on this s= olution since it does not work for single armed SFs. Since the SA solution = may not be acceptable, I believe we need to provide a forward/reverse indic= ator. Yours, Joel On 4/15/16 5:36 PM, Bottorff, Paul wrote: > Hi Paul Q. > > Some responses to comments. > > Cheers, > > Paul > > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: Thursday, April 14, 2016 10:21 AM > To: Bottorff, Paul > Cc: Thomas Narten ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Paul B. > > Some comments inline. > > > >> On Apr 13, 2016, at 6:05 PM, Bottorff, Paul wrot= e: >> >> Hi Thomas: >> >> I do not support last call on draft-eitf-sfc-nsh-04. The risk of rushing= to close a format before we have clear agreement on the forwarding princip= les and features is just too high. >> >> The major problems with the current draft are: >> 1)the service address formed by the combined SPI+SI appears to have a=20 >> number of deficiencies which lead to transport dependencies and to=20 >> layer violations, > > PQ> You draw this broad stoke, however, it is relatively unsubstantiated= with technical facts. The WG discussed the representation of the SPI/SI p= rior to NSH adoption. The SPI/SI are not transport values -- and please do= n't conflate transport (and the associated requirements) with address famil= y. > PB> I have never asserted that SPI+SI for a "transport" address. Please d= on't confuse what I've said. The modeling of SPI+SI as a service layer addr= ess is very soundly rooted in classic network layer modeling. It is the ass= ertion that that the service layer is independent from the "transport" laye= r below that indicates the SPI+SI form the address used by the service laye= r dialog. This address is mapped into the "transport" by mapping the SPI+SI= into a transport tunnel and destination address. > >> 2)there is no resolution to forward/reverse addressing necessary for=20 >> support of many L4-high service functions, > > PQ> That is factually incorrect and I think derives from your opinion tha= t SPI/SI =3D=3D address family: in general, you can create two unidirection= al chains and use them for forward and reverse traffic. This has been revi= ewed with /by L4+ vendors/experts. > PB>We have a lot of work on both L4-higher SFs and proxy forwarders for L= 4-higher SFs for MAC Chaining and understand this problem in a lot of detai= l. Having two unidirectional chains don't solve the forward/reverse traffic= problem because the reverse path SPI/SI are not included in the NSH header= and therefore not available at the time we need to reverse the forwarding = direction. Are you mandating every SF and Proxy be provisioned with the for= ward and reverse SPI/SI? If so the solution is unacceptable to me. > > >> 3)there is no resolution to encoding hierarchies which are of=20 >> importance to SFC applications in NFV environments, > > PQ> Encoding hierarchies is an optimization of the base protocol to suppo= rt scaling in a large deployment; in any case such optimization does not re= quire changes to the base SFC encapsulation. > PB> A general stacking solution will require some type of support which I= believe should be in the base header so the context words are kept clear f= or pure meta-data. > >> 4)the draft needs a transport service interface and a description of=20 >> the mappings used for the service layer onto the transport layer, > > PQ> I am not sure what you mean by "transport service interface" - it is = true that the SPI/SI need to map to a transport layer forwarding entry but = I don't know what you are implying. > PB>You are trying to specify a "transport" independent layer, however hav= e not specified what services the transport must provide to support the SFC= layer. A service interface is one of the formalized ways to specify the fe= ature requirements of the underlying layer. > >> 5)the draft specifies two independent formats for encoding the NSH heade= r which is likely to divide the market slowing the deployment of NSH. > > PQ> The draft actually specifies two metadata formats for flexibility an= d the market will decide which is most appropriate based on specific use ca= ses. The evidence is clear: a wide-range of _implementations_ already exis= t. In fact, the real impediment to deployment is esoteric opinion. > PB> This is always the last resort dodge we use in standards, however it = always comes at the price of some market confusion and delay. Even though I= can accept this if no middle ground is possible, I don't think we have pus= hed the parties hard enough toward a converged solution to give it up on it= yet. > >> >>> From my point of view the SFC formed service plane layer network with = a peer dialog between the SCF, SFF and SF. The Service Path Header (SPI+SI= ) forms the address for this service plane. As it stands there is an attemp= t to overload the function of the SI as both the SF identifier with the Ser= vice Path and as a form of loop detection, however the coupling has resulte= d in two problems: >> 1)Since every SF in a path must have a sequential SI, in the event we ne= ed to insert or delete a SF it is necessary to update the SFF forwarding en= tries for the entire chain. To fix this either the SI should be allowed to = take non-sequential values along the chain or should not be used for SF add= ressing. > > PQ> This is not a true statement; if an SF needs to be added or deleted t= hen it is necessary to update the SFF forwarding entries for all SFFs downs= tream of where the change occurs. > PB> Agreed, I stand corrected. > > >> 2)Since the SI is only decremented on SF hops it can't guard against a l= oop between SFFs or SCFs, hence SI is not a reliable method for loop squelc= hing. If a TTL is needed it needs to be separated from SI. Given that there= is no clear alternative to TTL for loop squelching at the service layer I = believe we do need to include an effective TTL to go forward. > > PQ> The SI can provide a simple loop check within the serivce plane but i= t's primary semantic value is one of location. The transport itself can pr= ovide loop detection as well as SFF verification of SPI/SI + source. > PB> I both disagree that SI is useful for loop squeltching or that "trans= port" TTL can stop service layer looping. To use the "transport" TTL the f= ield would need to be copied from one "transport" to the next "transport" o= ver the SFC service layer. Disregarding the fact that this operation is bui= lding a dependency between the "transport" and service layers, which we exp= ressly are trying to avoid, the TTL fields of the transports are not sized = to allow for the expanded path lengths which could be created in chains. In= addition, some of the transports like Ethernet only support TTL for in spe= cial cases (Ethernet only supports TTL when using F-Tag forwarding). > >> 3)Every other successful address space has needed to add a few bits to s= upport QoS options. I would suggest taking 3-4 bits from the MD-type and to= reserve for QoS handling. > > PQ> Again, this is blurring the lines: QoS is handled, as expected by th= e selection transport. This is a feature, not a bug, architecturally speak= ing. > PB> Just the opposite, failing to add QoS to the NSH header is blurring t= he lines between the service layer and the "transport" layer. Consider an a= chain which uses both a best effort and an expedited service. Next conside= r building the chain where each hop uses a different type of "transport". A= s we map from one "transport" to the next we may over some hops have less Q= oS information than others. As we continue to the next "transport" we retai= n the integrity of the end-to-end communication by regenerating QoS from th= e original QoS contained at the service layer a driven down into the "trans= port". > >> 4)In may data centers we have multi-vendor deployments. In these environ= ments we may have different managers assigning chains. There should to be s= ome convention for splitting the address space between these vendors. The m= ost desirable solution to this is to add an assigned organization ID to the= address space. An alternative would be to separate the SPI into a 4 and 20= bit field designating the high 4 bits as a local manager ID. >> > > PQ> You are conflating federation/configuration and frame format. The m= ulti-manager scenario is a control-plane/management-plane function. > PB> In a multi-manager situation I need a way to avoid collision in the a= llocation of the SPI/SI space which is being independently allocated by dif= ferent managers. > > _______________________________________________ > 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 Mon Apr 18 22:06:12 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 E489D12DB71 for ; Mon, 18 Apr 2016 22:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 AfAfTUPIFAxX for ; Mon, 18 Apr 2016 22:06:08 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665DF12DC6F for ; Mon, 18 Apr 2016 22:06:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D87C32672BE; Mon, 18 Apr 2016 22:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461042367; bh=Q4QuZuUwTofo6qiiwPQ1MOdXFaq45RZzKyuZrKtN2dk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=p2ym4TppyAJVxuPrfWmWJGveObRAKQRLrG0qtnoIrX1dJrdD2CdPSkRbhF0mx9px7 hkeQNKl5zg44hNjEpVbpEFwMQ+4B66XrEnP21+uFW8npQyHK2Kd8ZlTKjKw1ENZRsV S19Q7ei7UgRw5oy9JQ5VbrObH39JNi1yjfti59Dg= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (50-193-35-17-static.hfc.comcastbusiness.net [50.193.35.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4B676240E6E; Mon, 18 Apr 2016 22:06:07 -0700 (PDT) To: "Bottorff, Paul" , "Paul Quinn (paulq)" , "Elzur, Uri" References: <5711631F.6000006@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <5715BCB6.3090407@joelhalpern.com> Date: Tue, 19 Apr 2016 01:05:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Thomas Narten , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 19 Apr 2016 05:06:10 -0000 Paul B., if we are using a classifier to generate the NSH header, then all we need to do is send the packet back either without an NSH, or with an NSH with a bit indicating that reclassification is needed. The source and destination addresses in the packet will tell the classifier what it needs to know in order to generate the right NSH header. Other options include configuring the SF with the reverse direction SPI / SI. None of these require a direction bit in the neader. Which is good, as trying to define forward and backwards is pretty confusing in a network. Yours, Joel On 4/18/16 2:38 PM, Bottorff, Paul wrote: > Hi Joel: > > Some comments below, > > Cheers, > > Paul > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On > Behalf Of Joel M. Halpern Sent: Friday, April 15, 2016 2:55 PM To: > Bottorff, Paul ; Paul Quinn (paulq) > ; Elzur, Uri Cc: Thomas Narten > ; sfc@ietf.org Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Paul B., just to make sure I am reading you correctly, on the issue > of reverse direction SFPs, I believe the issue you are referring to > is specifically the case of SFs which need to originate a packet back > to the source of a packet the SF has processed? PB>Yes, this is the > original reference. This is also something which OAM sometimes > depends on since an OAM may generate a reply. > > While I think SFs can do better, it would seem that a properly > configured classifier at the SFF service that SF can take care of > that case. Requiring that it be encoded in the SPI seems overkill. > PB>Fixing this at the SFF requires some indication for flag from the > SF to indicate the frame is traveling (or is to travel) in the > reverse direction. I have proposed that using the transport source > address could be used at the SFF to make this determination, however > have received pushback on this solution since it does not work for > single armed SFs. Since the SA solution may not be acceptable, I > believe we need to provide a forward/reverse indicator. > > Yours, Joel > > On 4/15/16 5:36 PM, Bottorff, Paul wrote: >> Hi Paul Q. >> >> Some responses to comments. >> >> Cheers, >> >> Paul >> >> -----Original Message----- From: Paul Quinn (paulq) >> [mailto:paulq@cisco.com] Sent: Thursday, April 14, 2016 10:21 AM >> To: Bottorff, Paul Cc: Thomas Narten >> ; sfc@ietf.org Subject: Re: [sfc] WG last call >> for draft-ietf-sfc-nsh-04.txt >> >> Paul B. >> >> Some comments inline. >> >> >> >>> On Apr 13, 2016, at 6:05 PM, Bottorff, Paul >>> wrote: >>> >>> Hi Thomas: >>> >>> I do not support last call on draft-eitf-sfc-nsh-04. The risk of >>> rushing to close a format before we have clear agreement on the >>> forwarding principles and features is just too high. >>> >>> The major problems with the current draft are: 1)the service >>> address formed by the combined SPI+SI appears to have a number of >>> deficiencies which lead to transport dependencies and to layer >>> violations, >> >> PQ> You draw this broad stoke, however, it is relatively >> unsubstantiated with technical facts. The WG discussed the >> representation of the SPI/SI prior to NSH adoption. The SPI/SI are >> not transport values -- and please don't conflate transport (and >> the associated requirements) with address family. PB> I have never >> asserted that SPI+SI for a "transport" address. Please don't >> confuse what I've said. The modeling of SPI+SI as a service layer >> address is very soundly rooted in classic network layer modeling. >> It is the assertion that that the service layer is independent from >> the "transport" layer below that indicates the SPI+SI form the >> address used by the service layer dialog. This address is mapped >> into the "transport" by mapping the SPI+SI into a transport tunnel >> and destination address. >> >>> 2)there is no resolution to forward/reverse addressing necessary >>> for support of many L4-high service functions, >> >> PQ> That is factually incorrect and I think derives from your >> opinion that SPI/SI == address family: in general, you can create >> two unidirectional chains and use them for forward and reverse >> traffic. This has been reviewed with /by L4+ vendors/experts. >> PB>We have a lot of work on both L4-higher SFs and proxy forwarders >> for L4-higher SFs for MAC Chaining and understand this problem in a >> lot of detail. Having two unidirectional chains don't solve the >> forward/reverse traffic problem because the reverse path SPI/SI are >> not included in the NSH header and therefore not available at the >> time we need to reverse the forwarding direction. Are you mandating >> every SF and Proxy be provisioned with the forward and reverse >> SPI/SI? If so the solution is unacceptable to me. >> >> >>> 3)there is no resolution to encoding hierarchies which are of >>> importance to SFC applications in NFV environments, >> >> PQ> Encoding hierarchies is an optimization of the base protocol to >> support scaling in a large deployment; in any case such >> optimization does not require changes to the base SFC >> encapsulation. PB> A general stacking solution will require some >> type of support which I believe should be in the base header so the >> context words are kept clear for pure meta-data. >> >>> 4)the draft needs a transport service interface and a description >>> of the mappings used for the service layer onto the transport >>> layer, >> >> PQ> I am not sure what you mean by "transport service interface" - >> it is true that the SPI/SI need to map to a transport layer >> forwarding entry but I don't know what you are implying. PB>You are >> trying to specify a "transport" independent layer, however have not >> specified what services the transport must provide to support the >> SFC layer. A service interface is one of the formalized ways to >> specify the feature requirements of the underlying layer. >> >>> 5)the draft specifies two independent formats for encoding the >>> NSH header which is likely to divide the market slowing the >>> deployment of NSH. >> >> PQ> The draft actually specifies two metadata formats for >> flexibility and the market will decide which is most appropriate >> based on specific use cases. The evidence is clear: a wide-range >> of _implementations_ already exist. In fact, the real impediment to >> deployment is esoteric opinion. PB> This is always the last resort >> dodge we use in standards, however it always comes at the price of >> some market confusion and delay. Even though I can accept this if >> no middle ground is possible, I don't think we have pushed the >> parties hard enough toward a converged solution to give it up on it >> yet. >> >>> >>>> From my point of view the SFC formed service plane layer >>>> network with a peer dialog between the SCF, SFF and SF. The >>>> Service Path Header (SPI+SI) forms the address for this service >>>> plane. As it stands there is an attempt to overload the >>>> function of the SI as both the SF identifier with the Service >>>> Path and as a form of loop detection, however the coupling has >>>> resulted in two problems: >>> 1)Since every SF in a path must have a sequential SI, in the >>> event we need to insert or delete a SF it is necessary to update >>> the SFF forwarding entries for the entire chain. To fix this >>> either the SI should be allowed to take non-sequential values >>> along the chain or should not be used for SF addressing. >> >> PQ> This is not a true statement; if an SF needs to be added or >> deleted then it is necessary to update the SFF forwarding entries >> for all SFFs downstream of where the change occurs. PB> Agreed, I >> stand corrected. >> >> >>> 2)Since the SI is only decremented on SF hops it can't guard >>> against a loop between SFFs or SCFs, hence SI is not a reliable >>> method for loop squelching. If a TTL is needed it needs to be >>> separated from SI. Given that there is no clear alternative to >>> TTL for loop squelching at the service layer I believe we do need >>> to include an effective TTL to go forward. >> >> PQ> The SI can provide a simple loop check within the serivce plane >> but it's primary semantic value is one of location. The transport >> itself can provide loop detection as well as SFF verification of >> SPI/SI + source. PB> I both disagree that SI is useful for loop >> squeltching or that "transport" TTL can stop service layer looping. >> To use the "transport" TTL the field would need to be copied from >> one "transport" to the next "transport" over the SFC service layer. >> Disregarding the fact that this operation is building a dependency >> between the "transport" and service layers, which we expressly are >> trying to avoid, the TTL fields of the transports are not sized to >> allow for the expanded path lengths which could be created in >> chains. In addition, some of the transports like Ethernet only >> support TTL for in special cases (Ethernet only supports TTL when >> using F-Tag forwarding). >> >>> 3)Every other successful address space has needed to add a few >>> bits to support QoS options. I would suggest taking 3-4 bits from >>> the MD-type and to reserve for QoS handling. >> >> PQ> Again, this is blurring the lines: QoS is handled, as expected >> by the selection transport. This is a feature, not a bug, >> architecturally speaking. PB> Just the opposite, failing to add QoS >> to the NSH header is blurring the lines between the service layer >> and the "transport" layer. Consider an a chain which uses both a >> best effort and an expedited service. Next consider building the >> chain where each hop uses a different type of "transport". As we >> map from one "transport" to the next we may over some hops have >> less QoS information than others. As we continue to the next >> "transport" we retain the integrity of the end-to-end communication >> by regenerating QoS from the original QoS contained at the service >> layer a driven down into the "transport". >> >>> 4)In may data centers we have multi-vendor deployments. In these >>> environments we may have different managers assigning chains. >>> There should to be some convention for splitting the address >>> space between these vendors. The most desirable solution to this >>> is to add an assigned organization ID to the address space. An >>> alternative would be to separate the SPI into a 4 and 20 bit >>> field designating the high 4 bits as a local manager ID. >>> >> >> PQ> You are conflating federation/configuration and frame format. >> The multi-manager scenario is a control-plane/management-plane >> function. PB> In a multi-manager situation I need a way to avoid >> collision in the allocation of the SPI/SI space which is being >> independently allocated by different managers. >> >> _______________________________________________ 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 Mon Apr 18 23:43: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 450DE12D55E for ; Mon, 18 Apr 2016 23:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JGnuAVA1TgpK for ; Mon, 18 Apr 2016 23:43:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C456C12D0C6 for ; Mon, 18 Apr 2016 23:43:02 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0C79F3B454F; Tue, 19 Apr 2016 08:43:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D8C9335C05A; Tue, 19 Apr 2016 08:43:00 +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.0279.002; Tue, 19 Apr 2016 08:43:00 +0200 From: To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRmWb0PGjqacyz9EidOrx7rW39tJ+P1pwAgAECt7A= Date: Tue, 19 Apr 2016 06:42:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5C3B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D5BB09@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D5C3B4OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416 Archived-At: Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 19 Apr 2016 06:43:07 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D5C3B4OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, I'm puzzled here. Why do we need a large range of =AB TLV Class =BB? Would= n't few bits be sufficient (e.g., 3 or 4 bits)? Thank you. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : lundi 18 avril 2016 17:21 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: [sfc] TLV class of variable-length metadata should have a restr= icted range Med, I was discussing the "TLV Class" field, which is 16 bits. But thank you for finding the BCP for writing IANA considerations. -Dave From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, April 18, 2016 7:39 AM To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] TLV class of variable-length metadata should have a rest= ricted range Hi Dave, all, Thank you for raising this point. IANA considerations should be sketched in reference to RFC5226 (see https:/= /tools.ietf.org/html/rfc5226#section-4.1). IMO, it is reasonable to define ranges: =B7 assigned via Standards Action =B7 assigned via Specification Required =B7 reserved for Private Use =B7 reserved for Experimental Use Note that the ranges you are proposing are not aligned with the current TLV= encoding (Type is encoded in 7 bits). Saying that, I still do see value in reusing existing rich registries such = as IPFIX. Doing so allows to use immediately a code point while ensuring in= teroperability. A dedicated field in the encoding of the TLV can be defined= (or adjust TLV Class?) to point to the registry in use. BTW, the IANA section should include more details about "TLV Class". Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : jeudi 14 avril 2016 17:25 =C0 : sfc@ietf.org Objet : [sfc] TLV class of variable-length metadata should have a restricte= d range Regarding the TLV Class of variable-length metadata, https://tools.ietf.org= /html/draft-ietf-sfc-nsh-04#section-3.5.1 It is common for such fields to reserve ranges, allowing for future growth = into unanticipated uses. E.g., off the top of my head, classes 0 to 0x1ff --> types allocated by IETF classes 0x200 to 0x7fff --> allocated by IANA Classes 0x8000 to 0xbfff --> reserved, do not use classes 0xc000 to 0xefff --> locally administered classes 0xf000 to 0xffff --> experimental Or similar? I'm not sure what the best practice for this is. Generally, I'd want to try something experimentally before requesting IANA = allocation for it (experimental), or maybe types are too specific to warrant IANA allocation (locally adminis= tered). Can something like this be added to draft-ietf-sfc-nsh ? David Dolson Senior Software Architect, Sandvine Inc. --_000_787AE7BB302AE849A7480A190F8B933008D5C3B4OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

I’m puzzled here. Why do = we need a large range of =AB TLV Class =BB?  Wouldn’t = few bits be sufficient (e.g., 3 or 4 bits)?

 

Thank you.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : lundi 18 avril 2016 17:21
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: [sfc] TLV class of variable-length metadata should = have a restricted range

 

Med,

I was d= iscussing the “TLV Class” field, which is 16 bits.

&n= bsp;

But tha= nk you for finding the BCP for writing IANA considerations.

&n= bsp;

&n= bsp;

&n= bsp;

-Dave

&n= bsp;

&n= bsp;

&n= bsp;

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, April 18, 2016 7:39 AM
To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] TLV class of variable-length metadata should have= a restricted range

 

Hi Dave, all,

 

Thank you for raising this poin= t.

 

IANA considerations should be s= ketched in reference to RFC5226 (see https://tools.i= etf.org/html/rfc5226#section-4.1).

 

IMO, it is reasonable to define= ranges:

=B7    &n= bsp;    assigned via Standards = Action

=B7    &n= bsp;    assigned via Specificat= ion Required

=B7    &n= bsp;    reserved for Private Us= e

=B7    &n= bsp;    reserved for Experiment= al Use

 

Note that the ranges you are pr= oposing are not aligned with the current TLV encoding (Type is encoded in 7= bits).

 

Saying that, I still do see val= ue in reusing existing rich registries such as IPFIX. Doing so allows to us= e immediately a code point while ensuring interoperability. A dedicated field in the encoding of the TLV can be defined (or adjust TLV= Class?) to point to the registry in use.

 

BTW, the IANA section should in= clude more details about “TLV Class”.

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : jeudi 14 avril 2016 17:25
=C0 : sfc@ietf.org
Objet : [sfc] TLV class of variable-length metadata should have= a restricted range

 

Regarding the TLV Class of vari= able-length metadata, https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1

It is common for such fields to= reserve ranges, allowing for future growth into unanticipated uses.

 

E.g., off the top of my head,

classes 0 to 0x1ff --> types= allocated by IETF

classes 0x200 to 0x7fff --> = allocated by IANA

Classes 0x8000 to 0xbfff -->= reserved, do not use

classes 0xc000 to 0xefff -->= locally administered

classes 0xf000 to 0xffff -->= experimental

 

Or similar? I’m not sure = what the best practice for this is.

 

Generally, I’d want to tr= y something experimentally before requesting IANA allocation for it (experi= mental),

or maybe types are too specific= to warrant IANA allocation (locally administered).

 

Can something like this be adde= d to draft-ietf-sfc-nsh ?

 

 

David Dolson<= /p>

Senior Software Architect, Sand= vine Inc.

 

--_000_787AE7BB302AE849A7480A190F8B933008D5C3B4OPEXCLILMA3corp_-- From nobody Tue Apr 19 00:48: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 E646212ECDD; Tue, 19 Apr 2016 00:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 qta8yqIGRUhM; Tue, 19 Apr 2016 00:48:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2BD12D629; Tue, 19 Apr 2016 00:48:07 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4CA7D18C5D6; Tue, 19 Apr 2016 09:48:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2A94E35C06A; Tue, 19 Apr 2016 09:48:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Tue, 19 Apr 2016 09:48:05 +0200 From: To: Loa Andersson , "sfc@ietf.org" , "draft-ietf-sfc-nsh@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqtfmDbftCilE6QL9AG6Y6vN5+Q4utQ Date: Tue, 19 Apr 2016 07:48:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <57133AED.4080005@pi.nu> In-Reply-To: <57133AED.4080005@pi.nu> 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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 19 Apr 2016 07:48:10 -0000 Dear Loa, all,=20 Thank you for raising this point about the encoding of the optional context= information. =20 I agree that the use of TLV term is confusing. What about using another ter= m, e.g., "Information Elements", "Options", or "Context Element"?=20 As an input to this discussion, below a proposal for an encoding that achie= ves the following goals: * Shorten the encoding of the Class field. * Allow for more type code points. * Avoids requiring padding for the sake of compact headers. * Allows to include the ID of the entity that injected the context informat= ion (OPTIONAL).=20 * Inherit rich registries such as IPFIX. NOTE: This proposal does not include a dedicated flag bit to indicate wheth= er the context element is mandatory-to-process or optional-to-process becau= se further discussion/text specification is required: e.g., * Wouldn't be sufficient to supply that information using the control plane= ? * If that information is supplied in both the context element and configure= d to a SFC-aware function, how conflicts are managed? * What is the behavior for processing mandatory-to-process elements (partic= ularly, when it is not supported)? =20 * Is it required to recommend an ordering of supplying the mandatory-to-pro= cess or optional-to-process elements? * Is it required to preserve the same ordering when forwarding a packet? =3D=3DPROPOSAL=3D=3D=3D=3D =20 Base version 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class | Type | FLAGS | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Data (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version with Originator ID: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class | Type | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ //Originator Len| Originator ID (Variable)(Optional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Data (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The description of the fields is as follows: Class: In order to foster service innovation, this field allows to inherit from existing code point registries that are likely to be useful in a SFC context. The following values are reserved by this specification: 0: See IANA section. 1: IPFIX [IPFIX]. Type: Indicates the code point of the context element. If "Class" field is non-null, the interpretation of this field MUST conform to the one defined for that specific class registry. See I= ANA section. Flags: The Flags field comprises a set of 4 flags: +-+-+-+-+ |S|r|r|r| +-+-+-+-+ where "rrr" are reserved bits for future assignment as additional flag bits. r bits MUST each be sent as zero and MUS= T be ignored on receipt. When set, the S-flag indicates that an Originator ID field is present in the context element. This flag is set by default t= o 0, meaning there is no Originator ID field present in the element. Originator ID (Optional): Conveys the identifier of the entity that = injected this context element in the NSH header (e.g., a service function identifier, a classifier, etc.). This document does not make any assumption about the structure of the information carried in this field because this is deployment-specific. This information is used by SFC-aware elements to enforce policies such as: process a context information if and only if it was supplied by a given entity. This information can be used as a safeguard against misbehaving nodes that inject illegitimate data in the NSH header. This field MUST be included only if S-bit is set. =20 Length: Indicates, in octets, the length of the data carried in the context element. Data (Variable): The semantics of this field depend on the "Class" and "Type" fields. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Opinions? Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson > Envoy=E9=A0: dimanche 17 avril 2016 09:28 > =C0=A0: sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > Objet=A0: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on > TLVs in draft-ietf-sfc-nsh >=20 > Working Group, authors, >=20 > I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read > it before now) and have a question on how the TLV concept is understood > in the draft. >=20 > For example in LDP TLV were defined as Type, Length Value, e.g. (from > RFC 5036 section 3.3): >=20 > LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of > the information carried in LDP messages. >=20 > An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify > a Type and 2 bits to specify behavior when an LSR doesn't recognize > the Type, followed by a 2 octet Length field, followed by a variable > length Value field. >=20 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Value | > ~ ~ > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated > and I'm struggling a bit to understand if the "name" TLV should be used. >=20 > From draft-ietf-sfc-nsh-04 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Metadata | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Figure 6: Variable Context Headers >=20 > The draft is not entirely clear in this respect, but I think this is > what you call a TLV. >=20 > Should I understand this way? >=20 > Type =3D TLV Class + C + Type (24 bits) > Length =3D len (5 bits) > Value =3D Variable Metadata >=20 > A convention we used in MPLS when we have variable length fields is > to use a ~ instead of the |, like this:. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Variable Metadata ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > I suggest that this is a good practice that could be adopted here also. >=20 > Two more questions: >=20 > If the metadata does not align exactly with the 32 bit/4 byte structure, > what is the rules for padding? >=20 > A last, but a bit different question, do you need indicators like the U > and F flags in an to indicate what should happen if the node does not > recognize the (TLV Class, C, Type)-field? >=20 > /Loa >=20 >=20 > PS >=20 > I will also have a few more editorial comments that will be sent to > the authors within a day or two. >=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 19 13:16:02 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 A885C12D635 for ; Tue, 19 Apr 2016 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 5VsDSjEBTqYO for ; Tue, 19 Apr 2016 13:15:58 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 1ED9F12DE0A for ; Tue, 19 Apr 2016 13:15:58 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id f74so14770218qge.2 for ; Tue, 19 Apr 2016 13:15:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jI5FH0XP6sLJF2SjHXfahU2U8R5OgJ+H8H3GEcWBRQg=; b=T/ZQMhruIsd+06UBPzqOsiVwRCf2e1v23IOdvkV9+oQLtVWdQ7IurKny67AhblwUcW c2KsuiL2e/ts+PL76QZ3uoKEZVIuYduKhnaFpGByc4LClSlEVAsNjy0XKojTR89CBUuS y+DkVXCcAISelQqw/bR2fCy8R/Hqy0R8ssR9ELKl8TvYU3EItgnInsgldweyl5zFgSYJ efoNJuYNERZfY9sB8PlpaPSQ6OnQHQgjnAwpMcMxHY1IGSQsnxZpEifpp86Gf+Ddr04R Yrt9MgO+E/0ipLj0nxAB6iBOlY5zDL+UIL98oJAEDzq3FnVEVQoC2hzBKjVR1ioz03pX 3axw== X-Gm-Message-State: AOPr4FUgCwTcmcVswQ7dZ1onO9G8WOra2V1zSsybdHBNchi0xV6qedcO9A8P1F1xeNYk0zxG X-Received: by 10.140.82.20 with SMTP id g20mr6004310qgd.69.1461096957058; Tue, 19 Apr 2016 13:15:57 -0700 (PDT) Received: from wlan-196-77.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id l66sm18969878qhc.42.2016.04.19.13.15.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Apr 2016 13:15:56 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Azhar Sayeed In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 19 Apr 2016 16:16:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57133AED.4080005@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 19 Apr 2016 20:16:01 -0000 Hi Med, You can still encode this as a TLV by re-arranging the fields with Type = first, length and then value - In the value portions you can a mandatory = bytes that encode the flags, class, originator id and then variable = metadata So here is an option. Type - 16 bits Length - 16 bits Value: Flags - 4 bits Class - 4 bits Originator Length - 8 bits Originator ID - Variable Data Variable +1 to the idea of originator id. Azhar > On Apr 19, 2016, at 3:48 AM, mohamed.boucadair@orange.com wrote: >=20 > Dear Loa, all,=20 >=20 > Thank you for raising this point about the encoding of the optional = context information. =20 >=20 > I agree that the use of TLV term is confusing. What about using = another term, e.g., "Information Elements", "Options", or "Context = Element"?=20 >=20 > As an input to this discussion, below a proposal for an encoding that = achieves the following goals: >=20 > * Shorten the encoding of the Class field. > * Allow for more type code points. > * Avoids requiring padding for the sake of compact headers. > * Allows to include the ID of the entity that injected the context = information (OPTIONAL).=20 > * Inherit rich registries such as IPFIX. >=20 > NOTE: This proposal does not include a dedicated flag bit to indicate = whether the context element is mandatory-to-process or = optional-to-process because further discussion/text specification is = required: e.g., > * Wouldn't be sufficient to supply that information using the control = plane? > * If that information is supplied in both the context element and = configured to a SFC-aware function, how conflicts are managed? > * What is the behavior for processing mandatory-to-process elements = (particularly, when it is not supported)? =20 > * Is it required to recommend an ordering of supplying the = mandatory-to-process or optional-to-process elements? > * Is it required to preserve the same ordering when forwarding a = packet? >=20 > =3D=3DPROPOSAL=3D=3D=3D=3D =20 >=20 > Base version > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Class | Type | FLAGS | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // Data (Variable) = // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Version with Originator ID: > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Class | Type | Flags | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > //Originator Len| Originator ID (Variable)(Optional) // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // Data (Variable) = // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The description of the fields is as follows: >=20 > Class: In order to foster service innovation, this field > allows to inherit from existing code point registries that are > likely to be useful in a SFC context. The following values = are > reserved by this specification: > 0: See IANA section. > 1: IPFIX [IPFIX]. >=20 > Type: Indicates the code point of the context element. If > "Class" field is non-null, the interpretation of this field = MUST > conform to the one defined for that specific class registry. = See IANA section. >=20 > Flags: The Flags field comprises a set of 4 flags: >=20 > +-+-+-+-+ > |S|r|r|r| > +-+-+-+-+ >=20 > where "rrr" are reserved bits for future assignment as > additional flag bits. r bits MUST each be sent as zero and = MUST be > ignored on receipt. >=20 > When set, the S-flag indicates that an Originator ID field = is > present in the context element. This flag is set by = default to 0, meaning > there is no Originator ID field present in the element. >=20 > Originator ID (Optional): Conveys the identifier of the entity = that injected > this context element in the NSH header (e.g., a service > function identifier, a classifier, etc.). This document does > not make any assumption about the structure of the information > carried in this field because this is deployment-specific. > This information is used by SFC-aware elements to enforce > policies such as: process a context information if and only if > it was supplied by a given entity. This information can be > used as a safeguard against misbehaving nodes that inject > illegitimate data in the NSH header. >=20 > This field MUST be included only if S-bit is set. =20 >=20 > Length: Indicates, in octets, the length of the data carried in > the context element. >=20 > Data (Variable): The semantics of this field depend on the > "Class" and "Type" fields. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Opinions? >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson >> Envoy=E9 : dimanche 17 avril 2016 09:28 >> =C0 : sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org >> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions = on >> TLVs in draft-ietf-sfc-nsh >>=20 >> Working Group, authors, >>=20 >> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >> it before now) and have a question on how the TLV concept is = understood >> in the draft. >>=20 >> For example in LDP TLV were defined as Type, Length Value, e.g. (from >> RFC 5036 section 3.3): >>=20 >> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much = of >> the information carried in LDP messages. >>=20 >> An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify >> a Type and 2 bits to specify behavior when an LSR doesn't = recognize >> the Type, followed by a 2 octet Length field, followed by a = variable >> length Value field. >>=20 >>=20 >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |U|F| Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | Value | >> ~ ~ >> | | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >> and I'm struggling a bit to understand if the "name" TLV should be = used. >>=20 >> =46rom draft-ietf-sfc-nsh-04 >>=20 >> 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 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >>=20 >> Figure 6: Variable Context Headers >>=20 >> The draft is not entirely clear in this respect, but I think this is >> what you call a TLV. >>=20 >> Should I understand this way? >>=20 >> Type =3D TLV Class + C + Type (24 bits) >> Length =3D len (5 bits) >> Value =3D Variable Metadata >>=20 >> A convention we used in MPLS when we have variable length fields is >> to use a ~ instead of the |, like this:. >>=20 >> 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 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ Variable Metadata = ~ >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> I suggest that this is a good practice that could be adopted here = also. >>=20 >> Two more questions: >>=20 >> If the metadata does not align exactly with the 32 bit/4 byte = structure, >> what is the rules for padding? >>=20 >> A last, but a bit different question, do you need indicators like the = U >> and F flags in an to indicate what should happen if the node does not >> recognize the (TLV Class, C, Type)-field? >>=20 >> /Loa >>=20 >>=20 >> PS >>=20 >> I will also have a few more editorial comments that will be sent to >> the authors within a day or two. >>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 19 19:35:23 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 F1C5012EA6C; Tue, 19 Apr 2016 19:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 YbJq3iB3eOpQ; Tue, 19 Apr 2016 19:35:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0739112EA6A; Tue, 19 Apr 2016 19:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7316; q=dns/txt; s=iport; t=1461119719; x=1462329319; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1dppRpFirN6bt+qNoI/9r8RX7GHArczF232wwmpzLf0=; b=A8fOcW4JAmTQMu8rmf2GDRyUVpunnxXtwgLyuPfzmKqxj0C9ySl8JGo6 qqdkLsnrz8zeKGMwr2kg81JvusIzojUBt2XE6Ytsv1vCug0NE6bIQsRZM xac/zdEBa9ODxk0TT84AkGyjJK9p2YtJgRM+AYQrS339WtujCybZV9maC M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAwCz6RZX/5xdJa1egzhTfQa5cg6Bc?= =?us-ascii?q?RcLghiDVAKBRjgUAQEBAQEBAWUnhEEBAQEDAQEBARoGRAQDCwUJAgIBCBgqAgI?= =?us-ascii?q?bDAslAgQOBQ6IEwgOrAWRPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBASGHYF1g?= =?us-ascii?q?laEDxEBgx4rgisFjVOFS4RwAYMngWZtiBiBZod3hTSPKwEeAUOCM4E1bAGHXjZ?= =?us-ascii?q?+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,507,1454976000"; d="asc'?scan'208";a="99177277" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 02:35:18 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3K2ZIgn018186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 02:35:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 22:35:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 19 Apr 2016 22:35:17 -0400 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqvPG9+wCOo5UWLeYjmbm2Pnp+SbKQA Date: Wed, 20 Apr 2016 02:35:17 +0000 Message-ID: <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> References: <57133AED.4080005@pi.nu> In-Reply-To: <57133AED.4080005@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.251.155] Content-Type: multipart/signed; boundary="Apple-Mail=_BB565229-06DF-4A73-8288-A0788411007E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 02:35:22 -0000 --Apple-Mail=_BB565229-06DF-4A73-8288-A0788411007E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Loa, Good analysis on the format of these information elements. My sense is that a hierarchical syntax (such as the = Class/Type-Length-Value) provides much more flexibility than a flat = Type-Length-Value alone. We=E2=80=99ve built quite a number of protocols with this structure and = allocation scheme. For example, RSVP = (https://tools.ietf.org/html/rfc3209#section-7.2), L2TPv3 = (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP Multi-Part = Extensions (https://tools.ietf.org/html/rfc4884#section-8). Regardless of what we call the fields (e.g., Class and Type, or Type and = Sub-Type, or =E2=80=A6), there are clear technical advantages to this, = including the ability to delegate allocation, vendor types, etc. In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs = achieves what=E2=80=99s really needed for an SFC Encap. Lastly, you call out padding and 32-bit-word alignment. This is a great = point. The way things seems structured now, there=E2=80=99s a Len field = measured in 32-bit words. It=E2=80=99s not clear what happens when the = Metadata (Value) itself is not 32-bit-word-aligned. This needs fixing. Looking at the Length definition: Length: Length of the variable metadata, in 4-byte words. A value of 0x0 or higher can be used. A value of 0x0 denotes a TLV header without a Variable Metadata field. Comments: * First, instead of =E2=80=9C4-byte=E2=80=9D words, this needs to be = =E2=80=9C4-octet=E2=80=9D or =E2=80=9C32-bit=E2=80=9D words. Byte is = strictly machine dependent (7 bits, 8 bits, etc). * Second, =E2=80=9Ca value of 0x0 or higher=E2=80=9D for an unsigned = value does not say much. Hope these help. Thanks, =E2=80=94 Carlos. > On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >=20 > Working Group, authors, >=20 > I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read > it before now) and have a question on how the TLV concept is = understood > in the draft. >=20 > For example in LDP TLV were defined as Type, Length Value, e.g. (from > RFC 5036 section 3.3): >=20 > LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of > the information carried in LDP messages. >=20 > An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify > a Type and 2 bits to specify behavior when an LSR doesn't recognize > the Type, followed by a 2 octet Length field, followed by a variable > length Value field. >=20 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Value | > ~ ~ > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated > and I'm struggling a bit to understand if the "name" TLV should be = used. >=20 > =46rom draft-ietf-sfc-nsh-04 >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Metadata = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Figure 6: Variable Context Headers >=20 > The draft is not entirely clear in this respect, but I think this is = what you call a TLV. >=20 > Should I understand this way? >=20 > Type =3D TLV Class + C + Type (24 bits) > Length =3D len (5 bits) > Value =3D Variable Metadata >=20 > A convention we used in MPLS when we have variable length fields is > to use a ~ instead of the |, like this:. >=20 > 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 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Variable Metadata = ~ > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > I suggest that this is a good practice that could be adopted here = also. >=20 > Two more questions: >=20 > If the metadata does not align exactly with the 32 bit/4 byte = structure, > what is the rules for padding? >=20 > A last, but a bit different question, do you need indicators like the = U > and F flags in an to indicate what should happen if the node does not > recognize the (TLV Class, C, Type)-field? >=20 > /Loa >=20 >=20 > PS >=20 > I will also have a few more editorial comments that will be sent to > the authors within a day or two. >=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_BB565229-06DF-4A73-8288-A0788411007E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXFurkAAoJEIXgpQGOZny988QP/jJmnzUoX7xWAiGCZ1/htuX+ pHyLXpfJH6okVrHRoIbeB9uaGbNio3+AEoQYtB1caRdUEPx98FZvZoso/UnZndSF 08cVyP3+A7BpOSBh9/1u1xlTjtZzfIJH/AMyRt4dCH1D7qqejVJ+n1JAAPyuhIYt 7ncuQAtrYt/0yJXktroz+J9iTScAD6zBdcaqbVqAzkbdgkP9AVExQKK/pj9Nl3ii 23dbOxDSTYagELNL8miOyjUY+CuxjaFwoETRIQohY7BUDKqBNZUzQDmHK32ThctI 1G4+Vh0Q76wYdWWk0N/KkXou6csAeZjPvyrGHz19gpm7cakwGZz0hoWXdBUJMkGA NURGU7yPMRROx33nVRY2ZlZw+W2/UKFtHdfKiuBP7AXEphCRa88GyHI86t3m4Cmx mCkyLEOyxSGhqDKCefVoYqUMdaN9yM9okEP/znYN7Qc+c+3bb/5qpybDW/KLC2ZB WLJgWQdTUT5Vyw4BOhJ1VIuBpgFEHAXGvlxYzAWKjA8BpnRcgaUGoqNNgO0nDza8 26spzRG2HabW+rjrRbDlVaPhDNMEn8ggRlnS/pWO9sNYDkEp9E1eTLtgWfTHUba0 z4rvtHT1t2RkTJJw9656vcFYavwYydVDyTir4Qe8+C84fK/I7JUQtgR1Vx1IdIgM NY1+BRMIX5FE8V321tXX =i94P -----END PGP SIGNATURE----- --Apple-Mail=_BB565229-06DF-4A73-8288-A0788411007E-- From nobody Tue Apr 19 19:41: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 1698B12EAC5; Tue, 19 Apr 2016 19:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 N997cdt4W06b; Tue, 19 Apr 2016 19:41:55 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417F312EAC4; Tue, 19 Apr 2016 19:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7219; q=dns/txt; s=iport; t=1461120115; x=1462329715; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7SisTyZyfYPtjFb+id/MKPdR6gKoN3Utrt8MUY0AzUM=; b=f6Lvexa1H5+giwODBo7GFYKU7Ski3+HMRHymDAXI4ez29qdVNHWw3r5X DIelTPygNZO4/d9FwDR61aY8gPtb7Rfb/IvvYYTGJMQ9B+RddRkAy9mwv F6DfkZlre0T8fwVQVlmtzk9AAPBByKWd8hgKrlnefhf4/j0pEQjKZw4k+ E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAwCA6xZX/5BdJa1egzhTfQa5cg6Bc?= =?us-ascii?q?RcLghiDVAKBRjgUAQEBAQEBAWUnhEEBAQEDAQEBARoGRAQDCwUJAgIBBgIOCio?= =?us-ascii?q?CAhsMCyUCBA4FDogTCA6OcJ0XkT4BAQEBAQEBAQEBAQEBAQEBAQEBAQENBAQEh?= =?us-ascii?q?h2BdQiCToQPEQGDHiuCKwWNU4o7AYMngWaJBYFmh3eFNI8rAR4BQ4IzgTVsh18?= =?us-ascii?q?2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,507,1454976000"; d="asc'?scan'208";a="262047823" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 02:41:54 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3K2frBm006496 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 02:41:54 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 22:41:52 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 19 Apr 2016 22:41:52 -0400 From: "Carlos Pignataro (cpignata)" To: Azhar Sayeed Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqvPG9+wCOo5UWLeYjmbm2Pnp+QEKeAgAJd1QA= Date: Wed, 20 Apr 2016 02:41:52 +0000 Message-ID: <592C0220-7CE8-46A6-8181-2AA7EF1CA63D@cisco.com> References: <57133AED.4080005@pi.nu> <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> In-Reply-To: <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.251.155] Content-Type: multipart/signed; boundary="Apple-Mail=_2BA9FAD3-8161-4976-92EB-3781E872F0F1"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 02:41:57 -0000 --Apple-Mail=_2BA9FAD3-8161-4976-92EB-3781E872F0F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Azhar, -1 :-) Within the IETF-specified protocols, we can certainly find examples of = most syntax and structures, from the simple to the too creative ones. = Finding a protocol with a specific TLV structure does not mean that = that=E2=80=99s the best for every protocol use. You say: "This should also be consistent=E2=80=9D. However, just to understand your point, what is the technical reason for = NSH TLV structs having to match BFD structs and ISIS structs? And why = not, say, RSVP=E2=80=99s or ICMP Multipart=E2=80=99s or L2TPv3=E2=80=99s = (which, incidentally, use a Class/Type-length-value format)? When you say =E2=80=9C to align with all the other TLV=E2=80=99s = structure=E2=80=9D =E2=80=94 I ask: why? If we think of the goal of flexibility (main goal of Type 2) in the = context of most flexible allocation, a hierarchical scheme is a = technical answer. Given the rich ecosystem of vendors and open source = projects, the proposed structure, in my humble opinion, future proofs = the design. =E2=80=94 Carlos. > On Apr 18, 2016, at 10:33 AM, Azhar Sayeed wrote: >=20 > Loa, >=20 > +1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs have = the same structure - This should also be consistent..the question then = is can the current TLV structure in draft-~nsh-04 be re-configured to = align with all the other TLV=E2=80=99s structure? >=20 > Azhar >=20 >=20 >> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>=20 >> Working Group, authors, >>=20 >> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >> it before now) and have a question on how the TLV concept is = understood >> in the draft. >>=20 >> For example in LDP TLV were defined as Type, Length Value, e.g. (from >> RFC 5036 section 3.3): >>=20 >> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of >> the information carried in LDP messages. >>=20 >> An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify >> a Type and 2 bits to specify behavior when an LSR doesn't recognize >> the Type, followed by a 2 octet Length field, followed by a variable >> length Value field. >>=20 >>=20 >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |U|F| Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | Value | >> ~ ~ >> | | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >> and I'm struggling a bit to understand if the "name" TLV should be = used. >>=20 >> =46rom draft-ietf-sfc-nsh-04 >>=20 >> 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 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >>=20 >> Figure 6: Variable Context Headers >>=20 >> The draft is not entirely clear in this respect, but I think this is = what you call a TLV. >>=20 >> Should I understand this way? >>=20 >> Type =3D TLV Class + C + Type (24 bits) >> Length =3D len (5 bits) >> Value =3D Variable Metadata >>=20 >> A convention we used in MPLS when we have variable length fields is >> to use a ~ instead of the |, like this:. >>=20 >> 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 >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len = | >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ Variable Metadata = ~ >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> I suggest that this is a good practice that could be adopted here = also. >>=20 >> Two more questions: >>=20 >> If the metadata does not align exactly with the 32 bit/4 byte = structure, >> what is the rules for padding? >>=20 >> A last, but a bit different question, do you need indicators like the = U >> and F flags in an to indicate what should happen if the node does not >> recognize the (TLV Class, C, Type)-field? >>=20 >> /Loa >>=20 >>=20 >> PS >>=20 >> I will also have a few more editorial comments that will be sent to >> the authors within a day or two. >>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=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 --Apple-Mail=_2BA9FAD3-8161-4976-92EB-3781E872F0F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXFuxwAAoJEIXgpQGOZny91OQQAI5SCL4ZgkzdnswnNz7dudIv x2N1AlGM7CbKeg9pktzuCyh4PAnK0AglOFHxN19e1bueZYmzoW8B9Uz4OWk/REb9 nzvTjSR/D4u1lOzk7tiVVHGxuIWGCmAsV/SSynqHyrUGQU+OCAYf2Yqtms1wX+e1 6vWxlYqAfQf+IWyvD9slVAcjlSuQILhpTy0ZIi3ojjPoXtnGLYhOSGxnxhLAY69t VFmQayB7Lk12eGvYaFXbmyrk5535/496iB/RAJFlgYZ3hwXb7u07azsgvfjeYtHa o1TOCkejN4zwtkGfF5Ceh9NZFItg6pkV8dmKB3Fq2VRmA7od5dkEMXtEk1DVqfP6 XFthPM/La5RvrUbMmLoEUVtxXGMOSUaf77JGd3VMzOdX2EoCQRs9bLvFaP9Dw0+k r2sduHehRPgP3fqq9af0wiNm0eaVxp2NIC8SM/uuDmwbzGr4cBKfWGUKnu8qpaw7 kY2QukMNEGuDVv+06ToSbK28VlxJ2GIEwafdKNNrBJlNSIbCKmSQwhPQUypNVvwU 66lNN4/g3ZFqYcM8gr/tDhgTtpw7gepMHJWV/gTBOj5wcrUNAfPaaDUu9oA/tKxq Nu8yrDYQiXsZqYuiJ28cPNBAH+D5YxEvGqi8lkbmEJYEqkAjh/3h9+ry3Gm3b8XP pMqXf6bfM3Z2TQUAL3PC =oYOk -----END PGP SIGNATURE----- --Apple-Mail=_2BA9FAD3-8161-4976-92EB-3781E872F0F1-- From nobody Tue Apr 19 22:44:49 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 977AF12D706; Tue, 19 Apr 2016 22:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 IDIm_dH1At3l; Tue, 19 Apr 2016 22:44:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6616E12E13D; Tue, 19 Apr 2016 22:44:44 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9646F32448D; Wed, 20 Apr 2016 07:44:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7381727C066; Wed, 20 Apr 2016 07:44:42 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Wed, 20 Apr 2016 07:44:42 +0200 From: To: Azhar Sayeed Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmnhJd43LowhZakKM36eRU4WnUJ+SVxCQ Date: Wed, 20 Apr 2016 05:44:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5CBB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <57133AED.4080005@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5C41E@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.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.20.51518 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 05:44:47 -0000 Hi Azhar,=20 Thank you for the feedback and the support for the originator ID.=20 The re-arranging of the fields you propose is indeed another option, but it= does not allow a compact header, e.g., 16 bits for the length is too much = for the cases I'm aware of + it is not optimal if no originator ID is to be= supplied for instance.=20 Having the class, type, flags, and length in the first 32 bits would lead t= o a compact header.=20 Cheers, Med > -----Message d'origine----- > De=A0: Azhar Sayeed [mailto:asayeed@redhat.com] > Envoy=E9=A0: mardi 19 avril 2016 22:17 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Question= s > on TLVs in draft-ietf-sfc-nsh >=20 > Hi Med, >=20 > You can still encode this as a TLV by re-arranging the fields with Type > first, length and then value - In the value portions you can a mandatory > bytes that encode the flags, class, originator id and then variable > metadata >=20 > So here is an option. >=20 > Type - 16 bits > Length - 16 bits > Value: > Flags - 4 bits > Class - 4 bits > Originator Length - 8 bits > Originator ID - Variable > Data Variable >=20 > +1 to the idea of originator id. >=20 >=20 > Azhar >=20 >=20 >=20 > > On Apr 19, 2016, at 3:48 AM, mohamed.boucadair@orange.com wrote: > > > > Dear Loa, all, > > > > Thank you for raising this point about the encoding of the optional > context information. > > > > I agree that the use of TLV term is confusing. What about using another > term, e.g., "Information Elements", "Options", or "Context Element"? > > > > As an input to this discussion, below a proposal for an encoding that > achieves the following goals: > > > > * Shorten the encoding of the Class field. > > * Allow for more type code points. > > * Avoids requiring padding for the sake of compact headers. > > * Allows to include the ID of the entity that injected the context > information (OPTIONAL). > > * Inherit rich registries such as IPFIX. > > > > NOTE: This proposal does not include a dedicated flag bit to indicate > whether the context element is mandatory-to-process or optional-to-proces= s > because further discussion/text specification is required: e.g., > > * Wouldn't be sufficient to supply that information using the control > plane? > > * If that information is supplied in both the context element and > configured to a SFC-aware function, how conflicts are managed? > > * What is the behavior for processing mandatory-to-process elements > (particularly, when it is not supported)? > > * Is it required to recommend an ordering of supplying the mandatory-to= - > process or optional-to-process elements? > > * Is it required to preserve the same ordering when forwarding a packet= ? > > > > =3D=3DPROPOSAL=3D=3D=3D=3D > > > > Base version > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Class | Type | FLAGS | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // Data (Variable) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Version with Originator ID: > > 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Class | Type | Flags | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > //Originator Len| Originator ID (Variable)(Optional) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > // Data (Variable) // > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > The description of the fields is as follows: > > > > Class: In order to foster service innovation, this field > > allows to inherit from existing code point registries that are > > likely to be useful in a SFC context. The following values are > > reserved by this specification: > > 0: See IANA section. > > 1: IPFIX [IPFIX]. > > > > Type: Indicates the code point of the context element. If > > "Class" field is non-null, the interpretation of this field MUS= T > > conform to the one defined for that specific class registry. Se= e > IANA section. > > > > Flags: The Flags field comprises a set of 4 flags: > > > > +-+-+-+-+ > > |S|r|r|r| > > +-+-+-+-+ > > > > where "rrr" are reserved bits for future assignment as > > additional flag bits. r bits MUST each be sent as zero and > MUST be > > ignored on receipt. > > > > When set, the S-flag indicates that an Originator ID field > is > > present in the context element. This flag is set by defaul= t > to 0, meaning > > there is no Originator ID field present in the element. > > > > Originator ID (Optional): Conveys the identifier of the entity > that injected > > this context element in the NSH header (e.g., a service > > function identifier, a classifier, etc.). This document does > > not make any assumption about the structure of the information > > carried in this field because this is deployment-specific. > > This information is used by SFC-aware elements to enforce > > policies such as: process a context information if and only if > > it was supplied by a given entity. This information can be > > used as a safeguard against misbehaving nodes that inject > > illegitimate data in the NSH header. > > > > This field MUST be included only if S-bit is set. > > > > Length: Indicates, in octets, the length of the data carried in > > the context element. > > > > Data (Variable): The semantics of this field depend on the > > "Class" and "Type" fields. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Opinions? > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson > >> Envoy=E9 : dimanche 17 avril 2016 09:28 > >> =C0 : sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > >> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions o= n > >> TLVs in draft-ietf-sfc-nsh > >> > >> Working Group, authors, > >> > >> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read > >> it before now) and have a question on how the TLV concept is understoo= d > >> in the draft. > >> > >> For example in LDP TLV were defined as Type, Length Value, e.g. (from > >> RFC 5036 section 3.3): > >> > >> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much o= f > >> the information carried in LDP messages. > >> > >> An LDP TLV is encoded as a 2 octet field that uses 14 bits to > specify > >> a Type and 2 bits to specify behavior when an LSR doesn't recognize > >> the Type, followed by a 2 octet Length field, followed by a variabl= e > >> length Value field. > >> > >> > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |U|F| Type | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> | Value | > >> ~ ~ > >> | | > >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicate= d > >> and I'm struggling a bit to understand if the "name" TLV should be > used. > >> > >> From draft-ietf-sfc-nsh-04 > >> > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >> | TLV Class |C| Type |R|R|R| Len > | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >> | Variable Metadata > | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >> > >> > >> > >> Figure 6: Variable Context Headers > >> > >> The draft is not entirely clear in this respect, but I think this is > >> what you call a TLV. > >> > >> Should I understand this way? > >> > >> Type =3D TLV Class + C + Type (24 bits) > >> Length =3D len (5 bits) > >> Value =3D Variable Metadata > >> > >> A convention we used in MPLS when we have variable length fields is > >> to use a ~ instead of the |, like this:. > >> > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >> | TLV Class |C| Type |R|R|R| Len > | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >> ~ Variable Metadata > ~ > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >> > >> I suggest that this is a good practice that could be adopted here also= . > >> > >> Two more questions: > >> > >> If the metadata does not align exactly with the 32 bit/4 byte > structure, > >> what is the rules for padding? > >> > >> A last, but a bit different question, do you need indicators like the = U > >> and F flags in an to indicate what should happen if the node does not > >> recognize the (TLV Class, C, Type)-field? > >> > >> /Loa > >> > >> > >> PS > >> > >> I will also have a few more editorial comments that will be sent to > >> the authors within a day or two. > >> > >> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 19 23:30: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 4184F12EBE9; Tue, 19 Apr 2016 23:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 Oow9Itt6_tne; Tue, 19 Apr 2016 23:30:04 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A331812EBE4; Tue, 19 Apr 2016 23:30:04 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 32EED20455; Wed, 20 Apr 2016 08:30:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 01E8920057; Wed, 20 Apr 2016 08:30:03 +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.0279.002; Wed, 20 Apr 2016 08:30:02 +0200 From: To: "Carlos Pignataro (cpignata)" , Loa Andersson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqvd43LowhZakKM36eRU4WnUJ+SbKQA///5YnA= Date: Wed, 20 Apr 2016 06:30:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5CC0B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <57133AED.4080005@pi.nu> <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> In-Reply-To: <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@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.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 06:30:07 -0000 SGkgYWxsLCANCg0KSSBhZ3JlZSB3aXRoIENhcmxvcyB0aGF0IGEgaGllcmFyY2hpY2FsIHN0cnVj dHVyZSBpcyBtb3JlIGZsZXhpYmxlLCBidXQgSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHM6 IA0KDQoqIEFsbW9zdCBhbGwgdGhlIFJGQ3MgcXVvdGVkIGJ5IENhcmxvcyBkbyBub3QgY2xhaW0g dG8gdXNlIGEgVExWIHN0cnVjdHVyZSBvciB0aGUgVExWIHRlcm0uIEl0IGlzIHJlYXNvbmFibGUg dG8gdXBkYXRlIHRoZSBuc2ggc3BlYyB0byB1c2UgYSB0ZXJtIHRoYXQgZG9lcyBub3QgbGVhZCB0 byBjb25mdXNpb24uIEkgc2VlIHRoYXQgQ2FybG9zIGlzIHVzaW5nICJpbmZvcm1hdGlvbiBlbGVt ZW50Ii4gSXQgaXMgYWxzbyBpbiBteSBmYXZvcml0ZSBsaXN0ICh3aXRoIGEgcHJlZmVyZW5jZSBm b3IgY29udGV4dCBlbGVtZW50KS4gDQoqIFNvbWUgb2YgdGhlc2UgUkZDcyB1c2UgYSBiaXQgdGhh dCBpcyBzaW1pbGFyIHRvIHRoZSBDLWJpdCwgYnV0IHRoZXkgcmlnaHRmdWxseSBkb24ndCBtaXgg aXQgd2l0aCB0aGUgSUQgb2YgdGhlIGF0dHJpYnV0ZS4gDQoqIFNvbWUgb2YgdGhlc2UgUkZDcyBz cGVjaWZ5IChlLmcuLCBTZWN0aW9uIDUuMiBvZiBSRkMzOTMxKSBpbiBkZXRhaWxzIHRoZSBiZWhh dmlvciB3aGVuIHRoZSAiQy1iaXQiLWxpa2UgaXMgc2V0LiANCg0KVGhlIE5TSCBzcGVjIHN0aWxs IG5lZWQgbW9yZSB3b3JrLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+IERlwqA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBs YSBwYXJ0IGRlIENhcmxvcyBQaWduYXRhcm8NCj4gKGNwaWduYXRhKQ0KPiBFbnZvecOpwqA6IG1l cmNyZWRpIDIwIGF2cmlsIDIwMTYgMDQ6MzUNCj4gw4DCoDogTG9hIEFuZGVyc3Nvbg0KPiBDY8Kg OiBkcmFmdC1pZXRmLXNmYy1uc2hAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBS ZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0IC0gUXVl c3Rpb25zDQo+IG9uIFRMVnMgaW4gZHJhZnQtaWV0Zi1zZmMtbnNoDQo+IA0KPiBIaSwgTG9hLA0K PiANCj4gR29vZCBhbmFseXNpcyBvbiB0aGUgZm9ybWF0IG9mIHRoZXNlIGluZm9ybWF0aW9uIGVs ZW1lbnRzLg0KPiANCj4gTXkgc2Vuc2UgaXMgdGhhdCBhIGhpZXJhcmNoaWNhbCBzeW50YXggKHN1 Y2ggYXMgdGhlIENsYXNzL1R5cGUtTGVuZ3RoLQ0KPiBWYWx1ZSkgcHJvdmlkZXMgbXVjaCBtb3Jl IGZsZXhpYmlsaXR5IHRoYW4gYSBmbGF0IFR5cGUtTGVuZ3RoLVZhbHVlIGFsb25lLg0KPiANCj4g V2XigJl2ZSBidWlsdCBxdWl0ZSBhIG51bWJlciBvZiBwcm90b2NvbHMgd2l0aCB0aGlzIHN0cnVj dHVyZSBhbmQgYWxsb2NhdGlvbg0KPiBzY2hlbWUuIEZvciBleGFtcGxlLCBSU1ZQIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIwOSNzZWN0aW9uLQ0KPiA3LjIpLCBMMlRQdjMgKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzOTMxI3NlY3Rpb24tNS4xKSwgSUNNUA0KPiBN dWx0aS1QYXJ0IEV4dGVuc2lvbnMgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0ODg0 I3NlY3Rpb24tOCkuDQo+IA0KPiBSZWdhcmRsZXNzIG9mIHdoYXQgd2UgY2FsbCB0aGUgZmllbGRz IChlLmcuLCBDbGFzcyBhbmQgVHlwZSwgb3IgVHlwZSBhbmQNCj4gU3ViLVR5cGUsIG9yIOKApiks IHRoZXJlIGFyZSBjbGVhciB0ZWNobmljYWwgYWR2YW50YWdlcyB0byB0aGlzLCBpbmNsdWRpbmcN Cj4gdGhlIGFiaWxpdHkgdG8gZGVsZWdhdGUgYWxsb2NhdGlvbiwgdmVuZG9yIHR5cGVzLCBldGMu DQo+IA0KPiBJbiByZWdhcmRzIHRvIHRoZSBVL0YgYml0cyBpbiBMRFAsIEkgdGhpbmsgdGhlIEMt Yml0IGluIE5TSCBUTFZzIGFjaGlldmVzDQo+IHdoYXTigJlzIHJlYWxseSBuZWVkZWQgZm9yIGFu IFNGQyBFbmNhcC4NCj4gDQo+IExhc3RseSwgeW91IGNhbGwgb3V0IHBhZGRpbmcgYW5kIDMyLWJp dC13b3JkIGFsaWdubWVudC4gVGhpcyBpcyBhIGdyZWF0DQo+IHBvaW50Lg0KPiANCj4gVGhlIHdh eSB0aGluZ3Mgc2VlbXMgc3RydWN0dXJlZCBub3csIHRoZXJl4oCZcyBhIExlbiBmaWVsZCBtZWFz dXJlZCBpbiAzMi0NCj4gYml0IHdvcmRzLiBJdOKAmXMgbm90IGNsZWFyIHdoYXQgaGFwcGVucyB3 aGVuIHRoZSBNZXRhZGF0YSAoVmFsdWUpIGl0c2VsZiBpcw0KPiBub3QgMzItYml0LXdvcmQtYWxp Z25lZC4gVGhpcyBuZWVkcyBmaXhpbmcuDQo+IA0KPiBMb29raW5nIGF0IHRoZSBMZW5ndGggZGVm aW5pdGlvbjoNCj4gDQo+ICAgIExlbmd0aDogTGVuZ3RoIG9mIHRoZSB2YXJpYWJsZSBtZXRhZGF0 YSwgaW4gNC1ieXRlIHdvcmRzLiAgQSB2YWx1ZSBvZg0KPiAgICAweDAgb3IgaGlnaGVyIGNhbiBi ZSB1c2VkLiAgQSB2YWx1ZSBvZiAweDAgZGVub3RlcyBhIFRMViBoZWFkZXINCj4gICAgd2l0aG91 dCBhIFZhcmlhYmxlIE1ldGFkYXRhIGZpZWxkLg0KPiANCj4gQ29tbWVudHM6DQo+ICogRmlyc3Qs IGluc3RlYWQgb2Yg4oCcNC1ieXRl4oCdIHdvcmRzLCB0aGlzIG5lZWRzIHRvIGJlIOKAnDQtb2N0 ZXTigJ0gb3Ig4oCcMzItYml04oCdDQo+IHdvcmRzLiBCeXRlIGlzIHN0cmljdGx5IG1hY2hpbmUg ZGVwZW5kZW50ICg3IGJpdHMsIDggYml0cywgZXRjKS4NCj4gKiBTZWNvbmQsIOKAnGEgdmFsdWUg b2YgMHgwIG9yIGhpZ2hlcuKAnSBmb3IgYW4gdW5zaWduZWQgdmFsdWUgZG9lcyBub3Qgc2F5DQo+ IG11Y2guDQo+IA0KPiBIb3BlIHRoZXNlIGhlbHAuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiDigJQg Q2FybG9zLg0KPiANCj4gPiBPbiBBcHIgMTcsIDIwMTYsIGF0IDM6MjcgQU0sIExvYSBBbmRlcnNz b24gPGxvYUBwaS5udT4gd3JvdGU6DQo+ID4NCj4gPiBXb3JraW5nIEdyb3VwLCBhdXRob3JzLA0K PiA+DQo+ID4gSSdtIHJlYWRpbmcgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0IChzb3JyeSB0byBub3Qg aGF2ZSBiZWVuIGFibGUgdG8gcmVhZA0KPiA+IGl0IGJlZm9yZSBub3cpIGFuZCBoYXZlIGEgcXVl c3Rpb24gb24gaG93IHRoZSBUTFYgY29uY2VwdCBpcyB1bmRlcnN0b29kDQo+ID4gaW4gdGhlIGRy YWZ0Lg0KPiA+DQo+ID4gRm9yIGV4YW1wbGUgaW4gTERQIFRMViB3ZXJlIGRlZmluZWQgYXMgVHlw ZSwgTGVuZ3RoIFZhbHVlLCBlLmcuIChmcm9tDQo+ID4gUkZDIDUwMzYgc2VjdGlvbiAzLjMpOg0K PiA+DQo+ID4gICBMRFAgdXNlcyBhIFR5cGUtTGVuZ3RoLVZhbHVlIChUTFYpIGVuY29kaW5nIHNj aGVtZSB0byBlbmNvZGUgbXVjaCBvZg0KPiA+ICAgdGhlIGluZm9ybWF0aW9uIGNhcnJpZWQgaW4g TERQIG1lc3NhZ2VzLg0KPiA+DQo+ID4gICBBbiBMRFAgVExWIGlzIGVuY29kZWQgYXMgYSAyIG9j dGV0IGZpZWxkIHRoYXQgdXNlcyAxNCBiaXRzIHRvIHNwZWNpZnkNCj4gPiAgIGEgVHlwZSBhbmQg MiBiaXRzIHRvIHNwZWNpZnkgYmVoYXZpb3Igd2hlbiBhbiBMU1IgZG9lc24ndCByZWNvZ25pemUN Cj4gPiAgIHRoZSBUeXBlLCBmb2xsb3dlZCBieSBhIDIgb2N0ZXQgTGVuZ3RoIGZpZWxkLCBmb2xs b3dlZCBieSBhIHZhcmlhYmxlDQo+ID4gICBsZW5ndGggVmFsdWUgZmllbGQuDQo+ID4NCj4gPg0K PiA+ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMNCj4gPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICB8VXxGfCAg ICAgICAgVHlwZSAgICAgICAgICAgICAgIHwgICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAg fA0KPiA+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4gPiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAg fiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIH4NCj4gPiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gPg0KPiA+IEluIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNCB0aGUgVExWIHN0cnVj dHVyZSBzZWVtcyBhIGJpdCBtb3JlIGNvbXBsaWNhdGVkDQo+ID4gYW5kIEknbSBzdHJ1Z2dsaW5n IGEgYml0IHRvIHVuZGVyc3RhbmQgaWYgdGhlICJuYW1lIiBUTFYgc2hvdWxkIGJlIHVzZWQuDQo+ ID4NCj4gPiBGcm9tIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNA0KPiA+DQo+ID4gICAgICAgIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN Cj4gPiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxDQo+ID4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICB8ICAgICAg ICAgIFRMViBDbGFzcyAgICAgICAgICAgIHxDfCAgICBUeXBlICAgICB8UnxSfFJ8ICAgTGVuICAg fA0KPiA+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgICBW YXJpYWJsZSBNZXRhZGF0YSAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNjogVmFy aWFibGUgQ29udGV4dCBIZWFkZXJzDQo+ID4NCj4gPiBUaGUgZHJhZnQgaXMgbm90IGVudGlyZWx5 IGNsZWFyIGluIHRoaXMgcmVzcGVjdCwgYnV0IEkgdGhpbmsgdGhpcyBpcw0KPiB3aGF0IHlvdSBj YWxsIGEgVExWLg0KPiA+DQo+ID4gU2hvdWxkIEkgdW5kZXJzdGFuZCB0aGlzIHdheT8NCj4gPg0K PiA+IFR5cGUgPSBUTFYgQ2xhc3MgKyBDICsgVHlwZSAoMjQgYml0cykNCj4gPiBMZW5ndGggPSBs ZW4gKDUgYml0cykNCj4gPiBWYWx1ZSA9IFZhcmlhYmxlIE1ldGFkYXRhDQo+ID4NCj4gPiBBIGNv bnZlbnRpb24gd2UgdXNlZCBpbiBNUExTIHdoZW4gd2UgaGF2ZSB2YXJpYWJsZSBsZW5ndGggZmll bGRzIGlzDQo+ID4gdG8gdXNlIGEgfiBpbnN0ZWFkIG9mIHRoZSB8LCBsaWtlIHRoaXM6Lg0KPiA+ DQo+ID4gICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAg ICAgICAgICAgICAgICAgIDMNCj4gPiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQo+ID4gICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gPiAgICAgICB8ICAgICAgICAgIFRMViBDbGFzcyAgICAgICAgICAgIHxDfCAgICBUeXBlICAg ICB8UnxSfFJ8ICAgTGVuICAgfA0KPiA+ICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4gICAgICAgfiAgICAg ICAgICAgICAgICAgICAgICBWYXJpYWJsZSBNZXRhZGF0YSAgICAgICAgICAgICAgICAgICAgICAg IH4NCj4gPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+DQo+ID4gSSBzdWdnZXN0IHRoYXQgdGhpcyBpcyBh IGdvb2QgcHJhY3RpY2UgdGhhdCBjb3VsZCBiZSBhZG9wdGVkIGhlcmUgYWxzby4NCj4gPg0KPiA+ IFR3byBtb3JlIHF1ZXN0aW9uczoNCj4gPg0KPiA+IElmIHRoZSBtZXRhZGF0YSBkb2VzIG5vdCBh bGlnbiBleGFjdGx5IHdpdGggdGhlIDMyIGJpdC80IGJ5dGUgc3RydWN0dXJlLA0KPiA+IHdoYXQg aXMgdGhlIHJ1bGVzIGZvciBwYWRkaW5nPw0KPiA+DQo+ID4gQSBsYXN0LCBidXQgYSBiaXQgZGlm ZmVyZW50IHF1ZXN0aW9uLCBkbyB5b3UgbmVlZCBpbmRpY2F0b3JzIGxpa2UgdGhlIFUNCj4gPiBh bmQgRiBmbGFncyBpbiBhbiB0byBpbmRpY2F0ZSB3aGF0IHNob3VsZCBoYXBwZW4gaWYgdGhlIG5v ZGUgZG9lcyBub3QNCj4gPiByZWNvZ25pemUgdGhlIChUTFYgQ2xhc3MsIEMsIFR5cGUpLWZpZWxk Pw0KPiA+DQo+ID4gL0xvYQ0KPiA+DQo+ID4NCj4gPiBQUw0KPiA+DQo+ID4gSSB3aWxsIGFsc28g aGF2ZSBhIGZldyBtb3JlIGVkaXRvcmlhbCBjb21tZW50cyB0aGF0IHdpbGwgYmUgc2VudCB0bw0K PiA+IHRoZSBhdXRob3JzIHdpdGhpbiBhIGRheSBvciB0d28uDQo+ID4NCj4gPg0KPiA+IC0tDQo+ ID4NCj4gPg0KPiA+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDog bG9hQG1haWwwMS5odWF3ZWkuY29tDQo+ID4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAg ICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0 YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0K PiA+IHNmY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQoNCg== From nobody Wed Apr 20 00:51: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 BDF9612ECF9; Wed, 20 Apr 2016 00:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 a_87CKBf689s; Wed, 20 Apr 2016 00:51:37 -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 DAF4812ECD2; Wed, 20 Apr 2016 00:51:36 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 6A6AD1802BDF; Wed, 20 Apr 2016 09:51:34 +0200 (CEST) To: "Carlos Pignataro (cpignata)" References: <57133AED.4080005@pi.nu> <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> From: Loa Andersson Message-ID: <571734F7.4030804@pi.nu> Date: Wed, 20 Apr 2016 15:51:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 07:51:40 -0000 Carlos, Thanks for this, I don't think we are too far apart, and I have a suggestion that I hope resolve this. On 2016-04-20 10:35, Carlos Pignataro (cpignata) wrote: > Hi, Loa, > > Good analysis on the format of these information elements. > > My sense is that a hierarchical syntax (such as the Class/Type-Length-Value) provides much more flexibility than a flat Type-Length-Value alone. I tend to agree with that, but that is an argument on if the flexibility is needed. I think it is for the NSH. My point is that TLV is "named" for its structure, if an element does notm have that structure it is simply not a TLV. On the highest level I do not have a problem with the layout of the Variable Context Headers, but currently it is not clear why we call it a TLV. It could be made clear though. > > We’ve built quite a number of protocols with this structure and allocation scheme. For example, RSVP (https://tools.ietf.org/html/rfc3209#section-7.2), L2TPv3 (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP Multi-Part Extensions (https://tools.ietf.org/html/rfc4884#section-8). > Indeed, but of the three documents you refer to only the L2TPv3 document mention TLV, and only on a very high level in the terminology section. > Regardless of what we call the fields (e.g., Class and Type, or Type and Sub-Type, or …), there are clear technical advantages to this, including the ability to delegate allocation, vendor types, etc. > My point was that what we call things matter. > In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs achieves what’s really needed for an SFC Encap. > This is the response I expected, though I'm still not entirely comfortable, e.g. what do you do if you don't recognize the class and the C bit is not set? > Lastly, you call out padding and 32-bit-word alignment. This is a great point. > > The way things seems structured now, there’s a Len field measured in 32-bit words. It’s not clear what happens when the Metadata (Value) itself is not 32-bit-word-aligned. This needs fixing. > > Looking at the Length definition: > > Length: Length of the variable metadata, in 4-byte words. A value of > 0x0 or higher can be used. A value of 0x0 denotes a TLV header > without a Variable Metadata field. > > Comments: > * First, instead of “4-byte†words, this needs to be “4-octet†or “32-bit†words. Byte is strictly machine dependent (7 bits, 8 bits, etc). > * Second, “a value of 0x0 or higher†for an unsigned value does not say much. Agree to changing to "octet". Actually the Len field is 5 bits, gives us 32 variants, zero means "none", while 31 means 31 x 4 = 124 octets. What I suggest that we add (we can continue to discuss sizes of the differnt fields). I've not look closely where my text would fit exactly. 3.5.1. Optional Variable Length Metadata Optional variable length metadata are encoded as Variable Context Header TLVs The Variable Context Headers TLV has the same structure as TLVs defined in e.g. the LDP and BFD protocols, Type, Length and Value. However in the Variable Context Header TLV the Type field have an internal structure TLV Class, C-bit and Type. The format of the optional variable length context header TLVs, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| TLV-Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Variable Context Headers Type: The type field has three sub-fields, TLV Class, TLV Type and Len, the TLV-Type and Len fields have an internal structure. TLV Class: The TLV Class field is 16 bits and describes the scope of the "Type" field. In some cases, the TLV Class will identify a specific vendor, in others, the TLV Class will identify specific standards body allocated types. A new IANA registry will be created for TLV Class type. Type: The TLV-Type field is 8 bits and the specifies the type of information carried in the Variable Metadata field, within the scope of a given TLV Class. Value allocation is the responsibility of the TLV Class owner. The Critical bit (C-bit); 1 bit, encoding the criticality of the TLV-type. The C-bit is part of the TLV-Type field and is consistent with IPv6 option types. The C-bit (the most significant bit of the TLV-Type field) indicates whether the TLV is mandatory for the receiver to understand/process. This effectively allocates TLV-Type values 0 to 127 for non-critical options and Type values 128 to 255 for critical options. Figure 7 below illustrates the placement of the Critical bit within the Type field. +-+-+-+-+-+-+-+-+ |C| Type | +-+-+-+-+-+-+-+-+ Figure 7: Critical Bit Placement Within the TLV Type Field If a receiver receives an encapsulated packet containing a TLV with the Critical bit set to 0x1 in the Type field and it does not understand how to process the Type, it MUST drop the packet. Transit devices MUST NOT drop packets based on the setting of this bit. Length: The length field is 8 bits are reserved, three most significant bits (R) are reserved for future use. The length field indicates the length of the variable metadata, in 4-octet words. A value of 0x0 or higher can be used. A value of 0x0 denotes a Variable Context Header TLV without a Variable Metadata field. Note: as always when I write English a grammar review is necessary! Hope I did not screw this up too badly. /Loa > > Hope these help. > > Thanks, > > — Carlos. > >> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >> >> Working Group, authors, >> >> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read >> it before now) and have a question on how the TLV concept is understood >> in the draft. >> >> For example in LDP TLV were defined as Type, Length Value, e.g. (from >> RFC 5036 section 3.3): >> >> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of >> the information carried in LDP messages. >> >> An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify >> a Type and 2 bits to specify behavior when an LSR doesn't recognize >> the Type, followed by a 2 octet Length field, followed by a variable >> length Value field. >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |U|F| Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | Value | >> ~ ~ >> | | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated >> and I'm struggling a bit to understand if the "name" TLV should be used. >> >> From draft-ietf-sfc-nsh-04 >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Figure 6: Variable Context Headers >> >> The draft is not entirely clear in this respect, but I think this is what you call a TLV. >> >> Should I understand this way? >> >> Type = TLV Class + C + Type (24 bits) >> Length = len (5 bits) >> Value = Variable Metadata >> >> A convention we used in MPLS when we have variable length fields is >> to use a ~ instead of the |, like this:. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ Variable Metadata ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> I suggest that this is a good practice that could be adopted here also. >> >> Two more questions: >> >> If the metadata does not align exactly with the 32 bit/4 byte structure, >> what is the rules for padding? >> >> A last, but a bit different question, do you need indicators like the U >> and F flags in an to indicate what should happen if the node does not >> recognize the (TLV Class, C, Type)-field? >> >> /Loa >> >> >> PS >> >> I will also have a few more editorial comments that will be sent to >> the authors within a day or two. >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Apr 20 01:09: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 C7C5A12D68E; Wed, 20 Apr 2016 01:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 Ydmm_SMGCdOj; Wed, 20 Apr 2016 01:09:47 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF96912D639; Wed, 20 Apr 2016 01:09:46 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 5109640250; Wed, 20 Apr 2016 10:09:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 06F611A0059; Wed, 20 Apr 2016 10:09:45 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Wed, 20 Apr 2016 10:09:44 +0200 From: To: Loa Andersson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmtl/5AyYQOBYvkqAcGlGZ5oRl5+Sf5fQ Date: Wed, 20 Apr 2016 08:09:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5CCE1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <57133AED.4080005@pi.nu> <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> <571734F7.4030804@pi.nu> In-Reply-To: <571734F7.4030804@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 08:09:49 -0000 RGVhciBMb2EsIA0KDQpUaGFuayB5b3UgZm9yIGRyYWZ0aW5nIGEgTkVXIHRleHQgdGhhdCBpcyBi ZXR0ZXIgdG8gdGhlIG9uZSBpbiAtMDQuIE5ldmVydGhlbGVzcywgSSBzdGlsbCBoYXZlIGlzc3Vl cyB3aXRoIGl0IGJ1dCBJIHdpbGwgZm9jdXMgb25seSBvbiBvbmUgaXRlbSB0aGF0IGl0IGlzIHJl bGF0ZWQgdG8gdGhpcyB0ZXh0OiANCg0KIlRoaXMgZWZmZWN0aXZlbHkgYWxsb2NhdGVzDQogICAg ICBUTFYtVHlwZSB2YWx1ZXMgMCB0byAxMjcgZm9yIG5vbi1jcml0aWNhbCBvcHRpb25zIGFuZCBU eXBlIHZhbHVlcw0KICAgICAgMTI4IHRvIDI1NSBmb3IgY3JpdGljYWwgb3B0aW9ucy4iDQoNCkRv IHlvdSBoYXZlIGFuIGV4YW1wbGUgb2YgYW4gb3B0aW9uYWwgY29udGV4dCBpbmZvcm1hdGlvbiB0 aGF0IGlzICJjcml0aWNhbCIgaW4gYWxsIGRlcGxveW1lbnRzLCBhbGwgY2hhaW5zPyBXb3VsZG4n dCB0aGlzIGJlIGxlZnQgdG8gdGhlIHRhc3RlIG9mIHRoZSBlbnRpdHkgYWRtaW5pc3RyYXRpbmcg YW4gU0ZDLWVuYWJsZWQgZG9tYWluPw0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBMb2EgQW5kZXJzc29uDQo+IEVudm95w6nCoDog bWVyY3JlZGkgMjAgYXZyaWwgMjAxNiAwOTo1MQ0KPiDDgMKgOiBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkNCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtbnNoQGlldGYub3JnOyBzZmNAaWV0Zi5v cmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMt bnNoLTA0LnR4dCAtIFF1ZXN0aW9ucw0KPiBvbiBUTFZzIGluIGRyYWZ0LWlldGYtc2ZjLW5zaA0K PiANCj4gQ2FybG9zLA0KPiANCj4gVGhhbmtzIGZvciB0aGlzLCBJIGRvbid0IHRoaW5rIHdlIGFy ZSB0b28gZmFyIGFwYXJ0LCBhbmQgSSBoYXZlIGENCj4gc3VnZ2VzdGlvbiB0aGF0IEkgaG9wZSBy ZXNvbHZlIHRoaXMuDQo+IA0KPiBPbiAyMDE2LTA0LTIwIDEwOjM1LCBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSkgd3JvdGU6DQo+ID4gSGksIExvYSwNCj4gPg0KPiA+IEdvb2QgYW5hbHlzaXMg b24gdGhlIGZvcm1hdCBvZiB0aGVzZSBpbmZvcm1hdGlvbiBlbGVtZW50cy4NCj4gPg0KPiA+IE15 IHNlbnNlIGlzIHRoYXQgYSBoaWVyYXJjaGljYWwgc3ludGF4IChzdWNoIGFzIHRoZSBDbGFzcy9U eXBlLUxlbmd0aC0NCj4gVmFsdWUpIHByb3ZpZGVzIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSB0aGFu IGEgZmxhdCBUeXBlLUxlbmd0aC1WYWx1ZSBhbG9uZS4NCj4gDQo+IEkgdGVuZCB0byBhZ3JlZSB3 aXRoIHRoYXQsIGJ1dCB0aGF0IGlzIGFuIGFyZ3VtZW50IG9uIGlmIHRoZSBmbGV4aWJpbGl0eQ0K PiBpcyBuZWVkZWQuIEkgdGhpbmsgaXQgaXMgZm9yIHRoZSBOU0guDQo+IA0KPiBNeSBwb2ludCBp cyB0aGF0IFRMViBpcyAibmFtZWQiIGZvciBpdHMgc3RydWN0dXJlLCBpZiBhbiBlbGVtZW50IGRv ZXMNCj4gbm90bSBoYXZlIHRoYXQgc3RydWN0dXJlIGl0IGlzIHNpbXBseSBub3QgYSBUTFYuDQo+ IA0KPiBPbiB0aGUgaGlnaGVzdCBsZXZlbCBJIGRvIG5vdCBoYXZlIGEgcHJvYmxlbSB3aXRoIHRo ZSBsYXlvdXQgb2YgdGhlDQo+IFZhcmlhYmxlIENvbnRleHQgSGVhZGVycywgYnV0IGN1cnJlbnRs eSBpdCBpcyBub3QgY2xlYXIgd2h5IHdlIGNhbGwNCj4gaXQgYSBUTFYuIEl0IGNvdWxkIGJlIG1h ZGUgY2xlYXIgdGhvdWdoLg0KPiA+DQo+ID4gV2XigJl2ZSBidWlsdCBxdWl0ZSBhIG51bWJlciBv ZiBwcm90b2NvbHMgd2l0aCB0aGlzIHN0cnVjdHVyZSBhbmQNCj4gYWxsb2NhdGlvbiBzY2hlbWUu IEZvciBleGFtcGxlLCBSU1ZQDQo+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzIw OSNzZWN0aW9uLTcuMiksIEwyVFB2Mw0KPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzM5MzEjc2VjdGlvbi01LjEpLCBJQ01QIE11bHRpLVBhcnQNCj4gRXh0ZW5zaW9ucyAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ4ODQjc2VjdGlvbi04KS4NCj4gPg0KPiBJbmRlZWQs IGJ1dCBvZiB0aGUgdGhyZWUgZG9jdW1lbnRzIHlvdSByZWZlciB0byBvbmx5IHRoZSBMMlRQdjMN Cj4gZG9jdW1lbnQgbWVudGlvbiBUTFYsIGFuZCBvbmx5IG9uIGEgdmVyeSBoaWdoIGxldmVsIGlu IHRoZSB0ZXJtaW5vbG9neQ0KPiBzZWN0aW9uLg0KPiANCj4gPiBSZWdhcmRsZXNzIG9mIHdoYXQg d2UgY2FsbCB0aGUgZmllbGRzIChlLmcuLCBDbGFzcyBhbmQgVHlwZSwgb3IgVHlwZSBhbmQNCj4g U3ViLVR5cGUsIG9yIOKApiksIHRoZXJlIGFyZSBjbGVhciB0ZWNobmljYWwgYWR2YW50YWdlcyB0 byB0aGlzLCBpbmNsdWRpbmcNCj4gdGhlIGFiaWxpdHkgdG8gZGVsZWdhdGUgYWxsb2NhdGlvbiwg dmVuZG9yIHR5cGVzLCBldGMuDQo+ID4NCj4gTXkgcG9pbnQgd2FzIHRoYXQgd2hhdCB3ZSBjYWxs IHRoaW5ncyBtYXR0ZXIuDQo+IA0KPiA+IEluIHJlZ2FyZHMgdG8gdGhlIFUvRiBiaXRzIGluIExE UCwgSSB0aGluayB0aGUgQy1iaXQgaW4gTlNIIFRMVnMNCj4gYWNoaWV2ZXMgd2hhdOKAmXMgcmVh bGx5IG5lZWRlZCBmb3IgYW4gU0ZDIEVuY2FwLg0KPiA+DQo+IFRoaXMgaXMgdGhlIHJlc3BvbnNl IEkgZXhwZWN0ZWQsIHRob3VnaCBJJ20gc3RpbGwgbm90IGVudGlyZWx5DQo+IGNvbWZvcnRhYmxl LCBlLmcuIHdoYXQgZG8geW91IGRvIGlmIHlvdSBkb24ndCByZWNvZ25pemUgdGhlIGNsYXNzDQo+ IGFuZCB0aGUgQyBiaXQgaXMgbm90IHNldD8NCj4gDQo+ID4gTGFzdGx5LCB5b3UgY2FsbCBvdXQg cGFkZGluZyBhbmQgMzItYml0LXdvcmQgYWxpZ25tZW50LiBUaGlzIGlzIGEgZ3JlYXQNCj4gcG9p bnQuDQo+ID4NCj4gPiBUaGUgd2F5IHRoaW5ncyBzZWVtcyBzdHJ1Y3R1cmVkIG5vdywgdGhlcmXi gJlzIGEgTGVuIGZpZWxkIG1lYXN1cmVkIGluIDMyLQ0KPiBiaXQgd29yZHMuIEl04oCZcyBub3Qg Y2xlYXIgd2hhdCBoYXBwZW5zIHdoZW4gdGhlIE1ldGFkYXRhIChWYWx1ZSkgaXRzZWxmIGlzDQo+ IG5vdCAzMi1iaXQtd29yZC1hbGlnbmVkLiBUaGlzIG5lZWRzIGZpeGluZy4NCj4gPg0KPiA+IExv b2tpbmcgYXQgdGhlIExlbmd0aCBkZWZpbml0aW9uOg0KPiA+DQo+ID4gICAgIExlbmd0aDogTGVu Z3RoIG9mIHRoZSB2YXJpYWJsZSBtZXRhZGF0YSwgaW4gNC1ieXRlIHdvcmRzLiAgQSB2YWx1ZQ0K PiBvZg0KPiA+ICAgICAweDAgb3IgaGlnaGVyIGNhbiBiZSB1c2VkLiAgQSB2YWx1ZSBvZiAweDAg ZGVub3RlcyBhIFRMViBoZWFkZXINCj4gPiAgICAgd2l0aG91dCBhIFZhcmlhYmxlIE1ldGFkYXRh IGZpZWxkLg0KPiA+DQo+ID4gQ29tbWVudHM6DQo+ID4gKiBGaXJzdCwgaW5zdGVhZCBvZiDigJw0 LWJ5dGXigJ0gd29yZHMsIHRoaXMgbmVlZHMgdG8gYmUg4oCcNC1vY3RldOKAnSBvciDigJwzMi0N Cj4gYml04oCdIHdvcmRzLiBCeXRlIGlzIHN0cmljdGx5IG1hY2hpbmUgZGVwZW5kZW50ICg3IGJp dHMsIDggYml0cywgZXRjKS4NCj4gPiAqIFNlY29uZCwg4oCcYSB2YWx1ZSBvZiAweDAgb3IgaGln aGVy4oCdIGZvciBhbiB1bnNpZ25lZCB2YWx1ZSBkb2VzIG5vdCBzYXkNCj4gbXVjaC4NCj4gDQo+ IEFncmVlIHRvIGNoYW5naW5nIHRvICJvY3RldCIuDQo+IA0KPiBBY3R1YWxseSB0aGUgTGVuIGZp ZWxkIGlzIDUgYml0cywgZ2l2ZXMgdXMgMzIgdmFyaWFudHMsIHplcm8gbWVhbnMNCj4gIm5vbmUi LCB3aGlsZSAzMSBtZWFucyAzMSB4IDQgPSAxMjQgb2N0ZXRzLg0KPiANCj4gV2hhdCBJIHN1Z2dl c3QgdGhhdCB3ZSBhZGQgKHdlIGNhbiBjb250aW51ZSB0byBkaXNjdXNzIHNpemVzIG9mIHRoZQ0K PiBkaWZmZXJudCBmaWVsZHMpLiBJJ3ZlIG5vdCBsb29rIGNsb3NlbHkgd2hlcmUgbXkgdGV4dCB3 b3VsZCBmaXQNCj4gZXhhY3RseS4NCj4gDQo+IDMuNS4xLiBPcHRpb25hbCBWYXJpYWJsZSBMZW5n dGggTWV0YWRhdGENCj4gDQo+ICAgIE9wdGlvbmFsIHZhcmlhYmxlIGxlbmd0aCBtZXRhZGF0YSBh cmUgZW5jb2RlZCBhcyBWYXJpYWJsZSBDb250ZXh0DQo+ICAgIEhlYWRlciBUTFZzIFRoZSBWYXJp YWJsZSBDb250ZXh0IEhlYWRlcnMgVExWIGhhcyB0aGUgc2FtZSBzdHJ1Y3R1cmUNCj4gICAgYXMg VExWcyBkZWZpbmVkIGluIGUuZy4gdGhlIExEUCBhbmQgQkZEIHByb3RvY29scywgVHlwZSwgTGVu Z3RoIGFuZA0KPiAgICBWYWx1ZS4NCj4gDQo+ICAgIEhvd2V2ZXIgaW4gdGhlIFZhcmlhYmxlIENv bnRleHQgSGVhZGVyIFRMViB0aGUgVHlwZSBmaWVsZCBoYXZlIGFuDQo+ICAgIGludGVybmFsIHN0 cnVjdHVyZSBUTFYgQ2xhc3MsIEMtYml0IGFuZCBUeXBlLg0KPiANCj4gICAgIFRoZSBmb3JtYXQg b2YgdGhlIG9wdGlvbmFsIHZhcmlhYmxlIGxlbmd0aCBjb250ZXh0IGhlYWRlciBUTFZzLCBpcyBh cw0KPiAgICAgZGVzY3JpYmVkIGJlbG93Lg0KPiANCj4gICAgICAgICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiAgICAgICAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCj4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgIHwgICAgICAgICAgVExWIENs YXNzICAgICAgICAgICAgfEN8IFRMVi1UeXBlICAgIHxSfFJ8UnwgICBMZW4gICB8DQo+ICAgICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIFZhcmlhYmxlIE1l dGFkYXRhICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0K PiANCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA2OiBWYXJpYWJsZSBDb250ZXh0 IEhlYWRlcnMNCj4gDQo+ICAgICBUeXBlOiBUaGUgdHlwZSBmaWVsZCBoYXMgdGhyZWUgc3ViLWZp ZWxkcywgVExWIENsYXNzLCBUTFYgVHlwZSBhbmQNCj4gICAgIExlbiwgdGhlIFRMVi1UeXBlIGFu ZCBMZW4gZmllbGRzIGhhdmUgYW4gaW50ZXJuYWwgc3RydWN0dXJlLg0KPiANCj4gICAgICAgVExW IENsYXNzOiBUaGUgVExWIENsYXNzIGZpZWxkIGlzIDE2IGJpdHMgYW5kIGRlc2NyaWJlcyB0aGUg c2NvcGUNCj4gICAgICAgb2YgdGhlICJUeXBlIiBmaWVsZC4gIEluIHNvbWUgY2FzZXMsIHRoZSBU TFYgQ2xhc3Mgd2lsbCBpZGVudGlmeSBhDQo+ICAgICAgIHNwZWNpZmljIHZlbmRvciwgaW4gb3Ro ZXJzLCB0aGUgVExWIENsYXNzIHdpbGwgaWRlbnRpZnkgc3BlY2lmaWMNCj4gICAgICAgc3RhbmRh cmRzIGJvZHkgYWxsb2NhdGVkIHR5cGVzLiAgQSBuZXcgSUFOQSByZWdpc3RyeSB3aWxsIGJlDQo+ ICAgICAgIGNyZWF0ZWQgZm9yIFRMViBDbGFzcyB0eXBlLg0KPiANCj4gICAgICAgVHlwZTogVGhl IFRMVi1UeXBlIGZpZWxkIGlzIDggYml0cyBhbmQgdGhlIHNwZWNpZmllcyB0aGUgdHlwZSBvZg0K PiAgICAgICBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIHRoZSBWYXJpYWJsZSBNZXRhZGF0YSBmaWVs ZCwgd2l0aGluIHRoZQ0KPiAgICAgICBzY29wZSBvZiBhIGdpdmVuIFRMViBDbGFzcy4gIFZhbHVl IGFsbG9jYXRpb24gaXMgdGhlIHJlc3BvbnNpYmlsaXR5DQo+ICAgICAgIG9mIHRoZSBUTFYgQ2xh c3Mgb3duZXIuDQo+IA0KPiAgICAgICBUaGUgQ3JpdGljYWwgYml0IChDLWJpdCk7IDEgYml0LCBl bmNvZGluZyB0aGUgY3JpdGljYWxpdHkgb2YgdGhlDQo+ICAgICAgIFRMVi10eXBlLiBUaGUgQy1i aXQgaXMgcGFydCBvZiB0aGUgVExWLVR5cGUgZmllbGQgYW5kIGlzDQo+ICAgICAgIGNvbnNpc3Rl bnQgd2l0aCBJUHY2IG9wdGlvbiB0eXBlcy4gVGhlIEMtYml0ICh0aGUgbW9zdCBzaWduaWZpY2Fu dA0KPiAgICAgICBiaXQgb2YgdGhlIFRMVi1UeXBlIGZpZWxkKSBpbmRpY2F0ZXMgd2hldGhlciB0 aGUgVExWIGlzIG1hbmRhdG9yeQ0KPiAgICAgICBmb3IgdGhlIHJlY2VpdmVyIHRvIHVuZGVyc3Rh bmQvcHJvY2Vzcy4gIFRoaXMgZWZmZWN0aXZlbHkgYWxsb2NhdGVzDQo+ICAgICAgIFRMVi1UeXBl IHZhbHVlcyAwIHRvIDEyNyBmb3Igbm9uLWNyaXRpY2FsIG9wdGlvbnMgYW5kIFR5cGUgdmFsdWVz DQo+ICAgICAgIDEyOCB0byAyNTUgZm9yIGNyaXRpY2FsIG9wdGlvbnMuICBGaWd1cmUgNyBiZWxv dyBpbGx1c3RyYXRlcyB0aGUNCj4gICAgICAgcGxhY2VtZW50IG9mIHRoZSBDcml0aWNhbCBiaXQg d2l0aGluIHRoZSBUeXBlIGZpZWxkLg0KPiANCj4gICAgICAgKy0rLSstKy0rLSstKy0rLSsNCj4g ICAgICAgfEN8ICAgICBUeXBlICAgIHwNCj4gICAgICAgKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+ IA0KPiAgICAgICAgICBGaWd1cmUgNzogQ3JpdGljYWwgQml0IFBsYWNlbWVudCBXaXRoaW4gdGhl IFRMViBUeXBlIEZpZWxkDQo+IA0KPiANCj4gICAgICAgSWYgYSByZWNlaXZlciByZWNlaXZlcyBh biBlbmNhcHN1bGF0ZWQgcGFja2V0IGNvbnRhaW5pbmcgYSBUTFYgd2l0aA0KPiAgICAgICB0aGUg Q3JpdGljYWwgYml0IHNldCB0byAweDEgaW4gdGhlIFR5cGUgZmllbGQgYW5kIGl0IGRvZXMgbm90 DQo+ICAgICAgIHVuZGVyc3RhbmQgaG93IHRvIHByb2Nlc3MgdGhlIFR5cGUsIGl0IE1VU1QgZHJv cCB0aGUgcGFja2V0Lg0KPiAgICAgICBUcmFuc2l0IGRldmljZXMgTVVTVCBOT1QgZHJvcCBwYWNr ZXRzIGJhc2VkIG9uIHRoZSBzZXR0aW5nIG9mIHRoaXMNCj4gICAgICAgYml0Lg0KPiANCj4gICAg ICAgTGVuZ3RoOiBUaGUgbGVuZ3RoIGZpZWxkIGlzIDggYml0cyBhcmUgcmVzZXJ2ZWQsIHRocmVl IG1vc3QNCj4gICAgICAgc2lnbmlmaWNhbnQgYml0cyAoUikgYXJlIHJlc2VydmVkIGZvciBmdXR1 cmUgdXNlLiBUaGUgbGVuZ3RoIGZpZWxkDQo+ICAgICAgIGluZGljYXRlcyB0aGUgbGVuZ3RoIG9m IHRoZSB2YXJpYWJsZSBtZXRhZGF0YSwgaW4gNC1vY3RldCB3b3Jkcy4gQQ0KPiAgICAgICB2YWx1 ZSBvZiAweDAgb3IgaGlnaGVyIGNhbiBiZSB1c2VkLiBBIHZhbHVlIG9mIDB4MCBkZW5vdGVzIGEN Cj4gICAgICAgVmFyaWFibGUgQ29udGV4dCBIZWFkZXIgVExWIHdpdGhvdXQgYSBWYXJpYWJsZSBN ZXRhZGF0YSBmaWVsZC4NCj4gDQo+IE5vdGU6IGFzIGFsd2F5cyB3aGVuIEkgd3JpdGUgRW5nbGlz aCBhIGdyYW1tYXIgcmV2aWV3IGlzIG5lY2Vzc2FyeSENCj4gDQo+IEhvcGUgSSBkaWQgbm90IHNj cmV3IHRoaXMgdXAgdG9vIGJhZGx5Lg0KPiANCj4gL0xvYQ0KPiANCj4gDQo+IA0KPiANCj4gPg0K PiA+IEhvcGUgdGhlc2UgaGVscC4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IOKAlCBDYXJs b3MuDQo+ID4NCj4gPj4gT24gQXByIDE3LCAyMDE2LCBhdCAzOjI3IEFNLCBMb2EgQW5kZXJzc29u IDxsb2FAcGkubnU+IHdyb3RlOg0KPiA+Pg0KPiA+PiBXb3JraW5nIEdyb3VwLCBhdXRob3JzLA0K PiA+Pg0KPiA+PiBJJ20gcmVhZGluZyBkcmFmdC1pZXRmLXNmYy1uc2gtMDQgKHNvcnJ5IHRvIG5v dCBoYXZlIGJlZW4gYWJsZSB0byByZWFkDQo+ID4+IGl0IGJlZm9yZSBub3cpIGFuZCBoYXZlIGEg cXVlc3Rpb24gb24gaG93IHRoZSBUTFYgY29uY2VwdCBpcyB1bmRlcnN0b29kDQo+ID4+IGluIHRo ZSBkcmFmdC4NCj4gPj4NCj4gPj4gRm9yIGV4YW1wbGUgaW4gTERQIFRMViB3ZXJlIGRlZmluZWQg YXMgVHlwZSwgTGVuZ3RoIFZhbHVlLCBlLmcuIChmcm9tDQo+ID4+IFJGQyA1MDM2IHNlY3Rpb24g My4zKToNCj4gPj4NCj4gPj4gICAgTERQIHVzZXMgYSBUeXBlLUxlbmd0aC1WYWx1ZSAoVExWKSBl bmNvZGluZyBzY2hlbWUgdG8gZW5jb2RlIG11Y2ggb2YNCj4gPj4gICAgdGhlIGluZm9ybWF0aW9u IGNhcnJpZWQgaW4gTERQIG1lc3NhZ2VzLg0KPiA+Pg0KPiA+PiAgICBBbiBMRFAgVExWIGlzIGVu Y29kZWQgYXMgYSAyIG9jdGV0IGZpZWxkIHRoYXQgdXNlcyAxNCBiaXRzIHRvDQo+IHNwZWNpZnkN Cj4gPj4gICAgYSBUeXBlIGFuZCAyIGJpdHMgdG8gc3BlY2lmeSBiZWhhdmlvciB3aGVuIGFuIExT UiBkb2Vzbid0IHJlY29nbml6ZQ0KPiA+PiAgICB0aGUgVHlwZSwgZm9sbG93ZWQgYnkgYSAyIG9j dGV0IExlbmd0aCBmaWVsZCwgZm9sbG93ZWQgYnkgYSB2YXJpYWJsZQ0KPiA+PiAgICBsZW5ndGgg VmFsdWUgZmllbGQuDQo+ID4+DQo+ID4+DQo+ID4+ICAgICAwICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ID4+ICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN Cj4gPj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4gPj4gICAgfFV8RnwgICAgICAgIFR5cGUgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgIHwNCj4gPj4gICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g Pj4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCj4gPj4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmFs dWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPj4gICAgfiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4NCj4gPj4g ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gPj4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPj4gICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQo+ID4+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiA+Pg0KPiA+PiBJbiBkcmFmdC1pZXRmLXNmYy1uc2gtMDQgdGhlIFRMViBzdHJ1Y3R1cmUg c2VlbXMgYSBiaXQgbW9yZSBjb21wbGljYXRlZA0KPiA+PiBhbmQgSSdtIHN0cnVnZ2xpbmcgYSBi aXQgdG8gdW5kZXJzdGFuZCBpZiB0aGUgIm5hbWUiIFRMViBzaG91bGQgYmUNCj4gdXNlZC4NCj4g Pj4NCj4gPj4gIEZyb20gZHJhZnQtaWV0Zi1zZmMtbnNoLTA0DQo+ID4+DQo+ID4+ICAgICAgICAg MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMw0KPiA+PiAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+PiAgICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLQ0KPiArDQo+ID4+ ICAgICAgICB8ICAgICAgICAgIFRMViBDbGFzcyAgICAgICAgICAgIHxDfCAgICBUeXBlICAgICB8 UnxSfFJ8ICAgTGVuDQo+IHwNCj4gPj4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0NCj4gKw0KPiA+PiAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICBWYXJpYWJsZSBNZXRhZGF0YQ0KPiB8DQo+ID4+ICAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstDQo+ICsNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgNjogVmFyaWFibGUgQ29udGV4dCBIZWFkZXJzDQo+ID4+DQo+ID4+IFRoZSBkcmFm dCBpcyBub3QgZW50aXJlbHkgY2xlYXIgaW4gdGhpcyByZXNwZWN0LCBidXQgSSB0aGluayB0aGlz IGlzDQo+IHdoYXQgeW91IGNhbGwgYSBUTFYuDQo+ID4+DQo+ID4+IFNob3VsZCBJIHVuZGVyc3Rh bmQgdGhpcyB3YXk/DQo+ID4+DQo+ID4+IFR5cGUgPSBUTFYgQ2xhc3MgKyBDICsgVHlwZSAoMjQg Yml0cykNCj4gPj4gTGVuZ3RoID0gbGVuICg1IGJpdHMpDQo+ID4+IFZhbHVlID0gVmFyaWFibGUg TWV0YWRhdGENCj4gPj4NCj4gPj4gQSBjb252ZW50aW9uIHdlIHVzZWQgaW4gTVBMUyB3aGVuIHdl IGhhdmUgdmFyaWFibGUgbGVuZ3RoIGZpZWxkcyBpcw0KPiA+PiB0byB1c2UgYSB+IGluc3RlYWQg b2YgdGhlIHwsIGxpa2UgdGhpczouDQo+ID4+DQo+ID4+ICAgICAgICAgMCAgICAgICAgICAgICAg ICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiA+PiAgICAg ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQ0KPiA+PiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLQ0KPiArDQo+ID4+ICAgICAgICB8ICAgICAg ICAgIFRMViBDbGFzcyAgICAgICAgICAgIHxDfCAgICBUeXBlICAgICB8UnxSfFJ8ICAgTGVuDQo+ IHwNCj4gPj4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0NCj4gKw0KPiA+PiAgICAgICAgfiAgICAgICAgICAgICAg ICAgICAgICBWYXJpYWJsZSBNZXRhZGF0YQ0KPiB+DQo+ID4+ICAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstDQo+ICsN Cj4gPj4NCj4gPj4gSSBzdWdnZXN0IHRoYXQgdGhpcyBpcyBhIGdvb2QgcHJhY3RpY2UgdGhhdCBj b3VsZCBiZSBhZG9wdGVkIGhlcmUgYWxzby4NCj4gPj4NCj4gPj4gVHdvIG1vcmUgcXVlc3Rpb25z Og0KPiA+Pg0KPiA+PiBJZiB0aGUgbWV0YWRhdGEgZG9lcyBub3QgYWxpZ24gZXhhY3RseSB3aXRo IHRoZSAzMiBiaXQvNCBieXRlDQo+IHN0cnVjdHVyZSwNCj4gPj4gd2hhdCBpcyB0aGUgcnVsZXMg Zm9yIHBhZGRpbmc/DQo+ID4+DQo+ID4+IEEgbGFzdCwgYnV0IGEgYml0IGRpZmZlcmVudCBxdWVz dGlvbiwgZG8geW91IG5lZWQgaW5kaWNhdG9ycyBsaWtlIHRoZSBVDQo+ID4+IGFuZCBGIGZsYWdz IGluIGFuIHRvIGluZGljYXRlIHdoYXQgc2hvdWxkIGhhcHBlbiBpZiB0aGUgbm9kZSBkb2VzIG5v dA0KPiA+PiByZWNvZ25pemUgdGhlIChUTFYgQ2xhc3MsIEMsIFR5cGUpLWZpZWxkPw0KPiA+Pg0K PiA+PiAvTG9hDQo+ID4+DQo+ID4+DQo+ID4+IFBTDQo+ID4+DQo+ID4+IEkgd2lsbCBhbHNvIGhh dmUgYSBmZXcgbW9yZSBlZGl0b3JpYWwgY29tbWVudHMgdGhhdCB3aWxsIGJlIHNlbnQgdG8NCj4g Pj4gdGhlIGF1dGhvcnMgd2l0aGluIGEgZGF5IG9yIHR3by4NCj4gPj4NCj4gPj4NCj4gPj4gLS0N Cj4gPj4NCj4gPj4NCj4gPj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVt YWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gPj4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAg ICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gPj4gSHVhd2VpIFRlY2hub2xvZ2llcyAo Y29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ID4+DQo+ID4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHNmYyBtYWls aW5nIGxpc3QNCj4gPj4gc2ZjQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Wed Apr 20 06:05:12 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 1C34612D15B for ; Wed, 20 Apr 2016 06:05:11 -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 zUJtfkbM-jJ9 for ; Wed, 20 Apr 2016 06:05:08 -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 6F64912D114 for ; Wed, 20 Apr 2016 06:05:08 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id e201so49853961wme.0 for ; Wed, 20 Apr 2016 06:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=9u5GgU56tvzTvEedbWl2HP8LQHD9xaFYM0BqsQxL4g0=; b=XMNJR8uFqlDW33W7yevn/7KUuEWnrVlX0WiTPu/er7aZXj6JP5zvL17x5jaUXRRyyz Uol2C4O1+SdQVM793j9YDcdRWeBSIW+/Q/gsqgBrxRMYEUp+zikTFZBryxOXgM5FygSf ytoWRVLER7GP9iEGIa03NrYTBWBdjmkRIPfHwJ8DNlnkfNsWygR3EWk53ApRMqsJkoS0 DQ8CmjBjuguew5XmPsAdWeauQQyO5IwS0Nr6i5p2oaDWdKvJ5FEFkpLjASI50PEBhUt9 yXQC4BB8y4rV79bNXa1gt+Ilwv6Irld+xdHQHgM8WYGqdIeaZSvcliqr4f1CeRJI1wf1 uBoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=9u5GgU56tvzTvEedbWl2HP8LQHD9xaFYM0BqsQxL4g0=; b=dRru+OHp3LXIhJYAHQAyfkNN5cwyCqUb0yzFE4qRO0MSGsfhQ46B0v/sY/PEDrGRAe Yz847mgbUl6CDeyUrcfjojs0t2WyPFiuI2OvFMRef4PD6c6vmPrUxWKJsp7ga/5wv5XZ ahGMLs5SZLjW33JcT1JGC/7kKfVxIXkZIzX658aOLJICh4L5MVNkS9QYhnqklN1L8A2n Jh9oiIUydMbpdKPlZQIj3vjEvFi+DTb/F5mpPuO00zWPUzee1VDkt+PJ+Ejswpc67ijd dTslIlZgZPkQw9mJNOy2btplcKAzuThJsO6wybOgRaqwZkeY2sr7fN9asp0qPNWhcMQc o3wg== X-Gm-Message-State: AOPr4FUNSwc+YBHwS5tvECLHT+U5QURiacDIESnlwPK3mcVO24wmTmOnsQld65/6lW4O0n/BvcI+rhP1GfPRVw== MIME-Version: 1.0 X-Received: by 10.194.2.210 with SMTP id 18mr9283673wjw.55.1461157506976; Wed, 20 Apr 2016 06:05:06 -0700 (PDT) Received: by 10.28.87.19 with HTTP; Wed, 20 Apr 2016 06:05:06 -0700 (PDT) Date: Wed, 20 Apr 2016 18:35:06 +0530 Message-ID: From: Nobin Mathew To: anil.sn@huawei.com, gaurav.agrawal@huawei.com, vinods.kumar@huawei.com Content-Type: multipart/alternative; boundary=047d7b3a860a2a18710530ea3e71 Archived-At: Cc: sfc@ietf.org Subject: [sfc] Few Querries from draft-agv-sfc-packet-delay-measurement-00 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, 20 Apr 2016 13:05:11 -0000 --047d7b3a860a2a18710530ea3e71 Content-Type: text/plain; charset=UTF-8 Hi Anil Kumar S N, Gaurav Agrawal,Vinod Kumar S, I have few question with respect to the delay calculation method described in the draft "draft-agv-sfc-packet-delay-measurement-00". Please let me know your opinion on this queries. 1) -------------------------draft section--------------------------------------- 3.6 Incoming Packets Processing at MA On receiving the packet with NSH header following operations are carried out: Step 1: Detection of PM Context Header in a packet, by verifying the PM TLV Class as allocated by IANA. (If not detected, move to step 6) Step 2: Check if PM Type field value is 6 to 10. (If not move to step 6). Step 3: If PM Type Value = 7 to 10 move directly to Step 5 Step 4: Check Presence of self Service index in Service Index List (If not present, move to step 6) --------------------------------------------------------------------------- MA can be SF or SFF , but based on the steps given here, SFF cannot do the time recording or report to collector because step 4 checks the SI index and SFF we do not have Si index. [ SI: List of participating Service functions in the SFP. It SHOULD be in decreasing order of the SI for optimized traversal of the SI participation. ] So i thing we need to address SFF scenario as well. 2) +---+ +----+ |SF |--------------------+ +------------|SF | | |....... ----------+ \ / /+----------| | +---+ \ \ / / +----+ +---2 -3-+-4--5--+ | SF Forwarder | -----1| (SFF) |6------ +-------+--------+ As per the method specified in this draft MA will record 'timestamp' when a packet ENTER and EXIT and this 'timestamp' will be notified to the controller. but if we consider the above topology SFF has multiple entry and exit ports so each time these entries[timestamp] will be overwritten by the MA when the packet traverse and we will not get the correct delay because of this. I feel we need to track each ENTRY and EXIT separately to track the delay correctly. 3) ------------------------------draft section---------------------------------------------------------------- 3.8 MA Reporting the statistics to Collector Reporting timer will run on Each MA. Consistency of this timer should be ensured across the entire MA in the SFP, ensuring the same is out of scope of this document. On expiry of this timer following information needs to be sent to the Collector. - Service Index - PM Type Value - Value of all the collected Rx-Time[P][W], Rx-Sum-Time[P][W], & Rx-Sample-Count[P][W] parameters along with the corresponding PMF ID and Window Id - Value of all the collected Tx-Time[P][W], Tx-Sum-Time[P][W], & Tx-Sample-Count[P][W] parameters along with the corresponding PMF ID and Window Id MA may delete the parameters after sending the same to collector. ----------------------------------------------------------------------------------------------------------- If the MA is in SFF the what is the ID to track the device, Service index can be used for SF but not for SFF ? 4) ------------------------draft section------------------------------------------ - If Value = 0x7, 0x8, 0x9, 0x10 o No need to encode SI, since the type dictates the involved participating MA ------------------------------------------------------------------------------- I think 0x10 should be 0xA ? 5) ----------------------------draft section--------------------------------------- 3.7 Outgoing Packets Processing at MA At outgoing port of MA following operations are carried out. Step 1: If Option 1 is used then go to Step 2a, if Option 2 is used then go to Step 2b Step 2: If Option 1 is used then go to Step 2a, if Option 2 is used then go to Step 2b -------------------------------------------------------------------------------- Steps 1 and 2 is same here. Regards Nobin --047d7b3a860a2a18710530ea3e71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Hi Anil Kumar S N, Gaurav Agrawal,Vinod Kumar S,
<=
br>I have few question with respect to the delay calculation method describ=
ed in the draft "draft-agv-sfc-packet-delay-measurement-00".
P=
lease let me know your opinion on this queries.


1) 
---------=
----------------draft section---------------------------------------
   =
3.6 Incoming Packets Processing at MA

      On receiving the packet =
with NSH header following operations are 
      carried out:

    =
  Step 1: Detection of PM Context Header in a packet, by verifying 
    =
          the PM TLV Class as allocated by IANA.
              (If not d=
etected, move to step 6) 

      Step 2: Check if PM Type field value=
 is 6 to 10. 
              (If not move to step 6).

      Step 3=
: If PM Type Value =3D 7 to 10 move directly to Step 5

      Step 4:=
 Check Presence of self Service index in Service Index List
            =
  (If not present, move to step 6)
-------------------------------------=
--------------------------------------

MA can be SF or SFF , but bas=
ed on the steps given here, SFF cannot do the time recording or report to c=
ollector because
step 4 checks the SI index and SFF we do not have Si in=
dex.

[ SI: List of participating Service functions in the SFP. It SH=
OULD be 
   in decreasing order of the SI for optimized traversal of the=
 SI 
   participation. ]

So i thing we need to address SFF scenar=
io as well.


2) 
     +---+                                   =
       +----+
     |SF |--------------------+        +------------|SF  |=

     |   |....... ----------+  \      / /+----------|    | 
     +--=
-+                   \  \    / /            +----+  
                   =
      +---2 -3-+-4--5--+
                         |   SF Forwarder |
=
                   -----1|      (SFF)     |6------
                     =
    +-------+--------+

As per the method specified in this draft MA =
will record 'timestamp' when a packet ENTER and EXIT and this '=
timestamp'
will be notified to the controller. but if we consider th=
e above topology SFF has multiple entry and exit ports so 
each time the=
se entries[timestamp] will be overwritten by the MA when the packet travers=
e and we will not get the correct delay
because of this.

I feel w=
e need to track each ENTRY and EXIT separately to track the delay correctly=
.
 


3) 
------------------------------draft section-------=
---------------------------------------------------------
3.8 MA Reporti=
ng the statistics to Collector

   Reporting timer will run on Each M=
A. Consistency of this timer should
   be ensured across the entire MA i=
n the SFP, ensuring the same is out
   of scope of this document. 
   On expiry of this timer following information needs to be sent to the<=
br>   Collector.

       - Service Index 

       - PM Type Val=
ue

       - Value of all the collected Rx-Time[P][W], Rx-Sum-Time[P]=
[W],
         & Rx-Sample-Count[P][W] parameters along with the 
=
         corresponding PMF ID and Window Id 

       - Value of all t=
he collected Tx-Time[P][W], Tx-Sum-Time[P][W], 
         & Tx-Sample=
-Count[P][W] parameters along with the 
         corresponding PMF ID an=
d Window Id 

   MA may delete the parameters after sending the same =
to collector.
----------------------------------------------------------=
-------------------------------------------------

If the MA is in SF=
F the what is the ID to track the device, Service index can be used for SF =
but not for SFF ?



4) 
------------------------draft secti=
on------------------------------------------
   - If Value =3D 0x7, 0x8,=
 0x9, 0x10
          o No need to encode SI, since the type dictates the=
 involved
            participating MA 
-----------------------------=
--------------------------------------------------

I think 0x10 shou=
ld be 0xA ?




5) 
----------------------------draft sec=
tion---------------------------------------

3.7 Outgoing Packets Pro=
cessing at MA

      At outgoing port of MA following operations are =
carried out.

      Step 1: If Option 1 is used then go to Step 2a, i=
f Option 2 is 
              used then go to Step 2b

      Step 2=
: If Option 1 is used then go to Step 2a, if Option 2 is 
              =
used then go to Step 2b
------------------------------------------------=
--------------------------------

Steps 1 and 2 is same here.

=

Regards
Nobin
--047d7b3a860a2a18710530ea3e71-- From nobody Wed Apr 20 07:18:06 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 25AA712EF4F for ; Wed, 20 Apr 2016 07:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 J3bcl_HpLBGW for ; Wed, 20 Apr 2016 07:18:02 -0700 (PDT) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (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 4E4F112EF3F for ; Wed, 20 Apr 2016 07:18:02 -0700 (PDT) Received: by mail-qk0-f177.google.com with SMTP id r184so14725333qkc.1 for ; Wed, 20 Apr 2016 07:18:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7mwbcFlMWRy1+Kg3k513VjdBkgBbvN3Nn3czi9Xs9II=; b=Spw0dNYpUTwnFCaCaaFpPYXJ3Rlp/hsHTrxveBh+9GP/2/mtw3dMaTo/30iv2tSGXD hgvnmkudPv9zSOPCmD2e4iAQAXdVZnVijeBygjqCrhpE47GOC0HzKZqVkqQj5nnrAcdb QGgiuEFcLL75Zrkpq0+0GiBNyIcLrQKQ+B/iKTJkp+cbdPqavMvgvTgjdTPITXrQww5F YuweHVDM3hsvmEdiYvGHq86IWXoa8l/bDLGkRNrnerHeFiMsdONkA7fC5DEfQaNnTno6 KltDaUwmjaUqTKuQmgoixem419yTekt/29vMa4b6CoCC1zhCfVFoEl/Q58Fxe4uwgrdY uwFA== X-Gm-Message-State: AOPr4FVJI2UsEJDbYvVw7OpQPLholCEM0ni0TolNl9Nt1riygPj3lShH/3HBulcJ0rcNVvfM X-Received: by 10.55.80.131 with SMTP id e125mr11811060qkb.62.1461161881259; Wed, 20 Apr 2016 07:18:01 -0700 (PDT) Received: from wlan-196-245.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id 144sm1690553qhz.14.2016.04.20.07.17.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 07:17:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Azhar Sayeed In-Reply-To: <592C0220-7CE8-46A6-8181-2AA7EF1CA63D@cisco.com> Date: Wed, 20 Apr 2016 10:18:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57133AED.4080005@pi.nu> <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> <592C0220-7CE8-46A6-8181-2AA7EF1CA63D@cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 14:18:05 -0000 Carlos, We agree to disagree =E2=80=A6 My argument was fairly simple - if you call this a TLV then I gave you = an option to align to a TLV structure without breaking the proposed = structure too much=E2=80=A6you can call it what you want - call it an = informational element, call it a metadata structure or call it some = thing else - just don=E2=80=99t call it a TLV=E2=80=A6in which case we = are squared The difference between what I am stating and what you are arguing is not = much=E2=80=A6I am not proposing to take away the class field or to take = away the flags - (although I would argue why do you need a class field = when you already have a type - if you make type 16 bits then it covers = both class and type as proposed originally) I can see Med=E2=80=99s point that we want the header to be compact in = which case you can shrink the length or the type field or both=E2=80=A6If = you move the flags around then the structure does conform to TLV - If = you are not calling it a TLV but calling this a metadata spec then = ignore my comments Azhar > On Apr 19, 2016, at 10:41 PM, Carlos Pignataro (cpignata) = wrote: >=20 > Azhar, >=20 > -1 :-) >=20 > Within the IETF-specified protocols, we can certainly find examples of = most syntax and structures, from the simple to the too creative ones. = Finding a protocol with a specific TLV structure does not mean that = that=E2=80=99s the best for every protocol use. >=20 > You say: "This should also be consistent=E2=80=9D. >=20 > However, just to understand your point, what is the technical reason = for NSH TLV structs having to match BFD structs and ISIS structs? And = why not, say, RSVP=E2=80=99s or ICMP Multipart=E2=80=99s or L2TPv3=E2=80=99= s (which, incidentally, use a Class/Type-length-value format)? >=20 > When you say =E2=80=9C to align with all the other TLV=E2=80=99s = structure=E2=80=9D =E2=80=94 I ask: why? >=20 > If we think of the goal of flexibility (main goal of Type 2) in the = context of most flexible allocation, a hierarchical scheme is a = technical answer. Given the rich ecosystem of vendors and open source = projects, the proposed structure, in my humble opinion, future proofs = the design. >=20 > =E2=80=94 Carlos. >=20 >> On Apr 18, 2016, at 10:33 AM, Azhar Sayeed = wrote: >>=20 >> Loa, >>=20 >> +1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs have = the same structure - This should also be consistent..the question then = is can the current TLV structure in draft-~nsh-04 be re-configured to = align with all the other TLV=E2=80=99s structure? >>=20 >> Azhar >>=20 >>=20 >>> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>>=20 >>> Working Group, authors, >>>=20 >>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >>> it before now) and have a question on how the TLV concept is = understood >>> in the draft. >>>=20 >>> For example in LDP TLV were defined as Type, Length Value, e.g. = (from >>> RFC 5036 section 3.3): >>>=20 >>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of >>> the information carried in LDP messages. >>>=20 >>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify >>> a Type and 2 bits to specify behavior when an LSR doesn't recognize >>> the Type, followed by a 2 octet Length field, followed by a variable >>> length Value field. >>>=20 >>>=20 >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |U|F| Type | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> | Value | >>> ~ ~ >>> | | >>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >>> and I'm struggling a bit to understand if the "name" TLV should be = used. >>>=20 >>> =46rom draft-ietf-sfc-nsh-04 >>>=20 >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV Class |C| Type |R|R|R| Len = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Variable Metadata = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>>=20 >>> Figure 6: Variable Context Headers >>>=20 >>> The draft is not entirely clear in this respect, but I think this is = what you call a TLV. >>>=20 >>> Should I understand this way? >>>=20 >>> Type =3D TLV Class + C + Type (24 bits) >>> Length =3D len (5 bits) >>> Value =3D Variable Metadata >>>=20 >>> A convention we used in MPLS when we have variable length fields is >>> to use a ~ instead of the |, like this:. >>>=20 >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV Class |C| Type |R|R|R| Len = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> ~ Variable Metadata = ~ >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> I suggest that this is a good practice that could be adopted here = also. >>>=20 >>> Two more questions: >>>=20 >>> If the metadata does not align exactly with the 32 bit/4 byte = structure, >>> what is the rules for padding? >>>=20 >>> A last, but a bit different question, do you need indicators like = the U >>> and F flags in an to indicate what should happen if the node does = not >>> recognize the (TLV Class, C, Type)-field? >>>=20 >>> /Loa >>>=20 >>>=20 >>> PS >>>=20 >>> I will also have a few more editorial comments that will be sent to >>> the authors within a day or two. >>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 20 07:25:00 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 BF6D312D843 for ; Wed, 20 Apr 2016 07:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 XMt_UM0L3v72 for ; Wed, 20 Apr 2016 07:24:57 -0700 (PDT) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (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 6431712D956 for ; Wed, 20 Apr 2016 07:24:55 -0700 (PDT) Received: by mail-qk0-f171.google.com with SMTP id q76so5224548qke.2 for ; Wed, 20 Apr 2016 07:24:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j2Row4TRfdIhVAPAvxeAYt6znC0L3RBlr5vmsosMRg4=; b=an4M7jrPEDKbHIzduQbg8kgTxehljFtTNOIAcC06D/XWd+A+N32ZNhZgs9216XC7gv gEQwtVnVJdWWwjjRM6kF2p8JcXnR26EDd4AqfijnoTYIUX3FuQlkpvnjTRZi565dA+nR D+Cr+M4Koh6ejCG6asmMxCmdeGvElEWlchxiyTyg3BGG+8vQ5WWRnEHpd+F4fxG48oN5 7fJv6+VTX3do6Q8C0uU9Skp2Rav9yNMyJkyAArPEhB/LHSdpD839ACu48XQIVHJcTatZ +ngTJTqsLBmqEm2J6YVu7H2VPjkkDi5dCT7CS+xcSYeT9+Whfi1Fabd5ncFWyZdIbPVv z/WQ== X-Gm-Message-State: AOPr4FUWoN5Yqg/P09Xkx4Ljp8JJnlMS8h0KSlM9YfEWbnGO5kf8JTKjinw7SugSw4TrT4Ha X-Received: by 10.55.203.131 with SMTP id u3mr11616227qkl.16.1461162294352; Wed, 20 Apr 2016 07:24:54 -0700 (PDT) Received: from wlan-196-245.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id a123sm6418444qkc.23.2016.04.20.07.24.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Apr 2016 07:24:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Azhar Sayeed In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5CBB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 20 Apr 2016 10:25:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77E3E0A5-AA19-4E40-886E-A1739B1BEC45@redhat.com> References: <57133AED.4080005@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5CBB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 14:24:59 -0000 You have a point - perhaps shortening the length and type will = help..however, here is my rationale for longer length field 8 bits I feel is too little for metadata - just about twice as many in a = tweet :-) Azhar > On Apr 20, 2016, at 1:44 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Azhar,=20 >=20 > Thank you for the feedback and the support for the originator ID.=20 >=20 > The re-arranging of the fields you propose is indeed another option, = but it does not allow a compact header, e.g., 16 bits for the length is = too much for the cases I'm aware of + it is not optimal if no originator = ID is to be supplied for instance.=20 >=20 > Having the class, type, flags, and length in the first 32 bits would = lead to a compact header.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Azhar Sayeed [mailto:asayeed@redhat.com] >> Envoy=E9 : mardi 19 avril 2016 22:17 >> =C0 : BOUCADAIR Mohamed IMT/OLN >> Cc : Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - = Questions >> on TLVs in draft-ietf-sfc-nsh >>=20 >> Hi Med, >>=20 >> You can still encode this as a TLV by re-arranging the fields with = Type >> first, length and then value - In the value portions you can a = mandatory >> bytes that encode the flags, class, originator id and then variable >> metadata >>=20 >> So here is an option. >>=20 >> Type - 16 bits >> Length - 16 bits >> Value: >> Flags - 4 bits >> Class - 4 bits >> Originator Length - 8 bits >> Originator ID - Variable >> Data Variable >>=20 >> +1 to the idea of originator id. >>=20 >>=20 >> Azhar >>=20 >>=20 >>=20 >>> On Apr 19, 2016, at 3:48 AM, mohamed.boucadair@orange.com wrote: >>>=20 >>> Dear Loa, all, >>>=20 >>> Thank you for raising this point about the encoding of the optional >> context information. >>>=20 >>> I agree that the use of TLV term is confusing. What about using = another >> term, e.g., "Information Elements", "Options", or "Context Element"? >>>=20 >>> As an input to this discussion, below a proposal for an encoding = that >> achieves the following goals: >>>=20 >>> * Shorten the encoding of the Class field. >>> * Allow for more type code points. >>> * Avoids requiring padding for the sake of compact headers. >>> * Allows to include the ID of the entity that injected the context >> information (OPTIONAL). >>> * Inherit rich registries such as IPFIX. >>>=20 >>> NOTE: This proposal does not include a dedicated flag bit to = indicate >> whether the context element is mandatory-to-process or = optional-to-process >> because further discussion/text specification is required: e.g., >>> * Wouldn't be sufficient to supply that information using the = control >> plane? >>> * If that information is supplied in both the context element and >> configured to a SFC-aware function, how conflicts are managed? >>> * What is the behavior for processing mandatory-to-process elements >> (particularly, when it is not supported)? >>> * Is it required to recommend an ordering of supplying the = mandatory-to- >> process or optional-to-process elements? >>> * Is it required to preserve the same ordering when forwarding a = packet? >>>=20 >>> =3D=3DPROPOSAL=3D=3D=3D=3D >>>=20 >>> Base version >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Class | Type | FLAGS | Length = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> // Data (Variable) = // >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Version with Originator ID: >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Class | Type | Flags | Length = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> //Originator Len| Originator ID (Variable)(Optional) = // >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> // Data (Variable) = // >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> The description of the fields is as follows: >>>=20 >>> Class: In order to foster service innovation, this field >>> allows to inherit from existing code point registries that = are >>> likely to be useful in a SFC context. The following values = are >>> reserved by this specification: >>> 0: See IANA section. >>> 1: IPFIX [IPFIX]. >>>=20 >>> Type: Indicates the code point of the context element. If >>> "Class" field is non-null, the interpretation of this field = MUST >>> conform to the one defined for that specific class registry. = See >> IANA section. >>>=20 >>> Flags: The Flags field comprises a set of 4 flags: >>>=20 >>> +-+-+-+-+ >>> |S|r|r|r| >>> +-+-+-+-+ >>>=20 >>> where "rrr" are reserved bits for future assignment as >>> additional flag bits. r bits MUST each be sent as zero = and >> MUST be >>> ignored on receipt. >>>=20 >>> When set, the S-flag indicates that an Originator ID = field >> is >>> present in the context element. This flag is set by = default >> to 0, meaning >>> there is no Originator ID field present in the element. >>>=20 >>> Originator ID (Optional): Conveys the identifier of the entity >> that injected >>> this context element in the NSH header (e.g., a service >>> function identifier, a classifier, etc.). This document does >>> not make any assumption about the structure of the = information >>> carried in this field because this is deployment-specific. >>> This information is used by SFC-aware elements to enforce >>> policies such as: process a context information if and only = if >>> it was supplied by a given entity. This information can be >>> used as a safeguard against misbehaving nodes that inject >>> illegitimate data in the NSH header. >>>=20 >>> This field MUST be included only if S-bit is set. >>>=20 >>> Length: Indicates, in octets, the length of the data carried in >>> the context element. >>>=20 >>> Data (Variable): The semantics of this field depend on the >>> "Class" and "Type" fields. >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Opinions? >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson >>>> Envoy=E9 : dimanche 17 avril 2016 09:28 >>>> =C0 : sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org >>>> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - = Questions on >>>> TLVs in draft-ietf-sfc-nsh >>>>=20 >>>> Working Group, authors, >>>>=20 >>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >>>> it before now) and have a question on how the TLV concept is = understood >>>> in the draft. >>>>=20 >>>> For example in LDP TLV were defined as Type, Length Value, e.g. = (from >>>> RFC 5036 section 3.3): >>>>=20 >>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much = of >>>> the information carried in LDP messages. >>>>=20 >>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to >> specify >>>> a Type and 2 bits to specify behavior when an LSR doesn't = recognize >>>> the Type, followed by a 2 octet Length field, followed by a = variable >>>> length Value field. >>>>=20 >>>>=20 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |U|F| Type | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> | Value | >>>> ~ ~ >>>> | | >>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >>>> and I'm struggling a bit to understand if the "name" TLV should be >> used. >>>>=20 >>>> =46rom draft-ietf-sfc-nsh-04 >>>>=20 >>>> 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 >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> | TLV Class |C| Type |R|R|R| Len >> | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> | Variable Metadata >> | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>>=20 >>>>=20 >>>>=20 >>>> Figure 6: Variable Context Headers >>>>=20 >>>> The draft is not entirely clear in this respect, but I think this = is >>>> what you call a TLV. >>>>=20 >>>> Should I understand this way? >>>>=20 >>>> Type =3D TLV Class + C + Type (24 bits) >>>> Length =3D len (5 bits) >>>> Value =3D Variable Metadata >>>>=20 >>>> A convention we used in MPLS when we have variable length fields is >>>> to use a ~ instead of the |, like this:. >>>>=20 >>>> 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 >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> | TLV Class |C| Type |R|R|R| Len >> | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> ~ Variable Metadata >> ~ >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>>=20 >>>> I suggest that this is a good practice that could be adopted here = also. >>>>=20 >>>> Two more questions: >>>>=20 >>>> If the metadata does not align exactly with the 32 bit/4 byte >> structure, >>>> what is the rules for padding? >>>>=20 >>>> A last, but a bit different question, do you need indicators like = the U >>>> and F flags in an to indicate what should happen if the node does = not >>>> recognize the (TLV Class, C, Type)-field? >>>>=20 >>>> /Loa >>>>=20 >>>>=20 >>>> PS >>>>=20 >>>> I will also have a few more editorial comments that will be sent to >>>> the authors within a day or two. >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>=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 Apr 20 07:33:38 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 11D2D12EF6F; Wed, 20 Apr 2016 07:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 dR5P7zSF3WlI; Wed, 20 Apr 2016 07:33:35 -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 52E3412EF5A; Wed, 20 Apr 2016 07:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9206; q=dns/txt; s=iport; t=1461162811; x=1462372411; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KT9dGiB3yjx2QW6e88y6EypreWtJ+OmCkaX4iHDNcqA=; b=QyqkgPL+Hv6iVQ5CG97s/ielNSDD1rI6CtML54vZkWyigL0nYv07tf4D LVLGOMAtWMIQ3Ehaz+BpsIKuZ9Ncfdul8VLdPJYuerNUCo948FeC/ozfc uj0EEGIvJFSmQyQndZ18sEqVT8GnCgBBqmuVbcDbltXHHPTYv9jhsW4Ev I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAwC0khdX/5JdJa1egzhTfQa5ZQ6Bc?= =?us-ascii?q?RcLghiDVAKBQDgUAQEBAQEBAWUcC4RBAQEBAwEBAQEaBkQEAwsFCQICAQgYJwM?= =?us-ascii?q?CAhsMCxQRAgQOBQ6IEwgOrRiQfgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBASGH?= =?us-ascii?q?YF1CIFMgQKEDxEBgx4rgisFjVOFS4RxAYMngWZtiBmBZod2hTSGI4kJAR4BQ4I?= =?us-ascii?q?zgTVsAYcSNn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,510,1454976000"; d="asc'?scan'208";a="93921288" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 14:33:29 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3KEXTOB015106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 14:33:29 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 10:33:28 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 10:33:28 -0400 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqvPG9+wCOo5UWLeYjmbm2Pnp+SbKQAgABBmACAAIcQgA== Date: Wed, 20 Apr 2016 14:33:28 +0000 Message-ID: <555A080F-FA59-4305-8CEE-62C33BF18495@cisco.com> References: <57133AED.4080005@pi.nu> <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> <787AE7BB302AE849A7480A190F8B933008D5CC0B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5CC0B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.253.120] Content-Type: multipart/signed; boundary="Apple-Mail=_ABBFA2C0-D2DD-4B2D-ADCC-D23F6219DD0D"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 14:33:37 -0000 --Apple-Mail=_ABBFA2C0-D2DD-4B2D-ADCC-D23F6219DD0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Med, To clarify part of my comment, I cited some RFCs that came to mind that = provide a hierarchical structure. It is not an exhaustive list, nor a = sample to extrapolate too far on other fields. What we should look for = is what=E2=80=99s most useful for this use. Thanks! =E2=80=94 Carlos. > On Apr 20, 2016, at 2:30 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi all, >=20 > I agree with Carlos that a hierarchical structure is more flexible, = but I have the following comments: >=20 > * Almost all the RFCs quoted by Carlos do not claim to use a TLV = structure or the TLV term. It is reasonable to update the nsh spec to = use a term that does not lead to confusion. I see that Carlos is using = "information element". It is also in my favorite list (with a preference = for context element). > * Some of these RFCs use a bit that is similar to the C-bit, but they = rightfully don't mix it with the ID of the attribute. > * Some of these RFCs specify (e.g., Section 5.2 of RFC3931) in details = the behavior when the "C-bit"-like is set. >=20 > The NSH spec still need more work. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Carlos Pignataro >> (cpignata) >> Envoy=C3=A9 : mercredi 20 avril 2016 04:35 >> =C3=80 : Loa Andersson >> Cc : draft-ietf-sfc-nsh@ietf.org; sfc@ietf.org >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - = Questions >> on TLVs in draft-ietf-sfc-nsh >>=20 >> Hi, Loa, >>=20 >> Good analysis on the format of these information elements. >>=20 >> My sense is that a hierarchical syntax (such as the = Class/Type-Length- >> Value) provides much more flexibility than a flat Type-Length-Value = alone. >>=20 >> We=E2=80=99ve built quite a number of protocols with this structure = and allocation >> scheme. For example, RSVP = (https://tools.ietf.org/html/rfc3209#section- >> 7.2), L2TPv3 (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP >> Multi-Part Extensions = (https://tools.ietf.org/html/rfc4884#section-8). >>=20 >> Regardless of what we call the fields (e.g., Class and Type, or Type = and >> Sub-Type, or =E2=80=A6), there are clear technical advantages to = this, including >> the ability to delegate allocation, vendor types, etc. >>=20 >> In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs = achieves >> what=E2=80=99s really needed for an SFC Encap. >>=20 >> Lastly, you call out padding and 32-bit-word alignment. This is a = great >> point. >>=20 >> The way things seems structured now, there=E2=80=99s a Len field = measured in 32- >> bit words. It=E2=80=99s not clear what happens when the Metadata = (Value) itself is >> not 32-bit-word-aligned. This needs fixing. >>=20 >> Looking at the Length definition: >>=20 >> Length: Length of the variable metadata, in 4-byte words. A value = of >> 0x0 or higher can be used. A value of 0x0 denotes a TLV header >> without a Variable Metadata field. >>=20 >> Comments: >> * First, instead of =E2=80=9C4-byte=E2=80=9D words, this needs to be = =E2=80=9C4-octet=E2=80=9D or =E2=80=9C32-bit=E2=80=9D >> words. Byte is strictly machine dependent (7 bits, 8 bits, etc). >> * Second, =E2=80=9Ca value of 0x0 or higher=E2=80=9D for an unsigned = value does not say >> much. >>=20 >> Hope these help. >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>>=20 >>> Working Group, authors, >>>=20 >>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >>> it before now) and have a question on how the TLV concept is = understood >>> in the draft. >>>=20 >>> For example in LDP TLV were defined as Type, Length Value, e.g. = (from >>> RFC 5036 section 3.3): >>>=20 >>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much = of >>> the information carried in LDP messages. >>>=20 >>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify >>> a Type and 2 bits to specify behavior when an LSR doesn't recognize >>> the Type, followed by a 2 octet Length field, followed by a = variable >>> length Value field. >>>=20 >>>=20 >>> 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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |U|F| Type | Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> | Value | >>> ~ ~ >>> | | >>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >>> and I'm struggling a bit to understand if the "name" TLV should be = used. >>>=20 >>> =46rom draft-ietf-sfc-nsh-04 >>>=20 >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV Class |C| Type |R|R|R| Len = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Variable Metadata = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>>=20 >>> Figure 6: Variable Context Headers >>>=20 >>> The draft is not entirely clear in this respect, but I think this is >> what you call a TLV. >>>=20 >>> Should I understand this way? >>>=20 >>> Type =3D TLV Class + C + Type (24 bits) >>> Length =3D len (5 bits) >>> Value =3D Variable Metadata >>>=20 >>> A convention we used in MPLS when we have variable length fields is >>> to use a ~ instead of the |, like this:. >>>=20 >>> 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 >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | TLV Class |C| Type |R|R|R| Len = | >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> ~ Variable Metadata = ~ >>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> I suggest that this is a good practice that could be adopted here = also. >>>=20 >>> Two more questions: >>>=20 >>> If the metadata does not align exactly with the 32 bit/4 byte = structure, >>> what is the rules for padding? >>>=20 >>> A last, but a bit different question, do you need indicators like = the U >>> and F flags in an to indicate what should happen if the node does = not >>> recognize the (TLV Class, C, Type)-field? >>>=20 >>> /Loa >>>=20 >>>=20 >>> PS >>>=20 >>> I will also have a few more editorial comments that will be sent to >>> the authors within a day or two. >>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_ABBFA2C0-D2DD-4B2D-ADCC-D23F6219DD0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXF5M3AAoJEIXgpQGOZny9wJ8P/0rco0WI7kKju2t1TcY8vrZi GZFKCvDeYANEiQftPDafh0Rec0fMjAQMqSSJCzdEHaigOvAwWozZ+viwIolWNX0Q kNHwMi4NEUhsf7KG0KstUZWyEIJhEo2lLQDJAjIdjs15xW4c72ns21wkyi+6TWvl VtL35sgx/lA89+ZXZ4v3c5kEqY2AIG0/pL76YcHWSebBsjpiQ9VmM0nseBdVjTk4 Aqu5nCyG85zShw7t7476zdEB+RH8rFpTVmxhTe66/v6kzw+HRIDVELe10ipWtJ// Mhtfwjgkhsjtx1efMY0q2cICnv5WQe27y2x3p99sCVai9HNO/l9hmyaoIET70Ga8 /YZ8wpHRpZj2CCLHiG7icxW1yv+TwQ6lZQh+Ns+Y9xsaQMC6eyilqXFy/pjciCCn Pi/ZOW6GDz0ZeILHz9Gl7bQaF+Qrqo6H+qvHoiuRjvrqpQ2ikLyOhs9I07k7c5I3 /vsPhXtDassByi3kpRDH/1HntuTUjljIgt0xEzXrNjMfLn/qx6YVMBboiBvS2J7z 6FeY40RL2H+pRpz/WposfAJhnO0jrKtUdrFDBGDwC4r/SzXV6E23dZK2UU/ZANsM xRATwjvHSgM10HzMyvHdLYyruH77MYRq0G1NtOkkzjG5fq9WyFg5GNvgmn+takJ1 kI/QfjLUDhfUDNoWSHln =yYXk -----END PGP SIGNATURE----- --Apple-Mail=_ABBFA2C0-D2DD-4B2D-ADCC-D23F6219DD0D-- From nobody Wed Apr 20 07:36:42 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 7FABE12EF6F; Wed, 20 Apr 2016 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 LRUUoiEHj4Vn; Wed, 20 Apr 2016 07:36:39 -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 1FB8E12EF71; Wed, 20 Apr 2016 07:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9548; q=dns/txt; s=iport; t=1461162999; x=1462372599; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BBzNRNI2q02Tq5mM56N5kW3ltXf4gklmr0bt74hkfco=; b=NSxHapiCHF0SAV8HB+NEr061eDr1bfVyBBcKrc9HOglHjc/OAnxrReh1 eSk+Q+71yeY7xe+i3y3TXJET48cBIqoZxSvT4mjykwr5qEup9y9YFUPus xG4rGPQyw8deJ0mmmFXEcM91FBukmnMkxbAVFsgkOdeK58KPTRUzU/8NC w=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAwB0khdX/5hdJa1egzhTfQa5ZQ6Bc?= =?us-ascii?q?RcLghiDVAKBQDgUAQEBAQEBAWUnhEEBAQEDAQEBARoGRAQDCwUJAgIBBgIOCio?= =?us-ascii?q?CAhsMCyUCBA4FDogTCA6Pfp0XkH4BAQEBAQEBAQEBAQEBAQEBAQEBAQENBAQEh?= =?us-ascii?q?h2BdQiCToQPEQGDHiuCKwWHdoVdijwBgyeBZokGgWaHdoU0jywBHgFDggQaFYE?= =?us-ascii?q?1bIcTNn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,510,1454976000"; d="asc'?scan'208";a="263783882" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 14:36:37 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3KEaaYj015361 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 14:36:36 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 10:36:35 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 10:36:35 -0400 From: "Carlos Pignataro (cpignata)" To: Azhar Sayeed Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqvPG9+wCOo5UWLeYjmbm2Pnp+QEKeAgAJd1QCAAMK0AIAABPsA Date: Wed, 20 Apr 2016 14:36:35 +0000 Message-ID: <4674AF21-386A-4FC4-9714-9D6D003250BE@cisco.com> References: <57133AED.4080005@pi.nu> <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> <592C0220-7CE8-46A6-8181-2AA7EF1CA63D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.253.120] Content-Type: multipart/signed; boundary="Apple-Mail=_1FA3AEED-0899-4694-A86C-56B614A647EF"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 14:36:41 -0000 --Apple-Mail=_1FA3AEED-0899-4694-A86C-56B614A647EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Azhar, You wrote =E2=80=9Cthe question then is can the current TLV structure in = draft-~nsh-04 be re-configured to align with all the other TLV=E2=80=99s = structure=E2=80=9D, and I interpreted that, likely misinterpreted, as = =E2=80=9Clet=E2=80=99s shuffle all bits-on-the-wire to have only a = single flat Type, a length, and a value. If instead you meant =E2=80=9Cwe = can rename things=E2=80=9D, that=E2=80=99s different. Note I said = =E2=80=9Cinformation element=E2=80=9D to most generically refer to a = protocol element which provides information. Thanks, =E2=80=94 Carlos. > On Apr 20, 2016, at 10:18 AM, Azhar Sayeed wrote: >=20 > Carlos, >=20 > We agree to disagree =E2=80=A6 >=20 > My argument was fairly simple - if you call this a TLV then I gave you = an option to align to a TLV structure without breaking the proposed = structure too much=E2=80=A6you can call it what you want - call it an = informational element, call it a metadata structure or call it some = thing else - just don=E2=80=99t call it a TLV=E2=80=A6in which case we = are squared >=20 > The difference between what I am stating and what you are arguing is = not much=E2=80=A6I am not proposing to take away the class field or to = take away the flags - (although I would argue why do you need a class = field when you already have a type - if you make type 16 bits then it = covers both class and type as proposed originally) >=20 > I can see Med=E2=80=99s point that we want the header to be compact in = which case you can shrink the length or the type field or both=E2=80=A6If = you move the flags around then the structure does conform to TLV - If = you are not calling it a TLV but calling this a metadata spec then = ignore my comments >=20 > Azhar >=20 >=20 >> On Apr 19, 2016, at 10:41 PM, Carlos Pignataro (cpignata) = wrote: >>=20 >> Azhar, >>=20 >> -1 :-) >>=20 >> Within the IETF-specified protocols, we can certainly find examples = of most syntax and structures, from the simple to the too creative ones. = Finding a protocol with a specific TLV structure does not mean that = that=E2=80=99s the best for every protocol use. >>=20 >> You say: "This should also be consistent=E2=80=9D. >>=20 >> However, just to understand your point, what is the technical reason = for NSH TLV structs having to match BFD structs and ISIS structs? And = why not, say, RSVP=E2=80=99s or ICMP Multipart=E2=80=99s or L2TPv3=E2=80=99= s (which, incidentally, use a Class/Type-length-value format)? >>=20 >> When you say =E2=80=9C to align with all the other TLV=E2=80=99s = structure=E2=80=9D =E2=80=94 I ask: why? >>=20 >> If we think of the goal of flexibility (main goal of Type 2) in the = context of most flexible allocation, a hierarchical scheme is a = technical answer. Given the rich ecosystem of vendors and open source = projects, the proposed structure, in my humble opinion, future proofs = the design. >>=20 >> =E2=80=94 Carlos. >>=20 >>> On Apr 18, 2016, at 10:33 AM, Azhar Sayeed = wrote: >>>=20 >>> Loa, >>>=20 >>> +1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs have = the same structure - This should also be consistent..the question then = is can the current TLV structure in draft-~nsh-04 be re-configured to = align with all the other TLV=E2=80=99s structure? >>>=20 >>> Azhar >>>=20 >>>=20 >>>> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>>>=20 >>>> Working Group, authors, >>>>=20 >>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >>>> it before now) and have a question on how the TLV concept is = understood >>>> in the draft. >>>>=20 >>>> For example in LDP TLV were defined as Type, Length Value, e.g. = (from >>>> RFC 5036 section 3.3): >>>>=20 >>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much = of >>>> the information carried in LDP messages. >>>>=20 >>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify >>>> a Type and 2 bits to specify behavior when an LSR doesn't recognize >>>> the Type, followed by a 2 octet Length field, followed by a = variable >>>> length Value field. >>>>=20 >>>>=20 >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |U|F| Type | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> | Value | >>>> ~ ~ >>>> | | >>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >>>> and I'm struggling a bit to understand if the "name" TLV should be = used. >>>>=20 >>>> =46rom draft-ietf-sfc-nsh-04 >>>>=20 >>>> 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 >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | TLV Class |C| Type |R|R|R| Len = | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Variable Metadata = | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>>=20 >>>>=20 >>>> Figure 6: Variable Context Headers >>>>=20 >>>> The draft is not entirely clear in this respect, but I think this = is what you call a TLV. >>>>=20 >>>> Should I understand this way? >>>>=20 >>>> Type =3D TLV Class + C + Type (24 bits) >>>> Length =3D len (5 bits) >>>> Value =3D Variable Metadata >>>>=20 >>>> A convention we used in MPLS when we have variable length fields is >>>> to use a ~ instead of the |, like this:. >>>>=20 >>>> 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 >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | TLV Class |C| Type |R|R|R| Len = | >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> ~ Variable Metadata = ~ >>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>=20 >>>> I suggest that this is a good practice that could be adopted here = also. >>>>=20 >>>> Two more questions: >>>>=20 >>>> If the metadata does not align exactly with the 32 bit/4 byte = structure, >>>> what is the rules for padding? >>>>=20 >>>> A last, but a bit different question, do you need indicators like = the U >>>> and F flags in an to indicate what should happen if the node does = not >>>> recognize the (TLV Class, C, Type)-field? >>>>=20 >>>> /Loa >>>>=20 >>>>=20 >>>> PS >>>>=20 >>>> I will also have a few more editorial comments that will be sent to >>>> the authors within a day or two. >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_1FA3AEED-0899-4694-A86C-56B614A647EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXF5PyAAoJEIXgpQGOZny9obAP/jAO2j8lP6V+Fg4wgPaWcEPZ 0RpyuVhydL7MUxTpi6CyvkFV4RORsogsyEcpNgBYGPFe0nfwS/gl9hPIMoXm7rsF FhfNK/yy30Ls0R+5430xgcTlhWxiS13rVZixxIUmn83Fivhe4UwESULXbRA9JHFG V5bi6Z+GGluKwWUcE2e3iqlgZaC+eL2R3tTIO6xCS4Ky1D6gzpCuOEEi4EJxIGTH cE5laHwKile5hrFgF3ifHZ4qGjNhbbDba7bvoeo6g4GZIyjCGOel83Qg3S7qhrie ORkckkilYA1bLkqK1K4W6anSBZmuIYdIHvKhie90JRnrdkVJsrhOqX2kx9Ftfm+h EBZdpSey6o4VeU7m7gSp11K4QZoW+uaQDYm1HOXR6poqxip+9LX4WaCJihs3gDfk ZIZ/dlRLNUG3d6rMKXG8MbvK9sXVrcqh+eYzfz+eHJ56JRQY6rdXwibF1ULzLNJ/ AzJhJlw8Z2WfH06u1sL1qVmjhZczUo5PF+skes0TDKdyY8pgobbbKPE+R+EoYfzU /yJDEigNbuOGwUvh5axTZ1ChJrs/edst1yXkCNr597Axb9t4gn+xK2gGh/nLvo2L /aK/lygw6z3PNhFbyG+jbzdR7d1+DUb6g1Y6hPoBNM5DhImR8c4+FKjCuP2mhWQi eZDAfCthlg9X/ARdXD6N =xpuZ -----END PGP SIGNATURE----- --Apple-Mail=_1FA3AEED-0899-4694-A86C-56B614A647EF-- From nobody Wed Apr 20 07:46:29 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 3385612DD8D; Wed, 20 Apr 2016 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 KuCCDd-ud51H; Wed, 20 Apr 2016 07:46:26 -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 B7C3A12DCF5; Wed, 20 Apr 2016 07:46:25 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 DCCD61802ACF; Wed, 20 Apr 2016 16:46:20 +0200 (CEST) To: mohamed.boucadair@orange.com References: <57133AED.4080005@pi.nu> <46AB5547-90B8-4F2D-B72B-644F3FDC3E70@cisco.com> <571734F7.4030804@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5CCE1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Loa Andersson Message-ID: <57179628.3090302@pi.nu> Date: Wed, 20 Apr 2016 22:46:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5CCE1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 14:46:28 -0000 Med, On 2016-04-20 16:09, mohamed.boucadair@orange.com wrote: > Dear Loa, > > Thank you for drafting a NEW text that is better to the one in -04. Nevertheless, I still have issues with it but I will focus only on one item that it is related to this text: > > "This effectively allocates > TLV-Type values 0 to 127 for non-critical options and Type values > 128 to 255 for critical options." > > Do you have an example of an optional context information that is "critical" in all deployments, all chains? Wouldn't this be left to the taste of the entity administrating an SFC-enabled domain? > No not really, I took that part of the content from the original draft, but you have a point, I remember that I had a note while reading the draft for wglc, whether it was like we have 127 types where the C-bit could be set or net. The text however says that there will be 256 types, and if the most significant bit is it is dritical. Maybe worth asking the authors the question you asked me? /Loa > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson >> Envoyé : mercredi 20 avril 2016 09:51 >> À : Carlos Pignataro (cpignata) >> Cc : draft-ietf-sfc-nsh@ietf.org; sfc@ietf.org >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions >> on TLVs in draft-ietf-sfc-nsh >> >> Carlos, >> >> Thanks for this, I don't think we are too far apart, and I have a >> suggestion that I hope resolve this. >> >> On 2016-04-20 10:35, Carlos Pignataro (cpignata) wrote: >>> Hi, Loa, >>> >>> Good analysis on the format of these information elements. >>> >>> My sense is that a hierarchical syntax (such as the Class/Type-Length- >> Value) provides much more flexibility than a flat Type-Length-Value alone. >> >> I tend to agree with that, but that is an argument on if the flexibility >> is needed. I think it is for the NSH. >> >> My point is that TLV is "named" for its structure, if an element does >> notm have that structure it is simply not a TLV. >> >> On the highest level I do not have a problem with the layout of the >> Variable Context Headers, but currently it is not clear why we call >> it a TLV. It could be made clear though. >>> >>> We’ve built quite a number of protocols with this structure and >> allocation scheme. For example, RSVP >> (https://tools.ietf.org/html/rfc3209#section-7.2), L2TPv3 >> (https://tools.ietf.org/html/rfc3931#section-5.1), ICMP Multi-Part >> Extensions (https://tools.ietf.org/html/rfc4884#section-8). >>> >> Indeed, but of the three documents you refer to only the L2TPv3 >> document mention TLV, and only on a very high level in the terminology >> section. >> >>> Regardless of what we call the fields (e.g., Class and Type, or Type and >> Sub-Type, or …), there are clear technical advantages to this, including >> the ability to delegate allocation, vendor types, etc. >>> >> My point was that what we call things matter. >> >>> In regards to the U/F bits in LDP, I think the C-bit in NSH TLVs >> achieves what’s really needed for an SFC Encap. >>> >> This is the response I expected, though I'm still not entirely >> comfortable, e.g. what do you do if you don't recognize the class >> and the C bit is not set? >> >>> Lastly, you call out padding and 32-bit-word alignment. This is a great >> point. >>> >>> The way things seems structured now, there’s a Len field measured in 32- >> bit words. It’s not clear what happens when the Metadata (Value) itself is >> not 32-bit-word-aligned. This needs fixing. >>> >>> Looking at the Length definition: >>> >>> Length: Length of the variable metadata, in 4-byte words. A value >> of >>> 0x0 or higher can be used. A value of 0x0 denotes a TLV header >>> without a Variable Metadata field. >>> >>> Comments: >>> * First, instead of “4-byte†words, this needs to be “4-octet†or “32- >> bit†words. Byte is strictly machine dependent (7 bits, 8 bits, etc). >>> * Second, “a value of 0x0 or higher†for an unsigned value does not say >> much. >> >> Agree to changing to "octet". >> >> Actually the Len field is 5 bits, gives us 32 variants, zero means >> "none", while 31 means 31 x 4 = 124 octets. >> >> What I suggest that we add (we can continue to discuss sizes of the >> differnt fields). I've not look closely where my text would fit >> exactly. >> >> 3.5.1. Optional Variable Length Metadata >> >> Optional variable length metadata are encoded as Variable Context >> Header TLVs The Variable Context Headers TLV has the same structure >> as TLVs defined in e.g. the LDP and BFD protocols, Type, Length and >> Value. >> >> However in the Variable Context Header TLV the Type field have an >> internal structure TLV Class, C-bit and Type. >> >> The format of the optional variable length context header TLVs, 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| TLV-Type |R|R|R| Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Figure 6: Variable Context Headers >> >> Type: The type field has three sub-fields, TLV Class, TLV Type and >> Len, the TLV-Type and Len fields have an internal structure. >> >> TLV Class: The TLV Class field is 16 bits and describes the scope >> of the "Type" field. In some cases, the TLV Class will identify a >> specific vendor, in others, the TLV Class will identify specific >> standards body allocated types. A new IANA registry will be >> created for TLV Class type. >> >> Type: The TLV-Type field is 8 bits and the specifies the type of >> information carried in the Variable Metadata field, within the >> scope of a given TLV Class. Value allocation is the responsibility >> of the TLV Class owner. >> >> The Critical bit (C-bit); 1 bit, encoding the criticality of the >> TLV-type. The C-bit is part of the TLV-Type field and is >> consistent with IPv6 option types. The C-bit (the most significant >> bit of the TLV-Type field) indicates whether the TLV is mandatory >> for the receiver to understand/process. This effectively allocates >> TLV-Type values 0 to 127 for non-critical options and Type values >> 128 to 255 for critical options. Figure 7 below illustrates the >> placement of the Critical bit within the Type field. >> >> +-+-+-+-+-+-+-+-+ >> |C| Type | >> +-+-+-+-+-+-+-+-+ >> >> >> Figure 7: Critical Bit Placement Within the TLV Type Field >> >> >> If a receiver receives an encapsulated packet containing a TLV with >> the Critical bit set to 0x1 in the Type field and it does not >> understand how to process the Type, it MUST drop the packet. >> Transit devices MUST NOT drop packets based on the setting of this >> bit. >> >> Length: The length field is 8 bits are reserved, three most >> significant bits (R) are reserved for future use. The length field >> indicates the length of the variable metadata, in 4-octet words. A >> value of 0x0 or higher can be used. A value of 0x0 denotes a >> Variable Context Header TLV without a Variable Metadata field. >> >> Note: as always when I write English a grammar review is necessary! >> >> Hope I did not screw this up too badly. >> >> /Loa >> >> >> >> >>> >>> Hope these help. >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>>> >>>> Working Group, authors, >>>> >>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read >>>> it before now) and have a question on how the TLV concept is understood >>>> in the draft. >>>> >>>> For example in LDP TLV were defined as Type, Length Value, e.g. (from >>>> RFC 5036 section 3.3): >>>> >>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of >>>> the information carried in LDP messages. >>>> >>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to >> specify >>>> a Type and 2 bits to specify behavior when an LSR doesn't recognize >>>> the Type, followed by a 2 octet Length field, followed by a variable >>>> length Value field. >>>> >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |U|F| Type | Length | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> | Value | >>>> ~ ~ >>>> | | >>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated >>>> and I'm struggling a bit to understand if the "name" TLV should be >> used. >>>> >>>> From draft-ietf-sfc-nsh-04 >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> | TLV Class |C| Type |R|R|R| Len >> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> | Variable Metadata >> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> >>>> >>>> >>>> Figure 6: Variable Context Headers >>>> >>>> The draft is not entirely clear in this respect, but I think this is >> what you call a TLV. >>>> >>>> Should I understand this way? >>>> >>>> Type = TLV Class + C + Type (24 bits) >>>> Length = len (5 bits) >>>> Value = Variable Metadata >>>> >>>> A convention we used in MPLS when we have variable length fields is >>>> to use a ~ instead of the |, like this:. >>>> >>>> 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 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> | TLV Class |C| Type |R|R|R| Len >> | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> ~ Variable Metadata >> ~ >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> >>>> I suggest that this is a good practice that could be adopted here also. >>>> >>>> Two more questions: >>>> >>>> If the metadata does not align exactly with the 32 bit/4 byte >> structure, >>>> what is the rules for padding? >>>> >>>> A last, but a bit different question, do you need indicators like the U >>>> and F flags in an to indicate what should happen if the node does not >>>> recognize the (TLV Class, C, Type)-field? >>>> >>>> /Loa >>>> >>>> >>>> PS >>>> >>>> I will also have a few more editorial comments that will be sent to >>>> the authors within a day or two. >>>> >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> >>>> _______________________________________________ >>>> 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 Wed Apr 20 08:26: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 068C312F065; Wed, 20 Apr 2016 08:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 3VHgGaNISunT; Wed, 20 Apr 2016 08:26:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8BB12DB8D; Wed, 20 Apr 2016 08:17:59 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 350D426457E; Wed, 20 Apr 2016 17:17:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0F48B23806E; Wed, 20 Apr 2016 17:17:58 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Wed, 20 Apr 2016 17:17:57 +0200 From: To: Azhar Sayeed Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmxBqPG9+wCOo5UWLeYjmbm2Pnp+S+CdQ Date: Wed, 20 Apr 2016 15:17:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5D0AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <57133AED.4080005@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5CBB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <77E3E0A5-AA19-4E40-886E-A1739B1BEC45@redhat.com> In-Reply-To: <77E3E0A5-AA19-4E40-886E-A1739B1BEC45@redhat.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.20.142416 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 15:26:14 -0000 Re-, Ok, thank you.=20 256 bytes is by far sufficient for all the metadata types I'm aware of.=20 Cheers, Med > -----Message d'origine----- > De=A0: Azhar Sayeed [mailto:asayeed@redhat.com] > Envoy=E9=A0: mercredi 20 avril 2016 16:26 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Question= s > on TLVs in draft-ietf-sfc-nsh >=20 > You have a point - perhaps shortening the length and type will > help..however, here is my rationale for longer length field >=20 > 8 bits I feel is too little for metadata - just about twice as many in a > tweet :-) >=20 > Azhar >=20 > > On Apr 20, 2016, at 1:44 AM, mohamed.boucadair@orange.com wrote: > > > > Hi Azhar, > > > > Thank you for the feedback and the support for the originator ID. > > > > The re-arranging of the fields you propose is indeed another option, bu= t > it does not allow a compact header, e.g., 16 bits for the length is too > much for the cases I'm aware of + it is not optimal if no originator ID i= s > to be supplied for instance. > > > > Having the class, type, flags, and length in the first 32 bits would > lead to a compact header. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Azhar Sayeed [mailto:asayeed@redhat.com] > >> Envoy=E9 : mardi 19 avril 2016 22:17 > >> =C0 : BOUCADAIR Mohamed IMT/OLN > >> Cc : Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - > Questions > >> on TLVs in draft-ietf-sfc-nsh > >> > >> Hi Med, > >> > >> You can still encode this as a TLV by re-arranging the fields with Typ= e > >> first, length and then value - In the value portions you can a > mandatory > >> bytes that encode the flags, class, originator id and then variable > >> metadata > >> > >> So here is an option. > >> > >> Type - 16 bits > >> Length - 16 bits > >> Value: > >> Flags - 4 bits > >> Class - 4 bits > >> Originator Length - 8 bits > >> Originator ID - Variable > >> Data Variable > >> > >> +1 to the idea of originator id. > >> > >> > >> Azhar > >> > >> > >> > >>> On Apr 19, 2016, at 3:48 AM, mohamed.boucadair@orange.com wrote: > >>> > >>> Dear Loa, all, > >>> > >>> Thank you for raising this point about the encoding of the optional > >> context information. > >>> > >>> I agree that the use of TLV term is confusing. What about using > another > >> term, e.g., "Information Elements", "Options", or "Context Element"? > >>> > >>> As an input to this discussion, below a proposal for an encoding that > >> achieves the following goals: > >>> > >>> * Shorten the encoding of the Class field. > >>> * Allow for more type code points. > >>> * Avoids requiring padding for the sake of compact headers. > >>> * Allows to include the ID of the entity that injected the context > >> information (OPTIONAL). > >>> * Inherit rich registries such as IPFIX. > >>> > >>> NOTE: This proposal does not include a dedicated flag bit to indicate > >> whether the context element is mandatory-to-process or optional-to- > process > >> because further discussion/text specification is required: e.g., > >>> * Wouldn't be sufficient to supply that information using the control > >> plane? > >>> * If that information is supplied in both the context element and > >> configured to a SFC-aware function, how conflicts are managed? > >>> * What is the behavior for processing mandatory-to-process elements > >> (particularly, when it is not supported)? > >>> * Is it required to recommend an ordering of supplying the mandatory- > to- > >> process or optional-to-process elements? > >>> * Is it required to preserve the same ordering when forwarding a > packet? > >>> > >>> =3D=3DPROPOSAL=3D=3D=3D=3D > >>> > >>> Base version > >>> 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 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Class | Type | FLAGS | Length | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> // Data (Variable) /= / > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> Version with Originator ID: > >>> 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 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Class | Type | Flags | Length | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> //Originator Len| Originator ID (Variable)(Optional) // > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> // Data (Variable) /= / > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> The description of the fields is as follows: > >>> > >>> Class: In order to foster service innovation, this field > >>> allows to inherit from existing code point registries that are > >>> likely to be useful in a SFC context. The following values ar= e > >>> reserved by this specification: > >>> 0: See IANA section. > >>> 1: IPFIX [IPFIX]. > >>> > >>> Type: Indicates the code point of the context element. If > >>> "Class" field is non-null, the interpretation of this field > MUST > >>> conform to the one defined for that specific class registry. > See > >> IANA section. > >>> > >>> Flags: The Flags field comprises a set of 4 flags: > >>> > >>> +-+-+-+-+ > >>> |S|r|r|r| > >>> +-+-+-+-+ > >>> > >>> where "rrr" are reserved bits for future assignment as > >>> additional flag bits. r bits MUST each be sent as zero and > >> MUST be > >>> ignored on receipt. > >>> > >>> When set, the S-flag indicates that an Originator ID field > >> is > >>> present in the context element. This flag is set by > default > >> to 0, meaning > >>> there is no Originator ID field present in the element. > >>> > >>> Originator ID (Optional): Conveys the identifier of the entity > >> that injected > >>> this context element in the NSH header (e.g., a service > >>> function identifier, a classifier, etc.). This document does > >>> not make any assumption about the structure of the information > >>> carried in this field because this is deployment-specific. > >>> This information is used by SFC-aware elements to enforce > >>> policies such as: process a context information if and only if > >>> it was supplied by a given entity. This information can be > >>> used as a safeguard against misbehaving nodes that inject > >>> illegitimate data in the NSH header. > >>> > >>> This field MUST be included only if S-bit is set. > >>> > >>> Length: Indicates, in octets, the length of the data carried in > >>> the context element. > >>> > >>> Data (Variable): The semantics of this field depend on the > >>> "Class" and "Type" fields. > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> Opinions? > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson > >>>> Envoy=E9 : dimanche 17 avril 2016 09:28 > >>>> =C0 : sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > >>>> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions > on > >>>> TLVs in draft-ietf-sfc-nsh > >>>> > >>>> Working Group, authors, > >>>> > >>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to > read > >>>> it before now) and have a question on how the TLV concept is > understood > >>>> in the draft. > >>>> > >>>> For example in LDP TLV were defined as Type, Length Value, e.g. (fro= m > >>>> RFC 5036 section 3.3): > >>>> > >>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much > of > >>>> the information carried in LDP messages. > >>>> > >>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to > >> specify > >>>> a Type and 2 bits to specify behavior when an LSR doesn't recogniz= e > >>>> the Type, followed by a 2 octet Length field, followed by a > variable > >>>> length Value field. > >>>> > >>>> > >>>> 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 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> |U|F| Type | Length | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> | Value | > >>>> ~ ~ > >>>> | | > >>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> > >>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more > complicated > >>>> and I'm struggling a bit to understand if the "name" TLV should be > >> used. > >>>> > >>>> From draft-ietf-sfc-nsh-04 > >>>> > >>>> 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 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > >> + > >>>> | TLV Class |C| Type |R|R|R| Len > >> | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > >> + > >>>> | Variable Metadata > >> | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > >> + > >>>> > >>>> > >>>> > >>>> Figure 6: Variable Context Headers > >>>> > >>>> The draft is not entirely clear in this respect, but I think this is > >>>> what you call a TLV. > >>>> > >>>> Should I understand this way? > >>>> > >>>> Type =3D TLV Class + C + Type (24 bits) > >>>> Length =3D len (5 bits) > >>>> Value =3D Variable Metadata > >>>> > >>>> A convention we used in MPLS when we have variable length fields is > >>>> to use a ~ instead of the |, like this:. > >>>> > >>>> 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 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > >> + > >>>> | TLV Class |C| Type |R|R|R| Len > >> | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > >> + > >>>> ~ Variable Metadata > >> ~ > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +- > >> + > >>>> > >>>> I suggest that this is a good practice that could be adopted here > also. > >>>> > >>>> Two more questions: > >>>> > >>>> If the metadata does not align exactly with the 32 bit/4 byte > >> structure, > >>>> what is the rules for padding? > >>>> > >>>> A last, but a bit different question, do you need indicators like th= e > U > >>>> and F flags in an to indicate what should happen if the node does no= t > >>>> recognize the (TLV Class, C, Type)-field? > >>>> > >>>> /Loa > >>>> > >>>> > >>>> PS > >>>> > >>>> I will also have a few more editorial comments that will be sent to > >>>> the authors within a day or two. > >>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> Loa Andersson email: loa@mail01.huawei.com > >>>> Senior MPLS Expert loa@pi.nu > >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Apr 20 09:07:42 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 8E0B312D97E; Wed, 20 Apr 2016 09:07:41 -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 fLsp4J7emt10; Wed, 20 Apr 2016 09:07:34 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4CB12DB32; Wed, 20 Apr 2016 09:07:33 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id e201so56390211wme.0; Wed, 20 Apr 2016 09:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QX2RXF9SzvNn3Kv5dvhVj8wpun0A1OyizPWf3gYMlbk=; b=cPW6gMF51ZW0wibijaNFehwzFXxw2ozaNEZHCjRDN0REgRlF/QrAEi5UhStHOZMHDu SmM2qYCGBVBQfFVjsdSPjDT6PF8MASOoeA47LoNmt++g8eiBXJiX0sMpNjH/REFNDvYO VMtI0h5+lLlX2cVsGDBwpf9euv5OXY5O7dckD0m7vv3pZla7UD+v3WKJjBqiObBUp4q4 GY8jdNwvqqs7TkK0nJT4huT83ZKH6e20ALp2Ng+6aj1dEL1BIa0qogGXlNYZnUIpQ+L7 34RGx5QPF8eOx0CcEv2R6DriifbIQxbdzLGx45uuGx6S9g9QNQueelkpNryW6OyYuFeF W+Ew== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QX2RXF9SzvNn3Kv5dvhVj8wpun0A1OyizPWf3gYMlbk=; b=a7LMsasNZ4uS+fc/jd1liVx9wkUC3pmI6bqmQPcyfIv3yR9EdrELImgYCzPu2MD1wN DJEP5nMdaMNZxImO8T6XHi5PVKd9NBIpkVZoxOwAZTdnW4llpkmgzTA+GAEnZbnOMo+c soTdvn0jvBab+TdhDvrP+2DFiRuXszBM583L7Tg14EubQQy03T/O4bgidquVYSzRBrd+ eVbtVeQ29CXbMOOQQFsTaxsyw9RCPbTcw94eDHR7u0P4EjXW1zKDHoVoXN2f9WuwHYA6 bcVexRu5t3UsM2qEnKy29R0IxxDHu3Oq7catGYmJ6WdAxSwJ1vpCJYmylFCnVWNNRR1X DJBQ== X-Gm-Message-State: AOPr4FWxmS9bSTM0zL74OJw8P+OMuKX2rQtM/hfdvhSeFs48eq/JY9ly9+RO4HzqEtEmfA== X-Received: by 10.194.60.134 with SMTP id h6mr9626020wjr.115.1461168451814; Wed, 20 Apr 2016 09:07:31 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i5sm6329353wjx.15.2016.04.20.09.07.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2016 09:07:30 -0700 (PDT) To: mohamed.boucadair@orange.com, Azhar Sayeed References: <57133AED.4080005@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5CBB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <77E3E0A5-AA19-4E40-886E-A1739B1BEC45@redhat.com> <787AE7BB302AE849A7480A190F8B933008D5D0AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Stewart Bryant Message-ID: <5717A93F.1090800@gmail.com> Date: Wed, 20 Apr 2016 17:07:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5D0AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 20 Apr 2016 16:07:41 -0000 In designing this, it is not matter so much what we can think of today, but whether we have made adequate provision for what others might reasonably wish to do at some point in the near future. So, the question becomes, might you need to use more that 256 bytes in describing why you sent a packet somewhere, and I suspect that you might, for example if you needed to provide the rule set for the selection of the packet. Stewart On 20/04/2016 16:17, mohamed.boucadair@orange.com wrote: > Re-, > > Ok, thank you. > > 256 bytes is by far sufficient for all the metadata types I'm aware of. > > Cheers, > Med > >> -----Message d'origine----- >> De : Azhar Sayeed [mailto:asayeed@redhat.com] >> Envoyé : mercredi 20 avril 2016 16:26 >> À : BOUCADAIR Mohamed IMT/OLN >> Cc : Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions >> on TLVs in draft-ietf-sfc-nsh >> >> You have a point - perhaps shortening the length and type will >> help..however, here is my rationale for longer length field >> >> 8 bits I feel is too little for metadata - just about twice as many in a >> tweet :-) >> >> Azhar >> >>> On Apr 20, 2016, at 1:44 AM, mohamed.boucadair@orange.com wrote: >>> >>> Hi Azhar, >>> >>> Thank you for the feedback and the support for the originator ID. >>> >>> The re-arranging of the fields you propose is indeed another option, but >> it does not allow a compact header, e.g., 16 bits for the length is too >> much for the cases I'm aware of + it is not optimal if no originator ID is >> to be supplied for instance. >>> Having the class, type, flags, and length in the first 32 bits would >> lead to a compact header. >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Azhar Sayeed [mailto:asayeed@redhat.com] >>>> Envoyé : mardi 19 avril 2016 22:17 >>>> À : BOUCADAIR Mohamed IMT/OLN >>>> Cc : Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org >>>> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - >> Questions >>>> on TLVs in draft-ietf-sfc-nsh >>>> >>>> Hi Med, >>>> >>>> You can still encode this as a TLV by re-arranging the fields with Type >>>> first, length and then value - In the value portions you can a >> mandatory >>>> bytes that encode the flags, class, originator id and then variable >>>> metadata >>>> >>>> So here is an option. >>>> >>>> Type - 16 bits >>>> Length - 16 bits >>>> Value: >>>> Flags - 4 bits >>>> Class - 4 bits >>>> Originator Length - 8 bits >>>> Originator ID - Variable >>>> Data Variable >>>> >>>> +1 to the idea of originator id. >>>> >>>> >>>> Azhar >>>> >>>> >>>> >>>>> On Apr 19, 2016, at 3:48 AM, mohamed.boucadair@orange.com wrote: >>>>> >>>>> Dear Loa, all, >>>>> >>>>> Thank you for raising this point about the encoding of the optional >>>> context information. >>>>> I agree that the use of TLV term is confusing. What about using >> another >>>> term, e.g., "Information Elements", "Options", or "Context Element"? >>>>> As an input to this discussion, below a proposal for an encoding that >>>> achieves the following goals: >>>>> * Shorten the encoding of the Class field. >>>>> * Allow for more type code points. >>>>> * Avoids requiring padding for the sake of compact headers. >>>>> * Allows to include the ID of the entity that injected the context >>>> information (OPTIONAL). >>>>> * Inherit rich registries such as IPFIX. >>>>> >>>>> NOTE: This proposal does not include a dedicated flag bit to indicate >>>> whether the context element is mandatory-to-process or optional-to- >> process >>>> because further discussion/text specification is required: e.g., >>>>> * Wouldn't be sufficient to supply that information using the control >>>> plane? >>>>> * If that information is supplied in both the context element and >>>> configured to a SFC-aware function, how conflicts are managed? >>>>> * What is the behavior for processing mandatory-to-process elements >>>> (particularly, when it is not supported)? >>>>> * Is it required to recommend an ordering of supplying the mandatory- >> to- >>>> process or optional-to-process elements? >>>>> * Is it required to preserve the same ordering when forwarding a >> packet? >>>>> ==PROPOSAL==== >>>>> >>>>> Base version >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |Class | Type | FLAGS | Length | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> // Data (Variable) // >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> Version with Originator ID: >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |Class | Type | Flags | Length | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> //Originator Len| Originator ID (Variable)(Optional) // >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> // Data (Variable) // >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> The description of the fields is as follows: >>>>> >>>>> Class: In order to foster service innovation, this field >>>>> allows to inherit from existing code point registries that are >>>>> likely to be useful in a SFC context. The following values are >>>>> reserved by this specification: >>>>> 0: See IANA section. >>>>> 1: IPFIX [IPFIX]. >>>>> >>>>> Type: Indicates the code point of the context element. If >>>>> "Class" field is non-null, the interpretation of this field >> MUST >>>>> conform to the one defined for that specific class registry. >> See >>>> IANA section. >>>>> Flags: The Flags field comprises a set of 4 flags: >>>>> >>>>> +-+-+-+-+ >>>>> |S|r|r|r| >>>>> +-+-+-+-+ >>>>> >>>>> where "rrr" are reserved bits for future assignment as >>>>> additional flag bits. r bits MUST each be sent as zero and >>>> MUST be >>>>> ignored on receipt. >>>>> >>>>> When set, the S-flag indicates that an Originator ID field >>>> is >>>>> present in the context element. This flag is set by >> default >>>> to 0, meaning >>>>> there is no Originator ID field present in the element. >>>>> >>>>> Originator ID (Optional): Conveys the identifier of the entity >>>> that injected >>>>> this context element in the NSH header (e.g., a service >>>>> function identifier, a classifier, etc.). This document does >>>>> not make any assumption about the structure of the information >>>>> carried in this field because this is deployment-specific. >>>>> This information is used by SFC-aware elements to enforce >>>>> policies such as: process a context information if and only if >>>>> it was supplied by a given entity. This information can be >>>>> used as a safeguard against misbehaving nodes that inject >>>>> illegitimate data in the NSH header. >>>>> >>>>> This field MUST be included only if S-bit is set. >>>>> >>>>> Length: Indicates, in octets, the length of the data carried in >>>>> the context element. >>>>> >>>>> Data (Variable): The semantics of this field depend on the >>>>> "Class" and "Type" fields. >>>>> =============== >>>>> >>>>> Opinions? >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson >>>>>> Envoyé : dimanche 17 avril 2016 09:28 >>>>>> À : sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org >>>>>> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions >> on >>>>>> TLVs in draft-ietf-sfc-nsh >>>>>> >>>>>> Working Group, authors, >>>>>> >>>>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to >> read >>>>>> it before now) and have a question on how the TLV concept is >> understood >>>>>> in the draft. >>>>>> >>>>>> For example in LDP TLV were defined as Type, Length Value, e.g. (from >>>>>> RFC 5036 section 3.3): >>>>>> >>>>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much >> of >>>>>> the information carried in LDP messages. >>>>>> >>>>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to >>>> specify >>>>>> a Type and 2 bits to specify behavior when an LSR doesn't recognize >>>>>> the Type, followed by a 2 octet Length field, followed by a >> variable >>>>>> length Value field. >>>>>> >>>>>> >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |U|F| Type | Length | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> | Value | >>>>>> ~ ~ >>>>>> | | >>>>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more >> complicated >>>>>> and I'm struggling a bit to understand if the "name" TLV should be >>>> used. >>>>>> From draft-ietf-sfc-nsh-04 >>>>>> >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +- >>>> + >>>>>> | TLV Class |C| Type |R|R|R| Len >>>> | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +- >>>> + >>>>>> | Variable Metadata >>>> | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +- >>>> + >>>>>> >>>>>> >>>>>> Figure 6: Variable Context Headers >>>>>> >>>>>> The draft is not entirely clear in this respect, but I think this is >>>>>> what you call a TLV. >>>>>> >>>>>> Should I understand this way? >>>>>> >>>>>> Type = TLV Class + C + Type (24 bits) >>>>>> Length = len (5 bits) >>>>>> Value = Variable Metadata >>>>>> >>>>>> A convention we used in MPLS when we have variable length fields is >>>>>> to use a ~ instead of the |, like this:. >>>>>> >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +- >>>> + >>>>>> | TLV Class |C| Type |R|R|R| Len >>>> | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +- >>>> + >>>>>> ~ Variable Metadata >>>> ~ >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +- >>>> + >>>>>> I suggest that this is a good practice that could be adopted here >> also. >>>>>> Two more questions: >>>>>> >>>>>> If the metadata does not align exactly with the 32 bit/4 byte >>>> structure, >>>>>> what is the rules for padding? >>>>>> >>>>>> A last, but a bit different question, do you need indicators like the >> U >>>>>> and F flags in an to indicate what should happen if the node does not >>>>>> recognize the (TLV Class, C, Type)-field? >>>>>> >>>>>> /Loa >>>>>> >>>>>> >>>>>> PS >>>>>> >>>>>> I will also have a few more editorial comments that will be sent to >>>>>> the authors within a day or two. >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>> Senior MPLS Expert loa@pi.nu >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Wed Apr 20 13:08:02 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 F0A8012E503 for ; Wed, 20 Apr 2016 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 SI0GEicnGP_Z for ; Wed, 20 Apr 2016 13:07:59 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id AB3DB12E4EB for ; Wed, 20 Apr 2016 13:07:58 -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.195.1; Wed, 20 Apr 2016 16:07:57 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Wed, 20 Apr 2016 16:07:57 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRmWb0PGjqacyz9EidOrx7rW39tJ+P1pwAgAECt7CAAnQIcA== Date: Wed, 20 Apr 2016 20:07:56 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5C3B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5C3B4@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F310EEwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 20 Apr 2016 20:08:01 -0000 --_000_E8355113905631478EFF04F5AA706E9830F310EEwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Med, That's a question for others. I don't know why so bits are allocated for cl= ass. My sense is this is thought of as a vendor-ID field. Comments anyone? -Dave From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Tuesday, April 19, 2016 2:43 AM To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] TLV class of variable-length metadata should have a rest= ricted range Hi Dave, I'm puzzled here. Why do we need a large range of =AB TLV Class =BB? Would= n't few bits be sufficient (e.g., 3 or 4 bits)? Thank you. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : lundi 18 avril 2016 17:21 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: [sfc] TLV class of variable-length metadata should have a restr= icted range Med, I was discussing the "TLV Class" field, which is 16 bits. But thank you for finding the BCP for writing IANA considerations. -Dave From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, April 18, 2016 7:39 AM To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] TLV class of variable-length metadata should have a rest= ricted range Hi Dave, all, Thank you for raising this point. IANA considerations should be sketched in reference to RFC5226 (see https:/= /tools.ietf.org/html/rfc5226#section-4.1). IMO, it is reasonable to define ranges: =B7 assigned via Standards Action =B7 assigned via Specification Required =B7 reserved for Private Use =B7 reserved for Experimental Use Note that the ranges you are proposing are not aligned with the current TLV= encoding (Type is encoded in 7 bits). Saying that, I still do see value in reusing existing rich registries such = as IPFIX. Doing so allows to use immediately a code point while ensuring in= teroperability. A dedicated field in the encoding of the TLV can be defined= (or adjust TLV Class?) to point to the registry in use. BTW, the IANA section should include more details about "TLV Class". Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Dave Dolson Envoy=E9 : jeudi 14 avril 2016 17:25 =C0 : sfc@ietf.org Objet : [sfc] TLV class of variable-length metadata should have a restricte= d range Regarding the TLV Class of variable-length metadata, https://tools.ietf.org= /html/draft-ietf-sfc-nsh-04#section-3.5.1 It is common for such fields to reserve ranges, allowing for future growth = into unanticipated uses. E.g., off the top of my head, classes 0 to 0x1ff --> types allocated by IETF classes 0x200 to 0x7fff --> allocated by IANA Classes 0x8000 to 0xbfff --> reserved, do not use classes 0xc000 to 0xefff --> locally administered classes 0xf000 to 0xffff --> experimental Or similar? I'm not sure what the best practice for this is. Generally, I'd want to try something experimentally before requesting IANA = allocation for it (experimental), or maybe types are too specific to warrant IANA allocation (locally adminis= tered). Can something like this be added to draft-ietf-sfc-nsh ? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F310EEwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Med,

 

That’s a questio= n for others. I don’t know why so bits are allocated for class. My se= nse is this is thought of as a vendor-ID field.

 

Comments anyone?<= /o:p>

 

-Dave

 

 

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Tuesday, April 19, 2016 2:43 AM
To: Dave Dolson; sfc@ietf.org
Subject: RE: [sfc] TLV class of variable-length metadata should have= a restricted range

 

Hi Dave,

 

I’m puzzled here. Why do we need a large= range of =AB TLV Class =BB?  Wouldn’t few bits be suf= ficient (e.g., 3 or 4 bits)?

 

Thank you.

 

Cheers,

Med

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : lundi 18 avril 2016 17:21
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: [sfc] TLV class of variable-length metadata should = have a restricted range

 

Med,=

I was discussing the &= #8220;TLV Class” field, which is 16 bits.

 

But thank you for find= ing the BCP for writing IANA considerations.

 

 

 

-Dave

 

 

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, April 18, 2016 7:39 AM
To: Dave Dolson; sfc@ietf.org Subject: RE: [sfc] TLV class of variable-length metadata should have= a restricted range

 

Hi Dave, all,

 

Thank you for raising this point.

 

IANA considerations should be sketched in refe= rence to RFC5226 (see https://tools.i= etf.org/html/rfc5226#section-4.1).

 

IMO, it is reasonable to define ranges:

=B7       =   assigned via Standards Action

=B7       =   assigned via Specification Required

=B7       =   reserved for Private Use

=B7       =   reserved for Experimental Use

 

Note that the ranges you are proposing are not= aligned with the current TLV encoding (Type is encoded in 7 bits).

 

Saying that, I still do see value in reusing e= xisting rich registries such as IPFIX. Doing so allows to use immediately a= code point while ensuring interoperability. A dedicated field in the encoding of the TLV can be defined (or adjust TLV C= lass?) to point to the registry in use.

 

BTW, the IANA section should include more deta= ils about “TLV Class”.

 

Cheers,

Med

 

De : sfc [mailto:sfc= -bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : jeudi 14 avril 2016 17:25
=C0 : sfc@ietf.org
Objet : [sfc] TLV class of variable-length metadata should have= a restricted range

 

Regarding the TLV Class of variable-length metadata,= https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1

It is common for such fields to reserve ranges, allo= wing for future growth into unanticipated uses.

 

E.g., off the top of my head,

classes 0 to 0x1ff --> types allocated by IETF

classes 0x200 to 0x7fff --> allocated by IANA

Classes 0x8000 to 0xbfff --> reserved, do not use=

classes 0xc000 to 0xefff --> locally administered=

classes 0xf000 to 0xffff --> experimental

 

Or similar? I’m not sure what the best practic= e for this is.

 

Generally, I’d want to try something experimen= tally before requesting IANA allocation for it (experimental),

or maybe types are too specific to warrant IANA allo= cation (locally administered).

 

Can something like this be added to draft-ietf-sfc-n= sh ?

 

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830F310EEwtlexchp2sandvi_-- From nobody Wed Apr 20 16:49:26 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 7DBAA12E2E9 for ; Wed, 20 Apr 2016 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 NrTq6zOqy7YJ for ; Wed, 20 Apr 2016 16:49:24 -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 5EECE12E14C for ; Wed, 20 Apr 2016 16:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4008; q=dns/txt; s=iport; t=1461196164; x=1462405764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TP878H7+DIrFy6dVMOQZkJzNHlwLEntp+lRuKjTfvCc=; b=T2xNSnTS+37+ru/4QMUdO1Ys97JMXtsbpultHKiR6GNDiJofQ5Aa+yie QyRs7LE01uDl5PJDkFYpOba2u/tHDWI7GCyTXjYgvUt9+IKM5jAi2eohS fSI1QwraN3OkiZziCUzbbBZUIz+gZhGLDIMYNP1HsTOGG8NU7ejYc4LCs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgAMFRhX/49dJa1egmxNgVAGtHiEc?= =?us-ascii?q?gENgXKGDgIcgSk4FAEBAQEBAQFlJ4RCAQEEI1YQAgEIBAoxAwICAjAUEQIEDgW?= =?us-ascii?q?IKq1tkQ8BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdYJWhz8rgisFmA8BjhOPE?= =?us-ascii?q?I8sAR4BAUKDaGyHSX4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,511,1454976000"; d="scan'208,217"; a="96050512" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 23:49:23 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3KNnNq3008227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 23:49:23 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.1104.5; Wed, 20 Apr 2016 18:49: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.1104.009; Wed, 20 Apr 2016 18:49:22 -0500 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRmWezvp42UAHAT0eEsyO9QBxWVJ+QLNUAgAEBmYCAAnM8AIAAPdwA Date: Wed, 20 Apr 2016 23:49:22 +0000 Message-ID: <6E92E595-B0DD-4E35-96B0-795D75BE4C0B@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5C3B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.19.17.236] Content-Type: multipart/alternative; boundary="_000_6E92E595B0DD4E3596B0795D75BE4C0Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 20 Apr 2016 23:49:26 -0000 --_000_6E92E595B0DD4E3596B0795D75BE4C0Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBcHIgMjAsIDIwMTYsIGF0IDQ6MDcgUE0sIERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2 aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PiB3cm90ZToNCg0KTWVkLA0KDQpU aGF04oCZcyBhIHF1ZXN0aW9uIGZvciBvdGhlcnMuIEkgZG9u4oCZdCBrbm93IHdoeSBzbyBiaXRz IGFyZSBhbGxvY2F0ZWQgZm9yIGNsYXNzLiBNeSBzZW5zZSBpcyB0aGlzIGlzIHRob3VnaHQgb2Yg YXMgYSB2ZW5kb3ItSUQgZmllbGQuDQoNClRoYXQncyBjb3JyZWN0OiBpdCBzY29wZXMgdGhlIGRh dGEgdG8gYSBwYXJ0aWN1bGFyICJvd25lciIuICBUaGF0IHByb2JhYmx5IGlzbid0IGNsZWFyIGlu IHRoZSBkcmFmdCBhbmQgd2lsbCBiZSBjbGFyaWZpZWQuICBUaGUgaW50ZW50IGlzIHRvIHJlc2Vy dmUgYSByYW5nZSBmb3IgInN0YW5kYXJkcyIgdXNlLCBhbmQgdGhlbiBhbGxvdyB2ZW5kb3JzIChm b3IgZXhhbXBsZSkgdG8gaGF2ZSB0aGVpciBzY29wZSBhcyB3ZWxsLg0KDQpQYXVsDQo= --_000_6E92E595B0DD4E3596B0795D75BE4C0Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIg MjAsIDIwMTYsIGF0IDQ6MDcgUE0sIERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRv bHNvbkBzYW5kdmluZS5jb20iIGNsYXNzPSIiPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRT ZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPk1l ZCw8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5UaGF04oCZcyBhIHF1ZXN0aW9uIGZvciBvdGhlcnMu IEkgZG9u4oCZdCBrbm93IHdoeSBzbyBiaXRzIGFyZSBhbGxvY2F0ZWQgZm9yIGNsYXNzLiBNeSBz ZW5zZSBpcyB0aGlzIGlzIHRob3VnaHQgb2YgYXMgYSB2ZW5kb3ItSUQgZmllbGQuPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGF0J3MgY29ycmVjdDogaXQgc2NvcGVzIHRoZSBk YXRhIHRvIGEgcGFydGljdWxhciAmcXVvdDtvd25lciZxdW90Oy4gJm5ic3A7VGhhdCBwcm9iYWJs eSBpc24ndCBjbGVhciBpbiB0aGUgZHJhZnQgYW5kIHdpbGwgYmUgY2xhcmlmaWVkLiAmbmJzcDtU aGUgaW50ZW50IGlzIHRvIHJlc2VydmUgYSByYW5nZSBmb3IgJnF1b3Q7c3RhbmRhcmRzJnF1b3Q7 IHVzZSwgYW5kIHRoZW4gYWxsb3cgdmVuZG9ycyAoZm9yIGV4YW1wbGUpIHRvIGhhdmUgdGhlaXIg c2NvcGUgYXMgd2VsbC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlBh dWw8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E92E595B0DD4E3596B0795D75BE4C0Bciscocom_-- From nobody Wed Apr 20 16:50:31 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 06BC512E57F for ; Wed, 20 Apr 2016 16:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 XOp6A3npxRR6 for ; Wed, 20 Apr 2016 16:50:28 -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 4DFB612E30F for ; Wed, 20 Apr 2016 16:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12544; q=dns/txt; s=iport; t=1461196228; x=1462405828; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YXvYBKgJMt9pRKFiioszBXCK6l1Zwc2u+8p68lpjQ1w=; b=WyeP9xahwDJP55gd8TxuRgDObIKpIwIAj31nnexKkZSFfKm35EI7zPTR 3IBD1HxE7B5olJt5au5p9dM86WA6xnPzPYkbk6cw6nGlWW7yye0vY+E0u 4qaaftxGmo92dQEdCTuqYep9wktYdLloXa+E42yMimpdod7dwzXLUkAoC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgDMFBhX/5xdJa1egmxNU30GtHiEc?= =?us-ascii?q?gENgXIXAQqCPIMwAhyBKTgUAQEBAQEBAWUnhEIBAQQBAQEgBEcLEAIBCA4xAwI?= =?us-ascii?q?CAiULFBEBAQQOBYgqDq1fkQ8BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhgXWCV?= =?us-ascii?q?oQPEQFLglMrgisFmA8BhXqIGY8QjywBHgEBQoNobAEBhxE2fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,511,1454976000"; d="scan'208,217";a="263926580" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2016 23:50:27 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3KNoRiG019010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 23:50:27 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 18:50:26 -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.1104.009; Wed, 20 Apr 2016 18:50:26 -0500 From: "Paul Quinn (paulq)" To: Dave Dolson Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AdGWYcf4eX5Az/rjTQOEcq50WzDr6QFJ4l+A Date: Wed, 20 Apr 2016 23:50:26 +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.19.17.236] Content-Type: multipart/alternative; boundary="_000_A9E82077CF9C4BF8BC11A1C23C8B6760ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 20 Apr 2016 23:50:31 -0000 --_000_A9E82077CF9C4BF8BC11A1C23C8B6760ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZXBsaWVkIHRvIGEgbGF0ZXIgZW1haWwgaW4gdGhlIHRocmVhZCwgYnV0IHRoaXMgaXMgZXhh bXBsZSBob3cgd2UgZW52aXNpb25lZCB0aGlzIHdvcmtpbmcsIGFsb25nIHdpdGggc29tZSB2ZW5k b3IgYWxsb2NhdGlvbnMuICAgVGhpcyBzaG91bGQvd2lsbCBiZSBhZGRlZCB0byB0aGUgbmV4dCBy ZXYuDQoNClBhdWwNCg0KDQpPbiBBcHIgMTQsIDIwMTYsIGF0IDExOjI0IEFNLCBEYXZlIERvbHNv biA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4gd3Jv dGU6DQoNClJlZ2FyZGluZyB0aGUgVExWIENsYXNzIG9mIHZhcmlhYmxlLWxlbmd0aCBtZXRhZGF0 YSwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW5zaC0wNCNzZWN0 aW9uLTMuNS4xDQpJdCBpcyBjb21tb24gZm9yIHN1Y2ggZmllbGRzIHRvIHJlc2VydmUgcmFuZ2Vz LCBhbGxvd2luZyBmb3IgZnV0dXJlIGdyb3d0aCBpbnRvIHVuYW50aWNpcGF0ZWQgdXNlcy4NCg0K RS5nLiwgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCwNCmNsYXNzZXMgMCB0byAweDFmZiAtLT4gdHlw ZXMgYWxsb2NhdGVkIGJ5IElFVEYNCmNsYXNzZXMgMHgyMDAgdG8gMHg3ZmZmIC0tPiBhbGxvY2F0 ZWQgYnkgSUFOQQ0KQ2xhc3NlcyAweDgwMDAgdG8gMHhiZmZmIC0tPiByZXNlcnZlZCwgZG8gbm90 IHVzZQ0KY2xhc3NlcyAweGMwMDAgdG8gMHhlZmZmIC0tPiBsb2NhbGx5IGFkbWluaXN0ZXJlZA0K Y2xhc3NlcyAweGYwMDAgdG8gMHhmZmZmIC0tPiBleHBlcmltZW50YWwNCg0KT3Igc2ltaWxhcj8g SeKAmW0gbm90IHN1cmUgd2hhdCB0aGUgYmVzdCBwcmFjdGljZSBmb3IgdGhpcyBpcy4NCg0KR2Vu ZXJhbGx5LCBJ4oCZZCB3YW50IHRvIHRyeSBzb21ldGhpbmcgZXhwZXJpbWVudGFsbHkgYmVmb3Jl IHJlcXVlc3RpbmcgSUFOQSBhbGxvY2F0aW9uIGZvciBpdCAoZXhwZXJpbWVudGFsKSwNCm9yIG1h eWJlIHR5cGVzIGFyZSB0b28gc3BlY2lmaWMgdG8gd2FycmFudCBJQU5BIGFsbG9jYXRpb24gKGxv Y2FsbHkgYWRtaW5pc3RlcmVkKS4NCg0KQ2FuIHNvbWV0aGluZyBsaWtlIHRoaXMgYmUgYWRkZWQg dG8gZHJhZnQtaWV0Zi1zZmMtbnNoID8NCg0KDQpEYXZpZCBEb2xzb24NClNlbmlvciBTb2Z0d2Fy ZSBBcmNoaXRlY3QsIFNhbmR2aW5lIEluYy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCg0K --_000_A9E82077CF9C4BF8BC11A1C23C8B6760ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9CF7FEEEEA63A0449023ACD5DD9E0333@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSByZXBsaWVkIHRvIGEgbGF0ZXIg ZW1haWwgaW4gdGhlIHRocmVhZCwgYnV0IHRoaXMgaXMgZXhhbXBsZSBob3cgd2UgZW52aXNpb25l ZCB0aGlzIHdvcmtpbmcsIGFsb25nIHdpdGggc29tZSB2ZW5kb3IgYWxsb2NhdGlvbnMuICZuYnNw OyBUaGlzIHNob3VsZC93aWxsIGJlIGFkZGVkIHRvIHRoZSBuZXh0IHJldi4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBhdWw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gQXByIDE0LCAyMDE2LCBhdCAxMToyNCBBTSwgRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSIgY2xhc3M9IiI+ZGRvbHNvbkBzYW5kdmluZS5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0i cGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KUmVnYXJkaW5nIHRoZSBUTFYgQ2xhc3Mgb2YgdmFyaWFibGUtbGVu Z3RoIG1ldGFkYXRhLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMt bnNoLTA0I3NlY3Rpb24tMy41LjEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXNmYy1uc2gtMDQjc2VjdGlvbi0zLjUuMTwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJdCBpcyBj b21tb24gZm9yIHN1Y2ggZmllbGRzIHRvIHJlc2VydmUgcmFuZ2VzLCBhbGxvd2luZyBmb3IgZnV0 dXJlIGdyb3d0aCBpbnRvIHVuYW50aWNpcGF0ZWQgdXNlcy48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQpFLmcuLCBvZmYgdGhlIHRvcCBvZiBteSBoZWFkLDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CmNsYXNzZXMgMCB0byAweDFmZiAtLSZndDsgdHlwZXMgYWxsb2NhdGVkIGJ5IElFVEY8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQpjbGFzc2VzIDB4MjAwIHRvIDB4N2ZmZiAtLSZndDsgYWxsb2NhdGVkIGJ5IElBTkE8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQpDbGFzc2VzIDB4ODAwMCB0byAweGJmZmYgLS0mZ3Q7IHJlc2VydmVkLCBk byBub3QgdXNlPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KY2xhc3NlcyAweGMwMDAgdG8gMHhlZmZmIC0tJmd0OyBs b2NhbGx5IGFkbWluaXN0ZXJlZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCmNsYXNzZXMgMHhmMDAwIHRvIDB4ZmZm ZiAtLSZndDsgZXhwZXJpbWVudGFsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K T3Igc2ltaWxhcj8gSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUgYmVzdCBwcmFjdGljZSBmb3IgdGhp cyBpcy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpHZW5lcmFsbHksIEnigJlk IHdhbnQgdG8gdHJ5IHNvbWV0aGluZyBleHBlcmltZW50YWxseSBiZWZvcmUgcmVxdWVzdGluZyBJ QU5BIGFsbG9jYXRpb24gZm9yIGl0IChleHBlcmltZW50YWwpLDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCm9yIG1h eWJlIHR5cGVzIGFyZSB0b28gc3BlY2lmaWMgdG8gd2FycmFudCBJQU5BIGFsbG9jYXRpb24gKGxv Y2FsbHkgYWRtaW5pc3RlcmVkKS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpD YW4gc29tZXRoaW5nIGxpa2UgdGhpcyBiZSBhZGRlZCB0byBkcmFmdC1pZXRmLXNmYy1uc2ggPzxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkRh dmlkIERvbHNvbjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClNlbmlvciBTb2Z0d2FyZSBBcmNoaXRlY3QsIFNhbmR2 aW5lIEluYy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+c2ZjDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnNmY0BpZXRm Lm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A9E82077CF9C4BF8BC11A1C23C8B6760ciscocom_-- From nobody Wed Apr 20 18:34:53 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 AE28412E569 for ; Wed, 20 Apr 2016 18:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 grsSzSRU-6IL for ; Wed, 20 Apr 2016 18:34:49 -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 5265212DEE3 for ; Wed, 20 Apr 2016 18:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9415; q=dns/txt; s=iport; t=1461202489; x=1462412089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vp8qsak89psGrA5f2SVQKlLlVbJAjTseR5juJwcvmhA=; b=AeL7ibEu4ILcwtDPj+BOwvrLBuDbI8HSkcy+YthBr7kM2h98BzaHmis5 hLtNixmr5+WUhk3Y+rlhZbUywpv4Mtl8CaxPg40pzMgoLFnVGZdYhL4lv GUKasBCm3mPEx06nqNukOTP3SgnqWeHbO2LzUpS6YCD8jPYfgo/X4yDty E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AgC0LBhX/4cNJK1egzhTfblwAQ2Bc?= =?us-ascii?q?hcLghgBg08CAgKBRjgUAQEBAQEBAWUnhEEBAQEDAQEBARodLQcLBQcEAgEIEQQ?= =?us-ascii?q?BAQEeCQcnCxQJCAIEDgUUiA4IDr5tAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGI?= =?us-ascii?q?YF1CIFMgQKEPYMtgisFmA8BhXqIGYFmhE2DKYU0hiOJCQEeAQFCggQagUpsiEc?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="262247175" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 01:34:48 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3L1Ym96001001 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 01:34:48 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.1104.5; Wed, 20 Apr 2016 20:34: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.1104.009; Wed, 20 Apr 2016 20:34:47 -0500 From: "Jim Guichard (jguichar)" To: Xuxiaohu Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfXkTLhKguvd0+JCgYhcxHwwp+HiRgAgAAA4gCAAAKWgIAACdAAgAAR84CAAZSqAIAKiQ0P Date: Thu, 21 Apr 2016 01:34:47 +0000 Message-ID: <37D5FD1B-FDB7-4413-BF39-1881938CA954@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53955F@NKGEML515-MBX.china.huawei.com> <570DA48A.9010507@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539582@NKGEML515-MBX.china.huawei.com> <570DBDFF.4070305@joelhalpern.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539F32@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539F32@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Martin Stiemerling , "Joel M. Halpern" , "sfc@ietf.org" , Alia Atlas Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 21 Apr 2016 01:34:51 -0000 [individual contributor hat on ...] >From a purely technical standpoint, the MPLS community has already addresse= d the ECMP issue through RFC6790 Entropy Labels. Jim Sent from my iPhone > On Apr 13, 2016, at 11:42 PM, Xuxiaohu wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, April 13, 2016 11:33 AM >> To: Alia Atlas; Xuxiaohu; Martin Stiemerling; jguichar@cisco.com >> Cc: Joel M. Halpern; Thomas Narten; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>=20 >> With regard to MPLS encapsulation, I am not objecting to considering if = we want >> to rearrange things to make it simpler to carry NSH in MPLS. >>=20 >> Given that the IETF has not ratified a standards track RFC stating that = it is >> required for MPLS carriage to avoid the values, I was objecting the Xu >> overstating the situation. >>=20 >> It is not actually hard to avoid the values. If we feel it is imnportan= t (and I am >> tempted to agree that it is worth considering) we can rearrange some res= erved >> bits so that the first three bits are 0, the next two are the version, a= nd the >> remaining bits are flags. Makes us a little starved for flags, but if w= e agree that >> MPLS has stolen three bits of header, so be it. >=20 > It'd better to be determined by the IETF whether or not MPLS should conti= nuously steal the first nibble of any emerging encapsulation header, IMHO. >=20 > Best regards, > Xiaohu >=20 >> There are other answers. We could, for example, agree that when NSH is >> carried over MPLS, a dummy 0 label is inserted after the bottom of stack= . No >> worse than many things MPLS has done. (I could argue both sides of whic= h >> answer is right, and not persuade myself of either one.) >>=20 >> On the next protocol IDs, the last time we looked we could not find an I= D >> registration that was reasonably small and covered the needed meanings. = I >> note that even the section you point to concludes that there may well be= good >> reasons for using a separate ID space. >>=20 >> Yours, >> Joel >>=20 >>> On 4/12/16 10:29 PM, Alia Atlas wrote: >>> Xiaohu, Joel, and SFC WG group, >>>=20 >>> The first nibble question is quite relevant if it is expected that the >>> NSH header might be directly under an MPLS label stack. This issue >>> arose rather unpleasantly for pseudo-wires a long time ago and the >>> reasoning for it is much better documented, as Carlos pointed out in a >>> different thread, in RFC 4928 Section 3. >>>=20 >>> At the time that PWE3 was working on the control word and whether it >>> was to be mandatory (RFC 4385), it was clear that there were devices >>> that looked at the first nibble of a packet under the MPLS header as a >>> way to determine if the packet was IPv4 or IPv6 and obtain >>> flow-diversity from it. The cost of also verifying the associated >>> checksum if available wasn't deemed acceptable for several >>> implementations. >>> Given that determining as much entropy as possible is still really >>> important and that it is non-trivial to negotiate/indicate the >>> capability for including an Entropy Label in the MPLS stack, I have no >>> reason to believe that this shortcut of looking at the first nibble >>> is no longer used or deployed. Feel free to contact me off-list if yo= u >>> believe this to be the case. >>>=20 >>> It is clear from the NSH base header: >>>=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 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next >> Protocol | >>>=20 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> that this consideration has been completely ignored. In fact, an NSH >>> base header might have any value of 0b0000, 0b0001, 0b0010, 0b0010 and >>> if a version 01 for NSH were ever defined, suddenly the traffic might >>> be subject to startling reordering if an MPLS transport were to be >>> considered. >>>=20 >>> Given a claim of NSH being transport-agnostic and repeated emphasis >>> that MPLS, as well as UDP, is a valid transport for NSH, I do think >>> this is a significant oversight and needs, at a minimum, discussion >>> and explanation, and - quite likely - correction. >>>=20 >>> While I am on the topic of details of the NSH encapsulation, I would >>> request that Section 8 of draft-ietf-rtgwg-dt-encap-01 >>> be read and considered! I am not excited by having many different and >>> unique Next Protocol fields defined. >>> For instance, I note the definition of a nearly identical Next >>> Protocol field in https://datatracker.ietf.org/doc/draft-ietf-nvo3-vxla= n-gpe . >>>=20 >>> While I am, of course, willing to reason to detailed and well-thought >>> out explanations for why each and every new encapsulation needs its >>> very own IANA-defined Next Protocol field, this seems to me to be >>> highly likely to require consolidation so that the same Next Protocol >>> field can be used between the various encapsulations. >>>=20 >>> I will work on giving a through review of NSH as soon as practical. I >>> do realize that there are multiple implementations and while details >>> of how the "Next Protocol" field are documented shouldn't have a >>> significant impact there, the discussion about the first nibble is >>> likely to. >>>=20 >>> Regards, >>> Alia >>>=20 >>>=20 >>> On Tue, Apr 12, 2016 at 9:53 PM, Xuxiaohu >> > wrote: >>>=20 >>> Joel, >>>=20 >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] >>>> Sent: Wednesday, April 13, 2016 9:45 AM >>>> To: Xuxiaohu; Thomas Narten;sfc@ietf.org >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>=20 >>>> Xu, >>>> I do not believe that there is an MPLS specification that requires >> that all >>>> content other than IP must have a first nibble of 0 or 1. >>>=20 >>> When encapsulating NSH over MPLS directly, the first nibble of the >>> NSH must not be 4 or 6. >>>=20 >>>> There are specifications where it is discussed as desirable. >>>>=20 >>>> It is in fact pretty trivial for us to change the format so that the f= irst >> three bits are >>>> 0, but it burns several valuable flag bits. It is an SFC >>> working group decision, >>>=20 >>> That's the reason why I raised the first nibble question. >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> not, as far as I can tell, a violation of the MPLS specification. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>> On 4/12/16 9:41 PM, Xuxiaohu wrote: >>>>> Hi Thomas, >>>>>=20 >>>>> It said in the NSH draft: >>>>>=20 >>>>> "6. Transport Agnostic: NSH is transport independent and is >>> carried >>>>> in an overlay, over existing underlays. If an existing >>> overlay >>>>> topology provides the required service path >>> connectivity, that >>>>> existing overlay may be used." >>>>>=20 >>>>> That means the NSH should be able to be transported over MPLS. >>> However, >>>> according to the current NSH format definition, it's not safe to >>> carry the NSH >>>> over MPLS due to the first nibble issue. Therefore, I believe >>> this issue needs to be >>>> addressed before publication. >>>>>=20 >>>>> Best regards, >>>>> Xiaohu >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org >>> ] On Behalf Of Thomas Narten >>>>>> Sent: Thursday, March 31, 2016 10:48 AM >>>>>> To: sfc@ietf.org >>>>>> Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>=20 >>>>>> Dear WG: >>>>>>=20 >>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>=20 >>>>>> The editors of the NSH document have indicated that they have >>>>>> addressed all known comments and that there are no open issues >>> with >>>>>> the current version of the document. >>>>>>=20 >>>>>> Substantive comments to the list please, editorial comments can go >>>>>> directly to the document editors. >>>>>>=20 >>>>>> We'll also get a brief update from the editors at next week's >>>>>> meeting. If there are any remaining issues with the document, >>> raising >>>>>> them before the meeting would be especially helpful. >>>>>>=20 >>>>>> For the chairs, >>>>>> Thomas >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 20 20:44: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 0B53912D8D4; Wed, 20 Apr 2016 20:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 RFVEJCRzyQ-o; Wed, 20 Apr 2016 20:44:21 -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 73D7812DE52; Wed, 20 Apr 2016 20:44:21 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 B441A1801595; Thu, 21 Apr 2016 05:44:18 +0200 (CEST) To: "Carlos Pignataro (cpignata)" , Azhar Sayeed References: <57133AED.4080005@pi.nu> <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> <592C0220-7CE8-46A6-8181-2AA7EF1CA63D@cisco.com> <4674AF21-386A-4FC4-9714-9D6D003250BE@cisco.com> From: Loa Andersson Message-ID: <57184C83.4070501@pi.nu> Date: Thu, 21 Apr 2016 11:44:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4674AF21-386A-4FC4-9714-9D6D003250BE@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 21 Apr 2016 03:44:24 -0000 Carlos, On 2016-04-20 22:36, Carlos Pignataro (cpignata) wrote: > Hi, Azhar, > > You wrote “the question then is can the current TLV structure in draft-~nsh-04 be re-configured to align with all the other TLV’s structureâ€, and I interpreted that, likely misinterpreted, as “let’s shuffle all bits-on-the-wire to have only a single flat Type, a length, and a value. If instead you meant “we can rename thingsâ€, that’s different. Note I said “information element†to most generically refer to a protocol element which provides information. > Whether you misunderstood/misinterpreted Azhar or not the text I proposed does not "shuffle bits around", it is only the description of the field(s) that changes. If we don't want to do this type of change, we should not use the TLV name. /Loa > Thanks, > > — Carlos. > >> On Apr 20, 2016, at 10:18 AM, Azhar Sayeed wrote: >> >> Carlos, >> >> We agree to disagree … >> >> My argument was fairly simple - if you call this a TLV then I gave you an option to align to a TLV structure without breaking the proposed structure too much…you can call it what you want - call it an informational element, call it a metadata structure or call it some thing else - just don’t call it a TLV…in which case we are squared >> >> The difference between what I am stating and what you are arguing is not much…I am not proposing to take away the class field or to take away the flags - (although I would argue why do you need a class field when you already have a type - if you make type 16 bits then it covers both class and type as proposed originally) >> >> I can see Med’s point that we want the header to be compact in which case you can shrink the length or the type field or both…If you move the flags around then the structure does conform to TLV - If you are not calling it a TLV but calling this a metadata spec then ignore my comments >> >> Azhar >> >> >>> On Apr 19, 2016, at 10:41 PM, Carlos Pignataro (cpignata) wrote: >>> >>> Azhar, >>> >>> -1 :-) >>> >>> Within the IETF-specified protocols, we can certainly find examples of most syntax and structures, from the simple to the too creative ones. Finding a protocol with a specific TLV structure does not mean that that’s the best for every protocol use. >>> >>> You say: "This should also be consistentâ€. >>> >>> However, just to understand your point, what is the technical reason for NSH TLV structs having to match BFD structs and ISIS structs? And why not, say, RSVP’s or ICMP Multipart’s or L2TPv3’s (which, incidentally, use a Class/Type-length-value format)? >>> >>> When you say “ to align with all the other TLV’s structure†— I ask: why? >>> >>> If we think of the goal of flexibility (main goal of Type 2) in the context of most flexible allocation, a hierarchical scheme is a technical answer. Given the rich ecosystem of vendors and open source projects, the proposed structure, in my humble opinion, future proofs the design. >>> >>> — Carlos. >>> >>>> On Apr 18, 2016, at 10:33 AM, Azhar Sayeed wrote: >>>> >>>> Loa, >>>> >>>> +1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs have the same structure - This should also be consistent..the question then is can the current TLV structure in draft-~nsh-04 be re-configured to align with all the other TLV’s structure? >>>> >>>> Azhar >>>> >>>> >>>>> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>>>> >>>>> Working Group, authors, >>>>> >>>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read >>>>> it before now) and have a question on how the TLV concept is understood >>>>> in the draft. >>>>> >>>>> For example in LDP TLV were defined as Type, Length Value, e.g. (from >>>>> RFC 5036 section 3.3): >>>>> >>>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of >>>>> the information carried in LDP messages. >>>>> >>>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify >>>>> a Type and 2 bits to specify behavior when an LSR doesn't recognize >>>>> the Type, followed by a 2 octet Length field, followed by a variable >>>>> length Value field. >>>>> >>>>> >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |U|F| Type | Length | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | >>>>> | Value | >>>>> ~ ~ >>>>> | | >>>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated >>>>> and I'm struggling a bit to understand if the "name" TLV should be used. >>>>> >>>>> From draft-ietf-sfc-nsh-04 >>>>> >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | TLV Class |C| Type |R|R|R| Len | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Variable Metadata | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> >>>>> Figure 6: Variable Context Headers >>>>> >>>>> The draft is not entirely clear in this respect, but I think this is what you call a TLV. >>>>> >>>>> Should I understand this way? >>>>> >>>>> Type = TLV Class + C + Type (24 bits) >>>>> Length = len (5 bits) >>>>> Value = Variable Metadata >>>>> >>>>> A convention we used in MPLS when we have variable length fields is >>>>> to use a ~ instead of the |, like this:. >>>>> >>>>> 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 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | TLV Class |C| Type |R|R|R| Len | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> ~ Variable Metadata ~ >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> I suggest that this is a good practice that could be adopted here also. >>>>> >>>>> Two more questions: >>>>> >>>>> If the metadata does not align exactly with the 32 bit/4 byte structure, >>>>> what is the rules for padding? >>>>> >>>>> A last, but a bit different question, do you need indicators like the U >>>>> and F flags in an to indicate what should happen if the node does not >>>>> recognize the (TLV Class, C, Type)-field? >>>>> >>>>> /Loa >>>>> >>>>> >>>>> PS >>>>> >>>>> I will also have a few more editorial comments that will be sent to >>>>> the authors within a day or two. >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: loa@mail01.huawei.com >>>>> Senior MPLS Expert loa@pi.nu >>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>> >>>>> _______________________________________________ >>>>> 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 Wed Apr 20 20:52:33 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 9376812E029; Wed, 20 Apr 2016 20:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 6z1yqUyDHLC6; Wed, 20 Apr 2016 20:52:29 -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 1296D12DFD2; Wed, 20 Apr 2016 20:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10558; q=dns/txt; s=iport; t=1461210378; x=1462419978; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DmkPPURIvi9yeJl7lBoIE/F7xQXGJgtmlfJsHgNM/G4=; b=UNwagMbb5OXh1rnVzJl/x4a5D1mszFLdiRrtpoK2Q6WNIo/jxe08gJJm O8fmf21S40AA8rRV+EheFEGFrhW/skiqSfY2puU556TZpH4ImtYKer/EI F2hgcCGuKz3Hp3H2D2eNwBIjdEpTrLRGYxmhjMKkVPCQZCXMxgmJDWZ6i M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAgDTTBhX/4YNJK1egzhTfQa5bA6Bc?= =?us-ascii?q?hcLghiDVAKBPDgUAQEBAQEBAWUnhEEBAQEDAQEBARoGRAQDCwUJAgIBBgIYKgI?= =?us-ascii?q?CGwwLJQIEDgUOiBQIDpBCnReRDwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBASGH?= =?us-ascii?q?YF1glaEDxEBgx4rgisFh3aFXYo8AYMngWaJBoFmh3aFNI8sAR4BQ4IEGhWBNWy?= =?us-ascii?q?HEzZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="asc'?scan'208";a="264228635" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 03:46:17 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3L3kGcd007207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 03:46:16 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 23:46:15 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 23:46:15 -0400 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqvPG9+wCOo5UWLeYjmbm2Pnp+QEKeAgAJd1QCAAMK0AIAABPsAgADcBYCAAACegA== Date: Thu, 21 Apr 2016 03:46:15 +0000 Message-ID: <498C9023-F0A4-4EB5-B4D1-1397F02EA1D9@cisco.com> References: <57133AED.4080005@pi.nu> <33D1653F-230B-4877-AB8C-C1BAE6C26BD3@redhat.com> <592C0220-7CE8-46A6-8181-2AA7EF1CA63D@cisco.com> <4674AF21-386A-4FC4-9714-9D6D003250BE@cisco.com> <57184C83.4070501@pi.nu> In-Reply-To: <57184C83.4070501@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.253.120] Content-Type: multipart/signed; boundary="Apple-Mail=_D5ECCECF-8DF9-47B4-8792-94CE61629C4B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , Azhar Sayeed , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 21 Apr 2016 03:52:31 -0000 --Apple-Mail=_D5ECCECF-8DF9-47B4-8792-94CE61629C4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Loa, I very much agree with renaming the fields, and in particular I really = like your naming proposal! Subsequently, the field descriptions need to = be updated as well. Thanks, =E2=80=94 Carlos. > On Apr 20, 2016, at 11:44 PM, Loa Andersson wrote: >=20 > Carlos, >=20 > On 2016-04-20 22:36, Carlos Pignataro (cpignata) wrote: >> Hi, Azhar, >>=20 >> You wrote =E2=80=9Cthe question then is can the current TLV structure = in draft-~nsh-04 be re-configured to align with all the other TLV=E2=80=99= s structure=E2=80=9D, and I interpreted that, likely misinterpreted, as = =E2=80=9Clet=E2=80=99s shuffle all bits-on-the-wire to have only a = single flat Type, a length, and a value. If instead you meant =E2=80=9Cwe = can rename things=E2=80=9D, that=E2=80=99s different. Note I said = =E2=80=9Cinformation element=E2=80=9D to most generically refer to a = protocol element which provides information. >>=20 > Whether you misunderstood/misinterpreted Azhar or not the text I > proposed does not "shuffle bits around", it is only the description > of the field(s) that changes. >=20 > If we don't want to do this type of change, we should not use the > TLV name. >=20 > /Loa >=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> On Apr 20, 2016, at 10:18 AM, Azhar Sayeed = wrote: >>>=20 >>> Carlos, >>>=20 >>> We agree to disagree =E2=80=A6 >>>=20 >>> My argument was fairly simple - if you call this a TLV then I gave = you an option to align to a TLV structure without breaking the proposed = structure too much=E2=80=A6you can call it what you want - call it an = informational element, call it a metadata structure or call it some = thing else - just don=E2=80=99t call it a TLV=E2=80=A6in which case we = are squared >>>=20 >>> The difference between what I am stating and what you are arguing is = not much=E2=80=A6I am not proposing to take away the class field or to = take away the flags - (although I would argue why do you need a class = field when you already have a type - if you make type 16 bits then it = covers both class and type as proposed originally) >>>=20 >>> I can see Med=E2=80=99s point that we want the header to be compact = in which case you can shrink the length or the type field or both=E2=80=A6= If you move the flags around then the structure does conform to TLV - If = you are not calling it a TLV but calling this a metadata spec then = ignore my comments >>>=20 >>> Azhar >>>=20 >>>=20 >>>> On Apr 19, 2016, at 10:41 PM, Carlos Pignataro (cpignata) = wrote: >>>>=20 >>>> Azhar, >>>>=20 >>>> -1 :-) >>>>=20 >>>> Within the IETF-specified protocols, we can certainly find examples = of most syntax and structures, from the simple to the too creative ones. = Finding a protocol with a specific TLV structure does not mean that = that=E2=80=99s the best for every protocol use. >>>>=20 >>>> You say: "This should also be consistent=E2=80=9D. >>>>=20 >>>> However, just to understand your point, what is the technical = reason for NSH TLV structs having to match BFD structs and ISIS structs? = And why not, say, RSVP=E2=80=99s or ICMP Multipart=E2=80=99s or = L2TPv3=E2=80=99s (which, incidentally, use a Class/Type-length-value = format)? >>>>=20 >>>> When you say =E2=80=9C to align with all the other TLV=E2=80=99s = structure=E2=80=9D =E2=80=94 I ask: why? >>>>=20 >>>> If we think of the goal of flexibility (main goal of Type 2) in the = context of most flexible allocation, a hierarchical scheme is a = technical answer. Given the rich ecosystem of vendors and open source = projects, the proposed structure, in my humble opinion, future proofs = the design. >>>>=20 >>>> =E2=80=94 Carlos. >>>>=20 >>>>> On Apr 18, 2016, at 10:33 AM, Azhar Sayeed = wrote: >>>>>=20 >>>>> Loa, >>>>>=20 >>>>> +1 Agree and not just LDP, but BFD TLV or any of the ISIS TLVs = have the same structure - This should also be consistent..the question = then is can the current TLV structure in draft-~nsh-04 be re-configured = to align with all the other TLV=E2=80=99s structure? >>>>>=20 >>>>> Azhar >>>>>=20 >>>>>=20 >>>>>> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >>>>>>=20 >>>>>> Working Group, authors, >>>>>>=20 >>>>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to = read >>>>>> it before now) and have a question on how the TLV concept is = understood >>>>>> in the draft. >>>>>>=20 >>>>>> For example in LDP TLV were defined as Type, Length Value, e.g. = (from >>>>>> RFC 5036 section 3.3): >>>>>>=20 >>>>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much = of >>>>>> the information carried in LDP messages. >>>>>>=20 >>>>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to = specify >>>>>> a Type and 2 bits to specify behavior when an LSR doesn't = recognize >>>>>> the Type, followed by a 2 octet Length field, followed by a = variable >>>>>> length Value field. >>>>>>=20 >>>>>>=20 >>>>>> 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 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |U|F| Type | Length | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> | Value | >>>>>> ~ ~ >>>>>> | | >>>>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more = complicated >>>>>> and I'm struggling a bit to understand if the "name" TLV should = be used. >>>>>>=20 >>>>>> =46rom draft-ietf-sfc-nsh-04 >>>>>>=20 >>>>>> 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 >>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | TLV Class |C| Type |R|R|R| Len = | >>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Variable Metadata = | >>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Figure 6: Variable Context Headers >>>>>>=20 >>>>>> The draft is not entirely clear in this respect, but I think this = is what you call a TLV. >>>>>>=20 >>>>>> Should I understand this way? >>>>>>=20 >>>>>> Type =3D TLV Class + C + Type (24 bits) >>>>>> Length =3D len (5 bits) >>>>>> Value =3D Variable Metadata >>>>>>=20 >>>>>> A convention we used in MPLS when we have variable length fields = is >>>>>> to use a ~ instead of the |, like this:. >>>>>>=20 >>>>>> 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 >>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | TLV Class |C| Type |R|R|R| Len = | >>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> ~ Variable Metadata = ~ >>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>=20 >>>>>> I suggest that this is a good practice that could be adopted here = also. >>>>>>=20 >>>>>> Two more questions: >>>>>>=20 >>>>>> If the metadata does not align exactly with the 32 bit/4 byte = structure, >>>>>> what is the rules for padding? >>>>>>=20 >>>>>> A last, but a bit different question, do you need indicators like = the U >>>>>> and F flags in an to indicate what should happen if the node does = not >>>>>> recognize the (TLV Class, C, Type)-field? >>>>>>=20 >>>>>> /Loa >>>>>>=20 >>>>>>=20 >>>>>> PS >>>>>>=20 >>>>>> I will also have a few more editorial comments that will be sent = to >>>>>> the authors within a day or two. >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>> Senior MPLS Expert loa@pi.nu >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>=20 --Apple-Mail=_D5ECCECF-8DF9-47B4-8792-94CE61629C4B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXGE0HAAoJEIXgpQGOZny92ZkP/0n2Y2XbhbteLFnJUf2Q6HVg ju+e/01Xacw15h42yH6Z5b102RWtObn3ycqE5UfCMXVaB+G0EXGL2eueaA5ekHhR ZYe942TNbrWQJKiZWzz1CR560d0A9p50dL2d8Xq6ZsXHrqN88k7NuJNZ8fD1k5Dp PiDWAJrGmLuvitYpjQDO16lJg2rICvevlWTH2xZeDwaTJ5z5CtneoglomOIoTUAI huKB8Aodb0GUXoRzCnDXQOB+F1RpcJ2lGgp3+l4C5zvN9d1tC2ExIeioO601bOkk JUVDmltMXSVbsBQVTcBq06MDGW+KmsLHPwDDBTWTLnLjv/JCCnPWFLhtPfRlFiey NODB7l771tZbF6YxSgkd6q2Gct9Wt1GRec6P5t7vqHflmV+fufAMapI6WyatQ5Zt P47/MWk3mFo+RmIJbcinqFTgFP3OIfveKJ3N6KLNPuXAfbSiaWEGKoY5XsJKFlTm MEkb7b/IX2nXy5aeNdYBYxVnT5HQEk+nefzy1lGyRHFFIKEJhQXdtbLndMn+Hvq9 w892nygSDcaYltbovc6vsa+38UIzmM/7qtTJpM2WUe2NBg7ya/69H1+/8YSohjJ8 jF2hC+YMda3moZCjAfGCHNZFf5g3xTfJ2RWVQfuwu315BPEVV7oco8kwjttt9ATu /g1U12wY/5RG20HB5f7l =GZk3 -----END PGP SIGNATURE----- --Apple-Mail=_D5ECCECF-8DF9-47B4-8792-94CE61629C4B-- From nobody Wed Apr 20 21:29:06 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 CF4F412D710 for ; Wed, 20 Apr 2016 21:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 ZueaRSQRfvpQ for ; Wed, 20 Apr 2016 21:29:03 -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 571BB12B05B for ; Wed, 20 Apr 2016 21:29:03 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 4FF4A1802ADC; Thu, 21 Apr 2016 06:29:01 +0200 (CEST) To: Dave Dolson , "sfc@ietf.org" References: From: Loa Andersson Message-ID: <571856FE.5010901@pi.nu> Date: Thu, 21 Apr 2016 12:28:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 21 Apr 2016 04:29:05 -0000 Dave, A few comments and questions, though in general I agree with your approach. On 2016-04-14 23:24, Dave Dolson wrote: > Regarding the TLV Class of variable-length metadata, > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1 > > It is common for such fields to reserve ranges, allowing for future > growth into unanticipated uses. > > E.g., off the top of my head, > > classes 0 to 0x1ff --> types allocated by IETF > > classes 0x200 to 0x7fff --> allocated by IANA What is the difference between "alloacated by IETF" and "allocated by IANA"? I think we should say. classes 0 to 0x1ff --> types allocated by IETF consensus classes 0x200 to 0x7fff --> RFC needed > > Classes 0x8000 to 0xbfff --> reserved, do not use I don't understand why we need the reerved block of 16k classes reserved? > > classes 0xc000 to 0xefff --> locally administered what is this?? > > classes 0xf000 to 0xffff --> experimental this block is way to big , 4 or 8 values would be enough, e.g. classes 0xfff6 to 0xfffe --> experimental I'd also do class 0xffff reserved - this is set aside for future use and will require a standard track RFC to change. /Loa > > Or similar? I’m not sure what the best practice for this is. > > Generally, I’d want to try something experimentally before requesting > IANA allocation for it (experimental), > > or maybe types are too specific to warrant IANA allocation (locally > administered). > > Can something like this be added to draft-ietf-sfc-nsh ? > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Apr 20 22:46:33 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 A2A1F12E985 for ; Wed, 20 Apr 2016 22:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qBlIdmta4y3Z for ; Wed, 20 Apr 2016 22:46:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AABA12E97C for ; Wed, 20 Apr 2016 22:46:26 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3D46D324508; Thu, 21 Apr 2016 07:46:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1759835C048; Thu, 21 Apr 2016 07:46:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Thu, 21 Apr 2016 07:46:24 +0200 From: To: "Paul Quinn (paulq)" , Dave Dolson Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRm19IgqXVSRMWkUuCA205d0ScwJ+T6lgw Date: Thu, 21 Apr 2016 05:46:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5D52D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5C3B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6E92E595-B0DD-4E35-96B0-795D75BE4C0B@cisco.com> In-Reply-To: <6E92E595-B0DD-4E35-96B0-795D75BE4C0B@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D5D52DOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.21.52716 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 21 Apr 2016 05:46:31 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D5D52DOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KVGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gVGhpcyBpcyBhbGln bmVkIHdpdGggdGhlIGludGVycHJldGF0aW9uIEkgaGFkIGZvciB0aGlzIGZpZWxkLiBJdCBjYW4g cG9pbnQgdG8gYW5vdGhlciByZWdpc3Rlciwgb3duZXIsIGV0Yy4gYnV0IHN0aWxsIEkgZG9u4oCZ dCB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIHRvIGhhdmUgMl5eMTYgdmFsdWVzIGZvciB0aGlzLg0K DQpJIHdvbuKAmXQgcmVwZWF0IG15IHByb3Bvc2FsIHRvIGluY2x1ZGUgSVBGSVggcmVnaXN0cnkg aGVyZSBhcyBpdCBpcyBhbHJlYWR5IHJhaXNlZCBpbiBvdGhlciB0aHJlYWRzLg0KDQpDaGVlcnMs DQpNZWQNCg0KRGUgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dCBkZSBQYXVsIFF1aW5uIChwYXVscSkNCkVudm95w6kgOiBqZXVkaSAyMSBhdnJpbCAyMDE2IDAx OjQ5DQrDgCA6IERhdmUgRG9sc29uDQpDYyA6IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3Nm Y10gVExWIGNsYXNzIG9mIHZhcmlhYmxlLWxlbmd0aCBtZXRhZGF0YSBzaG91bGQgaGF2ZSBhIHJl c3RyaWN0ZWQgcmFuZ2UNCg0KDQpPbiBBcHIgMjAsIDIwMTYsIGF0IDQ6MDcgUE0sIERhdmUgRG9s c29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+PiB3 cm90ZToNCg0KTWVkLA0KDQpUaGF04oCZcyBhIHF1ZXN0aW9uIGZvciBvdGhlcnMuIEkgZG9u4oCZ dCBrbm93IHdoeSBzbyBiaXRzIGFyZSBhbGxvY2F0ZWQgZm9yIGNsYXNzLiBNeSBzZW5zZSBpcyB0 aGlzIGlzIHRob3VnaHQgb2YgYXMgYSB2ZW5kb3ItSUQgZmllbGQuDQoNClRoYXQncyBjb3JyZWN0 OiBpdCBzY29wZXMgdGhlIGRhdGEgdG8gYSBwYXJ0aWN1bGFyICJvd25lciIuICBUaGF0IHByb2Jh Ymx5IGlzbid0IGNsZWFyIGluIHRoZSBkcmFmdCBhbmQgd2lsbCBiZSBjbGFyaWZpZWQuICBUaGUg aW50ZW50IGlzIHRvIHJlc2VydmUgYSByYW5nZSBmb3IgInN0YW5kYXJkcyIgdXNlLCBhbmQgdGhl biBhbGxvdyB2ZW5kb3JzIChmb3IgZXhhbXBsZSkgdG8gaGF2ZSB0aGVpciBzY29wZSBhcyB3ZWxs Lg0KDQpQYXVsDQo= --_000_787AE7BB302AE849A7480A190F8B933008D5D52DOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgUGF1bCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZv ciB0aGUgY2xhcmlmaWNhdGlvbi4gVGhpcyBpcyBhbGlnbmVkIHdpdGggdGhlIGludGVycHJldGF0 aW9uIEkgaGFkIGZvciB0aGlzIGZpZWxkLiBJdCBjYW4gcG9pbnQgdG8gYW5vdGhlciByZWdpc3Rl ciwgb3duZXIsIGV0Yy4gYnV0IHN0aWxsIEkgZG9u4oCZdA0KIHVuZGVyc3RhbmQgd2h5IHdlIG5l ZWQgdG8gaGF2ZSAyXl4xNiB2YWx1ZXMgZm9yIHRoaXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHdvbuKAmXQgcmVwZWF0IG15IHByb3Bvc2Fs IHRvIGluY2x1ZGUgSVBGSVggcmVnaXN0cnkgaGVyZSBhcyBpdCBpcyBhbHJlYWR5IHJhaXNlZCBp biBvdGhlciB0aHJlYWRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IFBhdWwgUXVpbm4gKHBhdWxxKTxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiBqZXVkaSAyMSBhdnJpbCAyMDE2IDAxOjQ5PGJyPg0KPGI+w4AmbmJz cDs6PC9iPiBEYXZlIERvbHNvbjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gc2ZjQGlldGYub3JnPGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gVExWIGNsYXNzIG9mIHZhcmlhYmxlLWxl bmd0aCBtZXRhZGF0YSBzaG91bGQgaGF2ZSBhIHJlc3RyaWN0ZWQgcmFuZ2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMjAsIDIwMTYsIGF0 IDQ6MDcgUE0sIERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmlu ZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TWVkLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYXTigJlzIGEgcXVlc3Rpb24gZm9yIG90aGVycy4gSSBkb27igJl0IGtu b3cgd2h5IHNvIGJpdHMgYXJlIGFsbG9jYXRlZCBmb3IgY2xhc3MuIE15IHNlbnNlIGlzIHRoaXMg aXMgdGhvdWdodCBvZiBhcyBhIHZlbmRvci1JRCBmaWVsZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIGNvcnJlY3Q6 IGl0IHNjb3BlcyB0aGUgZGF0YSB0byBhIHBhcnRpY3VsYXIgJnF1b3Q7b3duZXImcXVvdDsuICZu YnNwO1RoYXQgcHJvYmFibHkgaXNuJ3QgY2xlYXIgaW4gdGhlIGRyYWZ0IGFuZCB3aWxsIGJlIGNs YXJpZmllZC4gJm5ic3A7VGhlIGludGVudCBpcyB0byByZXNlcnZlIGEgcmFuZ2UgZm9yICZxdW90 O3N0YW5kYXJkcyZxdW90OyB1c2UsIGFuZCB0aGVuIGFsbG93IHZlbmRvcnMgKGZvciBleGFtcGxl KSB0byBoYXZlIHRoZWlyIHNjb3BlIGFzDQogd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF1bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B933008D5D52DOPEXCLILMA3corp_-- From nobody Thu Apr 21 00:11: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 6987E12D9B4; Thu, 21 Apr 2016 00:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 gbZsFtPyAtHz; Thu, 21 Apr 2016 00:11:29 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDD212D9D7; Thu, 21 Apr 2016 00:11:29 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 3D5BB1804BB; Thu, 21 Apr 2016 09:11:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 0B6861C0067; Thu, 21 Apr 2016 09:11:28 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Thu, 21 Apr 2016 09:11:27 +0200 From: To: Stewart Bryant , Azhar Sayeed Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmx67PG9+wCOo5UWLeYjmbm2Pnp+T7HaQ Date: Thu, 21 Apr 2016 07:11:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5D58E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <57133AED.4080005@pi.nu> <787AE7BB302AE849A7480A190F8B933008D5C41E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5CBB0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <77E3E0A5-AA19-4E40-886E-A1739B1BEC45@redhat.com> <787AE7BB302AE849A7480A190F8B933008D5D0AE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5717A93F.1090800@gmail.com> In-Reply-To: <5717A93F.1090800@gmail.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: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" , Loa Andersson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 21 Apr 2016 07:11:33 -0000 Hi Stewart, all, This is a very good point. (Please note that the proposal to have 256 bytes is doubling what is curren= tly in the NSH spec: 4*2^5=3D128 bytes) I think the base context information won't exceed the 256 bytes, but the ex= ample you mentioned is an emblematic one. If there is really a need to define large context elements, I may suggest a= n idea that is close to the TCP scaling window: use one of the reserved bit= s to shift the length by a number that the WG will agrees on (scale factor = bit). Your point touched on aspects that lead to discuss the following technical = points:=20 * What is the trade-off between provisioning information directly to SFC-aw= are nodes (e.g., selection rules) vs. convey them in-band?=20 * What is the trade-off between provisioning information directly together = with an ID to SFC-aware nodes (e.g., selection rules) + convey an ID in-ban= d? * What is the trade-off between computing and installing a path (e.g., usin= g PCEP) + convey an ID using NSH? * How context information can be communicated in-band without EXACERBATING = fragmentation, and therefore ensure a COMPACT header? * What is the maximum RECOMMENDED size of a context information that can be= supplied while processing it does not ALTER (by a %, drastically) the perf= ormance of intermediate SFC-aware nodes, does not degrade the overall one-w= ay transfer delay when crossing an SFC-enabled domain, does not exhaust SFF= /SF resources, etc.?=20 * Shouldn't the specification include some sort of RECOMMENDATIONS for spec= ifying a context information vs. associate a meaning with a reserved flag (= see an example below for including a source router)? =3D=3D=3D=3D=3D=3D=3DExample to illustrate the usage of an NSH flag: =3D=3D=3D=3D=3D=3D=3DInclude an RSP 3.1. RSP If the E-flag is set, a "Explicit Source Routed SFP" field MUST be prese= nt in the NSH Header. This field MUST be positioned right after the "Service Index" field. =20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // (Optional) Locators[1..n] (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure xxx The optional "Source Routed SFP" field is structured as a vector of SFF/SF locators (whereas a SFF/SF locator could be an IP address, a MAC address or a FQDN, for example). A SFP Source Route is said to be "strict" when the exact set of all the SFF/SF instances that need to be invoked along the SFP is explicitly and exhaustively mentioned in the field. Each locator in the list is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Len | Locator (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure xx A SFP Source Route is said to be "loose" when only a subset of the SF/SF= F instances, that need to be invoked in the context of a given service function chain, is mentioned in the field. The other SFFs/SFs that need to be invoked will be set to "ANY" in the field, meaning that SFF are free to forward the packet towards the next SF instance that needs to be invoked as per the SFC instructions and according to SFC next hop resolution procedure or a result of load-balancing scheme. "ANY" corresponds to "Locator Len" set to "0" and no "Locator" field. A locator in the list set to 'ANY' is an indication that the selection of the exact SF instance to invoke is left to the SFF or to some kind of SF load-balancing mechanism. The Source Routed SFP field of the NSH header MUST NOT include a list of locators that are all set to "ANY". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Stewart Bryant [mailto:stewart.bryant@gmail.com] > Envoy=E9=A0: mercredi 20 avril 2016 18:07 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Azhar Sayeed > Cc=A0: draft-ietf-sfc-nsh@ietf.org; sfc@ietf.org; Loa Andersson > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Question= s > on TLVs in draft-ietf-sfc-nsh >=20 >=20 > In designing this, it is not matter so much what we can think of today, > but whether we have made adequate provision for what others might > reasonably wish to do at some point in the near future. >=20 > So, the question becomes, might you need to use more that 256 bytes in > describing why you sent a packet somewhere, and I suspect that you > might, for example if you needed to provide the rule set for the > selection of the packet. >=20 > Stewart >=20 >=20 > On 20/04/2016 16:17, mohamed.boucadair@orange.com wrote: > > Re-, > > > > Ok, thank you. > > > > 256 bytes is by far sufficient for all the metadata types I'm aware of. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Azhar Sayeed [mailto:asayeed@redhat.com] > >> Envoy=E9 : mercredi 20 avril 2016 16:26 > >> =C0 : BOUCADAIR Mohamed IMT/OLN > >> Cc : Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - > Questions > >> on TLVs in draft-ietf-sfc-nsh > >> > >> You have a point - perhaps shortening the length and type will > >> help..however, here is my rationale for longer length field > >> > >> 8 bits I feel is too little for metadata - just about twice as many in > a > >> tweet :-) > >> > >> Azhar > >> > >>> On Apr 20, 2016, at 1:44 AM, mohamed.boucadair@orange.com wrote: > >>> > >>> Hi Azhar, > >>> > >>> Thank you for the feedback and the support for the originator ID. > >>> > >>> The re-arranging of the fields you propose is indeed another option, > but > >> it does not allow a compact header, e.g., 16 bits for the length is to= o > >> much for the cases I'm aware of + it is not optimal if no originator I= D > is > >> to be supplied for instance. > >>> Having the class, type, flags, and length in the first 32 bits would > >> lead to a compact header. > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Azhar Sayeed [mailto:asayeed@redhat.com] > >>>> Envoy=E9 : mardi 19 avril 2016 22:17 > >>>> =C0 : BOUCADAIR Mohamed IMT/OLN > >>>> Cc : Loa Andersson; sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > >>>> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - > >> Questions > >>>> on TLVs in draft-ietf-sfc-nsh > >>>> > >>>> Hi Med, > >>>> > >>>> You can still encode this as a TLV by re-arranging the fields with > Type > >>>> first, length and then value - In the value portions you can a > >> mandatory > >>>> bytes that encode the flags, class, originator id and then variable > >>>> metadata > >>>> > >>>> So here is an option. > >>>> > >>>> Type - 16 bits > >>>> Length - 16 bits > >>>> Value: > >>>> Flags - 4 bits > >>>> Class - 4 bits > >>>> Originator Length - 8 bits > >>>> Originator ID - Variable > >>>> Data Variable > >>>> > >>>> +1 to the idea of originator id. > >>>> > >>>> > >>>> Azhar > >>>> > >>>> > >>>> > >>>>> On Apr 19, 2016, at 3:48 AM, mohamed.boucadair@orange.com wrote: > >>>>> > >>>>> Dear Loa, all, > >>>>> > >>>>> Thank you for raising this point about the encoding of the optional > >>>> context information. > >>>>> I agree that the use of TLV term is confusing. What about using > >> another > >>>> term, e.g., "Information Elements", "Options", or "Context Element"? > >>>>> As an input to this discussion, below a proposal for an encoding > that > >>>> achieves the following goals: > >>>>> * Shorten the encoding of the Class field. > >>>>> * Allow for more type code points. > >>>>> * Avoids requiring padding for the sake of compact headers. > >>>>> * Allows to include the ID of the entity that injected the context > >>>> information (OPTIONAL). > >>>>> * Inherit rich registries such as IPFIX. > >>>>> > >>>>> NOTE: This proposal does not include a dedicated flag bit to > indicate > >>>> whether the context element is mandatory-to-process or optional-to- > >> process > >>>> because further discussion/text specification is required: e.g., > >>>>> * Wouldn't be sufficient to supply that information using the > control > >>>> plane? > >>>>> * If that information is supplied in both the context element and > >>>> configured to a SFC-aware function, how conflicts are managed? > >>>>> * What is the behavior for processing mandatory-to-process elements > >>>> (particularly, when it is not supported)? > >>>>> * Is it required to recommend an ordering of supplying the > mandatory- > >> to- > >>>> process or optional-to-process elements? > >>>>> * Is it required to preserve the same ordering when forwarding a > >> packet? > >>>>> =3D=3DPROPOSAL=3D=3D=3D=3D > >>>>> > >>>>> Base version > >>>>> 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 > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> |Class | Type | FLAGS | Length > | > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> // Data (Variable) > // > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> Version with Originator ID: > >>>>> 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 > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> |Class | Type | Flags | Length > | > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> //Originator Len| Originator ID (Variable)(Optional) > // > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> // Data (Variable) > // > >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > >>>>> > >>>>> The description of the fields is as follows: > >>>>> > >>>>> Class: In order to foster service innovation, this field > >>>>> allows to inherit from existing code point registries that > are > >>>>> likely to be useful in a SFC context. The following values > are > >>>>> reserved by this specification: > >>>>> 0: See IANA section. > >>>>> 1: IPFIX [IPFIX]. > >>>>> > >>>>> Type: Indicates the code point of the context element. If > >>>>> "Class" field is non-null, the interpretation of this field > >> MUST > >>>>> conform to the one defined for that specific class registry= . > >> See > >>>> IANA section. > >>>>> Flags: The Flags field comprises a set of 4 flags: > >>>>> > >>>>> +-+-+-+-+ > >>>>> |S|r|r|r| > >>>>> +-+-+-+-+ > >>>>> > >>>>> where "rrr" are reserved bits for future assignment as > >>>>> additional flag bits. r bits MUST each be sent as zero > and > >>>> MUST be > >>>>> ignored on receipt. > >>>>> > >>>>> When set, the S-flag indicates that an Originator ID > field > >>>> is > >>>>> present in the context element. This flag is set by > >> default > >>>> to 0, meaning > >>>>> there is no Originator ID field present in the element. > >>>>> > >>>>> Originator ID (Optional): Conveys the identifier of the entit= y > >>>> that injected > >>>>> this context element in the NSH header (e.g., a service > >>>>> function identifier, a classifier, etc.). This document > does > >>>>> not make any assumption about the structure of the > information > >>>>> carried in this field because this is deployment-specific. > >>>>> This information is used by SFC-aware elements to enforce > >>>>> policies such as: process a context information if and only > if > >>>>> it was supplied by a given entity. This information can be > >>>>> used as a safeguard against misbehaving nodes that inject > >>>>> illegitimate data in the NSH header. > >>>>> > >>>>> This field MUST be included only if S-bit is set. > >>>>> > >>>>> Length: Indicates, in octets, the length of the data carried > in > >>>>> the context element. > >>>>> > >>>>> Data (Variable): The semantics of this field depend on the > >>>>> "Class" and "Type" fields. > >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> Opinions? > >>>>> > >>>>> Cheers, > >>>>> Med > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Loa Andersson > >>>>>> Envoy=E9 : dimanche 17 avril 2016 09:28 > >>>>>> =C0 : sfc@ietf.org; draft-ietf-sfc-nsh@ietf.org > >>>>>> Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - > Questions > >> on > >>>>>> TLVs in draft-ietf-sfc-nsh > >>>>>> > >>>>>> Working Group, authors, > >>>>>> > >>>>>> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to > >> read > >>>>>> it before now) and have a question on how the TLV concept is > >> understood > >>>>>> in the draft. > >>>>>> > >>>>>> For example in LDP TLV were defined as Type, Length Value, e.g. > (from > >>>>>> RFC 5036 section 3.3): > >>>>>> > >>>>>> LDP uses a Type-Length-Value (TLV) encoding scheme to encode > much > >> of > >>>>>> the information carried in LDP messages. > >>>>>> > >>>>>> An LDP TLV is encoded as a 2 octet field that uses 14 bits to > >>>> specify > >>>>>> a Type and 2 bits to specify behavior when an LSR doesn't > recognize > >>>>>> the Type, followed by a 2 octet Length field, followed by a > >> variable > >>>>>> length Value field. > >>>>>> > >>>>>> > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >>>>>> |U|F| Type | Length > | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >>>>>> | > | > >>>>>> | Value > | > >>>>>> ~ > ~ > >>>>>> | > | > >>>>>> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > + > >>>>>> | | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> > >>>>>> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more > >> complicated > >>>>>> and I'm struggling a bit to understand if the "name" TLV should be > >>>> used. > >>>>>> From draft-ietf-sfc-nsh-04 > >>>>>> > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > +- > >> +- > >>>> + > >>>>>> | TLV Class |C| Type |R|R|R| > Len > >>>> | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > +- > >> +- > >>>> + > >>>>>> | Variable Metadata > >>>> | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > +- > >> +- > >>>> + > >>>>>> > >>>>>> > >>>>>> Figure 6: Variable Context Headers > >>>>>> > >>>>>> The draft is not entirely clear in this respect, but I think this > is > >>>>>> what you call a TLV. > >>>>>> > >>>>>> Should I understand this way? > >>>>>> > >>>>>> Type =3D TLV Class + C + Type (24 bits) > >>>>>> Length =3D len (5 bits) > >>>>>> Value =3D Variable Metadata > >>>>>> > >>>>>> A convention we used in MPLS when we have variable length fields i= s > >>>>>> to use a ~ instead of the |, like this:. > >>>>>> > >>>>>> 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 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > +- > >> +- > >>>> + > >>>>>> | TLV Class |C| Type |R|R|R| > Len > >>>> | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > +- > >> +- > >>>> + > >>>>>> ~ Variable Metadata > >>>> ~ > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > +- > >> +- > >>>> + > >>>>>> I suggest that this is a good practice that could be adopted here > >> also. > >>>>>> Two more questions: > >>>>>> > >>>>>> If the metadata does not align exactly with the 32 bit/4 byte > >>>> structure, > >>>>>> what is the rules for padding? > >>>>>> > >>>>>> A last, but a bit different question, do you need indicators like > the > >> U > >>>>>> and F flags in an to indicate what should happen if the node does > not > >>>>>> recognize the (TLV Class, C, Type)-field? > >>>>>> > >>>>>> /Loa > >>>>>> > >>>>>> > >>>>>> PS > >>>>>> > >>>>>> I will also have a few more editorial comments that will be sent t= o > >>>>>> the authors within a day or two. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> > >>>>>> Loa Andersson email: loa@mail01.huawei.com > >>>>>> Senior MPLS Expert loa@pi.nu > >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Apr 21 00:34:06 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 9D01E12B05E; Thu, 21 Apr 2016 00:34:05 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421073405.19602.53635.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 00:34:05 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-control-plane-04.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, 21 Apr 2016 07:34:05 -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 : Service Function Chaining (SFC) Control Plane Components & Requirements Author : Mohamed Boucadair Filename : draft-ietf-sfc-control-plane-04.txt Pages : 27 Date : 2016-04-21 Abstract: This document describes requirements for conveying information between Service Function Chaining (SFC) control elements and SFC functional elements. Also, this document identifies a set of control interfaces to interact with SFC-aware elements to establish, maintain or recover service function chains. This document does not specify protocols nor extensions to existing protocols. This document exclusively focuses on SFC deployments that are under the responsibility of a single administrative entity. Inter-domain considerations are out of scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-control-plane/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-control-plane-04 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 Apr 21 09:09:16 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 5E96812D76D for ; Thu, 21 Apr 2016 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 1TnB6TdSwM9Q for ; Thu, 21 Apr 2016 09:09:13 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id CFB2B12DDEA for ; Thu, 21 Apr 2016 09:09:07 -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.0195.001; Thu, 21 Apr 2016 12:09:06 -0400 From: Dave Dolson To: Loa Andersson , "sfc@ietf.org" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AdGWYcf4eX5Az/rjTQOEcq50WzDr6QFRgpMAAA9UC8A= Date: Thu, 21 Apr 2016 16:09:05 +0000 Message-ID: References: <571856FE.5010901@pi.nu> In-Reply-To: <571856FE.5010901@pi.nu> 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] TLV class of variable-length metadata should have a restricted range 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, 21 Apr 2016 16:09:15 -0000 Please also see Med's BCP-conforming suggestions: https://mailarchive.ietf.org/arch/msg/sfc/1qWGtW1QVxXdG-OHy2T-bhh-C38 As for my "reserved" block, I realize that the "assigned by Standards Actio= n"=20 would suit my intended purpose of being reserved. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Thursday, April 21, 2016 12:29 AM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] TLV class of variable-length metadata should have a rest= ricted range Dave, A few comments and questions, though in general I agree with your approach. On 2016-04-14 23:24, Dave Dolson wrote: > Regarding the TLV Class of variable-length metadata, > https://tools.ietf.org/html/draft-ietf-sfc-nsh-04#section-3.5.1 > > It is common for such fields to reserve ranges, allowing for future > growth into unanticipated uses. > > E.g., off the top of my head, > > classes 0 to 0x1ff --> types allocated by IETF > > classes 0x200 to 0x7fff --> allocated by IANA What is the difference between "alloacated by IETF" and "allocated by IANA"? I think we should say. classes 0 to 0x1ff --> types allocated by IETF consensus classes 0x200 to 0x7fff --> RFC needed > > Classes 0x8000 to 0xbfff --> reserved, do not use I don't understand why we need the reerved block of 16k classes reserved? > > classes 0xc000 to 0xefff --> locally administered what is this?? > > classes 0xf000 to 0xffff --> experimental this block is way to big , 4 or 8 values would be enough, e.g. classes 0xfff6 to 0xfffe --> experimental I'd also do class 0xffff reserved - this is set aside for future use and will require a standard track RFC to change. /Loa > > Or similar? I'm not sure what the best practice for this is. > > Generally, I'd want to try something experimentally before requesting > IANA allocation for it (experimental), > > or maybe types are too specific to warrant IANA allocation (locally > administered). > > Can something like this be added to draft-ietf-sfc-nsh ? > > David Dolson > > Senior Software Architect, Sandvine Inc. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Apr 21 11:30: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 9BECF12E39A for ; Thu, 21 Apr 2016 11:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 appPdemHxBkE for ; Thu, 21 Apr 2016 11:30:53 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3812D12DE9E for ; Thu, 21 Apr 2016 11:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461263450; x=1492799450; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=CKldN9JXLqDrnWaALYY6tjARdOjTakfpX+JF4lAV+hk=; b=Y3/Dax55W/X1z3L65sUP5prtwEWTk08M7dvZORlq4dKx0OPpmskidNps DqpgGTOIFScOkoFYZbIT53JSFbiQZzPU81ZXt/UXxVwSE19kfUKWWIQu+ CI+NRFrLL+OplaRlHG3im+fiFgB8tM7dzf905M5h15XcPqY657752Rjyd o=; X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="214200252" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 21 Apr 2016 18:30:49 +0000 Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 21 Apr 2016 11:30:34 -0700 Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1156.000; Thu, 21 Apr 2016 11:30:34 -0700 From: Sunil Vallamkonda To: "sfc@ietf.org" Thread-Topic: [sfc] A request for Metadata allocation schemes Thread-Index: AdGQDZcInpioWvGORw+Jt9cutzS71wA06k3BABaJqpAABVdClwAR/VYAAAgzRwABZ3a4AAAIWBNgASB/GFA= Date: Thu, 21 Apr 2016 18:30:34 +0000 Message-ID: References: <1460042865963.25707@F5.com>, , <1460091126273.230@F5.com> <1D15709113D6B34BAE5E128F392059CA01268568BE@blr-exch-1.sandvine.com>, <1460738575691.54747@F5.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] A request for Metadata allocation schemes 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, 21 Apr 2016 18:30:55 -0000 DQpWZW5kb3JzIGFscmVhZHkgc2VlbSB0byBiZSB3b3JraW5nIG9uIHByb3ByaWV0YXJ5IG1lY2hh bmlzbXMgdG8gc2hhcmUgdGhlIG1ldGFkYXRhIGluIGltcGxlbWVudGF0aW9ucyB3aGljaCBzZWVt IHRvIGluZmVyIHRoZSBuZWVkIGZvciBhIHN0YW5kYXJkIGZyYW1ld29yayBmb3IgaW50ZXJvcCBh bmQgc2NhbGUuDQpUaGUgZG9jdW1lbnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXZhbGxhbWtvbmRhLXNmYy1tZXRhZGF0YS1tb2RlbC0wMCBwcm9wb3NlcyBtZXRob2QgdXNpbmcg SUFOQSByZWdpc3RyeSBmb3Igc3VwcG9ydGluZyBib3RoIHRoZSBnZW5lcmljIGFsbG9jYXRpb24g c2NoZW1lcyBhcyBtb2JpbGl0eSwgYnJvYWRiYW5kIGFuZCBvdGhlcnMsIGFuZCB0aGUgdmVuZG9y IHNwZWNpZmljIG9uZXMsIGFzIHRoZXkgZXZvbHZlLg0KDQoNClRoYW5rcywNClN1bmlsLg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBEb2xzb24NClNlbnQ6IEZyaWRheSwgQXByaWwgMTUs IDIwMTYgOTo1MCBBTQ0KVG86IFN1bWFuZHJhIE1hamVlIDxTLk1hamVlQEY1LmNvbT4NCkNjOiBz ZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFs bG9jYXRpb24gc2NoZW1lcw0KDQpTdW1hbmRyYSwNCg0KPiBJIGFtIGdlbmVyYWxseSBvcHBvc2Vk IHRvIHN0YW5kYXJkaXppbmcgbWV0YWRhdGEgYWxsb2NhdGlvbiB0aGlzIGVhcmx5Lg0KDQpSZWZl cnJpbmcgYmFjayB0byBteSBvcmlnaW5hbCBlbWFpbCwgSSBtYWRlIHRoZSByZXF1ZXN0IHRvIHRo b3NlIHdobyBhcmUgcHJvcG9zaW5nIG1ldGFkYXRhIHNjaGVtZXMgaW4gZHJhZnRzOyBJIGFtIG5v dCBhc2tpbmcgZm9yIGEgZGlyZWN0aW9uIGluZGljYXRpb24gaW4gdGhlIE5TSCBiYXNlIHByb3Rv Y29sLg0KDQpJbiBlYWNoIG9mIHRoZSBhbGxvY2F0aW9uIHNjaGVtZXMgdGhlcmUgYXJlICJyZXNl cnZlZCIgYml0cyB0aGF0IGNvdWxkIGJlIHVzZWQuDQoNCi1EYXZlDQoNCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVA RjUuY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMTUsIDIwMTYgMTI6NDMgUE0NClRvOiBCb3R0 b3JmZiwgUGF1bDsgTmlsYW5qYW4gU2Fya2FyDQpDYzogRGF2ZSBEb2xzb247IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzZmNdIEEgcmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBz Y2hlbWVzDQoNCkRhdmUsIFBhdWwgYW5kIE5pbGFuamFuLA0KDQpJIGFtIG5vdCBvcHBvc2VkIHRv IGhhdmluZyBhIGRpcmVjdGlvbiBiaXQgaW4gdGhlIG1ldGFkYXRhLCB5ZXMgaXQgbWlnaHQgYmVj b21lIG5lY2Vzc2l0eSBpbiBjZXJ0YWluIHNpdHVhdGlvbi4gSSBhbSBub3Qgc3VyZSBpZiB3ZSBu ZWVkIHRoaXMgc2Vuc2Ugb2YgZGlyZWN0aW9uIGZvciBtYWpvcml0eSBvZiB1c2UgY2FzZXMuDQoN CkkgYW0gZ2VuZXJhbGx5IG9wcG9zZWQgdG8gc3RhbmRhcmRpemluZyBtZXRhZGF0YSBhbGxvY2F0 aW9uIHRoaXMgZWFybHkuDQoNCldoYXQgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBoYXZlIGEgbWV0 YWRhdGEgcmVnaXN0cnkgYW5kIGEgc2NoZW1lIGZvciB0aGF0LiAgDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBCb3R0b3JmZiwgUGF1bCA8cGF1bC5ib3R0 b3JmZkBocGUuY29tPg0KU2VudDogRnJpZGF5LCBBcHJpbCA4LCAyMDE2IDY6MTAgQU0NClRvOiBO aWxhbmphbiBTYXJrYXI7IFN1bWFuZHJhIE1hamVlDQpDYzogRGF2ZSBEb2xzb247IHNmY0BpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFtzZmNdIEEgcmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlv biBzY2hlbWVzDQoNCkhpIE5pbGFuamFuLCBTdW1hbmRyYSwgRGF2ZToNCg0KQWdyZWVkLCB0aGUg Y2FzZSB3aGVyZSB0aGVyZSBhcmUgdHdvIHBvcnRzIChvciB0d28gdk5JQ3MpLCB0aGVuIHdlIGNh biB1c2UgdGhlIFNBIChvciBTSVApIHRvIGRldGVybWluZSB0aGUgZGlyZWN0aW9uLg0KDQpUaG91 Z2ggdGhpcyBkb2VzIG5vdCB3b3JrIGZvciBhIHNpbmdsZSBhcm1lZCBTRiBJIHN1c3BlY3QgdGhl IFNGcyB3aGljaCBuZWVkIHRvIGZvcm0gcmV2ZXJzZSBwYXRocyBhcmUgZHVhbCBhcm1lZCB0b2Rh eS4gSWYgd2Ugc2ltcGx5IHNheSB0aGF0IFNGcyB3aGljaCBuZWVkIHRvIHJldmVyc2UgZGlyZWN0 aW9ucyBhbHNvIG5lZWQgdG8gYmUgZHVhbCBhcm1lZCwgdGhlbiB0aGlzIGNvdWxkIGJlIGEgdW5p dmVyc2FsIHNvbHV0aW9uLiBUaGUgb3RoZXIgbmljZSB0aGluZyBhYm91dCBpdCBpcyB0aGF0IGl0 IHdvcmtzIGZvciBtdWx0aS1hcm1lZCBicmFuY2hpbmcgYWxzby4gU28gaWYgSSBoYXZlIGFuIFNG IHdpdGggTiBlZ3Jlc3MgcG9ydHMgKG9yIHZOSUNzKSB0aGVuIHRoZSBTRiBjYW4gYnJhbmNoIE4g d2F5cyBzaW1wbHkgYnkgc2VuZGluZyB0byB0aGUgY29ycmVjdCBlZ3Jlc3MgcG9ydC4gVGhpcyBz ZWVtcyBuYXR1cmFsIGZyb20gYW4gU0YgY29kaW5nIHBvaW50IG9mIHZpZXcuDQoNCkNoZWVycywN Cg0KUGF1bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOaWxhbmphbiBTYXJrYXINClNlbnQ6 IEZyaWRheSwgQXByaWwgMDgsIDIwMTYgMjoxNiBBTQ0KVG86IFN1bWFuZHJhIE1hamVlIDxTLk1h amVlQEY1LmNvbT4NCkNjOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+OyBzZmNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9j YXRpb24gc2NoZW1lcw0KDQpXaWxsIGEgU0YgZGV2aWNlIGhhdmUgMiBwb3J0cz8gUHJvYmxlbSB3 YXMgdG8gZmluZCBhbiAgSVAgcGFja2V0IGRpcmVjdGlvbiBpbiBhIHNpbmdsZSBwb3J0IFNGIGRl dmljZS4gSW4gY2FzZSB0aGVyZSBhcmUgMiBwb3J0cywgb25lIGlzIGNvbm5lY3RlZCB0byBzdWJz Y3JpYmVycyBhbmQgYW5vdGhlciBpcyBjb25uZWN0ZWQgdG8gaW50ZXJuZXQsIHRoZW4gdGhlcmUg aXMgbm8gaXNzdWUuDQoNClJlZ2FyZHMsDQpOaWxhbmphbg0KKHNlbnQgZnJvbSBteSBtb2JpbGUg cGhvbmUpDQoNCk9uIDggQXByIDIwMTYgMTA6MjIsIFN1bWFuZHJhIE1hamVlIDxTLk1hamVlQEY1 LmNvbT4gd3JvdGU6DQoNCuKAi0kgdGhpbmsgdGhlIHBhcnQgb2YgdGhlIHByb2JsZW0gbGllcyBp biB0aGUgZGVmaW5pdGlvbiBvZiBVUCBhbmQgRE9XTi4gU28gbGV0cyB0YWtlIHNvbWUgdXNlIGNh c2VzLg0KDQoNCmEpIEluIGNhc2Ugb2Ygc2VydmljZSBwcm92aWRlciBtYW55IGZ1bmN0aW9ucyBz aXRzIGF0IHRoZSBib3JkZXIgYmV0d2VlbiBuZXR3b3JrL2ludGVybmV0ICBhbmQgc3Vic2NyaWJl ci91c2VyLiBUeXBpY2FsbHkgdGhlIHR3byBzaWRlcyBvZiB0aGUgYm9yZGVyIGlzIGRlZmluZWQg Ynkgd2F5IG9mIGNvbmZpZ3VyYXRpb24sIHRoaXMgaW50ZXJmYWNlL3R1bm5lbCBwb2ludCB0byBz dWJzY3JpYmVyIHNpZGUgYW5kIHRoYXQgcG9pbnRzIHRvIHRoZSBpbnRlcm5ldC4gQW55dGhpbmcg aW5ncmVzcyBvbiBzdWJzY3JpYmVyIHNpZGUgaXMgRlJPTSBzdWJzY3JpYmVyIGFuZCB2aWNlIHZl cnNhLiBUaGUgVVAgb3IgRE9XTiBpcyBub3Qgc28gdXNlZnVsLg0KDQoNCmIpIENvbnNpZGVyIGEg dHlwaWNhbCBjbGllbnQgc2VydmVyLiAgQXNzdW1pbmcgeW91IG1lYW4gVVA6IGNsaWVudCAtPnNl cnZlci9maW5hbCBkZXN0aW5hdGlvbiBhbmQgRE9XTiB0aGUgb3RoZXIgd2F5LiBBIGZsb3cgYXdh cmUgc2VydmljZSB3b3VsZCBoYXZlIHN0YXRlIFNJUC0+RElQIGFzIFVQIGFuZCBESVAtPlNJUCBh cyBET1dOLiBPdGhlcnMgbGlrZSByb3V0ZXIgZXRjLiBtYXkgbm90IGNhcmUgYXQgYWxsIGFuZCB0 aGF0IGlzIGZpbmUuDQoNCg0KSW4gY2FzZSBvZiBzZWN1cml0eSBkZXZpY2UgdGhlIGluYm91bmQg YW5kIG91dGJvdW5kIChvciB6b25lcykgYXJlIGRlZmluZWQgYnkgY29uZmlndXJhdGlvbiB0aGF0 IGlzIGxvY2FsIHRvIHRoYXQgZW50aXR5LiBTbyBoYXZpbmcgYSBjbGFzc2lmaWVyIHNheSBJTiBv ciBPVVQgd291bGQgYmUgd3JvbmcgaW4gdGhhdCBjYXNlLg0KDQoNClN1bWFuZHJhDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBz YW5kdmluZS5jb20+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgNywgMjAxNiA3OjExIFBNDQpUbzog U3VtYW5kcmEgTWFqZWU7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IEEgcmVxdWVzdCBmb3Ig TWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNClN1bWFuZHJhIChhbmQgb3RoZXJzIHdobyBo YXZlIHF1ZXN0aW9uZWQgdGhpcyksIFdoYXQgZG8geW91IG1lYW4gYnkgZGV0ZWN0aW5nIGRpcmVj dGlvbiBmcm9tIHRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0Pw0KSeKAmW0gaGF2aW5nIHRyb3VibGUg dW5kZXJzdGFuZGluZyBob3cgb25lIGNvdWxkIHRlbGwgZnJvbSBhbiBhcmJpdHJhcnkgSVAgcGFj a2V0IHdoaWNoIGRpcmVjdGlvbiBpdCBpcyBnb2luZy4NCihVbmxlc3Mga25vd2luZyB0aGUgSVAg YWRkcmVzcyBhbGxvY2F0aW9uIHNjaGVtZSBpbiB0aGUgaW5uZXIgbmV0d29ya+KApj8gIFRoYXQg d291bGQgYmUgYXJkdW91cy4pDQoNCkFuZCBwb3NzaWJseSBpbi1ib3VuZCwgb3V0LWJvdW5kIGFy ZSBiZXR0ZXIgbmFtZXM/DQpJIGRvbuKAmXQgbGlrZSBmb3J3YXJkL3JldmVyc2UgYmVjYXVzZSBJ IGNhbuKAmXQgZ3Vlc3Mgd2hpY2ggaXMgd2hpY2guDQoNCi1EYXZlDQoNCkZyb206IFN1bWFuZHJh IE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDcs IDIwMTYgMTI6MjcgUE0NClRvOiBEYXZlIERvbHNvbjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0KDQrigItEYXZl LA0KDQoNCg0KVGhlIHVzZSBjYXNlIHlvdSBoYXZlIGRlZmluZWQgaXMgc3VwcG9ydGVkIGJ5IG1v c3QgZGV2aWNlcyBieSBiaW5kaW5nIHBvbGljaWVzIGV4cGxpY2l0bHkgb24sDQoNCiAgIGEpIGlu dGVyZmFjZSBvciBlcXVpdmFsZW50DQoNCiAgIGIpIGZsb3cgZGlyZWN0aW9uLiBNb3N0IGZsb3cg YXdhcmUgZGV2aWNlcyBoYXMgdG8gZGV0ZWN0IHRvIGFuZCBmcm9tIGNvcnJlY3RseSB0byBkbyBs b3Qgb2YgdGhuZ3MgY29ycmVjdGx5Lg0KDQoNCg0KU28gdGhlIHF1ZXN0aW9uIGlzIHdoYXQgZG8g d2UgZ2V0IGJ5IGFkZGluZyB0aGlzIGJpdD8gSSBhbSBvcHBvc2VkIHRvIHRoZSB0ZXJtIFVQIGFu ZCBET1dOIChmcm9tIHNob3cgcG9pbnQgb2Ygdmlldz8pLCByYXRoZXIgZm9yd2FyZCBhbmQgcmV2 ZXJzZSAoZXZlbiB0aGF0IGlzIGNvbmZ1c2luZykuDQoNCg0KDQpTdW1hbmRyYQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGF2ZSBEb2xzb24g PGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbT4+DQpTZW50 OiBXZWRuZXNkYXksIEFwcmlsIDYsIDIwMTYgNzoxMyBBTQ0KVG86IHNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogW3NmY10gQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBh bGxvY2F0aW9uIHNjaGVtZXMNCg0KVG8gdGhvc2UgYXV0aG9ycyBvZiBtZXRhZGF0YSBhbGxvY2F0 aW9ucywgSSBoYXZlIGEgcmVxdWVzdC4NCkkgYmVsaWV2ZSBtYW55IHR5cGVzIG9mIHNlcnZpY2Ug ZnVuY3Rpb25zIGFyZSBnb2luZyB0byB3YW50IHRvIGRpc3Rpbmd1aXNoIHVwLWxpbmsgdHJhZmZp YyBmcm9tIGRvd24tbGluayB0cmFmZmljLg0KRS5nLiwgYSBzZWN1cml0eSBkZXZpY2UgdHJlYXRz IGluLWJvdW5kIHRvIHRoZSBwcm90ZWN0ZWQgZGV2aWNlIGRpZmZlcmVudGx5IGZyb20gb3V0LWJv dW5kLg0KRS5nLiwgYW4gYWNjb3VudGluZyBzeXN0ZW0gbmVlZHMgdG8ga25vdyB3aGV0aGVyIHRv IGNoYXJnZSB0aGUgc291cmNlIG9yIGRlc3RpbmF0aW9uIG5vZGUuDQoNClNvIG15IHJlcXVlc3Qg aXMgdG8gYWxsb2NhdGUgYSBiaXQgZm9yIHVwLWxpbmsvZG93bi1saW5rIGRpc2NyaW1pbmF0aW9u Lg0KSSB0aGluayB0aGUgYWx0ZXJuYXRpdmUgaXMgdG8gY29uZmlndXJlIGVhY2ggU0YgYWJvdXQg ZWFjaCBwYXRoIHdoZXRoZXIgaXQgaXMgdXAgb3IgZG93biwgb3IgdG8gdXNlIHNvbWV0aGluZyBs aWtlIGFuIGV2ZW4vb2RkIHBhdGggSUQgc2NoZW1lLg0KDQpEb2VzIGFueW9uZSBlbHNlIHNlZSB0 aGlzIGFzIHVzZWZ1bD8NCg0KSSBiZWxpZXZlIGFsbCBvZiB0aGUgYWxsb2NhdGlvbiBkcmFmdHMg aGF2ZSByZXNlcnZlZCBiaXRzLg0KDQoNCkRhdmlkIERvbHNvbg0KU2VuaW9yIFNvZnR3YXJlIEFy Y2hpdGVjdA0KU2FuZHZpbmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Thu Apr 21 11:45: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 3914412DD77 for ; Thu, 21 Apr 2016 11:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 LcFmE4IswrvI for ; Thu, 21 Apr 2016 11:45:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E2012DC64 for ; Thu, 21 Apr 2016 11:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461264301; x=1492800301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yw209tQV22wGG0JWs4ds4WHLyV9dCwib8/esN9sC02o=; b=Bl8RbnoQX/2X9RNAUi66IqvYwJAD+GJ58TIIQMD8C9MJBg6Rpo2eKZJR qU4iQCaHF9NqkW4zlQT4AwquUTAC0MONkP1wmdynbIlXVGnyRdjV2U7fg b0k2xqNNRlY30/RFx8LyxqUxtYQf5ahzAjJoVePLDU2wA72EXraiGCh2n s=; X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208";a="215017457" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 21 Apr 2016 18:45:01 +0000 Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by SEAEXCHMBX08.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 21 Apr 2016 11:44:59 -0700 Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1156.000; Thu, 21 Apr 2016 11:44:59 -0700 From: Sunil Vallamkonda To: "Paul Quinn (paulq)" , Dave Dolson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfiCTJ8b8qeo0249+QoeHMadZ+HQqWAgAADV4CAAFnsgIAAy/AAgAGYJgCAADqXAIAKpR0w Date: Thu, 21 Apr 2016 18:44:59 +0000 Message-ID: <0bc0c81e19f24f16a4bacb0e896d291f@SEAEXCHMBX06.olympus.F5Net.com> References: <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@cisco.com> <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com> In-Reply-To: <0B2F4CF8-B94B-461F-92B2-ACC214D3E907@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "uri.elzur@intel.com" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 21 Apr 2016 18:45:02 -0000 Hi Paul, Does MDType 1 need to be a MUST ? If so, can Context header be customizable per implementation ? Futher re: Sec.3.4, is there way for "Context Headers to carry no metadata = MUST be set to zero", is it possible have a bit in header to indicate to ig= nore Context header for recipient to skip reading them ?=20 Thanks, Sunil. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, April 14, 2016 10:04 AM To: Dave Dolson Cc: uri.elzur@intel.com; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Dave, Sorry, I was traveling yesterday. In principal I don't have any issues wit= h the text since it doesn't impose requirements but rather clarifies a poss= ible behavior. I do wonder about how common this will be: a control of sorts is needed for= semantic meaning -- in type 1 or type 2 cases. Paul > On Apr 14, 2016, at 9:33 AM, Dave Dolson wrote: >=20 > Paul and Uri, can you please comment as to whether you agree or disagree = with this wording? >=20 > I feel that it allows the actual content to be opaque while giving=20 > guidance for service functions that create or replay packets in the chain= . >=20 > From my point of view, this is how such devices will work anyhow. >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Wednesday, April 13, 2016 9:13 AM > To: Paul Quinn (paulq); Ron Parker > Cc: Thomas Narten; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Paul, > Are you unhappy with the metadata constraints I suggested below? > Perhaps qualified by "In the absence of out-of-band configuration..." ? >=20 > I believe that the schemes proposed in these drafts satisfy the constrain= ts: > - draft-sfc-nsh-dc-allocation-4, > - draft-napper-sfc-nsh-broadband-allocation-00 >=20 > (I thought there were more allocation schemes, but I guess they=20 > expired.) >=20 > I'll update it here: >=20 > In the absence of out-of-band configuration to indicate otherwise, > metadata used in NSH headers must meet the condition that > a transport-layer-stateful Service Function can save away > metadata values that it has witnessed. An injected packet can > therefore be assigned a clone of metadata taken from an earlier > packet going in the same direction. For example, a Service Function > can send a TCP packet using metadata cloned from another TCP packet > of the same connection and direction. >=20 > Note that the Service Function need not know the meaning of the > metadata; it just needs to know it is safe to clone in this manner. >=20 >=20 > -Dave >=20 >=20 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Apr 22 07:18: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 6363C12DB55 for ; Fri, 22 Apr 2016 07:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 qgM3i6zTMl65 for ; Fri, 22 Apr 2016 07:18:16 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D6612DB09 for ; Fri, 22 Apr 2016 07:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13668; q=dns/txt; s=iport; t=1461334696; x=1462544296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u6//1YQQ992DdND4cIyAfnLBkO1MVqWLb+nu+0nqHsY=; b=jwQcT/mjx2kustkpMi1UO8seslrKcfKjvtjeRgOVo/bXtK3zK/BBNIqc dqnPn9DkhBtQ4z/1qSKzjIOzks6ziSEUid7GhxewkP7nGew93Au0KExVY suuaZ+fXvu+RK84KPQDEA4PPbLuqZ22YqH8cqTLRt4/EtK3CGhMgxcWKJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AgCAMRpX/40NJK1egmxMgVAGtQ2Ec?= =?us-ascii?q?wENgXOGDgIcgQo4FAEBAQEBAQFlHAuEQgEBBCNWEAIBCD8DAgICMBQRAgQOBR+?= =?us-ascii?q?IC64TkS0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdQiCToR1gkorgisFmA8Bj?= =?us-ascii?q?hOPEI8uAR4BAUKDa2yHeH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208,217";a="263300570" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2016 14:18:15 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3MEIFag007859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 14:18:15 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 09:18:15 -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.1104.009; Fri, 22 Apr 2016 09:18:15 -0500 From: "Paul Quinn (paulq)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRmWezvp42UAHAT0eEsyO9QBxWVJ+QLNUAgAEBmYCAAnM8AIAAPdwAgABjwQCAAiFYAA== Date: Fri, 22 Apr 2016 14:18:15 +0000 Message-ID: <825ECEA4-2762-44C1-84E7-86F332DD8550@cisco.com> References: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5C3B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6E92E595-B0DD-4E35-96B0-795D75BE4C0B@cisco.com> <787AE7BB302AE849A7480A190F8B933008D5D52D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5D52D@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.19.17.236] Content-Type: multipart/alternative; boundary="_000_825ECEA4276244C184E786F332DD8550ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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, 22 Apr 2016 14:18:18 -0000 --_000_825ECEA4276244C184E786F332DD8550ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTWVkLA0KDQpUaGlzICJzaXplIiBvZiB0aGUgZmllbGQgaGVscHMgZW5zdXJlIHRoYXQg bWFueSBvcmdhbml6YXRpb24vcmVnaXN0cmllcy9vd25lcnMgY2FuIHBhcnRpY2lwYXRlLiAgQXQg dGhpcyBwb2ludCwgaXQgc2VlbXMgcHJ1ZGVudCBhbmQgd2UgZG9uJ3QgbmVlZCB0byB0cnkgdG8g b3B0aW1pemUgc2luY2UgdGhpcyBhY2NvbW1vZGF0ZXMgYSBsYXJnZS1yYW5nZSBvZiBvcHRpb25z Lg0KDQpQYXVsDQoNCk9uIEFwciAyMSwgMjAxNiwgYXQgMTo0NiBBTSwgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6 DQoNCkhpIFBhdWwsDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpZmljYXRpb24uIFRoaXMgaXMg YWxpZ25lZCB3aXRoIHRoZSBpbnRlcnByZXRhdGlvbiBJIGhhZCBmb3IgdGhpcyBmaWVsZC4gSXQg Y2FuIHBvaW50IHRvIGFub3RoZXIgcmVnaXN0ZXIsIG93bmVyLCBldGMuIGJ1dCBzdGlsbCBJIGRv buKAmXQgdW5kZXJzdGFuZCB3aHkgd2UgbmVlZCB0byBoYXZlIDJeXjE2IHZhbHVlcyBmb3IgdGhp cy4NCg0KSSB3b27igJl0IHJlcGVhdCBteSBwcm9wb3NhbCB0byBpbmNsdWRlIElQRklYIHJlZ2lz dHJ5IGhlcmUgYXMgaXQgaXMgYWxyZWFkeSByYWlzZWQgaW4gb3RoZXIgdGhyZWFkcy4NCg0KQ2hl ZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgUGF1bCBRdWlubiAocGF1bHEpDQpFbnZvecOpIDogamV1ZGkgMjEgYXZyaWwgMjAx NiAwMTo0OQ0Kw4AgOiBEYXZlIERvbHNvbg0KQ2MgOiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCk9iamV0IDogUmU6IFtzZmNdIFRMViBjbGFzcyBvZiB2YXJpYWJsZS1sZW5ndGgg bWV0YWRhdGEgc2hvdWxkIGhhdmUgYSByZXN0cmljdGVkIHJhbmdlDQoNCg0KT24gQXByIDIwLCAy MDE2LCBhdCA0OjA3IFBNLCBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRv OmRkb2xzb25Ac2FuZHZpbmUuY29tPj4gd3JvdGU6DQoNCk1lZCwNCg0KVGhhdOKAmXMgYSBxdWVz dGlvbiBmb3Igb3RoZXJzLiBJIGRvbuKAmXQga25vdyB3aHkgc28gYml0cyBhcmUgYWxsb2NhdGVk IGZvciBjbGFzcy4gTXkgc2Vuc2UgaXMgdGhpcyBpcyB0aG91Z2h0IG9mIGFzIGEgdmVuZG9yLUlE IGZpZWxkLg0KDQpUaGF0J3MgY29ycmVjdDogaXQgc2NvcGVzIHRoZSBkYXRhIHRvIGEgcGFydGlj dWxhciAib3duZXIiLiAgVGhhdCBwcm9iYWJseSBpc24ndCBjbGVhciBpbiB0aGUgZHJhZnQgYW5k IHdpbGwgYmUgY2xhcmlmaWVkLiAgVGhlIGludGVudCBpcyB0byByZXNlcnZlIGEgcmFuZ2UgZm9y ICJzdGFuZGFyZHMiIHVzZSwgYW5kIHRoZW4gYWxsb3cgdmVuZG9ycyAoZm9yIGV4YW1wbGUpIHRv IGhhdmUgdGhlaXIgc2NvcGUgYXMgd2VsbC4NCg0KUGF1bA0KDQo= --_000_825ECEA4276244C184E786F332DD8550ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <46D94A2E6CF7144E8EC89B396471240A@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8gTWVkLA0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyAmcXVvdDtzaXpl JnF1b3Q7IG9mIHRoZSBmaWVsZCBoZWxwcyBlbnN1cmUgdGhhdCBtYW55IG9yZ2FuaXphdGlvbi9y ZWdpc3RyaWVzL293bmVycyBjYW4gcGFydGljaXBhdGUuICZuYnNwO0F0IHRoaXMgcG9pbnQsIGl0 IHNlZW1zIHBydWRlbnQgYW5kIHdlIGRvbid0IG5lZWQgdG8gdHJ5IHRvIG9wdGltaXplIHNpbmNl IHRoaXMgYWNjb21tb2RhdGVzIGEgbGFyZ2UtcmFuZ2Ugb2Ygb3B0aW9ucy48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBhdWw8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMjEsIDIwMTYsIGF0IDE6NDYgQU0s IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiBjbGFzcz0iIj4N Cm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsiIGNsYXNzPSIiPkhpIFBhdWwsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyIgY2xhc3M9IiI+VGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gVGhpcyBpcyBh bGlnbmVkIHdpdGggdGhlIGludGVycHJldGF0aW9uIEkgaGFkIGZvciB0aGlzIGZpZWxkLiBJdCBj YW4gcG9pbnQgdG8gYW5vdGhlciByZWdpc3Rlciwgb3duZXIsIGV0Yy4gYnV0IHN0aWxsIEkgZG9u 4oCZdCB1bmRlcnN0YW5kIHdoeSB3ZQ0KIG5lZWQgdG8gaGF2ZSAyXl4xNiB2YWx1ZXMgZm9yIHRo aXMuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPkkgd29u4oCZdCBy ZXBlYXQgbXkgcHJvcG9zYWwgdG8gaW5jbHVkZSBJUEZJWCByZWdpc3RyeSBoZXJlIGFzIGl0IGlz IGFscmVhZHkgcmFpc2VkIGluIG90aGVyIHRocmVhZHMuPG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+Q2hlZXJzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPk1lZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsg Ym9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGlu ZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigx ODEsIDE5NiwgMjIzKTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGNtIDBj bTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+c2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPkRlDQogbGEgcGFydCBkZTwvYj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGF1bCBRdWlubiAocGF1 bHEpPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RW52b3nDqSZuYnNwOzo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmpldWRpIDIxIGF2cmlsIDIw MTYgMDE6NDk8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRhdmUgRG9sc29uPGJyIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5zZmNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+T2JqZXQmbmJzcDs6 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTog W3NmY10gVExWIGNsYXNzIG9mIHZhcmlhYmxlLWxlbmd0aCBtZXRhZGF0YSBzaG91bGQgaGF2ZSBh IHJlc3RyaWN0ZWQgcmFuZ2U8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7 IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiBBcHIgMjAsIDIwMTYs IGF0IDQ6MDcgUE0sIERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5k dmluZS5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiIGNsYXNzPSIiPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj5NZWQsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiIGNsYXNzPSIiPlRoYXTigJlzIGEgcXVlc3Rpb24gZm9yIG90aGVycy4gSSBkb27igJl0IGtu b3cgd2h5IHNvIGJpdHMgYXJlIGFsbG9jYXRlZCBmb3IgY2xhc3MuIE15IHNlbnNlIGlzIHRoaXMg aXMgdGhvdWdodCBvZiBhcyBhIHZlbmRvci1JRCBmaWVsZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KVGhhdCdzIGNvcnJlY3Q6IGl0IHNjb3BlcyB0aGUgZGF0YSB0byBhIHBhcnRp Y3VsYXIgJnF1b3Q7b3duZXImcXVvdDsuICZuYnNwO1RoYXQgcHJvYmFibHkgaXNuJ3QgY2xlYXIg aW4gdGhlIGRyYWZ0IGFuZCB3aWxsIGJlIGNsYXJpZmllZC4gJm5ic3A7VGhlIGludGVudCBpcyB0 byByZXNlcnZlIGEgcmFuZ2UgZm9yICZxdW90O3N0YW5kYXJkcyZxdW90OyB1c2UsIGFuZCB0aGVu IGFsbG93IHZlbmRvcnMgKGZvciBleGFtcGxlKSB0byBoYXZlIHRoZWlyIHNjb3BlIGFzIHdlbGwu PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClBhdWw8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_825ECEA4276244C184E786F332DD8550ciscocom_-- From nobody Fri Apr 22 11:59: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 C62A512D554; Fri, 22 Apr 2016 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 SvxO-cnwp847; Fri, 22 Apr 2016 11:59:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6089D12D552; Fri, 22 Apr 2016 11:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4457; q=dns/txt; s=iport; t=1461351593; x=1462561193; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2Lm6Rxl1iOmkdEyXXZdiXIW9FND/8E8h3SjdnQEgoe0=; b=RHSXz0BDpwYv0jCRj/RGn9qDkVx+Fad4vlSiTUI5khtAnLtK5v6AZLIC Q0h8UTIUXvGZgIiSQW4scYqxfJPOYr77KBXB/sK3e7bdaWflo/1n63wqc EepGcsDYdBZMK2q2k5JcdmWCc0cDLJPNxfBcSJMPGf7hC8kD+dZjP5Yfm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgCZcxpX/4oNJK1egziBUAa6AQENg?= =?us-ascii?q?XOCOoNUAoEsOBQBAQEBAQEBZSeEQQEBAQMBHR0tEgULAgEIGB4QMiUCBA4FiCI?= =?us-ascii?q?Iv38BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdYJWhD2DLYIrBY1TijwBjhOBZ?= =?us-ascii?q?od2hTSPLgEeAQFCgjaBNWyHfH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,518,1454976000"; d="scan'208";a="100386648" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2016 18:59:52 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3MIxqDW031801 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 18:59:52 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.1104.5; Fri, 22 Apr 2016 13:59:51 -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.1104.009; Fri, 22 Apr 2016 13:59:51 -0500 From: "Paul Quinn (paulq)" To: Loa Andersson Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh Thread-Index: AQHRmHqq/yKia8M5e0m4Vl0c3PI8M5+WtScA Date: Fri, 22 Apr 2016 18:59:51 +0000 Message-ID: References: <57133AED.4080005@pi.nu> In-Reply-To: <57133AED.4080005@pi.nu> 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.19.17.236] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 22 Apr 2016 18:59:55 -0000 Hello Loa, Loa, You raise an interesting point wrt naming. In fact, this isn't a true TLV,= rather, a structure for variable length metadata. Perhaps, it would be cl= earer to simply label it as such. The structure can remain the same but it= would help readers understand that there are "extra" non T, L or V fields = present. Some further comments below. Thanks Paul > On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >=20 > Working Group, authors, >=20 > I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read > it before now) and have a question on how the TLV concept is understood > in the draft. >=20 > For example in LDP TLV were defined as Type, Length Value, e.g. (from > RFC 5036 section 3.3): >=20 > LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of > the information carried in LDP messages. >=20 > An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify > a Type and 2 bits to specify behavior when an LSR doesn't recognize > the Type, followed by a 2 octet Length field, followed by a variable > length Value field. >=20 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |U|F| Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Value | > ~ ~ > | | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated > and I'm struggling a bit to understand if the "name" TLV should be used. >=20 > From draft-ietf-sfc-nsh-04 >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Variable Metadata | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 >=20 > Figure 6: Variable Context Headers >=20 > The draft is not entirely clear in this respect, but I think this is what= you call a TLV. >=20 > Should I understand this way? >=20 > Type =3D TLV Class + C + Type (24 bits) PQ> In some ways, but as you point out this might be confusing and leads t= o an implied overload. In reality, the class "scopes" the type.=20 > Length =3D len (5 bits) > Value =3D Variable Metadata >=20 > A convention we used in MPLS when we have variable length fields is > to use a ~ instead of the |, like this:. >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TLV Class |C| Type |R|R|R| Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Variable Metadata ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > I suggest that this is a good practice that could be adopted here also. PQ> I'm happy to, assuming everyone else is as well. >=20 > Two more questions: >=20 > If the metadata does not align exactly with the 32 bit/4 byte structure, > what is the rules for padding? PQ> We can provide explicit pad with zero guidance. >=20 > A last, but a bit different question, do you need indicators like the U > and F flags in an to indicate what should happen if the node does not > recognize the (TLV Class, C, Type)-field? PQ> In general, we've implied that if a node doesn't understand the TLV it= simply ignores it. Thanks again! Paul= From nobody Sat Apr 23 02:03: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 4917D12D9F3; Sat, 23 Apr 2016 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 I5Dhi28sIdwl; Sat, 23 Apr 2016 02:03:05 -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 7EFB212D718; Sat, 23 Apr 2016 02:03:05 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 B4AF718013E4; Sat, 23 Apr 2016 11:03:02 +0200 (CEST) To: "Paul Quinn (paulq)" References: <57133AED.4080005@pi.nu> From: Loa Andersson Message-ID: <571B3A33.6010005@pi.nu> Date: Sat, 23 Apr 2016 17:02:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-sfc-nsh@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt - Questions on TLVs in draft-ietf-sfc-nsh 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, 23 Apr 2016 09:03:07 -0000 Paul, Thanks for response, I think we are converging. I have suggestions/questions below in - naming - on dropping packets when the variable length metadata is not recognized. - padding - and (a new one) on section 14.2.3. On 2016-04-23 02:59, Paul Quinn (paulq) wrote: > Hello Loa, > > Loa, > > > You raise an interesting point wrt naming. In fact, this isn't a true TLV, rather, a structure for variable length metadata. Perhaps, it would be clearer to simply label it as such. The structure can remain the same but it would help readers understand that there are "extra" non T, L or V fields present. Some further comments below. > OK - I like naming thing "Variable Length Metadata (VLM)" would work for me, you need to put that into the definition (and maybe terminology) and replace all occurrences of TLV. > Thanks > Paul > >> On Apr 17, 2016, at 3:27 AM, Loa Andersson wrote: >> >> Working Group, authors, >> >> I'm reading draft-ietf-sfc-nsh-04 (sorry to not have been able to read >> it before now) and have a question on how the TLV concept is understood >> in the draft. >> >> For example in LDP TLV were defined as Type, Length Value, e.g. (from >> RFC 5036 section 3.3): >> >> LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of >> the information carried in LDP messages. >> >> An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify >> a Type and 2 bits to specify behavior when an LSR doesn't recognize >> the Type, followed by a 2 octet Length field, followed by a variable >> length Value field. >> >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |U|F| Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | Value | >> ~ ~ >> | | >> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> In draft-ietf-sfc-nsh-04 the TLV structure seems a bit more complicated >> and I'm struggling a bit to understand if the "name" TLV should be used. >> >> From draft-ietf-sfc-nsh-04 >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Variable Metadata | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Figure 6: Variable Context Headers >> >> The draft is not entirely clear in this respect, but I think this is what you call a TLV. >> >> Should I understand this way? >> >> Type = TLV Class + C + Type (24 bits) > > PQ> In some ways, but as you point out this might be confusing and leads to an implied overload. In reality, the class "scopes" the type. > > >> Length = len (5 bits) >> Value = Variable Metadata >> >> A convention we used in MPLS when we have variable length fields is >> to use a ~ instead of the |, like this:. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TLV Class |C| Type |R|R|R| Len | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ~ Variable Metadata ~ >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> I suggest that this is a good practice that could be adopted here also. > > PQ> I'm happy to, assuming everyone else is as well. > > >> >> Two more questions: >> >> If the metadata does not align exactly with the 32 bit/4 byte structure, >> what is the rules for padding? > > PQ> We can provide explicit pad with zero guidance. Thanks, that would be great. Are we sure that the metadata does not start and stop with zero? Let us say that one metadata has the format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and another one the format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0 0 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ post padding would make them come out the same. Similar If one metadata has the format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and another one the format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 0 1 1 0 1 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pre-padding will make them come out the same. > >> >> A last, but a bit different question, do you need indicators like the U >> and F flags in an to indicate what should happen if the node does not >> recognize the (TLV Class, C, Type)-field? > > PQ> In general, we've implied that if a node doesn't understand the TLV it simply ignores it. As far as I can see you only talk about it the type is not recognized, you probably need to make a statement about Class also. In the IANA section there is a Section 14.2.3 that says 14.2.3. TLV Class Registry IANA is requested to set up a registry of "TLV Types". These are 16- bit values. Registry entries are assigned by using the "IETF Review" policy defined in RFC 5226 [RFC5226]. Apart from changing TLV to VLM, it is odd to name this registry "VLM Types it should be "VLM Classes", right? We are talking about a registry for the Classes that goes in the 16 bit field. Then I think you need a registry for the type field (8 bits) also, at least for the types defined by IETF, this registry should indicate whether the C bit is set or not. /Loa /Loa /Loa > > Thanks again! > Paul > From nobody Sun Apr 24 08:36: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 20DBD12B028 for ; Sun, 24 Apr 2016 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 XbWY5iFznsok for ; Sun, 24 Apr 2016 08:36:21 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACEE12B02A for ; Sun, 24 Apr 2016 08:36:21 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 24 Apr 2016 08:36:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,528,1455004800"; d="scan'208";a="939153391" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga001.jf.intel.com with ESMTP; 24 Apr 2016 08:36:20 -0700 Received: from orsmsx112.amr.corp.intel.com (10.22.240.13) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 24 Apr 2016 08:36:20 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX112.amr.corp.intel.com ([169.254.3.229]) with mapi id 14.03.0248.002; Sun, 24 Apr 2016 08:36:20 -0700 From: "Elzur, Uri" To: "mohamed.boucadair@orange.com" , "Thomas Narten" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQCYv/wVVMUagOUO32rRCGp+Er+AwgARg/TCAEFX48A== Date: Sun, 24 Apr 2016 15:36:20 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjM4MWQ1ZmUtNDk0Ni00ODVlLThiN2YtODBkM2Y4NmRlMWZjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilp5bDlIUDVmUzJ5Vk1JOXlnOU9nM2w4S3BBVTZyU2NkWElINHRcL01OY2kwPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Sun, 24 Apr 2016 15:36:23 -0000 Hi Med I see no need to specify the exact behavior as NSH is transport independent= i.e. like NSH interaction with any other Transport eh issue of Fragmentati= on is to be dealt in a way that matches the mechanisms supported by the Tra= nsport used and do not belong in the NSH draft Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, April 14, 2016 12:43 AM To: Thomas Narten ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt R-, In addition to other pending issues raised for this draft, I would like to = raise this additional one about Section 6.=20 =3D=3D 6. Fragmentation Considerations NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. In order the ensure proper forwarding of NSH data, several options for handling fragmentation and re-assembly exist: 1. Jumbo Frames, when supported, enable the transport of NSH and associated transport packets without requiring fragmentation. 2. Path MTU Discovery [RFC1191]"describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path" and can be utilized to ensure the the required packet size is used. 3. [RFC6830] describes two schemes for fragmentation and re-assembly in section 5.4. =3D=3D * The text is weak for a Standard track document that is intended to solve = the problem in https://tools.ietf.org/html/rfc7498#section-2.12. There shou= ld be a clear behavior to be followed by an implementation. Further, I woul= d avoid the use of words such as "can". * The text covers only fragmentation when it is induced by SFC operations, = it does not discuss the treatment of a fragment when received in an SFC dom= ain. IMHO, the draft should also specify the behavior of the Classifier wit= h regards to fragments for the sake of proper SFC operation. Applying class= ification policies may require the full packet, not only a fragment. In par= ticular, dedicated resources should dedicated for handling out of order fra= gments. Of course, it is out of scope of this document to describe how SFs = handle fragments.=20 * If an SFC header is prepended for all fragments, I'm not sure there is an= y particular issue at the SFF level...except if stripping/adding context TL= Vs depends on the full packet (not just fragment). It is warranted to consi= der a little bit this point before declaring there is no issue.=20 * The text states "several options". This may be interpreted as if implemen= ting one of them is sufficient...which is not true. The first two points co= ntribute to minimize the fragmentation risk, but fragmentation may still be= experienced (e.g., other shims are prepended by other nodes for some other= purposes, nested nsh, etc.) * The first two points have nothing to do with reassembly. * The support of jumbo frames by a router/device does not mean that it can = make use of it. Appropriate MTU configuration should be undertaken in a con= sistent manner within an SFC domain. The text should be updated to make it = is about (consistent) MTU configuration.=20 * BTW, shouldn't the text be reworded to recommended to increase the MTU of= **all nodes** of an SFC-enabled domain by at least the length of SFC heade= r + transport header? =20 * Bullet 2, how PMTU discovery is actually used in this context? Do you ass= ume that all SFC-aware nodes will issue such messages towards other SFC-awa= re node, arbitrary destination, else?=20 * Bullet 2, I would drop "describes a technique for dynamically discovering= the maximum transmission unit (MTU) of an arbitrary internet path". =20 * Bullet 2, s/ the the/the. * The reference to the LISP specification raises two concerns and one comme= nt: (1) I don't think it is a good approach that fragments induced by the netwo= rk are passed to their ultimate destinations as such (stateless). IMO, reas= sembly should be done within the SFC domain (responsible for fragmentation)= not passed away. (2) Does the stateful mode require all SFC data plane elements maintain a f= ull list of MTU for the any SFF/SF instance of the SFC domain?=20 =20 The current text suggests that [RFC6830] should be listed as normative refe= rence (not an informative one). I would personally favor removing the refer= ence to LISP (as it is an Experimental RFC).=20 * The security section of the draft may be augmented with informational fra= gmentation-related pointers to: e.g., RFC1858 (Security Considerations for = IP Fragment Filtering), RFC3128 (Protection Against a Variant of the Tiny F= ragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High Data Rates).= =20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de=20 > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 11 avril 2016 13:14 =C0= =A0:=20 > Thomas Narten; sfc@ietf.org Objet=A0: Re: [sfc] WG last call for=20 > draft-ietf-sfc-nsh-04.txt >=20 > Dear Thomas, all, >=20 > As I mentioned during the meeting, there are several issues that are=20 > not covered in the last version of the draft. I already provided=20 > examples of the issues offline as requested by Martin. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 > > Envoy=E9=A0: jeudi 31 mars 2016 04:48 =C0=A0: sfc@ietf.org Objet=A0: [s= fc] WG=20 > > last call for draft-ietf-sfc-nsh-04.txt > > > > Dear WG: > > > > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > The editors of the NSH document have indicated that they have=20 > > addressed all known comments and that there are no open issues with=20 > > the current version of the document. > > > > Substantive comments to the list please, editorial comments can go=20 > > directly to the document editors. > > > > We'll also get a brief update from the editors at next week's=20 > > meeting. If there are any remaining issues with the document,=20 > > raising them before the meeting would be especially helpful. > > > > For the chairs, > > Thomas > > > > _______________________________________________ > > 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 Sun Apr 24 22:31:49 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 2E10112D0F5 for ; Sun, 24 Apr 2016 22:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 EhBum8WIspuY for ; Sun, 24 Apr 2016 22:31:45 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5613C12D0E1 for ; Sun, 24 Apr 2016 22:31:45 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 6E8F7C0156; Mon, 25 Apr 2016 07:31:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 3B7161A0051; Mon, 25 Apr 2016 07:31:43 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0279.002; Mon, 25 Apr 2016 07:31:43 +0200 From: To: "Elzur, Uri" , Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPCTJ8b8qeo0249+QoeHMadZ+Er+AwgARg/TCAEFX48IAA6IrA Date: Mon, 25 Apr 2016 05:31:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.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: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 05:31:48 -0000 Hi Uri, That's another option that needs to be discussed/investigated. I'm afraid t= his is not the rationale adopted in -04 since it includes some text that is= far to be sufficient to ensure interoperable implementations. BTW, saying that nsh does not need to deal with fragmentation because it is= transport-independent is not IMHO a good strategy to adopt here because it= opens the door for interoperable issues, it may lead to sub-optimal implem= entations if the sfc information is present only in one fragments, etc. =20 My comments are related to the current text in the -04. This text needs to = be fixed somehow. Cheers, Med > -----Message d'origine----- > De=A0: Elzur, Uri [mailto:uri.elzur@intel.com] > Envoy=E9=A0: dimanche 24 avril 2016 17:36 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet=A0: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > I see no need to specify the exact behavior as NSH is transport > independent i.e. like NSH interaction with any other Transport eh issue o= f > Fragmentation is to be dealt in a way that matches the mechanisms > supported by the Transport used and do not belong in the NSH draft >=20 > Thx >=20 > Uri ("Oo-Ree") > C: 949-378-7568 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, April 14, 2016 12:43 AM > To: Thomas Narten ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > R-, >=20 > In addition to other pending issues raised for this draft, I would like t= o > raise this additional one about Section 6. >=20 > =3D=3D > 6. Fragmentation Considerations >=20 > NSH and the associated transport header are "added" to the > encapsulated packet/frame. This additional information increases the > size of the packet. In order the ensure proper forwarding of NSH > data, several options for handling fragmentation and re-assembly > exist: >=20 > 1. Jumbo Frames, when supported, enable the transport of NSH and > associated transport packets without requiring fragmentation. >=20 > 2. Path MTU Discovery [RFC1191]"describes a technique for > dynamically discovering the maximum transmission unit (MTU) of an > arbitrary internet path" and can be utilized to ensure the the > required packet size is used. >=20 > 3. [RFC6830] describes two schemes for fragmentation and re-assembly > in section 5.4. > =3D=3D >=20 > * The text is weak for a Standard track document that is intended to solv= e > the problem in https://tools.ietf.org/html/rfc7498#section-2.12. There > should be a clear behavior to be followed by an implementation. Further, = I > would avoid the use of words such as "can". >=20 > * The text covers only fragmentation when it is induced by SFC operations= , > it does not discuss the treatment of a fragment when received in an SFC > domain. IMHO, the draft should also specify the behavior of the Classifie= r > with regards to fragments for the sake of proper SFC operation. Applying > classification policies may require the full packet, not only a fragment. > In particular, dedicated resources should dedicated for handling out of > order fragments. Of course, it is out of scope of this document to > describe how SFs handle fragments. >=20 > * If an SFC header is prepended for all fragments, I'm not sure there is > any particular issue at the SFF level...except if stripping/adding contex= t > TLVs depends on the full packet (not just fragment). It is warranted to > consider a little bit this point before declaring there is no issue. >=20 > * The text states "several options". This may be interpreted as if > implementing one of them is sufficient...which is not true. The first two > points contribute to minimize the fragmentation risk, but fragmentation > may still be experienced (e.g., other shims are prepended by other nodes > for some other purposes, nested nsh, etc.) >=20 > * The first two points have nothing to do with reassembly. >=20 > * The support of jumbo frames by a router/device does not mean that it ca= n > make use of it. Appropriate MTU configuration should be undertaken in a > consistent manner within an SFC domain. The text should be updated to mak= e > it is about (consistent) MTU configuration. >=20 > * BTW, shouldn't the text be reworded to recommended to increase the MTU > of **all nodes** of an SFC-enabled domain by at least the length of SFC > header + transport header? >=20 > * Bullet 2, how PMTU discovery is actually used in this context? Do you > assume that all SFC-aware nodes will issue such messages towards other > SFC-aware node, arbitrary destination, else? >=20 > * Bullet 2, I would drop "describes a technique for dynamically > discovering the maximum transmission unit (MTU) of an arbitrary internet > path". >=20 > * Bullet 2, s/ the the/the. >=20 > * The reference to the LISP specification raises two concerns and one > comment: >=20 > (1) I don't think it is a good approach that fragments induced by the > network are passed to their ultimate destinations as such (stateless). > IMO, reassembly should be done within the SFC domain (responsible for > fragmentation) not passed away. > (2) Does the stateful mode require all SFC data plane elements maintain a > full list of MTU for the any SFF/SF instance of the SFC domain? >=20 > The current text suggests that [RFC6830] should be listed as normative > reference (not an informative one). I would personally favor removing the > reference to LISP (as it is an Experimental RFC). >=20 > * The security section of the draft may be augmented with informational > fragmentation-related pointers to: e.g., RFC1858 (Security Considerations > for IP Fragment Filtering), RFC3128 (Protection Against a Variant of the > Tiny Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High Data > Rates). >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 11 avril 2016 13:14 =C0= =A0: > > Thomas Narten; sfc@ietf.org Objet=A0: Re: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Dear Thomas, all, > > > > As I mentioned during the meeting, there are several issues that are > > not covered in the last version of the draft. I already provided > > examples of the issues offline as requested by Martin. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten > > > Envoy=E9=A0: jeudi 31 mars 2016 04:48 =C0=A0: sfc@ietf.org Objet=A0: = [sfc] WG > > > last call for draft-ietf-sfc-nsh-04.txt > > > > > > Dear WG: > > > > > > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > > > The editors of the NSH document have indicated that they have > > > addressed all known comments and that there are no open issues with > > > the current version of the document. > > > > > > Substantive comments to the list please, editorial comments can go > > > directly to the document editors. > > > > > > We'll also get a brief update from the editors at next week's > > > meeting. If there are any remaining issues with the document, > > > raising them before the meeting would be especially helpful. > > > > > > For the chairs, > > > Thomas > > > > > > _______________________________________________ > > > 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 Sun Apr 24 22:48: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 CB2A412B005 for ; Sun, 24 Apr 2016 22:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y2ARPfQ7qPt0 for ; Sun, 24 Apr 2016 22:48:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0618E12B025 for ; Sun, 24 Apr 2016 22:48:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 419122DC230; Mon, 25 Apr 2016 07:48:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D2114C048; Mon, 25 Apr 2016 07:48:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Mon, 25 Apr 2016 07:48:33 +0200 From: To: "Paul Quinn (paulq)" Thread-Topic: [sfc] TLV class of variable-length metadata should have a restricted range Thread-Index: AQHRmWezeX5Az/rjTQOEcq50WzDr6Z+QLNUAgAEBmYCAAnM8AIAAPdwAgABjwQCAAiFYAIAD0Bwg Date: Mon, 25 Apr 2016 05:48:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5EEE5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D5BB09@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D5C3B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6E92E595-B0DD-4E35-96B0-795D75BE4C0B@cisco.com> <787AE7BB302AE849A7480A190F8B933008D5D52D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <825ECEA4-2762-44C1-84E7-86F332DD8550@cisco.com> In-Reply-To: <825ECEA4-2762-44C1-84E7-86F332DD8550@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D5EEE5OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.52415 Archived-At: Cc: "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] TLV class of variable-length metadata should have a restricted range 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: Mon, 25 Apr 2016 05:48:39 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D5EEE5OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KVGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gSSB1bmRlcnN0YW5k IGZyb20geW91ciBhbnN3ZXIgdGhpcyBpcyBzdWJqZWN0aXZlLCBidXQgSSB3b3VsZCBub3Qgc2F5 IHRoYXQgaGF2aW5nIDJeXjE2IG93bmVycyBpcyBhIOKAnHBydWRlbnTigJ0gZGVzaWduLg0KDQpJ 4oCZbSBhZnJhaWQgdGhpcyBpcyBub3QgdGhlIG9ubHkgY29uc2lkZXJhdGlvbnMgdGhhdCBuZWVk IHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBmb3IgdGhpcyBvcHRpb25hbCBjb250ZXh0IGluZm9y bWF0aW9uLiBCZWxvdyBzb21lIG9mIHRoZSBrZXkgZGVzaWduIGNyaXRlcmlhIGZyb20gbXkgc3Rh bmRwb2ludDoNCg0KDQrCtyAgICAgICAgIEFsbG93IGZvciBiZXR0ZXIgaW50ZXJvcGVyYWJpbGl0 eSBlc3BlY2lhbGx5IGluIHRoZSBjb250ZXh0IG9mICBNdWx0aS12ZW5kb3IgU2VydmljZSBGdW5j dGlvbnMgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDk4I3NlY3Rpb24tMi4xMikN Cg0KwrcgICAgICAgICBGb3N0ZXIgU0ZDIGlubm92YXRpb24NCg0KwrcgICAgICAgICBQcmVzZXJ2 ZSBjb21wYWN0IG1lc3NhZ2UgZW5jb2RpbmcNCg0KSGF2aW5nIEZFVyBiaXRzIGZvciB0aGUgY2xh c3MgZmllbGQgd291bGQgYmUgdGhlIHJlYXNvbmFibGUgYXBwcm9hY2ggKHdoaWxlIDE2IGJpdHMg YXJlIHJlc2VydmVkIGZvciBjb252ZXlpbmcgdGhlIOKAnHR5cGXigJ0gb2YgdGhlIGNvbnRleHQg aW5mb3JtYXRpb24pLg0KDQpJIHNlZSB0aGF0IEpvZWwga2luZGx5IG1hZGUgYSBjb21tZW50IGFi b3V0IHRoZSBzaXplIG9mIHRoaXMgZmllbGQ6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9zZmMvY3VycmVudC9tc2cwNDQ5Ni5odG1sDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6 IFBhdWwgUXVpbm4gKHBhdWxxKSBbbWFpbHRvOnBhdWxxQGNpc2NvLmNvbV0NCkVudm95w6kgOiB2 ZW5kcmVkaSAyMiBhdnJpbCAyMDE2IDE2OjE4DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P TE4NCkNjIDogRGF2ZSBEb2xzb247IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBSZTogW3NmY10gVExW IGNsYXNzIG9mIHZhcmlhYmxlLWxlbmd0aCBtZXRhZGF0YSBzaG91bGQgaGF2ZSBhIHJlc3RyaWN0 ZWQgcmFuZ2UNCg0KSGVsbG8gTWVkLA0KDQpUaGlzICJzaXplIiBvZiB0aGUgZmllbGQgaGVscHMg ZW5zdXJlIHRoYXQgbWFueSBvcmdhbml6YXRpb24vcmVnaXN0cmllcy9vd25lcnMgY2FuIHBhcnRp Y2lwYXRlLiAgQXQgdGhpcyBwb2ludCwgaXQgc2VlbXMgcHJ1ZGVudCBhbmQgd2UgZG9uJ3QgbmVl ZCB0byB0cnkgdG8gb3B0aW1pemUgc2luY2UgdGhpcyBhY2NvbW1vZGF0ZXMgYSBsYXJnZS1yYW5n ZSBvZiBvcHRpb25zLg0KDQpQYXVsDQoNCk9uIEFwciAyMSwgMjAxNiwgYXQgMTo0NiBBTSwgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4gd3JvdGU6DQoNCkhpIFBhdWwsDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpZmljYXRp b24uIFRoaXMgaXMgYWxpZ25lZCB3aXRoIHRoZSBpbnRlcnByZXRhdGlvbiBJIGhhZCBmb3IgdGhp cyBmaWVsZC4gSXQgY2FuIHBvaW50IHRvIGFub3RoZXIgcmVnaXN0ZXIsIG93bmVyLCBldGMuIGJ1 dCBzdGlsbCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgd2UgbmVlZCB0byBoYXZlIDJeXjE2IHZh bHVlcyBmb3IgdGhpcy4NCg0KSSB3b27igJl0IHJlcGVhdCBteSBwcm9wb3NhbCB0byBpbmNsdWRl IElQRklYIHJlZ2lzdHJ5IGhlcmUgYXMgaXQgaXMgYWxyZWFkeSByYWlzZWQgaW4gb3RoZXIgdGhy ZWFkcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgUGF1bCBRdWlubiAocGF1bHEpDQpFbnZvecOpIDogamV1ZGkg MjEgYXZyaWwgMjAxNiAwMTo0OQ0Kw4AgOiBEYXZlIERvbHNvbg0KQ2MgOiBzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtzZmNdIFRMViBjbGFzcyBvZiB2YXJp YWJsZS1sZW5ndGggbWV0YWRhdGEgc2hvdWxkIGhhdmUgYSByZXN0cmljdGVkIHJhbmdlDQoNCg0K T24gQXByIDIwLCAyMDE2LCBhdCA0OjA3IFBNLCBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmlu ZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4gd3JvdGU6DQoNCk1lZCwNCg0KVGhh dOKAmXMgYSBxdWVzdGlvbiBmb3Igb3RoZXJzLiBJIGRvbuKAmXQga25vdyB3aHkgc28gYml0cyBh cmUgYWxsb2NhdGVkIGZvciBjbGFzcy4gTXkgc2Vuc2UgaXMgdGhpcyBpcyB0aG91Z2h0IG9mIGFz IGEgdmVuZG9yLUlEIGZpZWxkLg0KDQpUaGF0J3MgY29ycmVjdDogaXQgc2NvcGVzIHRoZSBkYXRh IHRvIGEgcGFydGljdWxhciAib3duZXIiLiAgVGhhdCBwcm9iYWJseSBpc24ndCBjbGVhciBpbiB0 aGUgZHJhZnQgYW5kIHdpbGwgYmUgY2xhcmlmaWVkLiAgVGhlIGludGVudCBpcyB0byByZXNlcnZl IGEgcmFuZ2UgZm9yICJzdGFuZGFyZHMiIHVzZSwgYW5kIHRoZW4gYWxsb3cgdmVuZG9ycyAoZm9y IGV4YW1wbGUpIHRvIGhhdmUgdGhlaXIgc2NvcGUgYXMgd2VsbC4NCg0KUGF1bA0KDQo= --_000_787AE7BB302AE849A7480A190F8B933008D5EEE5OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFy Z2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5 bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0K CWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEyNDAzNjM0OTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjEyOTUwMzU3MTggLTE0MDYzNTExNzIgNjc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcg Njc4OTUyOTkgNjc4OTUzMDEgNjc4OTUyOTcgNjc4OTUyOTkgNjc4OTUzMDE7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJG UiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIFBhdWwsDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UgZm9yIHRoZSBj bGFyaWZpY2F0aW9uLiBJIHVuZGVyc3RhbmQgZnJvbSB5b3VyIGFuc3dlciB0aGlzIGlzIHN1Ympl Y3RpdmUsIGJ1dCBJIHdvdWxkIG5vdCBzYXkgdGhhdCBoYXZpbmcNCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjJeXjE2IG93bmVycyBpcyBhIOKAnHBydWRlbnTigJ0gZGVzaWduLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5J4oCZbSBhZnJh aWQgdGhpcyBpcyBub3QgdGhlIG9ubHkgY29uc2lkZXJhdGlvbnMgdGhhdCBuZWVkIHRvIGJlIHRh a2VuIGludG8gYWNjb3VudCBmb3IgdGhpcyBvcHRpb25hbCBjb250ZXh0IGluZm9ybWF0aW9uLiBC ZWxvdyBzb21lIG9mIHRoZSBrZXkgZGVzaWduIGNyaXRlcmlhDQogZnJvbSBteSBzdGFuZHBvaW50 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGxvdyBmb3IgYmV0dGVyIGludGVyb3Bl cmFiaWxpdHkgZXNwZWNpYWxseSBpbiB0aGUgY29udGV4dCBvZiAmbmJzcDtNdWx0aS12ZW5kb3Ig U2VydmljZSBGdW5jdGlvbnMgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NDk4I3NlY3Rpb24tMi4xMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0OTgj c2VjdGlvbi0yLjEyPC9hPik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkZvc3RlciBTRkMgaW5ub3ZhdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UHJlc2VydmUgY29tcGFj dCBtZXNzYWdlIGVuY29kaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkhhdmluZyBGRVcgYml0cyBmb3IgdGhlIGNsYXNzIGZpZWxkIHdvdWxkIGJlIHRoZSByZWFzb25h YmxlIGFwcHJvYWNoICh3aGlsZSAxNiBiaXRzIGFyZSByZXNlcnZlZCBmb3IgY29udmV5aW5nIHRo ZSDigJx0eXBl4oCdIG9mIHRoZSBjb250ZXh0IGluZm9ybWF0aW9uKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBzZWUgdGhhdCBKb2VsIGtpbmRseSBtYWRlIGEgY29t bWVudCBhYm91dCB0aGUgc2l6ZSBvZiB0aGlzIGZpZWxkOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzA0NDk2Lmh0bWwiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwNDQ5Ni5odG1s PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1lZDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFBhdWwgUXVpbm4gKHBhdWxxKSBbbWFpbHRvOnBhdWxx QGNpc2NvLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSAyMiBhdnJp bCAyMDE2IDE2OjE4PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBEYXZlIERvbHNvbjsgc2ZjQGlldGYub3JnPGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NmY10gVExWIGNsYXNzIG9mIHZhcmlhYmxlLWxlbmd0 aCBtZXRhZGF0YSBzaG91bGQgaGF2ZSBhIHJlc3RyaWN0ZWQgcmFuZ2U8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBNZWQsIDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyAmcXVvdDtzaXplJnF1b3Q7IG9m IHRoZSBmaWVsZCBoZWxwcyBlbnN1cmUgdGhhdCBtYW55IG9yZ2FuaXphdGlvbi9yZWdpc3RyaWVz L293bmVycyBjYW4gcGFydGljaXBhdGUuICZuYnNwO0F0IHRoaXMgcG9pbnQsIGl0IHNlZW1zIHBy dWRlbnQgYW5kIHdlIGRvbid0IG5lZWQgdG8gdHJ5IHRvIG9wdGltaXplIHNpbmNlIHRoaXMgYWNj b21tb2RhdGVzIGEgbGFyZ2UtcmFuZ2Ugb2Ygb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF1bDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDIxLCAyMDE2LCBhdCAx OjQ2IEFNLCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgUGF1 bCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+VGhhbmsgeW91IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gVGhpcyBpcyBhbGlnbmVkIHdpdGgg dGhlIGludGVycHJldGF0aW9uIEkgaGFkIGZvciB0aGlzIGZpZWxkLiBJdCBjYW4gcG9pbnQgdG8g YW5vdGhlciByZWdpc3Rlciwgb3duZXIsIGV0Yy4gYnV0IHN0aWxsIEkgZG9u4oCZdCB1bmRlcnN0 YW5kDQogd2h5IHdlIG5lZWQgdG8gaGF2ZSAyXl4xNiB2YWx1ZXMgZm9yIHRoaXMuPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JIHdvbuKAmXQgcmVwZWF0 IG15IHByb3Bvc2FsIHRvIGluY2x1ZGUgSVBGSVggcmVnaXN0cnkgaGVyZSBhcyBpdCBpcyBhbHJl YWR5IHJhaXNlZCBpbiBvdGhlciB0aHJlYWRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5NZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnNmYw0KIFs8YSBocmVmPSJtYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5EZSBsYSBwYXJ0IGRlPC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QYXVsIFF1aW5uIChwYXVscSk8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+amV1ZGkgMjEgYXZyaWwgMjAxNiAwMTo0OTxicj4NCjxiPsOAJm5i c3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ RGF2ZSBEb2xzb248YnI+DQo8Yj5DYyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNmY0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+ T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5SZTogW3NmY10gVExWIGNsYXNzIG9mIHZhcmlhYmxlLWxlbmd0aCBtZXRhZGF0YSBz aG91bGQgaGF2ZSBhIHJlc3RyaWN0ZWQgcmFuZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBBcHIgMjAsIDIwMTYsIGF0IDQ6MDcgUE0sIERhdmUgRG9sc29uICZsdDs8 YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1l ZCw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGF04oCZcyBhIHF1ZXN0aW9uIGZvciBvdGhlcnMuIEkgZG9u4oCZdCBrbm93IHdo eSBzbyBiaXRzIGFyZSBhbGxvY2F0ZWQgZm9yIGNsYXNzLiBNeSBzZW5zZSBpcyB0aGlzIGlzIHRo b3VnaHQgb2YgYXMgYSB2ZW5kb3ItSUQgZmllbGQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBjb3JyZWN0OiBpdCBzY29wZXMg dGhlIGRhdGEgdG8gYSBwYXJ0aWN1bGFyICZxdW90O293bmVyJnF1b3Q7LiAmbmJzcDtUaGF0IHBy b2JhYmx5IGlzbid0IGNsZWFyIGluIHRoZSBkcmFmdCBhbmQgd2lsbCBiZSBjbGFyaWZpZWQuICZu YnNwO1RoZSBpbnRlbnQgaXMgdG8gcmVzZXJ2ZSBhIHJhbmdlIGZvciAmcXVvdDtzdGFuZGFyZHMm cXVvdDsgdXNlLCBhbmQgdGhlbiBhbGxvdyB2ZW5kb3JzIChmb3IgZXhhbXBsZSkgdG8gaGF2ZSB0 aGVpciBzY29wZSBhcw0KIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhdWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B933008D5EEE5OPEXCLILMA3corp_-- From nobody Sun Apr 24 23:30:00 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 4FB8412D0F5 for ; Sun, 24 Apr 2016 23:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 YRcK01M5K91H for ; Sun, 24 Apr 2016 23:29:57 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8112D0C5 for ; Sun, 24 Apr 2016 23:29:57 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 24 Apr 2016 23:29:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,531,1455004800"; d="scan'208";a="791684933" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga003.jf.intel.com with ESMTP; 24 Apr 2016 23:29:48 -0700 Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 24 Apr 2016 23:29:46 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX113.amr.corp.intel.com ([169.254.9.9]) with mapi id 14.03.0248.002; Sun, 24 Apr 2016 23:29:46 -0700 From: "Elzur, Uri" To: "mohamed.boucadair@orange.com" , "Thomas Narten" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQCYv/wVVMUagOUO32rRCGp+Er+AwgARg/TCAEFX48IABYBMA//+ZdQA= Date: Mon, 25 Apr 2016 06:29:46 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGQ2Y2ZiYTMtODQ0Zi00YmU5LTllZWQtOWM1M2E2MzIzODFmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkRDRW41bzErR016NnZwd1wvZGNZUm1xNE1LbGt3QVF6cWlsR0VpNnJEYytnPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 06:29:59 -0000 Hi Med My point is that Fragmentation is yet another transport related issue that = is beyond the scope of NSH and beyond the charter of the WG, so it doesn't = really belong in the draft. We are providing an advice as extending the siz= e of the packet may lead to fragmentation, but as you check RFC 7348 VxLAN,= which my create the same issue, you'll find it doesn't even relate to it. Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Sunday, April 24, 2016 10:32 PM To: Elzur, Uri ; Thomas Narten ; sf= c@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Uri, That's another option that needs to be discussed/investigated. I'm afraid t= his is not the rationale adopted in -04 since it includes some text that is= far to be sufficient to ensure interoperable implementations. BTW, saying that nsh does not need to deal with fragmentation because it is= transport-independent is not IMHO a good strategy to adopt here because it= opens the door for interoperable issues, it may lead to sub-optimal implem= entations if the sfc information is present only in one fragments, etc. =20 My comments are related to the current text in the -04. This text needs to = be fixed somehow. Cheers, Med > -----Message d'origine----- > De=A0: Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9=A0: dimanche 24=20 > avril 2016 17:36 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 > sfc@ietf.org Objet=A0: RE: [sfc] WG last call for=20 > draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > I see no need to specify the exact behavior as NSH is transport=20 > independent i.e. like NSH interaction with any other Transport eh=20 > issue of Fragmentation is to be dealt in a way that matches the=20 > mechanisms supported by the Transport used and do not belong in the=20 > NSH draft >=20 > Thx >=20 > Uri ("Oo-Ree") > C: 949-378-7568 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: Thursday, April 14, 2016 12:43 AM > To: Thomas Narten ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > R-, >=20 > In addition to other pending issues raised for this draft, I would=20 > like to raise this additional one about Section 6. >=20 > =3D=3D > 6. Fragmentation Considerations >=20 > NSH and the associated transport header are "added" to the > encapsulated packet/frame. This additional information increases the > size of the packet. In order the ensure proper forwarding of NSH > data, several options for handling fragmentation and re-assembly > exist: >=20 > 1. Jumbo Frames, when supported, enable the transport of NSH and > associated transport packets without requiring fragmentation. >=20 > 2. Path MTU Discovery [RFC1191]"describes a technique for > dynamically discovering the maximum transmission unit (MTU) of an > arbitrary internet path" and can be utilized to ensure the the > required packet size is used. >=20 > 3. [RFC6830] describes two schemes for fragmentation and re-assembly > in section 5.4. > =3D=3D >=20 > * The text is weak for a Standard track document that is intended to=20 > solve the problem in https://tools.ietf.org/html/rfc7498#section-2.12.=20 > There should be a clear behavior to be followed by an implementation.=20 > Further, I would avoid the use of words such as "can". >=20 > * The text covers only fragmentation when it is induced by SFC=20 > operations, it does not discuss the treatment of a fragment when=20 > received in an SFC domain. IMHO, the draft should also specify the=20 > behavior of the Classifier with regards to fragments for the sake of=20 > proper SFC operation. Applying classification policies may require the fu= ll packet, not only a fragment. > In particular, dedicated resources should dedicated for handling out=20 > of order fragments. Of course, it is out of scope of this document to=20 > describe how SFs handle fragments. >=20 > * If an SFC header is prepended for all fragments, I'm not sure there=20 > is any particular issue at the SFF level...except if stripping/adding=20 > context TLVs depends on the full packet (not just fragment). It is=20 > warranted to consider a little bit this point before declaring there is n= o issue. >=20 > * The text states "several options". This may be interpreted as if=20 > implementing one of them is sufficient...which is not true. The first=20 > two points contribute to minimize the fragmentation risk, but=20 > fragmentation may still be experienced (e.g., other shims are=20 > prepended by other nodes for some other purposes, nested nsh, etc.) >=20 > * The first two points have nothing to do with reassembly. >=20 > * The support of jumbo frames by a router/device does not mean that it=20 > can make use of it. Appropriate MTU configuration should be undertaken=20 > in a consistent manner within an SFC domain. The text should be=20 > updated to make it is about (consistent) MTU configuration. >=20 > * BTW, shouldn't the text be reworded to recommended to increase the=20 > MTU of **all nodes** of an SFC-enabled domain by at least the length=20 > of SFC header + transport header? >=20 > * Bullet 2, how PMTU discovery is actually used in this context? Do=20 > you assume that all SFC-aware nodes will issue such messages towards=20 > other SFC-aware node, arbitrary destination, else? >=20 > * Bullet 2, I would drop "describes a technique for dynamically=20 > discovering the maximum transmission unit (MTU) of an arbitrary=20 > internet path". >=20 > * Bullet 2, s/ the the/the. >=20 > * The reference to the LISP specification raises two concerns and one > comment: >=20 > (1) I don't think it is a good approach that fragments induced by the=20 > network are passed to their ultimate destinations as such (stateless). > IMO, reassembly should be done within the SFC domain (responsible for > fragmentation) not passed away. > (2) Does the stateful mode require all SFC data plane elements=20 > maintain a full list of MTU for the any SFF/SF instance of the SFC domain= ? >=20 > The current text suggests that [RFC6830] should be listed as normative=20 > reference (not an informative one). I would personally favor removing=20 > the reference to LISP (as it is an Experimental RFC). >=20 > * The security section of the draft may be augmented with=20 > informational fragmentation-related pointers to: e.g., RFC1858=20 > (Security Considerations for IP Fragment Filtering), RFC3128=20 > (Protection Against a Variant of the Tiny Fragment Attack), and RFC=20 > 4963 (IPv4 Reassembly Errors at High Data Rates). >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de=20 > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 11 avril 2016 13:14 =C0= =A0: > > Thomas Narten; sfc@ietf.org Objet=A0: Re: [sfc] WG last call for=20 > > draft-ietf-sfc-nsh-04.txt > > > > Dear Thomas, all, > > > > As I mentioned during the meeting, there are several issues that are=20 > > not covered in the last version of the draft. I already provided=20 > > examples of the issues offline as requested by Martin. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten= =20 > > > Envoy=E9=A0: jeudi 31 mars 2016 04:48 =C0=A0: sfc@ietf.org Objet=A0: = [sfc]=20 > > > WG last call for draft-ietf-sfc-nsh-04.txt > > > > > > Dear WG: > > > > > > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 > > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > > > The editors of the NSH document have indicated that they have=20 > > > addressed all known comments and that there are no open issues=20 > > > with the current version of the document. > > > > > > Substantive comments to the list please, editorial comments can go=20 > > > directly to the document editors. > > > > > > We'll also get a brief update from the editors at next week's=20 > > > meeting. If there are any remaining issues with the document,=20 > > > raising them before the meeting would be especially helpful. > > > > > > For the chairs, > > > Thomas > > > > > > _______________________________________________ > > > 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 Mon Apr 25 00:00:24 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 4209012D120 for ; Mon, 25 Apr 2016 00:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 XJUsfeNinxM6 for ; Mon, 25 Apr 2016 00:00:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F60412B03C for ; Mon, 25 Apr 2016 00:00:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CA84B324433; Mon, 25 Apr 2016 09:00:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A834635C068; Mon, 25 Apr 2016 09:00:18 +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.0279.002; Mon, 25 Apr 2016 09:00:18 +0200 From: To: "Elzur, Uri" , Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQCYv/wVVMUagOUO32rRCGp+Er+AwgARg/TCAEFX48IABYBMA//+ZdQCAAAWQcA== Date: Mon, 25 Apr 2016 07:00:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 07:00:23 -0000 Re-, I hear you, but my comment is that we need, as a WG, to decide what to put = in the draft. FWIW, I'm discussing two fragmentation issues:=20 (1) Fragmentation that is caused by prepending an SFC header. (2) Handling fragments at the ingress of an SFC-enabled domain.=20 Increasing the MTU is for sure a recommendation is to be explicitly called = out in the text (see my first message). There are other issues that need to be discussed, e.g., how to deal with fr= agments in SFFs/Classifiers?=20 It is also "prudent" to check that no issues will be experienced in SFF to = handle fragments. If an SFC header is prepended for all fragments, I'm not = sure there is any particular issue at the SFF level, except if stripping/adding contex= t TLVs depends on the full packet (not just fragment). It is warranted to c= onsider a little bit this point before declaring there is no issue. For point (1), declaring fragmentation out of scope would be meant that an = implementation must be prepared to receive fragments with or without NSH he= ader as this is a decision that is left to the transport encapsulation. Thi= s is a requirement per se! I won't reiterate all the comments I have about the current wording of this= section.=20 Cheers, Med > -----Message d'origine----- > De=A0: Elzur, Uri [mailto:uri.elzur@intel.com] > Envoy=E9=A0: lundi 25 avril 2016 08:30 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet=A0: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > My point is that Fragmentation is yet another transport related issue tha= t > is beyond the scope of NSH and beyond the charter of the WG, so it doesn'= t > really belong in the draft. We are providing an advice as extending the > size of the packet may lead to fragmentation, but as you check RFC 7348 > VxLAN, which my create the same issue, you'll find it doesn't even relate > to it. >=20 > Thx >=20 > Uri ("Oo-Ree") > C: 949-378-7568 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Sunday, April 24, 2016 10:32 PM > To: Elzur, Uri ; Thomas Narten ; > sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Uri, >=20 > That's another option that needs to be discussed/investigated. I'm afraid > this is not the rationale adopted in -04 since it includes some text that > is far to be sufficient to ensure interoperable implementations. >=20 > BTW, saying that nsh does not need to deal with fragmentation because it > is transport-independent is not IMHO a good strategy to adopt here becaus= e > it opens the door for interoperable issues, it may lead to sub-optimal > implementations if the sfc information is present only in one fragments, > etc. >=20 > My comments are related to the current text in the -04. This text needs t= o > be fixed somehow. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9=A0: dimanche 24 > > avril 2016 17:36 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > > sfc@ietf.org Objet=A0: RE: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Hi Med > > > > I see no need to specify the exact behavior as NSH is transport > > independent i.e. like NSH interaction with any other Transport eh > > issue of Fragmentation is to be dealt in a way that matches the > > mechanisms supported by the Transport used and do not belong in the > > NSH draft > > > > Thx > > > > Uri ("Oo-Ree") > > C: 949-378-7568 > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Thursday, April 14, 2016 12:43 AM > > To: Thomas Narten ; sfc@ietf.org > > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > R-, > > > > In addition to other pending issues raised for this draft, I would > > like to raise this additional one about Section 6. > > > > =3D=3D > > 6. Fragmentation Considerations > > > > NSH and the associated transport header are "added" to the > > encapsulated packet/frame. This additional information increases th= e > > size of the packet. In order the ensure proper forwarding of NSH > > data, several options for handling fragmentation and re-assembly > > exist: > > > > 1. Jumbo Frames, when supported, enable the transport of NSH and > > associated transport packets without requiring fragmentation. > > > > 2. Path MTU Discovery [RFC1191]"describes a technique for > > dynamically discovering the maximum transmission unit (MTU) of a= n > > arbitrary internet path" and can be utilized to ensure the the > > required packet size is used. > > > > 3. [RFC6830] describes two schemes for fragmentation and re-assembl= y > > in section 5.4. > > =3D=3D > > > > * The text is weak for a Standard track document that is intended to > > solve the problem in https://tools.ietf.org/html/rfc7498#section-2.12. > > There should be a clear behavior to be followed by an implementation. > > Further, I would avoid the use of words such as "can". > > > > * The text covers only fragmentation when it is induced by SFC > > operations, it does not discuss the treatment of a fragment when > > received in an SFC domain. IMHO, the draft should also specify the > > behavior of the Classifier with regards to fragments for the sake of > > proper SFC operation. Applying classification policies may require the > full packet, not only a fragment. > > In particular, dedicated resources should dedicated for handling out > > of order fragments. Of course, it is out of scope of this document to > > describe how SFs handle fragments. > > > > * If an SFC header is prepended for all fragments, I'm not sure there > > is any particular issue at the SFF level...except if stripping/adding > > context TLVs depends on the full packet (not just fragment). It is > > warranted to consider a little bit this point before declaring there is > no issue. > > > > * The text states "several options". This may be interpreted as if > > implementing one of them is sufficient...which is not true. The first > > two points contribute to minimize the fragmentation risk, but > > fragmentation may still be experienced (e.g., other shims are > > prepended by other nodes for some other purposes, nested nsh, etc.) > > > > * The first two points have nothing to do with reassembly. > > > > * The support of jumbo frames by a router/device does not mean that it > > can make use of it. Appropriate MTU configuration should be undertaken > > in a consistent manner within an SFC domain. The text should be > > updated to make it is about (consistent) MTU configuration. > > > > * BTW, shouldn't the text be reworded to recommended to increase the > > MTU of **all nodes** of an SFC-enabled domain by at least the length > > of SFC header + transport header? > > > > * Bullet 2, how PMTU discovery is actually used in this context? Do > > you assume that all SFC-aware nodes will issue such messages towards > > other SFC-aware node, arbitrary destination, else? > > > > * Bullet 2, I would drop "describes a technique for dynamically > > discovering the maximum transmission unit (MTU) of an arbitrary > > internet path". > > > > * Bullet 2, s/ the the/the. > > > > * The reference to the LISP specification raises two concerns and one > > comment: > > > > (1) I don't think it is a good approach that fragments induced by the > > network are passed to their ultimate destinations as such (stateless). > > IMO, reassembly should be done within the SFC domain (responsible for > > fragmentation) not passed away. > > (2) Does the stateful mode require all SFC data plane elements > > maintain a full list of MTU for the any SFF/SF instance of the SFC > domain? > > > > The current text suggests that [RFC6830] should be listed as normative > > reference (not an informative one). I would personally favor removing > > the reference to LISP (as it is an Experimental RFC). > > > > * The security section of the draft may be augmented with > > informational fragmentation-related pointers to: e.g., RFC1858 > > (Security Considerations for IP Fragment Filtering), RFC3128 > > (Protection Against a Variant of the Tiny Fragment Attack), and RFC > > 4963 (IPv4 Reassembly Errors at High Data Rates). > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de > > > mohamed.boucadair@orange.com Envoy=E9=A0: lundi 11 avril 2016 13:14 = =C0=A0: > > > Thomas Narten; sfc@ietf.org Objet=A0: Re: [sfc] WG last call for > > > draft-ietf-sfc-nsh-04.txt > > > > > > Dear Thomas, all, > > > > > > As I mentioned during the meeting, there are several issues that are > > > not covered in the last version of the draft. I already provided > > > examples of the issues offline as requested by Martin. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narte= n > > > > Envoy=E9=A0: jeudi 31 mars 2016 04:48 =C0=A0: sfc@ietf.org Objet=A0= : [sfc] > > > > WG last call for draft-ietf-sfc-nsh-04.txt > > > > > > > > Dear WG: > > > > > > > > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > > > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > > > > > The editors of the NSH document have indicated that they have > > > > addressed all known comments and that there are no open issues > > > > with the current version of the document. > > > > > > > > Substantive comments to the list please, editorial comments can go > > > > directly to the document editors. > > > > > > > > We'll also get a brief update from the editors at next week's > > > > meeting. If there are any remaining issues with the document, > > > > raising them before the meeting would be especially helpful. > > > > > > > > For the chairs, > > > > Thomas > > > > > > > > _______________________________________________ > > > > 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 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Apr 25 06:47:53 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 948A312D0B0 for ; Mon, 25 Apr 2016 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 Ox0WftGMwJey for ; Mon, 25 Apr 2016 06:47:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A4312B014 for ; Mon, 25 Apr 2016 06:47:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 85EF62638DA; Mon, 25 Apr 2016 06:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461592070; bh=iaOVASiZFVGzWD40Vzw1tll9cMs+FmJ79fw/jrJSooI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J7Q+SKMI/M9g1YQ4ywCfrVYvlep008YdMr74xdRtSO7iTxWPZ2d/Mn2VYuTAYPS6v T/O+agxcxr05a17vYkvPgreK20ozU1ulIy67ODuyhT6DLphH0uE5bFrULEOrFi34Ap 8JPa+SimSgy1YGl40WsCJcfu5iaLgNuk/SXbXziY= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id DD5C5250978; Mon, 25 Apr 2016 06:47:49 -0700 (PDT) To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> Date: Mon, 25 Apr 2016 09:47:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 13:47:52 -0000 If I am understanding you correctly Med, you are asking that the NSH draft specify how service chaining should cope with packets that have been fragmented? NSH, and the SFF functionality, does not care. It just does its job. Ingress and intermediate classifiers may cope with fragments in any number of ways. Specifying such is clearly out of scope for this draft. I suppose one could write an informational draft on possible ways of coping. The IETF has not usually published such. Service functions have to cope with fragmented packets just as they had to before the advent of NSH, so describing that is clearly not needed here. Yours, Joel On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > Re-, > > I hear you, but my comment is that we need, as a WG, to decide what to put in the draft. FWIW, I'm discussing two fragmentation issues: > > (1) Fragmentation that is caused by prepending an SFC header. > (2) Handling fragments at the ingress of an SFC-enabled domain. > > Increasing the MTU is for sure a recommendation is to be explicitly called out in the text (see my first message). > > There are other issues that need to be discussed, e.g., how to deal with fragments in SFFs/Classifiers? > > It is also "prudent" to check that no issues will be experienced in SFF to handle fragments. If an SFC header is prepended for all fragments, I'm not sure there > is any particular issue at the SFF level, except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. > > For point (1), declaring fragmentation out of scope would be meant that an implementation must be prepared to receive fragments with or without NSH header as this is a decision that is left to the transport encapsulation. This is a requirement per se! > > I won't reiterate all the comments I have about the current wording of this section. > > Cheers, > Med > >> -----Message d'origine----- >> De : Elzur, Uri [mailto:uri.elzur@intel.com] >> Envoyé : lundi 25 avril 2016 08:30 >> À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org >> Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> My point is that Fragmentation is yet another transport related issue that >> is beyond the scope of NSH and beyond the charter of the WG, so it doesn't >> really belong in the draft. We are providing an advice as extending the >> size of the packet may lead to fragmentation, but as you check RFC 7348 >> VxLAN, which my create the same issue, you'll find it doesn't even relate >> to it. >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Sunday, April 24, 2016 10:32 PM >> To: Elzur, Uri ; Thomas Narten ; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Uri, >> >> That's another option that needs to be discussed/investigated. I'm afraid >> this is not the rationale adopted in -04 since it includes some text that >> is far to be sufficient to ensure interoperable implementations. >> >> BTW, saying that nsh does not need to deal with fragmentation because it >> is transport-independent is not IMHO a good strategy to adopt here because >> it opens the door for interoperable issues, it may lead to sub-optimal >> implementations if the sfc information is present only in one fragments, >> etc. >> >> My comments are related to the current text in the -04. This text needs to >> be fixed somehow. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 >>> avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> I see no need to specify the exact behavior as NSH is transport >>> independent i.e. like NSH interaction with any other Transport eh >>> issue of Fragmentation is to be dealt in a way that matches the >>> mechanisms supported by the Transport used and do not belong in the >>> NSH draft >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Thursday, April 14, 2016 12:43 AM >>> To: Thomas Narten ; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> R-, >>> >>> In addition to other pending issues raised for this draft, I would >>> like to raise this additional one about Section 6. >>> >>> == >>> 6. Fragmentation Considerations >>> >>> NSH and the associated transport header are "added" to the >>> encapsulated packet/frame. This additional information increases the >>> size of the packet. In order the ensure proper forwarding of NSH >>> data, several options for handling fragmentation and re-assembly >>> exist: >>> >>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>> associated transport packets without requiring fragmentation. >>> >>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>> dynamically discovering the maximum transmission unit (MTU) of an >>> arbitrary internet path" and can be utilized to ensure the the >>> required packet size is used. >>> >>> 3. [RFC6830] describes two schemes for fragmentation and re-assembly >>> in section 5.4. >>> == >>> >>> * The text is weak for a Standard track document that is intended to >>> solve the problem in https://tools.ietf.org/html/rfc7498#section-2.12. >>> There should be a clear behavior to be followed by an implementation. >>> Further, I would avoid the use of words such as "can". >>> >>> * The text covers only fragmentation when it is induced by SFC >>> operations, it does not discuss the treatment of a fragment when >>> received in an SFC domain. IMHO, the draft should also specify the >>> behavior of the Classifier with regards to fragments for the sake of >>> proper SFC operation. Applying classification policies may require the >> full packet, not only a fragment. >>> In particular, dedicated resources should dedicated for handling out >>> of order fragments. Of course, it is out of scope of this document to >>> describe how SFs handle fragments. >>> >>> * If an SFC header is prepended for all fragments, I'm not sure there >>> is any particular issue at the SFF level...except if stripping/adding >>> context TLVs depends on the full packet (not just fragment). It is >>> warranted to consider a little bit this point before declaring there is >> no issue. >>> >>> * The text states "several options". This may be interpreted as if >>> implementing one of them is sufficient...which is not true. The first >>> two points contribute to minimize the fragmentation risk, but >>> fragmentation may still be experienced (e.g., other shims are >>> prepended by other nodes for some other purposes, nested nsh, etc.) >>> >>> * The first two points have nothing to do with reassembly. >>> >>> * The support of jumbo frames by a router/device does not mean that it >>> can make use of it. Appropriate MTU configuration should be undertaken >>> in a consistent manner within an SFC domain. The text should be >>> updated to make it is about (consistent) MTU configuration. >>> >>> * BTW, shouldn't the text be reworded to recommended to increase the >>> MTU of **all nodes** of an SFC-enabled domain by at least the length >>> of SFC header + transport header? >>> >>> * Bullet 2, how PMTU discovery is actually used in this context? Do >>> you assume that all SFC-aware nodes will issue such messages towards >>> other SFC-aware node, arbitrary destination, else? >>> >>> * Bullet 2, I would drop "describes a technique for dynamically >>> discovering the maximum transmission unit (MTU) of an arbitrary >>> internet path". >>> >>> * Bullet 2, s/ the the/the. >>> >>> * The reference to the LISP specification raises two concerns and one >>> comment: >>> >>> (1) I don't think it is a good approach that fragments induced by the >>> network are passed to their ultimate destinations as such (stateless). >>> IMO, reassembly should be done within the SFC domain (responsible for >>> fragmentation) not passed away. >>> (2) Does the stateful mode require all SFC data plane elements >>> maintain a full list of MTU for the any SFF/SF instance of the SFC >> domain? >>> >>> The current text suggests that [RFC6830] should be listed as normative >>> reference (not an informative one). I would personally favor removing >>> the reference to LISP (as it is an Experimental RFC). >>> >>> * The security section of the draft may be augmented with >>> informational fragmentation-related pointers to: e.g., RFC1858 >>> (Security Considerations for IP Fragment Filtering), RFC3128 >>> (Protection Against a Variant of the Tiny Fragment Attack), and RFC >>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril 2016 13:14 À : >>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>> draft-ietf-sfc-nsh-04.txt >>>> >>>> Dear Thomas, all, >>>> >>>> As I mentioned during the meeting, there are several issues that are >>>> not covered in the last version of the draft. I already provided >>>> examples of the issues offline as requested by Martin. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>> Envoyé : jeudi 31 mars 2016 04:48 À : sfc@ietf.org Objet : [sfc] >>>>> WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Dear WG: >>>>> >>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>> >>>>> The editors of the NSH document have indicated that they have >>>>> addressed all known comments and that there are no open issues >>>>> with the current version of the document. >>>>> >>>>> Substantive comments to the list please, editorial comments can go >>>>> directly to the document editors. >>>>> >>>>> We'll also get a brief update from the editors at next week's >>>>> meeting. If there are any remaining issues with the document, >>>>> raising them before the meeting would be especially helpful. >>>>> >>>>> For the chairs, >>>>> Thomas >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Apr 25 07:18:19 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 3CD9412B014 for ; Mon, 25 Apr 2016 07:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 Ov8kZ4g5CT5I for ; Mon, 25 Apr 2016 07:18:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F171612B040 for ; Mon, 25 Apr 2016 07:18:14 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 708593245D0; Mon, 25 Apr 2016 16:18:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4ED8627C066; Mon, 25 Apr 2016 16:18:13 +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.0279.002; Mon, 25 Apr 2016 16:18:13 +0200 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRnvkRmtJKuSm9sUC/43QpriLc9Z+atLPw Date: Mon, 25 Apr 2016 14:18:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> In-Reply-To: <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 14:18:18 -0000 Hi Joel,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: lundi 25 avril 2016 15:48 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > If I am understanding you correctly Med, you are asking that the NSH > draft specify how service chaining should cope with packets that have > been fragmented? >=20 [Med] To be accurate, I'm asking to assess whether there are implications. = If there are, then the draft should be updated accordingly. > NSH, and the SFF functionality, does not care. [Med] I'm not that sure. Some typical implications are listed below: * SFF: If the NSH header is present only in the a fragment but SFF didn't m= aintained a state, subsequent fragments won't be appropriately processed.=20 * SFC-aware function: if prepending a context information depends on the fu= ll packet, not only a fragment.=20 It just does its job. [Med] which may be disturbed in some situations as listed in the examples a= bove. > Ingress and intermediate classifiers may cope with fragments in any > number of ways. Specifying such is clearly out of scope for this draft. [Med] The purpose is not to specify the internal implementation details but= the external behavior of the classifier function when it comes to handle f= ragments. That behavior may have an incidence on SFF, in particular. The pu= rpose is not to recommend the maximum resources to be dedicated to out of o= rder fragments nor the timeout to cache those; these considerations are of = course out of scope. Nevertheless, an implementation should offer a configu= rable parameter so that an operator tweak those according to its context. = =20 > I suppose one could write an informational draft on possible ways of > coping. The IETF has not usually published such. > Service functions have to cope with fragmented packets just as they had > to before the advent of NSH, so describing that is clearly not needed > here. [Med] The advent of NSH has the following implications: * it exacerbates fragmentation. Handing over this issue to the transport la= yer may lead to interoperability issues.=20 * the chaining may not be efficient if fragments are inappropriately handle= d.=20 Introducing NSH should not degrade the overall service compared to legacy s= ervice deployment schemes. >=20 > Yours, > Joel >=20 > On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > I hear you, but my comment is that we need, as a WG, to decide what to > put in the draft. FWIW, I'm discussing two fragmentation issues: > > > > (1) Fragmentation that is caused by prepending an SFC header. > > (2) Handling fragments at the ingress of an SFC-enabled domain. > > > > Increasing the MTU is for sure a recommendation is to be explicitly > called out in the text (see my first message). > > > > There are other issues that need to be discussed, e.g., how to deal wit= h > fragments in SFFs/Classifiers? > > > > It is also "prudent" to check that no issues will be experienced in SFF > to handle fragments. If an SFC header is prepended for all fragments, I'm > not sure there > > is any particular issue at the SFF level, except if stripping/adding > context TLVs depends on the full packet (not just fragment). It is > warranted to consider a little bit this point before declaring there is n= o > issue. > > > > For point (1), declaring fragmentation out of scope would be meant that > an implementation must be prepared to receive fragments with or without > NSH header as this is a decision that is left to the transport > encapsulation. This is a requirement per se! > > > > I won't reiterate all the comments I have about the current wording of > this section. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Elzur, Uri [mailto:uri.elzur@intel.com] > >> Envoy=E9 : lundi 25 avril 2016 08:30 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > >> Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Hi Med > >> > >> My point is that Fragmentation is yet another transport related issue > that > >> is beyond the scope of NSH and beyond the charter of the WG, so it > doesn't > >> really belong in the draft. We are providing an advice as extending th= e > >> size of the packet may lead to fragmentation, but as you check RFC 734= 8 > >> VxLAN, which my create the same issue, you'll find it doesn't even > relate > >> to it. > >> > >> Thx > >> > >> Uri ("Oo-Ree") > >> C: 949-378-7568 > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >> mohamed.boucadair@orange.com > >> Sent: Sunday, April 24, 2016 10:32 PM > >> To: Elzur, Uri ; Thomas Narten > ; > >> sfc@ietf.org > >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Hi Uri, > >> > >> That's another option that needs to be discussed/investigated. I'm > afraid > >> this is not the rationale adopted in -04 since it includes some text > that > >> is far to be sufficient to ensure interoperable implementations. > >> > >> BTW, saying that nsh does not need to deal with fragmentation because > it > >> is transport-independent is not IMHO a good strategy to adopt here > because > >> it opens the door for interoperable issues, it may lead to sub-optimal > >> implementations if the sfc information is present only in one > fragments, > >> etc. > >> > >> My comments are related to the current text in the -04. This text need= s > to > >> be fixed somehow. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 > >>> avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > >>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>> draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Med > >>> > >>> I see no need to specify the exact behavior as NSH is transport > >>> independent i.e. like NSH interaction with any other Transport eh > >>> issue of Fragmentation is to be dealt in a way that matches the > >>> mechanisms supported by the Transport used and do not belong in the > >>> NSH draft > >>> > >>> Thx > >>> > >>> Uri ("Oo-Ree") > >>> C: 949-378-7568 > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>> mohamed.boucadair@orange.com > >>> Sent: Thursday, April 14, 2016 12:43 AM > >>> To: Thomas Narten ; sfc@ietf.org > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> R-, > >>> > >>> In addition to other pending issues raised for this draft, I would > >>> like to raise this additional one about Section 6. > >>> > >>> =3D=3D > >>> 6. Fragmentation Considerations > >>> > >>> NSH and the associated transport header are "added" to the > >>> encapsulated packet/frame. This additional information increases > the > >>> size of the packet. In order the ensure proper forwarding of NSH > >>> data, several options for handling fragmentation and re-assembly > >>> exist: > >>> > >>> 1. Jumbo Frames, when supported, enable the transport of NSH and > >>> associated transport packets without requiring fragmentation. > >>> > >>> 2. Path MTU Discovery [RFC1191]"describes a technique for > >>> dynamically discovering the maximum transmission unit (MTU) of > an > >>> arbitrary internet path" and can be utilized to ensure the the > >>> required packet size is used. > >>> > >>> 3. [RFC6830] describes two schemes for fragmentation and re- > assembly > >>> in section 5.4. > >>> =3D=3D > >>> > >>> * The text is weak for a Standard track document that is intended to > >>> solve the problem in https://tools.ietf.org/html/rfc7498#section-2.12= . > >>> There should be a clear behavior to be followed by an implementation. > >>> Further, I would avoid the use of words such as "can". > >>> > >>> * The text covers only fragmentation when it is induced by SFC > >>> operations, it does not discuss the treatment of a fragment when > >>> received in an SFC domain. IMHO, the draft should also specify the > >>> behavior of the Classifier with regards to fragments for the sake of > >>> proper SFC operation. Applying classification policies may require th= e > >> full packet, not only a fragment. > >>> In particular, dedicated resources should dedicated for handling out > >>> of order fragments. Of course, it is out of scope of this document to > >>> describe how SFs handle fragments. > >>> > >>> * If an SFC header is prepended for all fragments, I'm not sure there > >>> is any particular issue at the SFF level...except if stripping/adding > >>> context TLVs depends on the full packet (not just fragment). It is > >>> warranted to consider a little bit this point before declaring there > is > >> no issue. > >>> > >>> * The text states "several options". This may be interpreted as if > >>> implementing one of them is sufficient...which is not true. The first > >>> two points contribute to minimize the fragmentation risk, but > >>> fragmentation may still be experienced (e.g., other shims are > >>> prepended by other nodes for some other purposes, nested nsh, etc.) > >>> > >>> * The first two points have nothing to do with reassembly. > >>> > >>> * The support of jumbo frames by a router/device does not mean that i= t > >>> can make use of it. Appropriate MTU configuration should be undertake= n > >>> in a consistent manner within an SFC domain. The text should be > >>> updated to make it is about (consistent) MTU configuration. > >>> > >>> * BTW, shouldn't the text be reworded to recommended to increase the > >>> MTU of **all nodes** of an SFC-enabled domain by at least the length > >>> of SFC header + transport header? > >>> > >>> * Bullet 2, how PMTU discovery is actually used in this context? Do > >>> you assume that all SFC-aware nodes will issue such messages towards > >>> other SFC-aware node, arbitrary destination, else? > >>> > >>> * Bullet 2, I would drop "describes a technique for dynamically > >>> discovering the maximum transmission unit (MTU) of an arbitrary > >>> internet path". > >>> > >>> * Bullet 2, s/ the the/the. > >>> > >>> * The reference to the LISP specification raises two concerns and one > >>> comment: > >>> > >>> (1) I don't think it is a good approach that fragments induced by the > >>> network are passed to their ultimate destinations as such (stateless)= . > >>> IMO, reassembly should be done within the SFC domain (responsible for > >>> fragmentation) not passed away. > >>> (2) Does the stateful mode require all SFC data plane elements > >>> maintain a full list of MTU for the any SFF/SF instance of the SFC > >> domain? > >>> > >>> The current text suggests that [RFC6830] should be listed as normativ= e > >>> reference (not an informative one). I would personally favor removing > >>> the reference to LISP (as it is an Experimental RFC). > >>> > >>> * The security section of the draft may be augmented with > >>> informational fragmentation-related pointers to: e.g., RFC1858 > >>> (Security Considerations for IP Fragment Filtering), RFC3128 > >>> (Protection Against a Variant of the Tiny Fragment Attack), and RFC > >>> 4963 (IPv4 Reassembly Errors at High Data Rates). > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de > >>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : > >>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for > >>>> draft-ietf-sfc-nsh-04.txt > >>>> > >>>> Dear Thomas, all, > >>>> > >>>> As I mentioned during the meeting, there are several issues that are > >>>> not covered in the last version of the draft. I already provided > >>>> examples of the issues offline as requested by Martin. > >>>> > >>>> Cheers, > >>>> Med > >>>> > >>>>> -----Message d'origine----- > >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten > >>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org Objet : [sfc= ] > >>>>> WG last call for draft-ietf-sfc-nsh-04.txt > >>>>> > >>>>> Dear WG: > >>>>> > >>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > >>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>> > >>>>> The editors of the NSH document have indicated that they have > >>>>> addressed all known comments and that there are no open issues > >>>>> with the current version of the document. > >>>>> > >>>>> Substantive comments to the list please, editorial comments can go > >>>>> directly to the document editors. > >>>>> > >>>>> We'll also get a brief update from the editors at next week's > >>>>> meeting. If there are any remaining issues with the document, > >>>>> raising them before the meeting would be especially helpful. > >>>>> > >>>>> For the chairs, > >>>>> Thomas > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Mon Apr 25 07:25:29 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 884C612D5DC for ; Mon, 25 Apr 2016 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 H4TaPjbPays9 for ; Mon, 25 Apr 2016 07:25:26 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C7612D5D3 for ; Mon, 25 Apr 2016 07:25:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EA65924E0D1; Mon, 25 Apr 2016 07:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461594325; bh=AmsahL/I70ypyyMBGkrOLc6/H1nX2TzETJktZpqpI50=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Vt1lZaXez91GjoEFsNJ4UeHi9BoymQKsfoT8/6Hz9/Euf6mLMmju3DcAzOtlaeEk/ b/RiJ+mG/Rqx+O8FYHyiDEzg87bvrnMuf/edTObBbcpCfBA/t4PVC2v4auQuSQT0ib m+QN/VH0G6j4Enw34T/H/x5nBFiH93wK2X9kd9Co= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3586C240E0F; Mon, 25 Apr 2016 07:25:24 -0700 (PDT) To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <4e4601b5-1315-9869-5437-71816be627df@joelhalpern.com> Date: Mon, 25 Apr 2016 10:25:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 14:25:28 -0000 There are two different issues. There is the question of what happens if adding the NSH header causes fragmentation. I believe that is dealt with sufficiently. It is in scope for the document. The other issue is what happens if a packet is fragmented before it arrives at SFC. the classifier can play any games it likes, but all of the packets it emits will end up getting NSH encapsulated. The mechanism for doing that depends upon how the classifier works, and how the implementation couples the classifier to the encapsulator (which is internal and not subject ot standardization.) So I do not see the disturbances you refer to. Yours, Joel On 4/25/16 10:18 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : lundi 25 avril 2016 15:48 >> À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> If I am understanding you correctly Med, you are asking that the NSH >> draft specify how service chaining should cope with packets that have >> been fragmented? >> > > [Med] To be accurate, I'm asking to assess whether there are implications. If there are, then the draft should be updated accordingly. > >> NSH, and the SFF functionality, does not care. > > [Med] I'm not that sure. Some typical implications are listed below: > > * SFF: If the NSH header is present only in the a fragment but SFF didn't maintained a state, subsequent fragments won't be appropriately processed. > * SFC-aware function: if prepending a context information depends on the full packet, not only a fragment. > > It just does its job. > > [Med] which may be disturbed in some situations as listed in the examples above. > >> Ingress and intermediate classifiers may cope with fragments in any >> number of ways. > Specifying such is clearly out of scope for this draft. > > [Med] The purpose is not to specify the internal implementation details but the external behavior of the classifier function when it comes to handle fragments. That behavior may have an incidence on SFF, in particular. The purpose is not to recommend the maximum resources to be dedicated to out of order fragments nor the timeout to cache those; these considerations are of course out of scope. Nevertheless, an implementation should offer a configurable parameter so that an operator tweak those according to its context. > >> I suppose one could write an informational draft on possible ways of >> coping. The IETF has not usually published such. >> Service functions have to cope with fragmented packets just as they had >> to before the advent of NSH, so describing that is clearly not needed >> here. > > [Med] The advent of NSH has the following implications: > * it exacerbates fragmentation. Handing over this issue to the transport layer may lead to interoperability issues. > * the chaining may not be efficient if fragments are inappropriately handled. > > Introducing NSH should not degrade the overall service compared to legacy service deployment schemes. > >> >> Yours, >> Joel >> >> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>> >>> I hear you, but my comment is that we need, as a WG, to decide what to >> put in the draft. FWIW, I'm discussing two fragmentation issues: >>> >>> (1) Fragmentation that is caused by prepending an SFC header. >>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>> >>> Increasing the MTU is for sure a recommendation is to be explicitly >> called out in the text (see my first message). >>> >>> There are other issues that need to be discussed, e.g., how to deal with >> fragments in SFFs/Classifiers? >>> >>> It is also "prudent" to check that no issues will be experienced in SFF >> to handle fragments. If an SFC header is prepended for all fragments, I'm >> not sure there >>> is any particular issue at the SFF level, except if stripping/adding >> context TLVs depends on the full packet (not just fragment). It is >> warranted to consider a little bit this point before declaring there is no >> issue. >>> >>> For point (1), declaring fragmentation out of scope would be meant that >> an implementation must be prepared to receive fragments with or without >> NSH header as this is a decision that is left to the transport >> encapsulation. This is a requirement per se! >>> >>> I won't reiterate all the comments I have about the current wording of >> this section. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] >>>> Envoyé : lundi 25 avril 2016 08:30 >>>> À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org >>>> Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Med >>>> >>>> My point is that Fragmentation is yet another transport related issue >> that >>>> is beyond the scope of NSH and beyond the charter of the WG, so it >> doesn't >>>> really belong in the draft. We are providing an advice as extending the >>>> size of the packet may lead to fragmentation, but as you check RFC 7348 >>>> VxLAN, which my create the same issue, you'll find it doesn't even >> relate >>>> to it. >>>> >>>> Thx >>>> >>>> Uri ("Oo-Ree") >>>> C: 949-378-7568 >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Sunday, April 24, 2016 10:32 PM >>>> To: Elzur, Uri ; Thomas Narten >> ; >>>> sfc@ietf.org >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Uri, >>>> >>>> That's another option that needs to be discussed/investigated. I'm >> afraid >>>> this is not the rationale adopted in -04 since it includes some text >> that >>>> is far to be sufficient to ensure interoperable implementations. >>>> >>>> BTW, saying that nsh does not need to deal with fragmentation because >> it >>>> is transport-independent is not IMHO a good strategy to adopt here >> because >>>> it opens the door for interoperable issues, it may lead to sub-optimal >>>> implementations if the sfc information is present only in one >> fragments, >>>> etc. >>>> >>>> My comments are related to the current text in the -04. This text needs >> to >>>> be fixed somehow. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 >>>>> avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> I see no need to specify the exact behavior as NSH is transport >>>>> independent i.e. like NSH interaction with any other Transport eh >>>>> issue of Fragmentation is to be dealt in a way that matches the >>>>> mechanisms supported by the Transport used and do not belong in the >>>>> NSH draft >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>> mohamed.boucadair@orange.com >>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>> To: Thomas Narten ; sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> R-, >>>>> >>>>> In addition to other pending issues raised for this draft, I would >>>>> like to raise this additional one about Section 6. >>>>> >>>>> == >>>>> 6. Fragmentation Considerations >>>>> >>>>> NSH and the associated transport header are "added" to the >>>>> encapsulated packet/frame. This additional information increases >> the >>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>> data, several options for handling fragmentation and re-assembly >>>>> exist: >>>>> >>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>> associated transport packets without requiring fragmentation. >>>>> >>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>> dynamically discovering the maximum transmission unit (MTU) of >> an >>>>> arbitrary internet path" and can be utilized to ensure the the >>>>> required packet size is used. >>>>> >>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >> assembly >>>>> in section 5.4. >>>>> == >>>>> >>>>> * The text is weak for a Standard track document that is intended to >>>>> solve the problem in https://tools.ietf.org/html/rfc7498#section-2.12. >>>>> There should be a clear behavior to be followed by an implementation. >>>>> Further, I would avoid the use of words such as "can". >>>>> >>>>> * The text covers only fragmentation when it is induced by SFC >>>>> operations, it does not discuss the treatment of a fragment when >>>>> received in an SFC domain. IMHO, the draft should also specify the >>>>> behavior of the Classifier with regards to fragments for the sake of >>>>> proper SFC operation. Applying classification policies may require the >>>> full packet, not only a fragment. >>>>> In particular, dedicated resources should dedicated for handling out >>>>> of order fragments. Of course, it is out of scope of this document to >>>>> describe how SFs handle fragments. >>>>> >>>>> * If an SFC header is prepended for all fragments, I'm not sure there >>>>> is any particular issue at the SFF level...except if stripping/adding >>>>> context TLVs depends on the full packet (not just fragment). It is >>>>> warranted to consider a little bit this point before declaring there >> is >>>> no issue. >>>>> >>>>> * The text states "several options". This may be interpreted as if >>>>> implementing one of them is sufficient...which is not true. The first >>>>> two points contribute to minimize the fragmentation risk, but >>>>> fragmentation may still be experienced (e.g., other shims are >>>>> prepended by other nodes for some other purposes, nested nsh, etc.) >>>>> >>>>> * The first two points have nothing to do with reassembly. >>>>> >>>>> * The support of jumbo frames by a router/device does not mean that it >>>>> can make use of it. Appropriate MTU configuration should be undertaken >>>>> in a consistent manner within an SFC domain. The text should be >>>>> updated to make it is about (consistent) MTU configuration. >>>>> >>>>> * BTW, shouldn't the text be reworded to recommended to increase the >>>>> MTU of **all nodes** of an SFC-enabled domain by at least the length >>>>> of SFC header + transport header? >>>>> >>>>> * Bullet 2, how PMTU discovery is actually used in this context? Do >>>>> you assume that all SFC-aware nodes will issue such messages towards >>>>> other SFC-aware node, arbitrary destination, else? >>>>> >>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>> internet path". >>>>> >>>>> * Bullet 2, s/ the the/the. >>>>> >>>>> * The reference to the LISP specification raises two concerns and one >>>>> comment: >>>>> >>>>> (1) I don't think it is a good approach that fragments induced by the >>>>> network are passed to their ultimate destinations as such (stateless). >>>>> IMO, reassembly should be done within the SFC domain (responsible for >>>>> fragmentation) not passed away. >>>>> (2) Does the stateful mode require all SFC data plane elements >>>>> maintain a full list of MTU for the any SFF/SF instance of the SFC >>>> domain? >>>>> >>>>> The current text suggests that [RFC6830] should be listed as normative >>>>> reference (not an informative one). I would personally favor removing >>>>> the reference to LISP (as it is an Experimental RFC). >>>>> >>>>> * The security section of the draft may be augmented with >>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>> (Protection Against a Variant of the Tiny Fragment Attack), and RFC >>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril 2016 13:14 À : >>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Dear Thomas, all, >>>>>> >>>>>> As I mentioned during the meeting, there are several issues that are >>>>>> not covered in the last version of the draft. I already provided >>>>>> examples of the issues offline as requested by Martin. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>> Envoyé : jeudi 31 mars 2016 04:48 À : sfc@ietf.org Objet : [sfc] >>>>>>> WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Dear WG: >>>>>>> >>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>> >>>>>>> The editors of the NSH document have indicated that they have >>>>>>> addressed all known comments and that there are no open issues >>>>>>> with the current version of the document. >>>>>>> >>>>>>> Substantive comments to the list please, editorial comments can go >>>>>>> directly to the document editors. >>>>>>> >>>>>>> We'll also get a brief update from the editors at next week's >>>>>>> meeting. If there are any remaining issues with the document, >>>>>>> raising them before the meeting would be especially helpful. >>>>>>> >>>>>>> For the chairs, >>>>>>> Thomas >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Mon Apr 25 07:27:01 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 67F6812D607 for ; Mon, 25 Apr 2016 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 FmVgoAgO6kau for ; Mon, 25 Apr 2016 07:26:47 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by ietfa.amsl.com (Postfix) with ESMTP id 994D012D600 for ; Mon, 25 Apr 2016 07:26:47 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 25 Apr 2016 07:26:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,533,1455004800"; d="scan'208";a="962266805" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga002.jf.intel.com with ESMTP; 25 Apr 2016 07:26:16 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.253]) by ORSMSX103.amr.corp.intel.com ([169.254.5.227]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 07:26:15 -0700 From: "Elzur, Uri" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQCYv/wVVMUagOUO32rRCGp+Er+AwgARg/TCAEFX48IABYBMA//+ZdQCAAHv92oAAfagA//+MZ0A= Date: Mon, 25 Apr 2016 14:26:15 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTExOTU3Y2YtMWQ1ZS00MzYxLTk3YzctMWJjNThiZTdjMjA5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlBOYlo0elJuRjdmTjBVdEh6TytJNHEwZ1Jja2tQNFRpRWkyNXBSNmdyNmc9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 14:27:00 -0000 Hi Med Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a transport, dealing with fragmentation is left to the Tran= sport used. The model I use for NSH, is basically similar to VXLAN . It is an overly.=20 Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Monday, April 25, 2016 7:18 AM To: Joel M. Halpern ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9=A0: lundi 25= =20 > avril 2016 15:48 =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet=A0= :=20 > Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > If I am understanding you correctly Med, you are asking that the NSH=20 > draft specify how service chaining should cope with packets that have=20 > been fragmented? >=20 [Med] To be accurate, I'm asking to assess whether there are implications. = If there are, then the draft should be updated accordingly. > NSH, and the SFF functionality, does not care. [Med] I'm not that sure. Some typical implications are listed below: * SFF: If the NSH header is present only in the a fragment but SFF didn't m= aintained a state, subsequent fragments won't be appropriately processed.=20 * SFC-aware function: if prepending a context information depends on the fu= ll packet, not only a fragment.=20 It just does its job. [Med] which may be disturbed in some situations as listed in the examples a= bove. > Ingress and intermediate classifiers may cope with fragments in any=20 > number of ways. Specifying such is clearly out of scope for this draft. [Med] The purpose is not to specify the internal implementation details but= the external behavior of the classifier function when it comes to handle f= ragments. That behavior may have an incidence on SFF, in particular. The pu= rpose is not to recommend the maximum resources to be dedicated to out of o= rder fragments nor the timeout to cache those; these considerations are of = course out of scope. Nevertheless, an implementation should offer a configu= rable parameter so that an operator tweak those according to its context. = =20 > I suppose one could write an informational draft on possible ways of=20 > coping. The IETF has not usually published such. > Service functions have to cope with fragmented packets just as they=20 > had to before the advent of NSH, so describing that is clearly not=20 > needed here. [Med] The advent of NSH has the following implications: * it exacerbates fragmentation. Handing over this issue to the transport la= yer may lead to interoperability issues.=20 * the chaining may not be efficient if fragments are inappropriately handle= d.=20 Introducing NSH should not degrade the overall service compared to legacy s= ervice deployment schemes. >=20 > Yours, > Joel >=20 > On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > I hear you, but my comment is that we need, as a WG, to decide what=20 > > to > put in the draft. FWIW, I'm discussing two fragmentation issues: > > > > (1) Fragmentation that is caused by prepending an SFC header. > > (2) Handling fragments at the ingress of an SFC-enabled domain. > > > > Increasing the MTU is for sure a recommendation is to be explicitly > called out in the text (see my first message). > > > > There are other issues that need to be discussed, e.g., how to deal=20 > > with > fragments in SFFs/Classifiers? > > > > It is also "prudent" to check that no issues will be experienced in=20 > > SFF > to handle fragments. If an SFC header is prepended for all fragments,=20 > I'm not sure there > > is any particular issue at the SFF level, except if stripping/adding > context TLVs depends on the full packet (not just fragment). It is=20 > warranted to consider a little bit this point before declaring there=20 > is no issue. > > > > For point (1), declaring fragmentation out of scope would be meant=20 > > that > an implementation must be prepared to receive fragments with or=20 > without NSH header as this is a decision that is left to the transport=20 > encapsulation. This is a requirement per se! > > > > I won't reiterate all the comments I have about the current wording=20 > > of > this section. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25=20 > >> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 > >> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 > >> draft-ietf-sfc-nsh-04.txt > >> > >> Hi Med > >> > >> My point is that Fragmentation is yet another transport related=20 > >> issue > that > >> is beyond the scope of NSH and beyond the charter of the WG, so it > doesn't > >> really belong in the draft. We are providing an advice as extending=20 > >> the size of the packet may lead to fragmentation, but as you check=20 > >> RFC 7348 VxLAN, which my create the same issue, you'll find it=20 > >> doesn't even > relate > >> to it. > >> > >> Thx > >> > >> Uri ("Oo-Ree") > >> C: 949-378-7568 > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > >> mohamed.boucadair@orange.com > >> Sent: Sunday, April 24, 2016 10:32 PM > >> To: Elzur, Uri ; Thomas Narten > ; > >> sfc@ietf.org > >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Hi Uri, > >> > >> That's another option that needs to be discussed/investigated. I'm > afraid > >> this is not the rationale adopted in -04 since it includes some=20 > >> text > that > >> is far to be sufficient to ensure interoperable implementations. > >> > >> BTW, saying that nsh does not need to deal with fragmentation=20 > >> because > it > >> is transport-independent is not IMHO a good strategy to adopt here > because > >> it opens the door for interoperable issues, it may lead to=20 > >> sub-optimal implementations if the sfc information is present only=20 > >> in one > fragments, > >> etc. > >> > >> My comments are related to the current text in the -04. This text=20 > >> needs > to > >> be fixed somehow. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24=20 > >>> avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 > >>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 > >>> draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Med > >>> > >>> I see no need to specify the exact behavior as NSH is transport=20 > >>> independent i.e. like NSH interaction with any other Transport eh=20 > >>> issue of Fragmentation is to be dealt in a way that matches the=20 > >>> mechanisms supported by the Transport used and do not belong in=20 > >>> the NSH draft > >>> > >>> Thx > >>> > >>> Uri ("Oo-Ree") > >>> C: 949-378-7568 > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > >>> mohamed.boucadair@orange.com > >>> Sent: Thursday, April 14, 2016 12:43 AM > >>> To: Thomas Narten ; sfc@ietf.org > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> R-, > >>> > >>> In addition to other pending issues raised for this draft, I would=20 > >>> like to raise this additional one about Section 6. > >>> > >>> =3D=3D > >>> 6. Fragmentation Considerations > >>> > >>> NSH and the associated transport header are "added" to the > >>> encapsulated packet/frame. This additional information=20 > >>> increases > the > >>> size of the packet. In order the ensure proper forwarding of NSH > >>> data, several options for handling fragmentation and re-assembly > >>> exist: > >>> > >>> 1. Jumbo Frames, when supported, enable the transport of NSH and > >>> associated transport packets without requiring fragmentation. > >>> > >>> 2. Path MTU Discovery [RFC1191]"describes a technique for > >>> dynamically discovering the maximum transmission unit (MTU)=20 > >>> of > an > >>> arbitrary internet path" and can be utilized to ensure the the > >>> required packet size is used. > >>> > >>> 3. [RFC6830] describes two schemes for fragmentation and re- > assembly > >>> in section 5.4. > >>> =3D=3D > >>> > >>> * The text is weak for a Standard track document that is intended=20 > >>> to solve the problem in https://tools.ietf.org/html/rfc7498#section-2= .12. > >>> There should be a clear behavior to be followed by an implementation. > >>> Further, I would avoid the use of words such as "can". > >>> > >>> * The text covers only fragmentation when it is induced by SFC=20 > >>> operations, it does not discuss the treatment of a fragment when=20 > >>> received in an SFC domain. IMHO, the draft should also specify the=20 > >>> behavior of the Classifier with regards to fragments for the sake=20 > >>> of proper SFC operation. Applying classification policies may=20 > >>> require the > >> full packet, not only a fragment. > >>> In particular, dedicated resources should dedicated for handling=20 > >>> out of order fragments. Of course, it is out of scope of this=20 > >>> document to describe how SFs handle fragments. > >>> > >>> * If an SFC header is prepended for all fragments, I'm not sure=20 > >>> there is any particular issue at the SFF level...except if=20 > >>> stripping/adding context TLVs depends on the full packet (not just=20 > >>> fragment). It is warranted to consider a little bit this point=20 > >>> before declaring there > is > >> no issue. > >>> > >>> * The text states "several options". This may be interpreted as if=20 > >>> implementing one of them is sufficient...which is not true. The=20 > >>> first two points contribute to minimize the fragmentation risk,=20 > >>> but fragmentation may still be experienced (e.g., other shims are=20 > >>> prepended by other nodes for some other purposes, nested nsh,=20 > >>> etc.) > >>> > >>> * The first two points have nothing to do with reassembly. > >>> > >>> * The support of jumbo frames by a router/device does not mean=20 > >>> that it can make use of it. Appropriate MTU configuration should=20 > >>> be undertaken in a consistent manner within an SFC domain. The=20 > >>> text should be updated to make it is about (consistent) MTU configura= tion. > >>> > >>> * BTW, shouldn't the text be reworded to recommended to increase=20 > >>> the MTU of **all nodes** of an SFC-enabled domain by at least the=20 > >>> length of SFC header + transport header? > >>> > >>> * Bullet 2, how PMTU discovery is actually used in this context?=20 > >>> Do you assume that all SFC-aware nodes will issue such messages=20 > >>> towards other SFC-aware node, arbitrary destination, else? > >>> > >>> * Bullet 2, I would drop "describes a technique for dynamically=20 > >>> discovering the maximum transmission unit (MTU) of an arbitrary=20 > >>> internet path". > >>> > >>> * Bullet 2, s/ the the/the. > >>> > >>> * The reference to the LISP specification raises two concerns and=20 > >>> one > >>> comment: > >>> > >>> (1) I don't think it is a good approach that fragments induced by=20 > >>> the network are passed to their ultimate destinations as such (statel= ess). > >>> IMO, reassembly should be done within the SFC domain (responsible=20 > >>> for > >>> fragmentation) not passed away. > >>> (2) Does the stateful mode require all SFC data plane elements=20 > >>> maintain a full list of MTU for the any SFF/SF instance of the SFC > >> domain? > >>> > >>> The current text suggests that [RFC6830] should be listed as=20 > >>> normative reference (not an informative one). I would personally=20 > >>> favor removing the reference to LISP (as it is an Experimental RFC). > >>> > >>> * The security section of the draft may be augmented with=20 > >>> informational fragmentation-related pointers to: e.g., RFC1858=20 > >>> (Security Considerations for IP Fragment Filtering), RFC3128=20 > >>> (Protection Against a Variant of the Tiny Fragment Attack), and=20 > >>> RFC > >>> 4963 (IPv4 Reassembly Errors at High Data Rates). > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de=20 > >>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : > >>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for=20 > >>>> draft-ietf-sfc-nsh-04.txt > >>>> > >>>> Dear Thomas, all, > >>>> > >>>> As I mentioned during the meeting, there are several issues that=20 > >>>> are not covered in the last version of the draft. I already=20 > >>>> provided examples of the issues offline as requested by Martin. > >>>> > >>>> Cheers, > >>>> Med > >>>> > >>>>> -----Message d'origine----- > >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas=20 > >>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org Objet= =20 > >>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>> > >>>>> Dear WG: > >>>>> > >>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 > >>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>> > >>>>> The editors of the NSH document have indicated that they have=20 > >>>>> addressed all known comments and that there are no open issues=20 > >>>>> with the current version of the document. > >>>>> > >>>>> Substantive comments to the list please, editorial comments can=20 > >>>>> go directly to the document editors. > >>>>> > >>>>> We'll also get a brief update from the editors at next week's=20 > >>>>> meeting. If there are any remaining issues with the document,=20 > >>>>> raising them before the meeting would be especially helpful. > >>>>> > >>>>> For the chairs, > >>>>> Thomas > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > 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 Mon Apr 25 07:40:34 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 40B4A12D600 for ; Mon, 25 Apr 2016 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 AH-nEgjn-ROu for ; Mon, 25 Apr 2016 07:40:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9459112D156 for ; Mon, 25 Apr 2016 07:40:29 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 396872DC2EE; Mon, 25 Apr 2016 16:40:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BF62F27C066; Mon, 25 Apr 2016 16:40:27 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0279.002; Mon, 25 Apr 2016 16:40:27 +0200 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRnv5RcgW3qL7FtUSw06t+AZg8jp+awCng Date: Mon, 25 Apr 2016 14:40:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5F58B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4e4601b5-1315-9869-5437-71816be627df@joelhalpern.com> In-Reply-To: <4e4601b5-1315-9869-5437-71816be627df@joelhalpern.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 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 14:40:33 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: lundi 25 avril 2016 16:25 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > There are two different issues. > There is the question of what happens if adding the NSH header causes > fragmentation. I believe that is dealt with sufficiently. It is in > scope for the document. [Med] Glad to see that we both agree that this is in scope. Unlike you, the= current text needs more work IMHO (please refer to may detailed comments o= n this part). >=20 > The other issue is what happens if a packet is fragmented before it > arrives at SFC. the classifier can play any games it likes, but all of > the packets it emits will end up getting NSH encapsulated. [Med] We fully agree here. This is a what I called "the external behavior o= f the classifier function when it comes to handle fragments" in my reply to= you. This should be cited as such in the specification.=20 The > mechanism for doing that depends upon how the classifier works, and how > the implementation couples the classifier to the encapsulator (which is > internal and not subject ot standardization.) [Med] We are fully inline. That's why I said in my answer "The purpose is n= ot to specify the internal implementation details". =20 >=20 > So I do not see the disturbances you refer to. [Med] If you don't have NSH encapsulation for all fragments, then disturban= ces will be experienced. >=20 > Yours, > Joel >=20 > On 4/25/16 10:18 AM, mohamed.boucadair@orange.com wrote: > > Hi Joel, > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Envoy=E9 : lundi 25 avril 2016 15:48 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > >> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> If I am understanding you correctly Med, you are asking that the NSH > >> draft specify how service chaining should cope with packets that have > >> been fragmented? > >> > > > > [Med] To be accurate, I'm asking to assess whether there are > implications. If there are, then the draft should be updated accordingly. > > > >> NSH, and the SFF functionality, does not care. > > > > [Med] I'm not that sure. Some typical implications are listed below: > > > > * SFF: If the NSH header is present only in the a fragment but SFF > didn't maintained a state, subsequent fragments won't be appropriately > processed. > > * SFC-aware function: if prepending a context information depends on th= e > full packet, not only a fragment. > > > > It just does its job. > > > > [Med] which may be disturbed in some situations as listed in the > examples above. > > > >> Ingress and intermediate classifiers may cope with fragments in any > >> number of ways. > > Specifying such is clearly out of scope for this draft. > > > > [Med] The purpose is not to specify the internal implementation details > but the external behavior of the classifier function when it comes to > handle fragments. That behavior may have an incidence on SFF, in > particular. The purpose is not to recommend the maximum resources to be > dedicated to out of order fragments nor the timeout to cache those; these > considerations are of course out of scope. Nevertheless, an implementatio= n > should offer a configurable parameter so that an operator tweak those > according to its context. > > > >> I suppose one could write an informational draft on possible ways of > >> coping. The IETF has not usually published such. > >> Service functions have to cope with fragmented packets just as they ha= d > >> to before the advent of NSH, so describing that is clearly not needed > >> here. > > > > [Med] The advent of NSH has the following implications: > > * it exacerbates fragmentation. Handing over this issue to the transpor= t > layer may lead to interoperability issues. > > * the chaining may not be efficient if fragments are inappropriately > handled. > > > > Introducing NSH should not degrade the overall service compared to > legacy service deployment schemes. > > > >> > >> Yours, > >> Joel > >> > >> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > >>> Re-, > >>> > >>> I hear you, but my comment is that we need, as a WG, to decide what t= o > >> put in the draft. FWIW, I'm discussing two fragmentation issues: > >>> > >>> (1) Fragmentation that is caused by prepending an SFC header. > >>> (2) Handling fragments at the ingress of an SFC-enabled domain. > >>> > >>> Increasing the MTU is for sure a recommendation is to be explicitly > >> called out in the text (see my first message). > >>> > >>> There are other issues that need to be discussed, e.g., how to deal > with > >> fragments in SFFs/Classifiers? > >>> > >>> It is also "prudent" to check that no issues will be experienced in > SFF > >> to handle fragments. If an SFC header is prepended for all fragments, > I'm > >> not sure there > >>> is any particular issue at the SFF level, except if stripping/adding > >> context TLVs depends on the full packet (not just fragment). It is > >> warranted to consider a little bit this point before declaring there i= s > no > >> issue. > >>> > >>> For point (1), declaring fragmentation out of scope would be meant > that > >> an implementation must be prepared to receive fragments with or withou= t > >> NSH header as this is a decision that is left to the transport > >> encapsulation. This is a requirement per se! > >>> > >>> I won't reiterate all the comments I have about the current wording o= f > >> this section. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] > >>>> Envoy=E9 : lundi 25 avril 2016 08:30 > >>>> =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > >>>> Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> Hi Med > >>>> > >>>> My point is that Fragmentation is yet another transport related issu= e > >> that > >>>> is beyond the scope of NSH and beyond the charter of the WG, so it > >> doesn't > >>>> really belong in the draft. We are providing an advice as extending > the > >>>> size of the packet may lead to fragmentation, but as you check RFC > 7348 > >>>> VxLAN, which my create the same issue, you'll find it doesn't even > >> relate > >>>> to it. > >>>> > >>>> Thx > >>>> > >>>> Uri ("Oo-Ree") > >>>> C: 949-378-7568 > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>> mohamed.boucadair@orange.com > >>>> Sent: Sunday, April 24, 2016 10:32 PM > >>>> To: Elzur, Uri ; Thomas Narten > >> ; > >>>> sfc@ietf.org > >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> Hi Uri, > >>>> > >>>> That's another option that needs to be discussed/investigated. I'm > >> afraid > >>>> this is not the rationale adopted in -04 since it includes some text > >> that > >>>> is far to be sufficient to ensure interoperable implementations. > >>>> > >>>> BTW, saying that nsh does not need to deal with fragmentation becaus= e > >> it > >>>> is transport-independent is not IMHO a good strategy to adopt here > >> because > >>>> it opens the door for interoperable issues, it may lead to sub- > optimal > >>>> implementations if the sfc information is present only in one > >> fragments, > >>>> etc. > >>>> > >>>> My comments are related to the current text in the -04. This text > needs > >> to > >>>> be fixed somehow. > >>>> > >>>> Cheers, > >>>> Med > >>>> > >>>>> -----Message d'origine----- > >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 > >>>>> avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>>>> draft-ietf-sfc-nsh-04.txt > >>>>> > >>>>> Hi Med > >>>>> > >>>>> I see no need to specify the exact behavior as NSH is transport > >>>>> independent i.e. like NSH interaction with any other Transport eh > >>>>> issue of Fragmentation is to be dealt in a way that matches the > >>>>> mechanisms supported by the Transport used and do not belong in the > >>>>> NSH draft > >>>>> > >>>>> Thx > >>>>> > >>>>> Uri ("Oo-Ree") > >>>>> C: 949-378-7568 > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>> mohamed.boucadair@orange.com > >>>>> Sent: Thursday, April 14, 2016 12:43 AM > >>>>> To: Thomas Narten ; sfc@ietf.org > >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>> > >>>>> R-, > >>>>> > >>>>> In addition to other pending issues raised for this draft, I would > >>>>> like to raise this additional one about Section 6. > >>>>> > >>>>> =3D=3D > >>>>> 6. Fragmentation Considerations > >>>>> > >>>>> NSH and the associated transport header are "added" to the > >>>>> encapsulated packet/frame. This additional information increase= s > >> the > >>>>> size of the packet. In order the ensure proper forwarding of NS= H > >>>>> data, several options for handling fragmentation and re-assembly > >>>>> exist: > >>>>> > >>>>> 1. Jumbo Frames, when supported, enable the transport of NSH an= d > >>>>> associated transport packets without requiring fragmentation= . > >>>>> > >>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for > >>>>> dynamically discovering the maximum transmission unit (MTU) > of > >> an > >>>>> arbitrary internet path" and can be utilized to ensure the > the > >>>>> required packet size is used. > >>>>> > >>>>> 3. [RFC6830] describes two schemes for fragmentation and re- > >> assembly > >>>>> in section 5.4. > >>>>> =3D=3D > >>>>> > >>>>> * The text is weak for a Standard track document that is intended t= o > >>>>> solve the problem in https://tools.ietf.org/html/rfc7498#section- > 2.12. > >>>>> There should be a clear behavior to be followed by an > implementation. > >>>>> Further, I would avoid the use of words such as "can". > >>>>> > >>>>> * The text covers only fragmentation when it is induced by SFC > >>>>> operations, it does not discuss the treatment of a fragment when > >>>>> received in an SFC domain. IMHO, the draft should also specify the > >>>>> behavior of the Classifier with regards to fragments for the sake o= f > >>>>> proper SFC operation. Applying classification policies may require > the > >>>> full packet, not only a fragment. > >>>>> In particular, dedicated resources should dedicated for handling ou= t > >>>>> of order fragments. Of course, it is out of scope of this document > to > >>>>> describe how SFs handle fragments. > >>>>> > >>>>> * If an SFC header is prepended for all fragments, I'm not sure > there > >>>>> is any particular issue at the SFF level...except if > stripping/adding > >>>>> context TLVs depends on the full packet (not just fragment). It is > >>>>> warranted to consider a little bit this point before declaring ther= e > >> is > >>>> no issue. > >>>>> > >>>>> * The text states "several options". This may be interpreted as if > >>>>> implementing one of them is sufficient...which is not true. The > first > >>>>> two points contribute to minimize the fragmentation risk, but > >>>>> fragmentation may still be experienced (e.g., other shims are > >>>>> prepended by other nodes for some other purposes, nested nsh, etc.) > >>>>> > >>>>> * The first two points have nothing to do with reassembly. > >>>>> > >>>>> * The support of jumbo frames by a router/device does not mean that > it > >>>>> can make use of it. Appropriate MTU configuration should be > undertaken > >>>>> in a consistent manner within an SFC domain. The text should be > >>>>> updated to make it is about (consistent) MTU configuration. > >>>>> > >>>>> * BTW, shouldn't the text be reworded to recommended to increase th= e > >>>>> MTU of **all nodes** of an SFC-enabled domain by at least the lengt= h > >>>>> of SFC header + transport header? > >>>>> > >>>>> * Bullet 2, how PMTU discovery is actually used in this context? Do > >>>>> you assume that all SFC-aware nodes will issue such messages toward= s > >>>>> other SFC-aware node, arbitrary destination, else? > >>>>> > >>>>> * Bullet 2, I would drop "describes a technique for dynamically > >>>>> discovering the maximum transmission unit (MTU) of an arbitrary > >>>>> internet path". > >>>>> > >>>>> * Bullet 2, s/ the the/the. > >>>>> > >>>>> * The reference to the LISP specification raises two concerns and > one > >>>>> comment: > >>>>> > >>>>> (1) I don't think it is a good approach that fragments induced by > the > >>>>> network are passed to their ultimate destinations as such > (stateless). > >>>>> IMO, reassembly should be done within the SFC domain (responsible > for > >>>>> fragmentation) not passed away. > >>>>> (2) Does the stateful mode require all SFC data plane elements > >>>>> maintain a full list of MTU for the any SFF/SF instance of the SFC > >>>> domain? > >>>>> > >>>>> The current text suggests that [RFC6830] should be listed as > normative > >>>>> reference (not an informative one). I would personally favor > removing > >>>>> the reference to LISP (as it is an Experimental RFC). > >>>>> > >>>>> * The security section of the draft may be augmented with > >>>>> informational fragmentation-related pointers to: e.g., RFC1858 > >>>>> (Security Considerations for IP Fragment Filtering), RFC3128 > >>>>> (Protection Against a Variant of the Tiny Fragment Attack), and RFC > >>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). > >>>>> > >>>>> Cheers, > >>>>> Med > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de > >>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : > >>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for > >>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Dear Thomas, all, > >>>>>> > >>>>>> As I mentioned during the meeting, there are several issues that > are > >>>>>> not covered in the last version of the draft. I already provided > >>>>>> examples of the issues offline as requested by Martin. > >>>>>> > >>>>>> Cheers, > >>>>>> Med > >>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas Narte= n > >>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org Objet : [s= fc] > >>>>>>> WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> Dear WG: > >>>>>>> > >>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > >>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>>>> > >>>>>>> The editors of the NSH document have indicated that they have > >>>>>>> addressed all known comments and that there are no open issues > >>>>>>> with the current version of the document. > >>>>>>> > >>>>>>> Substantive comments to the list please, editorial comments can g= o > >>>>>>> directly to the document editors. > >>>>>>> > >>>>>>> We'll also get a brief update from the editors at next week's > >>>>>>> meeting. If there are any remaining issues with the document, > >>>>>>> raising them before the meeting would be especially helpful. > >>>>>>> > >>>>>>> For the chairs, > >>>>>>> Thomas > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> sfc mailing list > >>>>>>> sfc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > From nobody Mon Apr 25 07:42:01 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 8952612D156 for ; Mon, 25 Apr 2016 07:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 kfqUIxDLcrPW for ; Mon, 25 Apr 2016 07:41:57 -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 7D77812D60D for ; Mon, 25 Apr 2016 07:41:56 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 29DDCC0130; Mon, 25 Apr 2016 16:41:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id F1BFB1A0073; Mon, 25 Apr 2016 16:41:54 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Mon, 25 Apr 2016 16:41:54 +0200 From: To: "Elzur, Uri" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQCYv/wVVMUagOUO32rRCGp+Er+AwgARg/TCAEFX48IABYBMA//+ZdQCAAHv92oAAfagA//+MZ0CAAASSoA== Date: Mon, 25 Apr 2016 14:41:54 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.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: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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: Mon, 25 Apr 2016 14:41:59 -0000 Re-, How do you instruct the transport layer to ALWAYS prepend an NSH header eve= n for fragments? Or you don't care about that? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Elzur, Uri [mailto:uri.elzur@intel.com] > Envoy=E9=A0: lundi 25 avril 2016 16:26 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org > Objet=A0: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > Not to repeat my position, but I'll do it anyhow :-) > As NSH is *NOT* a transport, dealing with fragmentation is left to the > Transport used. >=20 > The model I use for NSH, is basically similar to VXLAN . It is an overly. >=20 > Thx >=20 > Uri ("Oo-Ree") > C: 949-378-7568 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 7:18 AM > To: Joel M. Halpern ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Joel, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9=A0: lundi = 25 > > avril 2016 15:48 =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet= =A0: > > Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > If I am understanding you correctly Med, you are asking that the NSH > > draft specify how service chaining should cope with packets that have > > been fragmented? > > >=20 > [Med] To be accurate, I'm asking to assess whether there are implications= . > If there are, then the draft should be updated accordingly. >=20 > > NSH, and the SFF functionality, does not care. >=20 > [Med] I'm not that sure. Some typical implications are listed below: >=20 > * SFF: If the NSH header is present only in the a fragment but SFF didn't > maintained a state, subsequent fragments won't be appropriately processed= . > * SFC-aware function: if prepending a context information depends on the > full packet, not only a fragment. >=20 > It just does its job. >=20 > [Med] which may be disturbed in some situations as listed in the examples > above. >=20 > > Ingress and intermediate classifiers may cope with fragments in any > > number of ways. > Specifying such is clearly out of scope for this draft. >=20 > [Med] The purpose is not to specify the internal implementation details > but the external behavior of the classifier function when it comes to > handle fragments. That behavior may have an incidence on SFF, in > particular. The purpose is not to recommend the maximum resources to be > dedicated to out of order fragments nor the timeout to cache those; these > considerations are of course out of scope. Nevertheless, an implementatio= n > should offer a configurable parameter so that an operator tweak those > according to its context. >=20 > > I suppose one could write an informational draft on possible ways of > > coping. The IETF has not usually published such. > > Service functions have to cope with fragmented packets just as they > > had to before the advent of NSH, so describing that is clearly not > > needed here. >=20 > [Med] The advent of NSH has the following implications: > * it exacerbates fragmentation. Handing over this issue to the transport > layer may lead to interoperability issues. > * the chaining may not be efficient if fragments are inappropriately > handled. >=20 > Introducing NSH should not degrade the overall service compared to legacy > service deployment schemes. >=20 > > > > Yours, > > Joel > > > > On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > > > Re-, > > > > > > I hear you, but my comment is that we need, as a WG, to decide what > > > to > > put in the draft. FWIW, I'm discussing two fragmentation issues: > > > > > > (1) Fragmentation that is caused by prepending an SFC header. > > > (2) Handling fragments at the ingress of an SFC-enabled domain. > > > > > > Increasing the MTU is for sure a recommendation is to be explicitly > > called out in the text (see my first message). > > > > > > There are other issues that need to be discussed, e.g., how to deal > > > with > > fragments in SFFs/Classifiers? > > > > > > It is also "prudent" to check that no issues will be experienced in > > > SFF > > to handle fragments. If an SFC header is prepended for all fragments, > > I'm not sure there > > > is any particular issue at the SFF level, except if stripping/adding > > context TLVs depends on the full packet (not just fragment). It is > > warranted to consider a little bit this point before declaring there > > is no issue. > > > > > > For point (1), declaring fragmentation out of scope would be meant > > > that > > an implementation must be prepared to receive fragments with or > > without NSH header as this is a decision that is left to the transport > > encapsulation. This is a requirement per se! > > > > > > I won't reiterate all the comments I have about the current wording > > > of > > this section. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 > > >> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > > >> sfc@ietf.org Objet : RE: [sfc] WG last call for > > >> draft-ietf-sfc-nsh-04.txt > > >> > > >> Hi Med > > >> > > >> My point is that Fragmentation is yet another transport related > > >> issue > > that > > >> is beyond the scope of NSH and beyond the charter of the WG, so it > > doesn't > > >> really belong in the draft. We are providing an advice as extending > > >> the size of the packet may lead to fragmentation, but as you check > > >> RFC 7348 VxLAN, which my create the same issue, you'll find it > > >> doesn't even > > relate > > >> to it. > > >> > > >> Thx > > >> > > >> Uri ("Oo-Ree") > > >> C: 949-378-7568 > > >> > > >> > > >> -----Original Message----- > > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > >> mohamed.boucadair@orange.com > > >> Sent: Sunday, April 24, 2016 10:32 PM > > >> To: Elzur, Uri ; Thomas Narten > > ; > > >> sfc@ietf.org > > >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > >> > > >> Hi Uri, > > >> > > >> That's another option that needs to be discussed/investigated. I'm > > afraid > > >> this is not the rationale adopted in -04 since it includes some > > >> text > > that > > >> is far to be sufficient to ensure interoperable implementations. > > >> > > >> BTW, saying that nsh does not need to deal with fragmentation > > >> because > > it > > >> is transport-independent is not IMHO a good strategy to adopt here > > because > > >> it opens the door for interoperable issues, it may lead to > > >> sub-optimal implementations if the sfc information is present only > > >> in one > > fragments, > > >> etc. > > >> > > >> My comments are related to the current text in the -04. This text > > >> needs > > to > > >> be fixed somehow. > > >> > > >> Cheers, > > >> Med > > >> > > >>> -----Message d'origine----- > > >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 > > >>> avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > > >>> sfc@ietf.org Objet : RE: [sfc] WG last call for > > >>> draft-ietf-sfc-nsh-04.txt > > >>> > > >>> Hi Med > > >>> > > >>> I see no need to specify the exact behavior as NSH is transport > > >>> independent i.e. like NSH interaction with any other Transport eh > > >>> issue of Fragmentation is to be dealt in a way that matches the > > >>> mechanisms supported by the Transport used and do not belong in > > >>> the NSH draft > > >>> > > >>> Thx > > >>> > > >>> Uri ("Oo-Ree") > > >>> C: 949-378-7568 > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > >>> mohamed.boucadair@orange.com > > >>> Sent: Thursday, April 14, 2016 12:43 AM > > >>> To: Thomas Narten ; sfc@ietf.org > > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > >>> > > >>> R-, > > >>> > > >>> In addition to other pending issues raised for this draft, I would > > >>> like to raise this additional one about Section 6. > > >>> > > >>> =3D=3D > > >>> 6. Fragmentation Considerations > > >>> > > >>> NSH and the associated transport header are "added" to the > > >>> encapsulated packet/frame. This additional information > > >>> increases > > the > > >>> size of the packet. In order the ensure proper forwarding of NS= H > > >>> data, several options for handling fragmentation and re-assembly > > >>> exist: > > >>> > > >>> 1. Jumbo Frames, when supported, enable the transport of NSH an= d > > >>> associated transport packets without requiring fragmentation= . > > >>> > > >>> 2. Path MTU Discovery [RFC1191]"describes a technique for > > >>> dynamically discovering the maximum transmission unit (MTU) > > >>> of > > an > > >>> arbitrary internet path" and can be utilized to ensure the > the > > >>> required packet size is used. > > >>> > > >>> 3. [RFC6830] describes two schemes for fragmentation and re- > > assembly > > >>> in section 5.4. > > >>> =3D=3D > > >>> > > >>> * The text is weak for a Standard track document that is intended > > >>> to solve the problem in https://tools.ietf.org/html/rfc7498#section= - > 2.12. > > >>> There should be a clear behavior to be followed by an > implementation. > > >>> Further, I would avoid the use of words such as "can". > > >>> > > >>> * The text covers only fragmentation when it is induced by SFC > > >>> operations, it does not discuss the treatment of a fragment when > > >>> received in an SFC domain. IMHO, the draft should also specify the > > >>> behavior of the Classifier with regards to fragments for the sake > > >>> of proper SFC operation. Applying classification policies may > > >>> require the > > >> full packet, not only a fragment. > > >>> In particular, dedicated resources should dedicated for handling > > >>> out of order fragments. Of course, it is out of scope of this > > >>> document to describe how SFs handle fragments. > > >>> > > >>> * If an SFC header is prepended for all fragments, I'm not sure > > >>> there is any particular issue at the SFF level...except if > > >>> stripping/adding context TLVs depends on the full packet (not just > > >>> fragment). It is warranted to consider a little bit this point > > >>> before declaring there > > is > > >> no issue. > > >>> > > >>> * The text states "several options". This may be interpreted as if > > >>> implementing one of them is sufficient...which is not true. The > > >>> first two points contribute to minimize the fragmentation risk, > > >>> but fragmentation may still be experienced (e.g., other shims are > > >>> prepended by other nodes for some other purposes, nested nsh, > > >>> etc.) > > >>> > > >>> * The first two points have nothing to do with reassembly. > > >>> > > >>> * The support of jumbo frames by a router/device does not mean > > >>> that it can make use of it. Appropriate MTU configuration should > > >>> be undertaken in a consistent manner within an SFC domain. The > > >>> text should be updated to make it is about (consistent) MTU > configuration. > > >>> > > >>> * BTW, shouldn't the text be reworded to recommended to increase > > >>> the MTU of **all nodes** of an SFC-enabled domain by at least the > > >>> length of SFC header + transport header? > > >>> > > >>> * Bullet 2, how PMTU discovery is actually used in this context? > > >>> Do you assume that all SFC-aware nodes will issue such messages > > >>> towards other SFC-aware node, arbitrary destination, else? > > >>> > > >>> * Bullet 2, I would drop "describes a technique for dynamically > > >>> discovering the maximum transmission unit (MTU) of an arbitrary > > >>> internet path". > > >>> > > >>> * Bullet 2, s/ the the/the. > > >>> > > >>> * The reference to the LISP specification raises two concerns and > > >>> one > > >>> comment: > > >>> > > >>> (1) I don't think it is a good approach that fragments induced by > > >>> the network are passed to their ultimate destinations as such > (stateless). > > >>> IMO, reassembly should be done within the SFC domain (responsible > > >>> for > > >>> fragmentation) not passed away. > > >>> (2) Does the stateful mode require all SFC data plane elements > > >>> maintain a full list of MTU for the any SFF/SF instance of the SFC > > >> domain? > > >>> > > >>> The current text suggests that [RFC6830] should be listed as > > >>> normative reference (not an informative one). I would personally > > >>> favor removing the reference to LISP (as it is an Experimental RFC)= . > > >>> > > >>> * The security section of the draft may be augmented with > > >>> informational fragmentation-related pointers to: e.g., RFC1858 > > >>> (Security Considerations for IP Fragment Filtering), RFC3128 > > >>> (Protection Against a Variant of the Tiny Fragment Attack), and > > >>> RFC > > >>> 4963 (IPv4 Reassembly Errors at High Data Rates). > > >>> > > >>> Cheers, > > >>> Med > > >>> > > >>>> -----Message d'origine----- > > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de > > >>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : > > >>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for > > >>>> draft-ietf-sfc-nsh-04.txt > > >>>> > > >>>> Dear Thomas, all, > > >>>> > > >>>> As I mentioned during the meeting, there are several issues that > > >>>> are not covered in the last version of the draft. I already > > >>>> provided examples of the issues offline as requested by Martin. > > >>>> > > >>>> Cheers, > > >>>> Med > > >>>> > > >>>>> -----Message d'origine----- > > >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas > > >>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org Obj= et > > >>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > >>>>> > > >>>>> Dear WG: > > >>>>> > > >>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > > >>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > >>>>> > > >>>>> The editors of the NSH document have indicated that they have > > >>>>> addressed all known comments and that there are no open issues > > >>>>> with the current version of the document. > > >>>>> > > >>>>> Substantive comments to the list please, editorial comments can > > >>>>> go directly to the document editors. > > >>>>> > > >>>>> We'll also get a brief update from the editors at next week's > > >>>>> meeting. If there are any remaining issues with the document, > > >>>>> raising them before the meeting would be especially helpful. > > >>>>> > > >>>>> For the chairs, > > >>>>> Thomas > > >>>>> > > >>>>> _______________________________________________ > > >>>>> sfc mailing list > > >>>>> sfc@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>> > > >>>> _______________________________________________ > > >>>> sfc mailing list > > >>>> sfc@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc > > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 26 08:10:16 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 48CBB12D1E7 for ; Tue, 26 Apr 2016 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 kB3KPx38MMVU for ; Tue, 26 Apr 2016 08:10:11 -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 1981B12D1E6 for ; Tue, 26 Apr 2016 08:10:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIN58586; Tue, 26 Apr 2016 15:10:07 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 16:10:05 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 08:10:02 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "Elzur, Uri" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQIp3nrjaS0+VjDL7mlh8GJ+Er+AwgARg/TCAEFX48IABYBMAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAEik2A= Date: Tue, 26 Apr 2016 15:10:02 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.571F84D0.001E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f00e12aefba01234b913f67e0c7526fe Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 15:10:15 -0000 Agree with Med. =20 Even if each fragment piece of a packet with NSH header carries the NSH hea= der, the intermediate SFF nodes still need to put together all the fragment= s together before passing the whole data frame to the SF. Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Monday, April 25, 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-, How do you instruct the transport layer to ALWAYS prepend an NSH header eve= n for fragments? Or you don't care about that? Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9=A0: lundi 25 avri= l=20 > 2016 16:26 =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;=20 > sfc@ietf.org Objet=A0: RE: [sfc] WG last call for=20 > draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a=20 > transport, dealing with fragmentation is left to the Transport used. >=20 > The model I use for NSH, is basically similar to VXLAN . It is an overly. >=20 > Thx >=20 > Uri ("Oo-Ree") > C: 949-378-7568 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 7:18 AM > To: Joel M. Halpern ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Joel, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9=A0: lundi = 25=20 > > avril 2016 15:48 =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet= =A0: > > Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > If I am understanding you correctly Med, you are asking that the NSH=20 > > draft specify how service chaining should cope with packets that=20 > > have been fragmented? > > >=20 > [Med] To be accurate, I'm asking to assess whether there are implications= . > If there are, then the draft should be updated accordingly. >=20 > > NSH, and the SFF functionality, does not care. >=20 > [Med] I'm not that sure. Some typical implications are listed below: >=20 > * SFF: If the NSH header is present only in the a fragment but SFF=20 > didn't maintained a state, subsequent fragments won't be appropriately pr= ocessed. > * SFC-aware function: if prepending a context information depends on=20 > the full packet, not only a fragment. >=20 > It just does its job. >=20 > [Med] which may be disturbed in some situations as listed in the=20 > examples above. >=20 > > Ingress and intermediate classifiers may cope with fragments in any=20 > > number of ways. > Specifying such is clearly out of scope for this draft. >=20 > [Med] The purpose is not to specify the internal implementation=20 > details but the external behavior of the classifier function when it=20 > comes to handle fragments. That behavior may have an incidence on SFF,=20 > in particular. The purpose is not to recommend the maximum resources=20 > to be dedicated to out of order fragments nor the timeout to cache=20 > those; these considerations are of course out of scope. Nevertheless,=20 > an implementation should offer a configurable parameter so that an=20 > operator tweak those according to its context. >=20 > > I suppose one could write an informational draft on possible ways=20 > > of coping. The IETF has not usually published such. > > Service functions have to cope with fragmented packets just as they=20 > > had to before the advent of NSH, so describing that is clearly not=20 > > needed here. >=20 > [Med] The advent of NSH has the following implications: > * it exacerbates fragmentation. Handing over this issue to the=20 > transport layer may lead to interoperability issues. > * the chaining may not be efficient if fragments are inappropriately=20 > handled. >=20 > Introducing NSH should not degrade the overall service compared to=20 > legacy service deployment schemes. >=20 > > > > Yours, > > Joel > > > > On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > > > Re-, > > > > > > I hear you, but my comment is that we need, as a WG, to decide=20 > > > what to > > put in the draft. FWIW, I'm discussing two fragmentation issues: > > > > > > (1) Fragmentation that is caused by prepending an SFC header. > > > (2) Handling fragments at the ingress of an SFC-enabled domain. > > > > > > Increasing the MTU is for sure a recommendation is to be=20 > > > explicitly > > called out in the text (see my first message). > > > > > > There are other issues that need to be discussed, e.g., how to=20 > > > deal with > > fragments in SFFs/Classifiers? > > > > > > It is also "prudent" to check that no issues will be experienced=20 > > > in SFF > > to handle fragments. If an SFC header is prepended for all=20 > > fragments, I'm not sure there > > > is any particular issue at the SFF level, except if=20 > > > stripping/adding > > context TLVs depends on the full packet (not just fragment). It is=20 > > warranted to consider a little bit this point before declaring there=20 > > is no issue. > > > > > > For point (1), declaring fragmentation out of scope would be meant=20 > > > that > > an implementation must be prepared to receive fragments with or=20 > > without NSH header as this is a decision that is left to the=20 > > transport encapsulation. This is a requirement per se! > > > > > > I won't reiterate all the comments I have about the current=20 > > > wording of > > this section. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25=20 > > >> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 > > >> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 > > >> draft-ietf-sfc-nsh-04.txt > > >> > > >> Hi Med > > >> > > >> My point is that Fragmentation is yet another transport related=20 > > >> issue > > that > > >> is beyond the scope of NSH and beyond the charter of the WG, so=20 > > >> it > > doesn't > > >> really belong in the draft. We are providing an advice as=20 > > >> extending the size of the packet may lead to fragmentation, but=20 > > >> as you check RFC 7348 VxLAN, which my create the same issue,=20 > > >> you'll find it doesn't even > > relate > > >> to it. > > >> > > >> Thx > > >> > > >> Uri ("Oo-Ree") > > >> C: 949-378-7568 > > >> > > >> > > >> -----Original Message----- > > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > > >> mohamed.boucadair@orange.com > > >> Sent: Sunday, April 24, 2016 10:32 PM > > >> To: Elzur, Uri ; Thomas Narten > > ; > > >> sfc@ietf.org > > >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > >> > > >> Hi Uri, > > >> > > >> That's another option that needs to be discussed/investigated.=20 > > >> I'm > > afraid > > >> this is not the rationale adopted in -04 since it includes some=20 > > >> text > > that > > >> is far to be sufficient to ensure interoperable implementations. > > >> > > >> BTW, saying that nsh does not need to deal with fragmentation=20 > > >> because > > it > > >> is transport-independent is not IMHO a good strategy to adopt=20 > > >> here > > because > > >> it opens the door for interoperable issues, it may lead to=20 > > >> sub-optimal implementations if the sfc information is present=20 > > >> only in one > > fragments, > > >> etc. > > >> > > >> My comments are related to the current text in the -04. This text=20 > > >> needs > > to > > >> be fixed somehow. > > >> > > >> Cheers, > > >> Med > > >> > > >>> -----Message d'origine----- > > >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche=20 > > >>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas=20 > > >>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for=20 > > >>> draft-ietf-sfc-nsh-04.txt > > >>> > > >>> Hi Med > > >>> > > >>> I see no need to specify the exact behavior as NSH is transport=20 > > >>> independent i.e. like NSH interaction with any other Transport=20 > > >>> eh issue of Fragmentation is to be dealt in a way that matches=20 > > >>> the mechanisms supported by the Transport used and do not belong=20 > > >>> in the NSH draft > > >>> > > >>> Thx > > >>> > > >>> Uri ("Oo-Ree") > > >>> C: 949-378-7568 > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > > >>> mohamed.boucadair@orange.com > > >>> Sent: Thursday, April 14, 2016 12:43 AM > > >>> To: Thomas Narten ; sfc@ietf.org > > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > >>> > > >>> R-, > > >>> > > >>> In addition to other pending issues raised for this draft, I=20 > > >>> would like to raise this additional one about Section 6. > > >>> > > >>> =3D=3D > > >>> 6. Fragmentation Considerations > > >>> > > >>> NSH and the associated transport header are "added" to the > > >>> encapsulated packet/frame. This additional information=20 > > >>> increases > > the > > >>> size of the packet. In order the ensure proper forwarding of NS= H > > >>> data, several options for handling fragmentation and re-assembly > > >>> exist: > > >>> > > >>> 1. Jumbo Frames, when supported, enable the transport of NSH an= d > > >>> associated transport packets without requiring fragmentation= . > > >>> > > >>> 2. Path MTU Discovery [RFC1191]"describes a technique for > > >>> dynamically discovering the maximum transmission unit=20 > > >>> (MTU) of > > an > > >>> arbitrary internet path" and can be utilized to ensure=20 > > >>> the > the > > >>> required packet size is used. > > >>> > > >>> 3. [RFC6830] describes two schemes for fragmentation and re- > > assembly > > >>> in section 5.4. > > >>> =3D=3D > > >>> > > >>> * The text is weak for a Standard track document that is=20 > > >>> intended to solve the problem in=20 > > >>> https://tools.ietf.org/html/rfc7498#section- > 2.12. > > >>> There should be a clear behavior to be followed by an > implementation. > > >>> Further, I would avoid the use of words such as "can". > > >>> > > >>> * The text covers only fragmentation when it is induced by SFC=20 > > >>> operations, it does not discuss the treatment of a fragment when=20 > > >>> received in an SFC domain. IMHO, the draft should also specify=20 > > >>> the behavior of the Classifier with regards to fragments for the=20 > > >>> sake of proper SFC operation. Applying classification policies=20 > > >>> may require the > > >> full packet, not only a fragment. > > >>> In particular, dedicated resources should dedicated for handling=20 > > >>> out of order fragments. Of course, it is out of scope of this=20 > > >>> document to describe how SFs handle fragments. > > >>> > > >>> * If an SFC header is prepended for all fragments, I'm not sure=20 > > >>> there is any particular issue at the SFF level...except if=20 > > >>> stripping/adding context TLVs depends on the full packet (not=20 > > >>> just fragment). It is warranted to consider a little bit this=20 > > >>> point before declaring there > > is > > >> no issue. > > >>> > > >>> * The text states "several options". This may be interpreted as=20 > > >>> if implementing one of them is sufficient...which is not true.=20 > > >>> The first two points contribute to minimize the fragmentation=20 > > >>> risk, but fragmentation may still be experienced (e.g., other=20 > > >>> shims are prepended by other nodes for some other purposes,=20 > > >>> nested nsh, > > >>> etc.) > > >>> > > >>> * The first two points have nothing to do with reassembly. > > >>> > > >>> * The support of jumbo frames by a router/device does not mean=20 > > >>> that it can make use of it. Appropriate MTU configuration should=20 > > >>> be undertaken in a consistent manner within an SFC domain. The=20 > > >>> text should be updated to make it is about (consistent) MTU > configuration. > > >>> > > >>> * BTW, shouldn't the text be reworded to recommended to increase=20 > > >>> the MTU of **all nodes** of an SFC-enabled domain by at least=20 > > >>> the length of SFC header + transport header? > > >>> > > >>> * Bullet 2, how PMTU discovery is actually used in this context? > > >>> Do you assume that all SFC-aware nodes will issue such messages=20 > > >>> towards other SFC-aware node, arbitrary destination, else? > > >>> > > >>> * Bullet 2, I would drop "describes a technique for dynamically=20 > > >>> discovering the maximum transmission unit (MTU) of an arbitrary=20 > > >>> internet path". > > >>> > > >>> * Bullet 2, s/ the the/the. > > >>> > > >>> * The reference to the LISP specification raises two concerns=20 > > >>> and one > > >>> comment: > > >>> > > >>> (1) I don't think it is a good approach that fragments induced=20 > > >>> by the network are passed to their ultimate destinations as such > (stateless). > > >>> IMO, reassembly should be done within the SFC domain=20 > > >>> (responsible for > > >>> fragmentation) not passed away. > > >>> (2) Does the stateful mode require all SFC data plane elements=20 > > >>> maintain a full list of MTU for the any SFF/SF instance of the=20 > > >>> SFC > > >> domain? > > >>> > > >>> The current text suggests that [RFC6830] should be listed as=20 > > >>> normative reference (not an informative one). I would personally=20 > > >>> favor removing the reference to LISP (as it is an Experimental RFC)= . > > >>> > > >>> * The security section of the draft may be augmented with=20 > > >>> informational fragmentation-related pointers to: e.g., RFC1858=20 > > >>> (Security Considerations for IP Fragment Filtering), RFC3128=20 > > >>> (Protection Against a Variant of the Tiny Fragment Attack), and=20 > > >>> RFC > > >>> 4963 (IPv4 Reassembly Errors at High Data Rates). > > >>> > > >>> Cheers, > > >>> Med > > >>> > > >>>> -----Message d'origine----- > > >>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de=20 > > >>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : > > >>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for=20 > > >>>> draft-ietf-sfc-nsh-04.txt > > >>>> > > >>>> Dear Thomas, all, > > >>>> > > >>>> As I mentioned during the meeting, there are several issues=20 > > >>>> that are not covered in the last version of the draft. I=20 > > >>>> already provided examples of the issues offline as requested by Ma= rtin. > > >>>> > > >>>> Cheers, > > >>>> Med > > >>>> > > >>>>> -----Message d'origine----- > > >>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas=20 > > >>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org=20 > > >>>>> Objet > > >>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > >>>>> > > >>>>> Dear WG: > > >>>>> > > >>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 > > >>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > >>>>> > > >>>>> The editors of the NSH document have indicated that they have=20 > > >>>>> addressed all known comments and that there are no open issues=20 > > >>>>> with the current version of the document. > > >>>>> > > >>>>> Substantive comments to the list please, editorial comments=20 > > >>>>> can go directly to the document editors. > > >>>>> > > >>>>> We'll also get a brief update from the editors at next week's=20 > > >>>>> meeting. If there are any remaining issues with the document,=20 > > >>>>> raising them before the meeting would be especially helpful. > > >>>>> > > >>>>> For the chairs, > > >>>>> Thomas > > >>>>> > > >>>>> _______________________________________________ > > >>>>> sfc mailing list > > >>>>> sfc@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/sfc > > >>>> > > >>>> _______________________________________________ > > >>>> sfc mailing list > > >>>> sfc@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/sfc > > >>> > > >>> _______________________________________________ > > >>> sfc mailing list > > >>> sfc@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/sfc > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ > > > 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 Apr 26 08:19:24 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 41FD012D1DE for ; Tue, 26 Apr 2016 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 R2nROEGJzAYl for ; Tue, 26 Apr 2016 08:19:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177C712D1E9 for ; Tue, 26 Apr 2016 08:19:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C547F24EB23; Tue, 26 Apr 2016 08:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461683959; bh=/WaTGY9EUt15JiWjWa7VkL+tPacQsxeBDzZVB7z0O8c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LzP/TMPhXckvGbSAbotpLz+y8qBfLfH7gX96AkJcYGPaL5GuWI5zRYLLI4ly2v2wC cGU9eivH3GZD0BTgWv03kP6949mNS/BEKN35uGU450Zi/EZoF40PhtQM5DnA5O1w7H LyfcC4qwb/Z6bmftmIhdcTK/QA9lss7BTq8KOSJw= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E5D7E24E0BB; Tue, 26 Apr 2016 08:19:18 -0700 (PDT) To: Linda Dunbar , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <354f9b2f-2adf-c22c-c1b8-8b0ef9d11db0@joelhalpern.com> Date: Tue, 26 Apr 2016 11:19:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 15:19:22 -0000 Linda, on what basis do you reach that conclusion? Service functions have to be able to deal with fragmented IP packets. I don't see any reason why we would expect SFF to reassemble packets, even in the rare case where service chaining forces the fragmentation. (Note that such a case is generally actually indistinguishable from the origin fragmenting the packet, and it would be very odd for SFF to reassemble packets that the origin had fragmented.) Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: > Agree with Med. > > Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. > > Linda > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM > To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril >> 2016 16:26 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >> sfc@ietf.org Objet : RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a >> transport, dealing with fragmentation is left to the Transport used. >> >> The model I use for NSH, is basically similar to VXLAN . It is an overly. >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 7:18 AM >> To: Joel M. Halpern ; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 >>> avril 2016 15:48 À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, you are asking that the NSH >>> draft specify how service chaining should cope with packets that >>> have been fragmented? >>> >> >> [Med] To be accurate, I'm asking to assess whether there are implications. >> If there are, then the draft should be updated accordingly. >> >>> NSH, and the SFF functionality, does not care. >> >> [Med] I'm not that sure. Some typical implications are listed below: >> >> * SFF: If the NSH header is present only in the a fragment but SFF >> didn't maintained a state, subsequent fragments won't be appropriately processed. >> * SFC-aware function: if prepending a context information depends on >> the full packet, not only a fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some situations as listed in the >> examples above. >> >>> Ingress and intermediate classifiers may cope with fragments in any >>> number of ways. >> Specifying such is clearly out of scope for this draft. >> >> [Med] The purpose is not to specify the internal implementation >> details but the external behavior of the classifier function when it >> comes to handle fragments. That behavior may have an incidence on SFF, >> in particular. The purpose is not to recommend the maximum resources >> to be dedicated to out of order fragments nor the timeout to cache >> those; these considerations are of course out of scope. Nevertheless, >> an implementation should offer a configurable parameter so that an >> operator tweak those according to its context. >> >>> I suppose one could write an informational draft on possible ways >>> of coping. The IETF has not usually published such. >>> Service functions have to cope with fragmented packets just as they >>> had to before the advent of NSH, so describing that is clearly not >>> needed here. >> >> [Med] The advent of NSH has the following implications: >> * it exacerbates fragmentation. Handing over this issue to the >> transport layer may lead to interoperability issues. >> * the chaining may not be efficient if fragments are inappropriately >> handled. >> >> Introducing NSH should not degrade the overall service compared to >> legacy service deployment schemes. >> >>> >>> Yours, >>> Joel >>> >>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> I hear you, but my comment is that we need, as a WG, to decide >>>> what to >>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>> >>>> (1) Fragmentation that is caused by prepending an SFC header. >>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>> >>>> Increasing the MTU is for sure a recommendation is to be >>>> explicitly >>> called out in the text (see my first message). >>>> >>>> There are other issues that need to be discussed, e.g., how to >>>> deal with >>> fragments in SFFs/Classifiers? >>>> >>>> It is also "prudent" to check that no issues will be experienced >>>> in SFF >>> to handle fragments. If an SFC header is prepended for all >>> fragments, I'm not sure there >>>> is any particular issue at the SFF level, except if >>>> stripping/adding >>> context TLVs depends on the full packet (not just fragment). It is >>> warranted to consider a little bit this point before declaring there >>> is no issue. >>>> >>>> For point (1), declaring fragmentation out of scope would be meant >>>> that >>> an implementation must be prepared to receive fragments with or >>> without NSH header as this is a decision that is left to the >>> transport encapsulation. This is a requirement per se! >>>> >>>> I won't reiterate all the comments I have about the current >>>> wording of >>> this section. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 >>>>> avril 2016 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> My point is that Fragmentation is yet another transport related >>>>> issue >>> that >>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>> it >>> doesn't >>>>> really belong in the draft. We are providing an advice as >>>>> extending the size of the packet may lead to fragmentation, but >>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>> you'll find it doesn't even >>> relate >>>>> to it. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>> mohamed.boucadair@orange.com >>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>> To: Elzur, Uri ; Thomas Narten >>> ; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Uri, >>>>> >>>>> That's another option that needs to be discussed/investigated. >>>>> I'm >>> afraid >>>>> this is not the rationale adopted in -04 since it includes some >>>>> text >>> that >>>>> is far to be sufficient to ensure interoperable implementations. >>>>> >>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>> because >>> it >>>>> is transport-independent is not IMHO a good strategy to adopt >>>>> here >>> because >>>>> it opens the door for interoperable issues, it may lead to >>>>> sub-optimal implementations if the sfc information is present >>>>> only in one >>> fragments, >>>>> etc. >>>>> >>>>> My comments are related to the current text in the -04. This text >>>>> needs >>> to >>>>> be fixed somehow. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : dimanche >>>>>> 24 avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas >>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>> independent i.e. like NSH interaction with any other Transport >>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>> the mechanisms supported by the Transport used and do not belong >>>>>> in the NSH draft >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> R-, >>>>>> >>>>>> In addition to other pending issues raised for this draft, I >>>>>> would like to raise this additional one about Section 6. >>>>>> >>>>>> == >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> NSH and the associated transport header are "added" to the >>>>>> encapsulated packet/frame. This additional information >>>>>> increases >>> the >>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>> data, several options for handling fragmentation and re-assembly >>>>>> exist: >>>>>> >>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>> associated transport packets without requiring fragmentation. >>>>>> >>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>> dynamically discovering the maximum transmission unit >>>>>> (MTU) of >>> an >>>>>> arbitrary internet path" and can be utilized to ensure >>>>>> the >> the >>>>>> required packet size is used. >>>>>> >>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>> assembly >>>>>> in section 5.4. >>>>>> == >>>>>> >>>>>> * The text is weak for a Standard track document that is >>>>>> intended to solve the problem in >>>>>> https://tools.ietf.org/html/rfc7498#section- >> 2.12. >>>>>> There should be a clear behavior to be followed by an >> implementation. >>>>>> Further, I would avoid the use of words such as "can". >>>>>> >>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>> operations, it does not discuss the treatment of a fragment when >>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>> the behavior of the Classifier with regards to fragments for the >>>>>> sake of proper SFC operation. Applying classification policies >>>>>> may require the >>>>> full packet, not only a fragment. >>>>>> In particular, dedicated resources should dedicated for handling >>>>>> out of order fragments. Of course, it is out of scope of this >>>>>> document to describe how SFs handle fragments. >>>>>> >>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>> there is any particular issue at the SFF level...except if >>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>> just fragment). It is warranted to consider a little bit this >>>>>> point before declaring there >>> is >>>>> no issue. >>>>>> >>>>>> * The text states "several options". This may be interpreted as >>>>>> if implementing one of them is sufficient...which is not true. >>>>>> The first two points contribute to minimize the fragmentation >>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>> shims are prepended by other nodes for some other purposes, >>>>>> nested nsh, >>>>>> etc.) >>>>>> >>>>>> * The first two points have nothing to do with reassembly. >>>>>> >>>>>> * The support of jumbo frames by a router/device does not mean >>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>> text should be updated to make it is about (consistent) MTU >> configuration. >>>>>> >>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>> the length of SFC header + transport header? >>>>>> >>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>> >>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>>> internet path". >>>>>> >>>>>> * Bullet 2, s/ the the/the. >>>>>> >>>>>> * The reference to the LISP specification raises two concerns >>>>>> and one >>>>>> comment: >>>>>> >>>>>> (1) I don't think it is a good approach that fragments induced >>>>>> by the network are passed to their ultimate destinations as such >> (stateless). >>>>>> IMO, reassembly should be done within the SFC domain >>>>>> (responsible for >>>>>> fragmentation) not passed away. >>>>>> (2) Does the stateful mode require all SFC data plane elements >>>>>> maintain a full list of MTU for the any SFF/SF instance of the >>>>>> SFC >>>>> domain? >>>>>> >>>>>> The current text suggests that [RFC6830] should be listed as >>>>>> normative reference (not an informative one). I would personally >>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>> >>>>>> * The security section of the draft may be augmented with >>>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and >>>>>> RFC >>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril 2016 13:14 À : >>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Dear Thomas, all, >>>>>>> >>>>>>> As I mentioned during the meeting, there are several issues >>>>>>> that are not covered in the last version of the draft. I >>>>>>> already provided examples of the issues offline as requested by Martin. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>> Narten Envoyé : jeudi 31 mars 2016 04:48 À : sfc@ietf.org >>>>>>>> Objet >>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear WG: >>>>>>>> >>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>> >>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>> addressed all known comments and that there are no open issues >>>>>>>> with the current version of the document. >>>>>>>> >>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>> can go directly to the document editors. >>>>>>>> >>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>> >>>>>>>> For the chairs, >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Apr 26 08:33:12 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 9803412D1E2 for ; Tue, 26 Apr 2016 08:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 CEEjF_p2oq39 for ; Tue, 26 Apr 2016 08:33:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCFA12D1E7 for ; Tue, 26 Apr 2016 08:33:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6417224EB23; Tue, 26 Apr 2016 08:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461684783; bh=GW8HqGphw+mygus2SpSD7VD76XiJd7bmlULjL+T98a4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SYg6V1tKcMR2AlPxvKV92TxmGn0A/PswGlFqwrBzub+dF0N6wny/yGFkTB+PqcKIg GGx+Xx5kR9GCTgR/l8jztwZnUA8SvDs95Zb0ClPCgdlBiHEdGVOli7ERCw9LKl+pJG wbSLzAQ34bgIkzuZDqqIRqlwWH0fh2LNRYoiAHgE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8A972264842; Tue, 26 Apr 2016 08:33:02 -0700 (PDT) To: Linda Dunbar , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> Date: Tue, 26 Apr 2016 11:32:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 15:33:10 -0000 Re-reading your note, it is possible that you are referring only to the case of transport generated fragmentation of the outer packet. I had assumed you were not talking about that, since the resulting fragments will not all have NSH headers. As with any tunnel technology, if the tunnel chooses to fragment at its layer, then the tunnel is responsible for reassembly. That would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: > Agree with Med. > > Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. > > Linda > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM > To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril >> 2016 16:26 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >> sfc@ietf.org Objet : RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a >> transport, dealing with fragmentation is left to the Transport used. >> >> The model I use for NSH, is basically similar to VXLAN . It is an overly. >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 7:18 AM >> To: Joel M. Halpern ; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 >>> avril 2016 15:48 À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, you are asking that the NSH >>> draft specify how service chaining should cope with packets that >>> have been fragmented? >>> >> >> [Med] To be accurate, I'm asking to assess whether there are implications. >> If there are, then the draft should be updated accordingly. >> >>> NSH, and the SFF functionality, does not care. >> >> [Med] I'm not that sure. Some typical implications are listed below: >> >> * SFF: If the NSH header is present only in the a fragment but SFF >> didn't maintained a state, subsequent fragments won't be appropriately processed. >> * SFC-aware function: if prepending a context information depends on >> the full packet, not only a fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some situations as listed in the >> examples above. >> >>> Ingress and intermediate classifiers may cope with fragments in any >>> number of ways. >> Specifying such is clearly out of scope for this draft. >> >> [Med] The purpose is not to specify the internal implementation >> details but the external behavior of the classifier function when it >> comes to handle fragments. That behavior may have an incidence on SFF, >> in particular. The purpose is not to recommend the maximum resources >> to be dedicated to out of order fragments nor the timeout to cache >> those; these considerations are of course out of scope. Nevertheless, >> an implementation should offer a configurable parameter so that an >> operator tweak those according to its context. >> >>> I suppose one could write an informational draft on possible ways >>> of coping. The IETF has not usually published such. >>> Service functions have to cope with fragmented packets just as they >>> had to before the advent of NSH, so describing that is clearly not >>> needed here. >> >> [Med] The advent of NSH has the following implications: >> * it exacerbates fragmentation. Handing over this issue to the >> transport layer may lead to interoperability issues. >> * the chaining may not be efficient if fragments are inappropriately >> handled. >> >> Introducing NSH should not degrade the overall service compared to >> legacy service deployment schemes. >> >>> >>> Yours, >>> Joel >>> >>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> I hear you, but my comment is that we need, as a WG, to decide >>>> what to >>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>> >>>> (1) Fragmentation that is caused by prepending an SFC header. >>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>> >>>> Increasing the MTU is for sure a recommendation is to be >>>> explicitly >>> called out in the text (see my first message). >>>> >>>> There are other issues that need to be discussed, e.g., how to >>>> deal with >>> fragments in SFFs/Classifiers? >>>> >>>> It is also "prudent" to check that no issues will be experienced >>>> in SFF >>> to handle fragments. If an SFC header is prepended for all >>> fragments, I'm not sure there >>>> is any particular issue at the SFF level, except if >>>> stripping/adding >>> context TLVs depends on the full packet (not just fragment). It is >>> warranted to consider a little bit this point before declaring there >>> is no issue. >>>> >>>> For point (1), declaring fragmentation out of scope would be meant >>>> that >>> an implementation must be prepared to receive fragments with or >>> without NSH header as this is a decision that is left to the >>> transport encapsulation. This is a requirement per se! >>>> >>>> I won't reiterate all the comments I have about the current >>>> wording of >>> this section. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 >>>>> avril 2016 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> My point is that Fragmentation is yet another transport related >>>>> issue >>> that >>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>> it >>> doesn't >>>>> really belong in the draft. We are providing an advice as >>>>> extending the size of the packet may lead to fragmentation, but >>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>> you'll find it doesn't even >>> relate >>>>> to it. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>> mohamed.boucadair@orange.com >>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>> To: Elzur, Uri ; Thomas Narten >>> ; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Uri, >>>>> >>>>> That's another option that needs to be discussed/investigated. >>>>> I'm >>> afraid >>>>> this is not the rationale adopted in -04 since it includes some >>>>> text >>> that >>>>> is far to be sufficient to ensure interoperable implementations. >>>>> >>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>> because >>> it >>>>> is transport-independent is not IMHO a good strategy to adopt >>>>> here >>> because >>>>> it opens the door for interoperable issues, it may lead to >>>>> sub-optimal implementations if the sfc information is present >>>>> only in one >>> fragments, >>>>> etc. >>>>> >>>>> My comments are related to the current text in the -04. This text >>>>> needs >>> to >>>>> be fixed somehow. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : dimanche >>>>>> 24 avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas >>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>> independent i.e. like NSH interaction with any other Transport >>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>> the mechanisms supported by the Transport used and do not belong >>>>>> in the NSH draft >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> R-, >>>>>> >>>>>> In addition to other pending issues raised for this draft, I >>>>>> would like to raise this additional one about Section 6. >>>>>> >>>>>> == >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> NSH and the associated transport header are "added" to the >>>>>> encapsulated packet/frame. This additional information >>>>>> increases >>> the >>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>> data, several options for handling fragmentation and re-assembly >>>>>> exist: >>>>>> >>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>> associated transport packets without requiring fragmentation. >>>>>> >>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>> dynamically discovering the maximum transmission unit >>>>>> (MTU) of >>> an >>>>>> arbitrary internet path" and can be utilized to ensure >>>>>> the >> the >>>>>> required packet size is used. >>>>>> >>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>> assembly >>>>>> in section 5.4. >>>>>> == >>>>>> >>>>>> * The text is weak for a Standard track document that is >>>>>> intended to solve the problem in >>>>>> https://tools.ietf.org/html/rfc7498#section- >> 2.12. >>>>>> There should be a clear behavior to be followed by an >> implementation. >>>>>> Further, I would avoid the use of words such as "can". >>>>>> >>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>> operations, it does not discuss the treatment of a fragment when >>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>> the behavior of the Classifier with regards to fragments for the >>>>>> sake of proper SFC operation. Applying classification policies >>>>>> may require the >>>>> full packet, not only a fragment. >>>>>> In particular, dedicated resources should dedicated for handling >>>>>> out of order fragments. Of course, it is out of scope of this >>>>>> document to describe how SFs handle fragments. >>>>>> >>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>> there is any particular issue at the SFF level...except if >>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>> just fragment). It is warranted to consider a little bit this >>>>>> point before declaring there >>> is >>>>> no issue. >>>>>> >>>>>> * The text states "several options". This may be interpreted as >>>>>> if implementing one of them is sufficient...which is not true. >>>>>> The first two points contribute to minimize the fragmentation >>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>> shims are prepended by other nodes for some other purposes, >>>>>> nested nsh, >>>>>> etc.) >>>>>> >>>>>> * The first two points have nothing to do with reassembly. >>>>>> >>>>>> * The support of jumbo frames by a router/device does not mean >>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>> text should be updated to make it is about (consistent) MTU >> configuration. >>>>>> >>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>> the length of SFC header + transport header? >>>>>> >>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>> >>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>>> internet path". >>>>>> >>>>>> * Bullet 2, s/ the the/the. >>>>>> >>>>>> * The reference to the LISP specification raises two concerns >>>>>> and one >>>>>> comment: >>>>>> >>>>>> (1) I don't think it is a good approach that fragments induced >>>>>> by the network are passed to their ultimate destinations as such >> (stateless). >>>>>> IMO, reassembly should be done within the SFC domain >>>>>> (responsible for >>>>>> fragmentation) not passed away. >>>>>> (2) Does the stateful mode require all SFC data plane elements >>>>>> maintain a full list of MTU for the any SFF/SF instance of the >>>>>> SFC >>>>> domain? >>>>>> >>>>>> The current text suggests that [RFC6830] should be listed as >>>>>> normative reference (not an informative one). I would personally >>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>> >>>>>> * The security section of the draft may be augmented with >>>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and >>>>>> RFC >>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril 2016 13:14 À : >>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Dear Thomas, all, >>>>>>> >>>>>>> As I mentioned during the meeting, there are several issues >>>>>>> that are not covered in the last version of the draft. I >>>>>>> already provided examples of the issues offline as requested by Martin. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>> Narten Envoyé : jeudi 31 mars 2016 04:48 À : sfc@ietf.org >>>>>>>> Objet >>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear WG: >>>>>>>> >>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>> >>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>> addressed all known comments and that there are no open issues >>>>>>>> with the current version of the document. >>>>>>>> >>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>> can go directly to the document editors. >>>>>>>> >>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>> >>>>>>>> For the chairs, >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> 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 Tue Apr 26 08:48:16 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 1404F12D511 for ; Tue, 26 Apr 2016 08:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 9vfPD5drhlDs for ; Tue, 26 Apr 2016 08:48:11 -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 ABC5712D13F for ; Tue, 26 Apr 2016 08:48:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIN65215; Tue, 26 Apr 2016 15:48:06 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 16:48:05 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 08:47:57 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQIp3nrjaS0+VjDL7mlh8GJ+Er+AwgARg/TCAEFX48IABYBMAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAEik2CAAH4AgP//ixXg Date: Tue, 26 Apr 2016 15:47:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> In-Reply-To: <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.571F8DB7.0070, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f00e12aefba01234b913f67e0c7526fe Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 15:48:14 -0000 Joel,=20 I think the document should add the description on the following two fragme= ntation scenarios: - Transport tunnel generated fragmentation:=20 When a packet fragmentation is caused by transport tunnel (i.e. various e= ncapsulations), the termination point of the transport tunnel is responsibl= e for re-assembling the fragmented pieces of the packet. Since there won't = be any SFF nodes in between the Transport Tunnel, the tunnel generated frag= mentation does not require any actions by SFF nodes or SF nodes.=20 - Source node generated fragmentation (after adding on the NSH header): When fragmentation has to be performed for a packet being encapsulated w= ith the NSH header, either the intermediate SFF nodes or the SF nodes have = to be able to reassemble the fragmented pieces.=20 Cheers,=20 Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, April 26, 2016 10:33 AM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-reading your note, it is possible that you are referring only to the cas= e of transport generated fragmentation of the outer packet. I had assumed = you were not talking about that, since the resulting fragments will not all= have NSH headers. As with any tunnel technology, if the tunnel chooses to= fragment at its layer, then the tunnel is responsible for reassembly. Tha= t would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: > Agree with Med. > > Even if each fragment piece of a packet with NSH header carries the NSH h= eader, the intermediate SFF nodes still need to put together all the fragme= nts together before passing the whole data frame to the SF. > > Linda > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM > To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to ALWAYS prepend an NSH header e= ven for fragments? Or you don't care about that? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril >> 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;=20 >> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT*=20 >> a transport, dealing with fragmentation is left to the Transport used. >> >> The model I use for NSH, is basically similar to VXLAN . It is an overly= . >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 7:18 AM >> To: Joel M. Halpern ; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25=20 >>> avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, you are asking that the NSH=20 >>> draft specify how service chaining should cope with packets that=20 >>> have been fragmented? >>> >> >> [Med] To be accurate, I'm asking to assess whether there are implication= s. >> If there are, then the draft should be updated accordingly. >> >>> NSH, and the SFF functionality, does not care. >> >> [Med] I'm not that sure. Some typical implications are listed below: >> >> * SFF: If the NSH header is present only in the a fragment but SFF=20 >> didn't maintained a state, subsequent fragments won't be appropriately p= rocessed. >> * SFC-aware function: if prepending a context information depends on=20 >> the full packet, not only a fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some situations as listed in the=20 >> examples above. >> >>> Ingress and intermediate classifiers may cope with fragments in any=20 >>> number of ways. >> Specifying such is clearly out of scope for this draft. >> >> [Med] The purpose is not to specify the internal implementation=20 >> details but the external behavior of the classifier function when it=20 >> comes to handle fragments. That behavior may have an incidence on=20 >> SFF, in particular. The purpose is not to recommend the maximum=20 >> resources to be dedicated to out of order fragments nor the timeout=20 >> to cache those; these considerations are of course out of scope.=20 >> Nevertheless, an implementation should offer a configurable parameter=20 >> so that an operator tweak those according to its context. >> >>> I suppose one could write an informational draft on possible ways=20 >>> of coping. The IETF has not usually published such. >>> Service functions have to cope with fragmented packets just as they=20 >>> had to before the advent of NSH, so describing that is clearly not=20 >>> needed here. >> >> [Med] The advent of NSH has the following implications: >> * it exacerbates fragmentation. Handing over this issue to the=20 >> transport layer may lead to interoperability issues. >> * the chaining may not be efficient if fragments are inappropriately=20 >> handled. >> >> Introducing NSH should not degrade the overall service compared to=20 >> legacy service deployment schemes. >> >>> >>> Yours, >>> Joel >>> >>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> I hear you, but my comment is that we need, as a WG, to decide what=20 >>>> to >>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>> >>>> (1) Fragmentation that is caused by prepending an SFC header. >>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>> >>>> Increasing the MTU is for sure a recommendation is to be explicitly >>> called out in the text (see my first message). >>>> >>>> There are other issues that need to be discussed, e.g., how to >>>> deal with >>> fragments in SFFs/Classifiers? >>>> >>>> It is also "prudent" to check that no issues will be experienced >>>> in SFF >>> to handle fragments. If an SFC header is prepended for all >>> fragments, I'm not sure there >>>> is any particular issue at the SFF level, except if >>>> stripping/adding >>> context TLVs depends on the full packet (not just fragment). It is >>> warranted to consider a little bit this point before declaring there >>> is no issue. >>>> >>>> For point (1), declaring fragmentation out of scope would be meant >>>> that >>> an implementation must be prepared to receive fragments with or >>> without NSH header as this is a decision that is left to the >>> transport encapsulation. This is a requirement per se! >>>> >>>> I won't reiterate all the comments I have about the current >>>> wording of >>> this section. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 >>>>> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> My point is that Fragmentation is yet another transport related >>>>> issue >>> that >>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>> it >>> doesn't >>>>> really belong in the draft. We are providing an advice as >>>>> extending the size of the packet may lead to fragmentation, but >>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>> you'll find it doesn't even >>> relate >>>>> to it. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>> mohamed.boucadair@orange.com >>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>> To: Elzur, Uri ; Thomas Narten >>> ; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Uri, >>>>> >>>>> That's another option that needs to be discussed/investigated. >>>>> I'm >>> afraid >>>>> this is not the rationale adopted in -04 since it includes some >>>>> text >>> that >>>>> is far to be sufficient to ensure interoperable implementations. >>>>> >>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>> because >>> it >>>>> is transport-independent is not IMHO a good strategy to adopt >>>>> here >>> because >>>>> it opens the door for interoperable issues, it may lead to >>>>> sub-optimal implementations if the sfc information is present >>>>> only in one >>> fragments, >>>>> etc. >>>>> >>>>> My comments are related to the current text in the -04. This text >>>>> needs >>> to >>>>> be fixed somehow. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche >>>>>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas >>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>> independent i.e. like NSH interaction with any other Transport >>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>> the mechanisms supported by the Transport used and do not belong >>>>>> in the NSH draft >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> R-, >>>>>> >>>>>> In addition to other pending issues raised for this draft, I >>>>>> would like to raise this additional one about Section 6. >>>>>> >>>>>> =3D=3D >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> NSH and the associated transport header are "added" to the >>>>>> encapsulated packet/frame. This additional information >>>>>> increases >>> the >>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>> data, several options for handling fragmentation and re-assembly >>>>>> exist: >>>>>> >>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>> associated transport packets without requiring fragmentation. >>>>>> >>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>> dynamically discovering the maximum transmission unit >>>>>> (MTU) of >>> an >>>>>> arbitrary internet path" and can be utilized to ensure >>>>>> the >> the >>>>>> required packet size is used. >>>>>> >>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>> assembly >>>>>> in section 5.4. >>>>>> =3D=3D >>>>>> >>>>>> * The text is weak for a Standard track document that is >>>>>> intended to solve the problem in >>>>>> https://tools.ietf.org/html/rfc7498#section- >> 2.12. >>>>>> There should be a clear behavior to be followed by an >> implementation. >>>>>> Further, I would avoid the use of words such as "can". >>>>>> >>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>> operations, it does not discuss the treatment of a fragment when >>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>> the behavior of the Classifier with regards to fragments for the >>>>>> sake of proper SFC operation. Applying classification policies >>>>>> may require the >>>>> full packet, not only a fragment. >>>>>> In particular, dedicated resources should dedicated for handling >>>>>> out of order fragments. Of course, it is out of scope of this >>>>>> document to describe how SFs handle fragments. >>>>>> >>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>> there is any particular issue at the SFF level...except if >>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>> just fragment). It is warranted to consider a little bit this >>>>>> point before declaring there >>> is >>>>> no issue. >>>>>> >>>>>> * The text states "several options". This may be interpreted as >>>>>> if implementing one of them is sufficient...which is not true. >>>>>> The first two points contribute to minimize the fragmentation >>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>> shims are prepended by other nodes for some other purposes, >>>>>> nested nsh, >>>>>> etc.) >>>>>> >>>>>> * The first two points have nothing to do with reassembly. >>>>>> >>>>>> * The support of jumbo frames by a router/device does not mean >>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>> text should be updated to make it is about (consistent) MTU >> configuration. >>>>>> >>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>> the length of SFC header + transport header? >>>>>> >>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>> >>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>>> internet path". >>>>>> >>>>>> * Bullet 2, s/ the the/the. >>>>>> >>>>>> * The reference to the LISP specification raises two concerns >>>>>> and one >>>>>> comment: >>>>>> >>>>>> (1) I don't think it is a good approach that fragments induced >>>>>> by the network are passed to their ultimate destinations as such >> (stateless). >>>>>> IMO, reassembly should be done within the SFC domain >>>>>> (responsible for >>>>>> fragmentation) not passed away. >>>>>> (2) Does the stateful mode require all SFC data plane elements >>>>>> maintain a full list of MTU for the any SFF/SF instance of the >>>>>> SFC >>>>> domain? >>>>>> >>>>>> The current text suggests that [RFC6830] should be listed as >>>>>> normative reference (not an informative one). I would personally >>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>> >>>>>> * The security section of the draft may be augmented with >>>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and >>>>>> RFC >>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : >>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Dear Thomas, all, >>>>>>> >>>>>>> As I mentioned during the meeting, there are several issues >>>>>>> that are not covered in the last version of the draft. I >>>>>>> already provided examples of the issues offline as requested by Mar= tin. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org >>>>>>>> Objet >>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear WG: >>>>>>>> >>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>> >>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>> addressed all known comments and that there are no open issues >>>>>>>> with the current version of the document. >>>>>>>> >>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>> can go directly to the document editors. >>>>>>>> >>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>> >>>>>>>> For the chairs, >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> 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 Tue Apr 26 08:58:15 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 4516112D13F for ; Tue, 26 Apr 2016 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XPLJB1uktUr8 for ; Tue, 26 Apr 2016 08:58:10 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9A812D0E2 for ; Tue, 26 Apr 2016 08:58:10 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0266.001; Tue, 26 Apr 2016 08:58:09 -0700 From: Ron Parker To: Linda Dunbar , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPjVJMNJL6xkKtVPhZYT1+65+Er+AwgARg/TCAEMylAIAA6WYAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAGaMQCAAAZigIAABDUA//+L/bA= Date: Tue, 26 Apr 2016 15:58:09 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 15:58:12 -0000 Linda, I like the first clause (transport tunnel based fragmentation). Regarding the second (source based), I think there are more subcases to con= sider: 1. Propagation of NSH encapsulated packet from classifier to SFF 2. Propagation of NSH encapsulated packet from SFF to SF 3. Propagation of NSH encapsulated packet from SF to SFF (including possib= ility that NSH size increased at SF) 4. Propagation of NSH encapsulated packet from SFF to SFF In each of the 4 cases above, there is the possibility that MTU will be ex= ceeded and therefore there are procedures to be defined in that eventuality= . Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, April 26, 2016 11:48 AM To: Joel M. Halpern ; mohamed.boucadair@orange.com; El= zur, Uri ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Joel,=20 I think the document should add the description on the following two fragme= ntation scenarios: - Transport tunnel generated fragmentation:=20 When a packet fragmentation is caused by transport tunnel (i.e. various e= ncapsulations), the termination point of the transport tunnel is responsibl= e for re-assembling the fragmented pieces of the packet. Since there won't = be any SFF nodes in between the Transport Tunnel, the tunnel generated frag= mentation does not require any actions by SFF nodes or SF nodes.=20 - Source node generated fragmentation (after adding on the NSH header): When fragmentation has to be performed for a packet being encapsulated w= ith the NSH header, either the intermediate SFF nodes or the SF nodes have = to be able to reassemble the fragmented pieces.=20 Cheers,=20 Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-reading your note, it is possible that you are referring only to the cas= e of transport generated fragmentation of the outer packet. I had assumed = you were not talking about that, since the resulting fragments will not all= have NSH headers. As with any tunnel technology, if the tunnel chooses to= fragment at its layer, then the tunnel is responsible for reassembly. Tha= t would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: > Agree with Med. > > Even if each fragment piece of a packet with NSH header carries the NSH h= eader, the intermediate SFF nodes still need to put together all the fragme= nts together before passing the whole data frame to the SF. > > Linda > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM > To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to ALWAYS prepend an NSH header e= ven for fragments? Or you don't care about that? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril >> 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;=20 >> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT*=20 >> a transport, dealing with fragmentation is left to the Transport used. >> >> The model I use for NSH, is basically similar to VXLAN . It is an overly= . >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 7:18 AM >> To: Joel M. Halpern ; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25=20 >>> avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, you are asking that the NSH=20 >>> draft specify how service chaining should cope with packets that=20 >>> have been fragmented? >>> >> >> [Med] To be accurate, I'm asking to assess whether there are implication= s. >> If there are, then the draft should be updated accordingly. >> >>> NSH, and the SFF functionality, does not care. >> >> [Med] I'm not that sure. Some typical implications are listed below: >> >> * SFF: If the NSH header is present only in the a fragment but SFF=20 >> didn't maintained a state, subsequent fragments won't be appropriately p= rocessed. >> * SFC-aware function: if prepending a context information depends on=20 >> the full packet, not only a fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some situations as listed in the=20 >> examples above. >> >>> Ingress and intermediate classifiers may cope with fragments in any=20 >>> number of ways. >> Specifying such is clearly out of scope for this draft. >> >> [Med] The purpose is not to specify the internal implementation=20 >> details but the external behavior of the classifier function when it=20 >> comes to handle fragments. That behavior may have an incidence on=20 >> SFF, in particular. The purpose is not to recommend the maximum=20 >> resources to be dedicated to out of order fragments nor the timeout=20 >> to cache those; these considerations are of course out of scope. >> Nevertheless, an implementation should offer a configurable parameter=20 >> so that an operator tweak those according to its context. >> >>> I suppose one could write an informational draft on possible ways=20 >>> of coping. The IETF has not usually published such. >>> Service functions have to cope with fragmented packets just as they=20 >>> had to before the advent of NSH, so describing that is clearly not=20 >>> needed here. >> >> [Med] The advent of NSH has the following implications: >> * it exacerbates fragmentation. Handing over this issue to the=20 >> transport layer may lead to interoperability issues. >> * the chaining may not be efficient if fragments are inappropriately=20 >> handled. >> >> Introducing NSH should not degrade the overall service compared to=20 >> legacy service deployment schemes. >> >>> >>> Yours, >>> Joel >>> >>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> I hear you, but my comment is that we need, as a WG, to decide what=20 >>>> to >>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>> >>>> (1) Fragmentation that is caused by prepending an SFC header. >>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>> >>>> Increasing the MTU is for sure a recommendation is to be explicitly >>> called out in the text (see my first message). >>>> >>>> There are other issues that need to be discussed, e.g., how to deal=20 >>>> with >>> fragments in SFFs/Classifiers? >>>> >>>> It is also "prudent" to check that no issues will be experienced in=20 >>>> SFF >>> to handle fragments. If an SFC header is prepended for all=20 >>> fragments, I'm not sure there >>>> is any particular issue at the SFF level, except if=20 >>>> stripping/adding >>> context TLVs depends on the full packet (not just fragment). It is=20 >>> warranted to consider a little bit this point before declaring there=20 >>> is no issue. >>>> >>>> For point (1), declaring fragmentation out of scope would be meant=20 >>>> that >>> an implementation must be prepared to receive fragments with or=20 >>> without NSH header as this is a decision that is left to the=20 >>> transport encapsulation. This is a requirement per se! >>>> >>>> I won't reiterate all the comments I have about the current wording=20 >>>> of >>> this section. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25=20 >>>>> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> My point is that Fragmentation is yet another transport related=20 >>>>> issue >>> that >>>>> is beyond the scope of NSH and beyond the charter of the WG, so it >>> doesn't >>>>> really belong in the draft. We are providing an advice as=20 >>>>> extending the size of the packet may lead to fragmentation, but as=20 >>>>> you check RFC 7348 VxLAN, which my create the same issue, you'll=20 >>>>> find it doesn't even >>> relate >>>>> to it. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>> mohamed.boucadair@orange.com >>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>> To: Elzur, Uri ; Thomas Narten >>> ; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Uri, >>>>> >>>>> That's another option that needs to be discussed/investigated. >>>>> I'm >>> afraid >>>>> this is not the rationale adopted in -04 since it includes some=20 >>>>> text >>> that >>>>> is far to be sufficient to ensure interoperable implementations. >>>>> >>>>> BTW, saying that nsh does not need to deal with fragmentation=20 >>>>> because >>> it >>>>> is transport-independent is not IMHO a good strategy to adopt here >>> because >>>>> it opens the door for interoperable issues, it may lead to=20 >>>>> sub-optimal implementations if the sfc information is present only=20 >>>>> in one >>> fragments, >>>>> etc. >>>>> >>>>> My comments are related to the current text in the -04. This text=20 >>>>> needs >>> to >>>>> be fixed somehow. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche >>>>>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;= =20 >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> I see no need to specify the exact behavior as NSH is transport=20 >>>>>> independent i.e. like NSH interaction with any other Transport eh=20 >>>>>> issue of Fragmentation is to be dealt in a way that matches the=20 >>>>>> mechanisms supported by the Transport used and do not belong in=20 >>>>>> the NSH draft >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> R-, >>>>>> >>>>>> In addition to other pending issues raised for this draft, I=20 >>>>>> would like to raise this additional one about Section 6. >>>>>> >>>>>> =3D=3D >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> NSH and the associated transport header are "added" to the >>>>>> encapsulated packet/frame. This additional information=20 >>>>>> increases >>> the >>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>> data, several options for handling fragmentation and re-assembly >>>>>> exist: >>>>>> >>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>> associated transport packets without requiring fragmentation. >>>>>> >>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>> dynamically discovering the maximum transmission unit >>>>>> (MTU) of >>> an >>>>>> arbitrary internet path" and can be utilized to ensure the >> the >>>>>> required packet size is used. >>>>>> >>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>> assembly >>>>>> in section 5.4. >>>>>> =3D=3D >>>>>> >>>>>> * The text is weak for a Standard track document that is intended=20 >>>>>> to solve the problem in >>>>>> https://tools.ietf.org/html/rfc7498#section- >> 2.12. >>>>>> There should be a clear behavior to be followed by an >> implementation. >>>>>> Further, I would avoid the use of words such as "can". >>>>>> >>>>>> * The text covers only fragmentation when it is induced by SFC=20 >>>>>> operations, it does not discuss the treatment of a fragment when=20 >>>>>> received in an SFC domain. IMHO, the draft should also specify=20 >>>>>> the behavior of the Classifier with regards to fragments for the=20 >>>>>> sake of proper SFC operation. Applying classification policies=20 >>>>>> may require the >>>>> full packet, not only a fragment. >>>>>> In particular, dedicated resources should dedicated for handling=20 >>>>>> out of order fragments. Of course, it is out of scope of this=20 >>>>>> document to describe how SFs handle fragments. >>>>>> >>>>>> * If an SFC header is prepended for all fragments, I'm not sure=20 >>>>>> there is any particular issue at the SFF level...except if=20 >>>>>> stripping/adding context TLVs depends on the full packet (not=20 >>>>>> just fragment). It is warranted to consider a little bit this=20 >>>>>> point before declaring there >>> is >>>>> no issue. >>>>>> >>>>>> * The text states "several options". This may be interpreted as=20 >>>>>> if implementing one of them is sufficient...which is not true. >>>>>> The first two points contribute to minimize the fragmentation=20 >>>>>> risk, but fragmentation may still be experienced (e.g., other=20 >>>>>> shims are prepended by other nodes for some other purposes,=20 >>>>>> nested nsh, >>>>>> etc.) >>>>>> >>>>>> * The first two points have nothing to do with reassembly. >>>>>> >>>>>> * The support of jumbo frames by a router/device does not mean=20 >>>>>> that it can make use of it. Appropriate MTU configuration should=20 >>>>>> be undertaken in a consistent manner within an SFC domain. The=20 >>>>>> text should be updated to make it is about (consistent) MTU >> configuration. >>>>>> >>>>>> * BTW, shouldn't the text be reworded to recommended to increase=20 >>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least the=20 >>>>>> length of SFC header + transport header? >>>>>> >>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>> Do you assume that all SFC-aware nodes will issue such messages=20 >>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>> >>>>>> * Bullet 2, I would drop "describes a technique for dynamically=20 >>>>>> discovering the maximum transmission unit (MTU) of an arbitrary=20 >>>>>> internet path". >>>>>> >>>>>> * Bullet 2, s/ the the/the. >>>>>> >>>>>> * The reference to the LISP specification raises two concerns and=20 >>>>>> one >>>>>> comment: >>>>>> >>>>>> (1) I don't think it is a good approach that fragments induced by=20 >>>>>> the network are passed to their ultimate destinations as such >> (stateless). >>>>>> IMO, reassembly should be done within the SFC domain (responsible=20 >>>>>> for >>>>>> fragmentation) not passed away. >>>>>> (2) Does the stateful mode require all SFC data plane elements=20 >>>>>> maintain a full list of MTU for the any SFF/SF instance of the=20 >>>>>> SFC >>>>> domain? >>>>>> >>>>>> The current text suggests that [RFC6830] should be listed as=20 >>>>>> normative reference (not an informative one). I would personally=20 >>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>> >>>>>> * The security section of the draft may be augmented with=20 >>>>>> informational fragmentation-related pointers to: e.g., RFC1858=20 >>>>>> (Security Considerations for IP Fragment Filtering), RFC3128=20 >>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and=20 >>>>>> RFC >>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de=20 >>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : >>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for=20 >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Dear Thomas, all, >>>>>>> >>>>>>> As I mentioned during the meeting, there are several issues that=20 >>>>>>> are not covered in the last version of the draft. I already=20 >>>>>>> provided examples of the issues offline as requested by Martin. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas=20 >>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org Obje= t >>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear WG: >>>>>>>> >>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>> >>>>>>>> The editors of the NSH document have indicated that they have=20 >>>>>>>> addressed all known comments and that there are no open issues=20 >>>>>>>> with the current version of the document. >>>>>>>> >>>>>>>> Substantive comments to the list please, editorial comments can=20 >>>>>>>> go directly to the document editors. >>>>>>>> >>>>>>>> We'll also get a brief update from the editors at next week's=20 >>>>>>>> meeting. If there are any remaining issues with the document,=20 >>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>> >>>>>>>> For the chairs, >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 26 09:13:24 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 484B412D510 for ; Tue, 26 Apr 2016 09:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 Fmuz6ZS9PQbS for ; Tue, 26 Apr 2016 09:13:19 -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 D84A912D13A for ; Tue, 26 Apr 2016 09:13:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIN69190; Tue, 26 Apr 2016 16:13:17 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 17:13:16 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 09:13:13 -0700 From: Linda Dunbar To: Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQIp3nrjaS0+VjDL7mlh8GJ+Er+AwgARg/TCAEFX48IABYBMAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAEik2CAAH4AgP//ixXggAB7+4D//45cwA== Date: Tue, 26 Apr 2016 16:13:13 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7CDF8@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D560CE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.571F939D.011D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f00e12aefba01234b913f67e0c7526fe Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 16:13:23 -0000 Ron,=20 That is very good addition. For the Source Based fragmentation, also need t= o add the description if the NSH header is added to each fragmented piece.= =20 Linda -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Tuesday, April 26, 2016 10:58 AM To: Linda Dunbar; Joel M. Halpern; mohamed.boucadair@orange.com; Elzur, Uri= ; sfc@ietf.org Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Linda, I like the first clause (transport tunnel based fragmentation). Regarding the second (source based), I think there are more subcases to con= sider: 1. Propagation of NSH encapsulated packet from classifier to SFF 2. Propa= gation of NSH encapsulated packet from SFF to SF 3. Propagation of NSH enc= apsulated packet from SF to SFF (including possibility that NSH size increa= sed at SF) 4. Propagation of NSH encapsulated packet from SFF to SFF In each of the 4 cases above, there is the possibility that MTU will be ex= ceeded and therefore there are procedures to be defined in that eventuality= . Thanks. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, April 26, 2016 11:48 AM To: Joel M. Halpern ; mohamed.boucadair@orange.com; El= zur, Uri ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Joel,=20 I think the document should add the description on the following two fragme= ntation scenarios: - Transport tunnel generated fragmentation:=20 When a packet fragmentation is caused by transport tunnel (i.e. various e= ncapsulations), the termination point of the transport tunnel is responsibl= e for re-assembling the fragmented pieces of the packet. Since there won't = be any SFF nodes in between the Transport Tunnel, the tunnel generated frag= mentation does not require any actions by SFF nodes or SF nodes.=20 - Source node generated fragmentation (after adding on the NSH header): When fragmentation has to be performed for a packet being encapsulated w= ith the NSH header, either the intermediate SFF nodes or the SF nodes have = to be able to reassemble the fragmented pieces.=20 Cheers,=20 Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-reading your note, it is possible that you are referring only to the cas= e of transport generated fragmentation of the outer packet. I had assumed = you were not talking about that, since the resulting fragments will not all= have NSH headers. As with any tunnel technology, if the tunnel chooses to= fragment at its layer, then the tunnel is responsible for reassembly. Tha= t would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: > Agree with Med. > > Even if each fragment piece of a packet with NSH header carries the NSH h= eader, the intermediate SFF nodes still need to put together all the fragme= nts together before passing the whole data frame to the SF. > > Linda > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM > To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to ALWAYS prepend an NSH header e= ven for fragments? Or you don't care about that? > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril >> 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;=20 >> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT*=20 >> a transport, dealing with fragmentation is left to the Transport used. >> >> The model I use for NSH, is basically similar to VXLAN . It is an overly= . >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 7:18 AM >> To: Joel M. Halpern ; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25=20 >>> avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, you are asking that the NSH=20 >>> draft specify how service chaining should cope with packets that=20 >>> have been fragmented? >>> >> >> [Med] To be accurate, I'm asking to assess whether there are implication= s. >> If there are, then the draft should be updated accordingly. >> >>> NSH, and the SFF functionality, does not care. >> >> [Med] I'm not that sure. Some typical implications are listed below: >> >> * SFF: If the NSH header is present only in the a fragment but SFF=20 >> didn't maintained a state, subsequent fragments won't be appropriately p= rocessed. >> * SFC-aware function: if prepending a context information depends on=20 >> the full packet, not only a fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some situations as listed in the=20 >> examples above. >> >>> Ingress and intermediate classifiers may cope with fragments in any=20 >>> number of ways. >> Specifying such is clearly out of scope for this draft. >> >> [Med] The purpose is not to specify the internal implementation=20 >> details but the external behavior of the classifier function when it=20 >> comes to handle fragments. That behavior may have an incidence on=20 >> SFF, in particular. The purpose is not to recommend the maximum=20 >> resources to be dedicated to out of order fragments nor the timeout=20 >> to cache those; these considerations are of course out of scope. >> Nevertheless, an implementation should offer a configurable parameter=20 >> so that an operator tweak those according to its context. >> >>> I suppose one could write an informational draft on possible ways=20 >>> of coping. The IETF has not usually published such. >>> Service functions have to cope with fragmented packets just as they=20 >>> had to before the advent of NSH, so describing that is clearly not=20 >>> needed here. >> >> [Med] The advent of NSH has the following implications: >> * it exacerbates fragmentation. Handing over this issue to the=20 >> transport layer may lead to interoperability issues. >> * the chaining may not be efficient if fragments are inappropriately=20 >> handled. >> >> Introducing NSH should not degrade the overall service compared to=20 >> legacy service deployment schemes. >> >>> >>> Yours, >>> Joel >>> >>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> I hear you, but my comment is that we need, as a WG, to decide what=20 >>>> to >>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>> >>>> (1) Fragmentation that is caused by prepending an SFC header. >>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>> >>>> Increasing the MTU is for sure a recommendation is to be explicitly >>> called out in the text (see my first message). >>>> >>>> There are other issues that need to be discussed, e.g., how to deal=20 >>>> with >>> fragments in SFFs/Classifiers? >>>> >>>> It is also "prudent" to check that no issues will be experienced in=20 >>>> SFF >>> to handle fragments. If an SFC header is prepended for all=20 >>> fragments, I'm not sure there >>>> is any particular issue at the SFF level, except if=20 >>>> stripping/adding >>> context TLVs depends on the full packet (not just fragment). It is=20 >>> warranted to consider a little bit this point before declaring there=20 >>> is no issue. >>>> >>>> For point (1), declaring fragmentation out of scope would be meant=20 >>>> that >>> an implementation must be prepared to receive fragments with or=20 >>> without NSH header as this is a decision that is left to the=20 >>> transport encapsulation. This is a requirement per se! >>>> >>>> I won't reiterate all the comments I have about the current wording=20 >>>> of >>> this section. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25=20 >>>>> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> My point is that Fragmentation is yet another transport related=20 >>>>> issue >>> that >>>>> is beyond the scope of NSH and beyond the charter of the WG, so it >>> doesn't >>>>> really belong in the draft. We are providing an advice as=20 >>>>> extending the size of the packet may lead to fragmentation, but as=20 >>>>> you check RFC 7348 VxLAN, which my create the same issue, you'll=20 >>>>> find it doesn't even >>> relate >>>>> to it. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>> mohamed.boucadair@orange.com >>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>> To: Elzur, Uri ; Thomas Narten >>> ; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Uri, >>>>> >>>>> That's another option that needs to be discussed/investigated. >>>>> I'm >>> afraid >>>>> this is not the rationale adopted in -04 since it includes some=20 >>>>> text >>> that >>>>> is far to be sufficient to ensure interoperable implementations. >>>>> >>>>> BTW, saying that nsh does not need to deal with fragmentation=20 >>>>> because >>> it >>>>> is transport-independent is not IMHO a good strategy to adopt here >>> because >>>>> it opens the door for interoperable issues, it may lead to=20 >>>>> sub-optimal implementations if the sfc information is present only=20 >>>>> in one >>> fragments, >>>>> etc. >>>>> >>>>> My comments are related to the current text in the -04. This text=20 >>>>> needs >>> to >>>>> be fixed somehow. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche >>>>>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;= =20 >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> I see no need to specify the exact behavior as NSH is transport=20 >>>>>> independent i.e. like NSH interaction with any other Transport eh=20 >>>>>> issue of Fragmentation is to be dealt in a way that matches the=20 >>>>>> mechanisms supported by the Transport used and do not belong in=20 >>>>>> the NSH draft >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> R-, >>>>>> >>>>>> In addition to other pending issues raised for this draft, I=20 >>>>>> would like to raise this additional one about Section 6. >>>>>> >>>>>> =3D=3D >>>>>> 6. Fragmentation Considerations >>>>>> >>>>>> NSH and the associated transport header are "added" to the >>>>>> encapsulated packet/frame. This additional information=20 >>>>>> increases >>> the >>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>> data, several options for handling fragmentation and re-assembly >>>>>> exist: >>>>>> >>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>> associated transport packets without requiring fragmentation. >>>>>> >>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>> dynamically discovering the maximum transmission unit >>>>>> (MTU) of >>> an >>>>>> arbitrary internet path" and can be utilized to ensure the >> the >>>>>> required packet size is used. >>>>>> >>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>> assembly >>>>>> in section 5.4. >>>>>> =3D=3D >>>>>> >>>>>> * The text is weak for a Standard track document that is intended=20 >>>>>> to solve the problem in >>>>>> https://tools.ietf.org/html/rfc7498#section- >> 2.12. >>>>>> There should be a clear behavior to be followed by an >> implementation. >>>>>> Further, I would avoid the use of words such as "can". >>>>>> >>>>>> * The text covers only fragmentation when it is induced by SFC=20 >>>>>> operations, it does not discuss the treatment of a fragment when=20 >>>>>> received in an SFC domain. IMHO, the draft should also specify=20 >>>>>> the behavior of the Classifier with regards to fragments for the=20 >>>>>> sake of proper SFC operation. Applying classification policies=20 >>>>>> may require the >>>>> full packet, not only a fragment. >>>>>> In particular, dedicated resources should dedicated for handling=20 >>>>>> out of order fragments. Of course, it is out of scope of this=20 >>>>>> document to describe how SFs handle fragments. >>>>>> >>>>>> * If an SFC header is prepended for all fragments, I'm not sure=20 >>>>>> there is any particular issue at the SFF level...except if=20 >>>>>> stripping/adding context TLVs depends on the full packet (not=20 >>>>>> just fragment). It is warranted to consider a little bit this=20 >>>>>> point before declaring there >>> is >>>>> no issue. >>>>>> >>>>>> * The text states "several options". This may be interpreted as=20 >>>>>> if implementing one of them is sufficient...which is not true. >>>>>> The first two points contribute to minimize the fragmentation=20 >>>>>> risk, but fragmentation may still be experienced (e.g., other=20 >>>>>> shims are prepended by other nodes for some other purposes,=20 >>>>>> nested nsh, >>>>>> etc.) >>>>>> >>>>>> * The first two points have nothing to do with reassembly. >>>>>> >>>>>> * The support of jumbo frames by a router/device does not mean=20 >>>>>> that it can make use of it. Appropriate MTU configuration should=20 >>>>>> be undertaken in a consistent manner within an SFC domain. The=20 >>>>>> text should be updated to make it is about (consistent) MTU >> configuration. >>>>>> >>>>>> * BTW, shouldn't the text be reworded to recommended to increase=20 >>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least the=20 >>>>>> length of SFC header + transport header? >>>>>> >>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>> Do you assume that all SFC-aware nodes will issue such messages=20 >>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>> >>>>>> * Bullet 2, I would drop "describes a technique for dynamically=20 >>>>>> discovering the maximum transmission unit (MTU) of an arbitrary=20 >>>>>> internet path". >>>>>> >>>>>> * Bullet 2, s/ the the/the. >>>>>> >>>>>> * The reference to the LISP specification raises two concerns and=20 >>>>>> one >>>>>> comment: >>>>>> >>>>>> (1) I don't think it is a good approach that fragments induced by=20 >>>>>> the network are passed to their ultimate destinations as such >> (stateless). >>>>>> IMO, reassembly should be done within the SFC domain (responsible=20 >>>>>> for >>>>>> fragmentation) not passed away. >>>>>> (2) Does the stateful mode require all SFC data plane elements=20 >>>>>> maintain a full list of MTU for the any SFF/SF instance of the=20 >>>>>> SFC >>>>> domain? >>>>>> >>>>>> The current text suggests that [RFC6830] should be listed as=20 >>>>>> normative reference (not an informative one). I would personally=20 >>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>> >>>>>> * The security section of the draft may be augmented with=20 >>>>>> informational fragmentation-related pointers to: e.g., RFC1858=20 >>>>>> (Security Considerations for IP Fragment Filtering), RFC3128=20 >>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and=20 >>>>>> RFC >>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de=20 >>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : >>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for=20 >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Dear Thomas, all, >>>>>>> >>>>>>> As I mentioned during the meeting, there are several issues that=20 >>>>>>> are not covered in the last version of the draft. I already=20 >>>>>>> provided examples of the issues offline as requested by Martin. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas=20 >>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org Obje= t >>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear WG: >>>>>>>> >>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>> >>>>>>>> The editors of the NSH document have indicated that they have=20 >>>>>>>> addressed all known comments and that there are no open issues=20 >>>>>>>> with the current version of the document. >>>>>>>> >>>>>>>> Substantive comments to the list please, editorial comments can=20 >>>>>>>> go directly to the document editors. >>>>>>>> >>>>>>>> We'll also get a brief update from the editors at next week's=20 >>>>>>>> meeting. If there are any remaining issues with the document,=20 >>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>> >>>>>>>> For the chairs, >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 26 10:06:34 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 4E28612D541 for ; Tue, 26 Apr 2016 10:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 DFQ5X1CpxrW8 for ; Tue, 26 Apr 2016 10:06:31 -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 378FE12D533 for ; Tue, 26 Apr 2016 10:06:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIN76890; Tue, 26 Apr 2016 17:06:28 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 18:06:27 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 10:06:24 -0700 From: Linda Dunbar To: Sunil Vallamkonda , "sfc@ietf.org" Thread-Topic: Questions to SFC-Metadata-model Thread-Index: AQHRn931TwQxIEnd+UK67M9K4Pjl1g== Date: Tue, 26 Apr 2016 17:06:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7CEE6@dfweml501-mbb> References: <1460042865963.25707@F5.com>, , <1460091126273.230@F5.com> <1D15709113D6B34BAE5E128F392059CA01268568BE@blr-exch-1.sandvine.com>, <1460738575691.54747@F5.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] 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.0A020204.571FA014.0206, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d4e251da4aa51661e299d3d82e2c2504 Archived-At: Subject: [sfc] Questions to SFC-Metadata-model 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, 26 Apr 2016 17:06:33 -0000 U3VuaWwsIA0KDQpEbyB5b3Ugc3VnZ2VzdCB0aGF0IHRoZSBtZXRhZGF0YSBjYXJyaWVkIGJ5IHRo ZSBwYWNrZXRzIG5lZWQgdG8gY2FycnkgdGhvc2UgTWV0YWRhdGEgYXR0cmlidXRlLVZhbHVlIHBh aXJzIChTZWN0aW9uIDQgb2YgeW91ciBkcmFmdCk/IA0KDQpPciBhcmUgdGhvc2UgbWV0YWRhdGEg YXR0cmlidXRlIHZhbHVlIGRpc3RyaWJ1dGVkIGJ5IG91dCBvZiBiYW5kIGNvbnRyb2wgcGxhbmUg bWVzc2FnZXM/IA0KDQpEbyBhc3N1bWUgdGhhdCBDbGFzc2lmaWVyIGlzIGluZm9ybWVkIG9mIHRo b3NlIE1ldGFkYXRhIEF0dHJpYnV0ZSB2YWx1ZSBwYWlycz8gV2hhdCBpZiBkaWZmZXJlbnQgaW5z dGFudGlhdGlvbiBvZiB0aGUgU0YgKGJ5IGRpZmZlcmVudCB2ZW5kb3IpIHdpbGwgYmUgdHJhdmVy c2VkIGJ5IHRoZSBwYWNrZXQ/IA0KDQoNCkxpbmRhDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT dW5pbCBWYWxsYW1rb25kYQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIxLCAyMDE2IDE6MzEgUE0N ClRvOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBBIHJlcXVlc3QgZm9yIE1ldGFk YXRhIGFsbG9jYXRpb24gc2NoZW1lcw0KDQoNClZlbmRvcnMgYWxyZWFkeSBzZWVtIHRvIGJlIHdv cmtpbmcgb24gcHJvcHJpZXRhcnkgbWVjaGFuaXNtcyB0byBzaGFyZSB0aGUgbWV0YWRhdGEgaW4g aW1wbGVtZW50YXRpb25zIHdoaWNoIHNlZW0gdG8gaW5mZXIgdGhlIG5lZWQgZm9yIGEgc3RhbmRh cmQgZnJhbWV3b3JrIGZvciBpbnRlcm9wIGFuZCBzY2FsZS4NClRoZSBkb2N1bWVudCBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmFsbGFta29uZGEtc2ZjLW1ldGFkYXRhLW1vZGVs LTAwIHByb3Bvc2VzIG1ldGhvZCB1c2luZyBJQU5BIHJlZ2lzdHJ5IGZvciBzdXBwb3J0aW5nIGJv dGggdGhlIGdlbmVyaWMgYWxsb2NhdGlvbiBzY2hlbWVzIGFzIG1vYmlsaXR5LCBicm9hZGJhbmQg YW5kIG90aGVycywgYW5kIHRoZSB2ZW5kb3Igc3BlY2lmaWMgb25lcywgYXMgdGhleSBldm9sdmUu DQoNCg0KVGhhbmtzLA0KU3VuaWwuDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIERvbHNv bg0KU2VudDogRnJpZGF5LCBBcHJpbCAxNSwgMjAxNiA5OjUwIEFNDQpUbzogU3VtYW5kcmEgTWFq ZWUgPFMuTWFqZWVARjUuY29tPg0KQ2M6IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNd IEEgcmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNClN1bWFuZHJhLA0K DQo+IEkgYW0gZ2VuZXJhbGx5IG9wcG9zZWQgdG8gc3RhbmRhcmRpemluZyBtZXRhZGF0YSBhbGxv Y2F0aW9uIHRoaXMgZWFybHkuDQoNClJlZmVycmluZyBiYWNrIHRvIG15IG9yaWdpbmFsIGVtYWls LCBJIG1hZGUgdGhlIHJlcXVlc3QgdG8gdGhvc2Ugd2hvIGFyZSBwcm9wb3NpbmcgbWV0YWRhdGEg c2NoZW1lcyBpbiBkcmFmdHM7IEkgYW0gbm90IGFza2luZyBmb3IgYSBkaXJlY3Rpb24gaW5kaWNh dGlvbiBpbiB0aGUgTlNIIGJhc2UgcHJvdG9jb2wuDQoNCkluIGVhY2ggb2YgdGhlIGFsbG9jYXRp b24gc2NoZW1lcyB0aGVyZSBhcmUgInJlc2VydmVkIiBiaXRzIHRoYXQgY291bGQgYmUgdXNlZC4N Cg0KLURhdmUNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1bWFu ZHJhIE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21dIA0KU2VudDogRnJpZGF5LCBBcHJpbCAx NSwgMjAxNiAxMjo0MyBQTQ0KVG86IEJvdHRvcmZmLCBQYXVsOyBOaWxhbmphbiBTYXJrYXINCkNj OiBEYXZlIERvbHNvbjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gQSByZXF1ZXN0 IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0KRGF2ZSwgUGF1bCBhbmQgTmlsYW5q YW4sDQoNCkkgYW0gbm90IG9wcG9zZWQgdG8gaGF2aW5nIGEgZGlyZWN0aW9uIGJpdCBpbiB0aGUg bWV0YWRhdGEsIHllcyBpdCBtaWdodCBiZWNvbWUgbmVjZXNzaXR5IGluIGNlcnRhaW4gc2l0dWF0 aW9uLiBJIGFtIG5vdCBzdXJlIGlmIHdlIG5lZWQgdGhpcyBzZW5zZSBvZiBkaXJlY3Rpb24gZm9y IG1ham9yaXR5IG9mIHVzZSBjYXNlcy4NCg0KSSBhbSBnZW5lcmFsbHkgb3Bwb3NlZCB0byBzdGFu ZGFyZGl6aW5nIG1ldGFkYXRhIGFsbG9jYXRpb24gdGhpcyBlYXJseS4NCg0KV2hhdCBJIHdvdWxk IHJlYWxseSBsaWtlIHRvIGhhdmUgYSBtZXRhZGF0YSByZWdpc3RyeSBhbmQgYSBzY2hlbWUgZm9y IHRoYXQuICANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IEJvdHRvcmZmLCBQYXVsIDxwYXVsLmJvdHRvcmZmQGhwZS5jb20+DQpTZW50OiBGcmlkYXksIEFw cmlsIDgsIDIwMTYgNjoxMCBBTQ0KVG86IE5pbGFuamFuIFNhcmthcjsgU3VtYW5kcmEgTWFqZWUN CkNjOiBEYXZlIERvbHNvbjsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NmY10gQSByZXF1 ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0KSGkgTmlsYW5qYW4sIFN1bWFu ZHJhLCBEYXZlOg0KDQpBZ3JlZWQsIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSB0d28gcG9ydHMg KG9yIHR3byB2TklDcyksIHRoZW4gd2UgY2FuIHVzZSB0aGUgU0EgKG9yIFNJUCkgdG8gZGV0ZXJt aW5lIHRoZSBkaXJlY3Rpb24uDQoNClRob3VnaCB0aGlzIGRvZXMgbm90IHdvcmsgZm9yIGEgc2lu Z2xlIGFybWVkIFNGIEkgc3VzcGVjdCB0aGUgU0ZzIHdoaWNoIG5lZWQgdG8gZm9ybSByZXZlcnNl IHBhdGhzIGFyZSBkdWFsIGFybWVkIHRvZGF5LiBJZiB3ZSBzaW1wbHkgc2F5IHRoYXQgU0ZzIHdo aWNoIG5lZWQgdG8gcmV2ZXJzZSBkaXJlY3Rpb25zIGFsc28gbmVlZCB0byBiZSBkdWFsIGFybWVk LCB0aGVuIHRoaXMgY291bGQgYmUgYSB1bml2ZXJzYWwgc29sdXRpb24uIFRoZSBvdGhlciBuaWNl IHRoaW5nIGFib3V0IGl0IGlzIHRoYXQgaXQgd29ya3MgZm9yIG11bHRpLWFybWVkIGJyYW5jaGlu ZyBhbHNvLiBTbyBpZiBJIGhhdmUgYW4gU0Ygd2l0aCBOIGVncmVzcyBwb3J0cyAob3Igdk5JQ3Mp IHRoZW4gdGhlIFNGIGNhbiBicmFuY2ggTiB3YXlzIHNpbXBseSBieSBzZW5kaW5nIHRvIHRoZSBj b3JyZWN0IGVncmVzcyBwb3J0LiBUaGlzIHNlZW1zIG5hdHVyYWwgZnJvbSBhbiBTRiBjb2Rpbmcg cG9pbnQgb2Ygdmlldy4NCg0KQ2hlZXJzLA0KDQpQYXVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE5pbGFuamFuIFNhcmthcg0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiAyOjE2IEFN DQpUbzogU3VtYW5kcmEgTWFqZWUgPFMuTWFqZWVARjUuY29tPg0KQ2M6IERhdmUgRG9sc29uIDxk ZG9sc29uQHNhbmR2aW5lLmNvbT47IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIEEg cmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNCldpbGwgYSBTRiBkZXZp Y2UgaGF2ZSAyIHBvcnRzPyBQcm9ibGVtIHdhcyB0byBmaW5kIGFuICBJUCBwYWNrZXQgZGlyZWN0 aW9uIGluIGEgc2luZ2xlIHBvcnQgU0YgZGV2aWNlLiBJbiBjYXNlIHRoZXJlIGFyZSAyIHBvcnRz LCBvbmUgaXMgY29ubmVjdGVkIHRvIHN1YnNjcmliZXJzIGFuZCBhbm90aGVyIGlzIGNvbm5lY3Rl ZCB0byBpbnRlcm5ldCwgdGhlbiB0aGVyZSBpcyBubyBpc3N1ZS4NCg0KUmVnYXJkcywNCk5pbGFu amFuDQooc2VudCBmcm9tIG15IG1vYmlsZSBwaG9uZSkNCg0KT24gOCBBcHIgMjAxNiAxMDoyMiwg U3VtYW5kcmEgTWFqZWUgPFMuTWFqZWVARjUuY29tPiB3cm90ZToNCg0K4oCLSSB0aGluayB0aGUg cGFydCBvZiB0aGUgcHJvYmxlbSBsaWVzIGluIHRoZSBkZWZpbml0aW9uIG9mIFVQIGFuZCBET1dO LiBTbyBsZXRzIHRha2Ugc29tZSB1c2UgY2FzZXMuDQoNCg0KYSkgSW4gY2FzZSBvZiBzZXJ2aWNl IHByb3ZpZGVyIG1hbnkgZnVuY3Rpb25zIHNpdHMgYXQgdGhlIGJvcmRlciBiZXR3ZWVuIG5ldHdv cmsvaW50ZXJuZXQgIGFuZCBzdWJzY3JpYmVyL3VzZXIuIFR5cGljYWxseSB0aGUgdHdvIHNpZGVz IG9mIHRoZSBib3JkZXIgaXMgZGVmaW5lZCBieSB3YXkgb2YgY29uZmlndXJhdGlvbiwgdGhpcyBp bnRlcmZhY2UvdHVubmVsIHBvaW50IHRvIHN1YnNjcmliZXIgc2lkZSBhbmQgdGhhdCBwb2ludHMg dG8gdGhlIGludGVybmV0LiBBbnl0aGluZyBpbmdyZXNzIG9uIHN1YnNjcmliZXIgc2lkZSBpcyBG Uk9NIHN1YnNjcmliZXIgYW5kIHZpY2UgdmVyc2EuIFRoZSBVUCBvciBET1dOIGlzIG5vdCBzbyB1 c2VmdWwuDQoNCg0KYikgQ29uc2lkZXIgYSB0eXBpY2FsIGNsaWVudCBzZXJ2ZXIuICBBc3N1bWlu ZyB5b3UgbWVhbiBVUDogY2xpZW50IC0+c2VydmVyL2ZpbmFsIGRlc3RpbmF0aW9uIGFuZCBET1dO IHRoZSBvdGhlciB3YXkuIEEgZmxvdyBhd2FyZSBzZXJ2aWNlIHdvdWxkIGhhdmUgc3RhdGUgU0lQ LT5ESVAgYXMgVVAgYW5kIERJUC0+U0lQIGFzIERPV04uIE90aGVycyBsaWtlIHJvdXRlciBldGMu IG1heSBub3QgY2FyZSBhdCBhbGwgYW5kIHRoYXQgaXMgZmluZS4NCg0KDQpJbiBjYXNlIG9mIHNl Y3VyaXR5IGRldmljZSB0aGUgaW5ib3VuZCBhbmQgb3V0Ym91bmQgKG9yIHpvbmVzKSBhcmUgZGVm aW5lZCBieSBjb25maWd1cmF0aW9uIHRoYXQgaXMgbG9jYWwgdG8gdGhhdCBlbnRpdHkuIFNvIGhh dmluZyBhIGNsYXNzaWZpZXIgc2F5IElOIG9yIE9VVCB3b3VsZCBiZSB3cm9uZyBpbiB0aGF0IGNh c2UuDQoNCg0KU3VtYW5kcmENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBB cHJpbCA3LCAyMDE2IDc6MTEgUE0NClRvOiBTdW1hbmRyYSBNYWplZTsgc2ZjQGlldGYub3JnDQpT dWJqZWN0OiBSRTogQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0K U3VtYW5kcmEgKGFuZCBvdGhlcnMgd2hvIGhhdmUgcXVlc3Rpb25lZCB0aGlzKSwgV2hhdCBkbyB5 b3UgbWVhbiBieSBkZXRlY3RpbmcgZGlyZWN0aW9uIGZyb20gdGhlIGVuY2Fwc3VsYXRlZCBwYWNr ZXQ/DQpJ4oCZbSBoYXZpbmcgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIGhvdyBvbmUgY291bGQgdGVs bCBmcm9tIGFuIGFyYml0cmFyeSBJUCBwYWNrZXQgd2hpY2ggZGlyZWN0aW9uIGl0IGlzIGdvaW5n Lg0KKFVubGVzcyBrbm93aW5nIHRoZSBJUCBhZGRyZXNzIGFsbG9jYXRpb24gc2NoZW1lIGluIHRo ZSBpbm5lciBuZXR3b3Jr4oCmPyAgVGhhdCB3b3VsZCBiZSBhcmR1b3VzLikNCg0KQW5kIHBvc3Np Ymx5IGluLWJvdW5kLCBvdXQtYm91bmQgYXJlIGJldHRlciBuYW1lcz8NCkkgZG9u4oCZdCBsaWtl IGZvcndhcmQvcmV2ZXJzZSBiZWNhdXNlIEkgY2Fu4oCZdCBndWVzcyB3aGljaCBpcyB3aGljaC4N Cg0KLURhdmUNCg0KRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiAxMjoyNyBQTQ0KVG86IERhdmUgRG9sc29u OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9j YXRpb24gc2NoZW1lcw0KDQoNCuKAi0RhdmUsDQoNCg0KDQpUaGUgdXNlIGNhc2UgeW91IGhhdmUg ZGVmaW5lZCBpcyBzdXBwb3J0ZWQgYnkgbW9zdCBkZXZpY2VzIGJ5IGJpbmRpbmcgcG9saWNpZXMg ZXhwbGljaXRseSBvbiwNCg0KICAgYSkgaW50ZXJmYWNlIG9yIGVxdWl2YWxlbnQNCg0KICAgYikg ZmxvdyBkaXJlY3Rpb24uIE1vc3QgZmxvdyBhd2FyZSBkZXZpY2VzIGhhcyB0byBkZXRlY3QgdG8g YW5kIGZyb20gY29ycmVjdGx5IHRvIGRvIGxvdCBvZiB0aG5ncyBjb3JyZWN0bHkuDQoNCg0KDQpT byB0aGUgcXVlc3Rpb24gaXMgd2hhdCBkbyB3ZSBnZXQgYnkgYWRkaW5nIHRoaXMgYml0PyBJIGFt IG9wcG9zZWQgdG8gdGhlIHRlcm0gVVAgYW5kIERPV04gKGZyb20gc2hvdyBwb2ludCBvZiB2aWV3 PyksIHJhdGhlciBmb3J3YXJkIGFuZCByZXZlcnNlIChldmVuIHRoYXQgaXMgY29uZnVzaW5nKS4N Cg0KDQoNClN1bWFuZHJhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBzZmMgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRk b2xzb25Ac2FuZHZpbmUuY29tPj4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgNiwgMjAxNiA3OjEz IEFNDQpUbzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2Zj XSBBIHJlcXVlc3QgZm9yIE1ldGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcw0KDQpUbyB0aG9zZSBh dXRob3JzIG9mIG1ldGFkYXRhIGFsbG9jYXRpb25zLCBJIGhhdmUgYSByZXF1ZXN0Lg0KSSBiZWxp ZXZlIG1hbnkgdHlwZXMgb2Ygc2VydmljZSBmdW5jdGlvbnMgYXJlIGdvaW5nIHRvIHdhbnQgdG8g ZGlzdGluZ3Vpc2ggdXAtbGluayB0cmFmZmljIGZyb20gZG93bi1saW5rIHRyYWZmaWMuDQpFLmcu LCBhIHNlY3VyaXR5IGRldmljZSB0cmVhdHMgaW4tYm91bmQgdG8gdGhlIHByb3RlY3RlZCBkZXZp Y2UgZGlmZmVyZW50bHkgZnJvbSBvdXQtYm91bmQuDQpFLmcuLCBhbiBhY2NvdW50aW5nIHN5c3Rl bSBuZWVkcyB0byBrbm93IHdoZXRoZXIgdG8gY2hhcmdlIHRoZSBzb3VyY2Ugb3IgZGVzdGluYXRp b24gbm9kZS4NCg0KU28gbXkgcmVxdWVzdCBpcyB0byBhbGxvY2F0ZSBhIGJpdCBmb3IgdXAtbGlu ay9kb3duLWxpbmsgZGlzY3JpbWluYXRpb24uDQpJIHRoaW5rIHRoZSBhbHRlcm5hdGl2ZSBpcyB0 byBjb25maWd1cmUgZWFjaCBTRiBhYm91dCBlYWNoIHBhdGggd2hldGhlciBpdCBpcyB1cCBvciBk b3duLCBvciB0byB1c2Ugc29tZXRoaW5nIGxpa2UgYW4gZXZlbi9vZGQgcGF0aCBJRCBzY2hlbWUu DQoNCkRvZXMgYW55b25lIGVsc2Ugc2VlIHRoaXMgYXMgdXNlZnVsPw0KDQpJIGJlbGlldmUgYWxs IG9mIHRoZSBhbGxvY2F0aW9uIGRyYWZ0cyBoYXZlIHJlc2VydmVkIGJpdHMuDQoNCg0KRGF2aWQg RG9sc29uDQpTZW5pb3IgU29mdHdhcmUgQXJjaGl0ZWN0DQpTYW5kdmluZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Tue Apr 26 10:17:54 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 051CD12D1D5 for ; Tue, 26 Apr 2016 10:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 QXOWzfUjDnZe for ; Tue, 26 Apr 2016 10:17:45 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5567D12D530 for ; Tue, 26 Apr 2016 10:17:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1FE09259F28; Tue, 26 Apr 2016 10:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461691065; bh=VsrrmBPEhP2kVKoXVOGXGn9tRt+Xuz6BYw+z0brCAy0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ddcdfT7D7IFhHZzh1ecZxzsj8diRbcwHOT7kvOL57DdkMWjC9FYyhjOBTPGz247Ce l/SLS6QBWPOBwQRp6mle9bR25wgvjYT8uLSbjUVn4cvpwV+b2+xvxl/CZsEIB1OjGO /uc3B4wdRXJaI8N8dc0MT2E7cVys+6pPrEcH06LI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0777D24097D; Tue, 26 Apr 2016 10:17:43 -0700 (PDT) To: Linda Dunbar , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: Date: Tue, 26 Apr 2016 13:17:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 17:17:53 -0000 With regard to Transport tunnel fragementation, that seems an issue for the transport protocol. I don't actually object to a sentence, but it does not seem that it will accomplish anything. With regard to packets fragmented by the source, I completely disagree with your assertion. If an SFF were to reassemble the packets, that would be a violation of its job. There is no reason for an SFF to reassemble a packet fragmented by the source. The classifier may have to do some interesting things in order to properly classify succeeding fragments, but that is an implementation issue (most commonly addressed with virtual reassembly, which doe snot delay the fragments.) We don't specity that. If an SF needs to reassemble fragments to do its job, that is up to the SF. Some will need to actually reassemble. Some will need to perform virtual reassembly, and some will happily process the fragments. I can not see what the NSH document could possibly mandate. Yours, Joel On 4/26/16 11:47 AM, Linda Dunbar wrote: > Joel, > > I think the document should add the description on the following two > fragmentation scenarios: > > - Transport tunnel generated fragmentation: When a packet > fragmentation is caused by transport tunnel (i.e. various > encapsulations), the termination point of the transport tunnel is > responsible for re-assembling the fragmented pieces of the packet. > Since there won't be any SFF nodes in between the Transport Tunnel, > the tunnel generated fragmentation does not require any actions by > SFF nodes or SF nodes. > > > - Source node generated fragmentation (after adding on the NSH > header): When fragmentation has to be performed for a packet being > encapsulated with the NSH header, either the intermediate SFF nodes > or the SF nodes have to be able to reassemble the fragmented pieces. > > > > > Cheers, > > > Linda > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; > sfc@ietf.org Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that you are referring only to > the case of transport generated fragmentation of the outer packet. I > had assumed you were not talking about that, since the resulting > fragments will not all have NSH headers. As with any tunnel > technology, if the tunnel chooses to fragment at its layer, then the > tunnel is responsible for reassembly. That would be invisible to the > SFF. > > Yours, Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: >> Agree with Med. >> >> Even if each fragment piece of a packet with NSH header carries the >> NSH header, the intermediate SFF nodes still need to put together >> all the fragments together before passing the whole data frame to >> the SF. >> >> Linda >> >> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer to ALWAYS prepend an NSH >> header even for fragments? Or you don't care about that? >> >> Thank you. >> >> Cheers, Med >> >>> -----Message d'origine----- De : Elzur, Uri >>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 16:26 À >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet >>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>> *NOT* a transport, dealing with fragmentation is left to the >>> Transport used. >>> >>> The model I use for NSH, is basically similar to VXLAN . It is an >>> overly. >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com Sent: Monday, April 25, 2016 7:18 >>> AM To: Joel M. Halpern ; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, >>> >>> Please see inline. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 avril 2016 15:48 >>>> À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] >>>> WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> If I am understanding you correctly Med, you are asking that >>>> the NSH draft specify how service chaining should cope with >>>> packets that have been fragmented? >>>> >>> >>> [Med] To be accurate, I'm asking to assess whether there are >>> implications. If there are, then the draft should be updated >>> accordingly. >>> >>>> NSH, and the SFF functionality, does not care. >>> >>> [Med] I'm not that sure. Some typical implications are listed >>> below: >>> >>> * SFF: If the NSH header is present only in the a fragment but >>> SFF didn't maintained a state, subsequent fragments won't be >>> appropriately processed. * SFC-aware function: if prepending a >>> context information depends on the full packet, not only a >>> fragment. >>> >>> It just does its job. >>> >>> [Med] which may be disturbed in some situations as listed in the >>> examples above. >>> >>>> Ingress and intermediate classifiers may cope with fragments in >>>> any number of ways. >>> Specifying such is clearly out of scope for this draft. >>> >>> [Med] The purpose is not to specify the internal implementation >>> details but the external behavior of the classifier function when >>> it comes to handle fragments. That behavior may have an incidence >>> on SFF, in particular. The purpose is not to recommend the >>> maximum resources to be dedicated to out of order fragments nor >>> the timeout to cache those; these considerations are of course >>> out of scope. Nevertheless, an implementation should offer a >>> configurable parameter so that an operator tweak those according >>> to its context. >>> >>>> I suppose one could write an informational draft on possible >>>> ways of coping. The IETF has not usually published such. >>>> Service functions have to cope with fragmented packets just as >>>> they had to before the advent of NSH, so describing that is >>>> clearly not needed here. >>> >>> [Med] The advent of NSH has the following implications: * it >>> exacerbates fragmentation. Handing over this issue to the >>> transport layer may lead to interoperability issues. * the >>> chaining may not be efficient if fragments are inappropriately >>> handled. >>> >>> Introducing NSH should not degrade the overall service compared >>> to legacy service deployment schemes. >>> >>>> >>>> Yours, Joel >>>> >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> I hear you, but my comment is that we need, as a WG, to >>>>> decide what to >>>> put in the draft. FWIW, I'm discussing two fragmentation >>>> issues: >>>>> >>>>> (1) Fragmentation that is caused by prepending an SFC >>>>> header. (2) Handling fragments at the ingress of an >>>>> SFC-enabled domain. >>>>> >>>>> Increasing the MTU is for sure a recommendation is to be >>>>> explicitly >>>> called out in the text (see my first message). >>>>> >>>>> There are other issues that need to be discussed, e.g., how >>>>> to deal with >>>> fragments in SFFs/Classifiers? >>>>> >>>>> It is also "prudent" to check that no issues will be >>>>> experienced in SFF >>>> to handle fragments. If an SFC header is prepended for all >>>> fragments, I'm not sure there >>>>> is any particular issue at the SFF level, except if >>>>> stripping/adding >>>> context TLVs depends on the full packet (not just fragment). It >>>> is warranted to consider a little bit this point before >>>> declaring there is no issue. >>>>> >>>>> For point (1), declaring fragmentation out of scope would be >>>>> meant that >>>> an implementation must be prepared to receive fragments with >>>> or without NSH header as this is a decision that is left to >>>> the transport encapsulation. This is a requirement per se! >>>>> >>>>> I won't reiterate all the comments I have about the current >>>>> wording of >>>> this section. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 >>>>>> 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> My point is that Fragmentation is yet another transport >>>>>> related issue >>>> that >>>>>> is beyond the scope of NSH and beyond the charter of the >>>>>> WG, so it >>>> doesn't >>>>>> really belong in the draft. We are providing an advice as >>>>>> extending the size of the packet may lead to fragmentation, >>>>>> but as you check RFC 7348 VxLAN, which my create the same >>>>>> issue, you'll find it doesn't even >>>> relate >>>>>> to it. >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 >>>>>> 10:32 PM To: Elzur, Uri ; Thomas >>>>>> Narten >>>> ; >>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Uri, >>>>>> >>>>>> That's another option that needs to be >>>>>> discussed/investigated. I'm >>>> afraid >>>>>> this is not the rationale adopted in -04 since it includes >>>>>> some text >>>> that >>>>>> is far to be sufficient to ensure interoperable >>>>>> implementations. >>>>>> >>>>>> BTW, saying that nsh does not need to deal with >>>>>> fragmentation because >>>> it >>>>>> is transport-independent is not IMHO a good strategy to >>>>>> adopt here >>>> because >>>>>> it opens the door for interoperable issues, it may lead to >>>>>> sub-optimal implementations if the sfc information is >>>>>> present only in one >>>> fragments, >>>>>> etc. >>>>>> >>>>>> My comments are related to the current text in the -04. >>>>>> This text needs >>>> to >>>>>> be fixed somehow. >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>> [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 avril >>>>>>> 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> I see no need to specify the exact behavior as NSH is >>>>>>> transport independent i.e. like NSH interaction with any >>>>>>> other Transport eh issue of Fragmentation is to be dealt >>>>>>> in a way that matches the mechanisms supported by the >>>>>>> Transport used and do not belong in the NSH draft >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14, >>>>>>> 2016 12:43 AM To: Thomas Narten ; >>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> R-, >>>>>>> >>>>>>> In addition to other pending issues raised for this >>>>>>> draft, I would like to raise this additional one about >>>>>>> Section 6. >>>>>>> >>>>>>> == 6. Fragmentation Considerations >>>>>>> >>>>>>> NSH and the associated transport header are "added" to >>>>>>> the encapsulated packet/frame. This additional >>>>>>> information increases >>>> the >>>>>>> size of the packet. In order the ensure proper >>>>>>> forwarding of NSH data, several options for handling >>>>>>> fragmentation and re-assembly exist: >>>>>>> >>>>>>> 1. Jumbo Frames, when supported, enable the transport of >>>>>>> NSH and associated transport packets without requiring >>>>>>> fragmentation. >>>>>>> >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique >>>>>>> for dynamically discovering the maximum transmission >>>>>>> unit (MTU) of >>>> an >>>>>>> arbitrary internet path" and can be utilized to ensure >>>>>>> the >>> the >>>>>>> required packet size is used. >>>>>>> >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>> re- >>>> assembly >>>>>>> in section 5.4. == >>>>>>> >>>>>>> * The text is weak for a Standard track document that is >>>>>>> intended to solve the problem in >>>>>>> https://tools.ietf.org/html/rfc7498#section- >>> 2.12. >>>>>>> There should be a clear behavior to be followed by an >>> implementation. >>>>>>> Further, I would avoid the use of words such as "can". >>>>>>> >>>>>>> * The text covers only fragmentation when it is induced >>>>>>> by SFC operations, it does not discuss the treatment of a >>>>>>> fragment when received in an SFC domain. IMHO, the draft >>>>>>> should also specify the behavior of the Classifier with >>>>>>> regards to fragments for the sake of proper SFC >>>>>>> operation. Applying classification policies may require >>>>>>> the >>>>>> full packet, not only a fragment. >>>>>>> In particular, dedicated resources should dedicated for >>>>>>> handling out of order fragments. Of course, it is out of >>>>>>> scope of this document to describe how SFs handle >>>>>>> fragments. >>>>>>> >>>>>>> * If an SFC header is prepended for all fragments, I'm >>>>>>> not sure there is any particular issue at the SFF >>>>>>> level...except if stripping/adding context TLVs depends >>>>>>> on the full packet (not just fragment). It is warranted >>>>>>> to consider a little bit this point before declaring >>>>>>> there >>>> is >>>>>> no issue. >>>>>>> >>>>>>> * The text states "several options". This may be >>>>>>> interpreted as if implementing one of them is >>>>>>> sufficient...which is not true. The first two points >>>>>>> contribute to minimize the fragmentation risk, but >>>>>>> fragmentation may still be experienced (e.g., other shims >>>>>>> are prepended by other nodes for some other purposes, >>>>>>> nested nsh, etc.) >>>>>>> >>>>>>> * The first two points have nothing to do with >>>>>>> reassembly. >>>>>>> >>>>>>> * The support of jumbo frames by a router/device does not >>>>>>> mean that it can make use of it. Appropriate MTU >>>>>>> configuration should be undertaken in a consistent manner >>>>>>> within an SFC domain. The text should be updated to make >>>>>>> it is about (consistent) MTU >>> configuration. >>>>>>> >>>>>>> * BTW, shouldn't the text be reworded to recommended to >>>>>>> increase the MTU of **all nodes** of an SFC-enabled >>>>>>> domain by at least the length of SFC header + transport >>>>>>> header? >>>>>>> >>>>>>> * Bullet 2, how PMTU discovery is actually used in this >>>>>>> context? Do you assume that all SFC-aware nodes will >>>>>>> issue such messages towards other SFC-aware node, >>>>>>> arbitrary destination, else? >>>>>>> >>>>>>> * Bullet 2, I would drop "describes a technique for >>>>>>> dynamically discovering the maximum transmission unit >>>>>>> (MTU) of an arbitrary internet path". >>>>>>> >>>>>>> * Bullet 2, s/ the the/the. >>>>>>> >>>>>>> * The reference to the LISP specification raises two >>>>>>> concerns and one comment: >>>>>>> >>>>>>> (1) I don't think it is a good approach that fragments >>>>>>> induced by the network are passed to their ultimate >>>>>>> destinations as such >>> (stateless). >>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>> (responsible for fragmentation) not passed away. (2) Does >>>>>>> the stateful mode require all SFC data plane elements >>>>>>> maintain a full list of MTU for the any SFF/SF instance >>>>>>> of the SFC >>>>>> domain? >>>>>>> >>>>>>> The current text suggests that [RFC6830] should be listed >>>>>>> as normative reference (not an informative one). I would >>>>>>> personally favor removing the reference to LISP (as it is >>>>>>> an Experimental RFC). >>>>>>> >>>>>>> * The security section of the draft may be augmented >>>>>>> with informational fragmentation-related pointers to: >>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>> Filtering), RFC3128 (Protection Against a Variant of the >>>>>>> Tiny Fragment Attack), and RFC 4963 (IPv4 Reassembly >>>>>>> Errors at High Data Rates). >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril >>>>>>>> 2016 13:14 À : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear Thomas, all, >>>>>>>> >>>>>>>> As I mentioned during the meeting, there are several >>>>>>>> issues that are not covered in the last version of the >>>>>>>> draft. I already provided examples of the issues >>>>>>>> offline as requested by Martin. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>>> Narten Envoyé : jeudi 31 mars 2016 04:48 À : >>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> This note begins a WG last call on >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>> >>>>>>>>> >>>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>>> addressed all known comments and that there are no >>>>>>>>> open issues with the current version of the >>>>>>>>> document. >>>>>>>>> >>>>>>>>> Substantive comments to the list please, editorial >>>>>>>>> comments can go directly to the document editors. >>>>>>>>> >>>>>>>>> We'll also get a brief update from the editors at >>>>>>>>> next week's meeting. If there are any remaining >>>>>>>>> issues with the document, raising them before the >>>>>>>>> meeting would be especially helpful. >>>>>>>>> >>>>>>>>> For the chairs, Thomas >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc >>>>>>>> mailing list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing >>>>>> list sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ 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 Tue Apr 26 10:21: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 321A712D1D5 for ; Tue, 26 Apr 2016 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 oW32AvPwK-mf for ; Tue, 26 Apr 2016 10:21:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C35212B02A for ; Tue, 26 Apr 2016 10:21:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2E387258B1E; Tue, 26 Apr 2016 10:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461691310; bh=8hDtr3txZHRqJaTKYrV+s1tkKXWnxinRaZEtPdoC2OA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SLgrhXKtdIE4lZAaR2BcA0O5WN7QhyaX1bUjDHDVX8EGwZ586oOsVPu8s9+HHZKXW ibnzMwI2V2/j9dKR5stNDBmq+fJCvCySee1MPY5NMOudjO1nV3cAQAIXYQxNiESO3G T48Mb/KtqFZbnlNXzSr/4bmuHznbV9tTo/ewS+wI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0CBBE24EB23; Tue, 26 Apr 2016 10:21:48 -0700 (PDT) To: Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> Date: Tue, 26 Apr 2016 13:21:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 17:21:53 -0000 At least so far, we have treated the communication between classifier and SFF (ingress or intermediate) as outside of the scope of our work. For SF <-> SFF communication we have ntoed the need for a proxy to handle the case when the SF can not accept and return the NSH header, since we assume that is preserved. Other than that preservation, similar to the above, we have treated the details as outside of our scope. That is because they depend so heavily on the implementation technique used. (Hypervisor ,_> application communication vs communication inside a user space or communication over an actual Ethernet are all very different.) Trying to extend the NSH document to address these would be a major change, and would step into the issues related to transport selection, which are explicitly out of scope. Yours, Joel On 4/26/16 11:58 AM, Ron Parker wrote: > Linda, > > I like the first clause (transport tunnel based fragmentation). > > Regarding the second (source based), I think there are more subcases to consider: > > 1. Propagation of NSH encapsulated packet from classifier to SFF > 2. Propagation of NSH encapsulated packet from SFF to SF > 3. Propagation of NSH encapsulated packet from SF to SFF (including possibility that NSH size increased at SF) > 4. Propagation of NSH encapsulated packet from SFF to SFF > > In each of the 4 cases above, there is the possibility that MTU will be exceeded and therefore there are procedures to be defined in that eventuality. > > Thanks. > > Ron > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Tuesday, April 26, 2016 11:48 AM > To: Joel M. Halpern ; mohamed.boucadair@orange.com; Elzur, Uri ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Joel, > > I think the document should add the description on the following two fragmentation scenarios: > > - Transport tunnel generated fragmentation: > When a packet fragmentation is caused by transport tunnel (i.e. various encapsulations), the termination point of the transport tunnel is responsible for re-assembling the fragmented pieces of the packet. Since there won't be any SFF nodes in between the Transport Tunnel, the tunnel generated fragmentation does not require any actions by SFF nodes or SF nodes. > > > - Source node generated fragmentation (after adding on the NSH header): > When fragmentation has to be performed for a packet being encapsulated with the NSH header, either the intermediate SFF nodes or the SF nodes have to be able to reassemble the fragmented pieces. > > > > Cheers, > > > Linda > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 26, 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that you are referring only to the case of transport generated fragmentation of the outer packet. I had assumed you were not talking about that, since the resulting fragments will not all have NSH headers. As with any tunnel technology, if the tunnel chooses to fragment at its layer, then the tunnel is responsible for reassembly. That would be invisible to the SFF. > > Yours, > Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: >> Agree with Med. >> >> Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. >> >> Linda >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 9:42 AM >> To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that? >> >> Thank you. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril >>> 2016 16:26 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* >>> a transport, dealing with fragmentation is left to the Transport used. >>> >>> The model I use for NSH, is basically similar to VXLAN . It is an overly. >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Monday, April 25, 2016 7:18 AM >>> To: Joel M. Halpern ; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 >>>> avril 2016 15:48 À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> If I am understanding you correctly Med, you are asking that the NSH >>>> draft specify how service chaining should cope with packets that >>>> have been fragmented? >>>> >>> >>> [Med] To be accurate, I'm asking to assess whether there are implications. >>> If there are, then the draft should be updated accordingly. >>> >>>> NSH, and the SFF functionality, does not care. >>> >>> [Med] I'm not that sure. Some typical implications are listed below: >>> >>> * SFF: If the NSH header is present only in the a fragment but SFF >>> didn't maintained a state, subsequent fragments won't be appropriately processed. >>> * SFC-aware function: if prepending a context information depends on >>> the full packet, not only a fragment. >>> >>> It just does its job. >>> >>> [Med] which may be disturbed in some situations as listed in the >>> examples above. >>> >>>> Ingress and intermediate classifiers may cope with fragments in any >>>> number of ways. >>> Specifying such is clearly out of scope for this draft. >>> >>> [Med] The purpose is not to specify the internal implementation >>> details but the external behavior of the classifier function when it >>> comes to handle fragments. That behavior may have an incidence on >>> SFF, in particular. The purpose is not to recommend the maximum >>> resources to be dedicated to out of order fragments nor the timeout >>> to cache those; these considerations are of course out of scope. >>> Nevertheless, an implementation should offer a configurable parameter >>> so that an operator tweak those according to its context. >>> >>>> I suppose one could write an informational draft on possible ways >>>> of coping. The IETF has not usually published such. >>>> Service functions have to cope with fragmented packets just as they >>>> had to before the advent of NSH, so describing that is clearly not >>>> needed here. >>> >>> [Med] The advent of NSH has the following implications: >>> * it exacerbates fragmentation. Handing over this issue to the >>> transport layer may lead to interoperability issues. >>> * the chaining may not be efficient if fragments are inappropriately >>> handled. >>> >>> Introducing NSH should not degrade the overall service compared to >>> legacy service deployment schemes. >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> I hear you, but my comment is that we need, as a WG, to decide what >>>>> to >>>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>>> >>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>> >>>>> Increasing the MTU is for sure a recommendation is to be explicitly >>>> called out in the text (see my first message). >>>>> >>>>> There are other issues that need to be discussed, e.g., how to deal >>>>> with >>>> fragments in SFFs/Classifiers? >>>>> >>>>> It is also "prudent" to check that no issues will be experienced in >>>>> SFF >>>> to handle fragments. If an SFC header is prepended for all >>>> fragments, I'm not sure there >>>>> is any particular issue at the SFF level, except if >>>>> stripping/adding >>>> context TLVs depends on the full packet (not just fragment). It is >>>> warranted to consider a little bit this point before declaring there >>>> is no issue. >>>>> >>>>> For point (1), declaring fragmentation out of scope would be meant >>>>> that >>>> an implementation must be prepared to receive fragments with or >>>> without NSH header as this is a decision that is left to the >>>> transport encapsulation. This is a requirement per se! >>>>> >>>>> I won't reiterate all the comments I have about the current wording >>>>> of >>>> this section. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 >>>>>> avril 2016 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> My point is that Fragmentation is yet another transport related >>>>>> issue >>>> that >>>>>> is beyond the scope of NSH and beyond the charter of the WG, so it >>>> doesn't >>>>>> really belong in the draft. We are providing an advice as >>>>>> extending the size of the packet may lead to fragmentation, but as >>>>>> you check RFC 7348 VxLAN, which my create the same issue, you'll >>>>>> find it doesn't even >>>> relate >>>>>> to it. >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>>> To: Elzur, Uri ; Thomas Narten >>>> ; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Uri, >>>>>> >>>>>> That's another option that needs to be discussed/investigated. >>>>>> I'm >>>> afraid >>>>>> this is not the rationale adopted in -04 since it includes some >>>>>> text >>>> that >>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>> >>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>> because >>>> it >>>>>> is transport-independent is not IMHO a good strategy to adopt here >>>> because >>>>>> it opens the door for interoperable issues, it may lead to >>>>>> sub-optimal implementations if the sfc information is present only >>>>>> in one >>>> fragments, >>>>>> etc. >>>>>> >>>>>> My comments are related to the current text in the -04. This text >>>>>> needs >>>> to >>>>>> be fixed somehow. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : dimanche >>>>>>> 24 avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>>> independent i.e. like NSH interaction with any other Transport eh >>>>>>> issue of Fragmentation is to be dealt in a way that matches the >>>>>>> mechanisms supported by the Transport used and do not belong in >>>>>>> the NSH draft >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") >>>>>>> C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> R-, >>>>>>> >>>>>>> In addition to other pending issues raised for this draft, I >>>>>>> would like to raise this additional one about Section 6. >>>>>>> >>>>>>> == >>>>>>> 6. Fragmentation Considerations >>>>>>> >>>>>>> NSH and the associated transport header are "added" to the >>>>>>> encapsulated packet/frame. This additional information >>>>>>> increases >>>> the >>>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>>> data, several options for handling fragmentation and re-assembly >>>>>>> exist: >>>>>>> >>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>>> associated transport packets without requiring fragmentation. >>>>>>> >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>> dynamically discovering the maximum transmission unit >>>>>>> (MTU) of >>>> an >>>>>>> arbitrary internet path" and can be utilized to ensure the >>> the >>>>>>> required packet size is used. >>>>>>> >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>>> assembly >>>>>>> in section 5.4. >>>>>>> == >>>>>>> >>>>>>> * The text is weak for a Standard track document that is intended >>>>>>> to solve the problem in >>>>>>> https://tools.ietf.org/html/rfc7498#section- >>> 2.12. >>>>>>> There should be a clear behavior to be followed by an >>> implementation. >>>>>>> Further, I would avoid the use of words such as "can". >>>>>>> >>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>> operations, it does not discuss the treatment of a fragment when >>>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>>> the behavior of the Classifier with regards to fragments for the >>>>>>> sake of proper SFC operation. Applying classification policies >>>>>>> may require the >>>>>> full packet, not only a fragment. >>>>>>> In particular, dedicated resources should dedicated for handling >>>>>>> out of order fragments. Of course, it is out of scope of this >>>>>>> document to describe how SFs handle fragments. >>>>>>> >>>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>>> there is any particular issue at the SFF level...except if >>>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>>> just fragment). It is warranted to consider a little bit this >>>>>>> point before declaring there >>>> is >>>>>> no issue. >>>>>>> >>>>>>> * The text states "several options". This may be interpreted as >>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>> The first two points contribute to minimize the fragmentation >>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>> nested nsh, >>>>>>> etc.) >>>>>>> >>>>>>> * The first two points have nothing to do with reassembly. >>>>>>> >>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>>> text should be updated to make it is about (consistent) MTU >>> configuration. >>>>>>> >>>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least the >>>>>>> length of SFC header + transport header? >>>>>>> >>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>> >>>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>>>> internet path". >>>>>>> >>>>>>> * Bullet 2, s/ the the/the. >>>>>>> >>>>>>> * The reference to the LISP specification raises two concerns and >>>>>>> one >>>>>>> comment: >>>>>>> >>>>>>> (1) I don't think it is a good approach that fragments induced by >>>>>>> the network are passed to their ultimate destinations as such >>> (stateless). >>>>>>> IMO, reassembly should be done within the SFC domain (responsible >>>>>>> for >>>>>>> fragmentation) not passed away. >>>>>>> (2) Does the stateful mode require all SFC data plane elements >>>>>>> maintain a full list of MTU for the any SFF/SF instance of the >>>>>>> SFC >>>>>> domain? >>>>>>> >>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>> normative reference (not an informative one). I would personally >>>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>>> >>>>>>> * The security section of the draft may be augmented with >>>>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and >>>>>>> RFC >>>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril 2016 13:14 À : >>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear Thomas, all, >>>>>>>> >>>>>>>> As I mentioned during the meeting, there are several issues that >>>>>>>> are not covered in the last version of the draft. I already >>>>>>>> provided examples of the issues offline as requested by Martin. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>>> Narten Envoyé : jeudi 31 mars 2016 04:48 À : sfc@ietf.org Objet >>>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>> >>>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>>> addressed all known comments and that there are no open issues >>>>>>>>> with the current version of the document. >>>>>>>>> >>>>>>>>> Substantive comments to the list please, editorial comments can >>>>>>>>> go directly to the document editors. >>>>>>>>> >>>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>> >>>>>>>>> For the chairs, >>>>>>>>> Thomas >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Apr 26 11:39:01 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 B0F8B12D56E for ; Tue, 26 Apr 2016 11:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 okFMMa7OXIzW for ; Tue, 26 Apr 2016 11:38:56 -0700 (PDT) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CFF12B029 for ; Tue, 26 Apr 2016 11:38:56 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0266.001; Tue, 26 Apr 2016 11:38:56 -0700 From: Ron Parker To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPjVJMNJL6xkKtVPhZYT1+65+Er+AwgARg/TCAEMylAIAA6WYAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAGaMQCAAAZigIAABDUA//+L/bCAAI4zAP//nyBQ Date: Tue, 26 Apr 2016 18:38:55 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> In-Reply-To: <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 18:38:59 -0000 Joel, I can't say that I disagree with your analysis on the scope. I think the = question raised by some on the thread is if an SFC-node (i.e., classifier, = SF, SFF) creates fragments, is the NSH header repeated in each fragment ? = I think the answer is "no". If so, is it worth stating this explicitly = in the document, or is it just obvious that properly layered systems would = behave that way. Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, April 26, 2016 1:22 PM To: Ron Parker ; Joel M. Halpern ; mohamed.boucadair@orange.com; Elzur, Uri ; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt At least so far, we have treated the communication between classifier and S= FF (ingress or intermediate) as outside of the scope of our work.=20 For SF <-> SFF communication we have ntoed the need for a proxy to handle t= he case when the SF can not accept and return the NSH header, since we assu= me that is preserved. Other than that preservation, similar to the above, = we have treated the details as outside of our scope. That is because they d= epend so heavily on the implementation technique used. (Hypervisor ,_> app= lication communication vs communication inside a user space or communicatio= n over an actual Ethernet are all very different.) Trying to extend the NSH document to address these would be a major change,= and would step into the issues related to transport selection, which are e= xplicitly out of scope. Yours, Joel On 4/26/16 11:58 AM, Ron Parker wrote: > Linda, > > I like the first clause (transport tunnel based fragmentation). > > Regarding the second (source based), I think there are more subcases to c= onsider: > > 1. Propagation of NSH encapsulated packet from classifier to SFF 2. =20 > Propagation of NSH encapsulated packet from SFF to SF 3. Propagation=20 > of NSH encapsulated packet from SF to SFF (including possibility that=20 > NSH size increased at SF) 4. Propagation of NSH encapsulated packet=20 > from SFF to SFF > > In each of the 4 cases above, there is the possibility that MTU will be = exceeded and therefore there are procedures to be defined in that eventuali= ty. > > Thanks. > > Ron > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar > Sent: Tuesday, April 26, 2016 11:48 AM > To: Joel M. Halpern ;=20 > mohamed.boucadair@orange.com; Elzur, Uri ;=20 > sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Joel, > > I think the document should add the description on the following two frag= mentation scenarios: > > - Transport tunnel generated fragmentation: > When a packet fragmentation is caused by transport tunnel (i.e. various= encapsulations), the termination point of the transport tunnel is responsi= ble for re-assembling the fragmented pieces of the packet. Since there won'= t be any SFF nodes in between the Transport Tunnel, the tunnel generated fr= agmentation does not require any actions by SFF nodes or SF nodes. > > > - Source node generated fragmentation (after adding on the NSH header): > When fragmentation has to be performed for a packet being encapsulated= with the NSH header, either the intermediate SFF nodes or the SF nodes hav= e to be able to reassemble the fragmented pieces. > > > > Cheers, > > > Linda > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 26, 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;=20 > sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that you are referring only to the c= ase of transport generated fragmentation of the outer packet. I had assume= d you were not talking about that, since the resulting fragments will not a= ll have NSH headers. As with any tunnel technology, if the tunnel chooses = to fragment at its layer, then the tunnel is responsible for reassembly. T= hat would be invisible to the SFF. > > Yours, > Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: >> Agree with Med. >> >> Even if each fragment piece of a packet with NSH header carries the NSH = header, the intermediate SFF nodes still need to put together all the fragm= ents together before passing the whole data frame to the SF. >> >> Linda >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >> mohamed.boucadair@orange.com >> Sent: Monday, April 25, 2016 9:42 AM >> To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer to ALWAYS prepend an NSH header = even for fragments? Or you don't care about that? >> >> Thank you. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril >>> 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;=20 >>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT*=20 >>> a transport, dealing with fragmentation is left to the Transport used. >>> >>> The model I use for NSH, is basically similar to VXLAN . It is an overl= y. >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>> mohamed.boucadair@orange.com >>> Sent: Monday, April 25, 2016 7:18 AM >>> To: Joel M. Halpern ; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25= =20 >>>> avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> If I am understanding you correctly Med, you are asking that the=20 >>>> NSH draft specify how service chaining should cope with packets=20 >>>> that have been fragmented? >>>> >>> >>> [Med] To be accurate, I'm asking to assess whether there are implicatio= ns. >>> If there are, then the draft should be updated accordingly. >>> >>>> NSH, and the SFF functionality, does not care. >>> >>> [Med] I'm not that sure. Some typical implications are listed below: >>> >>> * SFF: If the NSH header is present only in the a fragment but SFF=20 >>> didn't maintained a state, subsequent fragments won't be appropriately = processed. >>> * SFC-aware function: if prepending a context information depends on=20 >>> the full packet, not only a fragment. >>> >>> It just does its job. >>> >>> [Med] which may be disturbed in some situations as listed in the=20 >>> examples above. >>> >>>> Ingress and intermediate classifiers may cope with fragments in any=20 >>>> number of ways. >>> Specifying such is clearly out of scope for this draft. >>> >>> [Med] The purpose is not to specify the internal implementation=20 >>> details but the external behavior of the classifier function when it=20 >>> comes to handle fragments. That behavior may have an incidence on=20 >>> SFF, in particular. The purpose is not to recommend the maximum=20 >>> resources to be dedicated to out of order fragments nor the timeout=20 >>> to cache those; these considerations are of course out of scope. >>> Nevertheless, an implementation should offer a configurable=20 >>> parameter so that an operator tweak those according to its context. >>> >>>> I suppose one could write an informational draft on possible ways=20 >>>> of coping. The IETF has not usually published such. >>>> Service functions have to cope with fragmented packets just as they=20 >>>> had to before the advent of NSH, so describing that is clearly not=20 >>>> needed here. >>> >>> [Med] The advent of NSH has the following implications: >>> * it exacerbates fragmentation. Handing over this issue to the=20 >>> transport layer may lead to interoperability issues. >>> * the chaining may not be efficient if fragments are inappropriately=20 >>> handled. >>> >>> Introducing NSH should not degrade the overall service compared to=20 >>> legacy service deployment schemes. >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> I hear you, but my comment is that we need, as a WG, to decide=20 >>>>> what to >>>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>>> >>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>> >>>>> Increasing the MTU is for sure a recommendation is to be=20 >>>>> explicitly >>>> called out in the text (see my first message). >>>>> >>>>> There are other issues that need to be discussed, e.g., how to=20 >>>>> deal with >>>> fragments in SFFs/Classifiers? >>>>> >>>>> It is also "prudent" to check that no issues will be experienced=20 >>>>> in SFF >>>> to handle fragments. If an SFC header is prepended for all=20 >>>> fragments, I'm not sure there >>>>> is any particular issue at the SFF level, except if=20 >>>>> stripping/adding >>>> context TLVs depends on the full packet (not just fragment). It is=20 >>>> warranted to consider a little bit this point before declaring=20 >>>> there is no issue. >>>>> >>>>> For point (1), declaring fragmentation out of scope would be meant=20 >>>>> that >>>> an implementation must be prepared to receive fragments with or=20 >>>> without NSH header as this is a decision that is left to the=20 >>>> transport encapsulation. This is a requirement per se! >>>>> >>>>> I won't reiterate all the comments I have about the current=20 >>>>> wording of >>>> this section. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25=20 >>>>>> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> My point is that Fragmentation is yet another transport related=20 >>>>>> issue >>>> that >>>>>> is beyond the scope of NSH and beyond the charter of the WG, so=20 >>>>>> it >>>> doesn't >>>>>> really belong in the draft. We are providing an advice as=20 >>>>>> extending the size of the packet may lead to fragmentation, but=20 >>>>>> as you check RFC 7348 VxLAN, which my create the same issue,=20 >>>>>> you'll find it doesn't even >>>> relate >>>>>> to it. >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") >>>>>> C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>> mohamed.boucadair@orange.com >>>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>>> To: Elzur, Uri ; Thomas Narten >>>> ; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Uri, >>>>>> >>>>>> That's another option that needs to be discussed/investigated. >>>>>> I'm >>>> afraid >>>>>> this is not the rationale adopted in -04 since it includes some=20 >>>>>> text >>>> that >>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>> >>>>>> BTW, saying that nsh does not need to deal with fragmentation=20 >>>>>> because >>>> it >>>>>> is transport-independent is not IMHO a good strategy to adopt=20 >>>>>> here >>>> because >>>>>> it opens the door for interoperable issues, it may lead to=20 >>>>>> sub-optimal implementations if the sfc information is present=20 >>>>>> only in one >>>> fragments, >>>>>> etc. >>>>>> >>>>>> My comments are related to the current text in the -04. This text=20 >>>>>> needs >>>> to >>>>>> be fixed somehow. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche >>>>>>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas=20 >>>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> I see no need to specify the exact behavior as NSH is transport=20 >>>>>>> independent i.e. like NSH interaction with any other Transport=20 >>>>>>> eh issue of Fragmentation is to be dealt in a way that matches=20 >>>>>>> the mechanisms supported by the Transport used and do not belong=20 >>>>>>> in the NSH draft >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") >>>>>>> C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> R-, >>>>>>> >>>>>>> In addition to other pending issues raised for this draft, I=20 >>>>>>> would like to raise this additional one about Section 6. >>>>>>> >>>>>>> =3D=3D >>>>>>> 6. Fragmentation Considerations >>>>>>> >>>>>>> NSH and the associated transport header are "added" to the >>>>>>> encapsulated packet/frame. This additional information=20 >>>>>>> increases >>>> the >>>>>>> size of the packet. In order the ensure proper forwarding of NS= H >>>>>>> data, several options for handling fragmentation and re-assembly >>>>>>> exist: >>>>>>> >>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH an= d >>>>>>> associated transport packets without requiring fragmentation= . >>>>>>> >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>> dynamically discovering the maximum transmission unit >>>>>>> (MTU) of >>>> an >>>>>>> arbitrary internet path" and can be utilized to ensure=20 >>>>>>> the >>> the >>>>>>> required packet size is used. >>>>>>> >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>>> assembly >>>>>>> in section 5.4. >>>>>>> =3D=3D >>>>>>> >>>>>>> * The text is weak for a Standard track document that is=20 >>>>>>> intended to solve the problem in >>>>>>> https://tools.ietf.org/html/rfc7498#section- >>> 2.12. >>>>>>> There should be a clear behavior to be followed by an >>> implementation. >>>>>>> Further, I would avoid the use of words such as "can". >>>>>>> >>>>>>> * The text covers only fragmentation when it is induced by SFC=20 >>>>>>> operations, it does not discuss the treatment of a fragment when=20 >>>>>>> received in an SFC domain. IMHO, the draft should also specify=20 >>>>>>> the behavior of the Classifier with regards to fragments for the=20 >>>>>>> sake of proper SFC operation. Applying classification policies=20 >>>>>>> may require the >>>>>> full packet, not only a fragment. >>>>>>> In particular, dedicated resources should dedicated for handling=20 >>>>>>> out of order fragments. Of course, it is out of scope of this=20 >>>>>>> document to describe how SFs handle fragments. >>>>>>> >>>>>>> * If an SFC header is prepended for all fragments, I'm not sure=20 >>>>>>> there is any particular issue at the SFF level...except if=20 >>>>>>> stripping/adding context TLVs depends on the full packet (not=20 >>>>>>> just fragment). It is warranted to consider a little bit this=20 >>>>>>> point before declaring there >>>> is >>>>>> no issue. >>>>>>> >>>>>>> * The text states "several options". This may be interpreted as=20 >>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>> The first two points contribute to minimize the fragmentation=20 >>>>>>> risk, but fragmentation may still be experienced (e.g., other=20 >>>>>>> shims are prepended by other nodes for some other purposes,=20 >>>>>>> nested nsh, >>>>>>> etc.) >>>>>>> >>>>>>> * The first two points have nothing to do with reassembly. >>>>>>> >>>>>>> * The support of jumbo frames by a router/device does not mean=20 >>>>>>> that it can make use of it. Appropriate MTU configuration should=20 >>>>>>> be undertaken in a consistent manner within an SFC domain. The=20 >>>>>>> text should be updated to make it is about (consistent) MTU >>> configuration. >>>>>>> >>>>>>> * BTW, shouldn't the text be reworded to recommended to increase=20 >>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least=20 >>>>>>> the length of SFC header + transport header? >>>>>>> >>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>> Do you assume that all SFC-aware nodes will issue such messages=20 >>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>> >>>>>>> * Bullet 2, I would drop "describes a technique for dynamically=20 >>>>>>> discovering the maximum transmission unit (MTU) of an arbitrary=20 >>>>>>> internet path". >>>>>>> >>>>>>> * Bullet 2, s/ the the/the. >>>>>>> >>>>>>> * The reference to the LISP specification raises two concerns=20 >>>>>>> and one >>>>>>> comment: >>>>>>> >>>>>>> (1) I don't think it is a good approach that fragments induced=20 >>>>>>> by the network are passed to their ultimate destinations as such >>> (stateless). >>>>>>> IMO, reassembly should be done within the SFC domain=20 >>>>>>> (responsible for >>>>>>> fragmentation) not passed away. >>>>>>> (2) Does the stateful mode require all SFC data plane elements=20 >>>>>>> maintain a full list of MTU for the any SFF/SF instance of the=20 >>>>>>> SFC >>>>>> domain? >>>>>>> >>>>>>> The current text suggests that [RFC6830] should be listed as=20 >>>>>>> normative reference (not an informative one). I would personally=20 >>>>>>> favor removing the reference to LISP (as it is an Experimental RFC)= . >>>>>>> >>>>>>> * The security section of the draft may be augmented with=20 >>>>>>> informational fragmentation-related pointers to: e.g., RFC1858=20 >>>>>>> (Security Considerations for IP Fragment Filtering), RFC3128=20 >>>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and=20 >>>>>>> RFC >>>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de=20 >>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14 = =C0 : >>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for=20 >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear Thomas, all, >>>>>>>> >>>>>>>> As I mentioned during the meeting, there are several issues=20 >>>>>>>> that are not covered in the last version of the draft. I=20 >>>>>>>> already provided examples of the issues offline as requested by Ma= rtin. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas=20 >>>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org=20 >>>>>>>>> Objet >>>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>> >>>>>>>>> The editors of the NSH document have indicated that they have=20 >>>>>>>>> addressed all known comments and that there are no open issues=20 >>>>>>>>> with the current version of the document. >>>>>>>>> >>>>>>>>> Substantive comments to the list please, editorial comments=20 >>>>>>>>> can go directly to the document editors. >>>>>>>>> >>>>>>>>> We'll also get a brief update from the editors at next week's=20 >>>>>>>>> meeting. If there are any remaining issues with the document,=20 >>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>> >>>>>>>>> For the chairs, >>>>>>>>> Thomas >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Apr 26 12:12: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 8231612D56C for ; Tue, 26 Apr 2016 12:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 LYtPj9x5DiPC for ; Tue, 26 Apr 2016 12:12:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EF212D56A for ; Tue, 26 Apr 2016 12:12:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9E562258B35; Tue, 26 Apr 2016 12:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461697941; bh=7VS62SbCWYddXZBBB99QQlyLOrXaoWgaS4fh2tFimhs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BEyuGYLqlwHf00lzKR8TKVXR4ldGpUd6VPkbce6AF5zLaXZRVJgRbn4bdrKI/ZF8T 8uDBru6MkiYFKWA3a3jvPTzasvpf50AzK685WRT5l6X39CKtXJ2fiwYSgUCWCR0VmR u1b6jvq1tdPkQ6hcxxYaN4CiJiijOOKOqLfn85fM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BF30D24097D; Tue, 26 Apr 2016 12:12:20 -0700 (PDT) To: Ron Parker , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <1d9ca816-42ae-333c-a316-7ec5bff8b55b@joelhalpern.com> Date: Tue, 26 Apr 2016 15:12:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 19:12:24 -0000 In most tunnel anlysis, a tunnel entry point (in this case, the transport interface from the SFC component) can either fragment outer or, if available fragment inner. This is defined by the transport technology, not the user. In the case of SFC NSH, I would usually expect outer fragmentation, which is a pure transport issue. If the innermost packet is IP, and the tunnel entry wants to be complicated, it is permitted to fragment the inner packet and produce the proper NSH headers for the fragments. Inherently, an implementation can only choose to do this if it can construct the right metdata to put on each fragment. I don't actually know how to reliably do that, so I don't recommend it. In either case, the NSH document can't tell the implementation what to do or how to do it. Yours, Joel On 4/26/16 2:38 PM, Ron Parker wrote: > Joel, > > I can't say that I disagree with your analysis on the scope. I think the question raised by some on the thread is if an SFC-node (i.e., classifier, SF, SFF) creates fragments, is the NSH header repeated in each fragment ? I think the answer is "no". If so, is it worth stating this explicitly in the document, or is it just obvious that properly layered systems would behave that way. > > Ron > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 26, 2016 1:22 PM > To: Ron Parker ; Joel M. Halpern ; mohamed.boucadair@orange.com; Elzur, Uri ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > At least so far, we have treated the communication between classifier and SFF (ingress or intermediate) as outside of the scope of our work. > For SF <-> SFF communication we have ntoed the need for a proxy to handle the case when the SF can not accept and return the NSH header, since we assume that is preserved. Other than that preservation, similar to the above, we have treated the details as outside of our scope. That is because they depend so heavily on the implementation technique used. (Hypervisor ,_> application communication vs communication inside a user space or communication over an actual Ethernet are all very different.) > > Trying to extend the NSH document to address these would be a major change, and would step into the issues related to transport selection, which are explicitly out of scope. > > Yours, > Joel > > On 4/26/16 11:58 AM, Ron Parker wrote: >> Linda, >> >> I like the first clause (transport tunnel based fragmentation). >> >> Regarding the second (source based), I think there are more subcases to consider: >> >> 1. Propagation of NSH encapsulated packet from classifier to SFF 2. >> Propagation of NSH encapsulated packet from SFF to SF 3. Propagation >> of NSH encapsulated packet from SF to SFF (including possibility that >> NSH size increased at SF) 4. Propagation of NSH encapsulated packet >> from SFF to SFF >> >> In each of the 4 cases above, there is the possibility that MTU will be exceeded and therefore there are procedures to be defined in that eventuality. >> >> Thanks. >> >> Ron >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Tuesday, April 26, 2016 11:48 AM >> To: Joel M. Halpern ; >> mohamed.boucadair@orange.com; Elzur, Uri ; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Joel, >> >> I think the document should add the description on the following two fragmentation scenarios: >> >> - Transport tunnel generated fragmentation: >> When a packet fragmentation is caused by transport tunnel (i.e. various encapsulations), the termination point of the transport tunnel is responsible for re-assembling the fragmented pieces of the packet. Since there won't be any SFF nodes in between the Transport Tunnel, the tunnel generated fragmentation does not require any actions by SFF nodes or SF nodes. >> >> >> - Source node generated fragmentation (after adding on the NSH header): >> When fragmentation has to be performed for a packet being encapsulated with the NSH header, either the intermediate SFF nodes or the SF nodes have to be able to reassemble the fragmented pieces. >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 26, 2016 10:33 AM >> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that you are referring only to the case of transport generated fragmentation of the outer packet. I had assumed you were not talking about that, since the resulting fragments will not all have NSH headers. As with any tunnel technology, if the tunnel chooses to fragment at its layer, then the tunnel is responsible for reassembly. That would be invisible to the SFF. >> >> Yours, >> Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>> Agree with Med. >>> >>> Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. >>> >>> Linda >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Monday, April 25, 2016 9:42 AM >>> To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Re-, >>> >>> How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that? >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril >>>> 2016 16:26 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>> draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Med >>>> >>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* >>>> a transport, dealing with fragmentation is left to the Transport used. >>>> >>>> The model I use for NSH, is basically similar to VXLAN . It is an overly. >>>> >>>> Thx >>>> >>>> Uri ("Oo-Ree") >>>> C: 949-378-7568 >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Monday, April 25, 2016 7:18 AM >>>> To: Joel M. Halpern ; sfc@ietf.org >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Joel, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 >>>>> avril 2016 15:48 À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> If I am understanding you correctly Med, you are asking that the >>>>> NSH draft specify how service chaining should cope with packets >>>>> that have been fragmented? >>>>> >>>> >>>> [Med] To be accurate, I'm asking to assess whether there are implications. >>>> If there are, then the draft should be updated accordingly. >>>> >>>>> NSH, and the SFF functionality, does not care. >>>> >>>> [Med] I'm not that sure. Some typical implications are listed below: >>>> >>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>> didn't maintained a state, subsequent fragments won't be appropriately processed. >>>> * SFC-aware function: if prepending a context information depends on >>>> the full packet, not only a fragment. >>>> >>>> It just does its job. >>>> >>>> [Med] which may be disturbed in some situations as listed in the >>>> examples above. >>>> >>>>> Ingress and intermediate classifiers may cope with fragments in any >>>>> number of ways. >>>> Specifying such is clearly out of scope for this draft. >>>> >>>> [Med] The purpose is not to specify the internal implementation >>>> details but the external behavior of the classifier function when it >>>> comes to handle fragments. That behavior may have an incidence on >>>> SFF, in particular. The purpose is not to recommend the maximum >>>> resources to be dedicated to out of order fragments nor the timeout >>>> to cache those; these considerations are of course out of scope. >>>> Nevertheless, an implementation should offer a configurable >>>> parameter so that an operator tweak those according to its context. >>>> >>>>> I suppose one could write an informational draft on possible ways >>>>> of coping. The IETF has not usually published such. >>>>> Service functions have to cope with fragmented packets just as they >>>>> had to before the advent of NSH, so describing that is clearly not >>>>> needed here. >>>> >>>> [Med] The advent of NSH has the following implications: >>>> * it exacerbates fragmentation. Handing over this issue to the >>>> transport layer may lead to interoperability issues. >>>> * the chaining may not be efficient if fragments are inappropriately >>>> handled. >>>> >>>> Introducing NSH should not degrade the overall service compared to >>>> legacy service deployment schemes. >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>> Re-, >>>>>> >>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>> what to >>>>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>>>> >>>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>> >>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>> explicitly >>>>> called out in the text (see my first message). >>>>>> >>>>>> There are other issues that need to be discussed, e.g., how to >>>>>> deal with >>>>> fragments in SFFs/Classifiers? >>>>>> >>>>>> It is also "prudent" to check that no issues will be experienced >>>>>> in SFF >>>>> to handle fragments. If an SFC header is prepended for all >>>>> fragments, I'm not sure there >>>>>> is any particular issue at the SFF level, except if >>>>>> stripping/adding >>>>> context TLVs depends on the full packet (not just fragment). It is >>>>> warranted to consider a little bit this point before declaring >>>>> there is no issue. >>>>>> >>>>>> For point (1), declaring fragmentation out of scope would be meant >>>>>> that >>>>> an implementation must be prepared to receive fragments with or >>>>> without NSH header as this is a decision that is left to the >>>>> transport encapsulation. This is a requirement per se! >>>>>> >>>>>> I won't reiterate all the comments I have about the current >>>>>> wording of >>>>> this section. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : lundi 25 >>>>>>> avril 2016 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> My point is that Fragmentation is yet another transport related >>>>>>> issue >>>>> that >>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>> it >>>>> doesn't >>>>>>> really belong in the draft. We are providing an advice as >>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>> you'll find it doesn't even >>>>> relate >>>>>>> to it. >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") >>>>>>> C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>>>> To: Elzur, Uri ; Thomas Narten >>>>> ; >>>>>>> sfc@ietf.org >>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Uri, >>>>>>> >>>>>>> That's another option that needs to be discussed/investigated. >>>>>>> I'm >>>>> afraid >>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>> text >>>>> that >>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>> >>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>> because >>>>> it >>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>> here >>>>> because >>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>> sub-optimal implementations if the sfc information is present >>>>>>> only in one >>>>> fragments, >>>>>>> etc. >>>>>>> >>>>>>> My comments are related to the current text in the -04. This text >>>>>>> needs >>>>> to >>>>>>> be fixed somehow. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoyé : dimanche >>>>>>>> 24 avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas >>>>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>>>> independent i.e. like NSH interaction with any other Transport >>>>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>>>> the mechanisms supported by the Transport used and do not belong >>>>>>>> in the NSH draft >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") >>>>>>>> C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com >>>>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> R-, >>>>>>>> >>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>> would like to raise this additional one about Section 6. >>>>>>>> >>>>>>>> == >>>>>>>> 6. Fragmentation Considerations >>>>>>>> >>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>> encapsulated packet/frame. This additional information >>>>>>>> increases >>>>> the >>>>>>>> size of the packet. In order the ensure proper forwarding of NSH >>>>>>>> data, several options for handling fragmentation and re-assembly >>>>>>>> exist: >>>>>>>> >>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH and >>>>>>>> associated transport packets without requiring fragmentation. >>>>>>>> >>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>> (MTU) of >>>>> an >>>>>>>> arbitrary internet path" and can be utilized to ensure >>>>>>>> the >>>> the >>>>>>>> required packet size is used. >>>>>>>> >>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>>>> assembly >>>>>>>> in section 5.4. >>>>>>>> == >>>>>>>> >>>>>>>> * The text is weak for a Standard track document that is >>>>>>>> intended to solve the problem in >>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>> 2.12. >>>>>>>> There should be a clear behavior to be followed by an >>>> implementation. >>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>> >>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>> operations, it does not discuss the treatment of a fragment when >>>>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>>>> the behavior of the Classifier with regards to fragments for the >>>>>>>> sake of proper SFC operation. Applying classification policies >>>>>>>> may require the >>>>>>> full packet, not only a fragment. >>>>>>>> In particular, dedicated resources should dedicated for handling >>>>>>>> out of order fragments. Of course, it is out of scope of this >>>>>>>> document to describe how SFs handle fragments. >>>>>>>> >>>>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>>>> there is any particular issue at the SFF level...except if >>>>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>>>> just fragment). It is warranted to consider a little bit this >>>>>>>> point before declaring there >>>>> is >>>>>>> no issue. >>>>>>>> >>>>>>>> * The text states "several options". This may be interpreted as >>>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>>> The first two points contribute to minimize the fragmentation >>>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>>> nested nsh, >>>>>>>> etc.) >>>>>>>> >>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>> >>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>>>> text should be updated to make it is about (consistent) MTU >>>> configuration. >>>>>>>> >>>>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>>>> the length of SFC header + transport header? >>>>>>>> >>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>>> >>>>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>>>>> internet path". >>>>>>>> >>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>> >>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>> and one >>>>>>>> comment: >>>>>>>> >>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>> by the network are passed to their ultimate destinations as such >>>> (stateless). >>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>> (responsible for >>>>>>>> fragmentation) not passed away. >>>>>>>> (2) Does the stateful mode require all SFC data plane elements >>>>>>>> maintain a full list of MTU for the any SFF/SF instance of the >>>>>>>> SFC >>>>>>> domain? >>>>>>>> >>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>> normative reference (not an informative one). I would personally >>>>>>>> favor removing the reference to LISP (as it is an Experimental RFC). >>>>>>>> >>>>>>>> * The security section of the draft may be augmented with >>>>>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and >>>>>>>> RFC >>>>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril 2016 13:14 À : >>>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear Thomas, all, >>>>>>>>> >>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>> already provided examples of the issues offline as requested by Martin. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>>>> Narten Envoyé : jeudi 31 mars 2016 04:48 À : sfc@ietf.org >>>>>>>>>> Objet >>>>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>> >>>>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>>>> addressed all known comments and that there are no open issues >>>>>>>>>> with the current version of the document. >>>>>>>>>> >>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>> can go directly to the document editors. >>>>>>>>>> >>>>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>>> >>>>>>>>>> For the chairs, >>>>>>>>>> Thomas >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> sfc mailing list >>>>>>>>>> sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Tue Apr 26 12:20: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 CD03512D0A6 for ; Tue, 26 Apr 2016 12:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 g0XKZpLC9pdZ for ; Tue, 26 Apr 2016 12:20:44 -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 0AE3412B069 for ; Tue, 26 Apr 2016 12:20:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNH94426; Tue, 26 Apr 2016 19:20:39 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 20:20:38 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 12:20:32 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQIp3nrjaS0+VjDL7mlh8GJ+Er+AwgARg/TCAEFX48IABYBMAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAEik2CAAH4AgP//ixXggACSLID//6nIYA== Date: Tue, 26 Apr 2016 19:20:32 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E7CFA1dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.571FBF88.008D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7f390b4846863f306fe54fcbe9ebbbe3 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 19:20:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E7CFA1dfweml501mbb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joel, Replies are inserted below: -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 12:18 PM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt With regard to Transport tunnel fragementation, that seems an issue for the= transport protocol. I don't actually object to a sentence, but it does no= t seem that it will accomplish anything. [Linda] By having this description, you avoid a lot of future unnecessary d= ebate about how fragmentation should be processed because some people are o= nly thinking about Tunnel induced fragmentation where as some other people = are thinking of Source induced fragmentation. With regard to packets fragmented by the source, I completely disagree with= your assertion. If an SFF were to reassemble the packets, that would be a= violation of its job. There is no reason for an SFF to reassemble a packe= t fragmented by the source. The classifier may have to do some interesting= things in order to properly classify succeeding fragments, but that is an = implementation issue (most commonly addressed with virtual reassembly, whic= h doe snot delay the fragments.) We don't specity that. If an SF needs to reassemble fragments to do its job, that is up to the SF.= Some will need to actually reassemble. Some will need to perform virtual= reassembly, and some will happily process the fragments. I can not see wh= at the NSH document could possibly mandate. [Linda] I said "either SFF or SF" has to re-assemble the fragmented packets= . I don't have strong opinion on who perform the re-assembling job (as long= as one of them do). If a set of SFs attached to a SFF are not capable of p= erforming the re-assembling and they need the whole packet to do inspection= , then the SFF don't have any choice. I just think that it is necessary to= add the description because it can be very messy (if not impossible) for S= Fs to process partial packets. Linda Yours, Joel On 4/26/16 11:47 AM, Linda Dunbar wrote: > Joel, > > I think the document should add the description on the following two > fragmentation scenarios: > > - Transport tunnel generated fragmentation: When a packet > fragmentation is caused by transport tunnel (i.e. various > encapsulations), the termination point of the transport tunnel is > responsible for re-assembling the fragmented pieces of the packet. > Since there won't be any SFF nodes in between the Transport Tunnel, > the tunnel generated fragmentation does not require any actions by SFF > nodes or SF nodes. > > > - Source node generated fragmentation (after adding on the NSH > header): When fragmentation has to be performed for a packet being > encapsulated with the NSH header, either the intermediate SFF nodes or > the SF nodes have to be able to reassemble the fragmented pieces. > > > > > Cheers, > > > Linda > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; > sfc@ietf.org Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that you are referring only to > the case of transport generated fragmentation of the outer packet. I > had assumed you were not talking about that, since the resulting > fragments will not all have NSH headers. As with any tunnel > technology, if the tunnel chooses to fragment at its layer, then the > tunnel is responsible for reassembly. That would be invisible to the > SFF. > > Yours, Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: >> Agree with Med. >> >> Even if each fragment piece of a packet with NSH header carries the >> NSH header, the intermediate SFF nodes still need to put together all >> the fragments together before passing the whole data frame to the SF. >> >> Linda >> >> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On >> Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer to ALWAYS prepend an NSH >> header even for fragments? Or you don't care about that? >> >> Thank you. >> >> Cheers, Med >> >>> -----Message d'origine----- De : Elzur, Uri >>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet >>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>> *NOT* a transport, dealing with fragmentation is left to the >>> Transport used. >>> >>> The model I use for NSH, is basically similar to VXLAN . It is an >>> overly. >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >>> >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>> 2016 7:18 AM To: Joel M. Halpern >; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, >>> >>> Please see inline. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 =C0 = : >>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : R= e: [sfc] WG last >>>> call for draft-ietf-sfc-nsh-04.txt >>>> >>>> If I am understanding you correctly Med, you are asking that the >>>> NSH draft specify how service chaining should cope with packets >>>> that have been fragmented? >>>> >>> >>> [Med] To be accurate, I'm asking to assess whether there are >>> implications. If there are, then the draft should be updated >>> accordingly. >>> >>>> NSH, and the SFF functionality, does not care. >>> >>> [Med] I'm not that sure. Some typical implications are listed >>> below: >>> >>> * SFF: If the NSH header is present only in the a fragment but SFF >>> didn't maintained a state, subsequent fragments won't be >>> appropriately processed. * SFC-aware function: if prepending a >>> context information depends on the full packet, not only a fragment. >>> >>> It just does its job. >>> >>> [Med] which may be disturbed in some situations as listed in the >>> examples above. >>> >>>> Ingress and intermediate classifiers may cope with fragments in any >>>> number of ways. >>> Specifying such is clearly out of scope for this draft. >>> >>> [Med] The purpose is not to specify the internal implementation >>> details but the external behavior of the classifier function when it >>> comes to handle fragments. That behavior may have an incidence on >>> SFF, in particular. The purpose is not to recommend the maximum >>> resources to be dedicated to out of order fragments nor the timeout >>> to cache those; these considerations are of course out of scope. >>> Nevertheless, an implementation should offer a configurable >>> parameter so that an operator tweak those according to its context. >>> >>>> I suppose one could write an informational draft on possible ways >>>> of coping. The IETF has not usually published such. >>>> Service functions have to cope with fragmented packets just as they >>>> had to before the advent of NSH, so describing that is clearly not >>>> needed here. >>> >>> [Med] The advent of NSH has the following implications: * it >>> exacerbates fragmentation. Handing over this issue to the transport >>> layer may lead to interoperability issues. * the chaining may not be >>> efficient if fragments are inappropriately handled. >>> >>> Introducing NSH should not degrade the overall service compared to >>> legacy service deployment schemes. >>> >>>> >>>> Yours, Joel >>>> >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>> what to >>>> put in the draft. FWIW, I'm discussing two fragmentation >>>> issues: >>>>> >>>>> (1) Fragmentation that is caused by prepending an SFC header. (2) >>>>> Handling fragments at the ingress of an SFC-enabled domain. >>>>> >>>>> Increasing the MTU is for sure a recommendation is to be >>>>> explicitly >>>> called out in the text (see my first message). >>>>> >>>>> There are other issues that need to be discussed, e.g., how to >>>>> deal with >>>> fragments in SFFs/Classifiers? >>>>> >>>>> It is also "prudent" to check that no issues will be experienced >>>>> in SFF >>>> to handle fragments. If an SFC header is prepended for all >>>> fragments, I'm not sure there >>>>> is any particular issue at the SFF level, except if >>>>> stripping/adding >>>> context TLVs depends on the full packet (not just fragment). It is >>>> warranted to consider a little bit this point before declaring >>>> there is no issue. >>>>> >>>>> For point (1), declaring fragmentation out of scope would be meant >>>>> that >>>> an implementation must be prepared to receive fragments with or >>>> without NSH header as this is a decision that is left to the >>>> transport encapsulation. This is a requirement per se! >>>>> >>>>> I won't reiterate all the comments I have about the current >>>>> wording of >>>> this section. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 >>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org >>>>>> Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> My point is that Fragmentation is yet another transport related >>>>>> issue >>>> that >>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>> it >>>> doesn't >>>>>> really belong in the draft. We are providing an advice as >>>>>> extending the size of the packet may lead to fragmentation, but >>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>> you'll find it doesn't even >>>> relate >>>>>> to it. >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>> mohamed.boucadair@orange.com Se= nt: Sunday, April 24, 2016 >>>>>> 10:32 PM To: Elzur, Uri >; Thomas Narten >>>> >; >>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call fo= r >>>>>> draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Uri, >>>>>> >>>>>> That's another option that needs to be discussed/investigated. >>>>>> I'm >>>> afraid >>>>>> this is not the rationale adopted in -04 since it includes some >>>>>> text >>>> that >>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>> >>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>> because >>>> it >>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>> here >>>> because >>>>>> it opens the door for interoperable issues, it may lead to >>>>>> sub-optimal implementations if the sfc information is present >>>>>> only in one >>>> fragments, >>>>>> etc. >>>>>> >>>>>> My comments are related to the current text in the -04. >>>>>> This text needs >>>> to >>>>>> be fixed somehow. >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril >>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call fo= r >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>>> independent i.e. like NSH interaction with any other Transport >>>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>>> the mechanisms supported by the Transport used and do not belong >>>>>>> in the NSH draft >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com S= ent: Thursday, April 14, >>>>>>> 2016 12:43 AM To: Thomas Narten >; >>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call f= or >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> R-, >>>>>>> >>>>>>> In addition to other pending issues raised for this draft, I >>>>>>> would like to raise this additional one about Section 6. >>>>>>> >>>>>>> =3D=3D 6. Fragmentation Considerations >>>>>>> >>>>>>> NSH and the associated transport header are "added" to the >>>>>>> encapsulated packet/frame. This additional information >>>>>>> increases >>>> the >>>>>>> size of the packet. In order the ensure proper forwarding of >>>>>>> NSH data, several options for handling fragmentation and >>>>>>> re-assembly exist: >>>>>>> >>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH >>>>>>> and associated transport packets without requiring >>>>>>> fragmentation. >>>>>>> >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>> an >>>>>>> arbitrary internet path" and can be utilized to ensure the >>> the >>>>>>> required packet size is used. >>>>>>> >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>> re- >>>> assembly >>>>>>> in section 5.4. =3D=3D >>>>>>> >>>>>>> * The text is weak for a Standard track document that is >>>>>>> intended to solve the problem in >>>>>>> https://tools.ietf.org/html/rfc7498#section- >>> 2.12. >>>>>>> There should be a clear behavior to be followed by an >>> implementation. >>>>>>> Further, I would avoid the use of words such as "can". >>>>>>> >>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>> operations, it does not discuss the treatment of a fragment when >>>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>>> the behavior of the Classifier with regards to fragments for the >>>>>>> sake of proper SFC operation. Applying classification policies >>>>>>> may require the >>>>>> full packet, not only a fragment. >>>>>>> In particular, dedicated resources should dedicated for handling >>>>>>> out of order fragments. Of course, it is out of scope of this >>>>>>> document to describe how SFs handle fragments. >>>>>>> >>>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>>> there is any particular issue at the SFF level...except if >>>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>>> just fragment). It is warranted to consider a little bit this >>>>>>> point before declaring there >>>> is >>>>>> no issue. >>>>>>> >>>>>>> * The text states "several options". This may be interpreted as >>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>> The first two points contribute to minimize the fragmentation >>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>> nested nsh, etc.) >>>>>>> >>>>>>> * The first two points have nothing to do with reassembly. >>>>>>> >>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>>> text should be updated to make it is about (consistent) MTU >>> configuration. >>>>>>> >>>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>>> the length of SFC header + transport header? >>>>>>> >>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>> >>>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>>> discovering the maximum transmission unit >>>>>>> (MTU) of an arbitrary internet path". >>>>>>> >>>>>>> * Bullet 2, s/ the the/the. >>>>>>> >>>>>>> * The reference to the LISP specification raises two concerns >>>>>>> and one comment: >>>>>>> >>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>> by the network are passed to their ultimate destinations as such >>> (stateless). >>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>> (responsible for fragmentation) not passed away. (2) Does the >>>>>>> stateful mode require all SFC data plane elements maintain a >>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>> domain? >>>>>>> >>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>> normative reference (not an informative one). I would personally >>>>>>> favor removing the reference to LISP (as it is an Experimental >>>>>>> RFC). >>>>>>> >>>>>>> * The security section of the draft may be augmented with >>>>>>> informational fragmentation-related pointers to: >>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny >>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High >>>>>>> Data Rates). >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>> mohamed.boucadair@orange.com = Envoy=E9 : lundi 11 avril >>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org = Objet : Re: >>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Dear Thomas, all, >>>>>>>> >>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>> that are not covered in the last version of the draft. I >>>>>>>> already provided examples of the issues offline as requested by >>>>>>>> Martin. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : >>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear WG: >>>>>>>>> >>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>> >>>>>>>>> >>>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>>> addressed all known comments and that there are no open issues >>>>>>>>> with the current version of the document. >>>>>>>>> >>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>> can go directly to the document editors. >>>>>>>>> >>>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>> >>>>>>>>> For the chairs, Thomas >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailm= an/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailma= n/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing list >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/list= info/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listi= nfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listin= fo/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 >> --_000_4A95BA014132FF49AE685FAB4B9F17F657E7CFA1dfweml501mbb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Joel,
 
Replies are inserted below:
 
 
 
-----Original Message-----
From: Joel M. Halpern [mailto:jmh@jo= elhalpern.com]
Sent: Tuesday, April 26, 2016 12:18 PM
To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
 
With regard to Transport tunnel fragementation, that seems an issue fo= r the transport protocol.  I don't actually object to a sentence, but = it does not seem that it will accomplish anything.
 
[Linda] By having this description, you avoid = a lot of future unnecessary debate about how fragmentation should be proces= sed because some people are only thinking about Tunnel induced fragmentatio= n where as some other people are thinking of Source induced fragmentation.
 
 
With regard to packets fragmented by the source, I completely disagree= with your assertion.  If an SFF were to reassemble the packets, that = would be a violation of its job.  There is no reason for an SFF to rea= ssemble a packet fragmented by the source.  The classifier may have to do some interesting things in order to properly = classify succeeding fragments, but that is an implementation issue (most co= mmonly addressed with virtual reassembly, which doe snot delay the fragment= s.)  We don't specity that.
 
If an SF needs to reassemble fragments to do its job, that is up to th= e SF.  Some will need to actually reassemble.  Some will need to = perform virtual reassembly, and some will happily process the fragments.&nb= sp; I can not see what the NSH document could possibly mandate.
 
[Linda] I said “either SFF or SF” = has to re-assemble the fragmented packets. I don’t have strong opinio= n on who perform the re-assembling job (as long as one of them do). If a se= t of SFs attached to a SFF are not capable of performing the re-assembling and they need the whole packet to do inspection, then the= SFF don’t have any choice. I just think that it is necessary to add= the description because it can be very messy (if not impossible) for SFs t= o process partial packets.
 
 
Linda
 
 
 
 
Yours,
Joel
 
On 4/26/16 11:47 AM, Linda Dunbar wrote:
> Joel,
>
> I think the document should add the description on the following = two
> fragmentation scenarios:
>
> - Transport tunnel generated fragmentation: When a packet
> fragmentation is caused by transport tunnel (i.e. various
> encapsulations), the termination point of the transport tunnel is=
> responsible for re-assembling the fragmented pieces of the packet= .
> Since there won't be any SFF nodes in between the Transport Tunne= l,
> the tunnel generated fragmentation does not require any actions b= y SFF
> nodes or SF nodes.
>
>
> - Source node generated fragmentation (after adding on the NSH
> header): When fragmentation has to be performed for a packet bein= g
> encapsulated with the NSH header, either the intermediate SFF nod= es or
> the SF nodes have to be able to reassemble the fragmented pieces.=
>
>
>
>
> Cheers,
>
>
> Linda
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:jmh@joelhalpern.co= m] Sent: Tuesday, April 26, 2016 10:33 AM
> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;
> sfc@ietf.org Subject: Re: [sf= c] WG last call for
> draft-ietf-sfc-nsh-04.txt
>
> Re-reading your note, it is possible that you are referring only = to
> the case of transport generated fragmentation of the outer packet= .  I
> had assumed you were not talking about that, since the resulting =
> fragments will not all have NSH headers.  As with any tunnel=
> technology, if the tunnel chooses to fragment at its layer, then = the
> tunnel is responsible for reassembly.  That would be invisib= le to the
> SFF.
>
> Yours, Joel
>
> On 4/26/16 11:10 AM, Linda Dunbar wrote:
>> Agree with Med.
>>
>> Even if each fragment piece of a packet with NSH header carri= es the
>> NSH header, the intermediate SFF nodes still need to put toge= ther all
>> the fragments together before passing the whole data frame to= the SF.
>>
>> Linda
>>
>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On
>> Behalf Of moh= amed.boucadair@orange.com Sent: Monday, April 25,
>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject:
>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>>
>> Re-,
>>
>> How do you instruct the transport layer to ALWAYS prepend an = NSH
>> header even for fragments? Or you don't care about that?
>>
>> Thank you.
>>
>> Cheers, Med
>>
>>> -----Message d'origine----- De : Elzur, Uri
>>> [mailto:uri.elzur@= intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0
>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet
>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>>>
>>> Hi Med
>>>
>>> Not to repeat my position, but I'll do it anyhow :-) As N= SH is
>>> *NOT* a transport, dealing with fragmentation is left to = the
>>> Transport used.
>>>
>>> The model I use for NSH, is basically similar to VXLAN . = It is an
>>> overly.
>>>
>>> Thx
>>>
>>> Uri ("Oo-Ree") C: 949-378-7568
>>>
>>>
>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25,
>>> 2016 7:18 AM To: Joel M. Halpern <jmh@joelhalpern.com>; sfc@ietf.org
>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04= .txt
>>>
>>> Hi Joel,
>>>
>>> Please see inline.
>>>
>>> Cheers, Med
>>>
>>>> -----Message d'origine----- De : Joel M. Halpern
>>>> [mailto:jmh@jo= elhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 =C0 :
>>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG last
>>>> call for draft-ietf-sfc-nsh-04.txt
>>>>
>>>> If I am understanding you correctly Med, you are aski= ng that the
>>>> NSH draft specify how service chaining should cope wi= th packets
>>>> that have been fragmented?
>>>>
>>>
>>> [Med] To be accurate, I'm asking to assess whether there = are
>>> implications. If there are, then the draft should be upda= ted
>>> accordingly.
>>>
>>>> NSH, and the SFF functionality, does not care.
>>>
>>> [Med] I'm not that sure. Some typical implications are li= sted
>>> below:
>>>
>>> * SFF: If the NSH header is present only in the a fragmen= t but SFF
>>> didn't maintained a state, subsequent fragments won't be =
>>> appropriately processed. * SFC-aware function: if prepend= ing a
>>> context information depends on the full packet, not only = a fragment.
>>>
>>> It just does its job.
>>>
>>> [Med] which may be disturbed in some situations as listed= in the 
>>> examples above.
>>>
>>>> Ingress and intermediate classifiers may cope with fr= agments in any
>>>> number of ways.
>>> Specifying such is clearly out of scope for this draft.
>>>
>>> [Med] The purpose is not to specify the internal implemen= tation
>>> details but the external behavior of the classifier funct= ion when it
>>> comes to handle fragments. That behavior may have an inci= dence on
>>> SFF, in particular. The purpose is not to recommend the m= aximum
>>> resources to be dedicated to out of order fragments nor t= he timeout
>>> to cache those; these considerations are of course out of= scope.
>>> Nevertheless, an implementation should offer a configurab= le
>>> parameter so that an operator tweak those according to it= s context.
>>>
>>>> I suppose one could write an informational draft on p= ossible ways
>>>> of coping.  The IETF has not usually published s= uch.
>>>> Service functions have to cope with fragmented packet= s just as they
>>>> had to before the advent of NSH, so describing that i= s clearly not
>>>> needed here.
>>>
>>> [Med] The advent of NSH has the following implications: *= it
>>> exacerbates fragmentation. Handing over this issue to the= transport
>>> layer may lead to interoperability issues. * the chaining= may not be
>>> efficient if fragments are inappropriately handled.
>>>
>>> Introducing NSH should not degrade the overall service co= mpared to
>>> legacy service deployment schemes.
>>>
>>>>
>>>> Yours, Joel
>>>>
>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote:
>>>>> Re-,
>>>>>
>>>>> I hear you, but my comment is that we need, as a = WG, to decide
>>>>> what to
>>>> put in the draft. FWIW, I'm discussing two fragmentat= ion
>>>> issues:
>>>>>
>>>>> (1) Fragmentation that is caused by prepending an= SFC header. (2)
>>>>> Handling fragments at the ingress of an SFC-enabl= ed domain.
>>>>>
>>>>> Increasing the MTU is for sure a recommendation i= s to be
>>>>> explicitly
>>>> called out in the text (see my first message).
>>>>>
>>>>> There are other issues that need to be discussed,= e.g., how to
>>>>> deal with
>>>> fragments in SFFs/Classifiers?
>>>>>
>>>>> It is also "prudent" to check that no i= ssues will be experienced
>>>>> in SFF
>>>> to handle fragments. If an SFC header is prepended fo= r all
>>>> fragments, I'm not sure there
>>>>> is any particular issue at the SFF level, except = if
>>>>> stripping/adding
>>>> context TLVs depends on the full packet (not just fra= gment). It is
>>>> warranted to consider a little bit this point before = declaring
>>>> there is no issue.
>>>>>
>>>>> For point (1), declaring fragmentation out of sco= pe would be meant
>>>>> that
>>>> an implementation must be prepared to receive fragmen= ts with or
>>>> without NSH header as this is a decision that is left= to the
>>>> transport encapsulation. This is a requirement per se= !
>>>>>
>>>>> I won't reiterate all the comments I have about t= he current
>>>>> wording of
>>>> this section.
>>>>>
>>>>> Cheers, Med
>>>>>
>>>>>> -----Message d'origine----- De : Elzur, Uri <= /div>
>>>>>> [mailt= o:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016
>>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas= Narten; sfc@ietf.org
>>>>>> Objet : RE: [sfc] WG last call for draft-ietf= -sfc-nsh-04.txt
>>>>>>
>>>>>> Hi Med
>>>>>>
>>>>>> My point is that Fragmentation is yet another= transport related
>>>>>> issue
>>>> that
>>>>>> is beyond the scope of NSH and beyond the cha= rter of the WG, so
>>>>>> it
>>>> doesn't
>>>>>> really belong in the draft. We are providing = an advice as
>>>>>> extending the size of the packet may lead to = fragmentation, but
>>>>>> as you check RFC 7348 VxLAN, which my create = the same issue,
>>>>>> you'll find it doesn't even
>>>> relate
>>>>>> to it.
>>>>>>
>>>>>> Thx
>>>>>>
>>>>>> Uri ("Oo-Ree") C: 949-378-7568
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: sfc
>>>>>> [mail= to:sfc-bounces@ietf.org] On Behalf Of
>>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016
>>>>>> 10:32 PM To: Elzur, Uri <uri.elzur@intel.com>; Thomas Narten
>>>>>> draft-ietf-sfc-nsh-04.txt
>>>>>>
>>>>>> Hi Uri,
>>>>>>
>>>>>> That's another option that needs to be discus= sed/investigated.
>>>>>> I'm
>>>> afraid
>>>>>> this is not the rationale adopted in -04 sinc= e it includes some
>>>>>> text
>>>> that
>>>>>> is far to be sufficient to ensure interoperab= le implementations.
>>>>>>
>>>>>> BTW, saying that nsh does not need to deal wi= th fragmentation
>>>>>> because
>>>> it
>>>>>> is transport-independent is not IMHO a good s= trategy to adopt
>>>>>> here
>>>> because
>>>>>> it opens the door for interoperable issues, i= t may lead to
>>>>>> sub-optimal implementations if the sfc inform= ation is present
>>>>>> only in one
>>>> fragments,
>>>>>> etc.
>>>>>>
>>>>>> My comments are related to the current text i= n the -04.
>>>>>> This text needs
>>>> to
>>>>>> be fixed somehow.
>>>>>>
>>>>>> Cheers, Med
>>>>>>
>>>>>>> -----Message d'origine----- De : Elzur, U= ri
>>>>>>> [m= ailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril
>>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OL= N; Thomas Narten;
>>>>>>> sfc@ietf.= org Objet : RE: [sfc] WG last call for
>>>>>>> draft-ietf-sfc-nsh-04.txt
>>>>>>>
>>>>>>> Hi Med
>>>>>>>
>>>>>>> I see no need to specify the exact behavi= or as NSH is transport
>>>>>>> independent i.e. like NSH interaction wit= h any other Transport
>>>>>>> eh issue of Fragmentation is to be dealt = in a way that matches
>>>>>>> the mechanisms supported by the Transport= used and do not belong
>>>>>>> in the NSH draft
>>>>>>>
>>>>>>> Thx
>>>>>>>
>>>>>>> Uri ("Oo-Ree") C: 949-378-7568<= /div>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message----- From: sfc
>>>>>>> [= mailto:sfc-bounces@ietf.org] On Behalf Of
>>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14,
>>>>>>> 2016 12:43 AM To: Thomas Narten <narten@us.ibm.com>;
>>>>>>> sfc@ietf.= org Subject: Re: [sfc] WG last call for
>>>>>>> draft-ietf-sfc-nsh-04.txt
>>>>>>>
>>>>>>> R-,
>>>>>>>
>>>>>>> In addition to other pending issues raise= d for this draft, I
>>>>>>> would like to raise this additional one a= bout Section 6.
>>>>>>>
>>>>>>> =3D=3D 6.  Fragmentation Considerati= ons
>>>>>>>
>>>>>>> NSH and the associated transport header a= re "added" to the
>>>>>>> encapsulated packet/frame.  This add= itional information
>>>>>>> increases
>>>> the
>>>>>>> size of the packet.  In order the en= sure proper forwarding of
>>>>>>> NSH data, several options for handling fr= agmentation and
>>>>>>> re-assembly exist:
>>>>>>>
>>>>>>> 1.  Jumbo Frames, when supported, en= able the transport of NSH
>>>>>>> and associated transport packets without = requiring
>>>>>>> fragmentation.
>>>>>>>
>>>>>>> 2.  Path MTU Discovery [RFC1191]&quo= t;describes a technique for
>>>>>>> dynamically discovering the maximum trans= mission unit (MTU) of
>>>> an
>>>>>>> arbitrary internet path" and can be = utilized to ensure the
>>> the
>>>>>>> required packet size is used.
>>>>>>>
>>>>>>> 3.  [RFC6830] describes two schemes = for fragmentation and
>>>>>>> re-
>>>> assembly
>>>>>>> in section 5.4. =3D=3D
>>>>>>>
>>>>>>> * The text is weak for a Standard track d= ocument that is
>>>>>>> intended to solve the problem in
>>> 2.12.
>>>>>>> There should be a clear behavior to be fo= llowed by an
>>> implementation.
>>>>>>> Further, I would avoid the use of words s= uch as "can".
>>>>>>>
>>>>>>> * The text covers only fragmentation when= it is induced by SFC
>>>>>>> operations, it does not discuss the treat= ment of a fragment when
>>>>>>> received in an SFC domain. IMHO, the draf= t should also specify
>>>>>>> the behavior of the Classifier with regar= ds to fragments for the
>>>>>>> sake of proper SFC operation. Applying cl= assification policies
>>>>>>> may require the
>>>>>> full packet, not only a fragment.
>>>>>>> In particular, dedicated resources should= dedicated for handling
>>>>>>> out of order fragments. Of course, it is = out of scope of this
>>>>>>> document to describe how SFs handle fragm= ents.
>>>>>>>
>>>>>>> * If an SFC header is prepended for all f= ragments, I'm not sure
>>>>>>> there is any particular issue at the SFF = level...except if
>>>>>>> stripping/adding context TLVs depends on = the full packet (not
>>>>>>> just fragment). It is warranted to consid= er a little bit this
>>>>>>> point before declaring there
>>>> is
>>>>>> no issue.
>>>>>>>
>>>>>>> * The text states "several options&q= uot;. This may be interpreted as
>>>>>>> if implementing one of them is sufficient= ...which is not true.
>>>>>>> The first two points contribute to minimi= ze the fragmentation
>>>>>>> risk, but fragmentation may still be expe= rienced (e.g., other
>>>>>>> shims are prepended by other nodes for so= me other purposes,
>>>>>>> nested nsh, etc.)
>>>>>>>
>>>>>>> * The first two points have nothing to do= with reassembly.
>>>>>>>
>>>>>>> * The support of jumbo frames by a router= /device does not mean
>>>>>>> that it can make use of it. Appropriate M= TU configuration should
>>>>>>> be undertaken in a consistent manner with= in an SFC domain. The
>>>>>>> text should be updated to make it is abou= t (consistent) MTU
>>> configuration.
>>>>>>>
>>>>>>> * BTW, shouldn't the text be reworded to = recommended to increase
>>>>>>> the MTU of **all nodes** of an SFC-enable= d domain by at least
>>>>>>> the length of SFC header + transport = header?
>>>>>>>
>>>>>>> * Bullet 2, how PMTU discovery is actuall= y used in this context?
>>>>>>> Do you assume that all SFC-aware nodes wi= ll issue such messages
>>>>>>> towards other SFC-aware node, arbitrary d= estination, else?
>>>>>>>
>>>>>>> * Bullet 2, I would drop "describes = a technique for dynamically
>>>>>>> discovering the maximum transmission unit=
>>>>>>> (MTU) of an arbitrary internet path"= .
>>>>>>>
>>>>>>> * Bullet 2, s/ the the/the.
>>>>>>>
>>>>>>> * The reference to the LISP specification= raises two concerns
>>>>>>> and one comment:
>>>>>>>
>>>>>>> (1) I don't think it is a good approach t= hat fragments induced
>>>>>>> by the network are passed to their ultima= te destinations as such
>>> (stateless).
>>>>>>> IMO, reassembly should be done within the= SFC domain
>>>>>>> (responsible for fragmentation) not passe= d away. (2) Does the
>>>>>>> stateful mode require all SFC data plane = elements maintain a
>>>>>>> full list of MTU for the any SFF/SF insta= nce of the SFC
>>>>>> domain?
>>>>>>>
>>>>>>> The current text suggests that [RFC6830] = should be listed as
>>>>>>> normative reference (not an informative o= ne). I would personally
>>>>>>> favor removing the reference to LISP (as = it is an Experimental
>>>>>>> RFC).
>>>>>>>
>>>>>>> * The security section of the draft may b= e augmented with
>>>>>>> informational fragmentation-related point= ers to:
>>>>>>> e.g., RFC1858 (Security Considerations fo= r IP Fragment
>>>>>>> Filtering), RFC3128 (Protection Against a= Variant of the Tiny
>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reas= sembly Errors at High
>>>>>>> Data Rates).
>>>>>>>
>>>>>>> Cheers, Med
>>>>>>>
>>>>>>>> -----Message d'origine----- De : sfc =
>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de
>>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril
>>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org Objet : Re:
>>>>>>>> [sfc] WG last call for draft-ietf-sfc= -nsh-04.txt
>>>>>>>>
>>>>>>>> Dear Thomas, all,
>>>>>>>>
>>>>>>>> As I mentioned during the meeting, th= ere are several issues
>>>>>>>> that are not covered in the last vers= ion of the draft. I
>>>>>>>> already provided examples of the issu= es offline as requested by
>>>>>>>> Martin.
>>>>>>>>
>>>>>>>> Cheers, Med
>>>>>>>>
>>>>>>>>> -----Message d'origine----- De : = sfc
>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten
>>>>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:= 48 =C0 :
>>>>>>>>> s= fc@ietf.org Objet : [sfc] WG last call for
>>>>>>>>> draft-ietf-sfc-nsh-04.txt
>>>>>>>>>
>>>>>>>>> Dear WG:
>>>>>>>>>
>>>>>>>>> This note begins a WG last call o= n draft-ietf-sfc-nsh-04.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
The editors of the NSH document have indicated that they have
>>>>>>>>> addressed all known comments and = that there are no open issues
>>>>>>>>> with the current version of the d= ocument.
>>>>>>>>>
>>>>>>>>> Substantive comments to the list = please, editorial comments
>>>>>>>>> can go directly to the document e= ditors.
>>>>>>>>>
>>>>>>>>> We'll also get a brief update fro= m the editors at next week's
>>>>>>>>> meeting. If there are any remaini= ng issues with the document,
>>>>>>>>> raising them before the meeting w= ould be especially helpful.
>>>>>>>>>
>>>>>>>>> For the chairs, Thomas
>>>>>>>>>
>>>>>>>>> _________________________________= ______________ sfc mailing
>>>>>>>>
>>>>>>>> _____________________________________= __________ sfc mailing
>>>>>>>
>>>>>>> _________________________________________= ______ sfc mailing list
>>>>>>
>>>>>> _____________________________________________= __ sfc mailing list
>>>>>
>>>>> _______________________________________________ s= fc mailing list
>>>>>
>>>
>>> _______________________________________________ sfc maili= ng list
>>
>> _______________________________________________ sfc mailing l= ist
>>
 
--_000_4A95BA014132FF49AE685FAB4B9F17F657E7CFA1dfweml501mbb_-- From nobody Tue Apr 26 12:55:28 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 A13B612D57F for ; Tue, 26 Apr 2016 12:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 JpoLXlKdFKNE for ; Tue, 26 Apr 2016 12:55:24 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id D3D1812D0BA for ; Tue, 26 Apr 2016 12:55:23 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 26 Apr 2016 15:55:22 -0400 From: Dave Dolson To: "Joel M. Halpern" , Ron Parker , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfOeSAX3MU5GUyUYGxYNRxnVJ+E858AgAR8AoCAEDuWAIAA6WYAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAGaMgCAAAZigIAABDQAgAAC24CAABdWAIAAFZWAgAAJS4D//8DWkA== Date: Tue, 26 Apr 2016 19:55:22 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> <1d9ca816-42ae-333c-a316-7ec5bff8b55b@joelhalpern.com> In-Reply-To: <1d9ca816-42ae-333c-a316-7ec5bff8b55b@joelhalpern.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 19:55:26 -0000 Fragment reassembly is a computationally expensive process and tunnel fragmentation can substantially inflate the number of=20 packets, so I prefer fragmenting the inner packet. This allows SFFs and SFs to forward NSH packets without first reassembling them. If the inner packet is IPv6 or IPv4 with DF=3D1, Path-MTU discovery can be facilitated by sending an ICMP "Packet too big" message to=20 the sender. (RFC 1191, RFC 1981) There is an additional benefit that inner fragmentation/PMTU discovery allow service chaining to work even if the transport layer does not=20 facilitate fragmentation (e.g., when NSH is transported directly over=20 Ethernet). The fragmentation and Path MTU discovery are standard mechanisms, and permitted to be used for any link, so nothing needs to be said in the NSH draft to permit this. However, I think it would be useful to recommend these approaches. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, April 26, 2016 3:12 PM To: Ron Parker; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt In most tunnel anlysis, a tunnel entry point (in this case, the=20 transport interface from the SFC component) can either fragment outer=20 or, if available fragment inner. This is defined by the transport=20 technology, not the user. In the case of SFC NSH, I would usually expect outer fragmentation,=20 which is a pure transport issue. If the innermost packet is IP, and the=20 tunnel entry wants to be complicated, it is permitted to fragment the=20 inner packet and produce the proper NSH headers for the fragments.=20 Inherently, an implementation can only choose to do this if it can=20 construct the right metdata to put on each fragment. I don't actually=20 know how to reliably do that, so I don't recommend it. In either case, the NSH document can't tell the implementation what to=20 do or how to do it. Yours, Joel On 4/26/16 2:38 PM, Ron Parker wrote: > Joel, > > I can't say that I disagree with your analysis on the scope. I think th= e question raised by some on the thread is if an SFC-node (i.e., classifier= , SF, SFF) creates fragments, is the NSH header repeated in each fragment ?= I think the answer is "no". If so, is it worth stating this explicitl= y in the document, or is it just obvious that properly layered systems woul= d behave that way. > > Ron > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 26, 2016 1:22 PM > To: Ron Parker ; Joel M. Halpern ; mohamed.boucadair@orange.com; Elzur, Uri ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > At least so far, we have treated the communication between classifier and= SFF (ingress or intermediate) as outside of the scope of our work. > For SF <-> SFF communication we have ntoed the need for a proxy to handle= the case when the SF can not accept and return the NSH header, since we as= sume that is preserved. Other than that preservation, similar to the above= , we have treated the details as outside of our scope. That is because they= depend so heavily on the implementation technique used. (Hypervisor ,_> a= pplication communication vs communication inside a user space or communicat= ion over an actual Ethernet are all very different.) > > Trying to extend the NSH document to address these would be a major chang= e, and would step into the issues related to transport selection, which are= explicitly out of scope. > > Yours, > Joel > > On 4/26/16 11:58 AM, Ron Parker wrote: >> Linda, >> >> I like the first clause (transport tunnel based fragmentation). >> >> Regarding the second (source based), I think there are more subcases to = consider: >> >> 1. Propagation of NSH encapsulated packet from classifier to SFF 2. >> Propagation of NSH encapsulated packet from SFF to SF 3. Propagation >> of NSH encapsulated packet from SF to SFF (including possibility that >> NSH size increased at SF) 4. Propagation of NSH encapsulated packet >> from SFF to SFF >> >> In each of the 4 cases above, there is the possibility that MTU will be= exceeded and therefore there are procedures to be defined in that eventual= ity. >> >> Thanks. >> >> Ron >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar >> Sent: Tuesday, April 26, 2016 11:48 AM >> To: Joel M. Halpern ; >> mohamed.boucadair@orange.com; Elzur, Uri ; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Joel, >> >> I think the document should add the description on the following two fra= gmentation scenarios: >> >> - Transport tunnel generated fragmentation: >> When a packet fragmentation is caused by transport tunnel (i.e. variou= s encapsulations), the termination point of the transport tunnel is respons= ible for re-assembling the fragmented pieces of the packet. Since there won= 't be any SFF nodes in between the Transport Tunnel, the tunnel generated f= ragmentation does not require any actions by SFF nodes or SF nodes. >> >> >> - Source node generated fragmentation (after adding on the NSH header): >> When fragmentation has to be performed for a packet being encapsulate= d with the NSH header, either the intermediate SFF nodes or the SF nodes ha= ve to be able to reassemble the fragmented pieces. >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 26, 2016 10:33 AM >> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that you are referring only to the = case of transport generated fragmentation of the outer packet. I had assum= ed you were not talking about that, since the resulting fragments will not = all have NSH headers. As with any tunnel technology, if the tunnel chooses= to fragment at its layer, then the tunnel is responsible for reassembly. = That would be invisible to the SFF. >> >> Yours, >> Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>> Agree with Med. >>> >>> Even if each fragment piece of a packet with NSH header carries the NSH= header, the intermediate SFF nodes still need to put together all the frag= ments together before passing the whole data frame to the SF. >>> >>> Linda >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Monday, April 25, 2016 9:42 AM >>> To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Re-, >>> >>> How do you instruct the transport layer to ALWAYS prepend an NSH header= even for fragments? Or you don't care about that? >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril >>>> 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>> draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Med >>>> >>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* >>>> a transport, dealing with fragmentation is left to the Transport used. >>>> >>>> The model I use for NSH, is basically similar to VXLAN . It is an over= ly. >>>> >>>> Thx >>>> >>>> Uri ("Oo-Ree") >>>> C: 949-378-7568 >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com >>>> Sent: Monday, April 25, 2016 7:18 AM >>>> To: Joel M. Halpern ; sfc@ietf.org >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Joel, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 >>>>> avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet = : >>>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> If I am understanding you correctly Med, you are asking that the >>>>> NSH draft specify how service chaining should cope with packets >>>>> that have been fragmented? >>>>> >>>> >>>> [Med] To be accurate, I'm asking to assess whether there are implicati= ons. >>>> If there are, then the draft should be updated accordingly. >>>> >>>>> NSH, and the SFF functionality, does not care. >>>> >>>> [Med] I'm not that sure. Some typical implications are listed below: >>>> >>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>> didn't maintained a state, subsequent fragments won't be appropriately= processed. >>>> * SFC-aware function: if prepending a context information depends on >>>> the full packet, not only a fragment. >>>> >>>> It just does its job. >>>> >>>> [Med] which may be disturbed in some situations as listed in the >>>> examples above. >>>> >>>>> Ingress and intermediate classifiers may cope with fragments in any >>>>> number of ways. >>>> Specifying such is clearly out of scope for this draft. >>>> >>>> [Med] The purpose is not to specify the internal implementation >>>> details but the external behavior of the classifier function when it >>>> comes to handle fragments. That behavior may have an incidence on >>>> SFF, in particular. The purpose is not to recommend the maximum >>>> resources to be dedicated to out of order fragments nor the timeout >>>> to cache those; these considerations are of course out of scope. >>>> Nevertheless, an implementation should offer a configurable >>>> parameter so that an operator tweak those according to its context. >>>> >>>>> I suppose one could write an informational draft on possible ways >>>>> of coping. The IETF has not usually published such. >>>>> Service functions have to cope with fragmented packets just as they >>>>> had to before the advent of NSH, so describing that is clearly not >>>>> needed here. >>>> >>>> [Med] The advent of NSH has the following implications: >>>> * it exacerbates fragmentation. Handing over this issue to the >>>> transport layer may lead to interoperability issues. >>>> * the chaining may not be efficient if fragments are inappropriately >>>> handled. >>>> >>>> Introducing NSH should not degrade the overall service compared to >>>> legacy service deployment schemes. >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>> Re-, >>>>>> >>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>> what to >>>>> put in the draft. FWIW, I'm discussing two fragmentation issues: >>>>>> >>>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>> >>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>> explicitly >>>>> called out in the text (see my first message). >>>>>> >>>>>> There are other issues that need to be discussed, e.g., how to >>>>>> deal with >>>>> fragments in SFFs/Classifiers? >>>>>> >>>>>> It is also "prudent" to check that no issues will be experienced >>>>>> in SFF >>>>> to handle fragments. If an SFC header is prepended for all >>>>> fragments, I'm not sure there >>>>>> is any particular issue at the SFF level, except if >>>>>> stripping/adding >>>>> context TLVs depends on the full packet (not just fragment). It is >>>>> warranted to consider a little bit this point before declaring >>>>> there is no issue. >>>>>> >>>>>> For point (1), declaring fragmentation out of scope would be meant >>>>>> that >>>>> an implementation must be prepared to receive fragments with or >>>>> without NSH header as this is a decision that is left to the >>>>> transport encapsulation. This is a requirement per se! >>>>>> >>>>>> I won't reiterate all the comments I have about the current >>>>>> wording of >>>>> this section. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 >>>>>>> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> My point is that Fragmentation is yet another transport related >>>>>>> issue >>>>> that >>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>> it >>>>> doesn't >>>>>>> really belong in the draft. We are providing an advice as >>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>> you'll find it doesn't even >>>>> relate >>>>>>> to it. >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") >>>>>>> C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com >>>>>>> Sent: Sunday, April 24, 2016 10:32 PM >>>>>>> To: Elzur, Uri ; Thomas Narten >>>>> ; >>>>>>> sfc@ietf.org >>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Uri, >>>>>>> >>>>>>> That's another option that needs to be discussed/investigated. >>>>>>> I'm >>>>> afraid >>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>> text >>>>> that >>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>> >>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>> because >>>>> it >>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>> here >>>>> because >>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>> sub-optimal implementations if the sfc information is present >>>>>>> only in one >>>>> fragments, >>>>>>> etc. >>>>>>> >>>>>>> My comments are related to the current text in the -04. This text >>>>>>> needs >>>>> to >>>>>>> be fixed somehow. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche >>>>>>>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas >>>>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>>>> independent i.e. like NSH interaction with any other Transport >>>>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>>>> the mechanisms supported by the Transport used and do not belong >>>>>>>> in the NSH draft >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") >>>>>>>> C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com >>>>>>>> Sent: Thursday, April 14, 2016 12:43 AM >>>>>>>> To: Thomas Narten ; sfc@ietf.org >>>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> R-, >>>>>>>> >>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>> would like to raise this additional one about Section 6. >>>>>>>> >>>>>>>> =3D=3D >>>>>>>> 6. Fragmentation Considerations >>>>>>>> >>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>> encapsulated packet/frame. This additional information >>>>>>>> increases >>>>> the >>>>>>>> size of the packet. In order the ensure proper forwarding of N= SH >>>>>>>> data, several options for handling fragmentation and re-assembl= y >>>>>>>> exist: >>>>>>>> >>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH a= nd >>>>>>>> associated transport packets without requiring fragmentatio= n. >>>>>>>> >>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>> (MTU) of >>>>> an >>>>>>>> arbitrary internet path" and can be utilized to ensure >>>>>>>> the >>>> the >>>>>>>> required packet size is used. >>>>>>>> >>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- >>>>> assembly >>>>>>>> in section 5.4. >>>>>>>> =3D=3D >>>>>>>> >>>>>>>> * The text is weak for a Standard track document that is >>>>>>>> intended to solve the problem in >>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>> 2.12. >>>>>>>> There should be a clear behavior to be followed by an >>>> implementation. >>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>> >>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>> operations, it does not discuss the treatment of a fragment when >>>>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>>>> the behavior of the Classifier with regards to fragments for the >>>>>>>> sake of proper SFC operation. Applying classification policies >>>>>>>> may require the >>>>>>> full packet, not only a fragment. >>>>>>>> In particular, dedicated resources should dedicated for handling >>>>>>>> out of order fragments. Of course, it is out of scope of this >>>>>>>> document to describe how SFs handle fragments. >>>>>>>> >>>>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>>>> there is any particular issue at the SFF level...except if >>>>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>>>> just fragment). It is warranted to consider a little bit this >>>>>>>> point before declaring there >>>>> is >>>>>>> no issue. >>>>>>>> >>>>>>>> * The text states "several options". This may be interpreted as >>>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>>> The first two points contribute to minimize the fragmentation >>>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>>> nested nsh, >>>>>>>> etc.) >>>>>>>> >>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>> >>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>>>> text should be updated to make it is about (consistent) MTU >>>> configuration. >>>>>>>> >>>>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>>>> the length of SFC header + transport header? >>>>>>>> >>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>>> >>>>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>>>> discovering the maximum transmission unit (MTU) of an arbitrary >>>>>>>> internet path". >>>>>>>> >>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>> >>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>> and one >>>>>>>> comment: >>>>>>>> >>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>> by the network are passed to their ultimate destinations as such >>>> (stateless). >>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>> (responsible for >>>>>>>> fragmentation) not passed away. >>>>>>>> (2) Does the stateful mode require all SFC data plane elements >>>>>>>> maintain a full list of MTU for the any SFF/SF instance of the >>>>>>>> SFC >>>>>>> domain? >>>>>>>> >>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>> normative reference (not an informative one). I would personally >>>>>>>> favor removing the reference to LISP (as it is an Experimental RFC= ). >>>>>>>> >>>>>>>> * The security section of the draft may be augmented with >>>>>>>> informational fragmentation-related pointers to: e.g., RFC1858 >>>>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 >>>>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and >>>>>>>> RFC >>>>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:14= =C0 : >>>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear Thomas, all, >>>>>>>>> >>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>> already provided examples of the issues offline as requested by M= artin. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas >>>>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org >>>>>>>>>> Objet >>>>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>> >>>>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>>>> addressed all known comments and that there are no open issues >>>>>>>>>> with the current version of the document. >>>>>>>>>> >>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>> can go directly to the document editors. >>>>>>>>>> >>>>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>>> >>>>>>>>>> For the chairs, >>>>>>>>>> Thomas >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> sfc mailing list >>>>>>>>>> sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sfc mailing list >>>>>>>>> sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 26 13:03:26 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 CC0CB12B038 for ; Tue, 26 Apr 2016 13:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 QoR88w0kjWfC for ; Tue, 26 Apr 2016 13:03:20 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9A512B015 for ; Tue, 26 Apr 2016 13:03:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 904462662AA; Tue, 26 Apr 2016 13:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461701000; bh=CGBq6lStTWOJP3YFViKLM9rdb2clnT7Wv6o8PNXULt0=; h=Date:Subject:From:To:From; b=P6hqhWRgjM6GU9oYFtZi5QgK4YBrqSmmIocoEIkhif7v736CltkyPQc2CiDFWABDn A3UqXSYZM/P6EFf5ilwPMluLLOtn8L0gV3UIUwOdfQYoJI+mZK1vsJhB4x08y1uiGP btT0URjotU8QRbCqCpKisnQ1ZrHK0iq12XqiCIyI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.239.34.68] (mobile-166-171-058-125.mycingular.net [166.171.58.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 22731259F28; Tue, 26 Apr 2016 13:03:19 -0700 (PDT) Date: Tue, 26 Apr 2016 16:03:16 -0400 Message-ID: Importance: normal From: "jmh.direct" To: Dave Dolson , "Joel M. Halpern" , Ron Parker , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_3503018393531020" Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 20:03:25 -0000 ----_com.samsung.android.email_3503018393531020 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RG9pbmcgcGF0aCBNVFUgZGlzY292ZXJ5IGluc3RlYWQgb2YgZnJhZ21lbnRhdGlvbiBpcyBhIHZl cnkgcmVhc29uYWJsZSBzdHJhdGVneSwgcGFydGljdWxhcmx5IGluIHN1cHBvcnRpbmcgSVB2Ni4K VGhlIHBvaW50IGlzIHRoYXQgdGhlcmUgYXJlIG11bHRpcGxlIHJlYXNvbmFibGUgcmVzcG9uc2Vz LCBkZXBlbmRpbmcgdXBvbiB0aGUgdHJhbnNwb3J0IGFuZCBvdGhlciBmYWN0b3JzLiDCoEl0IGlz IG5vdCBmb3IgTlNIIHRvIG1hbmRhdGUgb25lLgpZb3VycyxKb2VsCgoKU2VudCB2aWEgdGhlIFNh bXN1bmcgR2FsYXh5IFPCriA2LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lLS0tLS0tLS0gT3Jp Z2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5l LmNvbT4gRGF0ZTogNC8yNi8yMDE2ICAzOjU1IFBNICAoR01ULTA1OjAwKSBUbzogIkpvZWwgTS4g SGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+LCBSb24gUGFya2VyIDxSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tPiwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSwgIkVsenVy LCBVcmkiIDx1cmkuZWx6dXJAaW50ZWwuY29tPiwgc2ZjQGlldGYub3JnIFN1YmplY3Q6IFJlOiBb c2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQgCkZyYWdtZW50 IHJlYXNzZW1ibHkgaXMgYSBjb21wdXRhdGlvbmFsbHkgZXhwZW5zaXZlIHByb2Nlc3MKYW5kIHR1 bm5lbCBmcmFnbWVudGF0aW9uIGNhbiBzdWJzdGFudGlhbGx5IGluZmxhdGUgdGhlIG51bWJlciBv ZiAKcGFja2V0cywgc28gSSBwcmVmZXIgZnJhZ21lbnRpbmcgdGhlIGlubmVyIHBhY2tldC4KVGhp cyBhbGxvd3MgU0ZGcyBhbmQgU0ZzIHRvIGZvcndhcmQgTlNIIHBhY2tldHMgd2l0aG91dCBmaXJz dCByZWFzc2VtYmxpbmcKdGhlbS4KCklmIHRoZSBpbm5lciBwYWNrZXQgaXMgSVB2NiBvciBJUHY0 IHdpdGggREY9MSwgUGF0aC1NVFUgZGlzY292ZXJ5CmNhbiBiZSBmYWNpbGl0YXRlZCBieSBzZW5k aW5nIGFuIElDTVAgIlBhY2tldCB0b28gYmlnIiBtZXNzYWdlIHRvIAp0aGUgc2VuZGVyLiAoUkZD IDExOTEsIFJGQyAxOTgxKQoKVGhlcmUgaXMgYW4gYWRkaXRpb25hbCBiZW5lZml0IHRoYXQgaW5u ZXIgZnJhZ21lbnRhdGlvbi9QTVRVIGRpc2NvdmVyeQphbGxvdyBzZXJ2aWNlIGNoYWluaW5nIHRv IHdvcmsgZXZlbiBpZiB0aGUgdHJhbnNwb3J0IGxheWVyIGRvZXMgbm90IApmYWNpbGl0YXRlIGZy YWdtZW50YXRpb24gKGUuZy4sIHdoZW4gTlNIIGlzIHRyYW5zcG9ydGVkIGRpcmVjdGx5IG92ZXIg CkV0aGVybmV0KS4KClRoZSBmcmFnbWVudGF0aW9uIGFuZCBQYXRoIE1UVSBkaXNjb3ZlcnkgYXJl IHN0YW5kYXJkIG1lY2hhbmlzbXMsCmFuZCBwZXJtaXR0ZWQgdG8gYmUgdXNlZCBmb3IgYW55IGxp bmssIHNvIG5vdGhpbmcgbmVlZHMgdG8gYmUKc2FpZCBpbiB0aGUgTlNIIGRyYWZ0IHRvIHBlcm1p dCB0aGlzLiBIb3dldmVyLCBJIHRoaW5rIGl0IHdvdWxkCmJlIHVzZWZ1bCB0byByZWNvbW1lbmQg dGhlc2UgYXBwcm9hY2hlcy4KCi1EYXZlCgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJv bTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0u IEhhbHBlcm4KU2VudDogVHVlc2RheSwgQXByaWwgMjYsIDIwMTYgMzoxMiBQTQpUbzogUm9uIFBh cmtlcjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgRWx6dXIsIFVyaTsgc2ZjQGlldGYu b3JnClN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5z aC0wNC50eHQKCkluIG1vc3QgdHVubmVsIGFubHlzaXMsIGEgdHVubmVsIGVudHJ5IHBvaW50IChp biB0aGlzIGNhc2UsIHRoZSAKdHJhbnNwb3J0IGludGVyZmFjZSBmcm9tIHRoZSBTRkMgY29tcG9u ZW50KSBjYW4gZWl0aGVyIGZyYWdtZW50IG91dGVyIApvciwgaWYgYXZhaWxhYmxlIGZyYWdtZW50 IGlubmVyLsKgIFRoaXMgaXMgZGVmaW5lZCBieSB0aGUgdHJhbnNwb3J0IAp0ZWNobm9sb2d5LCBu b3QgdGhlIHVzZXIuCgpJbiB0aGUgY2FzZSBvZiBTRkMgTlNILCBJIHdvdWxkIHVzdWFsbHkgZXhw ZWN0IG91dGVyIGZyYWdtZW50YXRpb24sIAp3aGljaCBpcyBhIHB1cmUgdHJhbnNwb3J0IGlzc3Vl LsKgIElmIHRoZSBpbm5lcm1vc3QgcGFja2V0IGlzIElQLCBhbmQgdGhlIAp0dW5uZWwgZW50cnkg d2FudHMgdG8gYmUgY29tcGxpY2F0ZWQsIGl0IGlzIHBlcm1pdHRlZCB0byBmcmFnbWVudCB0aGUg CmlubmVyIHBhY2tldCBhbmQgcHJvZHVjZSB0aGUgcHJvcGVyIE5TSCBoZWFkZXJzIGZvciB0aGUg ZnJhZ21lbnRzLiAKSW5oZXJlbnRseSwgYW4gaW1wbGVtZW50YXRpb24gY2FuIG9ubHkgY2hvb3Nl IHRvIGRvIHRoaXMgaWYgaXQgY2FuIApjb25zdHJ1Y3QgdGhlIHJpZ2h0IG1ldGRhdGEgdG8gcHV0 IG9uIGVhY2ggZnJhZ21lbnQuwqAgSSBkb24ndCBhY3R1YWxseSAKa25vdyBob3cgdG8gcmVsaWFi bHkgZG8gdGhhdCwgc28gSSBkb24ndCByZWNvbW1lbmQgaXQuCgpJbiBlaXRoZXIgY2FzZSwgdGhl IE5TSCBkb2N1bWVudCBjYW4ndCB0ZWxsIHRoZSBpbXBsZW1lbnRhdGlvbiB3aGF0IHRvIApkbyBv ciBob3cgdG8gZG8gaXQuCgpZb3VycywKSm9lbAoKT24gNC8yNi8xNiAyOjM4IFBNLCBSb24gUGFy a2VyIHdyb3RlOgo+IEpvZWwsCj4KPiBJIGNhbid0IHNheSB0aGF0IEkgZGlzYWdyZWUgd2l0aCB5 b3VyIGFuYWx5c2lzIG9uIHRoZSBzY29wZS7CoMKgIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIHJhaXNl ZCBieSBzb21lIG9uIHRoZSB0aHJlYWQgaXMgaWYgYW4gU0ZDLW5vZGUgKGkuZS4sIGNsYXNzaWZp ZXIsIFNGLCBTRkYpIGNyZWF0ZXMgZnJhZ21lbnRzLCBpcyB0aGUgTlNIIGhlYWRlciByZXBlYXRl ZCBpbiBlYWNoIGZyYWdtZW50ID/CoMKgwqAgSSB0aGluayB0aGUgYW5zd2VyIGlzICJubyIuwqDC oCBJZiBzbywgaXMgaXQgd29ydGggc3RhdGluZyB0aGlzIGV4cGxpY2l0bHkgaW4gdGhlIGRvY3Vt ZW50LCBvciBpcyBpdCBqdXN0IG9idmlvdXMgdGhhdCBwcm9wZXJseSBsYXllcmVkIHN5c3RlbXMg d291bGQgYmVoYXZlIHRoYXQgd2F5Lgo+Cj7CoMKgwqAgUm9uCj4KPgo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbV0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAyNiwgMjAxNiAxOjIyIFBNCj4gVG86IFJv biBQYXJrZXIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+OyBKb2VsIE0uIEhhbHBl cm4gPGptaEBqb2VsaGFscGVybi5jb20+OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBF bHp1ciwgVXJpIDx1cmkuZWx6dXJAaW50ZWwuY29tPjsgc2ZjQGlldGYub3JnCj4gU3ViamVjdDog UmU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dAo+Cj4g QXQgbGVhc3Qgc28gZmFyLCB3ZSBoYXZlIHRyZWF0ZWQgdGhlIGNvbW11bmljYXRpb24gYmV0d2Vl biBjbGFzc2lmaWVyIGFuZCBTRkYgKGluZ3Jlc3Mgb3IgaW50ZXJtZWRpYXRlKSBhcyBvdXRzaWRl IG9mIHRoZSBzY29wZSBvZiBvdXIgd29yay4KPiBGb3IgU0YgPC0+IFNGRiBjb21tdW5pY2F0aW9u IHdlIGhhdmUgbnRvZWQgdGhlIG5lZWQgZm9yIGEgcHJveHkgdG8gaGFuZGxlIHRoZSBjYXNlIHdo ZW4gdGhlIFNGIGNhbiBub3QgYWNjZXB0IGFuZCByZXR1cm4gdGhlIE5TSCBoZWFkZXIsIHNpbmNl IHdlIGFzc3VtZSB0aGF0IGlzIHByZXNlcnZlZC7CoCBPdGhlciB0aGFuIHRoYXQgcHJlc2VydmF0 aW9uLCBzaW1pbGFyIHRvIHRoZSBhYm92ZSwgd2UgaGF2ZSB0cmVhdGVkIHRoZSBkZXRhaWxzIGFz IG91dHNpZGUgb2Ygb3VyIHNjb3BlLiBUaGF0IGlzIGJlY2F1c2UgdGhleSBkZXBlbmQgc28gaGVh dmlseSBvbiB0aGUgaW1wbGVtZW50YXRpb24gdGVjaG5pcXVlIHVzZWQuwqAgKEh5cGVydmlzb3Ig LF8+IGFwcGxpY2F0aW9uIGNvbW11bmljYXRpb24gdnMgY29tbXVuaWNhdGlvbiBpbnNpZGUgYSB1 c2VyIHNwYWNlIG9yIGNvbW11bmljYXRpb24gb3ZlciBhbiBhY3R1YWwgRXRoZXJuZXQgYXJlIGFs bCB2ZXJ5IGRpZmZlcmVudC4pCj4KPiBUcnlpbmcgdG8gZXh0ZW5kIHRoZSBOU0ggZG9jdW1lbnQg dG8gYWRkcmVzcyB0aGVzZSB3b3VsZCBiZSBhIG1ham9yIGNoYW5nZSwgYW5kIHdvdWxkIHN0ZXAg aW50byB0aGUgaXNzdWVzIHJlbGF0ZWQgdG8gdHJhbnNwb3J0IHNlbGVjdGlvbiwgd2hpY2ggYXJl IGV4cGxpY2l0bHkgb3V0IG9mIHNjb3BlLgo+Cj4gWW91cnMsCj4gSm9lbAo+Cj4gT24gNC8yNi8x NiAxMTo1OCBBTSwgUm9uIFBhcmtlciB3cm90ZToKPj4gTGluZGEsCj4+Cj4+IEkgbGlrZSB0aGUg Zmlyc3QgY2xhdXNlICh0cmFuc3BvcnQgdHVubmVsIGJhc2VkIGZyYWdtZW50YXRpb24pLgo+Pgo+ PiBSZWdhcmRpbmcgdGhlIHNlY29uZCAoc291cmNlIGJhc2VkKSwgSSB0aGluayB0aGVyZSBhcmUg bW9yZSBzdWJjYXNlcyB0byBjb25zaWRlcjoKPj4KPj4gMS7CoCBQcm9wYWdhdGlvbiBvZiBOU0gg ZW5jYXBzdWxhdGVkIHBhY2tldCBmcm9tIGNsYXNzaWZpZXIgdG8gU0ZGIDIuCj4+IFByb3BhZ2F0 aW9uIG9mIE5TSCBlbmNhcHN1bGF0ZWQgcGFja2V0IGZyb20gU0ZGIHRvIFNGIDMuwqAgUHJvcGFn YXRpb24KPj4gb2YgTlNIIGVuY2Fwc3VsYXRlZCBwYWNrZXQgZnJvbSBTRiB0byBTRkYgKGluY2x1 ZGluZyBwb3NzaWJpbGl0eSB0aGF0Cj4+IE5TSCBzaXplIGluY3JlYXNlZCBhdCBTRikgNC7CoCBQ cm9wYWdhdGlvbiBvZiBOU0ggZW5jYXBzdWxhdGVkIHBhY2tldAo+PiBmcm9tIFNGRiB0byBTRkYK Pj4KPj4gSW4gZWFjaCBvZiB0aGUgNCBjYXNlcyBhYm92ZSzCoCB0aGVyZSBpcyB0aGUgcG9zc2li aWxpdHkgdGhhdCBNVFUgd2lsbCBiZSBleGNlZWRlZCBhbmQgdGhlcmVmb3JlIHRoZXJlIGFyZSBw cm9jZWR1cmVzIHRvIGJlIGRlZmluZWQgaW4gdGhhdCBldmVudHVhbGl0eS4KPj4KPj4gVGhhbmtz Lgo+Pgo+PsKgwqDCoMKgIFJvbgo+Pgo+Pgo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExp bmRhIER1bmJhcgo+PiBTZW50OiBUdWVzZGF5LCBBcHJpbCAyNiwgMjAxNiAxMTo0OCBBTQo+PiBU bzogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPjsKPj4gbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgRWx6dXIsIFVyaSA8dXJpLmVsenVyQGludGVsLmNvbT47Cj4+IHNm Y0BpZXRmLm9yZwo+PiBTdWJqZWN0OiBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1p ZXRmLXNmYy1uc2gtMDQudHh0Cj4+Cj4+IEpvZWwsCj4+Cj4+IEkgdGhpbmsgdGhlIGRvY3VtZW50 IHNob3VsZCBhZGQgdGhlIGRlc2NyaXB0aW9uIG9uIHRoZSBmb2xsb3dpbmcgdHdvIGZyYWdtZW50 YXRpb24gc2NlbmFyaW9zOgo+Pgo+PiAtIFRyYW5zcG9ydCB0dW5uZWwgZ2VuZXJhdGVkIGZyYWdt ZW50YXRpb246Cj4+wqDCoCBXaGVuIGEgcGFja2V0IGZyYWdtZW50YXRpb24gaXMgY2F1c2VkIGJ5 IHRyYW5zcG9ydCB0dW5uZWwgKGkuZS4gdmFyaW91cyBlbmNhcHN1bGF0aW9ucyksIHRoZSB0ZXJt aW5hdGlvbiBwb2ludCBvZiB0aGUgdHJhbnNwb3J0IHR1bm5lbCBpcyByZXNwb25zaWJsZSBmb3Ig cmUtYXNzZW1ibGluZyB0aGUgZnJhZ21lbnRlZCBwaWVjZXMgb2YgdGhlIHBhY2tldC4gU2luY2Ug dGhlcmUgd29uJ3QgYmUgYW55IFNGRiBub2RlcyBpbiBiZXR3ZWVuIHRoZSBUcmFuc3BvcnQgVHVu bmVsLCB0aGUgdHVubmVsIGdlbmVyYXRlZCBmcmFnbWVudGF0aW9uIGRvZXMgbm90IHJlcXVpcmUg YW55IGFjdGlvbnMgYnkgU0ZGIG5vZGVzIG9yIFNGIG5vZGVzLgo+Pgo+Pgo+PiAtIFNvdXJjZSBu b2RlIGdlbmVyYXRlZCBmcmFnbWVudGF0aW9uIChhZnRlciBhZGRpbmcgb24gdGhlIE5TSCBoZWFk ZXIpOgo+PsKgwqDCoCBXaGVuIGZyYWdtZW50YXRpb24gaGFzIHRvIGJlIHBlcmZvcm1lZCBmb3Ig YSBwYWNrZXQgYmVpbmcgZW5jYXBzdWxhdGVkIHdpdGggdGhlIE5TSCBoZWFkZXIsIGVpdGhlciB0 aGUgaW50ZXJtZWRpYXRlIFNGRiBub2RlcyBvciB0aGUgU0Ygbm9kZXMgaGF2ZSB0byBiZSBhYmxl IHRvIHJlYXNzZW1ibGUgdGhlIGZyYWdtZW50ZWQgcGllY2VzLgo+Pgo+Pgo+Pgo+PiBDaGVlcnMs Cj4+Cj4+Cj4+IExpbmRhCj4+Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+IEZyb206 IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dCj4+IFNlbnQ6IFR1 ZXNkYXksIEFwcmlsIDI2LCAyMDE2IDEwOjMzIEFNCj4+IFRvOiBMaW5kYSBEdW5iYXI7IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IEVsenVyLCBVcmk7Cj4+IHNmY0BpZXRmLm9yZwo+PiBT dWJqZWN0OiBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQu dHh0Cj4+Cj4+IFJlLXJlYWRpbmcgeW91ciBub3RlLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHlvdSBh cmUgcmVmZXJyaW5nIG9ubHkgdG8gdGhlIGNhc2Ugb2YgdHJhbnNwb3J0IGdlbmVyYXRlZCBmcmFn bWVudGF0aW9uIG9mIHRoZSBvdXRlciBwYWNrZXQuwqAgSSBoYWQgYXNzdW1lZCB5b3Ugd2VyZSBu b3QgdGFsa2luZyBhYm91dCB0aGF0LCBzaW5jZSB0aGUgcmVzdWx0aW5nIGZyYWdtZW50cyB3aWxs IG5vdCBhbGwgaGF2ZSBOU0ggaGVhZGVycy7CoCBBcyB3aXRoIGFueSB0dW5uZWwgdGVjaG5vbG9n eSwgaWYgdGhlIHR1bm5lbCBjaG9vc2VzIHRvIGZyYWdtZW50IGF0IGl0cyBsYXllciwgdGhlbiB0 aGUgdHVubmVsIGlzIHJlc3BvbnNpYmxlIGZvciByZWFzc2VtYmx5LsKgIFRoYXQgd291bGQgYmUg aW52aXNpYmxlIHRvIHRoZSBTRkYuCj4+Cj4+IFlvdXJzLAo+PiBKb2VsCj4+Cj4+IE9uIDQvMjYv MTYgMTE6MTAgQU0sIExpbmRhIER1bmJhciB3cm90ZToKPj4+IEFncmVlIHdpdGggTWVkLgo+Pj4K Pj4+IEV2ZW4gaWYgZWFjaCBmcmFnbWVudCBwaWVjZSBvZiBhIHBhY2tldCB3aXRoIE5TSCBoZWFk ZXIgY2FycmllcyB0aGUgTlNIIGhlYWRlciwgdGhlIGludGVybWVkaWF0ZSBTRkYgbm9kZXMgc3Rp bGwgbmVlZCB0byBwdXQgdG9nZXRoZXIgYWxsIHRoZSBmcmFnbWVudHMgdG9nZXRoZXIgYmVmb3Jl IHBhc3NpbmcgdGhlIHdob2xlIGRhdGEgZnJhbWUgdG8gdGhlIFNGLgo+Pj4KPj4+IExpbmRhCj4+ Pgo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4+IEZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YKPj4+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20KPj4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjUsIDIwMTYgOTo0MiBBTQo+Pj4gVG86 IEVsenVyLCBVcmk7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3JnCj4+PiBTdWJqZWN0OiBS ZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pgo+ Pj4gUmUtLAo+Pj4KPj4+IEhvdyBkbyB5b3UgaW5zdHJ1Y3QgdGhlIHRyYW5zcG9ydCBsYXllciB0 byBBTFdBWVMgcHJlcGVuZCBhbiBOU0ggaGVhZGVyIGV2ZW4gZm9yIGZyYWdtZW50cz8gT3IgeW91 IGRvbid0IGNhcmUgYWJvdXQgdGhhdD8KPj4+Cj4+PiBUaGFuayB5b3UuCj4+Pgo+Pj4gQ2hlZXJz LAo+Pj4gTWVkCj4+Pgo+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQo+Pj4+IERlIDog RWx6dXIsIFVyaSBbbWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5jb21dIEVudm95w6kgOiBsdW5kaSAy NSBhdnJpbAo+Pj4+IDIwMTYgMTY6MjYgw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBK b2VsIE0uIEhhbHBlcm47Cj4+Pj4gc2ZjQGlldGYub3JnIE9iamV0IDogUkU6IFtzZmNdIFdHIGxh c3QgY2FsbCBmb3IKPj4+PiBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pj4KPj4+PiBIaSBN ZWQKPj4+Pgo+Pj4+IE5vdCB0byByZXBlYXQgbXkgcG9zaXRpb24sIGJ1dCBJJ2xsIGRvIGl0IGFu eWhvdyA6LSkgQXMgTlNIIGlzICpOT1QqCj4+Pj4gYSB0cmFuc3BvcnQsIGRlYWxpbmcgd2l0aCBm cmFnbWVudGF0aW9uIGlzIGxlZnQgdG8gdGhlIFRyYW5zcG9ydCB1c2VkLgo+Pj4+Cj4+Pj4gVGhl IG1vZGVsIEkgdXNlIGZvciBOU0gsIGlzIGJhc2ljYWxseSBzaW1pbGFyIHRvIFZYTEFOIC4gSXQg aXMgYW4gb3Zlcmx5Lgo+Pj4+Cj4+Pj4gVGh4Cj4+Pj4KPj4+PiBVcmkgKCJPby1SZWUiKQo+Pj4+ IEM6IDk0OS0zNzgtNzU2OAo+Pj4+Cj4+Pj4KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQo+Pj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YKPj4+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tCj4+Pj4gU2VudDogTW9uZGF5LCBB cHJpbCAyNSwgMjAxNiA3OjE4IEFNCj4+Pj4gVG86IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxo YWxwZXJuLmNvbT47IHNmY0BpZXRmLm9yZwo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0 IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQKPj4+Pgo+Pj4+IEhpIEpvZWwsCj4+ Pj4KPj4+PiBQbGVhc2Ugc2VlIGlubGluZS4KPj4+Pgo+Pj4+IENoZWVycywKPj4+PiBNZWQKPj4+ Pgo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0KPj4+Pj4gRGUgOiBKb2VsIE0uIEhh bHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSBFbnZvecOpIDogbHVuZGkgMjUKPj4+ Pj4gYXZyaWwgMjAxNiAxNTo0OCDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IHNmY0Bp ZXRmLm9yZyBPYmpldCA6Cj4+Pj4+IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWll dGYtc2ZjLW5zaC0wNC50eHQKPj4+Pj4KPj4+Pj4gSWYgSSBhbSB1bmRlcnN0YW5kaW5nIHlvdSBj b3JyZWN0bHkgTWVkLCB5b3UgYXJlIGFza2luZyB0aGF0IHRoZQo+Pj4+PiBOU0ggZHJhZnQgc3Bl Y2lmeSBob3cgc2VydmljZSBjaGFpbmluZyBzaG91bGQgY29wZSB3aXRoIHBhY2tldHMKPj4+Pj4g dGhhdCBoYXZlIGJlZW4gZnJhZ21lbnRlZD8KPj4+Pj4KPj4+Pgo+Pj4+IFtNZWRdIFRvIGJlIGFj Y3VyYXRlLCBJJ20gYXNraW5nIHRvIGFzc2VzcyB3aGV0aGVyIHRoZXJlIGFyZSBpbXBsaWNhdGlv bnMuCj4+Pj4gSWYgdGhlcmUgYXJlLCB0aGVuIHRoZSBkcmFmdCBzaG91bGQgYmUgdXBkYXRlZCBh Y2NvcmRpbmdseS4KPj4+Pgo+Pj4+PiBOU0gsIGFuZCB0aGUgU0ZGIGZ1bmN0aW9uYWxpdHksIGRv ZXMgbm90IGNhcmUuCj4+Pj4KPj4+PiBbTWVkXSBJJ20gbm90IHRoYXQgc3VyZS4gU29tZSB0eXBp Y2FsIGltcGxpY2F0aW9ucyBhcmUgbGlzdGVkIGJlbG93Ogo+Pj4+Cj4+Pj4gKiBTRkY6IElmIHRo ZSBOU0ggaGVhZGVyIGlzIHByZXNlbnQgb25seSBpbiB0aGUgYSBmcmFnbWVudCBidXQgU0ZGCj4+ Pj4gZGlkbid0IG1haW50YWluZWQgYSBzdGF0ZSwgc3Vic2VxdWVudCBmcmFnbWVudHMgd29uJ3Qg YmUgYXBwcm9wcmlhdGVseSBwcm9jZXNzZWQuCj4+Pj4gKiBTRkMtYXdhcmUgZnVuY3Rpb246IGlm IHByZXBlbmRpbmcgYSBjb250ZXh0IGluZm9ybWF0aW9uIGRlcGVuZHMgb24KPj4+PiB0aGUgZnVs bCBwYWNrZXQsIG5vdCBvbmx5IGEgZnJhZ21lbnQuCj4+Pj4KPj4+PsKgwqAgSXQganVzdCBkb2Vz IGl0cyBqb2IuCj4+Pj4KPj4+PiBbTWVkXSB3aGljaCBtYXkgYmUgZGlzdHVyYmVkIGluIHNvbWUg c2l0dWF0aW9ucyBhcyBsaXN0ZWQgaW4gdGhlCj4+Pj4gZXhhbXBsZXMgYWJvdmUuCj4+Pj4KPj4+ Pj4gSW5ncmVzcyBhbmQgaW50ZXJtZWRpYXRlIGNsYXNzaWZpZXJzIG1heSBjb3BlIHdpdGggZnJh Z21lbnRzIGluIGFueQo+Pj4+PiBudW1iZXIgb2Ygd2F5cy4KPj4+PsKgwqAgU3BlY2lmeWluZyBz dWNoIGlzIGNsZWFybHkgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRyYWZ0Lgo+Pj4+Cj4+Pj4gW01l ZF0gVGhlIHB1cnBvc2UgaXMgbm90IHRvIHNwZWNpZnkgdGhlIGludGVybmFsIGltcGxlbWVudGF0 aW9uCj4+Pj4gZGV0YWlscyBidXQgdGhlIGV4dGVybmFsIGJlaGF2aW9yIG9mIHRoZSBjbGFzc2lm aWVyIGZ1bmN0aW9uIHdoZW4gaXQKPj4+PiBjb21lcyB0byBoYW5kbGUgZnJhZ21lbnRzLiBUaGF0 IGJlaGF2aW9yIG1heSBoYXZlIGFuIGluY2lkZW5jZSBvbgo+Pj4+IFNGRiwgaW4gcGFydGljdWxh ci4gVGhlIHB1cnBvc2UgaXMgbm90IHRvIHJlY29tbWVuZCB0aGUgbWF4aW11bQo+Pj4+IHJlc291 cmNlcyB0byBiZSBkZWRpY2F0ZWQgdG8gb3V0IG9mIG9yZGVyIGZyYWdtZW50cyBub3IgdGhlIHRp bWVvdXQKPj4+PiB0byBjYWNoZSB0aG9zZTsgdGhlc2UgY29uc2lkZXJhdGlvbnMgYXJlIG9mIGNv dXJzZSBvdXQgb2Ygc2NvcGUuCj4+Pj4gTmV2ZXJ0aGVsZXNzLCBhbiBpbXBsZW1lbnRhdGlvbiBz aG91bGQgb2ZmZXIgYSBjb25maWd1cmFibGUKPj4+PiBwYXJhbWV0ZXIgc28gdGhhdCBhbiBvcGVy YXRvciB0d2VhayB0aG9zZSBhY2NvcmRpbmcgdG8gaXRzIGNvbnRleHQuCj4+Pj4KPj4+Pj7CoMKg IEkgc3VwcG9zZSBvbmUgY291bGQgd3JpdGUgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBvbiBwb3Nz aWJsZSB3YXlzCj4+Pj4+IG9mIGNvcGluZy7CoCBUaGUgSUVURiBoYXMgbm90IHVzdWFsbHkgcHVi bGlzaGVkIHN1Y2guCj4+Pj4+IFNlcnZpY2UgZnVuY3Rpb25zIGhhdmUgdG8gY29wZSB3aXRoIGZy YWdtZW50ZWQgcGFja2V0cyBqdXN0IGFzIHRoZXkKPj4+Pj4gaGFkIHRvIGJlZm9yZSB0aGUgYWR2 ZW50IG9mIE5TSCwgc28gZGVzY3JpYmluZyB0aGF0IGlzIGNsZWFybHkgbm90Cj4+Pj4+IG5lZWRl ZCBoZXJlLgo+Pj4+Cj4+Pj4gW01lZF0gVGhlIGFkdmVudCBvZiBOU0ggaGFzIHRoZSBmb2xsb3dp bmcgaW1wbGljYXRpb25zOgo+Pj4+ICogaXQgZXhhY2VyYmF0ZXMgZnJhZ21lbnRhdGlvbi4gSGFu ZGluZyBvdmVyIHRoaXMgaXNzdWUgdG8gdGhlCj4+Pj4gdHJhbnNwb3J0IGxheWVyIG1heSBsZWFk IHRvIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLgo+Pj4+ICogdGhlIGNoYWluaW5nIG1heSBub3Qg YmUgZWZmaWNpZW50IGlmIGZyYWdtZW50cyBhcmUgaW5hcHByb3ByaWF0ZWx5Cj4+Pj4gaGFuZGxl ZC4KPj4+Pgo+Pj4+IEludHJvZHVjaW5nIE5TSCBzaG91bGQgbm90IGRlZ3JhZGUgdGhlIG92ZXJh bGwgc2VydmljZSBjb21wYXJlZCB0bwo+Pj4+IGxlZ2FjeSBzZXJ2aWNlIGRlcGxveW1lbnQgc2No ZW1lcy4KPj4+Pgo+Pj4+Pgo+Pj4+PiBZb3VycywKPj4+Pj4gSm9lbAo+Pj4+Pgo+Pj4+PiBPbiA0 LzI1LzE2IDM6MDAgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6Cj4+Pj4+ PiBSZS0sCj4+Pj4+Pgo+Pj4+Pj4gSSBoZWFyIHlvdSwgYnV0IG15IGNvbW1lbnQgaXMgdGhhdCB3 ZSBuZWVkLCBhcyBhIFdHLCB0byBkZWNpZGUKPj4+Pj4+IHdoYXQgdG8KPj4+Pj4gcHV0IGluIHRo ZSBkcmFmdC4gRldJVywgSSdtIGRpc2N1c3NpbmcgdHdvIGZyYWdtZW50YXRpb24gaXNzdWVzOgo+ Pj4+Pj4KPj4+Pj4+ICgxKSBGcmFnbWVudGF0aW9uIHRoYXQgaXMgY2F1c2VkIGJ5IHByZXBlbmRp bmcgYW4gU0ZDIGhlYWRlci4KPj4+Pj4+ICgyKSBIYW5kbGluZyBmcmFnbWVudHMgYXQgdGhlIGlu Z3Jlc3Mgb2YgYW4gU0ZDLWVuYWJsZWQgZG9tYWluLgo+Pj4+Pj4KPj4+Pj4+IEluY3JlYXNpbmcg dGhlIE1UVSBpcyBmb3Igc3VyZSBhIHJlY29tbWVuZGF0aW9uIGlzIHRvIGJlCj4+Pj4+PiBleHBs aWNpdGx5Cj4+Pj4+IGNhbGxlZCBvdXQgaW4gdGhlIHRleHQgKHNlZSBteSBmaXJzdCBtZXNzYWdl KS4KPj4+Pj4+Cj4+Pj4+PiBUaGVyZSBhcmUgb3RoZXIgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBk aXNjdXNzZWQsIGUuZy4sIGhvdyB0bwo+Pj4+Pj4gZGVhbCB3aXRoCj4+Pj4+IGZyYWdtZW50cyBp biBTRkZzL0NsYXNzaWZpZXJzPwo+Pj4+Pj4KPj4+Pj4+IEl0IGlzIGFsc28gInBydWRlbnQiIHRv IGNoZWNrIHRoYXQgbm8gaXNzdWVzIHdpbGwgYmUgZXhwZXJpZW5jZWQKPj4+Pj4+IGluIFNGRgo+ Pj4+PiB0byBoYW5kbGUgZnJhZ21lbnRzLiBJZiBhbiBTRkMgaGVhZGVyIGlzIHByZXBlbmRlZCBm b3IgYWxsCj4+Pj4+IGZyYWdtZW50cywgSSdtIG5vdCBzdXJlIHRoZXJlCj4+Pj4+PiBpcyBhbnkg cGFydGljdWxhciBpc3N1ZSBhdCB0aGUgU0ZGIGxldmVsLCBleGNlcHQgaWYKPj4+Pj4+IHN0cmlw cGluZy9hZGRpbmcKPj4+Pj4gY29udGV4dCBUTFZzIGRlcGVuZHMgb24gdGhlIGZ1bGwgcGFja2V0 IChub3QganVzdCBmcmFnbWVudCkuIEl0IGlzCj4+Pj4+IHdhcnJhbnRlZCB0byBjb25zaWRlciBh IGxpdHRsZSBiaXQgdGhpcyBwb2ludCBiZWZvcmUgZGVjbGFyaW5nCj4+Pj4+IHRoZXJlIGlzIG5v IGlzc3VlLgo+Pj4+Pj4KPj4+Pj4+IEZvciBwb2ludCAoMSksIGRlY2xhcmluZyBmcmFnbWVudGF0 aW9uIG91dCBvZiBzY29wZSB3b3VsZCBiZSBtZWFudAo+Pj4+Pj4gdGhhdAo+Pj4+PiBhbiBpbXBs ZW1lbnRhdGlvbiBtdXN0IGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgZnJhZ21lbnRzIHdpdGggb3IK Pj4+Pj4gd2l0aG91dCBOU0ggaGVhZGVyIGFzIHRoaXMgaXMgYSBkZWNpc2lvbiB0aGF0IGlzIGxl ZnQgdG8gdGhlCj4+Pj4+IHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9uLiBUaGlzIGlzIGEgcmVxdWly ZW1lbnQgcGVyIHNlIQo+Pj4+Pj4KPj4+Pj4+IEkgd29uJ3QgcmVpdGVyYXRlIGFsbCB0aGUgY29t bWVudHMgSSBoYXZlIGFib3V0IHRoZSBjdXJyZW50Cj4+Pj4+PiB3b3JkaW5nIG9mCj4+Pj4+IHRo aXMgc2VjdGlvbi4KPj4+Pj4+Cj4+Pj4+PiBDaGVlcnMsCj4+Pj4+PiBNZWQKPj4+Pj4+Cj4+Pj4+ Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tCj4+Pj4+Pj4gRGUgOiBFbHp1ciwgVXJpIFtt YWlsdG86dXJpLmVsenVyQGludGVsLmNvbV0gRW52b3nDqSA6IGx1bmRpIDI1Cj4+Pj4+Pj4gYXZy aWwgMjAxNiAwODozMCDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFRob21hcyBOYXJ0 ZW47Cj4+Pj4+Pj4gc2ZjQGlldGYub3JnIE9iamV0IDogUkU6IFtzZmNdIFdHIGxhc3QgY2FsbCBm b3IKPj4+Pj4+PiBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pj4+Pj4KPj4+Pj4+PiBIaSBN ZWQKPj4+Pj4+Pgo+Pj4+Pj4+IE15IHBvaW50IGlzIHRoYXQgRnJhZ21lbnRhdGlvbiBpcyB5ZXQg YW5vdGhlciB0cmFuc3BvcnQgcmVsYXRlZAo+Pj4+Pj4+IGlzc3VlCj4+Pj4+IHRoYXQKPj4+Pj4+ PiBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIE5TSCBhbmQgYmV5b25kIHRoZSBjaGFydGVyIG9mIHRo ZSBXRywgc28KPj4+Pj4+PiBpdAo+Pj4+PiBkb2Vzbid0Cj4+Pj4+Pj4gcmVhbGx5IGJlbG9uZyBp biB0aGUgZHJhZnQuIFdlIGFyZSBwcm92aWRpbmcgYW4gYWR2aWNlIGFzCj4+Pj4+Pj4gZXh0ZW5k aW5nIHRoZSBzaXplIG9mIHRoZSBwYWNrZXQgbWF5IGxlYWQgdG8gZnJhZ21lbnRhdGlvbiwgYnV0 Cj4+Pj4+Pj4gYXMgeW91IGNoZWNrIFJGQyA3MzQ4IFZ4TEFOLCB3aGljaCBteSBjcmVhdGUgdGhl IHNhbWUgaXNzdWUsCj4+Pj4+Pj4geW91J2xsIGZpbmQgaXQgZG9lc24ndCBldmVuCj4+Pj4+IHJl bGF0ZQo+Pj4+Pj4+IHRvIGl0Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gVGh4Cj4+Pj4+Pj4KPj4+Pj4+PiBV cmkgKCJPby1SZWUiKQo+Pj4+Pj4+IEM6IDk0OS0zNzgtNzU2OAo+Pj4+Pj4+Cj4+Pj4+Pj4KPj4+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+Pj4+Pj4+IEZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YKPj4+Pj4+PiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tCj4+Pj4+Pj4gU2VudDogU3VuZGF5LCBBcHJpbCAyNCwgMjAxNiAxMDoz MiBQTQo+Pj4+Pj4+IFRvOiBFbHp1ciwgVXJpIDx1cmkuZWx6dXJAaW50ZWwuY29tPjsgVGhvbWFz IE5hcnRlbgo+Pj4+PiA8bmFydGVuQHVzLmlibS5jb20+Owo+Pj4+Pj4+IHNmY0BpZXRmLm9yZwo+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2Zj LW5zaC0wNC50eHQKPj4+Pj4+Pgo+Pj4+Pj4+IEhpIFVyaSwKPj4+Pj4+Pgo+Pj4+Pj4+IFRoYXQn cyBhbm90aGVyIG9wdGlvbiB0aGF0IG5lZWRzIHRvIGJlIGRpc2N1c3NlZC9pbnZlc3RpZ2F0ZWQu Cj4+Pj4+Pj4gSSdtCj4+Pj4+IGFmcmFpZAo+Pj4+Pj4+IHRoaXMgaXMgbm90IHRoZSByYXRpb25h bGUgYWRvcHRlZCBpbiAtMDQgc2luY2UgaXQgaW5jbHVkZXMgc29tZQo+Pj4+Pj4+IHRleHQKPj4+ Pj4gdGhhdAo+Pj4+Pj4+IGlzIGZhciB0byBiZSBzdWZmaWNpZW50IHRvIGVuc3VyZSBpbnRlcm9w ZXJhYmxlIGltcGxlbWVudGF0aW9ucy4KPj4+Pj4+Pgo+Pj4+Pj4+IEJUVywgc2F5aW5nIHRoYXQg bnNoIGRvZXMgbm90IG5lZWQgdG8gZGVhbCB3aXRoIGZyYWdtZW50YXRpb24KPj4+Pj4+PiBiZWNh dXNlCj4+Pj4+IGl0Cj4+Pj4+Pj4gaXMgdHJhbnNwb3J0LWluZGVwZW5kZW50IGlzIG5vdCBJTUhP IGEgZ29vZCBzdHJhdGVneSB0byBhZG9wdAo+Pj4+Pj4+IGhlcmUKPj4+Pj4gYmVjYXVzZQo+Pj4+ Pj4+IGl0IG9wZW5zIHRoZSBkb29yIGZvciBpbnRlcm9wZXJhYmxlIGlzc3VlcywgaXQgbWF5IGxl YWQgdG8KPj4+Pj4+PiBzdWItb3B0aW1hbCBpbXBsZW1lbnRhdGlvbnMgaWYgdGhlIHNmYyBpbmZv cm1hdGlvbiBpcyBwcmVzZW50Cj4+Pj4+Pj4gb25seSBpbiBvbmUKPj4+Pj4gZnJhZ21lbnRzLAo+ Pj4+Pj4+IGV0Yy4KPj4+Pj4+Pgo+Pj4+Pj4+IE15IGNvbW1lbnRzIGFyZSByZWxhdGVkIHRvIHRo ZSBjdXJyZW50IHRleHQgaW4gdGhlIC0wNC4gVGhpcyB0ZXh0Cj4+Pj4+Pj4gbmVlZHMKPj4+Pj4g dG8KPj4+Pj4+PiBiZSBmaXhlZCBzb21laG93Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gQ2hlZXJzLAo+Pj4+ Pj4+IE1lZAo+Pj4+Pj4+Cj4+Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQo+Pj4+ Pj4+PiBEZSA6IEVsenVyLCBVcmkgW21haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tXSBFbnZvecOp IDogZGltYW5jaGUKPj4+Pj4+Pj4gMjQgYXZyaWwgMjAxNiAxNzozNiDDgCA6IEJPVUNBREFJUiBN b2hhbWVkIElNVC9PTE47IFRob21hcwo+Pj4+Pj4+PiBOYXJ0ZW47IHNmY0BpZXRmLm9yZyBPYmpl dCA6IFJFOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yCj4+Pj4+Pj4+IGRyYWZ0LWlldGYtc2ZjLW5z aC0wNC50eHQKPj4+Pj4+Pj4KPj4+Pj4+Pj4gSGkgTWVkCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IEkgc2Vl IG5vIG5lZWQgdG8gc3BlY2lmeSB0aGUgZXhhY3QgYmVoYXZpb3IgYXMgTlNIIGlzIHRyYW5zcG9y dAo+Pj4+Pj4+PiBpbmRlcGVuZGVudCBpLmUuIGxpa2UgTlNIIGludGVyYWN0aW9uIHdpdGggYW55 IG90aGVyIFRyYW5zcG9ydAo+Pj4+Pj4+PiBlaCBpc3N1ZSBvZiBGcmFnbWVudGF0aW9uIGlzIHRv IGJlIGRlYWx0IGluIGEgd2F5IHRoYXQgbWF0Y2hlcwo+Pj4+Pj4+PiB0aGUgbWVjaGFuaXNtcyBz dXBwb3J0ZWQgYnkgdGhlIFRyYW5zcG9ydCB1c2VkIGFuZCBkbyBub3QgYmVsb25nCj4+Pj4+Pj4+ IGluIHRoZSBOU0ggZHJhZnQKPj4+Pj4+Pj4KPj4+Pj4+Pj4gVGh4Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+ IFVyaSAoIk9vLVJlZSIpCj4+Pj4+Pj4+IEM6IDk0OS0zNzgtNzU2OAo+Pj4+Pj4+Pgo+Pj4+Pj4+ Pgo+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+Pj4+Pj4+PiBGcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mCj4+Pj4+Pj4+IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20KPj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE0 LCAyMDE2IDEyOjQzIEFNCj4+Pj4+Pj4+IFRvOiBUaG9tYXMgTmFydGVuIDxuYXJ0ZW5AdXMuaWJt LmNvbT47IHNmY0BpZXRmLm9yZwo+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10gV0cgbGFzdCBj YWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFItLAo+ Pj4+Pj4+Pgo+Pj4+Pj4+PiBJbiBhZGRpdGlvbiB0byBvdGhlciBwZW5kaW5nIGlzc3VlcyByYWlz ZWQgZm9yIHRoaXMgZHJhZnQsIEkKPj4+Pj4+Pj4gd291bGQgbGlrZSB0byByYWlzZSB0aGlzIGFk ZGl0aW9uYWwgb25lIGFib3V0IFNlY3Rpb24gNi4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gPT0KPj4+Pj4+ Pj4gNi7CoCBGcmFnbWVudGF0aW9uIENvbnNpZGVyYXRpb25zCj4+Pj4+Pj4+Cj4+Pj4+Pj4+wqDC oMKgIE5TSCBhbmQgdGhlIGFzc29jaWF0ZWQgdHJhbnNwb3J0IGhlYWRlciBhcmUgImFkZGVkIiB0 byB0aGUKPj4+Pj4+Pj7CoMKgwqAgZW5jYXBzdWxhdGVkIHBhY2tldC9mcmFtZS7CoCBUaGlzIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24KPj4+Pj4+Pj4gaW5jcmVhc2VzCj4+Pj4+IHRoZQo+Pj4+Pj4+ PsKgwqDCoCBzaXplIG9mIHRoZSBwYWNrZXQuwqAgSW4gb3JkZXIgdGhlIGVuc3VyZSBwcm9wZXIg Zm9yd2FyZGluZyBvZiBOU0gKPj4+Pj4+Pj7CoMKgwqAgZGF0YSwgc2V2ZXJhbCBvcHRpb25zIGZv ciBoYW5kbGluZyBmcmFnbWVudGF0aW9uIGFuZCByZS1hc3NlbWJseQo+Pj4+Pj4+PsKgwqDCoCBl eGlzdDoKPj4+Pj4+Pj4KPj4+Pj4+Pj7CoMKgwqAgMS7CoCBKdW1ibyBGcmFtZXMsIHdoZW4gc3Vw cG9ydGVkLCBlbmFibGUgdGhlIHRyYW5zcG9ydCBvZiBOU0ggYW5kCj4+Pj4+Pj4+wqDCoMKgwqDC oMKgwqAgYXNzb2NpYXRlZCB0cmFuc3BvcnQgcGFja2V0cyB3aXRob3V0IHJlcXVpcmluZyBmcmFn bWVudGF0aW9uLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PsKgwqDCoCAyLsKgIFBhdGggTVRVIERpc2NvdmVy eSBbUkZDMTE5MV0iZGVzY3JpYmVzIGEgdGVjaG5pcXVlIGZvcgo+Pj4+Pj4+PsKgwqDCoMKgwqDC oMKgIGR5bmFtaWNhbGx5IGRpc2NvdmVyaW5nIHRoZSBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0 Cj4+Pj4+Pj4+IChNVFUpIG9mCj4+Pj4+IGFuCj4+Pj4+Pj4+wqDCoMKgwqDCoMKgwqAgYXJiaXRy YXJ5IGludGVybmV0IHBhdGgiIGFuZCBjYW4gYmUgdXRpbGl6ZWQgdG8gZW5zdXJlCj4+Pj4+Pj4+ IHRoZQo+Pj4+IHRoZQo+Pj4+Pj4+PsKgwqDCoMKgwqDCoMKgIHJlcXVpcmVkIHBhY2tldCBzaXpl IGlzIHVzZWQuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+wqDCoMKgIDMuwqAgW1JGQzY4MzBdIGRlc2NyaWJl cyB0d28gc2NoZW1lcyBmb3IgZnJhZ21lbnRhdGlvbiBhbmQgcmUtCj4+Pj4+IGFzc2VtYmx5Cj4+ Pj4+Pj4+wqDCoMKgwqDCoMKgwqAgaW4gc2VjdGlvbiA1LjQuCj4+Pj4+Pj4+ID09Cj4+Pj4+Pj4+ Cj4+Pj4+Pj4+ICogVGhlIHRleHQgaXMgd2VhayBmb3IgYSBTdGFuZGFyZCB0cmFjayBkb2N1bWVu dCB0aGF0IGlzCj4+Pj4+Pj4+IGludGVuZGVkIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGluCj4+Pj4+ Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDk4I3NlY3Rpb24tCj4+Pj4gMi4x Mi4KPj4+Pj4+Pj4gVGhlcmUgc2hvdWxkIGJlIGEgY2xlYXIgYmVoYXZpb3IgdG8gYmUgZm9sbG93 ZWQgYnkgYW4KPj4+PiBpbXBsZW1lbnRhdGlvbi4KPj4+Pj4+Pj4gRnVydGhlciwgSSB3b3VsZCBh dm9pZCB0aGUgdXNlIG9mIHdvcmRzIHN1Y2ggYXMgImNhbiIuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+ICog VGhlIHRleHQgY292ZXJzIG9ubHkgZnJhZ21lbnRhdGlvbiB3aGVuIGl0IGlzIGluZHVjZWQgYnkg U0ZDCj4+Pj4+Pj4+IG9wZXJhdGlvbnMsIGl0IGRvZXMgbm90IGRpc2N1c3MgdGhlIHRyZWF0bWVu dCBvZiBhIGZyYWdtZW50IHdoZW4KPj4+Pj4+Pj4gcmVjZWl2ZWQgaW4gYW4gU0ZDIGRvbWFpbi4g SU1ITywgdGhlIGRyYWZ0IHNob3VsZCBhbHNvIHNwZWNpZnkKPj4+Pj4+Pj4gdGhlIGJlaGF2aW9y IG9mIHRoZSBDbGFzc2lmaWVyIHdpdGggcmVnYXJkcyB0byBmcmFnbWVudHMgZm9yIHRoZQo+Pj4+ Pj4+PiBzYWtlIG9mIHByb3BlciBTRkMgb3BlcmF0aW9uLiBBcHBseWluZyBjbGFzc2lmaWNhdGlv biBwb2xpY2llcwo+Pj4+Pj4+PiBtYXkgcmVxdWlyZSB0aGUKPj4+Pj4+PiBmdWxsIHBhY2tldCwg bm90IG9ubHkgYSBmcmFnbWVudC4KPj4+Pj4+Pj4gSW4gcGFydGljdWxhciwgZGVkaWNhdGVkIHJl c291cmNlcyBzaG91bGQgZGVkaWNhdGVkIGZvciBoYW5kbGluZwo+Pj4+Pj4+PiBvdXQgb2Ygb3Jk ZXIgZnJhZ21lbnRzLiBPZiBjb3Vyc2UsIGl0IGlzIG91dCBvZiBzY29wZSBvZiB0aGlzCj4+Pj4+ Pj4+IGRvY3VtZW50IHRvIGRlc2NyaWJlIGhvdyBTRnMgaGFuZGxlIGZyYWdtZW50cy4KPj4+Pj4+ Pj4KPj4+Pj4+Pj4gKiBJZiBhbiBTRkMgaGVhZGVyIGlzIHByZXBlbmRlZCBmb3IgYWxsIGZyYWdt ZW50cywgSSdtIG5vdCBzdXJlCj4+Pj4+Pj4+IHRoZXJlIGlzIGFueSBwYXJ0aWN1bGFyIGlzc3Vl IGF0IHRoZSBTRkYgbGV2ZWwuLi5leGNlcHQgaWYKPj4+Pj4+Pj4gc3RyaXBwaW5nL2FkZGluZyBj b250ZXh0IFRMVnMgZGVwZW5kcyBvbiB0aGUgZnVsbCBwYWNrZXQgKG5vdAo+Pj4+Pj4+PiBqdXN0 IGZyYWdtZW50KS4gSXQgaXMgd2FycmFudGVkIHRvIGNvbnNpZGVyIGEgbGl0dGxlIGJpdCB0aGlz Cj4+Pj4+Pj4+IHBvaW50IGJlZm9yZSBkZWNsYXJpbmcgdGhlcmUKPj4+Pj4gaXMKPj4+Pj4+PiBu byBpc3N1ZS4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gKiBUaGUgdGV4dCBzdGF0ZXMgInNldmVyYWwgb3B0 aW9ucyIuIFRoaXMgbWF5IGJlIGludGVycHJldGVkIGFzCj4+Pj4+Pj4+IGlmIGltcGxlbWVudGlu ZyBvbmUgb2YgdGhlbSBpcyBzdWZmaWNpZW50Li4ud2hpY2ggaXMgbm90IHRydWUuCj4+Pj4+Pj4+ IFRoZSBmaXJzdCB0d28gcG9pbnRzIGNvbnRyaWJ1dGUgdG8gbWluaW1pemUgdGhlIGZyYWdtZW50 YXRpb24KPj4+Pj4+Pj4gcmlzaywgYnV0IGZyYWdtZW50YXRpb24gbWF5IHN0aWxsIGJlIGV4cGVy aWVuY2VkIChlLmcuLCBvdGhlcgo+Pj4+Pj4+PiBzaGltcyBhcmUgcHJlcGVuZGVkIGJ5IG90aGVy IG5vZGVzIGZvciBzb21lIG90aGVyIHB1cnBvc2VzLAo+Pj4+Pj4+PiBuZXN0ZWQgbnNoLAo+Pj4+ Pj4+PiBldGMuKQo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAqIFRoZSBmaXJzdCB0d28gcG9pbnRzIGhhdmUg bm90aGluZyB0byBkbyB3aXRoIHJlYXNzZW1ibHkuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+ICogVGhlIHN1 cHBvcnQgb2YganVtYm8gZnJhbWVzIGJ5IGEgcm91dGVyL2RldmljZSBkb2VzIG5vdCBtZWFuCj4+ Pj4+Pj4+IHRoYXQgaXQgY2FuIG1ha2UgdXNlIG9mIGl0LiBBcHByb3ByaWF0ZSBNVFUgY29uZmln dXJhdGlvbiBzaG91bGQKPj4+Pj4+Pj4gYmUgdW5kZXJ0YWtlbiBpbiBhIGNvbnNpc3RlbnQgbWFu bmVyIHdpdGhpbiBhbiBTRkMgZG9tYWluLiBUaGUKPj4+Pj4+Pj4gdGV4dCBzaG91bGQgYmUgdXBk YXRlZCB0byBtYWtlIGl0IGlzIGFib3V0IChjb25zaXN0ZW50KSBNVFUKPj4+PiBjb25maWd1cmF0 aW9uLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAqIEJUVywgc2hvdWxkbid0IHRoZSB0ZXh0IGJlIHJld29y ZGVkIHRvIHJlY29tbWVuZGVkIHRvIGluY3JlYXNlCj4+Pj4+Pj4+IHRoZSBNVFUgb2YgKiphbGwg bm9kZXMqKiBvZiBhbiBTRkMtZW5hYmxlZCBkb21haW4gYnkgYXQgbGVhc3QKPj4+Pj4+Pj4gdGhl IGxlbmd0aCBvZiBTRkMgaGVhZGVyICsgdHJhbnNwb3J0IGhlYWRlcj8KPj4+Pj4+Pj4KPj4+Pj4+ Pj4gKiBCdWxsZXQgMiwgaG93IFBNVFUgZGlzY292ZXJ5IGlzIGFjdHVhbGx5IHVzZWQgaW4gdGhp cyBjb250ZXh0Pwo+Pj4+Pj4+PiBEbyB5b3UgYXNzdW1lIHRoYXQgYWxsIFNGQy1hd2FyZSBub2Rl cyB3aWxsIGlzc3VlIHN1Y2ggbWVzc2FnZXMKPj4+Pj4+Pj4gdG93YXJkcyBvdGhlciBTRkMtYXdh cmUgbm9kZSwgYXJiaXRyYXJ5IGRlc3RpbmF0aW9uLCBlbHNlPwo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAq IEJ1bGxldCAyLCBJIHdvdWxkIGRyb3AgImRlc2NyaWJlcyBhIHRlY2huaXF1ZSBmb3IgZHluYW1p Y2FsbHkKPj4+Pj4+Pj4gZGlzY292ZXJpbmcgdGhlIG1heGltdW0gdHJhbnNtaXNzaW9uIHVuaXQg KE1UVSkgb2YgYW4gYXJiaXRyYXJ5Cj4+Pj4+Pj4+IGludGVybmV0IHBhdGgiLgo+Pj4+Pj4+Pgo+ Pj4+Pj4+PiAqIEJ1bGxldCAyLCBzLyB0aGUgdGhlL3RoZS4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gKiBU aGUgcmVmZXJlbmNlIHRvIHRoZSBMSVNQIHNwZWNpZmljYXRpb24gcmFpc2VzIHR3byBjb25jZXJu cwo+Pj4+Pj4+PiBhbmQgb25lCj4+Pj4+Pj4+IGNvbW1lbnQ6Cj4+Pj4+Pj4+Cj4+Pj4+Pj4+ICgx KSBJIGRvbid0IHRoaW5rIGl0IGlzIGEgZ29vZCBhcHByb2FjaCB0aGF0IGZyYWdtZW50cyBpbmR1 Y2VkCj4+Pj4+Pj4+IGJ5IHRoZSBuZXR3b3JrIGFyZSBwYXNzZWQgdG8gdGhlaXIgdWx0aW1hdGUg ZGVzdGluYXRpb25zIGFzIHN1Y2gKPj4+PiAoc3RhdGVsZXNzKS4KPj4+Pj4+Pj4gSU1PLCByZWFz c2VtYmx5IHNob3VsZCBiZSBkb25lIHdpdGhpbiB0aGUgU0ZDIGRvbWFpbgo+Pj4+Pj4+PiAocmVz cG9uc2libGUgZm9yCj4+Pj4+Pj4+IGZyYWdtZW50YXRpb24pIG5vdCBwYXNzZWQgYXdheS4KPj4+ Pj4+Pj4gKDIpIERvZXMgdGhlIHN0YXRlZnVsIG1vZGUgcmVxdWlyZSBhbGwgU0ZDIGRhdGEgcGxh bmUgZWxlbWVudHMKPj4+Pj4+Pj4gbWFpbnRhaW4gYSBmdWxsIGxpc3Qgb2YgTVRVIGZvciB0aGUg YW55IFNGRi9TRiBpbnN0YW5jZSBvZiB0aGUKPj4+Pj4+Pj4gU0ZDCj4+Pj4+Pj4gZG9tYWluPwo+ Pj4+Pj4+Pgo+Pj4+Pj4+PiBUaGUgY3VycmVudCB0ZXh0IHN1Z2dlc3RzIHRoYXQgW1JGQzY4MzBd IHNob3VsZCBiZSBsaXN0ZWQgYXMKPj4+Pj4+Pj4gbm9ybWF0aXZlIHJlZmVyZW5jZSAobm90IGFu IGluZm9ybWF0aXZlIG9uZSkuIEkgd291bGQgcGVyc29uYWxseQo+Pj4+Pj4+PiBmYXZvciByZW1v dmluZyB0aGUgcmVmZXJlbmNlIHRvIExJU1AgKGFzIGl0IGlzIGFuIEV4cGVyaW1lbnRhbCBSRkMp Lgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiAqIFRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIHRoZSBkcmFmdCBt YXkgYmUgYXVnbWVudGVkIHdpdGgKPj4+Pj4+Pj4gaW5mb3JtYXRpb25hbCBmcmFnbWVudGF0aW9u LXJlbGF0ZWQgcG9pbnRlcnMgdG86IGUuZy4sIFJGQzE4NTgKPj4+Pj4+Pj4gKFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIGZvciBJUCBGcmFnbWVudCBGaWx0ZXJpbmcpLCBSRkMzMTI4Cj4+Pj4+Pj4+ IChQcm90ZWN0aW9uIEFnYWluc3QgYSBWYXJpYW50IG9mIHRoZSBUaW55IEZyYWdtZW50IEF0dGFj ayksIGFuZAo+Pj4+Pj4+PiBSRkMKPj4+Pj4+Pj4gNDk2MyAoSVB2NCBSZWFzc2VtYmx5IEVycm9y cyBhdCBIaWdoIERhdGEgUmF0ZXMpLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBDaGVlcnMsCj4+Pj4+Pj4+ IE1lZAo+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tCj4+Pj4+ Pj4+PiBEZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl Cj4+Pj4+Pj4+PiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIEVudm95w6kgOiBsdW5kaSAx MSBhdnJpbCAyMDE2IDEzOjE0IMOAIDoKPj4+Pj4+Pj4+IFRob21hcyBOYXJ0ZW47IHNmY0BpZXRm Lm9yZyBPYmpldCA6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yCj4+Pj4+Pj4+PiBkcmFmdC1p ZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gRGVhciBUaG9tYXMsIGFsbCwK Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+PiBBcyBJIG1lbnRpb25lZCBkdXJpbmcgdGhlIG1lZXRpbmcsIHRo ZXJlIGFyZSBzZXZlcmFsIGlzc3Vlcwo+Pj4+Pj4+Pj4gdGhhdCBhcmUgbm90IGNvdmVyZWQgaW4g dGhlIGxhc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEkKPj4+Pj4+Pj4+IGFscmVhZHkgcHJvdmlk ZWQgZXhhbXBsZXMgb2YgdGhlIGlzc3VlcyBvZmZsaW5lIGFzIHJlcXVlc3RlZCBieSBNYXJ0aW4u Cj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4gQ2hlZXJzLAo+Pj4+Pj4+Pj4gTWVkCj4+Pj4+Pj4+Pgo+Pj4+ Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQo+Pj4+Pj4+Pj4+IERlIDogc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgVGhvbWFzCj4+Pj4+Pj4+ Pj4gTmFydGVuIEVudm95w6kgOiBqZXVkaSAzMSBtYXJzIDIwMTYgMDQ6NDggw4AgOiBzZmNAaWV0 Zi5vcmcKPj4+Pj4+Pj4+PiBPYmpldAo+Pj4+Pj4+Pj4+IDogW3NmY10gV0cgbGFzdCBjYWxsIGZv ciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBEZWFyIFdH Ogo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gVGhpcyBub3RlIGJlZ2lucyBhIFdHIGxhc3QgY2FsbCBv biBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0Cj4+Pj4+Pj4+Pj4gKGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC8pLgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+ Pj4gVGhlIGVkaXRvcnMgb2YgdGhlIE5TSCBkb2N1bWVudCBoYXZlIGluZGljYXRlZCB0aGF0IHRo ZXkgaGF2ZQo+Pj4+Pj4+Pj4+IGFkZHJlc3NlZCBhbGwga25vd24gY29tbWVudHMgYW5kIHRoYXQg dGhlcmUgYXJlIG5vIG9wZW4gaXNzdWVzCj4+Pj4+Pj4+Pj4gd2l0aCB0aGUgY3VycmVudCB2ZXJz aW9uIG9mIHRoZSBkb2N1bWVudC4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+Pj4+IFN1YnN0YW50aXZlIGNv bW1lbnRzIHRvIHRoZSBsaXN0IHBsZWFzZSwgZWRpdG9yaWFsIGNvbW1lbnRzCj4+Pj4+Pj4+Pj4g Y2FuIGdvIGRpcmVjdGx5IHRvIHRoZSBkb2N1bWVudCBlZGl0b3JzLgo+Pj4+Pj4+Pj4+Cj4+Pj4+ Pj4+Pj4gV2UnbGwgYWxzbyBnZXQgYSBicmllZiB1cGRhdGUgZnJvbSB0aGUgZWRpdG9ycyBhdCBu ZXh0IHdlZWsncwo+Pj4+Pj4+Pj4+IG1lZXRpbmcuIElmIHRoZXJlIGFyZSBhbnkgcmVtYWluaW5n IGlzc3VlcyB3aXRoIHRoZSBkb2N1bWVudCwKPj4+Pj4+Pj4+PiByYWlzaW5nIHRoZW0gYmVmb3Jl IHRoZSBtZWV0aW5nIHdvdWxkIGJlIGVzcGVjaWFsbHkgaGVscGZ1bC4KPj4+Pj4+Pj4+Pgo+Pj4+ Pj4+Pj4+IEZvciB0aGUgY2hhaXJzLAo+Pj4+Pj4+Pj4+IFRob21hcwo+Pj4+Pj4+Pj4+Cj4+Pj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+ Pj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+Pj4gc2ZjQGlldGYub3JnCj4+Pj4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPj4+Pj4+Pj4+Cj4+ Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ Pj4+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdAo+Pj4+Pj4+Pj4gc2ZjQGlldGYub3JnCj4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYwo+Pj4+Pj4+Pgo+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+ Pj4+PiBzZmMgbWFpbGluZyBsaXN0Cj4+Pj4+Pj4+IHNmY0BpZXRmLm9yZwo+Pj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYwo+Pj4+Pj4+Cj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4+PiBzZmMg bWFpbGluZyBsaXN0Cj4+Pj4+Pj4gc2ZjQGlldGYub3JnCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPj4+Pj4+Cj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdAo+ Pj4+Pj4gc2ZjQGlldGYub3JnCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYwo+Pj4+Pj4KPj4+Pgo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdAo+Pj4+IHNmY0BpZXRmLm9y Zwo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4+Pgo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+IHNmYyBt YWlsaW5nIGxpc3QKPj4+IHNmY0BpZXRmLm9yZwo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMKPj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4+IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4+CgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpzZmMgbWFpbGluZyBsaXN0CnNm Y0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYwoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc2ZjIG1haWxpbmcg bGlzdApzZmNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMK ----_com.samsung.android.email_3503018393531020 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkRvaW5nIHBhdGggTVRVIGRp c2NvdmVyeSBpbnN0ZWFkIG9mIGZyYWdtZW50YXRpb24gaXMgYSB2ZXJ5IHJlYXNvbmFibGUgc3Ry YXRlZ3ksIHBhcnRpY3VsYXJseSBpbiBzdXBwb3J0aW5nIElQdjYuPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5UaGUgcG9pbnQgaXMgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgcmVhc29uYWJsZSBy ZXNwb25zZXMsIGRlcGVuZGluZyB1cG9uIHRoZSB0cmFuc3BvcnQgYW5kIG90aGVyIGZhY3RvcnMu ICZuYnNwO0l0IGlzIG5vdCBmb3IgTlNIIHRvIG1hbmRhdGUgb25lLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+WW91cnMsPC9kaXY+PGRpdj5Kb2VsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2 IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5n IEdhbGF4eSBTwq4gNiwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVz c2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2 PkZyb206IERhdmUgRG9sc29uICZsdDtkZG9sc29uQHNhbmR2aW5lLmNvbSZndDsgPC9kaXY+PGRp dj5EYXRlOiA0LzI2LzIwMTYgIDM6NTUgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86ICJK b2VsIE0uIEhhbHBlcm4iICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0OywgUm9uIFBhcmtlciAm bHQ7Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSZndDssIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20sICJFbHp1ciwgVXJpIiAmbHQ7dXJpLmVsenVyQGludGVsLmNvbSZndDssIHNm Y0BpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9y IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+RnJh Z21lbnQgcmVhc3NlbWJseSBpcyBhIGNvbXB1dGF0aW9uYWxseSBleHBlbnNpdmUgcHJvY2Vzczxi cj5hbmQgdHVubmVsIGZyYWdtZW50YXRpb24gY2FuIHN1YnN0YW50aWFsbHkgaW5mbGF0ZSB0aGUg bnVtYmVyIG9mIDxicj5wYWNrZXRzLCBzbyBJIHByZWZlciBmcmFnbWVudGluZyB0aGUgaW5uZXIg cGFja2V0Ljxicj5UaGlzIGFsbG93cyBTRkZzIGFuZCBTRnMgdG8gZm9yd2FyZCBOU0ggcGFja2V0 cyB3aXRob3V0IGZpcnN0IHJlYXNzZW1ibGluZzxicj50aGVtLjxicj48YnI+SWYgdGhlIGlubmVy IHBhY2tldCBpcyBJUHY2IG9yIElQdjQgd2l0aCBERj0xLCBQYXRoLU1UVSBkaXNjb3Zlcnk8YnI+ Y2FuIGJlIGZhY2lsaXRhdGVkIGJ5IHNlbmRpbmcgYW4gSUNNUCAiUGFja2V0IHRvbyBiaWciIG1l c3NhZ2UgdG8gPGJyPnRoZSBzZW5kZXIuIChSRkMgMTE5MSwgUkZDIDE5ODEpPGJyPjxicj5UaGVy ZSBpcyBhbiBhZGRpdGlvbmFsIGJlbmVmaXQgdGhhdCBpbm5lciBmcmFnbWVudGF0aW9uL1BNVFUg ZGlzY292ZXJ5PGJyPmFsbG93IHNlcnZpY2UgY2hhaW5pbmcgdG8gd29yayBldmVuIGlmIHRoZSB0 cmFuc3BvcnQgbGF5ZXIgZG9lcyBub3QgPGJyPmZhY2lsaXRhdGUgZnJhZ21lbnRhdGlvbiAoZS5n Liwgd2hlbiBOU0ggaXMgdHJhbnNwb3J0ZWQgZGlyZWN0bHkgb3ZlciA8YnI+RXRoZXJuZXQpLjxi cj48YnI+VGhlIGZyYWdtZW50YXRpb24gYW5kIFBhdGggTVRVIGRpc2NvdmVyeSBhcmUgc3RhbmRh cmQgbWVjaGFuaXNtcyw8YnI+YW5kIHBlcm1pdHRlZCB0byBiZSB1c2VkIGZvciBhbnkgbGluaywg c28gbm90aGluZyBuZWVkcyB0byBiZTxicj5zYWlkIGluIHRoZSBOU0ggZHJhZnQgdG8gcGVybWl0 IHRoaXMuIEhvd2V2ZXIsIEkgdGhpbmsgaXQgd291bGQ8YnI+YmUgdXNlZnVsIHRvIHJlY29tbWVu ZCB0aGVzZSBhcHByb2FjaGVzLjxicj48YnI+LURhdmU8YnI+PGJyPjxicj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybjxicj5TZW50OiBUdWVzZGF5LCBBcHJpbCAyNiwg MjAxNiAzOjEyIFBNPGJyPlRvOiBSb24gUGFya2VyOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tOyBFbHp1ciwgVXJpOyBzZmNAaWV0Zi5vcmc8YnI+U3ViamVjdDogUmU6IFtzZmNdIFdHIGxh c3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj48YnI+SW4gbW9zdCB0dW5u ZWwgYW5seXNpcywgYSB0dW5uZWwgZW50cnkgcG9pbnQgKGluIHRoaXMgY2FzZSwgdGhlIDxicj50 cmFuc3BvcnQgaW50ZXJmYWNlIGZyb20gdGhlIFNGQyBjb21wb25lbnQpIGNhbiBlaXRoZXIgZnJh Z21lbnQgb3V0ZXIgPGJyPm9yLCBpZiBhdmFpbGFibGUgZnJhZ21lbnQgaW5uZXIuJm5ic3A7IFRo aXMgaXMgZGVmaW5lZCBieSB0aGUgdHJhbnNwb3J0IDxicj50ZWNobm9sb2d5LCBub3QgdGhlIHVz ZXIuPGJyPjxicj5JbiB0aGUgY2FzZSBvZiBTRkMgTlNILCBJIHdvdWxkIHVzdWFsbHkgZXhwZWN0 IG91dGVyIGZyYWdtZW50YXRpb24sIDxicj53aGljaCBpcyBhIHB1cmUgdHJhbnNwb3J0IGlzc3Vl LiZuYnNwOyBJZiB0aGUgaW5uZXJtb3N0IHBhY2tldCBpcyBJUCwgYW5kIHRoZSA8YnI+dHVubmVs IGVudHJ5IHdhbnRzIHRvIGJlIGNvbXBsaWNhdGVkLCBpdCBpcyBwZXJtaXR0ZWQgdG8gZnJhZ21l bnQgdGhlIDxicj5pbm5lciBwYWNrZXQgYW5kIHByb2R1Y2UgdGhlIHByb3BlciBOU0ggaGVhZGVy cyBmb3IgdGhlIGZyYWdtZW50cy4gPGJyPkluaGVyZW50bHksIGFuIGltcGxlbWVudGF0aW9uIGNh biBvbmx5IGNob29zZSB0byBkbyB0aGlzIGlmIGl0IGNhbiA8YnI+Y29uc3RydWN0IHRoZSByaWdo dCBtZXRkYXRhIHRvIHB1dCBvbiBlYWNoIGZyYWdtZW50LiZuYnNwOyBJIGRvbid0IGFjdHVhbGx5 IDxicj5rbm93IGhvdyB0byByZWxpYWJseSBkbyB0aGF0LCBzbyBJIGRvbid0IHJlY29tbWVuZCBp dC48YnI+PGJyPkluIGVpdGhlciBjYXNlLCB0aGUgTlNIIGRvY3VtZW50IGNhbid0IHRlbGwgdGhl IGltcGxlbWVudGF0aW9uIHdoYXQgdG8gPGJyPmRvIG9yIGhvdyB0byBkbyBpdC48YnI+PGJyPllv dXJzLDxicj5Kb2VsPGJyPjxicj5PbiA0LzI2LzE2IDI6MzggUE0sIFJvbiBQYXJrZXIgd3JvdGU6 PGJyPiZndDsgSm9lbCw8YnI+Jmd0Ozxicj4mZ3Q7IEkgY2FuJ3Qgc2F5IHRoYXQgSSBkaXNhZ3Jl ZSB3aXRoIHlvdXIgYW5hbHlzaXMgb24gdGhlIHNjb3BlLiZuYnNwOyZuYnNwOyBJIHRoaW5rIHRo ZSBxdWVzdGlvbiByYWlzZWQgYnkgc29tZSBvbiB0aGUgdGhyZWFkIGlzIGlmIGFuIFNGQy1ub2Rl IChpLmUuLCBjbGFzc2lmaWVyLCBTRiwgU0ZGKSBjcmVhdGVzIGZyYWdtZW50cywgaXMgdGhlIE5T SCBoZWFkZXIgcmVwZWF0ZWQgaW4gZWFjaCBmcmFnbWVudCA/Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkg dGhpbmsgdGhlIGFuc3dlciBpcyAibm8iLiZuYnNwOyZuYnNwOyBJZiBzbywgaXMgaXQgd29ydGgg c3RhdGluZyB0aGlzIGV4cGxpY2l0bHkgaW4gdGhlIGRvY3VtZW50LCBvciBpcyBpdCBqdXN0IG9i dmlvdXMgdGhhdCBwcm9wZXJseSBsYXllcmVkIHN5c3RlbXMgd291bGQgYmVoYXZlIHRoYXQgd2F5 Ljxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPGJyPiZndDs8YnI+Jmd0Ozxi cj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTogSm9lbCBNLiBI YWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV08YnI+Jmd0OyBTZW50OiBUdWVzZGF5 LCBBcHJpbCAyNiwgMjAxNiAxOjIyIFBNPGJyPiZndDsgVG86IFJvbiBQYXJrZXIgJmx0O1Jvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20mZ3Q7OyBKb2VsIE0uIEhhbHBlcm4gJmx0O2ptaEBq b2VsaGFscGVybi5jb20mZ3Q7OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBFbHp1ciwg VXJpICZsdDt1cmkuZWx6dXJAaW50ZWwuY29tJmd0Ozsgc2ZjQGlldGYub3JnPGJyPiZndDsgU3Vi amVjdDogUmU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4 dDxicj4mZ3Q7PGJyPiZndDsgQXQgbGVhc3Qgc28gZmFyLCB3ZSBoYXZlIHRyZWF0ZWQgdGhlIGNv bW11bmljYXRpb24gYmV0d2VlbiBjbGFzc2lmaWVyIGFuZCBTRkYgKGluZ3Jlc3Mgb3IgaW50ZXJt ZWRpYXRlKSBhcyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBvdXIgd29yay48YnI+Jmd0OyBGb3Ig U0YgJmx0Oy0mZ3Q7IFNGRiBjb21tdW5pY2F0aW9uIHdlIGhhdmUgbnRvZWQgdGhlIG5lZWQgZm9y IGEgcHJveHkgdG8gaGFuZGxlIHRoZSBjYXNlIHdoZW4gdGhlIFNGIGNhbiBub3QgYWNjZXB0IGFu ZCByZXR1cm4gdGhlIE5TSCBoZWFkZXIsIHNpbmNlIHdlIGFzc3VtZSB0aGF0IGlzIHByZXNlcnZl ZC4mbmJzcDsgT3RoZXIgdGhhbiB0aGF0IHByZXNlcnZhdGlvbiwgc2ltaWxhciB0byB0aGUgYWJv dmUsIHdlIGhhdmUgdHJlYXRlZCB0aGUgZGV0YWlscyBhcyBvdXRzaWRlIG9mIG91ciBzY29wZS4g VGhhdCBpcyBiZWNhdXNlIHRoZXkgZGVwZW5kIHNvIGhlYXZpbHkgb24gdGhlIGltcGxlbWVudGF0 aW9uIHRlY2huaXF1ZSB1c2VkLiZuYnNwOyAoSHlwZXJ2aXNvciAsXyZndDsgYXBwbGljYXRpb24g Y29tbXVuaWNhdGlvbiB2cyBjb21tdW5pY2F0aW9uIGluc2lkZSBhIHVzZXIgc3BhY2Ugb3IgY29t bXVuaWNhdGlvbiBvdmVyIGFuIGFjdHVhbCBFdGhlcm5ldCBhcmUgYWxsIHZlcnkgZGlmZmVyZW50 Lik8YnI+Jmd0Ozxicj4mZ3Q7IFRyeWluZyB0byBleHRlbmQgdGhlIE5TSCBkb2N1bWVudCB0byBh ZGRyZXNzIHRoZXNlIHdvdWxkIGJlIGEgbWFqb3IgY2hhbmdlLCBhbmQgd291bGQgc3RlcCBpbnRv IHRoZSBpc3N1ZXMgcmVsYXRlZCB0byB0cmFuc3BvcnQgc2VsZWN0aW9uLCB3aGljaCBhcmUgZXhw bGljaXRseSBvdXQgb2Ygc2NvcGUuPGJyPiZndDs8YnI+Jmd0OyBZb3Vycyw8YnI+Jmd0OyBKb2Vs PGJyPiZndDs8YnI+Jmd0OyBPbiA0LzI2LzE2IDExOjU4IEFNLCBSb24gUGFya2VyIHdyb3RlOjxi cj4mZ3Q7Jmd0OyBMaW5kYSw8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgSSBsaWtlIHRoZSBmaXJz dCBjbGF1c2UgKHRyYW5zcG9ydCB0dW5uZWwgYmFzZWQgZnJhZ21lbnRhdGlvbikuPGJyPiZndDsm Z3Q7PGJyPiZndDsmZ3Q7IFJlZ2FyZGluZyB0aGUgc2Vjb25kIChzb3VyY2UgYmFzZWQpLCBJIHRo aW5rIHRoZXJlIGFyZSBtb3JlIHN1YmNhc2VzIHRvIGNvbnNpZGVyOjxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyAxLiZuYnNwOyBQcm9wYWdhdGlvbiBvZiBOU0ggZW5jYXBzdWxhdGVkIHBhY2tldCBm cm9tIGNsYXNzaWZpZXIgdG8gU0ZGIDIuPGJyPiZndDsmZ3Q7IFByb3BhZ2F0aW9uIG9mIE5TSCBl bmNhcHN1bGF0ZWQgcGFja2V0IGZyb20gU0ZGIHRvIFNGIDMuJm5ic3A7IFByb3BhZ2F0aW9uPGJy PiZndDsmZ3Q7IG9mIE5TSCBlbmNhcHN1bGF0ZWQgcGFja2V0IGZyb20gU0YgdG8gU0ZGIChpbmNs dWRpbmcgcG9zc2liaWxpdHkgdGhhdDxicj4mZ3Q7Jmd0OyBOU0ggc2l6ZSBpbmNyZWFzZWQgYXQg U0YpIDQuJm5ic3A7IFByb3BhZ2F0aW9uIG9mIE5TSCBlbmNhcHN1bGF0ZWQgcGFja2V0PGJyPiZn dDsmZ3Q7IGZyb20gU0ZGIHRvIFNGRjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJbiBlYWNoIG9m IHRoZSA0IGNhc2VzIGFib3ZlLCZuYnNwOyB0aGVyZSBpcyB0aGUgcG9zc2liaWxpdHkgdGhhdCBN VFUgd2lsbCBiZSBleGNlZWRlZCBhbmQgdGhlcmVmb3JlIHRoZXJlIGFyZSBwcm9jZWR1cmVzIHRv IGJlIGRlZmluZWQgaW4gdGhhdCBldmVudHVhbGl0eS48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsg VGhhbmtzLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS b248YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+Jmd0OyZndDsgRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMaW5kYSBEdW5iYXI8YnI+Jmd0OyZndDsgU2VudDogVHVlc2RheSwg QXByaWwgMjYsIDIwMTYgMTE6NDggQU08YnI+Jmd0OyZndDsgVG86IEpvZWwgTS4gSGFscGVybiAm bHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7PGJyPiZndDsmZ3Q7IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb207IEVsenVyLCBVcmkgJmx0O3VyaS5lbHp1ckBpbnRlbC5jb20mZ3Q7Ozxicj4m Z3Q7Jmd0OyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIFdHIGxh c3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyBKb2VsLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIHRoaW5rIHRoZSBkb2N1bWVudCBz aG91bGQgYWRkIHRoZSBkZXNjcmlwdGlvbiBvbiB0aGUgZm9sbG93aW5nIHR3byBmcmFnbWVudGF0 aW9uIHNjZW5hcmlvczo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgLSBUcmFuc3BvcnQgdHVubmVs IGdlbmVyYXRlZCBmcmFnbWVudGF0aW9uOjxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBXaGVuIGEg cGFja2V0IGZyYWdtZW50YXRpb24gaXMgY2F1c2VkIGJ5IHRyYW5zcG9ydCB0dW5uZWwgKGkuZS4g dmFyaW91cyBlbmNhcHN1bGF0aW9ucyksIHRoZSB0ZXJtaW5hdGlvbiBwb2ludCBvZiB0aGUgdHJh bnNwb3J0IHR1bm5lbCBpcyByZXNwb25zaWJsZSBmb3IgcmUtYXNzZW1ibGluZyB0aGUgZnJhZ21l bnRlZCBwaWVjZXMgb2YgdGhlIHBhY2tldC4gU2luY2UgdGhlcmUgd29uJ3QgYmUgYW55IFNGRiBu b2RlcyBpbiBiZXR3ZWVuIHRoZSBUcmFuc3BvcnQgVHVubmVsLCB0aGUgdHVubmVsIGdlbmVyYXRl ZCBmcmFnbWVudGF0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IGFjdGlvbnMgYnkgU0ZGIG5vZGVz IG9yIFNGIG5vZGVzLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAtIFNvdXJj ZSBub2RlIGdlbmVyYXRlZCBmcmFnbWVudGF0aW9uIChhZnRlciBhZGRpbmcgb24gdGhlIE5TSCBo ZWFkZXIpOjxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBXaGVuIGZyYWdtZW50YXRpb24g aGFzIHRvIGJlIHBlcmZvcm1lZCBmb3IgYSBwYWNrZXQgYmVpbmcgZW5jYXBzdWxhdGVkIHdpdGgg dGhlIE5TSCBoZWFkZXIsIGVpdGhlciB0aGUgaW50ZXJtZWRpYXRlIFNGRiBub2RlcyBvciB0aGUg U0Ygbm9kZXMgaGF2ZSB0byBiZSBhYmxlIHRvIHJlYXNzZW1ibGUgdGhlIGZyYWdtZW50ZWQgcGll Y2VzLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBDaGVl cnMsPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IExpbmRhPGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPiZndDsmZ3Q7IEZyb206 IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dPGJyPiZndDsmZ3Q7 IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI2LCAyMDE2IDEwOjMzIEFNPGJyPiZndDsmZ3Q7IFRvOiBM aW5kYSBEdW5iYXI7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IEVsenVyLCBVcmk7PGJy PiZndDsmZ3Q7IHNmY0BpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gV0cg bGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7PGJyPiZn dDsmZ3Q7IFJlLXJlYWRpbmcgeW91ciBub3RlLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHlvdSBhcmUg cmVmZXJyaW5nIG9ubHkgdG8gdGhlIGNhc2Ugb2YgdHJhbnNwb3J0IGdlbmVyYXRlZCBmcmFnbWVu dGF0aW9uIG9mIHRoZSBvdXRlciBwYWNrZXQuJm5ic3A7IEkgaGFkIGFzc3VtZWQgeW91IHdlcmUg bm90IHRhbGtpbmcgYWJvdXQgdGhhdCwgc2luY2UgdGhlIHJlc3VsdGluZyBmcmFnbWVudHMgd2ls bCBub3QgYWxsIGhhdmUgTlNIIGhlYWRlcnMuJm5ic3A7IEFzIHdpdGggYW55IHR1bm5lbCB0ZWNo bm9sb2d5LCBpZiB0aGUgdHVubmVsIGNob29zZXMgdG8gZnJhZ21lbnQgYXQgaXRzIGxheWVyLCB0 aGVuIHRoZSB0dW5uZWwgaXMgcmVzcG9uc2libGUgZm9yIHJlYXNzZW1ibHkuJm5ic3A7IFRoYXQg d291bGQgYmUgaW52aXNpYmxlIHRvIHRoZSBTRkYuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFlv dXJzLDxicj4mZ3Q7Jmd0OyBKb2VsPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IE9uIDQvMjYvMTYg MTE6MTAgQU0sIExpbmRhIER1bmJhciB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7IEFncmVlIHdpdGgg TWVkLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEV2ZW4gaWYgZWFjaCBmcmFnbWVu dCBwaWVjZSBvZiBhIHBhY2tldCB3aXRoIE5TSCBoZWFkZXIgY2FycmllcyB0aGUgTlNIIGhlYWRl ciwgdGhlIGludGVybWVkaWF0ZSBTRkYgbm9kZXMgc3RpbGwgbmVlZCB0byBwdXQgdG9nZXRoZXIg YWxsIHRoZSBmcmFnbWVudHMgdG9nZXRoZXIgYmVmb3JlIHBhc3NpbmcgdGhlIHdob2xlIGRhdGEg ZnJhbWUgdG8gdGhlIFNGLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IExpbmRhPGJy PiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+Jmd0OyZndDsmZ3Q7IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Y8YnI+Jmd0OyZndDsmZ3Q7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 YnI+Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgQXByaWwgMjUsIDIwMTYgOTo0MiBBTTxicj4m Z3Q7Jmd0OyZndDsgVG86IEVsenVyLCBVcmk7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3Jn PGJyPiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFm dC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgUmUt LDxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEhvdyBkbyB5b3UgaW5zdHJ1Y3QgdGhl IHRyYW5zcG9ydCBsYXllciB0byBBTFdBWVMgcHJlcGVuZCBhbiBOU0ggaGVhZGVyIGV2ZW4gZm9y IGZyYWdtZW50cz8gT3IgeW91IGRvbid0IGNhcmUgYWJvdXQgdGhhdD88YnI+Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyBUaGFuayB5b3UuPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsgQ2hlZXJzLDxicj4mZ3Q7Jmd0OyZndDsgTWVkPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 IERlIDogRWx6dXIsIFVyaSBbbWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5jb21dIEVudm95w6kgOiBs dW5kaSAyNSBhdnJpbDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IDIwMTYgMTY6MjYgw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBJTVQvT0xOOyBKb2VsIE0uIEhhbHBlcm47PGJyPiZndDsmZ3Q7Jmd0OyZndDsg c2ZjQGlldGYub3JnIE9iamV0IDogUkU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBNZWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7IE5vdCB0byByZXBlYXQgbXkgcG9zaXRpb24sIGJ1dCBJJ2xsIGRvIGl0IGFueWhv dyA6LSkgQXMgTlNIIGlzICpOT1QqPGJyPiZndDsmZ3Q7Jmd0OyZndDsgYSB0cmFuc3BvcnQsIGRl YWxpbmcgd2l0aCBmcmFnbWVudGF0aW9uIGlzIGxlZnQgdG8gdGhlIFRyYW5zcG9ydCB1c2VkLjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgVGhlIG1vZGVsIEkgdXNlIGZv ciBOU0gsIGlzIGJhc2ljYWxseSBzaW1pbGFyIHRvIFZYTEFOIC4gSXQgaXMgYW4gb3Zlcmx5Ljxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgVGh4PGJyPiZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBVcmkgKCJPby1SZWUiKTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7IEM6IDk0OS0zNzgtNzU2ODxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2Y8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PGJyPiZndDsmZ3Q7Jmd0OyZndDsgU2VudDogTW9uZGF5LCBBcHJpbCAyNSwgMjAxNiA3OjE4IEFN PGJyPiZndDsmZ3Q7Jmd0OyZndDsgVG86IEpvZWwgTS4gSGFscGVybiAmbHQ7am1oQGpvZWxoYWxw ZXJuLmNvbSZndDs7IHNmY0BpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJl OiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEhpIEpvZWwsPGJyPiZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2Ugc2VlIGlubGluZS48YnI+Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBN ZWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRGUgOiBKb2VsIE0uIEhh bHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSBFbnZvecOpIDogbHVuZGkgMjU8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXZyaWwgMjAxNiAxNTo0OCDDgCA6IEJPVUNBREFJUiBNb2hh bWVkIElNVC9PTE47IHNmY0BpZXRmLm9yZyBPYmpldCA6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgSSBhbSB1bmRl cnN0YW5kaW5nIHlvdSBjb3JyZWN0bHkgTWVkLCB5b3UgYXJlIGFza2luZyB0aGF0IHRoZTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBOU0ggZHJhZnQgc3BlY2lmeSBob3cgc2VydmljZSBjaGFpbmlu ZyBzaG91bGQgY29wZSB3aXRoIHBhY2tldHM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBo YXZlIGJlZW4gZnJhZ21lbnRlZD88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFtNZWRdIFRvIGJlIGFjY3VyYXRlLCBJJ20gYXNr aW5nIHRvIGFzc2VzcyB3aGV0aGVyIHRoZXJlIGFyZSBpbXBsaWNhdGlvbnMuPGJyPiZndDsmZ3Q7 Jmd0OyZndDsgSWYgdGhlcmUgYXJlLCB0aGVuIHRoZSBkcmFmdCBzaG91bGQgYmUgdXBkYXRlZCBh Y2NvcmRpbmdseS48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBO U0gsIGFuZCB0aGUgU0ZGIGZ1bmN0aW9uYWxpdHksIGRvZXMgbm90IGNhcmUuPGJyPiZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBbTWVkXSBJJ20gbm90IHRoYXQgc3VyZS4gU29t ZSB0eXBpY2FsIGltcGxpY2F0aW9ucyBhcmUgbGlzdGVkIGJlbG93Ojxicj4mZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgKiBTRkY6IElmIHRoZSBOU0ggaGVhZGVyIGlzIHByZXNl bnQgb25seSBpbiB0aGUgYSBmcmFnbWVudCBidXQgU0ZGPGJyPiZndDsmZ3Q7Jmd0OyZndDsgZGlk bid0IG1haW50YWluZWQgYSBzdGF0ZSwgc3Vic2VxdWVudCBmcmFnbWVudHMgd29uJ3QgYmUgYXBw cm9wcmlhdGVseSBwcm9jZXNzZWQuPGJyPiZndDsmZ3Q7Jmd0OyZndDsgKiBTRkMtYXdhcmUgZnVu Y3Rpb246IGlmIHByZXBlbmRpbmcgYSBjb250ZXh0IGluZm9ybWF0aW9uIGRlcGVuZHMgb248YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgZnVsbCBwYWNrZXQsIG5vdCBvbmx5IGEgZnJhZ21lbnQuPGJy PiZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBJdCBqdXN0 IGRvZXMgaXRzIGpvYi48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFtN ZWRdIHdoaWNoIG1heSBiZSBkaXN0dXJiZWQgaW4gc29tZSBzaXR1YXRpb25zIGFzIGxpc3RlZCBp biB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBleGFtcGxlcyBhYm92ZS48YnI+Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbmdyZXNzIGFuZCBpbnRlcm1lZGlhdGUgY2xh c3NpZmllcnMgbWF5IGNvcGUgd2l0aCBmcmFnbWVudHMgaW4gYW55PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IG51bWJlciBvZiB3YXlzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFNw ZWNpZnlpbmcgc3VjaCBpcyBjbGVhcmx5IG91dCBvZiBzY29wZSBmb3IgdGhpcyBkcmFmdC48YnI+ Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFtNZWRdIFRoZSBwdXJwb3NlIGlz IG5vdCB0byBzcGVjaWZ5IHRoZSBpbnRlcm5hbCBpbXBsZW1lbnRhdGlvbjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7IGRldGFpbHMgYnV0IHRoZSBleHRlcm5hbCBiZWhhdmlvciBvZiB0aGUgY2xhc3NpZmll ciBmdW5jdGlvbiB3aGVuIGl0PGJyPiZndDsmZ3Q7Jmd0OyZndDsgY29tZXMgdG8gaGFuZGxlIGZy YWdtZW50cy4gVGhhdCBiZWhhdmlvciBtYXkgaGF2ZSBhbiBpbmNpZGVuY2Ugb248YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyBTRkYsIGluIHBhcnRpY3VsYXIuIFRoZSBwdXJwb3NlIGlzIG5vdCB0byByZWNv bW1lbmQgdGhlIG1heGltdW08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyByZXNvdXJjZXMgdG8gYmUgZGVk aWNhdGVkIHRvIG91dCBvZiBvcmRlciBmcmFnbWVudHMgbm9yIHRoZSB0aW1lb3V0PGJyPiZndDsm Z3Q7Jmd0OyZndDsgdG8gY2FjaGUgdGhvc2U7IHRoZXNlIGNvbnNpZGVyYXRpb25zIGFyZSBvZiBj b3Vyc2Ugb3V0IG9mIHNjb3BlLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IE5ldmVydGhlbGVzcywgYW4g aW1wbGVtZW50YXRpb24gc2hvdWxkIG9mZmVyIGEgY29uZmlndXJhYmxlPGJyPiZndDsmZ3Q7Jmd0 OyZndDsgcGFyYW1ldGVyIHNvIHRoYXQgYW4gb3BlcmF0b3IgdHdlYWsgdGhvc2UgYWNjb3JkaW5n IHRvIGl0cyBjb250ZXh0Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7IEkgc3VwcG9zZSBvbmUgY291bGQgd3JpdGUgYW4gaW5mb3JtYXRpb25h bCBkcmFmdCBvbiBwb3NzaWJsZSB3YXlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIGNvcGlu Zy4mbmJzcDsgVGhlIElFVEYgaGFzIG5vdCB1c3VhbGx5IHB1Ymxpc2hlZCBzdWNoLjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBTZXJ2aWNlIGZ1bmN0aW9ucyBoYXZlIHRvIGNvcGUgd2l0aCBmcmFn bWVudGVkIHBhY2tldHMganVzdCBhcyB0aGV5PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhhZCB0 byBiZWZvcmUgdGhlIGFkdmVudCBvZiBOU0gsIHNvIGRlc2NyaWJpbmcgdGhhdCBpcyBjbGVhcmx5 IG5vdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWVkZWQgaGVyZS48YnI+Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IFtNZWRdIFRoZSBhZHZlbnQgb2YgTlNIIGhhcyB0aGUg Zm9sbG93aW5nIGltcGxpY2F0aW9uczo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyAqIGl0IGV4YWNlcmJh dGVzIGZyYWdtZW50YXRpb24uIEhhbmRpbmcgb3ZlciB0aGlzIGlzc3VlIHRvIHRoZTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydCBsYXllciBtYXkgbGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5 IGlzc3Vlcy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyAqIHRoZSBjaGFpbmluZyBtYXkgbm90IGJlIGVm ZmljaWVudCBpZiBmcmFnbWVudHMgYXJlIGluYXBwcm9wcmlhdGVseTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7IGhhbmRsZWQuPGJyPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBJbnRy b2R1Y2luZyBOU0ggc2hvdWxkIG5vdCBkZWdyYWRlIHRoZSBvdmVyYWxsIHNlcnZpY2UgY29tcGFy ZWQgdG88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBsZWdhY3kgc2VydmljZSBkZXBsb3ltZW50IHNjaGVt ZXMuPGJyPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgWW91cnMsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEpvZWw8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gNC8yNS8xNiAzOjAw IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgUmUtLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEkgaGVhciB5b3UsIGJ1dCBteSBjb21tZW50IGlzIHRoYXQgd2UgbmVl ZCwgYXMgYSBXRywgdG8gZGVjaWRlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGF0IHRv PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHB1dCBpbiB0aGUgZHJhZnQuIEZXSVcsIEknbSBkaXNj dXNzaW5nIHR3byBmcmFnbWVudGF0aW9uIGlzc3Vlczo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoMSkgRnJhZ21lbnRhdGlvbiB0aGF0IGlz IGNhdXNlZCBieSBwcmVwZW5kaW5nIGFuIFNGQyBoZWFkZXIuPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAoMikgSGFuZGxpbmcgZnJhZ21lbnRzIGF0IHRoZSBpbmdyZXNzIG9mIGFuIFNGQy1l bmFibGVkIGRvbWFpbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJbmNyZWFzaW5nIHRoZSBNVFUgaXMgZm9yIHN1cmUgYSByZWNvbW1lbmRh dGlvbiBpcyB0byBiZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhwbGljaXRseTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjYWxsZWQgb3V0IGluIHRoZSB0ZXh0IChzZWUgbXkgZmlyc3Qg bWVzc2FnZSkuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhlcmUgYXJlIG90aGVyIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgZGlzY3Vzc2Vk LCBlLmcuLCBob3cgdG88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRlYWwgd2l0aDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmcmFnbWVudHMgaW4gU0ZGcy9DbGFzc2lmaWVycz88YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBpcyBh bHNvICJwcnVkZW50IiB0byBjaGVjayB0aGF0IG5vIGlzc3VlcyB3aWxsIGJlIGV4cGVyaWVuY2Vk PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBTRkY8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdG8gaGFuZGxlIGZyYWdtZW50cy4gSWYgYW4gU0ZDIGhlYWRlciBpcyBwcmVwZW5kZWQgZm9y IGFsbDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmcmFnbWVudHMsIEknbSBub3Qgc3VyZSB0aGVy ZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYW55IHBhcnRpY3VsYXIgaXNzdWUgYXQg dGhlIFNGRiBsZXZlbCwgZXhjZXB0IGlmPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdHJp cHBpbmcvYWRkaW5nPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnRleHQgVExWcyBkZXBlbmRz IG9uIHRoZSBmdWxsIHBhY2tldCAobm90IGp1c3QgZnJhZ21lbnQpLiBJdCBpczxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB3YXJyYW50ZWQgdG8gY29uc2lkZXIgYSBsaXR0bGUgYml0IHRoaXMgcG9p bnQgYmVmb3JlIGRlY2xhcmluZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVyZSBpcyBubyBp c3N1ZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBGb3IgcG9pbnQgKDEpLCBkZWNsYXJpbmcgZnJhZ21lbnRhdGlvbiBvdXQgb2Ygc2NvcGUg d291bGQgYmUgbWVhbnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYW4gaW1wbGVtZW50YXRpb24gbXVzdCBiZSBwcmVwYXJlZCB0byByZWNl aXZlIGZyYWdtZW50cyB3aXRoIG9yPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdpdGhvdXQgTlNI IGhlYWRlciBhcyB0aGlzIGlzIGEgZGVjaXNpb24gdGhhdCBpcyBsZWZ0IHRvIHRoZTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbi4gVGhpcyBpcyBhIHJlcXVp cmVtZW50IHBlciBzZSE8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJIHdvbid0IHJlaXRlcmF0ZSBhbGwgdGhlIGNvbW1lbnRzIEkgaGF2ZSBh Ym91dCB0aGUgY3VycmVudDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29yZGluZyBvZjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIHNlY3Rpb24uPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgTWVkPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERlIDogRWx6dXIsIFVyaSBbbWFpbHRvOnVyaS5lbHp1 ckBpbnRlbC5jb21dIEVudm95w6kgOiBsdW5kaSAyNTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGF2cmlsIDIwMTYgMDg6MzAgw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBU aG9tYXMgTmFydGVuOzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNmY0BpZXRmLm9y ZyBPYmpldCA6IFJFOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgTWVkPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBNeSBwb2ludCBpcyB0aGF0IEZyYWdtZW50YXRpb24gaXMgeWV0IGFub3RoZXIgdHJhbnNwb3J0 IHJlbGF0ZWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpc3N1ZTxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGF0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgYmV5 b25kIHRoZSBzY29wZSBvZiBOU0ggYW5kIGJleW9uZCB0aGUgY2hhcnRlciBvZiB0aGUgV0csIHNv PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZG9lc24ndDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlYWxseSBiZWxvbmcg aW4gdGhlIGRyYWZ0LiBXZSBhcmUgcHJvdmlkaW5nIGFuIGFkdmljZSBhczxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4dGVuZGluZyB0aGUgc2l6ZSBvZiB0aGUgcGFja2V0IG1heSBs ZWFkIHRvIGZyYWdtZW50YXRpb24sIGJ1dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFzIHlvdSBjaGVjayBSRkMgNzM0OCBWeExBTiwgd2hpY2ggbXkgY3JlYXRlIHRoZSBzYW1lIGlz c3VlLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHlvdSdsbCBmaW5kIGl0IGRvZXNu J3QgZXZlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWxhdGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0byBpdC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoeDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVXJpICgiT28tUmVlIik8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDOiA5NDktMzc4LTc1Njg8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFNlbnQ6IFN1bmRheSwgQXByaWwgMjQsIDIwMTYgMTA6MzIgUE08YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUbzogRWx6dXIsIFVyaSAmbHQ7dXJpLmVsenVyQGludGVsLmNvbSZn dDs7IFRob21hcyBOYXJ0ZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O25hcnRlbkB1cy5p Ym0uY29tJmd0Ozs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmNAaWV0Zi5vcmc8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gV0cgbGFz dCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBVcmksPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBUaGF0J3MgYW5vdGhlciBvcHRpb24gdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQvaW52ZXN0 aWdhdGVkLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEknbTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhZnJhaWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIGlz IG5vdCB0aGUgcmF0aW9uYWxlIGFkb3B0ZWQgaW4gLTA0IHNpbmNlIGl0IGluY2x1ZGVzIHNvbWU8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0ZXh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRoYXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBmYXIgdG8gYmUgc3Vm ZmljaWVudCB0byBlbnN1cmUgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBC VFcsIHNheWluZyB0aGF0IG5zaCBkb2VzIG5vdCBuZWVkIHRvIGRlYWwgd2l0aCBmcmFnbWVudGF0 aW9uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVjYXVzZTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBpdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHRyYW5zcG9y dC1pbmRlcGVuZGVudCBpcyBub3QgSU1ITyBhIGdvb2Qgc3RyYXRlZ3kgdG8gYWRvcHQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBoZXJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJl Y2F1c2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpdCBvcGVucyB0aGUgZG9vciBm b3IgaW50ZXJvcGVyYWJsZSBpc3N1ZXMsIGl0IG1heSBsZWFkIHRvPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgc3ViLW9wdGltYWwgaW1wbGVtZW50YXRpb25zIGlmIHRoZSBzZmMgaW5m b3JtYXRpb24gaXMgcHJlc2VudDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9ubHkg aW4gb25lPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZyYWdtZW50cyw8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBldGMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNeSBjb21tZW50cyBhcmUgcmVsYXRlZCB0byB0 aGUgY3VycmVudCB0ZXh0IGluIHRoZSAtMDQuIFRoaXMgdGV4dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG5lZWRzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUgZml4ZWQgc29tZWhvdy48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNZWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRGUgOiBF bHp1ciwgVXJpIFttYWlsdG86dXJpLmVsenVyQGludGVsLmNvbV0gRW52b3nDqSA6IGRpbWFuY2hl PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDI0IGF2cmlsIDIwMTYgMTc6MzYg w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBUaG9tYXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgTmFydGVuOyBzZmNAaWV0Zi5vcmcgT2JqZXQgOiBSRTogW3NmY10g V0cgbGFzdCBjYWxsIGZvcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFm dC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIE1lZDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJIHNlZSBubyBuZWVkIHRvIHNwZWNpZnkgdGhlIGV4YWN0IGJlaGF2aW9yIGFzIE5TSCBpcyB0 cmFuc3BvcnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kZXBlbmRlbnQg aS5lLiBsaWtlIE5TSCBpbnRlcmFjdGlvbiB3aXRoIGFueSBvdGhlciBUcmFuc3BvcnQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZWggaXNzdWUgb2YgRnJhZ21lbnRhdGlvbiBp cyB0byBiZSBkZWFsdCBpbiBhIHdheSB0aGF0IG1hdGNoZXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhlIG1lY2hhbmlzbXMgc3VwcG9ydGVkIGJ5IHRoZSBUcmFuc3BvcnQg dXNlZCBhbmQgZG8gbm90IGJlbG9uZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBpbiB0aGUgTlNIIGRyYWZ0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoeDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBVcmkg KCJPby1SZWUiKTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDOiA5NDktMzc4 LTc1Njg8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP Zjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAxNCwgMjAxNiAxMjo0MyBBTTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUbzogVGhvbWFzIE5hcnRlbiAmbHQ7bmFydGVuQHVzLmlibS5jb20mZ3Q7OyBzZmNA aWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6 IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBSLSw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gYWRkaXRpb24gdG8gb3RoZXIgcGVuZGluZyBp c3N1ZXMgcmFpc2VkIGZvciB0aGlzIGRyYWZ0LCBJPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHdvdWxkIGxpa2UgdG8gcmFpc2UgdGhpcyBhZGRpdGlvbmFsIG9uZSBhYm91dCBT ZWN0aW9uIDYuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ID09PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDYuJm5ic3A7IEZyYWdtZW50YXRpb24gQ29uc2lkZXJhdGlvbnM8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgTlNIIGFuZCB0aGUgYXNzb2NpYXRlZCB0cmFuc3BvcnQgaGVh ZGVyIGFyZSAiYWRkZWQiIHRvIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNhcHN1bGF0ZWQgcGFja2V0L2ZyYW1lLiZuYnNwOyBUaGlz IGFkZGl0aW9uYWwgaW5mb3JtYXRpb248YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaW5jcmVhc2VzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzaXplIG9mIHRoZSBwYWNrZXQu Jm5ic3A7IEluIG9yZGVyIHRoZSBlbnN1cmUgcHJvcGVyIGZvcndhcmRpbmcgb2YgTlNIPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRhdGEsIHNl dmVyYWwgb3B0aW9ucyBmb3IgaGFuZGxpbmcgZnJhZ21lbnRhdGlvbiBhbmQgcmUtYXNzZW1ibHk8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhp c3Q6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuJm5ic3A7IEp1bWJvIEZyYW1l cywgd2hlbiBzdXBwb3J0ZWQsIGVuYWJsZSB0aGUgdHJhbnNwb3J0IG9mIE5TSCBhbmQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYXNzb2NpYXRlZCB0cmFuc3BvcnQgcGFja2V0cyB3aXRob3V0IHJlcXVp cmluZyBmcmFnbWVudGF0aW9uLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAyLiZu YnNwOyBQYXRoIE1UVSBEaXNjb3ZlcnkgW1JGQzExOTFdImRlc2NyaWJlcyBhIHRlY2huaXF1ZSBm b3I8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHluYW1pY2FsbHkgZGlzY292ZXJpbmcgdGhlIG1heGlt dW0gdHJhbnNtaXNzaW9uIHVuaXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg KE1UVSkgb2Y8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXJiaXRyYXJ5IGludGVybmV0IHBhdGgiIGFuZCBjYW4gYmUgdXRpbGl6ZWQgdG8gZW5zdXJlPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 IHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlZCBwYWNrZXQgc2l6ZSBpcyB1c2VkLjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAzLiZuYnNwOyBbUkZDNjgzMF0gZGVzY3Jp YmVzIHR3byBzY2hlbWVzIGZvciBmcmFnbWVudGF0aW9uIGFuZCByZS08YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgYXNzZW1ibHk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gc2VjdGlvbiA1LjQuPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ID09PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICogVGhl IHRleHQgaXMgd2VhayBmb3IgYSBTdGFuZGFyZCB0cmFjayBkb2N1bWVudCB0aGF0IGlzPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZGVkIHRvIHNvbHZlIHRoZSBwcm9i bGVtIGluPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3NDk4I3NlY3Rpb24tPGJyPiZndDsmZ3Q7Jmd0OyZndDsgMi4xMi48 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgc2hvdWxkIGJlIGEgY2xl YXIgYmVoYXZpb3IgdG8gYmUgZm9sbG93ZWQgYnkgYW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBpbXBs ZW1lbnRhdGlvbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnVydGhlciwg SSB3b3VsZCBhdm9pZCB0aGUgdXNlIG9mIHdvcmRzIHN1Y2ggYXMgImNhbiIuPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICogVGhlIHRleHQgY292ZXJzIG9ubHkgZnJhZ21lbnRhdGlvbiB3aGVuIGl0IGlzIGluZHVj ZWQgYnkgU0ZDPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9wZXJhdGlvbnMs IGl0IGRvZXMgbm90IGRpc2N1c3MgdGhlIHRyZWF0bWVudCBvZiBhIGZyYWdtZW50IHdoZW48YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjZWl2ZWQgaW4gYW4gU0ZDIGRvbWFp bi4gSU1ITywgdGhlIGRyYWZ0IHNob3VsZCBhbHNvIHNwZWNpZnk8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGJlaGF2aW9yIG9mIHRoZSBDbGFzc2lmaWVyIHdpdGggcmVn YXJkcyB0byBmcmFnbWVudHMgZm9yIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzYWtlIG9mIHByb3BlciBTRkMgb3BlcmF0aW9uLiBBcHBseWluZyBjbGFzc2lmaWNhdGlv biBwb2xpY2llczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYXkgcmVxdWly ZSB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmdWxsIHBhY2tldCwgbm90IG9u bHkgYSBmcmFnbWVudC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gcGFy dGljdWxhciwgZGVkaWNhdGVkIHJlc291cmNlcyBzaG91bGQgZGVkaWNhdGVkIGZvciBoYW5kbGlu Zzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvdXQgb2Ygb3JkZXIgZnJhZ21l bnRzLiBPZiBjb3Vyc2UsIGl0IGlzIG91dCBvZiBzY29wZSBvZiB0aGlzPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvY3VtZW50IHRvIGRlc2NyaWJlIGhvdyBTRnMgaGFuZGxl IGZyYWdtZW50cy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKiBJZiBhbiBTRkMgaGVhZGVyIGlzIHByZXBlbmRl ZCBmb3IgYWxsIGZyYWdtZW50cywgSSdtIG5vdCBzdXJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZXJlIGlzIGFueSBwYXJ0aWN1bGFyIGlzc3VlIGF0IHRoZSBTRkYgbGV2 ZWwuLi5leGNlcHQgaWY8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RyaXBw aW5nL2FkZGluZyBjb250ZXh0IFRMVnMgZGVwZW5kcyBvbiB0aGUgZnVsbCBwYWNrZXQgKG5vdDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBqdXN0IGZyYWdtZW50KS4gSXQgaXMg d2FycmFudGVkIHRvIGNvbnNpZGVyIGEgbGl0dGxlIGJpdCB0aGlzPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBvaW50IGJlZm9yZSBkZWNsYXJpbmcgdGhlcmU8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgaXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBubyBpc3N1 ZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgKiBUaGUgdGV4dCBzdGF0ZXMgInNldmVyYWwgb3B0aW9ucyIuIFRo aXMgbWF5IGJlIGludGVycHJldGVkIGFzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGlmIGltcGxlbWVudGluZyBvbmUgb2YgdGhlbSBpcyBzdWZmaWNpZW50Li4ud2hpY2ggaXMg bm90IHRydWUuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBmaXJzdCB0 d28gcG9pbnRzIGNvbnRyaWJ1dGUgdG8gbWluaW1pemUgdGhlIGZyYWdtZW50YXRpb248YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmlzaywgYnV0IGZyYWdtZW50YXRpb24gbWF5 IHN0aWxsIGJlIGV4cGVyaWVuY2VkIChlLmcuLCBvdGhlcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzaGltcyBhcmUgcHJlcGVuZGVkIGJ5IG90aGVyIG5vZGVzIGZvciBzb21l IG90aGVyIHB1cnBvc2VzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXN0 ZWQgbnNoLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBldGMuKTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAqIFRoZSBmaXJzdCB0d28gcG9pbnRzIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHJl YXNzZW1ibHkuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICogVGhlIHN1cHBvcnQgb2YganVtYm8gZnJhbWVzIGJ5 IGEgcm91dGVyL2RldmljZSBkb2VzIG5vdCBtZWFuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoYXQgaXQgY2FuIG1ha2UgdXNlIG9mIGl0LiBBcHByb3ByaWF0ZSBNVFUgY29u ZmlndXJhdGlvbiBzaG91bGQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmUg dW5kZXJ0YWtlbiBpbiBhIGNvbnNpc3RlbnQgbWFubmVyIHdpdGhpbiBhbiBTRkMgZG9tYWluLiBU aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGV4dCBzaG91bGQgYmUgdXBk YXRlZCB0byBtYWtlIGl0IGlzIGFib3V0IChjb25zaXN0ZW50KSBNVFU8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyBjb25maWd1cmF0aW9uLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqIEJUVywgc2hvdWxkbid0IHRoZSB0 ZXh0IGJlIHJld29yZGVkIHRvIHJlY29tbWVuZGVkIHRvIGluY3JlYXNlPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBNVFUgb2YgKiphbGwgbm9kZXMqKiBvZiBhbiBTRkMt ZW5hYmxlZCBkb21haW4gYnkgYXQgbGVhc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlIGxlbmd0aCBvZiBTRkMgaGVhZGVyICsgdHJhbnNwb3J0IGhlYWRlcj88YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgKiBCdWxsZXQgMiwgaG93IFBNVFUgZGlzY292ZXJ5IGlzIGFjdHVhbGx5IHVzZWQg aW4gdGhpcyBjb250ZXh0Pzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEbyB5 b3UgYXNzdW1lIHRoYXQgYWxsIFNGQy1hd2FyZSBub2RlcyB3aWxsIGlzc3VlIHN1Y2ggbWVzc2Fn ZXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG93YXJkcyBvdGhlciBTRkMt YXdhcmUgbm9kZSwgYXJiaXRyYXJ5IGRlc3RpbmF0aW9uLCBlbHNlPzxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAq IEJ1bGxldCAyLCBJIHdvdWxkIGRyb3AgImRlc2NyaWJlcyBhIHRlY2huaXF1ZSBmb3IgZHluYW1p Y2FsbHk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlzY292ZXJpbmcgdGhl IG1heGltdW0gdHJhbnNtaXNzaW9uIHVuaXQgKE1UVSkgb2YgYW4gYXJiaXRyYXJ5PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVybmV0IHBhdGgiLjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAqIEJ1bGxldCAyLCBzLyB0aGUgdGhlL3RoZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKiBUaGUgcmVmZXJl bmNlIHRvIHRoZSBMSVNQIHNwZWNpZmljYXRpb24gcmFpc2VzIHR3byBjb25jZXJuczxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgb25lPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGNvbW1lbnQ6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICgxKSBJIGRvbid0IHRoaW5r IGl0IGlzIGEgZ29vZCBhcHByb2FjaCB0aGF0IGZyYWdtZW50cyBpbmR1Y2VkPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJ5IHRoZSBuZXR3b3JrIGFyZSBwYXNzZWQgdG8gdGhl aXIgdWx0aW1hdGUgZGVzdGluYXRpb25zIGFzIHN1Y2g8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyAoc3Rh dGVsZXNzKS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSU1PLCByZWFzc2Vt Ymx5IHNob3VsZCBiZSBkb25lIHdpdGhpbiB0aGUgU0ZDIGRvbWFpbjxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAocmVzcG9uc2libGUgZm9yPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGZyYWdtZW50YXRpb24pIG5vdCBwYXNzZWQgYXdheS48YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKDIpIERvZXMgdGhlIHN0YXRlZnVsIG1vZGUgcmVx dWlyZSBhbGwgU0ZDIGRhdGEgcGxhbmUgZWxlbWVudHM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgbWFpbnRhaW4gYSBmdWxsIGxpc3Qgb2YgTVRVIGZvciB0aGUgYW55IFNGRi9T RiBpbnN0YW5jZSBvZiB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU0ZD PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZG9tYWluPzxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBU aGUgY3VycmVudCB0ZXh0IHN1Z2dlc3RzIHRoYXQgW1JGQzY4MzBdIHNob3VsZCBiZSBsaXN0ZWQg YXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9ybWF0aXZlIHJlZmVyZW5j ZSAobm90IGFuIGluZm9ybWF0aXZlIG9uZSkuIEkgd291bGQgcGVyc29uYWxseTxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmYXZvciByZW1vdmluZyB0aGUgcmVmZXJlbmNlIHRv IExJU1AgKGFzIGl0IGlzIGFuIEV4cGVyaW1lbnRhbCBSRkMpLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqIFRo ZSBzZWN1cml0eSBzZWN0aW9uIG9mIHRoZSBkcmFmdCBtYXkgYmUgYXVnbWVudGVkIHdpdGg8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb25hbCBmcmFnbWVudGF0 aW9uLXJlbGF0ZWQgcG9pbnRlcnMgdG86IGUuZy4sIFJGQzE4NTg8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGZvciBJUCBGcmFnbWVu dCBGaWx0ZXJpbmcpLCBSRkMzMTI4PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IChQcm90ZWN0aW9uIEFnYWluc3QgYSBWYXJpYW50IG9mIHRoZSBUaW55IEZyYWdtZW50IEF0dGFj ayksIGFuZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSRkM8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgNDk2MyAoSVB2NCBSZWFzc2VtYmx5IEVycm9ycyBh dCBIaWdoIERhdGEgUmF0ZXMpLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1lZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBE ZSA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIEVudm95w6kgOiBsdW5kaSAxMSBhdnJpbCAyMDE2IDEzOjE0IMOAIDo8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRob21hcyBOYXJ0ZW47IHNmY0BpZXRmLm9y ZyBPYmpldCA6IFJlOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgRGVhciBUaG9tYXMsIGFsbCw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBJ IG1lbnRpb25lZCBkdXJpbmcgdGhlIG1lZXRpbmcsIHRoZXJlIGFyZSBzZXZlcmFsIGlzc3Vlczxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBhcmUgbm90IGNvdmVy ZWQgaW4gdGhlIGxhc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEk8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFscmVhZHkgcHJvdmlkZWQgZXhhbXBsZXMgb2YgdGhlIGlz c3VlcyBvZmZsaW5lIGFzIHJlcXVlc3RlZCBieSBNYXJ0aW4uPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQ2hlZXJzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWVkPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERlIDogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgVGhvbWFzPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTmFydGVuIEVudm95w6kgOiBqZXVkaSAzMSBt YXJzIDIwMTYgMDQ6NDggw4AgOiBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPYmpldDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gt MDQudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEZWFyIFdHOjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBub3RlIGJlZ2lucyBhIFdHIGxhc3QgY2FsbCBvbiBk cmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt c2ZjLW5zaC8pLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGVkaXRvcnMgb2Yg dGhlIE5TSCBkb2N1bWVudCBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZTxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3NlZCBhbGwga25vd24gY29t bWVudHMgYW5kIHRoYXQgdGhlcmUgYXJlIG5vIG9wZW4gaXNzdWVzPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRo ZSBkb2N1bWVudC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN1YnN0YW50aXZlIGNv bW1lbnRzIHRvIHRoZSBsaXN0IHBsZWFzZSwgZWRpdG9yaWFsIGNvbW1lbnRzPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2FuIGdvIGRpcmVjdGx5IHRvIHRoZSBk b2N1bWVudCBlZGl0b3JzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2UnbGwgYWxz byBnZXQgYSBicmllZiB1cGRhdGUgZnJvbSB0aGUgZWRpdG9ycyBhdCBuZXh0IHdlZWsnczxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lZXRpbmcuIElmIHRoZXJl IGFyZSBhbnkgcmVtYWluaW5nIGlzc3VlcyB3aXRoIHRoZSBkb2N1bWVudCw8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByYWlzaW5nIHRoZW0gYmVmb3JlIHRoZSBt ZWV0aW5nIHdvdWxkIGJlIGVzcGVjaWFsbHkgaGVscGZ1bC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEZvciB0aGUgY2hhaXJzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRob21hczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNmY0BpZXRmLm9yZzxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0OyZn dDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IHNmY0BpZXRmLm9yZzxicj4m Z3Q7Jmd0OyZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8 YnI+Jmd0OyZndDsmZ3Q7IHNmY0BpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPiZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgc2ZjQGlldGYub3Jn PGJyPiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJy PiZndDsmZ3Q7PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5zZmMgbWFpbGluZyBsaXN0PGJyPnNmY0BpZXRmLm9yZzxicj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj48YnI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+c2ZjIG1haWxpbmcgbGlzdDxicj5zZmNA aWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+ PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_3503018393531020-- From nobody Tue Apr 26 13:53: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 9E59212D10F for ; Tue, 26 Apr 2016 13:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KdMJVsqvI-ub for ; Tue, 26 Apr 2016 13:53:05 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF30012B04B for ; Tue, 26 Apr 2016 13:53:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BD504240828; Tue, 26 Apr 2016 13:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461703984; bh=uUfvQaO5fTzHQky2rKFRcYIPyzlQCQKnTZZ7vKDUqCc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RRFYYtFv5ARhECYoKdP1e4n/zv4nV9ZziWryV/CttHEJQo99ogmdjJ1kfMhM9dw71 zctpd3m8vEqVVE2TDTNce/uELWBTpla9GwMNtWbmppeIkkhikyM4QKbotMXWpP9wwG eG4oXSQOguZMHZ8QpbMeBYK7gusMwOgTd7/vRnlc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 02541240E0F; Tue, 26 Apr 2016 13:53:03 -0700 (PDT) To: Linda Dunbar , "sfc@ietf.org" References: <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <40836304-a3b3-d16d-c9e5-4951d0100b65@joelhalpern.com> Date: Tue, 26 Apr 2016 16:52:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 20:53:07 -0000 You second insertion below seems to assume that service functions require reassembled packets. That is not generally true. I am sure that there are some service functions that require that. But most of them either: 1) do not require reassembly at all; 2) can get by with virtual reassembly where they preserve needed state between fragments; 3) or, even more rarely, can get by with reassembling the first and second packet, and then applying stateful processing thereafter. Yours, Joel On 4/26/16 3:20 PM, Linda Dunbar wrote: > Joel, > > Replies are inserted below: > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 26, 2016 12:18 PM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > With regard to Transport tunnel fragementation, that seems an issue for > the transport protocol. I don't actually object to a sentence, but it > does not seem that it will accomplish anything. > > [Linda] By having this description, you avoid a lot of future > unnecessary debate about how fragmentation should be processed because > some people are only thinking about Tunnel induced fragmentation where > as some other people are thinking of Source induced fragmentation. > > > With regard to packets fragmented by the source, I completely disagree > with your assertion. If an SFF were to reassemble the packets, that > would be a violation of its job. There is no reason for an SFF to > reassemble a packet fragmented by the source. The classifier may have > to do some interesting things in order to properly classify succeeding > fragments, but that is an implementation issue (most commonly addressed > with virtual reassembly, which doe snot delay the fragments.) We don't > specity that. > > If an SF needs to reassemble fragments to do its job, that is up to the > SF. Some will need to actually reassemble. Some will need to perform > virtual reassembly, and some will happily process the fragments. I can > not see what the NSH document could possibly mandate. > > [Linda] I said “either SFF or SF” has to re-assemble the fragmented > packets. I don’t have strong opinion on who perform the re-assembling > job (as long as one of them do). If a set of SFs attached to a SFF are > not capable of performing the re-assembling and they need the whole > packet to do inspection, then the SFF don’t have any choice. I just > think that it is necessary to add the description because it can be very > messy (if not impossible) for SFs to process partial packets. > > > Linda > > > > > Yours, > Joel > > On 4/26/16 11:47 AM, Linda Dunbar wrote: >> Joel, >> >> I think the document should add the description on the following two >> fragmentation scenarios: >> >> - Transport tunnel generated fragmentation: When a packet >> fragmentation is caused by transport tunnel (i.e. various >> encapsulations), the termination point of the transport tunnel is >> responsible for re-assembling the fragmented pieces of the packet. >> Since there won't be any SFF nodes in between the Transport Tunnel, >> the tunnel generated fragmentation does not require any actions by SFF >> nodes or SF nodes. >> >> >> - Source node generated fragmentation (after adding on the NSH >> header): When fragmentation has to be performed for a packet being >> encapsulated with the NSH header, either the intermediate SFF nodes or >> the SF nodes have to be able to reassemble the fragmented pieces. >> >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >> To: Linda Dunbar; mohamed.boucadair@orange.com ; > Elzur, Uri; >> sfc@ietf.org Subject: Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that you are referring only to >> the case of transport generated fragmentation of the outer packet. I >> had assumed you were not talking about that, since the resulting >> fragments will not all have NSH headers. As with any tunnel >> technology, if the tunnel chooses to fragment at its layer, then the >> tunnel is responsible for reassembly. That would be invisible to the >> SFF. >> >> Yours, Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>> Agree with Med. >>> >>> Even if each fragment piece of a packet with NSH header carries the >>> NSH header, the intermediate SFF nodes still need to put together all >>> the fragments together before passing the whole data frame to the SF. >>> >>> Linda >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On >>> Behalf Of mohamed.boucadair@orange.com Sent: > Monday, April 25, >>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Re-, >>> >>> How do you instruct the transport layer to ALWAYS prepend an NSH >>> header even for fragments? Or you don't care about that? >>> >>> Thank you. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : Elzur, Uri >>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 16:26 À >>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet >>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Med >>>> >>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>> *NOT* a transport, dealing with fragmentation is left to the >>>> Transport used. >>>> >>>> The model I use for NSH, is basically similar to VXLAN . It is an >>>> overly. >>>> >>>> Thx >>>> >>>> Uri ("Oo-Ree") C: 949-378-7568 >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>> On Behalf Of mohamed.boucadair@orange.com Sent: > Monday, April 25, >>>> 2016 7:18 AM To: Joel M. Halpern >; sfc@ietf.org > >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Joel, >>>> >>>> Please see inline. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Joel M. Halpern >>>>> [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 avril 2016 15:48 À : >>>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG last >>>>> call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> If I am understanding you correctly Med, you are asking that the >>>>> NSH draft specify how service chaining should cope with packets >>>>> that have been fragmented? >>>>> >>>> >>>> [Med] To be accurate, I'm asking to assess whether there are >>>> implications. If there are, then the draft should be updated >>>> accordingly. >>>> >>>>> NSH, and the SFF functionality, does not care. >>>> >>>> [Med] I'm not that sure. Some typical implications are listed >>>> below: >>>> >>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>> didn't maintained a state, subsequent fragments won't be >>>> appropriately processed. * SFC-aware function: if prepending a >>>> context information depends on the full packet, not only a fragment. >>>> >>>> It just does its job. >>>> >>>> [Med] which may be disturbed in some situations as listed in the >>>> examples above. >>>> >>>>> Ingress and intermediate classifiers may cope with fragments in any >>>>> number of ways. >>>> Specifying such is clearly out of scope for this draft. >>>> >>>> [Med] The purpose is not to specify the internal implementation >>>> details but the external behavior of the classifier function when it >>>> comes to handle fragments. That behavior may have an incidence on >>>> SFF, in particular. The purpose is not to recommend the maximum >>>> resources to be dedicated to out of order fragments nor the timeout >>>> to cache those; these considerations are of course out of scope. >>>> Nevertheless, an implementation should offer a configurable >>>> parameter so that an operator tweak those according to its context. >>>> >>>>> I suppose one could write an informational draft on possible ways >>>>> of coping. The IETF has not usually published such. >>>>> Service functions have to cope with fragmented packets just as they >>>>> had to before the advent of NSH, so describing that is clearly not >>>>> needed here. >>>> >>>> [Med] The advent of NSH has the following implications: * it >>>> exacerbates fragmentation. Handing over this issue to the transport >>>> layer may lead to interoperability issues. * the chaining may not be >>>> efficient if fragments are inappropriately handled. >>>> >>>> Introducing NSH should not degrade the overall service compared to >>>> legacy service deployment schemes. >>>> >>>>> >>>>> Yours, Joel >>>>> >>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>> Re-, >>>>>> >>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>> what to >>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>> issues: >>>>>> >>>>>> (1) Fragmentation that is caused by prepending an SFC header. (2) >>>>>> Handling fragments at the ingress of an SFC-enabled domain. >>>>>> >>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>> explicitly >>>>> called out in the text (see my first message). >>>>>> >>>>>> There are other issues that need to be discussed, e.g., how to >>>>>> deal with >>>>> fragments in SFFs/Classifiers? >>>>>> >>>>>> It is also "prudent" to check that no issues will be experienced >>>>>> in SFF >>>>> to handle fragments. If an SFC header is prepended for all >>>>> fragments, I'm not sure there >>>>>> is any particular issue at the SFF level, except if >>>>>> stripping/adding >>>>> context TLVs depends on the full packet (not just fragment). It is >>>>> warranted to consider a little bit this point before declaring >>>>> there is no issue. >>>>>> >>>>>> For point (1), declaring fragmentation out of scope would be meant >>>>>> that >>>>> an implementation must be prepared to receive fragments with or >>>>> without NSH header as this is a decision that is left to the >>>>> transport encapsulation. This is a requirement per se! >>>>>> >>>>>> I won't reiterate all the comments I have about the current >>>>>> wording of >>>>> this section. >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 >>>>>>> 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org >>>>>>> Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> My point is that Fragmentation is yet another transport related >>>>>>> issue >>>>> that >>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>> it >>>>> doesn't >>>>>>> really belong in the draft. We are providing an advice as >>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>> you'll find it doesn't even >>>>> relate >>>>>>> to it. >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: sfc >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>> mohamed.boucadair@orange.com Sent: > Sunday, April 24, 2016 >>>>>>> 10:32 PM To: Elzur, Uri >; Thomas Narten >>>>> >; >>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Uri, >>>>>>> >>>>>>> That's another option that needs to be discussed/investigated. >>>>>>> I'm >>>>> afraid >>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>> text >>>>> that >>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>> >>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>> because >>>>> it >>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>> here >>>>> because >>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>> sub-optimal implementations if the sfc information is present >>>>>>> only in one >>>>> fragments, >>>>>>> etc. >>>>>>> >>>>>>> My comments are related to the current text in the -04. >>>>>>> This text needs >>>>> to >>>>>>> be fixed somehow. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 avril >>>>>>>> 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>>>> independent i.e. like NSH interaction with any other Transport >>>>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>>>> the mechanisms supported by the Transport used and do not belong >>>>>>>> in the NSH draft >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com Sent: > Thursday, April 14, >>>>>>>> 2016 12:43 AM To: Thomas Narten >; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> R-, >>>>>>>> >>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>> would like to raise this additional one about Section 6. >>>>>>>> >>>>>>>> == 6. Fragmentation Considerations >>>>>>>> >>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>> encapsulated packet/frame. This additional information >>>>>>>> increases >>>>> the >>>>>>>> size of the packet. In order the ensure proper forwarding of >>>>>>>> NSH data, several options for handling fragmentation and >>>>>>>> re-assembly exist: >>>>>>>> >>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH >>>>>>>> and associated transport packets without requiring >>>>>>>> fragmentation. >>>>>>>> >>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>> an >>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>> the >>>>>>>> required packet size is used. >>>>>>>> >>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>> re- >>>>> assembly >>>>>>>> in section 5.4. == >>>>>>>> >>>>>>>> * The text is weak for a Standard track document that is >>>>>>>> intended to solve the problem in >>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>> 2.12. >>>>>>>> There should be a clear behavior to be followed by an >>>> implementation. >>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>> >>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>> operations, it does not discuss the treatment of a fragment when >>>>>>>> received in an SFC domain. IMHO, the draft should also specify >>>>>>>> the behavior of the Classifier with regards to fragments for the >>>>>>>> sake of proper SFC operation. Applying classification policies >>>>>>>> may require the >>>>>>> full packet, not only a fragment. >>>>>>>> In particular, dedicated resources should dedicated for handling >>>>>>>> out of order fragments. Of course, it is out of scope of this >>>>>>>> document to describe how SFs handle fragments. >>>>>>>> >>>>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>>>> there is any particular issue at the SFF level...except if >>>>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>>>> just fragment). It is warranted to consider a little bit this >>>>>>>> point before declaring there >>>>> is >>>>>>> no issue. >>>>>>>> >>>>>>>> * The text states "several options". This may be interpreted as >>>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>>> The first two points contribute to minimize the fragmentation >>>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>>> nested nsh, etc.) >>>>>>>> >>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>> >>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>> that it can make use of it. Appropriate MTU configuration should >>>>>>>> be undertaken in a consistent manner within an SFC domain. The >>>>>>>> text should be updated to make it is about (consistent) MTU >>>> configuration. >>>>>>>> >>>>>>>> * BTW, shouldn't the text be reworded to recommended to increase >>>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least >>>>>>>> the length of SFC header + transport header? >>>>>>>> >>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>>> >>>>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>>>> discovering the maximum transmission unit >>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>> >>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>> >>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>> and one comment: >>>>>>>> >>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>> by the network are passed to their ultimate destinations as such >>>> (stateless). >>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>> (responsible for fragmentation) not passed away. (2) Does the >>>>>>>> stateful mode require all SFC data plane elements maintain a >>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>> domain? >>>>>>>> >>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>> normative reference (not an informative one). I would personally >>>>>>>> favor removing the reference to LISP (as it is an Experimental >>>>>>>> RFC). >>>>>>>> >>>>>>>> * The security section of the draft may be augmented with >>>>>>>> informational fragmentation-related pointers to: >>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny >>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High >>>>>>>> Data Rates). >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>> mohamed.boucadair@orange.com > Envoyé : lundi 11 avril >>>>>>>>> 2016 13:14 À : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear Thomas, all, >>>>>>>>> >>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>> already provided examples of the issues offline as requested by >>>>>>>>> Martin. >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>>>>> Envoyé : jeudi 31 mars 2016 04:48 À : >>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for >>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > The editors of the NSH document have indicated that they have >>>>>>>>>> addressed all known comments and that there are no open issues >>>>>>>>>> with the current version of the document. >>>>>>>>>> >>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>> can go directly to the document editors. >>>>>>>>>> >>>>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>>> >>>>>>>>>> For the chairs, Thomas >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing list >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing list >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ 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 Tue Apr 26 14:32:28 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 C124C12D0C9 for ; Tue, 26 Apr 2016 14:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 warEklDJKVKJ for ; Tue, 26 Apr 2016 14:32:25 -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 001C1120727 for ; Tue, 26 Apr 2016 14:32:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIO09456; Tue, 26 Apr 2016 21:32:21 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 22:32:20 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 14:32:15 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQIp3nrjaS0+VjDL7mlh8GJ+Er+AwgARg/TCAEFX48IABYBMAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAEik2CAAH4AgP//ixXggACSLID//6nIYIAAkmEA//+UMlA= Date: Tue, 26 Apr 2016 21:32:15 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7D111@dfweml501-mbb> References: <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> <40836304-a3b3-d16d-c9e5-4951d0100b65@joelhalpern.com> In-Reply-To: <40836304-a3b3-d16d-c9e5-4951d0100b65@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.571FDE66.006C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f00e12aefba01234b913f67e0c7526fe Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 21:32:27 -0000 Joel,=20 I agree that some SFs don't need to re-assemble fragmented packets. But I a= m also aware of SFs that need to process the whole packets.=20 It would be helpful to describe your assumptions in the draft Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, April 26, 2016 3:53 PM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt You second insertion below seems to assume that service functions require r= eassembled packets. That is not generally true. I am sure that there are = some service functions that require that. But most of them either: 1) do not require reassembly at all; 2) can get by with virtual reassembly where they preserve needed state betw= een fragments; 3) or, even more rarely, can get by with reassembling the first and second = packet, and then applying stateful processing thereafter. Yours, Joel On 4/26/16 3:20 PM, Linda Dunbar wrote: > Joel, > > Replies are inserted below: > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, April 26, 2016 12:18 PM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;=20 > sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > With regard to Transport tunnel fragementation, that seems an issue=20 > for the transport protocol. I don't actually object to a sentence,=20 > but it does not seem that it will accomplish anything. > > [Linda] By having this description, you avoid a lot of future=20 > unnecessary debate about how fragmentation should be processed because=20 > some people are only thinking about Tunnel induced fragmentation where=20 > as some other people are thinking of Source induced fragmentation. > > > With regard to packets fragmented by the source, I completely disagree=20 > with your assertion. If an SFF were to reassemble the packets, that=20 > would be a violation of its job. There is no reason for an SFF to=20 > reassemble a packet fragmented by the source. The classifier may have=20 > to do some interesting things in order to properly classify succeeding=20 > fragments, but that is an implementation issue (most commonly=20 > addressed with virtual reassembly, which doe snot delay the=20 > fragments.) We don't specity that. > > If an SF needs to reassemble fragments to do its job, that is up to=20 > the SF. Some will need to actually reassemble. Some will need to=20 > perform virtual reassembly, and some will happily process the=20 > fragments. I can not see what the NSH document could possibly mandate. > > [Linda] I said "either SFF or SF" has to re-assemble the fragmented=20 > packets. I don't have strong opinion on who perform the re-assembling=20 > job (as long as one of them do). If a set of SFs attached to a SFF are=20 > not capable of performing the re-assembling and they need the whole=20 > packet to do inspection, then the SFF don't have any choice. I just=20 > think that it is necessary to add the description because it can be=20 > very messy (if not impossible) for SFs to process partial packets. > > > Linda > > > > > Yours, > Joel > > On 4/26/16 11:47 AM, Linda Dunbar wrote: >> Joel, >> >> I think the document should add the description on the following two=20 >> fragmentation scenarios: >> >> - Transport tunnel generated fragmentation: When a packet=20 >> fragmentation is caused by transport tunnel (i.e. various=20 >> encapsulations), the termination point of the transport tunnel is=20 >> responsible for re-assembling the fragmented pieces of the packet. >> Since there won't be any SFF nodes in between the Transport Tunnel,=20 >> the tunnel generated fragmentation does not require any actions by=20 >> SFF nodes or SF nodes. >> >> >> - Source node generated fragmentation (after adding on the NSH >> header): When fragmentation has to be performed for a packet being=20 >> encapsulated with the NSH header, either the intermediate SFF nodes=20 >> or the SF nodes have to be able to reassemble the fragmented pieces. >> >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- From: Joel M. Halpern=20 >> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >> To: Linda Dunbar; mohamed.boucadair@orange.com=20 >> ; > Elzur, Uri; >> sfc@ietf.org Subject: Re: [sfc] WG last call=20 >> for draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that you are referring only to=20 >> the case of transport generated fragmentation of the outer packet. I=20 >> had assumed you were not talking about that, since the resulting=20 >> fragments will not all have NSH headers. As with any tunnel=20 >> technology, if the tunnel chooses to fragment at its layer, then the=20 >> tunnel is responsible for reassembly. That would be invisible to the=20 >> SFF. >> >> Yours, Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>> Agree with Med. >>> >>> Even if each fragment piece of a packet with NSH header carries the=20 >>> NSH header, the intermediate SFF nodes still need to put together=20 >>> all the fragments together before passing the whole data frame to the S= F. >>> >>> Linda >>> >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>> On Behalf Of mohamed.boucadair@orange.com Sent: > Monday, April 25, >>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Re-, >>> >>> How do you instruct the transport layer to ALWAYS prepend an NSH=20 >>> header even for fragments? Or you don't care about that? >>> >>> Thank you. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : Elzur, Uri=20 >>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 >>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org=20 >>>> Objet >>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Med >>>> >>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>> *NOT* a transport, dealing with fragmentation is left to the=20 >>>> Transport used. >>>> >>>> The model I use for NSH, is basically similar to VXLAN . It is an=20 >>>> overly. >>>> >>>> Thx >>>> >>>> Uri ("Oo-Ree") C: 949-378-7568 >>>> >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of mohamed.boucadair@orange.com Sent: > Monday, April 25, >>>> 2016 7:18 AM To: Joel M. Halpern >>> >; sfc@ietf.org > >>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Hi Joel, >>>> >>>> Please see inline. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Joel M. Halpern=20 >>>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 =C0= : >>>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org =20 >>>>> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> If I am understanding you correctly Med, you are asking that the=20 >>>>> NSH draft specify how service chaining should cope with packets=20 >>>>> that have been fragmented? >>>>> >>>> >>>> [Med] To be accurate, I'm asking to assess whether there are=20 >>>> implications. If there are, then the draft should be updated=20 >>>> accordingly. >>>> >>>>> NSH, and the SFF functionality, does not care. >>>> >>>> [Med] I'm not that sure. Some typical implications are listed >>>> below: >>>> >>>> * SFF: If the NSH header is present only in the a fragment but SFF=20 >>>> didn't maintained a state, subsequent fragments won't be=20 >>>> appropriately processed. * SFC-aware function: if prepending a=20 >>>> context information depends on the full packet, not only a fragment. >>>> >>>> It just does its job. >>>> >>>> [Med] which may be disturbed in some situations as listed in the=20 >>>> examples above. >>>> >>>>> Ingress and intermediate classifiers may cope with fragments in=20 >>>>> any number of ways. >>>> Specifying such is clearly out of scope for this draft. >>>> >>>> [Med] The purpose is not to specify the internal implementation=20 >>>> details but the external behavior of the classifier function when=20 >>>> it comes to handle fragments. That behavior may have an incidence=20 >>>> on SFF, in particular. The purpose is not to recommend the maximum=20 >>>> resources to be dedicated to out of order fragments nor the timeout=20 >>>> to cache those; these considerations are of course out of scope. >>>> Nevertheless, an implementation should offer a configurable=20 >>>> parameter so that an operator tweak those according to its context. >>>> >>>>> I suppose one could write an informational draft on possible ways=20 >>>>> of coping. The IETF has not usually published such. >>>>> Service functions have to cope with fragmented packets just as=20 >>>>> they had to before the advent of NSH, so describing that is=20 >>>>> clearly not needed here. >>>> >>>> [Med] The advent of NSH has the following implications: * it=20 >>>> exacerbates fragmentation. Handing over this issue to the transport=20 >>>> layer may lead to interoperability issues. * the chaining may not=20 >>>> be efficient if fragments are inappropriately handled. >>>> >>>> Introducing NSH should not degrade the overall service compared to=20 >>>> legacy service deployment schemes. >>>> >>>>> >>>>> Yours, Joel >>>>> >>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>> Re-, >>>>>> >>>>>> I hear you, but my comment is that we need, as a WG, to decide=20 >>>>>> what to >>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>> issues: >>>>>> >>>>>> (1) Fragmentation that is caused by prepending an SFC header. (2)=20 >>>>>> Handling fragments at the ingress of an SFC-enabled domain. >>>>>> >>>>>> Increasing the MTU is for sure a recommendation is to be=20 >>>>>> explicitly >>>>> called out in the text (see my first message). >>>>>> >>>>>> There are other issues that need to be discussed, e.g., how to=20 >>>>>> deal with >>>>> fragments in SFFs/Classifiers? >>>>>> >>>>>> It is also "prudent" to check that no issues will be experienced=20 >>>>>> in SFF >>>>> to handle fragments. If an SFC header is prepended for all=20 >>>>> fragments, I'm not sure there >>>>>> is any particular issue at the SFF level, except if=20 >>>>>> stripping/adding >>>>> context TLVs depends on the full packet (not just fragment). It is=20 >>>>> warranted to consider a little bit this point before declaring=20 >>>>> there is no issue. >>>>>> >>>>>> For point (1), declaring fragmentation out of scope would be=20 >>>>>> meant that >>>>> an implementation must be prepared to receive fragments with or=20 >>>>> without NSH header as this is a decision that is left to the=20 >>>>> transport encapsulation. This is a requirement per se! >>>>>> >>>>>> I won't reiterate all the comments I have about the current=20 >>>>>> wording of >>>>> this section. >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 >>>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org= =20 >>>>>>> Objet : RE: [sfc] WG last call for=20 >>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Med >>>>>>> >>>>>>> My point is that Fragmentation is yet another transport related=20 >>>>>>> issue >>>>> that >>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so=20 >>>>>>> it >>>>> doesn't >>>>>>> really belong in the draft. We are providing an advice as=20 >>>>>>> extending the size of the packet may lead to fragmentation, but=20 >>>>>>> as you check RFC 7348 VxLAN, which my create the same issue,=20 >>>>>>> you'll find it doesn't even >>>>> relate >>>>>>> to it. >>>>>>> >>>>>>> Thx >>>>>>> >>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: sfc=20 >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>> mohamed.boucadair@orange.com = Sent: > Sunday, April 24, 2016 >>>>>>> 10:32 PM To: Elzur, Uri >>>>>> >; Thomas Narten >>>>> >; >>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last=20 >>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> Hi Uri, >>>>>>> >>>>>>> That's another option that needs to be discussed/investigated. >>>>>>> I'm >>>>> afraid >>>>>>> this is not the rationale adopted in -04 since it includes some=20 >>>>>>> text >>>>> that >>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>> >>>>>>> BTW, saying that nsh does not need to deal with fragmentation=20 >>>>>>> because >>>>> it >>>>>>> is transport-independent is not IMHO a good strategy to adopt=20 >>>>>>> here >>>>> because >>>>>>> it opens the door for interoperable issues, it may lead to=20 >>>>>>> sub-optimal implementations if the sfc information is present=20 >>>>>>> only in one >>>>> fragments, >>>>>>> etc. >>>>>>> >>>>>>> My comments are related to the current text in the -04. >>>>>>> This text needs >>>>> to >>>>>>> be fixed somehow. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril >>>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last=20 >>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> I see no need to specify the exact behavior as NSH is transport=20 >>>>>>>> independent i.e. like NSH interaction with any other Transport=20 >>>>>>>> eh issue of Fragmentation is to be dealt in a way that matches=20 >>>>>>>> the mechanisms supported by the Transport used and do not=20 >>>>>>>> belong in the NSH draft >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc=20 >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>>> mohamed.boucadair@orange.com = Sent: > Thursday, April 14, >>>>>>>> 2016 12:43 AM To: Thomas Narten >>>>>>> >; sfc@ietf.org =20 >>>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> R-, >>>>>>>> >>>>>>>> In addition to other pending issues raised for this draft, I=20 >>>>>>>> would like to raise this additional one about Section 6. >>>>>>>> >>>>>>>> =3D=3D 6. Fragmentation Considerations >>>>>>>> >>>>>>>> NSH and the associated transport header are "added" to the=20 >>>>>>>> encapsulated packet/frame. This additional information=20 >>>>>>>> increases >>>>> the >>>>>>>> size of the packet. In order the ensure proper forwarding of=20 >>>>>>>> NSH data, several options for handling fragmentation and=20 >>>>>>>> re-assembly exist: >>>>>>>> >>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH=20 >>>>>>>> and associated transport packets without requiring=20 >>>>>>>> fragmentation. >>>>>>>> >>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for=20 >>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>> an >>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>> the >>>>>>>> required packet size is used. >>>>>>>> >>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>> re- >>>>> assembly >>>>>>>> in section 5.4. =3D=3D >>>>>>>> >>>>>>>> * The text is weak for a Standard track document that is=20 >>>>>>>> intended to solve the problem in >>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>> 2.12. >>>>>>>> There should be a clear behavior to be followed by an >>>> implementation. >>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>> >>>>>>>> * The text covers only fragmentation when it is induced by SFC=20 >>>>>>>> operations, it does not discuss the treatment of a fragment=20 >>>>>>>> when received in an SFC domain. IMHO, the draft should also=20 >>>>>>>> specify the behavior of the Classifier with regards to=20 >>>>>>>> fragments for the sake of proper SFC operation. Applying=20 >>>>>>>> classification policies may require the >>>>>>> full packet, not only a fragment. >>>>>>>> In particular, dedicated resources should dedicated for=20 >>>>>>>> handling out of order fragments. Of course, it is out of scope=20 >>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>> >>>>>>>> * If an SFC header is prepended for all fragments, I'm not sure=20 >>>>>>>> there is any particular issue at the SFF level...except if=20 >>>>>>>> stripping/adding context TLVs depends on the full packet (not=20 >>>>>>>> just fragment). It is warranted to consider a little bit this=20 >>>>>>>> point before declaring there >>>>> is >>>>>>> no issue. >>>>>>>> >>>>>>>> * The text states "several options". This may be interpreted as=20 >>>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>>> The first two points contribute to minimize the fragmentation=20 >>>>>>>> risk, but fragmentation may still be experienced (e.g., other=20 >>>>>>>> shims are prepended by other nodes for some other purposes,=20 >>>>>>>> nested nsh, etc.) >>>>>>>> >>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>> >>>>>>>> * The support of jumbo frames by a router/device does not mean=20 >>>>>>>> that it can make use of it. Appropriate MTU configuration=20 >>>>>>>> should be undertaken in a consistent manner within an SFC=20 >>>>>>>> domain. The text should be updated to make it is about=20 >>>>>>>> (consistent) MTU >>>> configuration. >>>>>>>> >>>>>>>> * BTW, shouldn't the text be reworded to recommended to=20 >>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by=20 >>>>>>>> at least the length of SFC header + transport header? >>>>>>>> >>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>> Do you assume that all SFC-aware nodes will issue such messages=20 >>>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>>> >>>>>>>> * Bullet 2, I would drop "describes a technique for dynamically=20 >>>>>>>> discovering the maximum transmission unit >>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>> >>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>> >>>>>>>> * The reference to the LISP specification raises two concerns=20 >>>>>>>> and one comment: >>>>>>>> >>>>>>>> (1) I don't think it is a good approach that fragments induced=20 >>>>>>>> by the network are passed to their ultimate destinations as=20 >>>>>>>> such >>>> (stateless). >>>>>>>> IMO, reassembly should be done within the SFC domain=20 >>>>>>>> (responsible for fragmentation) not passed away. (2) Does the=20 >>>>>>>> stateful mode require all SFC data plane elements maintain a=20 >>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>> domain? >>>>>>>> >>>>>>>> The current text suggests that [RFC6830] should be listed as=20 >>>>>>>> normative reference (not an informative one). I would=20 >>>>>>>> personally favor removing the reference to LISP (as it is an=20 >>>>>>>> Experimental RFC). >>>>>>>> >>>>>>>> * The security section of the draft may be augmented with=20 >>>>>>>> informational fragmentation-related pointers to: >>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment=20 >>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny=20 >>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High=20 >>>>>>>> Data Rates). >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de=20 >>>>>>>>> mohamed.boucadair@orange.com=20 >>>>>>>>> > Envoy=E9 : lundi 11 avril >>>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Dear Thomas, all, >>>>>>>>> >>>>>>>>> As I mentioned during the meeting, there are several issues=20 >>>>>>>>> that are not covered in the last version of the draft. I=20 >>>>>>>>> already provided examples of the issues offline as requested=20 >>>>>>>>> by Martin. >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 >>>>>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : >>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call=20 >>>>>>>>>> for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear WG: >>>>>>>>>> >>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 >>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > The editors of the NSH document have indicated that they have >>>>>>>>>> addressed all known comments and that there are no open=20 >>>>>>>>>> issues with the current version of the document. >>>>>>>>>> >>>>>>>>>> Substantive comments to the list please, editorial comments=20 >>>>>>>>>> can go directly to the document editors. >>>>>>>>>> >>>>>>>>>> We'll also get a brief update from the editors at next week's=20 >>>>>>>>>> meeting. If there are any remaining issues with the document,=20 >>>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>>> >>>>>>>>>> For the chairs, Thomas >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>>> list sfc@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>> list sfc@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>> list sfc@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing list=20 >>>>>>> sfc@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>>> _______________________________________________ sfc mailing list=20 >>>>>> sfc@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ sfc mailing list=20 >>> sfc@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/sfc >>> > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Apr 26 14:43: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 D5C6512B071 for ; Tue, 26 Apr 2016 14:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 myx7wqBm7Zed for ; Tue, 26 Apr 2016 14:43:05 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100FC120727 for ; Tue, 26 Apr 2016 14:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CC1A5259F28; Tue, 26 Apr 2016 14:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461706984; bh=d7EdJG1HU5Mo1L4zGTfw7PUOmluIMXEWmysgT5BS5AA=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NkeZmzPcs6a8gaqtkZTH2LTMSUZAj2ujAMWDrtghRJzgnmH5FvN992UiGJn05L6Rj JD5I1coqRTx8O8VldUTKnzhER80cylSlDVHcrt/Ma2mowT2ZsbQSOfI2OHguMDvHEw fgQVNooKqWKqQqqtOKR1xPYjDU3p5VwHxj5ZxRN4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EA39424E0BB; Tue, 26 Apr 2016 14:43:03 -0700 (PDT) To: Linda Dunbar , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> <40836304-a3b3-d16d-c9e5-4951d0100b65@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7D111@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: Date: Tue, 26 Apr 2016 17:42:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7D111@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 21:43:08 -0000 The draft assumes that SFF are network elements. Network elements do not normally reassemble packets not addressed to themselves. As such, the assumption you refer to is the norm. Yes, some SF need to reassemble packets. We presume that functions which need to do somethign will do so. This is not something that changes by adding SFC or NSH to service chaining or even to non-chaining transparent in-line service delivery. I have trouble seeing how a sentence such as "Service Functions which require fully reassembled transport packets are responsible for such reassembly" would add value. I also don't see how it could go in the NSH document, as it has nothing to do with NSH. Yours, Joel On 4/26/16 5:32 PM, Linda Dunbar wrote: > Joel, > > I agree that some SFs don't need to re-assemble fragmented packets. But I am also aware of SFs that need to process the whole packets. > It would be helpful to describe your assumptions in the draft > > Linda > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, April 26, 2016 3:53 PM > To: Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > You second insertion below seems to assume that service functions require reassembled packets. That is not generally true. I am sure that there are some service functions that require that. But most of them either: > 1) do not require reassembly at all; > 2) can get by with virtual reassembly where they preserve needed state between fragments; > 3) or, even more rarely, can get by with reassembling the first and second packet, and then applying stateful processing thereafter. > > Yours, > Joel > > On 4/26/16 3:20 PM, Linda Dunbar wrote: >> Joel, >> >> Replies are inserted below: >> >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 26, 2016 12:18 PM >> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, that seems an issue >> for the transport protocol. I don't actually object to a sentence, >> but it does not seem that it will accomplish anything. >> >> [Linda] By having this description, you avoid a lot of future >> unnecessary debate about how fragmentation should be processed because >> some people are only thinking about Tunnel induced fragmentation where >> as some other people are thinking of Source induced fragmentation. >> >> >> With regard to packets fragmented by the source, I completely disagree >> with your assertion. If an SFF were to reassemble the packets, that >> would be a violation of its job. There is no reason for an SFF to >> reassemble a packet fragmented by the source. The classifier may have >> to do some interesting things in order to properly classify succeeding >> fragments, but that is an implementation issue (most commonly >> addressed with virtual reassembly, which doe snot delay the >> fragments.) We don't specity that. >> >> If an SF needs to reassemble fragments to do its job, that is up to >> the SF. Some will need to actually reassemble. Some will need to >> perform virtual reassembly, and some will happily process the >> fragments. I can not see what the NSH document could possibly mandate. >> >> [Linda] I said "either SFF or SF" has to re-assemble the fragmented >> packets. I don't have strong opinion on who perform the re-assembling >> job (as long as one of them do). If a set of SFs attached to a SFF are >> not capable of performing the re-assembling and they need the whole >> packet to do inspection, then the SFF don't have any choice. I just >> think that it is necessary to add the description because it can be >> very messy (if not impossible) for SFs to process partial packets. >> >> >> Linda >> >> >> >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> Joel, >>> >>> I think the document should add the description on the following two >>> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a packet >>> fragmentation is caused by transport tunnel (i.e. various >>> encapsulations), the termination point of the transport tunnel is >>> responsible for re-assembling the fragmented pieces of the packet. >>> Since there won't be any SFF nodes in between the Transport Tunnel, >>> the tunnel generated fragmentation does not require any actions by >>> SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on the NSH >>> header): When fragmentation has to be performed for a packet being >>> encapsulated with the NSH header, either the intermediate SFF nodes >>> or the SF nodes have to be able to reassemble the fragmented pieces. >>> >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >>> To: Linda Dunbar; mohamed.boucadair@orange.com >>> ; >> Elzur, Uri; >>> sfc@ietf.org Subject: Re: [sfc] WG last call >>> for draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are referring only to >>> the case of transport generated fragmentation of the outer packet. I >>> had assumed you were not talking about that, since the resulting >>> fragments will not all have NSH headers. As with any tunnel >>> technology, if the tunnel chooses to fragment at its layer, then the >>> tunnel is responsible for reassembly. That would be invisible to the >>> SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>> Agree with Med. >>>> >>>> Even if each fragment piece of a packet with NSH header carries the >>>> NSH header, the intermediate SFF nodes still need to put together >>>> all the fragments together before passing the whole data frame to the SF. >>>> >>>> Linda >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>> On Behalf Of mohamed.boucadair@orange.com Sent: >> Monday, April 25, >>>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-, >>>> >>>> How do you instruct the transport layer to ALWAYS prepend an NSH >>>> header even for fragments? Or you don't care about that? >>>> >>>> Thank you. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Elzur, Uri >>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 16:26 À >>>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org >>>>> Objet >>>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>>> *NOT* a transport, dealing with fragmentation is left to the >>>>> Transport used. >>>>> >>>>> The model I use for NSH, is basically similar to VXLAN . It is an >>>>> overly. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>> On Behalf Of mohamed.boucadair@orange.com Sent: >> Monday, April 25, >>>>> 2016 7:18 AM To: Joel M. Halpern >>>> >; sfc@ietf.org >> >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Joel, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Joel M. Halpern >>>>>> [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 avril 2016 15:48 À : >>>>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>>>>> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> If I am understanding you correctly Med, you are asking that the >>>>>> NSH draft specify how service chaining should cope with packets >>>>>> that have been fragmented? >>>>>> >>>>> >>>>> [Med] To be accurate, I'm asking to assess whether there are >>>>> implications. If there are, then the draft should be updated >>>>> accordingly. >>>>> >>>>>> NSH, and the SFF functionality, does not care. >>>>> >>>>> [Med] I'm not that sure. Some typical implications are listed >>>>> below: >>>>> >>>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>>> didn't maintained a state, subsequent fragments won't be >>>>> appropriately processed. * SFC-aware function: if prepending a >>>>> context information depends on the full packet, not only a fragment. >>>>> >>>>> It just does its job. >>>>> >>>>> [Med] which may be disturbed in some situations as listed in the >>>>> examples above. >>>>> >>>>>> Ingress and intermediate classifiers may cope with fragments in >>>>>> any number of ways. >>>>> Specifying such is clearly out of scope for this draft. >>>>> >>>>> [Med] The purpose is not to specify the internal implementation >>>>> details but the external behavior of the classifier function when >>>>> it comes to handle fragments. That behavior may have an incidence >>>>> on SFF, in particular. The purpose is not to recommend the maximum >>>>> resources to be dedicated to out of order fragments nor the timeout >>>>> to cache those; these considerations are of course out of scope. >>>>> Nevertheless, an implementation should offer a configurable >>>>> parameter so that an operator tweak those according to its context. >>>>> >>>>>> I suppose one could write an informational draft on possible ways >>>>>> of coping. The IETF has not usually published such. >>>>>> Service functions have to cope with fragmented packets just as >>>>>> they had to before the advent of NSH, so describing that is >>>>>> clearly not needed here. >>>>> >>>>> [Med] The advent of NSH has the following implications: * it >>>>> exacerbates fragmentation. Handing over this issue to the transport >>>>> layer may lead to interoperability issues. * the chaining may not >>>>> be efficient if fragments are inappropriately handled. >>>>> >>>>> Introducing NSH should not degrade the overall service compared to >>>>> legacy service deployment schemes. >>>>> >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Re-, >>>>>>> >>>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>>> what to >>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>> issues: >>>>>>> >>>>>>> (1) Fragmentation that is caused by prepending an SFC header. (2) >>>>>>> Handling fragments at the ingress of an SFC-enabled domain. >>>>>>> >>>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>>> explicitly >>>>>> called out in the text (see my first message). >>>>>>> >>>>>>> There are other issues that need to be discussed, e.g., how to >>>>>>> deal with >>>>>> fragments in SFFs/Classifiers? >>>>>>> >>>>>>> It is also "prudent" to check that no issues will be experienced >>>>>>> in SFF >>>>>> to handle fragments. If an SFC header is prepended for all >>>>>> fragments, I'm not sure there >>>>>>> is any particular issue at the SFF level, except if >>>>>>> stripping/adding >>>>>> context TLVs depends on the full packet (not just fragment). It is >>>>>> warranted to consider a little bit this point before declaring >>>>>> there is no issue. >>>>>>> >>>>>>> For point (1), declaring fragmentation out of scope would be >>>>>>> meant that >>>>>> an implementation must be prepared to receive fragments with or >>>>>> without NSH header as this is a decision that is left to the >>>>>> transport encapsulation. This is a requirement per se! >>>>>>> >>>>>>> I won't reiterate all the comments I have about the current >>>>>>> wording of >>>>>> this section. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 >>>>>>>> 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org >>>>>>>> Objet : RE: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> My point is that Fragmentation is yet another transport related >>>>>>>> issue >>>>>> that >>>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>>> it >>>>>> doesn't >>>>>>>> really belong in the draft. We are providing an advice as >>>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>>> you'll find it doesn't even >>>>>> relate >>>>>>>> to it. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com Sent: >> Sunday, April 24, 2016 >>>>>>>> 10:32 PM To: Elzur, Uri >>>>>>> >; Thomas Narten >>>>>> >; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last >>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Uri, >>>>>>>> >>>>>>>> That's another option that needs to be discussed/investigated. >>>>>>>> I'm >>>>>> afraid >>>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>>> text >>>>>> that >>>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>>> >>>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>>> because >>>>>> it >>>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>>> here >>>>>> because >>>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>>> sub-optimal implementations if the sfc information is present >>>>>>>> only in one >>>>>> fragments, >>>>>>>> etc. >>>>>>>> >>>>>>>> My comments are related to the current text in the -04. >>>>>>>> This text needs >>>>>> to >>>>>>>> be fixed somehow. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 avril >>>>>>>>> 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last >>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> I see no need to specify the exact behavior as NSH is transport >>>>>>>>> independent i.e. like NSH interaction with any other Transport >>>>>>>>> eh issue of Fragmentation is to be dealt in a way that matches >>>>>>>>> the mechanisms supported by the Transport used and do not >>>>>>>>> belong in the NSH draft >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>> mohamed.boucadair@orange.com Sent: >> Thursday, April 14, >>>>>>>>> 2016 12:43 AM To: Thomas Narten >>>>>>>> >; sfc@ietf.org >>>>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> R-, >>>>>>>>> >>>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>>> would like to raise this additional one about Section 6. >>>>>>>>> >>>>>>>>> == 6. Fragmentation Considerations >>>>>>>>> >>>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>>> encapsulated packet/frame. This additional information >>>>>>>>> increases >>>>>> the >>>>>>>>> size of the packet. In order the ensure proper forwarding of >>>>>>>>> NSH data, several options for handling fragmentation and >>>>>>>>> re-assembly exist: >>>>>>>>> >>>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH >>>>>>>>> and associated transport packets without requiring >>>>>>>>> fragmentation. >>>>>>>>> >>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>>> an >>>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>>> the >>>>>>>>> required packet size is used. >>>>>>>>> >>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>>> re- >>>>>> assembly >>>>>>>>> in section 5.4. == >>>>>>>>> >>>>>>>>> * The text is weak for a Standard track document that is >>>>>>>>> intended to solve the problem in >>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>> 2.12. >>>>>>>>> There should be a clear behavior to be followed by an >>>>> implementation. >>>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>>> >>>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>>> operations, it does not discuss the treatment of a fragment >>>>>>>>> when received in an SFC domain. IMHO, the draft should also >>>>>>>>> specify the behavior of the Classifier with regards to >>>>>>>>> fragments for the sake of proper SFC operation. Applying >>>>>>>>> classification policies may require the >>>>>>>> full packet, not only a fragment. >>>>>>>>> In particular, dedicated resources should dedicated for >>>>>>>>> handling out of order fragments. Of course, it is out of scope >>>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>>> >>>>>>>>> * If an SFC header is prepended for all fragments, I'm not sure >>>>>>>>> there is any particular issue at the SFF level...except if >>>>>>>>> stripping/adding context TLVs depends on the full packet (not >>>>>>>>> just fragment). It is warranted to consider a little bit this >>>>>>>>> point before declaring there >>>>>> is >>>>>>>> no issue. >>>>>>>>> >>>>>>>>> * The text states "several options". This may be interpreted as >>>>>>>>> if implementing one of them is sufficient...which is not true. >>>>>>>>> The first two points contribute to minimize the fragmentation >>>>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>>>> nested nsh, etc.) >>>>>>>>> >>>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>>> >>>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>>> that it can make use of it. Appropriate MTU configuration >>>>>>>>> should be undertaken in a consistent manner within an SFC >>>>>>>>> domain. The text should be updated to make it is about >>>>>>>>> (consistent) MTU >>>>> configuration. >>>>>>>>> >>>>>>>>> * BTW, shouldn't the text be reworded to recommended to >>>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by >>>>>>>>> at least the length of SFC header + transport header? >>>>>>>>> >>>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>>> Do you assume that all SFC-aware nodes will issue such messages >>>>>>>>> towards other SFC-aware node, arbitrary destination, else? >>>>>>>>> >>>>>>>>> * Bullet 2, I would drop "describes a technique for dynamically >>>>>>>>> discovering the maximum transmission unit >>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>> >>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>> >>>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>>> and one comment: >>>>>>>>> >>>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>>> by the network are passed to their ultimate destinations as >>>>>>>>> such >>>>> (stateless). >>>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>>> (responsible for fragmentation) not passed away. (2) Does the >>>>>>>>> stateful mode require all SFC data plane elements maintain a >>>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>>> domain? >>>>>>>>> >>>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>>> normative reference (not an informative one). I would >>>>>>>>> personally favor removing the reference to LISP (as it is an >>>>>>>>> Experimental RFC). >>>>>>>>> >>>>>>>>> * The security section of the draft may be augmented with >>>>>>>>> informational fragmentation-related pointers to: >>>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny >>>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High >>>>>>>>> Data Rates). >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>>> mohamed.boucadair@orange.com >>>>>>>>>> >> Envoyé : lundi 11 avril >>>>>>>>>> 2016 13:14 À : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear Thomas, all, >>>>>>>>>> >>>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>>> already provided examples of the issues offline as requested >>>>>>>>>> by Martin. >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>>>>>> Envoyé : jeudi 31 mars 2016 04:48 À : >>>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call >>>>>>>>>>> for draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear WG: >>>>>>>>>>> >>>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> The editors of the NSH document have indicated that they have >>>>>>>>>>> addressed all known comments and that there are no open >>>>>>>>>>> issues with the current version of the document. >>>>>>>>>>> >>>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>>> can go directly to the document editors. >>>>>>>>>>> >>>>>>>>>>> We'll also get a brief update from the editors at next week's >>>>>>>>>>> meeting. If there are any remaining issues with the document, >>>>>>>>>>> raising them before the meeting would be especially helpful. >>>>>>>>>>> >>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Apr 26 15:23:45 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 0B16112B02B for ; Tue, 26 Apr 2016 15:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 PhtiBik_0YKl for ; Tue, 26 Apr 2016 15:23:40 -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 1F8ED12D0B0 for ; Tue, 26 Apr 2016 15:23:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIO15158; Tue, 26 Apr 2016 22:22:33 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 26 Apr 2016 23:22:32 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 15:22:26 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfPQIp3nrjaS0+VjDL7mlh8GJ+Er+AwgARg/TCAEFX48IABYBMAgAAQOQCAAAiIAIAAcdWAgAAIhACAAAJAgIAABF8AgAEik2CAAH4AgP//ixXggACSLID//6nIYIAAkmEA//+UMlAADzjUAAANlJ/Q Date: Tue, 26 Apr 2016 22:22:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7D1A2@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> <40836304-a3b3-d16d-c9e5-4951d0100b65@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7D111@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.571FEA69.013A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f00e12aefba01234b913f67e0c7526fe Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 22:23:44 -0000 Joel,=20 Where is a better place to describe how to deal with the Fragmentation indu= ced by NSH header than the NSF document?=20 The NSH header induced fragmentation is very different from Tunnel encapsul= ation induced fragmentation in the following aspects: - Tunnel induced fragmented pieces of a packet will not be processed by any= intermediate nodes other than forwarding. As all fragmented pieces have th= e Dest/Source, all the intermediate nodes can forward based on the Dst/Src.= =20 - NSH induced fragmented pieces of a packet will be processed by SF in the = middle. Some of the SFs do need to inspect the whole packet or multiple fra= gmented pieces --> warrant partial or whole re-assembling.=20 Therefore, I disagree with your statement of "NSH header induced fragmentat= ion has nothing to do with NSH".=20 Linda=20 =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, April 26, 2016 4:43 PM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt The draft assumes that SFF are network elements. Network elements do not n= ormally reassemble packets not addressed to themselves. As such, the assum= ption you refer to is the norm. Yes, some SF need to reassemble packets. We presume that functions which n= eed to do somethign will do so. This is not something that changes by addi= ng SFC or NSH to service chaining or even to non-chaining transparent in-li= ne service delivery. I have trouble seeing how a sentence such as "Service Functions which requi= re fully reassembled transport packets are responsible for such reassembly"= would add value. I also don't see how it could go in the NSH document, as= it has nothing to do with NSH. Yours, Joel On 4/26/16 5:32 PM, Linda Dunbar wrote: > Joel, > > I agree that some SFs don't need to re-assemble fragmented packets. But I= am also aware of SFs that need to process the whole packets. > It would be helpful to describe your assumptions in the draft > > Linda > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, April 26, 2016 3:53 PM > To: Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > You second insertion below seems to assume that service functions require= reassembled packets. That is not generally true. I am sure that there ar= e some service functions that require that. But most of them either: > 1) do not require reassembly at all; > 2) can get by with virtual reassembly where they preserve needed state=20 > between fragments; > 3) or, even more rarely, can get by with reassembling the first and secon= d packet, and then applying stateful processing thereafter. > > Yours, > Joel > > On 4/26/16 3:20 PM, Linda Dunbar wrote: >> Joel, >> >> Replies are inserted below: >> >> >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, April 26, 2016 12:18 PM >> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;=20 >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, that seems an issue=20 >> for the transport protocol. I don't actually object to a sentence,=20 >> but it does not seem that it will accomplish anything. >> >> [Linda] By having this description, you avoid a lot of future=20 >> unnecessary debate about how fragmentation should be processed=20 >> because some people are only thinking about Tunnel induced=20 >> fragmentation where as some other people are thinking of Source induced = fragmentation. >> >> >> With regard to packets fragmented by the source, I completely=20 >> disagree with your assertion. If an SFF were to reassemble the=20 >> packets, that would be a violation of its job. There is no reason=20 >> for an SFF to reassemble a packet fragmented by the source. The=20 >> classifier may have to do some interesting things in order to=20 >> properly classify succeeding fragments, but that is an implementation=20 >> issue (most commonly addressed with virtual reassembly, which doe=20 >> snot delay the >> fragments.) We don't specity that. >> >> If an SF needs to reassemble fragments to do its job, that is up to=20 >> the SF. Some will need to actually reassemble. Some will need to=20 >> perform virtual reassembly, and some will happily process the=20 >> fragments. I can not see what the NSH document could possibly mandate. >> >> [Linda] I said "either SFF or SF" has to re-assemble the fragmented=20 >> packets. I don't have strong opinion on who perform the re-assembling=20 >> job (as long as one of them do). If a set of SFs attached to a SFF=20 >> are not capable of performing the re-assembling and they need the=20 >> whole packet to do inspection, then the SFF don't have any choice. I=20 >> just think that it is necessary to add the description because it can=20 >> be very messy (if not impossible) for SFs to process partial packets. >> >> >> Linda >> >> >> >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> Joel, >>> >>> I think the document should add the description on the following two=20 >>> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a packet=20 >>> fragmentation is caused by transport tunnel (i.e. various=20 >>> encapsulations), the termination point of the transport tunnel is=20 >>> responsible for re-assembling the fragmented pieces of the packet. >>> Since there won't be any SFF nodes in between the Transport Tunnel,=20 >>> the tunnel generated fragmentation does not require any actions by=20 >>> SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on the NSH >>> header): When fragmentation has to be performed for a packet being=20 >>> encapsulated with the NSH header, either the intermediate SFF nodes=20 >>> or the SF nodes have to be able to reassemble the fragmented pieces. >>> >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern=20 >>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >>> To: Linda Dunbar; mohamed.boucadair@orange.com=20 >>> ; >> Elzur, Uri; >>> sfc@ietf.org Subject: Re: [sfc] WG last call=20 >>> for draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are referring only to=20 >>> the case of transport generated fragmentation of the outer packet. =20 >>> I had assumed you were not talking about that, since the resulting=20 >>> fragments will not all have NSH headers. As with any tunnel=20 >>> technology, if the tunnel chooses to fragment at its layer, then the=20 >>> tunnel is responsible for reassembly. That would be invisible to=20 >>> the SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>> Agree with Med. >>>> >>>> Even if each fragment piece of a packet with NSH header carries the=20 >>>> NSH header, the intermediate SFF nodes still need to put together=20 >>>> all the fragments together before passing the whole data frame to the = SF. >>>> >>>> Linda >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of mohamed.boucadair@orange.com Sent: >> Monday, April 25, >>>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-, >>>> >>>> How do you instruct the transport layer to ALWAYS prepend an NSH=20 >>>> header even for fragments? Or you don't care about that? >>>> >>>> Thank you. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 >>>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org=20 >>>>> Objet >>>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>>> *NOT* a transport, dealing with fragmentation is left to the=20 >>>>> Transport used. >>>>> >>>>> The model I use for NSH, is basically similar to VXLAN . It is an=20 >>>>> overly. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>>> On Behalf Of mohamed.boucadair@orange.com Sent: >> Monday, April 25, >>>>> 2016 7:18 AM To: Joel M. Halpern >>>> >; sfc@ietf.org >> >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Joel, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Joel M. Halpern=20 >>>>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 = =C0 : >>>>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org =20 >>>>>> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> If I am understanding you correctly Med, you are asking that the=20 >>>>>> NSH draft specify how service chaining should cope with packets=20 >>>>>> that have been fragmented? >>>>>> >>>>> >>>>> [Med] To be accurate, I'm asking to assess whether there are=20 >>>>> implications. If there are, then the draft should be updated=20 >>>>> accordingly. >>>>> >>>>>> NSH, and the SFF functionality, does not care. >>>>> >>>>> [Med] I'm not that sure. Some typical implications are listed >>>>> below: >>>>> >>>>> * SFF: If the NSH header is present only in the a fragment but SFF=20 >>>>> didn't maintained a state, subsequent fragments won't be=20 >>>>> appropriately processed. * SFC-aware function: if prepending a=20 >>>>> context information depends on the full packet, not only a fragment. >>>>> >>>>> It just does its job. >>>>> >>>>> [Med] which may be disturbed in some situations as listed in the=20 >>>>> examples above. >>>>> >>>>>> Ingress and intermediate classifiers may cope with fragments in=20 >>>>>> any number of ways. >>>>> Specifying such is clearly out of scope for this draft. >>>>> >>>>> [Med] The purpose is not to specify the internal implementation=20 >>>>> details but the external behavior of the classifier function when=20 >>>>> it comes to handle fragments. That behavior may have an incidence=20 >>>>> on SFF, in particular. The purpose is not to recommend the maximum=20 >>>>> resources to be dedicated to out of order fragments nor the=20 >>>>> timeout to cache those; these considerations are of course out of sco= pe. >>>>> Nevertheless, an implementation should offer a configurable=20 >>>>> parameter so that an operator tweak those according to its context. >>>>> >>>>>> I suppose one could write an informational draft on possible ways=20 >>>>>> of coping. The IETF has not usually published such. >>>>>> Service functions have to cope with fragmented packets just as=20 >>>>>> they had to before the advent of NSH, so describing that is=20 >>>>>> clearly not needed here. >>>>> >>>>> [Med] The advent of NSH has the following implications: * it=20 >>>>> exacerbates fragmentation. Handing over this issue to the=20 >>>>> transport layer may lead to interoperability issues. * the=20 >>>>> chaining may not be efficient if fragments are inappropriately handle= d. >>>>> >>>>> Introducing NSH should not degrade the overall service compared to=20 >>>>> legacy service deployment schemes. >>>>> >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Re-, >>>>>>> >>>>>>> I hear you, but my comment is that we need, as a WG, to decide=20 >>>>>>> what to >>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>> issues: >>>>>>> >>>>>>> (1) Fragmentation that is caused by prepending an SFC header.=20 >>>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>>> >>>>>>> Increasing the MTU is for sure a recommendation is to be=20 >>>>>>> explicitly >>>>>> called out in the text (see my first message). >>>>>>> >>>>>>> There are other issues that need to be discussed, e.g., how to=20 >>>>>>> deal with >>>>>> fragments in SFFs/Classifiers? >>>>>>> >>>>>>> It is also "prudent" to check that no issues will be experienced=20 >>>>>>> in SFF >>>>>> to handle fragments. If an SFC header is prepended for all=20 >>>>>> fragments, I'm not sure there >>>>>>> is any particular issue at the SFF level, except if=20 >>>>>>> stripping/adding >>>>>> context TLVs depends on the full packet (not just fragment). It=20 >>>>>> is warranted to consider a little bit this point before declaring=20 >>>>>> there is no issue. >>>>>>> >>>>>>> For point (1), declaring fragmentation out of scope would be=20 >>>>>>> meant that >>>>>> an implementation must be prepared to receive fragments with or=20 >>>>>> without NSH header as this is a decision that is left to the=20 >>>>>> transport encapsulation. This is a requirement per se! >>>>>>> >>>>>>> I won't reiterate all the comments I have about the current=20 >>>>>>> wording of >>>>>> this section. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 >>>>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last=20 >>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> My point is that Fragmentation is yet another transport related=20 >>>>>>>> issue >>>>>> that >>>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so=20 >>>>>>>> it >>>>>> doesn't >>>>>>>> really belong in the draft. We are providing an advice as=20 >>>>>>>> extending the size of the packet may lead to fragmentation, but=20 >>>>>>>> as you check RFC 7348 VxLAN, which my create the same issue,=20 >>>>>>>> you'll find it doesn't even >>>>>> relate >>>>>>>> to it. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc=20 >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>>> mohamed.boucadair@orange.com = Sent: >> Sunday, April 24, 2016 >>>>>>>> 10:32 PM To: Elzur, Uri >>>>>>> >; Thomas Narten >>>>>> >; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last=20 >>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Uri, >>>>>>>> >>>>>>>> That's another option that needs to be discussed/investigated. >>>>>>>> I'm >>>>>> afraid >>>>>>>> this is not the rationale adopted in -04 since it includes some=20 >>>>>>>> text >>>>>> that >>>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>>> >>>>>>>> BTW, saying that nsh does not need to deal with fragmentation=20 >>>>>>>> because >>>>>> it >>>>>>>> is transport-independent is not IMHO a good strategy to adopt=20 >>>>>>>> here >>>>>> because >>>>>>>> it opens the door for interoperable issues, it may lead to=20 >>>>>>>> sub-optimal implementations if the sfc information is present=20 >>>>>>>> only in one >>>>>> fragments, >>>>>>>> etc. >>>>>>>> >>>>>>>> My comments are related to the current text in the -04. >>>>>>>> This text needs >>>>>> to >>>>>>>> be fixed somehow. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril >>>>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last=20 >>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> I see no need to specify the exact behavior as NSH is=20 >>>>>>>>> transport independent i.e. like NSH interaction with any other=20 >>>>>>>>> Transport eh issue of Fragmentation is to be dealt in a way=20 >>>>>>>>> that matches the mechanisms supported by the Transport used=20 >>>>>>>>> and do not belong in the NSH draft >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc=20 >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>>>> mohamed.boucadair@orange.com Sent: >> Thursday, April 14, >>>>>>>>> 2016 12:43 AM To: Thomas Narten >>>>>>>> >; sfc@ietf.org=20 >>>>>>>>> >>>>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> R-, >>>>>>>>> >>>>>>>>> In addition to other pending issues raised for this draft, I=20 >>>>>>>>> would like to raise this additional one about Section 6. >>>>>>>>> >>>>>>>>> =3D=3D 6. Fragmentation Considerations >>>>>>>>> >>>>>>>>> NSH and the associated transport header are "added" to the=20 >>>>>>>>> encapsulated packet/frame. This additional information=20 >>>>>>>>> increases >>>>>> the >>>>>>>>> size of the packet. In order the ensure proper forwarding of=20 >>>>>>>>> NSH data, several options for handling fragmentation and=20 >>>>>>>>> re-assembly exist: >>>>>>>>> >>>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH=20 >>>>>>>>> and associated transport packets without requiring=20 >>>>>>>>> fragmentation. >>>>>>>>> >>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for=20 >>>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>>> an >>>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>>> the >>>>>>>>> required packet size is used. >>>>>>>>> >>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>>> re- >>>>>> assembly >>>>>>>>> in section 5.4. =3D=3D >>>>>>>>> >>>>>>>>> * The text is weak for a Standard track document that is=20 >>>>>>>>> intended to solve the problem in >>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>> 2.12. >>>>>>>>> There should be a clear behavior to be followed by an >>>>> implementation. >>>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>>> >>>>>>>>> * The text covers only fragmentation when it is induced by SFC=20 >>>>>>>>> operations, it does not discuss the treatment of a fragment=20 >>>>>>>>> when received in an SFC domain. IMHO, the draft should also=20 >>>>>>>>> specify the behavior of the Classifier with regards to=20 >>>>>>>>> fragments for the sake of proper SFC operation. Applying=20 >>>>>>>>> classification policies may require the >>>>>>>> full packet, not only a fragment. >>>>>>>>> In particular, dedicated resources should dedicated for=20 >>>>>>>>> handling out of order fragments. Of course, it is out of scope=20 >>>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>>> >>>>>>>>> * If an SFC header is prepended for all fragments, I'm not=20 >>>>>>>>> sure there is any particular issue at the SFF level...except=20 >>>>>>>>> if stripping/adding context TLVs depends on the full packet=20 >>>>>>>>> (not just fragment). It is warranted to consider a little bit=20 >>>>>>>>> this point before declaring there >>>>>> is >>>>>>>> no issue. >>>>>>>>> >>>>>>>>> * The text states "several options". This may be interpreted=20 >>>>>>>>> as if implementing one of them is sufficient...which is not true. >>>>>>>>> The first two points contribute to minimize the fragmentation=20 >>>>>>>>> risk, but fragmentation may still be experienced (e.g., other=20 >>>>>>>>> shims are prepended by other nodes for some other purposes,=20 >>>>>>>>> nested nsh, etc.) >>>>>>>>> >>>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>>> >>>>>>>>> * The support of jumbo frames by a router/device does not mean=20 >>>>>>>>> that it can make use of it. Appropriate MTU configuration=20 >>>>>>>>> should be undertaken in a consistent manner within an SFC=20 >>>>>>>>> domain. The text should be updated to make it is about >>>>>>>>> (consistent) MTU >>>>> configuration. >>>>>>>>> >>>>>>>>> * BTW, shouldn't the text be reworded to recommended to=20 >>>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by=20 >>>>>>>>> at least the length of SFC header + transport header? >>>>>>>>> >>>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>>> Do you assume that all SFC-aware nodes will issue such=20 >>>>>>>>> messages towards other SFC-aware node, arbitrary destination, els= e? >>>>>>>>> >>>>>>>>> * Bullet 2, I would drop "describes a technique for=20 >>>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>> >>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>> >>>>>>>>> * The reference to the LISP specification raises two concerns=20 >>>>>>>>> and one comment: >>>>>>>>> >>>>>>>>> (1) I don't think it is a good approach that fragments induced=20 >>>>>>>>> by the network are passed to their ultimate destinations as=20 >>>>>>>>> such >>>>> (stateless). >>>>>>>>> IMO, reassembly should be done within the SFC domain=20 >>>>>>>>> (responsible for fragmentation) not passed away. (2) Does the=20 >>>>>>>>> stateful mode require all SFC data plane elements maintain a=20 >>>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>>> domain? >>>>>>>>> >>>>>>>>> The current text suggests that [RFC6830] should be listed as=20 >>>>>>>>> normative reference (not an informative one). I would=20 >>>>>>>>> personally favor removing the reference to LISP (as it is an=20 >>>>>>>>> Experimental RFC). >>>>>>>>> >>>>>>>>> * The security section of the draft may be augmented with=20 >>>>>>>>> informational fragmentation-related pointers to: >>>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment=20 >>>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny=20 >>>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High=20 >>>>>>>>> Data Rates). >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de=20 >>>>>>>>>> mohamed.boucadair@orange.com=20 >>>>>>>>>> >> Envoy=E9 : lundi 11 avril >>>>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear Thomas, all, >>>>>>>>>> >>>>>>>>>> As I mentioned during the meeting, there are several issues=20 >>>>>>>>>> that are not covered in the last version of the draft. I=20 >>>>>>>>>> already provided examples of the issues offline as requested=20 >>>>>>>>>> by Martin. >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 >>>>>>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : >>>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last=20 >>>>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear WG: >>>>>>>>>>> >>>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 >>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> The editors of the NSH document have indicated that they have >>>>>>>>>>> addressed all known comments and that there are no open=20 >>>>>>>>>>> issues with the current version of the document. >>>>>>>>>>> >>>>>>>>>>> Substantive comments to the list please, editorial comments=20 >>>>>>>>>>> can go directly to the document editors. >>>>>>>>>>> >>>>>>>>>>> We'll also get a brief update from the editors at next=20 >>>>>>>>>>> week's meeting. If there are any remaining issues with the=20 >>>>>>>>>>> document, raising them before the meeting would be especially h= elpful. >>>>>>>>>>> >>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>>>> list sfc@ietf.org =20 >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>>> list sfc@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>> list sfc@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>> list sfc@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing list=20 >>>>>>> sfc@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org =20 >>>> 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 Tue Apr 26 15:29:21 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 5CAA512D0B0 for ; Tue, 26 Apr 2016 15:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 17Dee0QubKwV for ; Tue, 26 Apr 2016 15:29:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A655812D0FA for ; Tue, 26 Apr 2016 15:29:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6FD50258B35; Tue, 26 Apr 2016 15:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461709757; bh=XeogAdZToVpzG1SqZ9RLov29qGIZSkj/J2YaxfX8sMo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dN6gDEbtpnc7yDfA0mrzZ9nUk62MJQsobnPl+VwAp36z2GrCQCg+dJBFovF9VciOk 2sbgOCieZiXAbEfimCkjbAqmweov7bvA7044SpiISzE5/UJHn5w7pkcxTfgOM7i5/H F8e23GZvBNDw15R5LJGQx1xoZrbi9vrx/FpNCD6c= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A209C24E0BB; Tue, 26 Apr 2016 15:29:16 -0700 (PDT) To: Linda Dunbar , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657E7CFA1@dfweml501-mbb> <40836304-a3b3-d16d-c9e5-4951d0100b65@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7D111@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657E7D1A2@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: Date: Tue, 26 Apr 2016 18:29:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7D1A2@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 26 Apr 2016 22:29:20 -0000 That is not what I said. There are two different cases. One is Transport fragmentation. And one is source fragmentation. You argued that source fragmentation needs to be discussed in the NSH document. I pointed out that the requirement you claim is not wide-spread, and that for the cases where it exists, it exists before SFC. So that does not seem to be an NSH problem at all. With regard to Tunnel fragmentation, the question of where to describe all the possible issues is more complex. There is text in section 6 of the document. Beyond that, the problem is that the mechanism needed depends upon the underlying packet and the transport technology. It also depends upon whether the service chaining environment can enable a larger MTU, and thereby avoid all of the problems. I will grant that this problem is not unrelated to NSH. However, given our requirement to be transport agnostic, I am confused as to why anything more than what is stated in section 6 is needed. Yours, Joel On 4/26/16 6:22 PM, Linda Dunbar wrote: > Joel, > > Where is a better place to describe how to deal with the Fragmentation induced by NSH header than the NSF document? > > The NSH header induced fragmentation is very different from Tunnel encapsulation induced fragmentation in the following aspects: > > - Tunnel induced fragmented pieces of a packet will not be processed by any intermediate nodes other than forwarding. As all fragmented pieces have the Dest/Source, all the intermediate nodes can forward based on the Dst/Src. > > - NSH induced fragmented pieces of a packet will be processed by SF in the middle. Some of the SFs do need to inspect the whole packet or multiple fragmented pieces --> warrant partial or whole re-assembling. > > > Therefore, I disagree with your statement of "NSH header induced fragmentation has nothing to do with NSH". > > Linda > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, April 26, 2016 4:43 PM > To: Linda Dunbar; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > The draft assumes that SFF are network elements. Network elements do not normally reassemble packets not addressed to themselves. As such, the assumption you refer to is the norm. > > Yes, some SF need to reassemble packets. We presume that functions which need to do somethign will do so. This is not something that changes by adding SFC or NSH to service chaining or even to non-chaining transparent in-line service delivery. > > I have trouble seeing how a sentence such as "Service Functions which require fully reassembled transport packets are responsible for such reassembly" would add value. I also don't see how it could go in the NSH document, as it has nothing to do with NSH. > > Yours, > Joel > > On 4/26/16 5:32 PM, Linda Dunbar wrote: >> Joel, >> >> I agree that some SFs don't need to re-assemble fragmented packets. But I am also aware of SFs that need to process the whole packets. >> It would be helpful to describe your assumptions in the draft >> >> Linda >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Tuesday, April 26, 2016 3:53 PM >> To: Linda Dunbar; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> You second insertion below seems to assume that service functions require reassembled packets. That is not generally true. I am sure that there are some service functions that require that. But most of them either: >> 1) do not require reassembly at all; >> 2) can get by with virtual reassembly where they preserve needed state >> between fragments; >> 3) or, even more rarely, can get by with reassembling the first and second packet, and then applying stateful processing thereafter. >> >> Yours, >> Joel >> >> On 4/26/16 3:20 PM, Linda Dunbar wrote: >>> Joel, >>> >>> Replies are inserted below: >>> >>> >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Tuesday, April 26, 2016 12:18 PM >>> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >>> sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> With regard to Transport tunnel fragementation, that seems an issue >>> for the transport protocol. I don't actually object to a sentence, >>> but it does not seem that it will accomplish anything. >>> >>> [Linda] By having this description, you avoid a lot of future >>> unnecessary debate about how fragmentation should be processed >>> because some people are only thinking about Tunnel induced >>> fragmentation where as some other people are thinking of Source induced fragmentation. >>> >>> >>> With regard to packets fragmented by the source, I completely >>> disagree with your assertion. If an SFF were to reassemble the >>> packets, that would be a violation of its job. There is no reason >>> for an SFF to reassemble a packet fragmented by the source. The >>> classifier may have to do some interesting things in order to >>> properly classify succeeding fragments, but that is an implementation >>> issue (most commonly addressed with virtual reassembly, which doe >>> snot delay the >>> fragments.) We don't specity that. >>> >>> If an SF needs to reassemble fragments to do its job, that is up to >>> the SF. Some will need to actually reassemble. Some will need to >>> perform virtual reassembly, and some will happily process the >>> fragments. I can not see what the NSH document could possibly mandate. >>> >>> [Linda] I said "either SFF or SF" has to re-assemble the fragmented >>> packets. I don't have strong opinion on who perform the re-assembling >>> job (as long as one of them do). If a set of SFs attached to a SFF >>> are not capable of performing the re-assembling and they need the >>> whole packet to do inspection, then the SFF don't have any choice. I >>> just think that it is necessary to add the description because it can >>> be very messy (if not impossible) for SFs to process partial packets. >>> >>> >>> Linda >>> >>> >>> >>> >>> Yours, >>> Joel >>> >>> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>>> Joel, >>>> >>>> I think the document should add the description on the following two >>>> fragmentation scenarios: >>>> >>>> - Transport tunnel generated fragmentation: When a packet >>>> fragmentation is caused by transport tunnel (i.e. various >>>> encapsulations), the termination point of the transport tunnel is >>>> responsible for re-assembling the fragmented pieces of the packet. >>>> Since there won't be any SFF nodes in between the Transport Tunnel, >>>> the tunnel generated fragmentation does not require any actions by >>>> SFF nodes or SF nodes. >>>> >>>> >>>> - Source node generated fragmentation (after adding on the NSH >>>> header): When fragmentation has to be performed for a packet being >>>> encapsulated with the NSH header, either the intermediate SFF nodes >>>> or the SF nodes have to be able to reassemble the fragmented pieces. >>>> >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> Linda >>>> >>>> -----Original Message----- From: Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >>>> To: Linda Dunbar; mohamed.boucadair@orange.com >>>> ; >>> Elzur, Uri; >>>> sfc@ietf.org Subject: Re: [sfc] WG last call >>>> for draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-reading your note, it is possible that you are referring only to >>>> the case of transport generated fragmentation of the outer packet. >>>> I had assumed you were not talking about that, since the resulting >>>> fragments will not all have NSH headers. As with any tunnel >>>> technology, if the tunnel chooses to fragment at its layer, then the >>>> tunnel is responsible for reassembly. That would be invisible to >>>> the SFF. >>>> >>>> Yours, Joel >>>> >>>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>>> Agree with Med. >>>>> >>>>> Even if each fragment piece of a packet with NSH header carries the >>>>> NSH header, the intermediate SFF nodes still need to put together >>>>> all the fragments together before passing the whole data frame to the SF. >>>>> >>>>> Linda >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>> On Behalf Of mohamed.boucadair@orange.com Sent: >>> Monday, April 25, >>>>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Re-, >>>>> >>>>> How do you instruct the transport layer to ALWAYS prepend an NSH >>>>> header even for fragments? Or you don't care about that? >>>>> >>>>> Thank you. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 16:26 À >>>>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org >>>>>> Objet >>>>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>>>> *NOT* a transport, dealing with fragmentation is left to the >>>>>> Transport used. >>>>>> >>>>>> The model I use for NSH, is basically similar to VXLAN . It is an >>>>>> overly. >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>>> On Behalf Of mohamed.boucadair@orange.com Sent: >>> Monday, April 25, >>>>>> 2016 7:18 AM To: Joel M. Halpern >>>>> >; sfc@ietf.org >>> >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Joel, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>>> -----Message d'origine----- De : Joel M. Halpern >>>>>>> [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 avril 2016 15:48 À : >>>>>>> BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>>>>>> Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> If I am understanding you correctly Med, you are asking that the >>>>>>> NSH draft specify how service chaining should cope with packets >>>>>>> that have been fragmented? >>>>>>> >>>>>> >>>>>> [Med] To be accurate, I'm asking to assess whether there are >>>>>> implications. If there are, then the draft should be updated >>>>>> accordingly. >>>>>> >>>>>>> NSH, and the SFF functionality, does not care. >>>>>> >>>>>> [Med] I'm not that sure. Some typical implications are listed >>>>>> below: >>>>>> >>>>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>>>> didn't maintained a state, subsequent fragments won't be >>>>>> appropriately processed. * SFC-aware function: if prepending a >>>>>> context information depends on the full packet, not only a fragment. >>>>>> >>>>>> It just does its job. >>>>>> >>>>>> [Med] which may be disturbed in some situations as listed in the >>>>>> examples above. >>>>>> >>>>>>> Ingress and intermediate classifiers may cope with fragments in >>>>>>> any number of ways. >>>>>> Specifying such is clearly out of scope for this draft. >>>>>> >>>>>> [Med] The purpose is not to specify the internal implementation >>>>>> details but the external behavior of the classifier function when >>>>>> it comes to handle fragments. That behavior may have an incidence >>>>>> on SFF, in particular. The purpose is not to recommend the maximum >>>>>> resources to be dedicated to out of order fragments nor the >>>>>> timeout to cache those; these considerations are of course out of scope. >>>>>> Nevertheless, an implementation should offer a configurable >>>>>> parameter so that an operator tweak those according to its context. >>>>>> >>>>>>> I suppose one could write an informational draft on possible ways >>>>>>> of coping. The IETF has not usually published such. >>>>>>> Service functions have to cope with fragmented packets just as >>>>>>> they had to before the advent of NSH, so describing that is >>>>>>> clearly not needed here. >>>>>> >>>>>> [Med] The advent of NSH has the following implications: * it >>>>>> exacerbates fragmentation. Handing over this issue to the >>>>>> transport layer may lead to interoperability issues. * the >>>>>> chaining may not be efficient if fragments are inappropriately handled. >>>>>> >>>>>> Introducing NSH should not degrade the overall service compared to >>>>>> legacy service deployment schemes. >>>>>> >>>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>>> Re-, >>>>>>>> >>>>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>>>> what to >>>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>>> issues: >>>>>>>> >>>>>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>>>> >>>>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>>>> explicitly >>>>>>> called out in the text (see my first message). >>>>>>>> >>>>>>>> There are other issues that need to be discussed, e.g., how to >>>>>>>> deal with >>>>>>> fragments in SFFs/Classifiers? >>>>>>>> >>>>>>>> It is also "prudent" to check that no issues will be experienced >>>>>>>> in SFF >>>>>>> to handle fragments. If an SFC header is prepended for all >>>>>>> fragments, I'm not sure there >>>>>>>> is any particular issue at the SFF level, except if >>>>>>>> stripping/adding >>>>>>> context TLVs depends on the full packet (not just fragment). It >>>>>>> is warranted to consider a little bit this point before declaring >>>>>>> there is no issue. >>>>>>>> >>>>>>>> For point (1), declaring fragmentation out of scope would be >>>>>>>> meant that >>>>>>> an implementation must be prepared to receive fragments with or >>>>>>> without NSH header as this is a decision that is left to the >>>>>>> transport encapsulation. This is a requirement per se! >>>>>>>> >>>>>>>> I won't reiterate all the comments I have about the current >>>>>>>> wording of >>>>>>> this section. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 >>>>>>>>> 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last >>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> My point is that Fragmentation is yet another transport related >>>>>>>>> issue >>>>>>> that >>>>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>>>> it >>>>>>> doesn't >>>>>>>>> really belong in the draft. We are providing an advice as >>>>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>>>> you'll find it doesn't even >>>>>>> relate >>>>>>>>> to it. >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>> mohamed.boucadair@orange.com Sent: >>> Sunday, April 24, 2016 >>>>>>>>> 10:32 PM To: Elzur, Uri >>>>>>>> >; Thomas Narten >>>>>>> >; >>>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last >>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Uri, >>>>>>>>> >>>>>>>>> That's another option that needs to be discussed/investigated. >>>>>>>>> I'm >>>>>>> afraid >>>>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>>>> text >>>>>>> that >>>>>>>>> is far to be sufficient to ensure interoperable implementations. >>>>>>>>> >>>>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>>>> because >>>>>>> it >>>>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>>>> here >>>>>>> because >>>>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>>>> sub-optimal implementations if the sfc information is present >>>>>>>>> only in one >>>>>>> fragments, >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> My comments are related to the current text in the -04. >>>>>>>>> This text needs >>>>>>> to >>>>>>>>> be fixed somehow. >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 avril >>>>>>>>>> 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last >>>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Hi Med >>>>>>>>>> >>>>>>>>>> I see no need to specify the exact behavior as NSH is >>>>>>>>>> transport independent i.e. like NSH interaction with any other >>>>>>>>>> Transport eh issue of Fragmentation is to be dealt in a way >>>>>>>>>> that matches the mechanisms supported by the Transport used >>>>>>>>>> and do not belong in the NSH draft >>>>>>>>>> >>>>>>>>>> Thx >>>>>>>>>> >>>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- From: sfc >>>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>>> mohamed.boucadair@orange.com Sent: >>> Thursday, April 14, >>>>>>>>>> 2016 12:43 AM To: Thomas Narten >>>>>>>>> >; sfc@ietf.org >>>>>>>>>> >>>>>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> R-, >>>>>>>>>> >>>>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>>>> would like to raise this additional one about Section 6. >>>>>>>>>> >>>>>>>>>> == 6. Fragmentation Considerations >>>>>>>>>> >>>>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>>>> encapsulated packet/frame. This additional information >>>>>>>>>> increases >>>>>>> the >>>>>>>>>> size of the packet. In order the ensure proper forwarding of >>>>>>>>>> NSH data, several options for handling fragmentation and >>>>>>>>>> re-assembly exist: >>>>>>>>>> >>>>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH >>>>>>>>>> and associated transport packets without requiring >>>>>>>>>> fragmentation. >>>>>>>>>> >>>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>>>> an >>>>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>>>> the >>>>>>>>>> required packet size is used. >>>>>>>>>> >>>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>>>> re- >>>>>>> assembly >>>>>>>>>> in section 5.4. == >>>>>>>>>> >>>>>>>>>> * The text is weak for a Standard track document that is >>>>>>>>>> intended to solve the problem in >>>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>>> 2.12. >>>>>>>>>> There should be a clear behavior to be followed by an >>>>>> implementation. >>>>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>>>> >>>>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>>>> operations, it does not discuss the treatment of a fragment >>>>>>>>>> when received in an SFC domain. IMHO, the draft should also >>>>>>>>>> specify the behavior of the Classifier with regards to >>>>>>>>>> fragments for the sake of proper SFC operation. Applying >>>>>>>>>> classification policies may require the >>>>>>>>> full packet, not only a fragment. >>>>>>>>>> In particular, dedicated resources should dedicated for >>>>>>>>>> handling out of order fragments. Of course, it is out of scope >>>>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>>>> >>>>>>>>>> * If an SFC header is prepended for all fragments, I'm not >>>>>>>>>> sure there is any particular issue at the SFF level...except >>>>>>>>>> if stripping/adding context TLVs depends on the full packet >>>>>>>>>> (not just fragment). It is warranted to consider a little bit >>>>>>>>>> this point before declaring there >>>>>>> is >>>>>>>>> no issue. >>>>>>>>>> >>>>>>>>>> * The text states "several options". This may be interpreted >>>>>>>>>> as if implementing one of them is sufficient...which is not true. >>>>>>>>>> The first two points contribute to minimize the fragmentation >>>>>>>>>> risk, but fragmentation may still be experienced (e.g., other >>>>>>>>>> shims are prepended by other nodes for some other purposes, >>>>>>>>>> nested nsh, etc.) >>>>>>>>>> >>>>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>>>> >>>>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>>>> that it can make use of it. Appropriate MTU configuration >>>>>>>>>> should be undertaken in a consistent manner within an SFC >>>>>>>>>> domain. The text should be updated to make it is about >>>>>>>>>> (consistent) MTU >>>>>> configuration. >>>>>>>>>> >>>>>>>>>> * BTW, shouldn't the text be reworded to recommended to >>>>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by >>>>>>>>>> at least the length of SFC header + transport header? >>>>>>>>>> >>>>>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? >>>>>>>>>> Do you assume that all SFC-aware nodes will issue such >>>>>>>>>> messages towards other SFC-aware node, arbitrary destination, else? >>>>>>>>>> >>>>>>>>>> * Bullet 2, I would drop "describes a technique for >>>>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>>> >>>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>>> >>>>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>>>> and one comment: >>>>>>>>>> >>>>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>>>> by the network are passed to their ultimate destinations as >>>>>>>>>> such >>>>>> (stateless). >>>>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>>>> (responsible for fragmentation) not passed away. (2) Does the >>>>>>>>>> stateful mode require all SFC data plane elements maintain a >>>>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>>>> domain? >>>>>>>>>> >>>>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>>>> normative reference (not an informative one). I would >>>>>>>>>> personally favor removing the reference to LISP (as it is an >>>>>>>>>> Experimental RFC). >>>>>>>>>> >>>>>>>>>> * The security section of the draft may be augmented with >>>>>>>>>> informational fragmentation-related pointers to: >>>>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny >>>>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High >>>>>>>>>> Data Rates). >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>>>> mohamed.boucadair@orange.com >>>>>>>>>>> >>> Envoyé : lundi 11 avril >>>>>>>>>>> 2016 13:14 À : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear Thomas, all, >>>>>>>>>>> >>>>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>>>> already provided examples of the issues offline as requested >>>>>>>>>>> by Martin. >>>>>>>>>>> >>>>>>>>>>> Cheers, Med >>>>>>>>>>> >>>>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>>>>>>> Envoyé : jeudi 31 mars 2016 04:48 À : >>>>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last >>>>>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>>>> >>>>>>>>>>>> Dear WG: >>>>>>>>>>>> >>>>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> The editors of the NSH document have indicated that they have >>>>>>>>>>>> addressed all known comments and that there are no open >>>>>>>>>>>> issues with the current version of the document. >>>>>>>>>>>> >>>>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>>>> can go directly to the document editors. >>>>>>>>>>>> >>>>>>>>>>>> We'll also get a brief update from the editors at next >>>>>>>>>>>> week's meeting. If there are any remaining issues with the >>>>>>>>>>>> document, raising them before the meeting would be especially helpful. >>>>>>>>>>>> >>>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>> list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing list >>>>>>>> sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Apr 26 21:29:16 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 0A80E12D5DC for ; Tue, 26 Apr 2016 21:29:10 -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 HKVc0ubJvkGg for ; Tue, 26 Apr 2016 21:29:08 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 3383A12D096 for ; Tue, 26 Apr 2016 21:29:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id n129so9543439wmn.1 for ; Tue, 26 Apr 2016 21:29:08 -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=iEf7Meb6XAoXGB2Jw8IaH36+dBA5c6KvnQDnJa1ATbU=; b=wpOhtQTMr/2VtcVJ8jVH1cERpZIDn8BRTqM912zIoBlqR4guePqpiLyjdlzASqlRJp HR6OC+iiZde/+wNaMmkPgcyspAah0yFPJFkxT/zidy2SotaVzNVLMvRlq3QK9BZgeZcK oT6ltsuXQfvobZhu6dKbmX5t3iD3o2325Uwcod5FXLwcVnDkFdOXTQ2oVdZeU+kmFYcN s3fDJDOqJ8JMsh4vLiQMHmw92zcO6wmEt8P9eEmZpMIAQ4GugECKMlGrki876xF3iTEl KW2KTOzSC8PeoCbf4fsH55FXjRLMsyR7c3WHwx4EdKG8ZeECJOrAZLGVgUdPEuGoMdrr 0Kjw== 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=iEf7Meb6XAoXGB2Jw8IaH36+dBA5c6KvnQDnJa1ATbU=; b=B5JFLAyGrSAD/Jl9X03aO4BLXMNpYNK39eQNo7eUwlB5f2Wcje5uynLnBfIhMAUuDA ZQwnisTZklfhJrSY+agm//YKs5Xtr6svOxh3P9hpor5BiHcHMV+gtHpwoeBheIrQjlaz HMEg7qzxw+CC/6z6LaELcsP3j0EcOS/dAVs4xmrQ4HRulZ7m+WTp7eNi/5WxfXuBa5kY Rsz9+soZsW38PUZg0l+G3dx+UEX35uA/nefwqgFTaIOh1PIwWKPQJQ0pEtn4/7+BgHNN wuqxqBKZVNeA7e5fi8hv2CSclbpNa0tG4COUEp0YNW4Xn1UNAuPS7me1hnhBRFcmCn6C 27gA== X-Gm-Message-State: AOPr4FVJgFQ/t2RGa5m5DXv6DVtiPp8Ik4aojjmtom627xI6CSpa54TGF6IQaIV1WR/vEA== X-Received: by 10.28.141.18 with SMTP id p18mr6953256wmd.57.1461731346717; Tue, 26 Apr 2016 21:29:06 -0700 (PDT) Received: from ?IPv6:2003:74:cf63:d501:499d:101d:1b0f:302f? (p2003000611105301499D101D1B0F302F.dip0.t-ipconnect.de. [2003:6:1110:5301:499d:101d:1b0f:302f]) by smtp.googlemail.com with ESMTPSA id da5sm1819127wjb.25.2016.04.26.21.29.05 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2016 21:29:05 -0700 (PDT) To: sfc@ietf.org From: Martin Stiemerling Message-ID: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> Date: Wed, 27 Apr 2016 06:29:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 04:29:11 -0000 Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) From nobody Tue Apr 26 22:39: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 542B912B02E for ; Tue, 26 Apr 2016 22:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 Ss6d2GFRtFEC for ; Tue, 26 Apr 2016 22:39:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F039F12B007 for ; Tue, 26 Apr 2016 22:39:53 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 39E03203C6; Wed, 27 Apr 2016 07:39:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 08DB212005B; Wed, 27 Apr 2016 07:39:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 07:39:51 +0200 From: To: "Joel M. Halpern" , Linda Dunbar , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRn9DlqSmT+mHDUEONqWoKbKSi95+cRNcAgAAZDICAAO7E4A== Date: Wed, 27 Apr 2016 05:39:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> 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.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 27 Apr 2016 05:39:57 -0000 Hi Joel, all, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mardi 26 avril 2016 19:18 > =C0=A0: Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur, Uri; sfc@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > With regard to Transport tunnel fragementation, that seems an issue for > the transport protocol. I don't actually object to a sentence, but it > does not seem that it will accomplish anything. [Med] I would like to see some text added to the draft. >=20 > With regard to packets fragmented by the source, I completely disagree > with your assertion. If an SFF were to reassemble the packets, that > would be a violation of its job. [Med] I agree with you. There is no reason for an SFF to > reassemble a packet fragmented by the source. The classifier may have > to do some interesting things in order to properly classify succeeding > fragments, but that is an implementation issue (most commonly addressed > with virtual reassembly, which doe snot delay the fragments.) We don't > specity that. [Med] Still, the external behavior of the classifier needs to be clear in t= he document. I don't find any text in the draft saying for instance that an= NSH header must be present in all fragments. (There some processing that m= ight be needed at the SFF to "do its job" with regards to fragments (receiv= e out of order fragments + forwarding policy on the full packet).) >=20 > If an SF needs to reassemble fragments to do its job, that is up to the > SF. Some will need to actually reassemble. Some will need to perform > virtual reassembly, and some will happily process the fragments. I can > not see what the NSH document could possibly mandate. [Med] Fully agree. >=20 > Yours, > Joel >=20 > On 4/26/16 11:47 AM, Linda Dunbar wrote: > > Joel, > > > > I think the document should add the description on the following two > > fragmentation scenarios: > > > > - Transport tunnel generated fragmentation: When a packet > > fragmentation is caused by transport tunnel (i.e. various > > encapsulations), the termination point of the transport tunnel is > > responsible for re-assembling the fragmented pieces of the packet. > > Since there won't be any SFF nodes in between the Transport Tunnel, > > the tunnel generated fragmentation does not require any actions by > > SFF nodes or SF nodes. > > > > > > - Source node generated fragmentation (after adding on the NSH > > header): When fragmentation has to be performed for a packet being > > encapsulated with the NSH header, either the intermediate SFF nodes > > or the SF nodes have to be able to reassemble the fragmented pieces. > > > > > > > > > > Cheers, > > > > > > Linda > > > > -----Original Message----- From: Joel M. Halpern > > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM > > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; > > sfc@ietf.org Subject: Re: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Re-reading your note, it is possible that you are referring only to > > the case of transport generated fragmentation of the outer packet. I > > had assumed you were not talking about that, since the resulting > > fragments will not all have NSH headers. As with any tunnel > > technology, if the tunnel chooses to fragment at its layer, then the > > tunnel is responsible for reassembly. That would be invisible to the > > SFF. > > > > Yours, Joel > > > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > >> Agree with Med. > >> > >> Even if each fragment piece of a packet with NSH header carries the > >> NSH header, the intermediate SFF nodes still need to put together > >> all the fragments together before passing the whole data frame to > >> the SF. > >> > >> Linda > >> > >> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] > >> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, > >> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: > >> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Re-, > >> > >> How do you instruct the transport layer to ALWAYS prepend an NSH > >> header even for fragments? Or you don't care about that? > >> > >> Thank you. > >> > >> Cheers, Med > >> > >>> -----Message d'origine----- De : Elzur, Uri > >>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 > >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet > >>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Med > >>> > >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is > >>> *NOT* a transport, dealing with fragmentation is left to the > >>> Transport used. > >>> > >>> The model I use for NSH, is basically similar to VXLAN . It is an > >>> overly. > >>> > >>> Thx > >>> > >>> Uri ("Oo-Ree") C: 949-378-7568 > >>> > >>> > >>> -----Original Message----- From: sfc > >>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>> mohamed.boucadair@orange.com Sent: Monday, April 25, 2016 7:18 > >>> AM To: Joel M. Halpern ; sfc@ietf.org > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Joel, > >>> > >>> Please see inline. > >>> > >>> Cheers, Med > >>> > >>>> -----Message d'origine----- De : Joel M. Halpern > >>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 > >>>> =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] > >>>> WG last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> If I am understanding you correctly Med, you are asking that > >>>> the NSH draft specify how service chaining should cope with > >>>> packets that have been fragmented? > >>>> > >>> > >>> [Med] To be accurate, I'm asking to assess whether there are > >>> implications. If there are, then the draft should be updated > >>> accordingly. > >>> > >>>> NSH, and the SFF functionality, does not care. > >>> > >>> [Med] I'm not that sure. Some typical implications are listed > >>> below: > >>> > >>> * SFF: If the NSH header is present only in the a fragment but > >>> SFF didn't maintained a state, subsequent fragments won't be > >>> appropriately processed. * SFC-aware function: if prepending a > >>> context information depends on the full packet, not only a > >>> fragment. > >>> > >>> It just does its job. > >>> > >>> [Med] which may be disturbed in some situations as listed in the > >>> examples above. > >>> > >>>> Ingress and intermediate classifiers may cope with fragments in > >>>> any number of ways. > >>> Specifying such is clearly out of scope for this draft. > >>> > >>> [Med] The purpose is not to specify the internal implementation > >>> details but the external behavior of the classifier function when > >>> it comes to handle fragments. That behavior may have an incidence > >>> on SFF, in particular. The purpose is not to recommend the > >>> maximum resources to be dedicated to out of order fragments nor > >>> the timeout to cache those; these considerations are of course > >>> out of scope. Nevertheless, an implementation should offer a > >>> configurable parameter so that an operator tweak those according > >>> to its context. > >>> > >>>> I suppose one could write an informational draft on possible > >>>> ways of coping. The IETF has not usually published such. > >>>> Service functions have to cope with fragmented packets just as > >>>> they had to before the advent of NSH, so describing that is > >>>> clearly not needed here. > >>> > >>> [Med] The advent of NSH has the following implications: * it > >>> exacerbates fragmentation. Handing over this issue to the > >>> transport layer may lead to interoperability issues. * the > >>> chaining may not be efficient if fragments are inappropriately > >>> handled. > >>> > >>> Introducing NSH should not degrade the overall service compared > >>> to legacy service deployment schemes. > >>> > >>>> > >>>> Yours, Joel > >>>> > >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > >>>>> Re-, > >>>>> > >>>>> I hear you, but my comment is that we need, as a WG, to > >>>>> decide what to > >>>> put in the draft. FWIW, I'm discussing two fragmentation > >>>> issues: > >>>>> > >>>>> (1) Fragmentation that is caused by prepending an SFC > >>>>> header. (2) Handling fragments at the ingress of an > >>>>> SFC-enabled domain. > >>>>> > >>>>> Increasing the MTU is for sure a recommendation is to be > >>>>> explicitly > >>>> called out in the text (see my first message). > >>>>> > >>>>> There are other issues that need to be discussed, e.g., how > >>>>> to deal with > >>>> fragments in SFFs/Classifiers? > >>>>> > >>>>> It is also "prudent" to check that no issues will be > >>>>> experienced in SFF > >>>> to handle fragments. If an SFC header is prepended for all > >>>> fragments, I'm not sure there > >>>>> is any particular issue at the SFF level, except if > >>>>> stripping/adding > >>>> context TLVs depends on the full packet (not just fragment). It > >>>> is warranted to consider a little bit this point before > >>>> declaring there is no issue. > >>>>> > >>>>> For point (1), declaring fragmentation out of scope would be > >>>>> meant that > >>>> an implementation must be prepared to receive fragments with > >>>> or without NSH header as this is a decision that is left to > >>>> the transport encapsulation. This is a requirement per se! > >>>>> > >>>>> I won't reiterate all the comments I have about the current > >>>>> wording of > >>>> this section. > >>>>> > >>>>> Cheers, Med > >>>>> > >>>>>> -----Message d'origine----- De : Elzur, Uri > >>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 > >>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Hi Med > >>>>>> > >>>>>> My point is that Fragmentation is yet another transport > >>>>>> related issue > >>>> that > >>>>>> is beyond the scope of NSH and beyond the charter of the > >>>>>> WG, so it > >>>> doesn't > >>>>>> really belong in the draft. We are providing an advice as > >>>>>> extending the size of the packet may lead to fragmentation, > >>>>>> but as you check RFC 7348 VxLAN, which my create the same > >>>>>> issue, you'll find it doesn't even > >>>> relate > >>>>>> to it. > >>>>>> > >>>>>> Thx > >>>>>> > >>>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>>> > >>>>>> > >>>>>> -----Original Message----- From: sfc > >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 > >>>>>> 10:32 PM To: Elzur, Uri ; Thomas > >>>>>> Narten > >>>> ; > >>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for > >>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Hi Uri, > >>>>>> > >>>>>> That's another option that needs to be > >>>>>> discussed/investigated. I'm > >>>> afraid > >>>>>> this is not the rationale adopted in -04 since it includes > >>>>>> some text > >>>> that > >>>>>> is far to be sufficient to ensure interoperable > >>>>>> implementations. > >>>>>> > >>>>>> BTW, saying that nsh does not need to deal with > >>>>>> fragmentation because > >>>> it > >>>>>> is transport-independent is not IMHO a good strategy to > >>>>>> adopt here > >>>> because > >>>>>> it opens the door for interoperable issues, it may lead to > >>>>>> sub-optimal implementations if the sfc information is > >>>>>> present only in one > >>>> fragments, > >>>>>> etc. > >>>>>> > >>>>>> My comments are related to the current text in the -04. > >>>>>> This text needs > >>>> to > >>>>>> be fixed somehow. > >>>>>> > >>>>>> Cheers, Med > >>>>>> > >>>>>>> -----Message d'origine----- De : Elzur, Uri > >>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril > >>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> Hi Med > >>>>>>> > >>>>>>> I see no need to specify the exact behavior as NSH is > >>>>>>> transport independent i.e. like NSH interaction with any > >>>>>>> other Transport eh issue of Fragmentation is to be dealt > >>>>>>> in a way that matches the mechanisms supported by the > >>>>>>> Transport used and do not belong in the NSH draft > >>>>>>> > >>>>>>> Thx > >>>>>>> > >>>>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- From: sfc > >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14, > >>>>>>> 2016 12:43 AM To: Thomas Narten ; > >>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for > >>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> R-, > >>>>>>> > >>>>>>> In addition to other pending issues raised for this > >>>>>>> draft, I would like to raise this additional one about > >>>>>>> Section 6. > >>>>>>> > >>>>>>> =3D=3D 6. Fragmentation Considerations > >>>>>>> > >>>>>>> NSH and the associated transport header are "added" to > >>>>>>> the encapsulated packet/frame. This additional > >>>>>>> information increases > >>>> the > >>>>>>> size of the packet. In order the ensure proper > >>>>>>> forwarding of NSH data, several options for handling > >>>>>>> fragmentation and re-assembly exist: > >>>>>>> > >>>>>>> 1. Jumbo Frames, when supported, enable the transport of > >>>>>>> NSH and associated transport packets without requiring > >>>>>>> fragmentation. > >>>>>>> > >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique > >>>>>>> for dynamically discovering the maximum transmission > >>>>>>> unit (MTU) of > >>>> an > >>>>>>> arbitrary internet path" and can be utilized to ensure > >>>>>>> the > >>> the > >>>>>>> required packet size is used. > >>>>>>> > >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and > >>>>>>> re- > >>>> assembly > >>>>>>> in section 5.4. =3D=3D > >>>>>>> > >>>>>>> * The text is weak for a Standard track document that is > >>>>>>> intended to solve the problem in > >>>>>>> https://tools.ietf.org/html/rfc7498#section- > >>> 2.12. > >>>>>>> There should be a clear behavior to be followed by an > >>> implementation. > >>>>>>> Further, I would avoid the use of words such as "can". > >>>>>>> > >>>>>>> * The text covers only fragmentation when it is induced > >>>>>>> by SFC operations, it does not discuss the treatment of a > >>>>>>> fragment when received in an SFC domain. IMHO, the draft > >>>>>>> should also specify the behavior of the Classifier with > >>>>>>> regards to fragments for the sake of proper SFC > >>>>>>> operation. Applying classification policies may require > >>>>>>> the > >>>>>> full packet, not only a fragment. > >>>>>>> In particular, dedicated resources should dedicated for > >>>>>>> handling out of order fragments. Of course, it is out of > >>>>>>> scope of this document to describe how SFs handle > >>>>>>> fragments. > >>>>>>> > >>>>>>> * If an SFC header is prepended for all fragments, I'm > >>>>>>> not sure there is any particular issue at the SFF > >>>>>>> level...except if stripping/adding context TLVs depends > >>>>>>> on the full packet (not just fragment). It is warranted > >>>>>>> to consider a little bit this point before declaring > >>>>>>> there > >>>> is > >>>>>> no issue. > >>>>>>> > >>>>>>> * The text states "several options". This may be > >>>>>>> interpreted as if implementing one of them is > >>>>>>> sufficient...which is not true. The first two points > >>>>>>> contribute to minimize the fragmentation risk, but > >>>>>>> fragmentation may still be experienced (e.g., other shims > >>>>>>> are prepended by other nodes for some other purposes, > >>>>>>> nested nsh, etc.) > >>>>>>> > >>>>>>> * The first two points have nothing to do with > >>>>>>> reassembly. > >>>>>>> > >>>>>>> * The support of jumbo frames by a router/device does not > >>>>>>> mean that it can make use of it. Appropriate MTU > >>>>>>> configuration should be undertaken in a consistent manner > >>>>>>> within an SFC domain. The text should be updated to make > >>>>>>> it is about (consistent) MTU > >>> configuration. > >>>>>>> > >>>>>>> * BTW, shouldn't the text be reworded to recommended to > >>>>>>> increase the MTU of **all nodes** of an SFC-enabled > >>>>>>> domain by at least the length of SFC header + transport > >>>>>>> header? > >>>>>>> > >>>>>>> * Bullet 2, how PMTU discovery is actually used in this > >>>>>>> context? Do you assume that all SFC-aware nodes will > >>>>>>> issue such messages towards other SFC-aware node, > >>>>>>> arbitrary destination, else? > >>>>>>> > >>>>>>> * Bullet 2, I would drop "describes a technique for > >>>>>>> dynamically discovering the maximum transmission unit > >>>>>>> (MTU) of an arbitrary internet path". > >>>>>>> > >>>>>>> * Bullet 2, s/ the the/the. > >>>>>>> > >>>>>>> * The reference to the LISP specification raises two > >>>>>>> concerns and one comment: > >>>>>>> > >>>>>>> (1) I don't think it is a good approach that fragments > >>>>>>> induced by the network are passed to their ultimate > >>>>>>> destinations as such > >>> (stateless). > >>>>>>> IMO, reassembly should be done within the SFC domain > >>>>>>> (responsible for fragmentation) not passed away. (2) Does > >>>>>>> the stateful mode require all SFC data plane elements > >>>>>>> maintain a full list of MTU for the any SFF/SF instance > >>>>>>> of the SFC > >>>>>> domain? > >>>>>>> > >>>>>>> The current text suggests that [RFC6830] should be listed > >>>>>>> as normative reference (not an informative one). I would > >>>>>>> personally favor removing the reference to LISP (as it is > >>>>>>> an Experimental RFC). > >>>>>>> > >>>>>>> * The security section of the draft may be augmented > >>>>>>> with informational fragmentation-related pointers to: > >>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment > >>>>>>> Filtering), RFC3128 (Protection Against a Variant of the > >>>>>>> Tiny Fragment Attack), and RFC 4963 (IPv4 Reassembly > >>>>>>> Errors at High Data Rates). > >>>>>>> > >>>>>>> Cheers, Med > >>>>>>> > >>>>>>>> -----Message d'origine----- De : sfc > >>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de > >>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril > >>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org Objet : Re: > >>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>>>> > >>>>>>>> Dear Thomas, all, > >>>>>>>> > >>>>>>>> As I mentioned during the meeting, there are several > >>>>>>>> issues that are not covered in the last version of the > >>>>>>>> draft. I already provided examples of the issues > >>>>>>>> offline as requested by Martin. > >>>>>>>> > >>>>>>>> Cheers, Med > >>>>>>>> > >>>>>>>>> -----Message d'origine----- De : sfc > >>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas > >>>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : > >>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for > >>>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>>> > >>>>>>>>> Dear WG: > >>>>>>>>> > >>>>>>>>> This note begins a WG last call on > >>>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > The editors of the NSH document have indicated that they have > >>>>>>>>> addressed all known comments and that there are no > >>>>>>>>> open issues with the current version of the > >>>>>>>>> document. > >>>>>>>>> > >>>>>>>>> Substantive comments to the list please, editorial > >>>>>>>>> comments can go directly to the document editors. > >>>>>>>>> > >>>>>>>>> We'll also get a brief update from the editors at > >>>>>>>>> next week's meeting. If there are any remaining > >>>>>>>>> issues with the document, raising them before the > >>>>>>>>> meeting would be especially helpful. > >>>>>>>>> > >>>>>>>>> For the chairs, Thomas > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > >>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > >>>>>>>> mailing list sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>>> _______________________________________________ sfc > >>>>>>> mailing list sfc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ sfc mailing > >>>>>> list sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ 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 Tue Apr 26 22:46:12 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 ABDDE12D55F for ; Tue, 26 Apr 2016 22:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 kIW66SBxMKNs for ; Tue, 26 Apr 2016 22:46:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CCB712B03D for ; Tue, 26 Apr 2016 22:46:08 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 42D882DC377; Wed, 27 Apr 2016 07:46:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1BCCF4C06C; Wed, 27 Apr 2016 07:46:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 07:46:05 +0200 From: To: "Joel M. Halpern" , Ron Parker , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRn9DlqSmT+mHDUEONqWoKbKSi95+cRNcAgAAC24CAABdVAIAA8A1Q Date: Wed, 27 Apr 2016 05:46:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D604F7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> In-Reply-To: <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.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.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.27.50317 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 27 Apr 2016 05:46:11 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mardi 26 avril 2016 19:22 > =C0=A0: Ron Parker; Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; Elzur, Ur= i; > sfc@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > At least so far, we have treated the communication between classifier > and SFF (ingress or intermediate) as outside of the scope of our work. [Med] I'm afraid I don't get this one. Isn't this what is depicted in https= ://tools.ietf.org/html/rfc7665#section-4?=20 > For SF <-> SFF communication we have ntoed the need for a proxy to > handle the case when the SF can not accept and return the NSH header, > since we assume that is preserved. Other than that preservation, > similar to the above, we have treated the details as outside of our > scope. That is because they depend so heavily on the implementation > technique used. (Hypervisor ,_> application communication vs > communication inside a user space or communication over an actual > Ethernet are all very different.) [Med] Specifying the external behavior of the interface between an SFF and = an SFC-aware SF is completely in scope, imho.=20 >=20 > Trying to extend the NSH document to address these would be a major > change, and would step into the issues related to transport selection, > which are explicitly out of scope. >=20 > Yours, > Joel >=20 > On 4/26/16 11:58 AM, Ron Parker wrote: > > Linda, > > > > I like the first clause (transport tunnel based fragmentation). > > > > Regarding the second (source based), I think there are more subcases to > consider: > > > > 1. Propagation of NSH encapsulated packet from classifier to SFF > > 2. Propagation of NSH encapsulated packet from SFF to SF > > 3. Propagation of NSH encapsulated packet from SF to SFF (including > possibility that NSH size increased at SF) > > 4. Propagation of NSH encapsulated packet from SFF to SFF > > > > In each of the 4 cases above, there is the possibility that MTU will b= e > exceeded and therefore there are procedures to be defined in that > eventuality. > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar > > Sent: Tuesday, April 26, 2016 11:48 AM > > To: Joel M. Halpern ; mohamed.boucadair@orange.com= ; > Elzur, Uri ; sfc@ietf.org > > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Joel, > > > > I think the document should add the description on the following two > fragmentation scenarios: > > > > - Transport tunnel generated fragmentation: > > When a packet fragmentation is caused by transport tunnel (i.e. > various encapsulations), the termination point of the transport tunnel is > responsible for re-assembling the fragmented pieces of the packet. Since > there won't be any SFF nodes in between the Transport Tunnel, the tunnel > generated fragmentation does not require any actions by SFF nodes or SF > nodes. > > > > > > - Source node generated fragmentation (after adding on the NSH header): > > When fragmentation has to be performed for a packet being > encapsulated with the NSH header, either the intermediate SFF nodes or th= e > SF nodes have to be able to reassemble the fragmented pieces. > > > > > > > > Cheers, > > > > > > Linda > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Tuesday, April 26, 2016 10:33 AM > > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.or= g > > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Re-reading your note, it is possible that you are referring only to the > case of transport generated fragmentation of the outer packet. I had > assumed you were not talking about that, since the resulting fragments > will not all have NSH headers. As with any tunnel technology, if the > tunnel chooses to fragment at its layer, then the tunnel is responsible > for reassembly. That would be invisible to the SFF. > > > > Yours, > > Joel > > > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > >> Agree with Med. > >> > >> Even if each fragment piece of a packet with NSH header carries the NS= H > header, the intermediate SFF nodes still need to put together all the > fragments together before passing the whole data frame to the SF. > >> > >> Linda > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >> mohamed.boucadair@orange.com > >> Sent: Monday, April 25, 2016 9:42 AM > >> To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Re-, > >> > >> How do you instruct the transport layer to ALWAYS prepend an NSH heade= r > even for fragments? Or you don't care about that? > >> > >> Thank you. > >> > >> Cheers, > >> Med > >> > >>> -----Message d'origine----- > >>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avri= l > >>> 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; > >>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>> draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Med > >>> > >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* > >>> a transport, dealing with fragmentation is left to the Transport used= . > >>> > >>> The model I use for NSH, is basically similar to VXLAN . It is an > overly. > >>> > >>> Thx > >>> > >>> Uri ("Oo-Ree") > >>> C: 949-378-7568 > >>> > >>> > >>> -----Original Message----- > >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>> mohamed.boucadair@orange.com > >>> Sent: Monday, April 25, 2016 7:18 AM > >>> To: Joel M. Halpern ; sfc@ietf.org > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Joel, > >>> > >>> Please see inline. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 2= 5 > >>>> avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet= : > >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> If I am understanding you correctly Med, you are asking that the NSH > >>>> draft specify how service chaining should cope with packets that > >>>> have been fragmented? > >>>> > >>> > >>> [Med] To be accurate, I'm asking to assess whether there are > implications. > >>> If there are, then the draft should be updated accordingly. > >>> > >>>> NSH, and the SFF functionality, does not care. > >>> > >>> [Med] I'm not that sure. Some typical implications are listed below: > >>> > >>> * SFF: If the NSH header is present only in the a fragment but SFF > >>> didn't maintained a state, subsequent fragments won't be appropriatel= y > processed. > >>> * SFC-aware function: if prepending a context information depends on > >>> the full packet, not only a fragment. > >>> > >>> It just does its job. > >>> > >>> [Med] which may be disturbed in some situations as listed in the > >>> examples above. > >>> > >>>> Ingress and intermediate classifiers may cope with fragments in any > >>>> number of ways. > >>> Specifying such is clearly out of scope for this draft. > >>> > >>> [Med] The purpose is not to specify the internal implementation > >>> details but the external behavior of the classifier function when it > >>> comes to handle fragments. That behavior may have an incidence on > >>> SFF, in particular. The purpose is not to recommend the maximum > >>> resources to be dedicated to out of order fragments nor the timeout > >>> to cache those; these considerations are of course out of scope. > >>> Nevertheless, an implementation should offer a configurable parameter > >>> so that an operator tweak those according to its context. > >>> > >>>> I suppose one could write an informational draft on possible ways > >>>> of coping. The IETF has not usually published such. > >>>> Service functions have to cope with fragmented packets just as they > >>>> had to before the advent of NSH, so describing that is clearly not > >>>> needed here. > >>> > >>> [Med] The advent of NSH has the following implications: > >>> * it exacerbates fragmentation. Handing over this issue to the > >>> transport layer may lead to interoperability issues. > >>> * the chaining may not be efficient if fragments are inappropriately > >>> handled. > >>> > >>> Introducing NSH should not degrade the overall service compared to > >>> legacy service deployment schemes. > >>> > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > >>>>> Re-, > >>>>> > >>>>> I hear you, but my comment is that we need, as a WG, to decide what > >>>>> to > >>>> put in the draft. FWIW, I'm discussing two fragmentation issues: > >>>>> > >>>>> (1) Fragmentation that is caused by prepending an SFC header. > >>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. > >>>>> > >>>>> Increasing the MTU is for sure a recommendation is to be explicitly > >>>> called out in the text (see my first message). > >>>>> > >>>>> There are other issues that need to be discussed, e.g., how to deal > >>>>> with > >>>> fragments in SFFs/Classifiers? > >>>>> > >>>>> It is also "prudent" to check that no issues will be experienced in > >>>>> SFF > >>>> to handle fragments. If an SFC header is prepended for all > >>>> fragments, I'm not sure there > >>>>> is any particular issue at the SFF level, except if > >>>>> stripping/adding > >>>> context TLVs depends on the full packet (not just fragment). It is > >>>> warranted to consider a little bit this point before declaring there > >>>> is no issue. > >>>>> > >>>>> For point (1), declaring fragmentation out of scope would be meant > >>>>> that > >>>> an implementation must be prepared to receive fragments with or > >>>> without NSH header as this is a decision that is left to the > >>>> transport encapsulation. This is a requirement per se! > >>>>> > >>>>> I won't reiterate all the comments I have about the current wording > >>>>> of > >>>> this section. > >>>>> > >>>>> Cheers, > >>>>> Med > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 > >>>>>> avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Hi Med > >>>>>> > >>>>>> My point is that Fragmentation is yet another transport related > >>>>>> issue > >>>> that > >>>>>> is beyond the scope of NSH and beyond the charter of the WG, so it > >>>> doesn't > >>>>>> really belong in the draft. We are providing an advice as > >>>>>> extending the size of the packet may lead to fragmentation, but as > >>>>>> you check RFC 7348 VxLAN, which my create the same issue, you'll > >>>>>> find it doesn't even > >>>> relate > >>>>>> to it. > >>>>>> > >>>>>> Thx > >>>>>> > >>>>>> Uri ("Oo-Ree") > >>>>>> C: 949-378-7568 > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>>> mohamed.boucadair@orange.com > >>>>>> Sent: Sunday, April 24, 2016 10:32 PM > >>>>>> To: Elzur, Uri ; Thomas Narten > >>>> ; > >>>>>> sfc@ietf.org > >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Hi Uri, > >>>>>> > >>>>>> That's another option that needs to be discussed/investigated. > >>>>>> I'm > >>>> afraid > >>>>>> this is not the rationale adopted in -04 since it includes some > >>>>>> text > >>>> that > >>>>>> is far to be sufficient to ensure interoperable implementations. > >>>>>> > >>>>>> BTW, saying that nsh does not need to deal with fragmentation > >>>>>> because > >>>> it > >>>>>> is transport-independent is not IMHO a good strategy to adopt here > >>>> because > >>>>>> it opens the door for interoperable issues, it may lead to > >>>>>> sub-optimal implementations if the sfc information is present only > >>>>>> in one > >>>> fragments, > >>>>>> etc. > >>>>>> > >>>>>> My comments are related to the current text in the -04. This text > >>>>>> needs > >>>> to > >>>>>> be fixed somehow. > >>>>>> > >>>>>> Cheers, > >>>>>> Med > >>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> De : Elzur, Uri [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche > >>>>>>> 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narte= n; > >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> Hi Med > >>>>>>> > >>>>>>> I see no need to specify the exact behavior as NSH is transport > >>>>>>> independent i.e. like NSH interaction with any other Transport eh > >>>>>>> issue of Fragmentation is to be dealt in a way that matches the > >>>>>>> mechanisms supported by the Transport used and do not belong in > >>>>>>> the NSH draft > >>>>>>> > >>>>>>> Thx > >>>>>>> > >>>>>>> Uri ("Oo-Ree") > >>>>>>> C: 949-378-7568 > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>>>> mohamed.boucadair@orange.com > >>>>>>> Sent: Thursday, April 14, 2016 12:43 AM > >>>>>>> To: Thomas Narten ; sfc@ietf.org > >>>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> R-, > >>>>>>> > >>>>>>> In addition to other pending issues raised for this draft, I > >>>>>>> would like to raise this additional one about Section 6. > >>>>>>> > >>>>>>> =3D=3D > >>>>>>> 6. Fragmentation Considerations > >>>>>>> > >>>>>>> NSH and the associated transport header are "added" to the > >>>>>>> encapsulated packet/frame. This additional information > >>>>>>> increases > >>>> the > >>>>>>> size of the packet. In order the ensure proper forwarding of > NSH > >>>>>>> data, several options for handling fragmentation and re- > assembly > >>>>>>> exist: > >>>>>>> > >>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH > and > >>>>>>> associated transport packets without requiring > fragmentation. > >>>>>>> > >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for > >>>>>>> dynamically discovering the maximum transmission unit > >>>>>>> (MTU) of > >>>> an > >>>>>>> arbitrary internet path" and can be utilized to ensure the > >>> the > >>>>>>> required packet size is used. > >>>>>>> > >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and re- > >>>> assembly > >>>>>>> in section 5.4. > >>>>>>> =3D=3D > >>>>>>> > >>>>>>> * The text is weak for a Standard track document that is intended > >>>>>>> to solve the problem in > >>>>>>> https://tools.ietf.org/html/rfc7498#section- > >>> 2.12. > >>>>>>> There should be a clear behavior to be followed by an > >>> implementation. > >>>>>>> Further, I would avoid the use of words such as "can". > >>>>>>> > >>>>>>> * The text covers only fragmentation when it is induced by SFC > >>>>>>> operations, it does not discuss the treatment of a fragment when > >>>>>>> received in an SFC domain. IMHO, the draft should also specify > >>>>>>> the behavior of the Classifier with regards to fragments for the > >>>>>>> sake of proper SFC operation. Applying classification policies > >>>>>>> may require the > >>>>>> full packet, not only a fragment. > >>>>>>> In particular, dedicated resources should dedicated for handling > >>>>>>> out of order fragments. Of course, it is out of scope of this > >>>>>>> document to describe how SFs handle fragments. > >>>>>>> > >>>>>>> * If an SFC header is prepended for all fragments, I'm not sure > >>>>>>> there is any particular issue at the SFF level...except if > >>>>>>> stripping/adding context TLVs depends on the full packet (not > >>>>>>> just fragment). It is warranted to consider a little bit this > >>>>>>> point before declaring there > >>>> is > >>>>>> no issue. > >>>>>>> > >>>>>>> * The text states "several options". This may be interpreted as > >>>>>>> if implementing one of them is sufficient...which is not true. > >>>>>>> The first two points contribute to minimize the fragmentation > >>>>>>> risk, but fragmentation may still be experienced (e.g., other > >>>>>>> shims are prepended by other nodes for some other purposes, > >>>>>>> nested nsh, > >>>>>>> etc.) > >>>>>>> > >>>>>>> * The first two points have nothing to do with reassembly. > >>>>>>> > >>>>>>> * The support of jumbo frames by a router/device does not mean > >>>>>>> that it can make use of it. Appropriate MTU configuration should > >>>>>>> be undertaken in a consistent manner within an SFC domain. The > >>>>>>> text should be updated to make it is about (consistent) MTU > >>> configuration. > >>>>>>> > >>>>>>> * BTW, shouldn't the text be reworded to recommended to increase > >>>>>>> the MTU of **all nodes** of an SFC-enabled domain by at least the > >>>>>>> length of SFC header + transport header? > >>>>>>> > >>>>>>> * Bullet 2, how PMTU discovery is actually used in this context? > >>>>>>> Do you assume that all SFC-aware nodes will issue such messages > >>>>>>> towards other SFC-aware node, arbitrary destination, else? > >>>>>>> > >>>>>>> * Bullet 2, I would drop "describes a technique for dynamically > >>>>>>> discovering the maximum transmission unit (MTU) of an arbitrary > >>>>>>> internet path". > >>>>>>> > >>>>>>> * Bullet 2, s/ the the/the. > >>>>>>> > >>>>>>> * The reference to the LISP specification raises two concerns and > >>>>>>> one > >>>>>>> comment: > >>>>>>> > >>>>>>> (1) I don't think it is a good approach that fragments induced by > >>>>>>> the network are passed to their ultimate destinations as such > >>> (stateless). > >>>>>>> IMO, reassembly should be done within the SFC domain (responsible > >>>>>>> for > >>>>>>> fragmentation) not passed away. > >>>>>>> (2) Does the stateful mode require all SFC data plane elements > >>>>>>> maintain a full list of MTU for the any SFF/SF instance of the > >>>>>>> SFC > >>>>>> domain? > >>>>>>> > >>>>>>> The current text suggests that [RFC6830] should be listed as > >>>>>>> normative reference (not an informative one). I would personally > >>>>>>> favor removing the reference to LISP (as it is an Experimental > RFC). > >>>>>>> > >>>>>>> * The security section of the draft may be augmented with > >>>>>>> informational fragmentation-related pointers to: e.g., RFC1858 > >>>>>>> (Security Considerations for IP Fragment Filtering), RFC3128 > >>>>>>> (Protection Against a Variant of the Tiny Fragment Attack), and > >>>>>>> RFC > >>>>>>> 4963 (IPv4 Reassembly Errors at High Data Rates). > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Med > >>>>>>> > >>>>>>>> -----Message d'origine----- > >>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de > >>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril 2016 13:1= 4 =C0 > : > >>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG last call for > >>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>> > >>>>>>>> Dear Thomas, all, > >>>>>>>> > >>>>>>>> As I mentioned during the meeting, there are several issues that > >>>>>>>> are not covered in the last version of the draft. I already > >>>>>>>> provided examples of the issues offline as requested by Martin. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Med > >>>>>>>> > >>>>>>>>> -----Message d'origine----- > >>>>>>>>> De : sfc [mailto:sfc-bounces@ietf.org] De la part de Thomas > >>>>>>>>> Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org O= bjet > >>>>>>>>> : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>>>>> > >>>>>>>>> Dear WG: > >>>>>>>>> > >>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>>>>>> > >>>>>>>>> The editors of the NSH document have indicated that they have > >>>>>>>>> addressed all known comments and that there are no open issues > >>>>>>>>> with the current version of the document. > >>>>>>>>> > >>>>>>>>> Substantive comments to the list please, editorial comments can > >>>>>>>>> go directly to the document editors. > >>>>>>>>> > >>>>>>>>> We'll also get a brief update from the editors at next week's > >>>>>>>>> meeting. If there are any remaining issues with the document, > >>>>>>>>> raising them before the meeting would be especially helpful. > >>>>>>>>> > >>>>>>>>> For the chairs, > >>>>>>>>> Thomas > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> sfc mailing list > >>>>>>>>> sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> sfc mailing list > >>>>>>>> sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> sfc mailing list > >>>>>>> sfc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ > >>>>>> sfc mailing list > >>>>>> sfc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > >> > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Apr 27 04:45: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 65F7512D7A2 for ; Wed, 27 Apr 2016 04:45:49 -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 3GR1Ry29jmfg for ; Wed, 27 Apr 2016 04:45:44 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7CB12D7B0 for ; Wed, 27 Apr 2016 04:45:44 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x201so45794351oif.3 for ; Wed, 27 Apr 2016 04:45:44 -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=ejByNfqCAzeJGe78+o/7qy71q6WVEeFneyiBXlREkzw=; b=g0NAzi4trbqSoQ1+98sVCYLnPtcpDrpleD2LZX9TyoR51+eKPprVaJxhvQQds/W5HF yuJhhDyW+RQUWlDz0cL+eFTE8DlXmXxJpqkLj0vH5oV6WYFSooH6NJi4F/ai7AKmLfJ0 oReVnVCTxLX4ky11+E6RWrLMDoPSwruXeAY684c+LDS7Xv53wCFS9hQPlqNbMu9o5OuB QmCmVpG1hrQSt/z/0uughJHNO1WOrR5FlgYkcGTnCJr+8SpeSLoaupCvCyxQLsRBIRiE rlC7uVeht99hm73UuXdaMijaOIcv8+MZFeuo2Jv9YSJNsBHdM6/qFNJSQTSQtu/Cy85n jbgA== 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=ejByNfqCAzeJGe78+o/7qy71q6WVEeFneyiBXlREkzw=; b=lYu6/6J5piAh7xjIvO00Azh4M7BoX7xkdLo2g+LMJIqYFI2cJ+Bj0G5Kxdj0jQTs6Q xOGZBcWyftLkH1NAbObKsS4U8kkC/Z1RwTmzzX1JM+BEbDPhi8cyyk1gSUHVsu90o2rQ UyzHr9tlZzMgSAPloH5Wgpem8oquk0MG8r7Qj9N7WXM26VzG+nVyYj0J4a69kkppe8id X3Rut/4EABaFgUG5S70u/cboeonPwVet9vT6Se9StSRXurnw4QeEebFgOgmn2p1QU72i 5h5ea5AOKZ06zmRVsxn2l1Rl7T/rUVmxvPs16EXB78noBcg/hdn3ofNOgg3JLkdqm8DX e4XA== X-Gm-Message-State: AOPr4FWgDNbf6Ah6KVBxTV9P3ZaciyAFJm7W+mrZ8GL8bfDtT7qTzMOjhrfd14doaMrw7dHhSX4eleiM8qNTgw== X-Received: by 10.202.184.6 with SMTP id i6mr3412741oif.76.1461757543595; Wed, 27 Apr 2016 04:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Wed, 27 Apr 2016 04:45:24 -0700 (PDT) In-Reply-To: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> From: "Andrew G. Malis" Date: Wed, 27 Apr 2016 07:45:24 -0400 Message-ID: To: Martin Stiemerling Content-Type: multipart/alternative; boundary=001a113cd19022435a053175f341 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 11:45:49 -0000 --001a113cd19022435a053175f341 Content-Type: text/plain; charset=UTF-8 Martin, As a contributor, I support publication of this draft. Thanks, Andy On Wed, Apr 27, 2016 at 12:29 AM, Martin Stiemerling wrote: > Dear all, > > This is the start of the Working Group Last Call (WGLC) for > > draft-ietf-sfc-control-plane-04.txt > > The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. > > Please send your comments and reviews to the sfc@ietf.org list. > > Regards, > > Martin (SFC co-chair) > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a113cd19022435a053175f341 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

As a contributor, I support pub= lication of this draft.

Thanks,
Andy

On Wed, A= pr 27, 2016 at 12:29 AM, Martin Stiemerling <mls.ietf@gmail.com>= wrote:
Dear all,

This is the start of the Working Group Last Call (WGLC) for

draft-ietf-sfc-control-plane-04.txt

The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT.

Please send your comments and reviews to the sfc@ietf.org list.

Regards,

=C2=A0 Martin (SFC co-chair)

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--001a113cd19022435a053175f341-- From nobody Wed Apr 27 04:57: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 1D38812D7BA for ; Wed, 27 Apr 2016 04:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 RlXKXrychJ8h for ; Wed, 27 Apr 2016 04:57:33 -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 1F8B512D7CF for ; Wed, 27 Apr 2016 04:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4923; q=dns/txt; s=iport; t=1461758253; x=1462967853; h=from:to:subject:date:message-id:mime-version; bh=74Pvlnc21RNplHGkXjxqenlKbOWQ9ou8Qk3A3u5gJdY=; b=OhJKHKXDJrxyb5sj4nCp30D8nYr3CsZgI4AYdWccf7wKtLCKJDCqQaZP yNcIrqPtYAOzWuJyhsdnuCPSjp3+651MsSVkPWOKSzqYwi8iuLygAYXcP JryFdLjgD4geMkfHYF8VxpVkZL/AKc8vOgaicW8/aTV6bZvF4qoNsSmhg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQDvpyBX/5tdJa1egmxMgVa0coRzA?= =?us-ascii?q?Q2BdYdMOBQBAQEBAQEBZRwLhEiBCwEMdCcEJweID6J4oQ4BAQgCHoYhjl4Fjgy?= =?us-ascii?q?KBAGOFo8Rjy8BHgEBQoNriRt/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208,217";a="266754999" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 11:57:31 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3RBvULM030854 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 27 Apr 2016 11:57:31 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.1104.5; Wed, 27 Apr 2016 06:57: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.1104.009; Wed, 27 Apr 2016 06:57:30 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh "first nibble" issue Thread-Index: AQHRoHv5jA1HvFPCM0yMnvW+PmvYjg== Date: Wed, 27 Apr 2016 11:57:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D34621684C3B2jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] draft-ietf-sfc-nsh "first nibble" issue 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, 27 Apr 2016 11:57:35 -0000 --_000_D34621684C3B2jguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: The infamous "MPLS first nibble" issue was raised as part of the WGLC for d= raft-ietf-sfc-nsh-04. While this issue has been known for some time, and wo= rk has been done by the community to try and mitigate (for example RFC4928)= or remove it (for example RFC6790), given the widespread implementation of= existing hardware that uses the first nibble for ECMP decision processing,= it seems prudent for us as a WG to address it in terms of how it affects o= ur SFC protocol and make it clear within the draft the conclusion of the WG= . While it is true that we could rearrange our encapsulation header such that= it avoids this issue (by simply making the first nibble correspond to a va= lue that is neither 0x4 or 0x6), given multiple industry and open source im= plementations of the SFC encapsulation header, that is not a desired outcom= e, especially as multiple other transport encapsulations do not exhibit thi= s behavior when coupled with the SFC encapsulation. If we consider the current definition of the SFC encapsulation base header,= we can see that the first two bits are used as a version field. This means= that if we ever produce a version 01 for NSH it could result in a value of= 0x4 or 0x6 being present within the first nibble. To avoid such a result t= he simplest solution would be to reserve within the SFC encapsulation speci= fication version 01 and make it clear within the text that this is reserved= and should not be used in future versions of the protocol. If we ever chan= ge the version, which incidentally should be a rare thing, we would therefo= re jump from version=3D00 to version=3D02 (i.e. making version 1 'reserved'= ) thereby avoiding any clash in the first nibble. IMHO this seems like a reasonable approach to the problem but I would like = to hear opinions from the WG as to whether this is an acceptable solution a= nd if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add = text to reflect it. Jim --_000_D34621684C3B2jguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear WG:

The infamous “MPLS first nibble” issue was raised as part = of the WGLC for draft-ietf-sfc-nsh-04. While this issue has been known for = some time, and work has been done by the community to try and mitigate (for= example RFC4928) or remove it (for example RFC6790), given the widespread implementation of existing hardware that us= es the first nibble for ECMP decision processing, it seems prudent for us a= s a WG to address it in terms of how it affects our SFC protocol and make i= t clear within the draft the conclusion of the WG.

While it is true that we could rearrange our encapsulation header such= that it avoids this issue (by simply making the first nibble correspond to= a value that is neither 0x4 or 0x6), given multiple industry and open sour= ce implementations of the SFC encapsulation header, that is not a desired outcome, especially as multiple other transp= ort encapsulations do not exhibit this behavior when coupled with the SFC e= ncapsulation.

If we consider the current definition of the SFC encapsulation base he= ader, we can see that the first two bits are used as a version field. This = means that if we ever produce a version 01 for NSH it could result in a val= ue of 0x4 or 0x6 being present within the first nibble. To avoid such a result the simplest solution would be to= reserve within the SFC encapsulation specification version 01 and make it = clear within the text that this is reserved and should not be used in futur= e versions of the protocol. If we ever change the version, which incidentally should be a rare thing, we wou= ld therefore jump from version=3D00 to version=3D02 (i.e. making version 1 = ‘reserved’) thereby avoiding any clash in the first nibble.&nbs= p;

IMHO this seems like a reasonable approach to the problem but I would = like to hear opinions from the WG as to whether this is an acceptable solut= ion and if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to= add text to reflect it.

Jim
--_000_D34621684C3B2jguicharciscocom_-- From nobody Wed Apr 27 05:19:39 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 CF2BF12D0DF for ; Wed, 27 Apr 2016 05:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 mbqEzyA10Qhg for ; Wed, 27 Apr 2016 05:19:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE2E12D5B2 for ; Wed, 27 Apr 2016 05:19:36 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 71014180173; Wed, 27 Apr 2016 14:19:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 45D441A0059; Wed, 27 Apr 2016 14:19:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 14:19:34 +0200 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh "first nibble" issue Thread-Index: AQHRoHv5jA1HvFPCM0yMnvW+PmvYjp+dvNLg Date: Wed, 27 Apr 2016 12:19:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6079C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6079COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue 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, 27 Apr 2016 12:19:39 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6079COPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, Looks like a good plan. Thanks. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : mercredi 27 avril 2016 13:58 =C0 : sfc@ietf.org Objet : [sfc] draft-ietf-sfc-nsh "first nibble" issue Dear WG: The infamous "MPLS first nibble" issue was raised as part of the WGLC for d= raft-ietf-sfc-nsh-04. While this issue has been known for some time, and wo= rk has been done by the community to try and mitigate (for example RFC4928)= or remove it (for example RFC6790), given the widespread implementation of= existing hardware that uses the first nibble for ECMP decision processing,= it seems prudent for us as a WG to address it in terms of how it affects o= ur SFC protocol and make it clear within the draft the conclusion of the WG= . While it is true that we could rearrange our encapsulation header such that= it avoids this issue (by simply making the first nibble correspond to a va= lue that is neither 0x4 or 0x6), given multiple industry and open source im= plementations of the SFC encapsulation header, that is not a desired outcom= e, especially as multiple other transport encapsulations do not exhibit thi= s behavior when coupled with the SFC encapsulation. If we consider the current definition of the SFC encapsulation base header,= we can see that the first two bits are used as a version field. This means= that if we ever produce a version 01 for NSH it could result in a value of= 0x4 or 0x6 being present within the first nibble. To avoid such a result t= he simplest solution would be to reserve within the SFC encapsulation speci= fication version 01 and make it clear within the text that this is reserved= and should not be used in future versions of the protocol. If we ever chan= ge the version, which incidentally should be a rare thing, we would therefo= re jump from version=3D00 to version=3D02 (i.e. making version 1 'reserved'= ) thereby avoiding any clash in the first nibble. IMHO this seems like a reasonable approach to the problem but I would like = to hear opinions from the WG as to whether this is an acceptable solution a= nd if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add = text to reflect it. Jim --_000_787AE7BB302AE849A7480A190F8B933008D6079COPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

Looks like a good plan.

 

Thanks.

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mercredi 27 avril 2016 13:58
=C0 : sfc@ietf.org
Objet : [sfc] draft-ietf-sfc-nsh "first nibble" issue=

 

Dear WG:<= /p>

 

The infamous “MPLS fi= rst nibble” issue was raised as part of the WGLC for draft-ietf-sfc-n= sh-04. While this issue has been known for some time, and work has been done by the community to try and mitigate (for example RFC4928) or remove = it (for example RFC6790), given the widespread implementation of existing h= ardware that uses the first nibble for ECMP decision processing, it seems p= rudent for us as a WG to address it in terms of how it affects our SFC protocol and make it clear within th= e draft the conclusion of the WG.

 

While it is true that we co= uld rearrange our encapsulation header such that it avoids this issue (by s= imply making the first nibble correspond to a value that is neither 0x4 or 0x6), given multiple industry and open source implementa= tions of the SFC encapsulation header, that is not a desired outcome, espec= ially as multiple other transport encapsulations do not exhibit this behavi= or when coupled with the SFC encapsulation.

 

If we consider the current = definition of the SFC encapsulation base header, we can see that the first = two bits are used as a version field. This means that if we ever produce a version 01 for NSH it could result in a value of 0x4 or = 0x6 being present within the first nibble. To avoid such a result the simpl= est solution would be to reserve within the SFC encapsulation specification= version 01 and make it clear within the text that this is reserved and should not be used in future versions o= f the protocol. If we ever change the version, which incidentally should be= a rare thing, we would therefore jump from version=3D00 to version=3D02 (i= .e. making version 1 ‘reserved’) thereby avoiding any clash in the first nibble. 

 

IMHO this seems like a reas= onable approach to the problem but I would like to hear opinions from the W= G as to whether this is an acceptable solution and if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add text to = reflect it.

 

Jim

--_000_787AE7BB302AE849A7480A190F8B933008D6079COPEXCLILMA3corp_-- From nobody Wed Apr 27 06:06:31 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 A52A912D169 for ; Wed, 27 Apr 2016 06:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 LW5EN8OzIe8E for ; Wed, 27 Apr 2016 06:06:27 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id C989B12D14B for ; Wed, 27 Apr 2016 06:06:26 -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.0195.001; Wed, 27 Apr 2016 09:06:25 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-nsh "first nibble" issue Thread-Index: AQHRoHv5jA1HvFPCM0yMnvW+PmvYjp+dvNLggAANY8A= Date: Wed, 27 Apr 2016 13:06:25 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D6079C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6079C@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F3EE64wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue 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, 27 Apr 2016 13:06:29 -0000 --_000_E8355113905631478EFF04F5AA706E9830F3EE64wtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Wednesday, April 27, 2016 8:20 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue Hi Jim, Looks like a good plan. Thanks. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : mercredi 27 avril 2016 13:58 =C0 : sfc@ietf.org Objet : [sfc] draft-ietf-sfc-nsh "first nibble" issue Dear WG: The infamous "MPLS first nibble" issue was raised as part of the WGLC for d= raft-ietf-sfc-nsh-04. While this issue has been known for some time, and wo= rk has been done by the community to try and mitigate (for example RFC4928)= or remove it (for example RFC6790), given the widespread implementation of= existing hardware that uses the first nibble for ECMP decision processing,= it seems prudent for us as a WG to address it in terms of how it affects o= ur SFC protocol and make it clear within the draft the conclusion of the WG= . While it is true that we could rearrange our encapsulation header such that= it avoids this issue (by simply making the first nibble correspond to a va= lue that is neither 0x4 or 0x6), given multiple industry and open source im= plementations of the SFC encapsulation header, that is not a desired outcom= e, especially as multiple other transport encapsulations do not exhibit thi= s behavior when coupled with the SFC encapsulation. If we consider the current definition of the SFC encapsulation base header,= we can see that the first two bits are used as a version field. This means= that if we ever produce a version 01 for NSH it could result in a value of= 0x4 or 0x6 being present within the first nibble. To avoid such a result t= he simplest solution would be to reserve within the SFC encapsulation speci= fication version 01 and make it clear within the text that this is reserved= and should not be used in future versions of the protocol. If we ever chan= ge the version, which incidentally should be a rare thing, we would therefo= re jump from version=3D00 to version=3D02 (i.e. making version 1 'reserved'= ) thereby avoiding any clash in the first nibble. IMHO this seems like a reasonable approach to the problem but I would like = to hear opinions from the WG as to whether this is an acceptable solution a= nd if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add = text to reflect it. Jim --_000_E8355113905631478EFF04F5AA706E9830F3EE64wtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Wednesday, April 27, 2016 8:20 AM
To: Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue=

 

Hi Jim,

 

Looks like a good plan.

 

Thanks.

 

Cheers,

Med

 

De : sfc [mailto:sfc= -bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mercredi 27 avril 2016 13:58
=C0 : sfc@ietf.org
Objet : [sfc] draft-ietf-sfc-nsh "first nibble" issue=

 

Dear WG:

 

The infamous &#= 8220;MPLS first nibble” issue was raised as part of the WGLC for draf= t-ietf-sfc-nsh-04. While this issue has been known for some time, and work has been done by the community to try and mitigate (for example RFC49= 28) or remove it (for example RFC6790), given the widespread implementation= of existing hardware that uses the first nibble for ECMP decision processi= ng, it seems prudent for us as a WG to address it in terms of how it affects our SFC protocol and make it c= lear within the draft the conclusion of the WG.

 

While it is tru= e that we could rearrange our encapsulation header such that it avoids this= issue (by simply making the first nibble correspond to a value that is neither 0x4 or 0x6), given multiple industry and open source= implementations of the SFC encapsulation header, that is not a desired out= come, especially as multiple other transport encapsulations do not exhibit = this behavior when coupled with the SFC encapsulation.

 

If we consider = the current definition of the SFC encapsulation base header, we can see tha= t the first two bits are used as a version field. This means that if we ever produce a version 01 for NSH it could result in a value of= 0x4 or 0x6 being present within the first nibble. To avoid such a result t= he simplest solution would be to reserve within the SFC encapsulation speci= fication version 01 and make it clear within the text that this is reserved and should not be used in futu= re versions of the protocol. If we ever change the version, which incidenta= lly should be a rare thing, we would therefore jump from version=3D00 to ve= rsion=3D02 (i.e. making version 1 ‘reserved’) thereby avoiding any clash in the first nibble. 

 

IMHO this seems= like a reasonable approach to the problem but I would like to hear opinion= s from the WG as to whether this is an acceptable solution and if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to ad= d text to reflect it.

 

Jim<= /span>

--_000_E8355113905631478EFF04F5AA706E9830F3EE64wtlexchp2sandvi_-- From nobody Wed Apr 27 06:52:16 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 4F4B912D820 for ; Wed, 27 Apr 2016 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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, 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 nuviM-QijbkH for ; Wed, 27 Apr 2016 06:52:07 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5066B12D5AC for ; Wed, 27 Apr 2016 06:51:45 -0700 (PDT) Received: from [85.158.139.3] by server-3.bemta-5.messagelabs.com id CE/C9-14148-FE3C0275; Wed, 27 Apr 2016 13:51:43 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRWlGSWpSXmKPExsVybg1jku77wwr hBvf61SyWzlO3ePJgK7sDk8eU3xtZPZYs+ckUwBTFmpmXlF+RwJpxb0JkwVaJijez3rI0MPZI dDFyckgI+Enc3zSJvYuRi0NIYD+jxORLb9hAEkICNxgldjcFQyROMkp8u3eVHSTBJmApsWLzb FYQW0QgSKK7eSJYg7CAlcT3bXcYIeLWEvtOQtSLCOhJ/Fn/kwnEZhFQlZi0vpEZxOYFqu+8NQ mshlFATOL7qTVgNcwC4hK3nsxngrhOQGLJnvPMELaoxMvH/8D2igLN7P2+kx0iriNx9voTRgj bQGLr0n0sELa8xM0JILdxAM3UlFi/Sx9ivL3ErvUdzBC2osSU7ofsEOcISpyc+QSqVVLi4Iob LJBwUJb4tX8PIyQcFjJKbO6cxwwyUwJo0Pte7wmM0rOQXD0LYdssJNtmIdk2C8m2BYysqxjVi 1OLylKLdE31kooy0zNKchMzc3QNDUz1clOLixPTU3MSk4r1kvNzNzECY5wBCHYwful3PsQoyc GkJMrLuUIhXIgvKT+lMiOxOCO+qDQntfgQowwHh5IE75RDQDnBotT01Iq0zBxgsoFJS3DwKIn wHgdJ8xYXJOYWZ6ZDpE4xKkqJ804GSQiAJDJK8+DaYAnuEqOslDAvI9AhQjwFqUW5mSWo8q8Y xTkYlYR5uYDpUognM68EbvoroMVMQIsvH5IFWVySiJCSamDUZXj5mYHBTS5kx+EDjsXs82dUb Ols+/Zgd8ruO20i69oX/izeXXVv84LTe17/9eqz2bzqi9LtS8H6c+9UuWbHxUdvj80/xvAlK4 tPqX/71E2pvIr3jFujix6vDb154fsHTouH/db60/8f3LOwmu96VsKp71+1LFyZZL9dDjh978C x8y///z/0RYmlOCPRUIu5qDgRAKpC1DdrAwAA X-Env-Sender: daniel.bernier@bell.ca X-Msg-Ref: server-3.tower-90.messagelabs.com!1461765102!35411202!1 X-Originating-IP: [206.172.1.98] X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32503 invoked from network); 27 Apr 2016 13:51:43 -0000 Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (206.172.1.98) by server-3.tower-90.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 27 Apr 2016 13:51:43 -0000 X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE01-DOR.bell.corp.bce.ca Received: from DG3MBX02-WYN.bell.corp.bce.ca (198.235.121.230) by EX13EDGE01-DOR.bell.corp.bce.ca (198.235.121.54) with Microsoft SMTP Server id 15.0.1076.9; Wed, 27 Apr 2016 09:46:28 -0400 Received: from DG3MBX04-WYN.bell.corp.bce.ca (2002:8eb6:121a::8eb6:121a) by DG3MBX02-WYN.bell.corp.bce.ca (2002:8eb6:1218::8eb6:1218) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 09:51:41 -0400 Received: from DG3MBX04-WYN.bell.corp.bce.ca ([fe80::442:b9b4:718c:9736]) by DG3MBX04-WYN.bell.corp.bce.ca ([fe80::442:b9b4:718c:9736%22]) with mapi id 15.00.1104.000; Wed, 27 Apr 2016 09:51:42 -0400 From: "Bernier, Daniel (520165)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-nsh "first nibble" issue Thread-Index: AQHRoIvtAP2rM7kGNU6DrnZCeYW/VQ== Date: Wed, 27 Apr 2016 13:51:41 +0000 Message-ID: <420F91E3-0580-4FA2-B5C6-3343EE0F41AB@bell.ca> 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: [172.24.25.8] Content-Type: text/plain; charset="utf-8" Content-ID: <08A68CB2F5E8F34292AD8AE10F1FB654@exchange.bell.ca> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Received-SPF: SoftFail (EX13EDGE01-DOR.bell.corp.bce.ca: domain of transitioning daniel.bernier@bell.ca discourages use of 198.235.121.230 as permitted sender) X-OrganizationHeadersPreserved: EX13EDGE01-DOR.bell.corp.bce.ca Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue 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, 27 Apr 2016 13:52:14 -0000 KzENCg0KLSBEYW5pZWwgQmVybmllciB8IEJlbGwgQ2FuYWRhDQoNCkZyb206IHNmYyA8c2ZjLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IEppbSBHdWljaGFyZCA8amd1aWNoYXJAY2lzY28uY29tPG1haWx0bzpqZ3VpY2hhckBjaXNjby5j b20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBBcHJpbCAyNywgMjAxNiBhdCA3OjU3IEFNDQpUbzogInNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2Zj QGlldGYub3JnPj4NClN1YmplY3Q6IFtzZmNdIGRyYWZ0LWlldGYtc2ZjLW5zaCAiZmlyc3Qgbmli YmxlIiBpc3N1ZQ0KDQpEZWFyIFdHOg0KDQpUaGUgaW5mYW1vdXMg4oCcTVBMUyBmaXJzdCBuaWJi bGXigJ0gaXNzdWUgd2FzIHJhaXNlZCBhcyBwYXJ0IG9mIHRoZSBXR0xDIGZvciBkcmFmdC1pZXRm LXNmYy1uc2gtMDQuIFdoaWxlIHRoaXMgaXNzdWUgaGFzIGJlZW4ga25vd24gZm9yIHNvbWUgdGlt ZSwgYW5kIHdvcmsgaGFzIGJlZW4gZG9uZSBieSB0aGUgY29tbXVuaXR5IHRvIHRyeSBhbmQgbWl0 aWdhdGUgKGZvciBleGFtcGxlIFJGQzQ5MjgpIG9yIHJlbW92ZSBpdCAoZm9yIGV4YW1wbGUgUkZD Njc5MCksIGdpdmVuIHRoZSB3aWRlc3ByZWFkIGltcGxlbWVudGF0aW9uIG9mIGV4aXN0aW5nIGhh cmR3YXJlIHRoYXQgdXNlcyB0aGUgZmlyc3QgbmliYmxlIGZvciBFQ01QIGRlY2lzaW9uIHByb2Nl c3NpbmcsIGl0IHNlZW1zIHBydWRlbnQgZm9yIHVzIGFzIGEgV0cgdG8gYWRkcmVzcyBpdCBpbiB0 ZXJtcyBvZiBob3cgaXQgYWZmZWN0cyBvdXIgU0ZDIHByb3RvY29sIGFuZCBtYWtlIGl0IGNsZWFy IHdpdGhpbiB0aGUgZHJhZnQgdGhlIGNvbmNsdXNpb24gb2YgdGhlIFdHLg0KDQpXaGlsZSBpdCBp cyB0cnVlIHRoYXQgd2UgY291bGQgcmVhcnJhbmdlIG91ciBlbmNhcHN1bGF0aW9uIGhlYWRlciBz dWNoIHRoYXQgaXQgYXZvaWRzIHRoaXMgaXNzdWUgKGJ5IHNpbXBseSBtYWtpbmcgdGhlIGZpcnN0 IG5pYmJsZSBjb3JyZXNwb25kIHRvIGEgdmFsdWUgdGhhdCBpcyBuZWl0aGVyIDB4NCBvciAweDYp LCBnaXZlbiBtdWx0aXBsZSBpbmR1c3RyeSBhbmQgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25z IG9mIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBoZWFkZXIsIHRoYXQgaXMgbm90IGEgZGVzaXJlZCBv dXRjb21lLCBlc3BlY2lhbGx5IGFzIG11bHRpcGxlIG90aGVyIHRyYW5zcG9ydCBlbmNhcHN1bGF0 aW9ucyBkbyBub3QgZXhoaWJpdCB0aGlzIGJlaGF2aW9yIHdoZW4gY291cGxlZCB3aXRoIHRoZSBT RkMgZW5jYXBzdWxhdGlvbi4NCg0KSWYgd2UgY29uc2lkZXIgdGhlIGN1cnJlbnQgZGVmaW5pdGlv biBvZiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gYmFzZSBoZWFkZXIsIHdlIGNhbiBzZWUgdGhhdCB0 aGUgZmlyc3QgdHdvIGJpdHMgYXJlIHVzZWQgYXMgYSB2ZXJzaW9uIGZpZWxkLiBUaGlzIG1lYW5z IHRoYXQgaWYgd2UgZXZlciBwcm9kdWNlIGEgdmVyc2lvbiAwMSBmb3IgTlNIIGl0IGNvdWxkIHJl c3VsdCBpbiBhIHZhbHVlIG9mIDB4NCBvciAweDYgYmVpbmcgcHJlc2VudCB3aXRoaW4gdGhlIGZp cnN0IG5pYmJsZS4gVG8gYXZvaWQgc3VjaCBhIHJlc3VsdCB0aGUgc2ltcGxlc3Qgc29sdXRpb24g d291bGQgYmUgdG8gcmVzZXJ2ZSB3aXRoaW4gdGhlIFNGQyBlbmNhcHN1bGF0aW9uIHNwZWNpZmlj YXRpb24gdmVyc2lvbiAwMSBhbmQgbWFrZSBpdCBjbGVhciB3aXRoaW4gdGhlIHRleHQgdGhhdCB0 aGlzIGlzIHJlc2VydmVkIGFuZCBzaG91bGQgbm90IGJlIHVzZWQgaW4gZnV0dXJlIHZlcnNpb25z IG9mIHRoZSBwcm90b2NvbC4gSWYgd2UgZXZlciBjaGFuZ2UgdGhlIHZlcnNpb24sIHdoaWNoIGlu Y2lkZW50YWxseSBzaG91bGQgYmUgYSByYXJlIHRoaW5nLCB3ZSB3b3VsZCB0aGVyZWZvcmUganVt cCBmcm9tIHZlcnNpb249MDAgdG8gdmVyc2lvbj0wMiAoaS5lLiBtYWtpbmcgdmVyc2lvbiAxIOKA mHJlc2VydmVk4oCZKSB0aGVyZWJ5IGF2b2lkaW5nIGFueSBjbGFzaCBpbiB0aGUgZmlyc3Qgbmli YmxlLg0KDQpJTUhPIHRoaXMgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgYXBwcm9hY2ggdG8gdGhl IHByb2JsZW0gYnV0IEkgd291bGQgbGlrZSB0byBoZWFyIG9waW5pb25zIGZyb20gdGhlIFdHIGFz IHRvIHdoZXRoZXIgdGhpcyBpcyBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uIGFuZCBpZiB3ZSBjYW4g cmVhY2ggY29uc2Vuc3VzLCBhc2sgdGhlIGVkaXRvcnMgb2YgZHJhZnQtaWV0Zi1zZmMtbnNoIHRv IGFkZCB0ZXh0IHRvIHJlZmxlY3QgaXQuDQoNCkppbQ0K From nobody Wed Apr 27 07:04:16 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 97ED212D80E for ; Wed, 27 Apr 2016 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 W6tLBlSZ7dqE for ; Wed, 27 Apr 2016 07:04:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99F012D1D3 for ; Wed, 27 Apr 2016 07:04:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B39C2240E6E; Wed, 27 Apr 2016 07:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461765849; bh=O1M1Z8RRSzFj2UgyatgmUtVBeGL3d+j6A3HrzMN2XMU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=E3fl53uuTz3I+0ITJEsIzHOFv4gtRMpHGMg1EZRxQASkvDj67Cp76RBM3SX5iGdCC 8CySWDm82PALQ4gaQQ5pMBZZ+IfTzXzQcOObinIH6t2bZjdFMqOJbV5VMllcX6gYUs GoYfEPzsIdkbpiqYT+vI0PtRTgjY82U8hBKPcnhs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3240E240828; Wed, 27 Apr 2016 07:04:08 -0700 (PDT) To: mohamed.boucadair@orange.com, Ron Parker , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D604F7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Wed, 27 Apr 2016 10:03:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D604F7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 27 Apr 2016 14:04:12 -0000 On the Classifier<->SFF communication, you have a fiar point. My personal model is off in that regard. My apologies. I believe that the assumption there is that just as with an SFF, it will use a local means to couple to a transport encapsulator. I tend to think of this as putting an SFF co-located with the classifier, and then using SFF functionality, but that is not required by the architecture. The external behavior of the SFF,_>SF interface, where the SF speaks NSH, is that an NSH encapsulated frame is communicated between the two. The transport mechanism (which may need to fragment) is out of scope. Yours, Joel On 4/27/16 1:46 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, Med > >> -----Message d'origine----- De : Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Envoyé : mardi 26 avril 2016 19:22 À : >> Ron Parker; Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; Elzur, >> Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> At least so far, we have treated the communication between >> classifier and SFF (ingress or intermediate) as outside of the >> scope of our work. > > [Med] I'm afraid I don't get this one. Isn't this what is depicted in > https://tools.ietf.org/html/rfc7665#section-4? > >> For SF <-> SFF communication we have ntoed the need for a proxy to >> handle the case when the SF can not accept and return the NSH >> header, since we assume that is preserved. Other than that >> preservation, similar to the above, we have treated the details as >> outside of our scope. That is because they depend so heavily on the >> implementation technique used. (Hypervisor ,_> application >> communication vs communication inside a user space or communication >> over an actual Ethernet are all very different.) > > [Med] Specifying the external behavior of the interface between an > SFF and an SFC-aware SF is completely in scope, imho. > >> >> Trying to extend the NSH document to address these would be a >> major change, and would step into the issues related to transport >> selection, which are explicitly out of scope. >> >> Yours, Joel >> >> On 4/26/16 11:58 AM, Ron Parker wrote: >>> Linda, >>> >>> I like the first clause (transport tunnel based fragmentation). >>> >>> Regarding the second (source based), I think there are more >>> subcases to >> consider: >>> >>> 1. Propagation of NSH encapsulated packet from classifier to >>> SFF 2. Propagation of NSH encapsulated packet from SFF to SF 3. >>> Propagation of NSH encapsulated packet from SF to SFF (including >> possibility that NSH size increased at SF) >>> 4. Propagation of NSH encapsulated packet from SFF to SFF >>> >>> In each of the 4 cases above, there is the possibility that MTU >>> will be >> exceeded and therefore there are procedures to be defined in that >> eventuality. >>> >>> Thanks. >>> >>> Ron >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: >>> Tuesday, April 26, 2016 11:48 AM To: Joel M. Halpern >>> ; mohamed.boucadair@orange.com; >> Elzur, Uri ; sfc@ietf.org >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Joel, >>> >>> I think the document should add the description on the following >>> two >> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a packet >>> fragmentation is caused by transport tunnel (i.e. >> various encapsulations), the termination point of the transport >> tunnel is responsible for re-assembling the fragmented pieces of >> the packet. Since there won't be any SFF nodes in between the >> Transport Tunnel, the tunnel generated fragmentation does not >> require any actions by SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on the NSH >>> header): When fragmentation has to be performed for a packet >>> being >> encapsulated with the NSH header, either the intermediate SFF nodes >> or the SF nodes have to be able to reassemble the fragmented >> pieces. >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 >>> AM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are referring only >>> to the >> case of transport generated fragmentation of the outer packet. I >> had assumed you were not talking about that, since the resulting >> fragments will not all have NSH headers. As with any tunnel >> technology, if the tunnel chooses to fragment at its layer, then >> the tunnel is responsible for reassembly. That would be invisible >> to the SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>> Agree with Med. >>>> >>>> Even if each fragment piece of a packet with NSH header carries >>>> the NSH >> header, the intermediate SFF nodes still need to put together all >> the fragments together before passing the whole data frame to the >> SF. >>>> >>>> Linda >>>> >>>> -----Original Message----- From: sfc >>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>> mohamed.boucadair@orange.com Sent: Monday, April 25, 2016 9:42 >>>> AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: Re: >>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-, >>>> >>>> How do you instruct the transport layer to ALWAYS prepend an >>>> NSH header >> even for fragments? Or you don't care about that? >>>> >>>> Thank you. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Elzur, Uri >>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 >>>>> 16:26 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH >>>>> is *NOT* a transport, dealing with fragmentation is left to >>>>> the Transport used. >>>>> >>>>> The model I use for NSH, is basically similar to VXLAN . It >>>>> is an >> overly. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- From: sfc >>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>> mohamed.boucadair@orange.com Sent: Monday, April 25, 2016 >>>>> 7:18 AM To: Joel M. Halpern ; >>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>> draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Joel, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Joel M. Halpern >>>>>> [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 avril 2016 >>>>>> 15:48 À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : >>>>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> If I am understanding you correctly Med, you are asking >>>>>> that the NSH draft specify how service chaining should cope >>>>>> with packets that have been fragmented? >>>>>> >>>>> >>>>> [Med] To be accurate, I'm asking to assess whether there are >> implications. >>>>> If there are, then the draft should be updated accordingly. >>>>> >>>>>> NSH, and the SFF functionality, does not care. >>>>> >>>>> [Med] I'm not that sure. Some typical implications are listed >>>>> below: >>>>> >>>>> * SFF: If the NSH header is present only in the a fragment >>>>> but SFF didn't maintained a state, subsequent fragments won't >>>>> be appropriately >> processed. >>>>> * SFC-aware function: if prepending a context information >>>>> depends on the full packet, not only a fragment. >>>>> >>>>> It just does its job. >>>>> >>>>> [Med] which may be disturbed in some situations as listed in >>>>> the examples above. >>>>> >>>>>> Ingress and intermediate classifiers may cope with >>>>>> fragments in any number of ways. >>>>> Specifying such is clearly out of scope for this draft. >>>>> >>>>> [Med] The purpose is not to specify the internal >>>>> implementation details but the external behavior of the >>>>> classifier function when it comes to handle fragments. That >>>>> behavior may have an incidence on SFF, in particular. The >>>>> purpose is not to recommend the maximum resources to be >>>>> dedicated to out of order fragments nor the timeout to cache >>>>> those; these considerations are of course out of scope. >>>>> Nevertheless, an implementation should offer a configurable >>>>> parameter so that an operator tweak those according to its >>>>> context. >>>>> >>>>>> I suppose one could write an informational draft on >>>>>> possible ways of coping. The IETF has not usually >>>>>> published such. Service functions have to cope with >>>>>> fragmented packets just as they had to before the advent of >>>>>> NSH, so describing that is clearly not needed here. >>>>> >>>>> [Med] The advent of NSH has the following implications: * it >>>>> exacerbates fragmentation. Handing over this issue to the >>>>> transport layer may lead to interoperability issues. * the >>>>> chaining may not be efficient if fragments are >>>>> inappropriately handled. >>>>> >>>>> Introducing NSH should not degrade the overall service >>>>> compared to legacy service deployment schemes. >>>>> >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Re-, >>>>>>> >>>>>>> I hear you, but my comment is that we need, as a WG, to >>>>>>> decide what to >>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>> issues: >>>>>>> >>>>>>> (1) Fragmentation that is caused by prepending an SFC >>>>>>> header. (2) Handling fragments at the ingress of an >>>>>>> SFC-enabled domain. >>>>>>> >>>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>>> explicitly >>>>>> called out in the text (see my first message). >>>>>>> >>>>>>> There are other issues that need to be discussed, e.g., >>>>>>> how to deal with >>>>>> fragments in SFFs/Classifiers? >>>>>>> >>>>>>> It is also "prudent" to check that no issues will be >>>>>>> experienced in SFF >>>>>> to handle fragments. If an SFC header is prepended for all >>>>>> fragments, I'm not sure there >>>>>>> is any particular issue at the SFF level, except if >>>>>>> stripping/adding >>>>>> context TLVs depends on the full packet (not just >>>>>> fragment). It is warranted to consider a little bit this >>>>>> point before declaring there is no issue. >>>>>>> >>>>>>> For point (1), declaring fragmentation out of scope would >>>>>>> be meant that >>>>>> an implementation must be prepared to receive fragments >>>>>> with or without NSH header as this is a decision that is >>>>>> left to the transport encapsulation. This is a requirement >>>>>> per se! >>>>>>> >>>>>>> I won't reiterate all the comments I have about the >>>>>>> current wording of >>>>>> this section. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril >>>>>>>> 2016 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas >>>>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call >>>>>>>> for draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> My point is that Fragmentation is yet another transport >>>>>>>> related issue >>>>>> that >>>>>>>> is beyond the scope of NSH and beyond the charter of >>>>>>>> the WG, so it >>>>>> doesn't >>>>>>>> really belong in the draft. We are providing an advice >>>>>>>> as extending the size of the packet may lead to >>>>>>>> fragmentation, but as you check RFC 7348 VxLAN, which >>>>>>>> my create the same issue, you'll find it doesn't even >>>>>> relate >>>>>>>> to it. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, >>>>>>>> 2016 10:32 PM To: Elzur, Uri ; >>>>>>>> Thomas Narten >>>>>> ; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Uri, >>>>>>>> >>>>>>>> That's another option that needs to be >>>>>>>> discussed/investigated. I'm >>>>>> afraid >>>>>>>> this is not the rationale adopted in -04 since it >>>>>>>> includes some text >>>>>> that >>>>>>>> is far to be sufficient to ensure interoperable >>>>>>>> implementations. >>>>>>>> >>>>>>>> BTW, saying that nsh does not need to deal with >>>>>>>> fragmentation because >>>>>> it >>>>>>>> is transport-independent is not IMHO a good strategy to >>>>>>>> adopt here >>>>>> because >>>>>>>> it opens the door for interoperable issues, it may lead >>>>>>>> to sub-optimal implementations if the sfc information >>>>>>>> is present only in one >>>>>> fragments, >>>>>>>> etc. >>>>>>>> >>>>>>>> My comments are related to the current text in the -04. >>>>>>>> This text needs >>>>>> to >>>>>>>> be fixed somehow. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 >>>>>>>>> avril 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; >>>>>>>>> Thomas Narten; sfc@ietf.org Objet : RE: [sfc] WG last >>>>>>>>> call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> I see no need to specify the exact behavior as NSH is >>>>>>>>> transport independent i.e. like NSH interaction with >>>>>>>>> any other Transport eh issue of Fragmentation is to >>>>>>>>> be dealt in a way that matches the mechanisms >>>>>>>>> supported by the Transport used and do not belong in >>>>>>>>> the NSH draft >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April >>>>>>>>> 14, 2016 12:43 AM To: Thomas Narten >>>>>>>>> ; sfc@ietf.org Subject: Re: [sfc] >>>>>>>>> WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> R-, >>>>>>>>> >>>>>>>>> In addition to other pending issues raised for this >>>>>>>>> draft, I would like to raise this additional one >>>>>>>>> about Section 6. >>>>>>>>> >>>>>>>>> == 6. Fragmentation Considerations >>>>>>>>> >>>>>>>>> NSH and the associated transport header are "added" >>>>>>>>> to the encapsulated packet/frame. This additional >>>>>>>>> information increases >>>>>> the >>>>>>>>> size of the packet. In order the ensure proper >>>>>>>>> forwarding of >> NSH >>>>>>>>> data, several options for handling fragmentation and >>>>>>>>> re- >> assembly >>>>>>>>> exist: >>>>>>>>> >>>>>>>>> 1. Jumbo Frames, when supported, enable the >>>>>>>>> transport of NSH >> and >>>>>>>>> associated transport packets without requiring >> fragmentation. >>>>>>>>> >>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a >>>>>>>>> technique for dynamically discovering the maximum >>>>>>>>> transmission unit (MTU) of >>>>>> an >>>>>>>>> arbitrary internet path" and can be utilized to >>>>>>>>> ensure the >>>>> the >>>>>>>>> required packet size is used. >>>>>>>>> >>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation >>>>>>>>> and re- >>>>>> assembly >>>>>>>>> in section 5.4. == >>>>>>>>> >>>>>>>>> * The text is weak for a Standard track document that >>>>>>>>> is intended to solve the problem in >>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>> 2.12. >>>>>>>>> There should be a clear behavior to be followed by >>>>>>>>> an >>>>> implementation. >>>>>>>>> Further, I would avoid the use of words such as >>>>>>>>> "can". >>>>>>>>> >>>>>>>>> * The text covers only fragmentation when it is >>>>>>>>> induced by SFC operations, it does not discuss the >>>>>>>>> treatment of a fragment when received in an SFC >>>>>>>>> domain. IMHO, the draft should also specify the >>>>>>>>> behavior of the Classifier with regards to fragments >>>>>>>>> for the sake of proper SFC operation. Applying >>>>>>>>> classification policies may require the >>>>>>>> full packet, not only a fragment. >>>>>>>>> In particular, dedicated resources should dedicated >>>>>>>>> for handling out of order fragments. Of course, it is >>>>>>>>> out of scope of this document to describe how SFs >>>>>>>>> handle fragments. >>>>>>>>> >>>>>>>>> * If an SFC header is prepended for all fragments, >>>>>>>>> I'm not sure there is any particular issue at the SFF >>>>>>>>> level...except if stripping/adding context TLVs >>>>>>>>> depends on the full packet (not just fragment). It is >>>>>>>>> warranted to consider a little bit this point before >>>>>>>>> declaring there >>>>>> is >>>>>>>> no issue. >>>>>>>>> >>>>>>>>> * The text states "several options". This may be >>>>>>>>> interpreted as if implementing one of them is >>>>>>>>> sufficient...which is not true. The first two points >>>>>>>>> contribute to minimize the fragmentation risk, but >>>>>>>>> fragmentation may still be experienced (e.g., other >>>>>>>>> shims are prepended by other nodes for some other >>>>>>>>> purposes, nested nsh, etc.) >>>>>>>>> >>>>>>>>> * The first two points have nothing to do with >>>>>>>>> reassembly. >>>>>>>>> >>>>>>>>> * The support of jumbo frames by a router/device does >>>>>>>>> not mean that it can make use of it. Appropriate MTU >>>>>>>>> configuration should be undertaken in a consistent >>>>>>>>> manner within an SFC domain. The text should be >>>>>>>>> updated to make it is about (consistent) MTU >>>>> configuration. >>>>>>>>> >>>>>>>>> * BTW, shouldn't the text be reworded to recommended >>>>>>>>> to increase the MTU of **all nodes** of an >>>>>>>>> SFC-enabled domain by at least the length of SFC >>>>>>>>> header + transport header? >>>>>>>>> >>>>>>>>> * Bullet 2, how PMTU discovery is actually used in >>>>>>>>> this context? Do you assume that all SFC-aware nodes >>>>>>>>> will issue such messages towards other SFC-aware >>>>>>>>> node, arbitrary destination, else? >>>>>>>>> >>>>>>>>> * Bullet 2, I would drop "describes a technique for >>>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>> >>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>> >>>>>>>>> * The reference to the LISP specification raises two >>>>>>>>> concerns and one comment: >>>>>>>>> >>>>>>>>> (1) I don't think it is a good approach that >>>>>>>>> fragments induced by the network are passed to their >>>>>>>>> ultimate destinations as such >>>>> (stateless). >>>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>>> (responsible for fragmentation) not passed away. (2) >>>>>>>>> Does the stateful mode require all SFC data plane >>>>>>>>> elements maintain a full list of MTU for the any >>>>>>>>> SFF/SF instance of the SFC >>>>>>>> domain? >>>>>>>>> >>>>>>>>> The current text suggests that [RFC6830] should be >>>>>>>>> listed as normative reference (not an informative >>>>>>>>> one). I would personally favor removing the reference >>>>>>>>> to LISP (as it is an Experimental >> RFC). >>>>>>>>> >>>>>>>>> * The security section of the draft may be augmented >>>>>>>>> with informational fragmentation-related pointers to: >>>>>>>>> e.g., RFC1858 (Security Considerations for IP >>>>>>>>> Fragment Filtering), RFC3128 (Protection Against a >>>>>>>>> Variant of the Tiny Fragment Attack), and RFC 4963 >>>>>>>>> (IPv4 Reassembly Errors at High Data Rates). >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 >>>>>>>>>> avril 2016 13:14 À >> : >>>>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG >>>>>>>>>> last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear Thomas, all, >>>>>>>>>> >>>>>>>>>> As I mentioned during the meeting, there are >>>>>>>>>> several issues that are not covered in the last >>>>>>>>>> version of the draft. I already provided examples >>>>>>>>>> of the issues offline as requested by Martin. >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>>>> Thomas Narten Envoyé : jeudi 31 mars 2016 04:48 À >>>>>>>>>>> : sfc@ietf.org Objet : [sfc] WG last call for >>>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear WG: >>>>>>>>>>> >>>>>>>>>>> This note begins a WG last call on >>>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The editors of the NSH document have indicated that they have >>>>>>>>>>> addressed all known comments and that there are >>>>>>>>>>> no open issues with the current version of the >>>>>>>>>>> document. >>>>>>>>>>> >>>>>>>>>>> Substantive comments to the list please, >>>>>>>>>>> editorial comments can go directly to the >>>>>>>>>>> document editors. >>>>>>>>>>> >>>>>>>>>>> We'll also get a brief update from the editors at >>>>>>>>>>> next week's meeting. If there are any remaining >>>>>>>>>>> issues with the document, raising them before the >>>>>>>>>>> meeting would be especially helpful. >>>>>>>>>>> >>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> sfc mailing list sfc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc >>>>>>>>>> mailing list sfc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc >>>>>>>>> mailing list sfc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc >>>>>>>> mailing list sfc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>> >>>>> _______________________________________________ sfc mailing >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >>> _______________________________________________ sfc mailing list >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Wed Apr 27 07:16:26 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 8634D12D1C2 for ; Wed, 27 Apr 2016 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 4dI3fVTziy7F for ; Wed, 27 Apr 2016 07:16:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C6812D80B for ; Wed, 27 Apr 2016 07:16:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B7EBC240EFB for ; Wed, 27 Apr 2016 07:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461766582; bh=gSKc7U+Uea+/OsXTmbYvf3CheDa001KLDcRiIKWMcxg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VuHW//xHUqNIAI7FGkmcSIqkLok1HtTx2BrtKS/JzXQlVvrpS828k3QvL+sM6aEK4 gnUbJkZQqkhaFWW+3Ua3h6bbiPXlcoJJcb/KLBAAR+IImJ8DervhFN4sKamOkyoVte Ex1ENz1bZBOJIdMqz4yylvDNT7TPxmo57mUqtKmc= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 55EB2240828 for ; Wed, 27 Apr 2016 07:16:22 -0700 (PDT) To: "sfc@ietf.org" References: From: "Joel M. Halpern" Message-ID: <5e632481-0ea6-7974-e05f-b35c2fce82a6@joelhalpern.com> Date: Wed, 27 Apr 2016 10:16:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue 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, 27 Apr 2016 14:16:25 -0000 This seems to be the best of the available choices. I will note that in the absence of widespread support of RFC 6790, the best we can get is avoiding mistakes. NSH will not be handled well by MPLS based ECMP or LAG. The good news is that if 6790 support becomes wide-spread, we can reuse the version number if we then needed it. And of course we can always use the 11 version as an escape to use some other bits for further versions in the unlikely event that such becomes necessary. Yours, Joel On 4/27/16 7:57 AM, Jim Guichard (jguichar) wrote: > Dear WG: > > The infamous “MPLS first nibble” issue was raised as part of the WGLC > for draft-ietf-sfc-nsh-04. While this issue has been known for some > time, and work has been done by the community to try and mitigate (for > example RFC4928) or remove it (for example RFC6790), given the > widespread implementation of existing hardware that uses the first > nibble for ECMP decision processing, it seems prudent for us as a WG to > address it in terms of how it affects our SFC protocol and make it clear > within the draft the conclusion of the WG. > > While it is true that we could rearrange our encapsulation header such > that it avoids this issue (by simply making the first nibble correspond > to a value that is neither 0x4 or 0x6), given multiple industry and open > source implementations of the SFC encapsulation header, that is not a > desired outcome, especially as multiple other transport encapsulations > do not exhibit this behavior when coupled with the SFC encapsulation. > > If we consider the current definition of the SFC encapsulation base > header, we can see that the first two bits are used as a version field. > This means that if we ever produce a version 01 for NSH it could result > in a value of 0x4 or 0x6 being present within the first nibble. To avoid > such a result the simplest solution would be to reserve within the SFC > encapsulation specification version 01 and make it clear within the text > that this is reserved and should not be used in future versions of the > protocol. If we ever change the version, which incidentally should be a > rare thing, we would therefore jump from version=00 to version=02 (i.e. > making version 1 ‘reserved’) thereby avoiding any clash in the first > nibble. > > IMHO this seems like a reasonable approach to the problem but I would > like to hear opinions from the WG as to whether this is an acceptable > solution and if we can reach consensus, ask the editors of > draft-ietf-sfc-nsh to add text to reflect it. > > Jim > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Apr 27 07:17:42 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 6940012D80B for ; Wed, 27 Apr 2016 07:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 uJk5LIBhF9N6 for ; Wed, 27 Apr 2016 07:17:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3EF12D129 for ; Wed, 27 Apr 2016 07:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12870; q=dns/txt; s=iport; t=1461766658; x=1462976258; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mvlaC+dvlKtMxwo+7NWE4H0P1rgfMpq9oCr3Sb3g0uE=; b=fyc8oLpTXAn72wQhAbraUri1enCt76MIdjb0JmPlFTir+PF5JgFbkNBx kbBkzqqBSS+Z5ZB3+IksN+tuVRarQhZC1ibcXzxMSkM2r4C23u5LJyjVd 0VIDvolzjSL1WjTcl0+2x1n5QOBUxPBTZEJds6Y0E/qQ9vHTfOuxqRc/3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQA3ySBX/4UNJK1egmxMU30GhB+BI?= =?us-ascii?q?qhIhmqEcwENgXUXAQqEFoFXAoEsOBQBAQEBAQEBZSeEQgEBBAEBASRHBBcCAQg?= =?us-ascii?q?OBC0HIQYLFAMOAgQBEogVAxIOvzsNhGEBAQEBAQEEAQEBAQEBARUEhiGES4JBg?= =?us-ascii?q?jKFIAWODIUAhFMxAYwggXaBZ4RNgyl7hDmHUYdeAR4BAUKBTIIfbIgvfwEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,541,1454976000"; d="scan'208,217"; a="98292474" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2016 14:17:36 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3REHaXn026251 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 14:17:36 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.1104.5; Wed, 27 Apr 2016 09:17:36 -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.1104.009; Wed, 27 Apr 2016 09:17:36 -0500 From: "Jim Guichard (jguichar)" To: Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1hgqCe3Pkr6EKnc83IMsxhI5+d714A Date: Wed, 27 Apr 2016 14:17:35 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> In-Reply-To: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D34629264C3CAjguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 14:17:41 -0000 --_000_D34629264C3CAjguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_D34629264C3CAjguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9A56D69232795A46A0CA82CB3FDCF6BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Martin & WG:

A few comments that I woul= d like to see addressed in the document before it can move forward to the n= ext step.
  • Section 2.2 SFC Control Plane Bootstrapping.
This section is too wishy = washy. It makes the statement “this document assumes the SFC control = plane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

Minor point -> typo in = bullet point 6 – SFP proxy should read SFC proxy
  • Section 2.3 Coherent Setup of an SFC-enabled Domain
What does the sentence = 220;various transport encapsulation schemes and/or variations of SFC header= implementations may be supported” actually mean ? Are we referring t= o the fact that the SFC header may carry type-1 or type-2 metadata or something else ? Note that there is only one = SFC header implementation based on the WG charter so if we are referring to= different SFC formats (meaning metadata) then please make this clear in th= e text, and if not, please remove this sentence. 
  • Section 3.1 Reference Architecture
Second bullet point “= ;mapping between service function chains and SFPs” - this is a genera= l comment for the entire document but applies here also. There is no mentio= n of mapping SFPs -> RSPs – in fact RSP is mentioned only once in the entire document. The architecture is explicit in that the= SFP when rendered into the network is an RSP and therefore the SFC control= plane element needs to have information on currently deployed RSPs.

Additionally there is no i= nterface specified for communication between the SFC Control Plane Element = and SF management systems. This is an important aspect as many SF’s m= ay require that SFC information be communicated to their management systems that will be responsible for communicating dir= ectly with their respective SF’s. 
  • Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classi= fier
The sentence &#= 8220;The control plane may instruct the classifier about the initial values= of the Service Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. 
  • Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets
    • =
This section does not actually provide any meaning or indication of re= lationship with the SFC Control Plane element. Furthermore,  there has= been no WG consensus to carry source routes within the SFC encapsulation. = Therefore this entire section should be removed from the document.
  • Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP
Figure 2 lists 3 different SFP-id’s whereas the text mentions on= ly SFP-id #1. Is this simply a typo or are you trying to convey something e= lse ?

Further you state that “the steering policies to a SFF node for = service function chain depends on if the packet comes from previous SFF or = comes from a specific SF i.e., the SFP Forwarding Table entries have to be = ingress port specific” -  this is an inaccurate statement as the combination of the SFP-id and service-index determines th= e forwarding behavior (as specified in section 3.3 & section 7 of draft= -ietf-sfc-nsh-04).  This sentence should be removed from the text.

Jim



On 4/27/16, 12:29 AM, &quo= t;sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

Dear all,

This is the start of the Working Group Last Call (WGLC) for

draft-ietf-sfc-control-plane-04.txt

The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT.

Please send your comments and reviews to the sfc@ietf.org list.

Regards,

   Martin (SFC co-chair)

_______________________________________________
sfc mailing list

--_000_D34629264C3CAjguicharciscocom_-- From nobody Wed Apr 27 07:42:34 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 DD7FB12D163 for ; Wed, 27 Apr 2016 07:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 wVTzFEGIlQHS for ; Wed, 27 Apr 2016 07:42:31 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0485212D840 for ; Wed, 27 Apr 2016 07:42:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C2794240828; Wed, 27 Apr 2016 07:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461768150; bh=01oBRivmeQp3kvfJr+FxJh0Vp8R/TYknaBDi3Xl+cqI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d3zCCRhL8svOUNqgbHQfAypANZLit7dyllveeSZuDy/6naynpDETuOzxeJgETa80b tbQQMI5yyvhXZgYY16iHJ4927IvyKCRGj4yt73YJ1oxAn47TlRdMhhxgws5LPhFjZV O61BAur7iaaOcdNR3XRPReEiZM0AvVZjoJCu0+nA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 785DD24032B; Wed, 27 Apr 2016 07:42:29 -0700 (PDT) To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> From: "Joel M. Halpern" Message-ID: <0d8fde59-52b4-507a-46e6-d8fb12489f0c@joelhalpern.com> Date: Wed, 27 Apr 2016 10:42:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 14:42:34 -0000 Jim, I agree with most of your comments below. However, I think your comment regarding RSP is incorrect. Given the way teh architecture is written, the control plane is not required to know the RSP, and in fact the architecture and the NSH header allow for implementations in which the control plane knows the possible paths, but not the RSP that a given flow takes. As such, regarding RSP I believe the document is correct, and the fact that there are almost no reference to RSP is a feature, not a bug. Yours, Joel On 4/27/16 10:17 AM, Jim Guichard (jguichar) wrote: > Hi Martin & WG: > > A few comments that I would like to see addressed in the document before > it can move forward to the next step. > > * Section 2.2 SFC Control Plane Bootstrapping. > > This section is too wishy washy. It makes the statement “this document > assumes the SFC control plane is provided with a set of information that > is _required_ for proper SFC operation” but then goes on to list bullets > that are _likely_ to be provided or _may_ be provided. It does not > actually provide any information on what _is required for proper SFC > operation_. In the list of _likely_ information there is no indication > of whether this information must exist in the network prior to > bootstrapping the SFC control plane element; this is true also for the > list of _may_ information. Surely we should provide guidelines on what > _must_ be available before the SFC control plane element can actually > function although it is reasonable to assume that it can bootstrap > without any information (albeit it can’t actually do anything). On this > point I would argue that several of the _may_ elements are actually > required such as SFF, SF, SFC-proxy locators and may exist prior to > bootstrapping the SFC control plane element, or may be added later > through some control interface. > > Minor point -> typo in bullet point 6 – SFP proxy should read *SFC* proxy > > * Section 2.3 Coherent Setup of an SFC-enabled Domain > > What does the sentence “various transport encapsulation schemes and/or > variations of SFC header implementations may be supported” actually mean > ? Are we referring to the fact that the SFC header may carry type-1 or > type-2 metadata or something else ? Note that there is only *one *SFC > header implementation based on the WG charter so if we are referring to > different SFC formats (meaning metadata) then please make this clear in > the text, and if not, please remove this sentence. > > * Section 3.1 Reference Architecture > > Second bullet point “mapping between service function chains and SFPs” - > this is a general comment for the entire document but applies here also. > There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned > only once in the entire document. The architecture is explicit in that > the SFP when rendered into the network is an RSP and therefore the SFC > control plane element needs to have information on currently deployed RSPs. > > Additionally there is no interface specified for communication between > the SFC Control Plane Element and SF management systems. This is an > important aspect as many SF’s may require that SFC information be > communicated to their management systems that will be responsible for > communicating directly with their respective SF’s. > > * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifier > > The sentence “The control plane may instruct the classifier about the > initial values of the Service Index (SI)” should be changed to say > *MUST* as otherwise if a classifier chooses whatever value it wants then > that may not align with what is programmed into the SFFs by the SFC > Control Plane element. > > * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets > > This section does not actually provide any meaning or indication of > relationship with the SFC Control Plane element. Furthermore, there has > been no WG consensus to carry source routes within the SFC > encapsulation. Therefore this entire section should be removed from the > document. > > * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP > > Figure 2 lists 3 different SFP-id’s whereas the text mentions only > SFP-id #1. Is this simply a typo or are you trying to convey something > else ? > > Further you state that “the steering policies to a SFF node for service > function chain depends on if the packet comes from previous SFF or comes > from a specific SF i.e., the SFP Forwarding Table entries have to be > ingress port specific” - this is an inaccurate statement as the > combination of the SFP-id and service-index determines the forwarding > behavior (as specified in section 3.3 & section 7 of > draft-ietf-sfc-nsh-04). This sentence should be removed from the text. > > Jim > > > > On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" > on behalf of > mls.ietf@gmail.com > wrote: > > Dear all, > > This is the start of the Working Group Last Call (WGLC) for > > draft-ietf-sfc-control-plane-04.txt > > The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. > > Please send your comments and reviews to the sfc@ietf.org > list. > > Regards, > > Martin (SFC co-chair) > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Apr 27 09:02:38 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 858F212B00C for ; Wed, 27 Apr 2016 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 8BgAEZYvsNhP for ; Wed, 27 Apr 2016 09:02:34 -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 E1D0512B006 for ; Wed, 27 Apr 2016 09:02:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNK37639; Wed, 27 Apr 2016 16:02:30 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Apr 2016 17:02:29 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Wed, 27 Apr 2016 09:02:26 -0700 From: Linda Dunbar To: Martin Stiemerling Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1w03Th2ZpF0U6s9T50CcQVUp+eKW8A///SX+A= Date: Wed, 27 Apr 2016 16:02:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7D84D@dfweml501-mbb> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657E7D84Ddfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5720E297.010D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7df78501b731d5c76ed13dd5288eb113 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 16:02:37 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657E7D84Ddfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFydGluLA0KDQpBcyBhIGNvbnRyaWJ1dG9yLCBJIHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhp cyBkcmFmdC4NCg0KVGhhbmtzLA0KTGluZGENCg0KDQpPbiBXZWQsIEFwciAyNywgMjAxNiBhdCAx MjoyOSBBTSwgTWFydGluIFN0aWVtZXJsaW5nIDxtbHMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOm1s cy5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KRGVhciBhbGwsDQoNClRoaXMgaXMgdGhlIHN0YXJ0 IG9mIHRoZSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCAoV0dMQykgZm9yDQoNCmRyYWZ0LWlldGYt c2ZjLWNvbnRyb2wtcGxhbmUtMDQudHh0DQoNClRoZSBXR0xDIGxhc3RzIGZvciAyIHdlZWtzIGFu ZCB3aWxsIGVuZCBNYXkgMTF0aCBhdCAxMCBwbSBQRFQuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgYW5kIHJldmlld3MgdG8gdGhlIHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn PiBsaXN0Lg0KDQpSZWdhcmRzLA0KDQogIE1hcnRpbiAoU0ZDIGNvLWNoYWlyKQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlz dA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657E7D84Ddfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk1hcnRpbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IGEgY29udHJpYnV0b3IsIEkgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Ms PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaW5k YSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDI3LCAyMDE2 IGF0IDEyOjI5IEFNLCBNYXJ0aW4gU3RpZW1lcmxpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzptbHMu aWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tbHMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLDxi cj4NCjxicj4NClRoaXMgaXMgdGhlIHN0YXJ0IG9mIHRoZSBXb3JraW5nIEdyb3VwIExhc3QgQ2Fs bCAoV0dMQykgZm9yPGJyPg0KPGJyPg0KZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS0wNC50 eHQ8YnI+DQo8YnI+DQpUaGUgV0dMQyBsYXN0cyBmb3IgMiB3ZWVrcyBhbmQgd2lsbCBlbmQgTWF5 IDExdGggYXQgMTAgcG0gUERULjxicj4NCjxicj4NClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMg YW5kIHJldmlld3MgdG8gdGhlIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwvYT4gbGlzdC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N Cjxicj4NCiZuYnNwOyBNYXJ0aW4gKFNGQyBjby1jaGFpcik8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNmYyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Zj QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657E7D84Ddfweml501mbb_-- From nobody Wed Apr 27 09:05:48 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 572A012D8AB for ; Wed, 27 Apr 2016 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 d5tF3f6PrqAs for ; Wed, 27 Apr 2016 09:05:44 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97E412D89A for ; Wed, 27 Apr 2016 09:05:44 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0266.001; Wed, 27 Apr 2016 09:05:44 -0700 From: Ron Parker To: Linda Dunbar , Martin Stiemerling Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoHpZsovTIzEGyUKuSOuYMz6Tep+ecMYA//+LjNA= Date: Wed, 27 Apr 2016 16:05:43 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657E7D84D@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7D84D@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B6D787A6DMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 16:05:46 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D787A6DMBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMaW5kYSBEdW5iYXINClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjcsIDIwMTYgMTI6MDIgUE0N ClRvOiBNYXJ0aW4gU3RpZW1lcmxpbmcgPG1scy5pZXRmQGdtYWlsLmNvbT4NCkNjOiBzZmNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBXR0xDIGZvciBkcmFmdC1pZXRmLXNmYy1jb250cm9s LXBsYW5lLTA0LnR4dA0KDQpNYXJ0aW4sDQoNCkFzIGEgY29udHJpYnV0b3IsIEkgc3VwcG9ydCBw dWJsaWNhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpUaGFua3MsDQpMaW5kYQ0KDQoNCk9uIFdlZCwg QXByIDI3LCAyMDE2IGF0IDEyOjI5IEFNLCBNYXJ0aW4gU3RpZW1lcmxpbmcgPG1scy5pZXRmQGdt YWlsLmNvbTxtYWlsdG86bWxzLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpEZWFyIGFsbCwNCg0K VGhpcyBpcyB0aGUgc3RhcnQgb2YgdGhlIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIChXR0xDKSBm b3INCg0KZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS0wNC50eHQNCg0KVGhlIFdHTEMgbGFz dHMgZm9yIDIgd2Vla3MgYW5kIHdpbGwgZW5kIE1heSAxMXRoIGF0IDEwIHBtIFBEVC4NCg0KUGxl YXNlIHNlbmQgeW91ciBjb21tZW50cyBhbmQgcmV2aWV3cyB0byB0aGUgc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+IGxpc3QuDQoNClJlZ2FyZHMsDQoNCiAgTWFydGluIChTRkMgY28t Y2hhaXIpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D787A6DMBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiYjNDM7MTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkxpbmRhIER1bmJhcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI3LCAy MDE2IDEyOjAyIFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gU3RpZW1lcmxpbmcgJmx0O21scy5p ZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3NmY10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFu ZS0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TWFydGluLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgYSBjb250cmlidXRvciwgSSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkxpbmRhIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBcHIgMjcsIDIwMTYgYXQgMTI6 MjkgQU0sIE1hcnRpbiBTdGllbWVybGluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1scy5pZXRmQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1scy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBhbGwsPGJyPg0KPGJy Pg0KVGhpcyBpcyB0aGUgc3RhcnQgb2YgdGhlIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIChXR0xD KSBmb3I8YnI+DQo8YnI+DQpkcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lLTA0LnR4dDxicj4N Cjxicj4NClRoZSBXR0xDIGxhc3RzIGZvciAyIHdlZWtzIGFuZCB3aWxsIGVuZCBNYXkgMTF0aCBh dCAxMCBwbSBQRFQuPGJyPg0KPGJyPg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyBhbmQgcmV2 aWV3cyB0byB0aGUgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0Kc2ZjQGlldGYub3JnPC9hPiBsaXN0Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0K Jm5ic3A7IE1hcnRpbiAoU0ZDIGNvLWNoYWlyKTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B6D787A6DMBX021W3CA2exch_-- From nobody Wed Apr 27 09:14:47 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 DF46012D1E2 for ; Wed, 27 Apr 2016 09:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 gGjSS43Ix5c5 for ; Wed, 27 Apr 2016 09:14:44 -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 4196612D1BC for ; Wed, 27 Apr 2016 09:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6097; q=dns/txt; s=iport; t=1461773684; x=1462983284; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Iw6xoTsGZHQzNkBpQeUArSL6eRqmJBy5alpudFG2cw8=; b=gXevnJMvbb8RDsjs0ZkgnX3Mu9PMrT3fCDSIshbcIvSfDa9hKy8p3hpd /Au16LCA9ALU5H0+KRhZr5xKPclCLMsvWZ0Vo29t+ShqJmAFGt1iddgv1 PnNcCu4vqsQ6gxVIzw+vbF0YSio7J5ooj4FlRo7LZ2xqJ6NfYikAPkhCP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgDc5CBX/5xdJa1egzhTfQauCItdA?= =?us-ascii?q?Q2BdRcLhW0CgS84FAEBAQEBAQFlJ4RBAQEBAwEBAQEkRwQXAgEIEgYnByEGCxQ?= =?us-ascii?q?DDgIEARKIFQMKCA6/JA2EYQEBAQEBAQEBAgEBAQEBAQEVBIYhhEuCQYF8hVYFj?= =?us-ascii?q?gyFAIRTMQGMIIF2gWeETYMpe4Q5h1GHXgEeAQFCg2tsiC9/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,542,1454976000"; d="scan'208";a="264971480" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 16:14:43 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3RGEhWd003260 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 16:14:43 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.1104.5; Wed, 27 Apr 2016 11:14:42 -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.1104.009; Wed, 27 Apr 2016 11:14:42 -0500 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1hgqCe3Pkr6EKnc83IMsxhI5+d714AgABJ9wD//9a+AA== Date: Wed, 27 Apr 2016 16:14:42 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <0d8fde59-52b4-507a-46e6-d8fb12489f0c@joelhalpern.com> In-Reply-To: <0d8fde59-52b4-507a-46e6-d8fb12489f0c@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.74.152] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 27 Apr 2016 16:14:46 -0000 Yes you make a good point and I agree. Jim On 4/27/16, 10:42 AM, "Joel M. Halpern" wrote: >Jim, I agree with most of your comments below. However, I think your >comment regarding RSP is incorrect. Given the way teh architecture is >written, the control plane is not required to know the RSP, and in fact >the architecture and the NSH header allow for implementations in which >the control plane knows the possible paths, but not the RSP that a given >flow takes. > >As such, regarding RSP I believe the document is correct, and the fact >that there are almost no reference to RSP is a feature, not a bug. > >Yours, >Joel > >On 4/27/16 10:17 AM, Jim Guichard (jguichar) wrote: >> Hi Martin & WG: >> >> A few comments that I would like to see addressed in the document before >> it can move forward to the next step. >> >> * Section 2.2 SFC Control Plane Bootstrapping. >> >> This section is too wishy washy. It makes the statement =B3this document >> assumes the SFC control plane is provided with a set of information that >> is _required_ for proper SFC operation=B2 but then goes on to list bulle= ts >> that are _likely_ to be provided or _may_ be provided. It does not >> actually provide any information on what _is required for proper SFC >> operation_. In the list of _likely_ information there is no indication >> of whether this information must exist in the network prior to >> bootstrapping the SFC control plane element; this is true also for the >> list of _may_ information. Surely we should provide guidelines on what >> _must_ be available before the SFC control plane element can actually >> function although it is reasonable to assume that it can bootstrap >> without any information (albeit it can=B9t actually do anything). On thi= s >> point I would argue that several of the _may_ elements are actually >> required such as SFF, SF, SFC-proxy locators and may exist prior to >> bootstrapping the SFC control plane element, or may be added later >> through some control interface. >> >> Minor point -> typo in bullet point 6 =AD SFP proxy should read *SFC* >>proxy >> >> * Section 2.3 Coherent Setup of an SFC-enabled Domain >> >> What does the sentence =B3various transport encapsulation schemes and/or >> variations of SFC header implementations may be supported=B2 actually me= an >> ? Are we referring to the fact that the SFC header may carry type-1 or >> type-2 metadata or something else ? Note that there is only *one *SFC >> header implementation based on the WG charter so if we are referring to >> different SFC formats (meaning metadata) then please make this clear in >> the text, and if not, please remove this sentence. >> >> * Section 3.1 Reference Architecture >> >> Second bullet point =B3mapping between service function chains and SFPs= =B2 - >> this is a general comment for the entire document but applies here also. >> There is no mention of mapping SFPs -> RSPs =AD in fact RSP is mentioned >> only once in the entire document. The architecture is explicit in that >> the SFP when rendered into the network is an RSP and therefore the SFC >> control plane element needs to have information on currently deployed >>RSPs. >> >> Additionally there is no interface specified for communication between >> the SFC Control Plane Element and SF management systems. This is an >> important aspect as many SF=B9s may require that SFC information be >> communicated to their management systems that will be responsible for >> communicating directly with their respective SF=B9s. >> >> * Section 3.1.1. C1: Interface between SFC Control Plane & SFC >>Classifier >> >> The sentence =B3The control plane may instruct the classifier about the >> initial values of the Service Index (SI)=B2 should be changed to say >> *MUST* as otherwise if a classifier chooses whatever value it wants then >> that may not align with what is programmed into the SFFs by the SFC >> Control Plane element. >> >> * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets >> >> This section does not actually provide any meaning or indication of >> relationship with the SFC Control Plane element. Furthermore, there has >> been no WG consensus to carry source routes within the SFC >> encapsulation. Therefore this entire section should be removed from the >> document. >> >> * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP >> >> Figure 2 lists 3 different SFP-id=B9s whereas the text mentions only >> SFP-id #1. Is this simply a typo or are you trying to convey something >> else ? >> >> Further you state that =B3the steering policies to a SFF node for servic= e >> function chain depends on if the packet comes from previous SFF or comes >> from a specific SF i.e., the SFP Forwarding Table entries have to be >> ingress port specific=B2 - this is an inaccurate statement as the >> combination of the SFP-id and service-index determines the forwarding >> behavior (as specified in section 3.3 & section 7 of >> draft-ietf-sfc-nsh-04). This sentence should be removed from the text. >> >> Jim >> >> >> >> On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" >> on behalf of >> mls.ietf@gmail.com > wrote: >> >> Dear all, >> >> This is the start of the Working Group Last Call (WGLC) for >> >> draft-ietf-sfc-control-plane-04.txt >> >> The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. >> >> Please send your comments and reviews to the sfc@ietf.org >> list. >> >> Regards, >> >> Martin (SFC co-chair) >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Wed Apr 27 10:05: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 ABB8A12D9F3; Wed, 27 Apr 2016 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gi7lTXzrcmKr; Wed, 27 Apr 2016 10:05:02 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE0912D9EF; Wed, 27 Apr 2016 10:05:01 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-f1-5720ea026bc0 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 24.0C.09012.20AE0275; Wed, 27 Apr 2016 18:34:10 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 13:05:00 -0400 From: Gregory Mirsky To: "Jim Guichard (jguichar)" , "sfc@ietf.org" , "mpls@ietf.org" , "pals@ietf.org" Thread-Topic: draft-ietf-sfc-nsh "first nibble" issue Thread-Index: AQHRoHv5jA1HvFPCM0yMnvW+PmvYjp+eC04w Date: Wed, 27 Apr 2016 17:04:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A60FA3@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHT5fplUK4wembMhZL56lb3Fq6ktVi zb91TBZPHmxld2DxmPJ7I6vHkiU/mQKYorhsUlJzMstSi/TtErgyVi4OLjgcVrF7z3vWBsav Xl2MnBwSAiYSu272sELYYhIX7q1n62Lk4hASOMoosalzHxtIQkhgOaPE3ZO2IDabgJHEi409 7CBFIgLTGSWWrdvMApIQBpr0/+E5ZhBbRMBUovvuFCCbA8g2ktjUbQVisgioSrz4zwJi8gr4 Srw/VAgxXV9i15sV7CA2p4CBRPeCE2DnMAKd8/3UGiYQm1lAXOLWk/lMEGcKSCzZc54ZwhaV ePn4H9T5ihL7+qezQ9TnSzxp3gdWzysgKHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/YIGxt iWULXzPD2GcOPGZCFl/AyL6KkaO0uCAnN93IYBMjMJKOSbDp7mC8P93zEKMAB6MSD6+CrEK4 EGtiWXFl7iFGCQ5mJRHe6W+AQrwpiZVVqUX58UWlOanFhxilOViUxHkbg/+FCQmkJ5akZqem FqQWwWSZODilGhgVFVyUXjWf8zGqttz19erq+3fCDu5+mC+V+HPKbhupM/8SE/jXcovad1tu mRTF+lu50Y3befor3TR+AQs++8UJi8x3njtv8Xi5Qq71Iil551ev/N84SjnX5gU5WMnOWxio NKH5xKSZppltr1+WhmTciX774kaDoEwq7+OPW18t7gue7Lr1AYcSS3FGoqEWc1FxIgBdF7zS oAIAAA== Archived-At: Subject: Re: [sfc] draft-ietf-sfc-nsh "first nibble" issue 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, 27 Apr 2016 17:05:07 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, as this issue is related to MPLS and MPLS PWs shall we extend the audience = and invite MPLS and PALS WGs to the discussion? Personally, I prefer solution that avoids not only 0x04 and 0x06 in the fir= st nibble but 0x00 and 0x01 as well by using Non-of-the-Above value, e.g. 0= x05 as in BIER over MPLS encapsulation. Regards, Greg From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 4:58 AM To: sfc@ietf.org Subject: [sfc] draft-ietf-sfc-nsh "first nibble" issue Dear WG: The infamous "MPLS first nibble" issue was raised as part of the WGLC for d= raft-ietf-sfc-nsh-04. While this issue has been known for some time, and wo= rk has been done by the community to try and mitigate (for example RFC4928)= or remove it (for example RFC6790), given the widespread implementation of= existing hardware that uses the first nibble for ECMP decision processing,= it seems prudent for us as a WG to address it in terms of how it affects o= ur SFC protocol and make it clear within the draft the conclusion of the WG= . While it is true that we could rearrange our encapsulation header such that= it avoids this issue (by simply making the first nibble correspond to a va= lue that is neither 0x4 or 0x6), given multiple industry and open source im= plementations of the SFC encapsulation header, that is not a desired outcom= e, especially as multiple other transport encapsulations do not exhibit thi= s behavior when coupled with the SFC encapsulation. If we consider the current definition of the SFC encapsulation base header,= we can see that the first two bits are used as a version field. This means= that if we ever produce a version 01 for NSH it could result in a value of= 0x4 or 0x6 being present within the first nibble. To avoid such a result t= he simplest solution would be to reserve within the SFC encapsulation speci= fication version 01 and make it clear within the text that this is reserved= and should not be used in future versions of the protocol. If we ever chan= ge the version, which incidentally should be a rare thing, we would therefo= re jump from version=3D00 to version=3D02 (i.e. making version 1 'reserved'= ) thereby avoiding any clash in the first nibble. IMHO this seems like a reasonable approach to the problem but I would like = to hear opinions from the WG as to whether this is an acceptable solution a= nd if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add = text to reflect it. Jim --_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

as this issue is related = to MPLS and MPLS PWs shall we extend the audience and invite MPLS and PALS = WGs to the discussion?

Personally, I prefer solu= tion that avoids not only 0x04 and 0x06 in the first nibble but 0x00 and 0x= 01 as well by using Non-of-the-Above value, e.g. 0x05 as in BIER over MPLS encapsulation.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 4:58 AM
To: sfc@ietf.org
Subject: [sfc] draft-ietf-sfc-nsh "first nibble" issue

 

Dear WG:<= /p>

 

The infamous “MPLS fi= rst nibble” issue was raised as part of the WGLC for draft-ietf-sfc-n= sh-04. While this issue has been known for some time, and work has been done by the community to try and mitigate (for example RFC4928) or remove = it (for example RFC6790), given the widespread implementation of existing h= ardware that uses the first nibble for ECMP decision processing, it seems p= rudent for us as a WG to address it in terms of how it affects our SFC protocol and make it clear within th= e draft the conclusion of the WG.

 

While it is true that we co= uld rearrange our encapsulation header such that it avoids this issue (by s= imply making the first nibble correspond to a value that is neither 0x4 or 0x6), given multiple industry and open source implementa= tions of the SFC encapsulation header, that is not a desired outcome, espec= ially as multiple other transport encapsulations do not exhibit this behavi= or when coupled with the SFC encapsulation.

 

If we consider the current = definition of the SFC encapsulation base header, we can see that the first = two bits are used as a version field. This means that if we ever produce a version 01 for NSH it could result in a value of 0x4 or = 0x6 being present within the first nibble. To avoid such a result the simpl= est solution would be to reserve within the SFC encapsulation specification= version 01 and make it clear within the text that this is reserved and should not be used in future versions o= f the protocol. If we ever change the version, which incidentally should be= a rare thing, we would therefore jump from version=3D00 to version=3D02 (i= .e. making version 1 ‘reserved’) thereby avoiding any clash in the first nibble. 

 

IMHO this seems like a reas= onable approach to the problem but I would like to hear opinions from the W= G as to whether this is an acceptable solution and if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add text to = reflect it.

 

Jim

--_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_-- From nobody Wed Apr 27 12:40:48 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 69BE812DB55 for ; Wed, 27 Apr 2016 12:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 3v7bQLoIVQu3 for ; Wed, 27 Apr 2016 12:40:44 -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 301A312D79E for ; Wed, 27 Apr 2016 12:40:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNK66049; Wed, 27 Apr 2016 19:40:39 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Apr 2016 20:40:38 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 27 Apr 2016 12:40:35 -0700 From: Linda Dunbar To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLyqrLBdZa9hMkm7UAhBhKf8Ww== Date: Wed, 27 Apr 2016 19:40:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D582DD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589371EF5@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.572115B8.0065, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 07dfb8d4ded86ffbf6be80e2d25368da Archived-At: Subject: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 19:40:47 -0000 I suggest adding the following paragraphs after the Bullet 3 of the Section= 6 Fragmentation Consideration to make the process more clear and less cont= roversial: -------------------------------- RFC6830 describes the fragmentation method of breaking the original packet = into two equal sub-frames and encapsulating [LISP Header + Transport header= ] to each sub-frame.=20 If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Tran= sport Header] will be added to each half frame (or the original data frame)= . As the Transport Header is terminated by the next SFF node's tunnel trans= port layer, the combined two sub-frames will have two SFC Headers.=20 Therefore, the fragmentation for NSH encapsulated data frame should be done= completely by the node tunnel transport layer, which should break the [SFC= + original packet] into two equal sub-frames and each sub-frame being enca= psulated with its respective tunnel header. The next SFF node's tunnel tra= nsport layer should combine the two sub-frames before sending to the next n= ode. =20 ------------------------------------------------------ By the way, there are to typo in the Section 6:=20 3rd line: "In order the" =3D=3D> "In order to" Last line of Bullet 2: extra "the" in the "utilized to ensure the the requi= red packet".=20 Hope it helps.=20 Linda -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Wednesday, April 27, 2016 12:40 AM To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, all, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9=A0: mardi 26= =20 > avril 2016 19:18 =C0=A0: Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur,= =20 > Uri; sfc@ietf.org Objet=A0: Re: [sfc] WG last call for=20 > draft-ietf-sfc-nsh-04.txt >=20 > With regard to Transport tunnel fragementation, that seems an issue=20 > for the transport protocol. I don't actually object to a sentence,=20 > but it does not seem that it will accomplish anything. [Med] I would like to see some text added to the draft. >=20 > With regard to packets fragmented by the source, I completely disagree=20 > with your assertion. If an SFF were to reassemble the packets, that=20 > would be a violation of its job. [Med] I agree with you. There is no reason for an SFF to > reassemble a packet fragmented by the source. The classifier may have=20 > to do some interesting things in order to properly classify succeeding=20 > fragments, but that is an implementation issue (most commonly=20 > addressed with virtual reassembly, which doe snot delay the=20 > fragments.) We don't specity that. [Med] Still, the external behavior of the classifier needs to be clear in t= he document. I don't find any text in the draft saying for instance that an= NSH header must be present in all fragments. (There some processing that m= ight be needed at the SFF to "do its job" with regards to fragments (receiv= e out of order fragments + forwarding policy on the full packet).) >=20 > If an SF needs to reassemble fragments to do its job, that is up to=20 > the SF. Some will need to actually reassemble. Some will need to=20 > perform virtual reassembly, and some will happily process the=20 > fragments. I can not see what the NSH document could possibly mandate. [Med] Fully agree. >=20 > Yours, > Joel >=20 > On 4/26/16 11:47 AM, Linda Dunbar wrote: > > Joel, > > > > I think the document should add the description on the following two=20 > > fragmentation scenarios: > > > > - Transport tunnel generated fragmentation: When a packet=20 > > fragmentation is caused by transport tunnel (i.e. various=20 > > encapsulations), the termination point of the transport tunnel is=20 > > responsible for re-assembling the fragmented pieces of the packet. > > Since there won't be any SFF nodes in between the Transport Tunnel,=20 > > the tunnel generated fragmentation does not require any actions by=20 > > SFF nodes or SF nodes. > > > > > > - Source node generated fragmentation (after adding on the NSH > > header): When fragmentation has to be performed for a packet being=20 > > encapsulated with the NSH header, either the intermediate SFF nodes=20 > > or the SF nodes have to be able to reassemble the fragmented pieces. > > > > > > > > > > Cheers, > > > > > > Linda > > > > -----Original Message----- From: Joel M. Halpern=20 > > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM > > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;=20 > > sfc@ietf.org Subject: Re: [sfc] WG last call for=20 > > draft-ietf-sfc-nsh-04.txt > > > > Re-reading your note, it is possible that you are referring only to=20 > > the case of transport generated fragmentation of the outer packet. =20 > > I had assumed you were not talking about that, since the resulting=20 > > fragments will not all have NSH headers. As with any tunnel=20 > > technology, if the tunnel chooses to fragment at its layer, then the=20 > > tunnel is responsible for reassembly. That would be invisible to=20 > > the SFF. > > > > Yours, Joel > > > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > >> Agree with Med. > >> > >> Even if each fragment piece of a packet with NSH header carries the=20 > >> NSH header, the intermediate SFF nodes still need to put together=20 > >> all the fragments together before passing the whole data frame to=20 > >> the SF. > >> > >> Linda > >> > >> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 > >> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, > >> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: > >> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Re-, > >> > >> How do you instruct the transport layer to ALWAYS prepend an NSH=20 > >> header even for fragments? Or you don't care about that? > >> > >> Thank you. > >> > >> Cheers, Med > >> > >>> -----Message d'origine----- De : Elzur, Uri=20 > >>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 > >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet > >>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Med > >>> > >>> Not to repeat my position, but I'll do it anyhow :-) As NSH is > >>> *NOT* a transport, dealing with fragmentation is left to the=20 > >>> Transport used. > >>> > >>> The model I use for NSH, is basically similar to VXLAN . It is an=20 > >>> overly. > >>> > >>> Thx > >>> > >>> Uri ("Oo-Ree") C: 949-378-7568 > >>> > >>> > >>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 > >>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25,=20 > >>> 2016 7:18 AM To: Joel M. Halpern ;=20 > >>> sfc@ietf.org > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> Hi Joel, > >>> > >>> Please see inline. > >>> > >>> Cheers, Med > >>> > >>>> -----Message d'origine----- De : Joel M. Halpern=20 > >>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 = =C0=20 > >>>> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG=20 > >>>> last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> If I am understanding you correctly Med, you are asking that the=20 > >>>> NSH draft specify how service chaining should cope with packets=20 > >>>> that have been fragmented? > >>>> > >>> > >>> [Med] To be accurate, I'm asking to assess whether there are=20 > >>> implications. If there are, then the draft should be updated=20 > >>> accordingly. > >>> > >>>> NSH, and the SFF functionality, does not care. > >>> > >>> [Med] I'm not that sure. Some typical implications are listed > >>> below: > >>> > >>> * SFF: If the NSH header is present only in the a fragment but SFF=20 > >>> didn't maintained a state, subsequent fragments won't be=20 > >>> appropriately processed. * SFC-aware function: if prepending a=20 > >>> context information depends on the full packet, not only a=20 > >>> fragment. > >>> > >>> It just does its job. > >>> > >>> [Med] which may be disturbed in some situations as listed in the =20 > >>> examples above. > >>> > >>>> Ingress and intermediate classifiers may cope with fragments in=20 > >>>> any number of ways. > >>> Specifying such is clearly out of scope for this draft. > >>> > >>> [Med] The purpose is not to specify the internal implementation=20 > >>> details but the external behavior of the classifier function when=20 > >>> it comes to handle fragments. That behavior may have an incidence=20 > >>> on SFF, in particular. The purpose is not to recommend the maximum=20 > >>> resources to be dedicated to out of order fragments nor the=20 > >>> timeout to cache those; these considerations are of course out of=20 > >>> scope. Nevertheless, an implementation should offer a configurable=20 > >>> parameter so that an operator tweak those according to its=20 > >>> context. > >>> > >>>> I suppose one could write an informational draft on possible ways=20 > >>>> of coping. The IETF has not usually published such. > >>>> Service functions have to cope with fragmented packets just as=20 > >>>> they had to before the advent of NSH, so describing that is=20 > >>>> clearly not needed here. > >>> > >>> [Med] The advent of NSH has the following implications: * it=20 > >>> exacerbates fragmentation. Handing over this issue to the=20 > >>> transport layer may lead to interoperability issues. * the=20 > >>> chaining may not be efficient if fragments are inappropriately=20 > >>> handled. > >>> > >>> Introducing NSH should not degrade the overall service compared to=20 > >>> legacy service deployment schemes. > >>> > >>>> > >>>> Yours, Joel > >>>> > >>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > >>>>> Re-, > >>>>> > >>>>> I hear you, but my comment is that we need, as a WG, to decide=20 > >>>>> what to > >>>> put in the draft. FWIW, I'm discussing two fragmentation > >>>> issues: > >>>>> > >>>>> (1) Fragmentation that is caused by prepending an SFC header.=20 > >>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. > >>>>> > >>>>> Increasing the MTU is for sure a recommendation is to be=20 > >>>>> explicitly > >>>> called out in the text (see my first message). > >>>>> > >>>>> There are other issues that need to be discussed, e.g., how to=20 > >>>>> deal with > >>>> fragments in SFFs/Classifiers? > >>>>> > >>>>> It is also "prudent" to check that no issues will be experienced=20 > >>>>> in SFF > >>>> to handle fragments. If an SFC header is prepended for all=20 > >>>> fragments, I'm not sure there > >>>>> is any particular issue at the SFF level, except if=20 > >>>>> stripping/adding > >>>> context TLVs depends on the full packet (not just fragment). It=20 > >>>> is warranted to consider a little bit this point before declaring=20 > >>>> there is no issue. > >>>>> > >>>>> For point (1), declaring fragmentation out of scope would be=20 > >>>>> meant that > >>>> an implementation must be prepared to receive fragments with or=20 > >>>> without NSH header as this is a decision that is left to the=20 > >>>> transport encapsulation. This is a requirement per se! > >>>>> > >>>>> I won't reiterate all the comments I have about the current=20 > >>>>> wording of > >>>> this section. > >>>>> > >>>>> Cheers, Med > >>>>> > >>>>>> -----Message d'origine----- De : Elzur, Uri=20 > >>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 > >>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 > >>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 > >>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Hi Med > >>>>>> > >>>>>> My point is that Fragmentation is yet another transport related=20 > >>>>>> issue > >>>> that > >>>>>> is beyond the scope of NSH and beyond the charter of the WG, so=20 > >>>>>> it > >>>> doesn't > >>>>>> really belong in the draft. We are providing an advice as=20 > >>>>>> extending the size of the packet may lead to fragmentation, but=20 > >>>>>> as you check RFC 7348 VxLAN, which my create the same issue,=20 > >>>>>> you'll find it doesn't even > >>>> relate > >>>>>> to it. > >>>>>> > >>>>>> Thx > >>>>>> > >>>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>>> > >>>>>> > >>>>>> -----Original Message----- From: sfc=20 > >>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > >>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 > >>>>>> 10:32 PM To: Elzur, Uri ; Thomas Narten > >>>> ; > >>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for=20 > >>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> Hi Uri, > >>>>>> > >>>>>> That's another option that needs to be discussed/investigated.=20 > >>>>>> I'm > >>>> afraid > >>>>>> this is not the rationale adopted in -04 since it includes some=20 > >>>>>> text > >>>> that > >>>>>> is far to be sufficient to ensure interoperable=20 > >>>>>> implementations. > >>>>>> > >>>>>> BTW, saying that nsh does not need to deal with fragmentation=20 > >>>>>> because > >>>> it > >>>>>> is transport-independent is not IMHO a good strategy to adopt=20 > >>>>>> here > >>>> because > >>>>>> it opens the door for interoperable issues, it may lead to=20 > >>>>>> sub-optimal implementations if the sfc information is present=20 > >>>>>> only in one > >>>> fragments, > >>>>>> etc. > >>>>>> > >>>>>> My comments are related to the current text in the -04. > >>>>>> This text needs > >>>> to > >>>>>> be fixed somehow. > >>>>>> > >>>>>> Cheers, Med > >>>>>> > >>>>>>> -----Message d'origine----- De : Elzur, Uri=20 > >>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril > >>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 > >>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 > >>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> Hi Med > >>>>>>> > >>>>>>> I see no need to specify the exact behavior as NSH is=20 > >>>>>>> transport independent i.e. like NSH interaction with any other=20 > >>>>>>> Transport eh issue of Fragmentation is to be dealt in a way=20 > >>>>>>> that matches the mechanisms supported by the Transport used=20 > >>>>>>> and do not belong in the NSH draft > >>>>>>> > >>>>>>> Thx > >>>>>>> > >>>>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- From: sfc=20 > >>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 > >>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14, > >>>>>>> 2016 12:43 AM To: Thomas Narten ;=20 > >>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for=20 > >>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>> > >>>>>>> R-, > >>>>>>> > >>>>>>> In addition to other pending issues raised for this draft, I=20 > >>>>>>> would like to raise this additional one about Section 6. > >>>>>>> > >>>>>>> =3D=3D 6. Fragmentation Considerations > >>>>>>> > >>>>>>> NSH and the associated transport header are "added" to the=20 > >>>>>>> encapsulated packet/frame. This additional information=20 > >>>>>>> increases > >>>> the > >>>>>>> size of the packet. In order the ensure proper forwarding of=20 > >>>>>>> NSH data, several options for handling fragmentation and=20 > >>>>>>> re-assembly exist: > >>>>>>> > >>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH=20 > >>>>>>> and associated transport packets without requiring=20 > >>>>>>> fragmentation. > >>>>>>> > >>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for=20 > >>>>>>> dynamically discovering the maximum transmission unit (MTU) of > >>>> an > >>>>>>> arbitrary internet path" and can be utilized to ensure the > >>> the > >>>>>>> required packet size is used. > >>>>>>> > >>>>>>> 3. [RFC6830] describes two schemes for fragmentation and > >>>>>>> re- > >>>> assembly > >>>>>>> in section 5.4. =3D=3D > >>>>>>> > >>>>>>> * The text is weak for a Standard track document that is=20 > >>>>>>> intended to solve the problem in > >>>>>>> https://tools.ietf.org/html/rfc7498#section- > >>> 2.12. > >>>>>>> There should be a clear behavior to be followed by an > >>> implementation. > >>>>>>> Further, I would avoid the use of words such as "can". > >>>>>>> > >>>>>>> * The text covers only fragmentation when it is induced by SFC=20 > >>>>>>> operations, it does not discuss the treatment of a fragment=20 > >>>>>>> when received in an SFC domain. IMHO, the draft should also=20 > >>>>>>> specify the behavior of the Classifier with regards to=20 > >>>>>>> fragments for the sake of proper SFC operation. Applying=20 > >>>>>>> classification policies may require the > >>>>>> full packet, not only a fragment. > >>>>>>> In particular, dedicated resources should dedicated for=20 > >>>>>>> handling out of order fragments. Of course, it is out of scope=20 > >>>>>>> of this document to describe how SFs handle fragments. > >>>>>>> > >>>>>>> * If an SFC header is prepended for all fragments, I'm not=20 > >>>>>>> sure there is any particular issue at the SFF level...except=20 > >>>>>>> if stripping/adding context TLVs depends on the full packet=20 > >>>>>>> (not just fragment). It is warranted to consider a little bit=20 > >>>>>>> this point before declaring there > >>>> is > >>>>>> no issue. > >>>>>>> > >>>>>>> * The text states "several options". This may be interpreted=20 > >>>>>>> as if implementing one of them is sufficient...which is not=20 > >>>>>>> true. The first two points contribute to minimize the=20 > >>>>>>> fragmentation risk, but fragmentation may still be experienced=20 > >>>>>>> (e.g., other shims are prepended by other nodes for some other=20 > >>>>>>> purposes, nested nsh, etc.) > >>>>>>> > >>>>>>> * The first two points have nothing to do with reassembly. > >>>>>>> > >>>>>>> * The support of jumbo frames by a router/device does not mean=20 > >>>>>>> that it can make use of it. Appropriate MTU configuration=20 > >>>>>>> should be undertaken in a consistent manner within an SFC=20 > >>>>>>> domain. The text should be updated to make it is about=20 > >>>>>>> (consistent) MTU > >>> configuration. > >>>>>>> > >>>>>>> * BTW, shouldn't the text be reworded to recommended to=20 > >>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by=20 > >>>>>>> at least the length of SFC header + transport header? > >>>>>>> > >>>>>>> * Bullet 2, how PMTU discovery is actually used in this=20 > >>>>>>> context? Do you assume that all SFC-aware nodes will issue=20 > >>>>>>> such messages towards other SFC-aware node, arbitrary=20 > >>>>>>> destination, else? > >>>>>>> > >>>>>>> * Bullet 2, I would drop "describes a technique for=20 > >>>>>>> dynamically discovering the maximum transmission unit > >>>>>>> (MTU) of an arbitrary internet path". > >>>>>>> > >>>>>>> * Bullet 2, s/ the the/the. > >>>>>>> > >>>>>>> * The reference to the LISP specification raises two concerns=20 > >>>>>>> and one comment: > >>>>>>> > >>>>>>> (1) I don't think it is a good approach that fragments induced=20 > >>>>>>> by the network are passed to their ultimate destinations as=20 > >>>>>>> such > >>> (stateless). > >>>>>>> IMO, reassembly should be done within the SFC domain=20 > >>>>>>> (responsible for fragmentation) not passed away. (2) Does the=20 > >>>>>>> stateful mode require all SFC data plane elements maintain a=20 > >>>>>>> full list of MTU for the any SFF/SF instance of the SFC > >>>>>> domain? > >>>>>>> > >>>>>>> The current text suggests that [RFC6830] should be listed as=20 > >>>>>>> normative reference (not an informative one). I would=20 > >>>>>>> personally favor removing the reference to LISP (as it is an=20 > >>>>>>> Experimental RFC). > >>>>>>> > >>>>>>> * The security section of the draft may be augmented with=20 > >>>>>>> informational fragmentation-related pointers to: > >>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment=20 > >>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny=20 > >>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High=20 > >>>>>>> Data Rates). > >>>>>>> > >>>>>>> Cheers, Med > >>>>>>> > >>>>>>>> -----Message d'origine----- De : sfc=20 > >>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de=20 > >>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril > >>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org Objet : Re: > >>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>>>> > >>>>>>>> Dear Thomas, all, > >>>>>>>> > >>>>>>>> As I mentioned during the meeting, there are several issues=20 > >>>>>>>> that are not covered in the last version of the draft. I=20 > >>>>>>>> already provided examples of the issues offline as requested=20 > >>>>>>>> by Martin. > >>>>>>>> > >>>>>>>> Cheers, Med > >>>>>>>> > >>>>>>>>> -----Message d'origine----- De : sfc=20 > >>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 > >>>>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : > >>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for=20 > >>>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>>> > >>>>>>>>> Dear WG: > >>>>>>>>> > >>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 > >>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > The editors of the NSH document have indicated that they have > >>>>>>>>> addressed all known comments and that there are no open=20 > >>>>>>>>> issues with the current version of the document. > >>>>>>>>> > >>>>>>>>> Substantive comments to the list please, editorial comments=20 > >>>>>>>>> can go directly to the document editors. > >>>>>>>>> > >>>>>>>>> We'll also get a brief update from the editors at next=20 > >>>>>>>>> week's meeting. If there are any remaining issues with the=20 > >>>>>>>>> document, raising them before the meeting would be=20 > >>>>>>>>> especially helpful. > >>>>>>>>> > >>>>>>>>> For the chairs, Thomas > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc mailing=20 > >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ sfc mailing=20 > >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>>> _______________________________________________ sfc mailing=20 > >>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>>> > >>>>>> _______________________________________________ sfc mailing=20 > >>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>>>> _______________________________________________ sfc mailing list=20 > >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>> > >>> _______________________________________________ sfc mailing list=20 > >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >> > >> _______________________________________________ sfc mailing list=20 > >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >> From nobody Wed Apr 27 13:19:33 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 5DA8D12D567 for ; Wed, 27 Apr 2016 13:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 NvdIcbeUQ1e9 for ; Wed, 27 Apr 2016 13:19:29 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B36E12D1C8 for ; Wed, 27 Apr 2016 13:19:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EB99F240207; Wed, 27 Apr 2016 13:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461788368; bh=P0cYqw0l07OWmCD/zKZldM1GUrYbHZDGCn7E2xZCe4c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bIdf/QoDBoqvPqm37YTpKd5p3lf//o7FuGPZOsw77RtqraGD8M0cMGy3kw8AKBbFa 8YtyOKZ38ZCFCLQn+NwgO45A5pig0sEaTPmtMSSv4uEuiQZkun6ZojAt6m0j/AjEax FFn2F17xcs07g5O7tlH1R0fDvFZvHAkslXpQN7Ys= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EC919240EFB; Wed, 27 Apr 2016 13:19:27 -0700 (PDT) To: Linda Dunbar , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> From: "Joel M. Halpern" Message-ID: <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> Date: Wed, 27 Apr 2016 16:19:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 20:19:32 -0000 Both methods are valid, and both depend upon details of the underlying packet and the transport. As such, I don't see why this document benefits from describing them, much less why it should mark one method as a "should". Implementation details are likely to be more significant than any bit consumption difference between the two alternatives. Yours, Joel On 4/27/16 3:40 PM, Linda Dunbar wrote: > I suggest adding the following paragraphs after the Bullet 3 of the Section 6 Fragmentation Consideration to make the process more clear and less controversial: > > > -------------------------------- > > RFC6830 describes the fragmentation method of breaking the original packet into two equal sub-frames and encapsulating [LISP Header + Transport header] to each sub-frame. > > If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Transport Header] will be added to each half frame (or the original data frame). As the Transport Header is terminated by the next SFF node's tunnel transport layer, the combined two sub-frames will have two SFC Headers. > > Therefore, the fragmentation for NSH encapsulated data frame should be done completely by the node tunnel transport layer, which should break the [SFC + original packet] into two equal sub-frames and each sub-frame being encapsulated with its respective tunnel header. The next SFF node's tunnel transport layer should combine the two sub-frames before sending to the next node. > > ------------------------------------------------------ > > > By the way, there are to typo in the Section 6: > 3rd line: "In order the" ==> "In order to" > Last line of Bullet 2: extra "the" in the "utilized to ensure the the required packet". > > > Hope it helps. > > Linda > > > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, April 27, 2016 12:40 AM > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Hi Joel, all, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : mardi 26 >> avril 2016 19:18 À : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur, >> Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, that seems an issue >> for the transport protocol. I don't actually object to a sentence, >> but it does not seem that it will accomplish anything. > > [Med] I would like to see some text added to the draft. > >> >> With regard to packets fragmented by the source, I completely disagree >> with your assertion. If an SFF were to reassemble the packets, that >> would be a violation of its job. > > [Med] I agree with you. > > There is no reason for an SFF to >> reassemble a packet fragmented by the source. The classifier may have >> to do some interesting things in order to properly classify succeeding >> fragments, but that is an implementation issue (most commonly >> addressed with virtual reassembly, which doe snot delay the >> fragments.) We don't specity that. > > [Med] Still, the external behavior of the classifier needs to be clear in the document. I don't find any text in the draft saying for instance that an NSH header must be present in all fragments. (There some processing that might be needed at the SFF to "do its job" with regards to fragments (receive out of order fragments + forwarding policy on the full packet).) > >> >> If an SF needs to reassemble fragments to do its job, that is up to >> the SF. Some will need to actually reassemble. Some will need to >> perform virtual reassembly, and some will happily process the >> fragments. I can not see what the NSH document could possibly mandate. > > [Med] Fully agree. > >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> Joel, >>> >>> I think the document should add the description on the following two >>> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a packet >>> fragmentation is caused by transport tunnel (i.e. various >>> encapsulations), the termination point of the transport tunnel is >>> responsible for re-assembling the fragmented pieces of the packet. >>> Since there won't be any SFF nodes in between the Transport Tunnel, >>> the tunnel generated fragmentation does not require any actions by >>> SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on the NSH >>> header): When fragmentation has to be performed for a packet being >>> encapsulated with the NSH header, either the intermediate SFF nodes >>> or the SF nodes have to be able to reassemble the fragmented pieces. >>> >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >>> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are referring only to >>> the case of transport generated fragmentation of the outer packet. >>> I had assumed you were not talking about that, since the resulting >>> fragments will not all have NSH headers. As with any tunnel >>> technology, if the tunnel chooses to fragment at its layer, then the >>> tunnel is responsible for reassembly. That would be invisible to >>> the SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>> Agree with Med. >>>> >>>> Even if each fragment piece of a packet with NSH header carries the >>>> NSH header, the intermediate SFF nodes still need to put together >>>> all the fragments together before passing the whole data frame to >>>> the SF. >>>> >>>> Linda >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-, >>>> >>>> How do you instruct the transport layer to ALWAYS prepend an NSH >>>> header even for fragments? Or you don't care about that? >>>> >>>> Thank you. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Elzur, Uri >>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 16:26 À >>>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet >>>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>>> *NOT* a transport, dealing with fragmentation is left to the >>>>> Transport used. >>>>> >>>>> The model I use for NSH, is basically similar to VXLAN . It is an >>>>> overly. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>>>> 2016 7:18 AM To: Joel M. Halpern ; >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Joel, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Joel M. Halpern >>>>>> [mailto:jmh@joelhalpern.com] Envoyé : lundi 25 avril 2016 15:48 À >>>>>> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG >>>>>> last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> If I am understanding you correctly Med, you are asking that the >>>>>> NSH draft specify how service chaining should cope with packets >>>>>> that have been fragmented? >>>>>> >>>>> >>>>> [Med] To be accurate, I'm asking to assess whether there are >>>>> implications. If there are, then the draft should be updated >>>>> accordingly. >>>>> >>>>>> NSH, and the SFF functionality, does not care. >>>>> >>>>> [Med] I'm not that sure. Some typical implications are listed >>>>> below: >>>>> >>>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>>> didn't maintained a state, subsequent fragments won't be >>>>> appropriately processed. * SFC-aware function: if prepending a >>>>> context information depends on the full packet, not only a >>>>> fragment. >>>>> >>>>> It just does its job. >>>>> >>>>> [Med] which may be disturbed in some situations as listed in the >>>>> examples above. >>>>> >>>>>> Ingress and intermediate classifiers may cope with fragments in >>>>>> any number of ways. >>>>> Specifying such is clearly out of scope for this draft. >>>>> >>>>> [Med] The purpose is not to specify the internal implementation >>>>> details but the external behavior of the classifier function when >>>>> it comes to handle fragments. That behavior may have an incidence >>>>> on SFF, in particular. The purpose is not to recommend the maximum >>>>> resources to be dedicated to out of order fragments nor the >>>>> timeout to cache those; these considerations are of course out of >>>>> scope. Nevertheless, an implementation should offer a configurable >>>>> parameter so that an operator tweak those according to its >>>>> context. >>>>> >>>>>> I suppose one could write an informational draft on possible ways >>>>>> of coping. The IETF has not usually published such. >>>>>> Service functions have to cope with fragmented packets just as >>>>>> they had to before the advent of NSH, so describing that is >>>>>> clearly not needed here. >>>>> >>>>> [Med] The advent of NSH has the following implications: * it >>>>> exacerbates fragmentation. Handing over this issue to the >>>>> transport layer may lead to interoperability issues. * the >>>>> chaining may not be efficient if fragments are inappropriately >>>>> handled. >>>>> >>>>> Introducing NSH should not degrade the overall service compared to >>>>> legacy service deployment schemes. >>>>> >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Re-, >>>>>>> >>>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>>> what to >>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>> issues: >>>>>>> >>>>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>>> >>>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>>> explicitly >>>>>> called out in the text (see my first message). >>>>>>> >>>>>>> There are other issues that need to be discussed, e.g., how to >>>>>>> deal with >>>>>> fragments in SFFs/Classifiers? >>>>>>> >>>>>>> It is also "prudent" to check that no issues will be experienced >>>>>>> in SFF >>>>>> to handle fragments. If an SFC header is prepended for all >>>>>> fragments, I'm not sure there >>>>>>> is any particular issue at the SFF level, except if >>>>>>> stripping/adding >>>>>> context TLVs depends on the full packet (not just fragment). It >>>>>> is warranted to consider a little bit this point before declaring >>>>>> there is no issue. >>>>>>> >>>>>>> For point (1), declaring fragmentation out of scope would be >>>>>>> meant that >>>>>> an implementation must be prepared to receive fragments with or >>>>>> without NSH header as this is a decision that is left to the >>>>>> transport encapsulation. This is a requirement per se! >>>>>>> >>>>>>> I won't reiterate all the comments I have about the current >>>>>>> wording of >>>>>> this section. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : lundi 25 avril 2016 >>>>>>>> 08:30 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> My point is that Fragmentation is yet another transport related >>>>>>>> issue >>>>>> that >>>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>>> it >>>>>> doesn't >>>>>>>> really belong in the draft. We are providing an advice as >>>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>>> you'll find it doesn't even >>>>>> relate >>>>>>>> to it. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 >>>>>>>> 10:32 PM To: Elzur, Uri ; Thomas Narten >>>>>> ; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Uri, >>>>>>>> >>>>>>>> That's another option that needs to be discussed/investigated. >>>>>>>> I'm >>>>>> afraid >>>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>>> text >>>>>> that >>>>>>>> is far to be sufficient to ensure interoperable >>>>>>>> implementations. >>>>>>>> >>>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>>> because >>>>>> it >>>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>>> here >>>>>> because >>>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>>> sub-optimal implementations if the sfc information is present >>>>>>>> only in one >>>>>> fragments, >>>>>>>> etc. >>>>>>>> >>>>>>>> My comments are related to the current text in the -04. >>>>>>>> This text needs >>>>>> to >>>>>>>> be fixed somehow. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>> [mailto:uri.elzur@intel.com] Envoyé : dimanche 24 avril >>>>>>>>> 2016 17:36 À : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> I see no need to specify the exact behavior as NSH is >>>>>>>>> transport independent i.e. like NSH interaction with any other >>>>>>>>> Transport eh issue of Fragmentation is to be dealt in a way >>>>>>>>> that matches the mechanisms supported by the Transport used >>>>>>>>> and do not belong in the NSH draft >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14, >>>>>>>>> 2016 12:43 AM To: Thomas Narten ; >>>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> R-, >>>>>>>>> >>>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>>> would like to raise this additional one about Section 6. >>>>>>>>> >>>>>>>>> == 6. Fragmentation Considerations >>>>>>>>> >>>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>>> encapsulated packet/frame. This additional information >>>>>>>>> increases >>>>>> the >>>>>>>>> size of the packet. In order the ensure proper forwarding of >>>>>>>>> NSH data, several options for handling fragmentation and >>>>>>>>> re-assembly exist: >>>>>>>>> >>>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH >>>>>>>>> and associated transport packets without requiring >>>>>>>>> fragmentation. >>>>>>>>> >>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>>> an >>>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>>> the >>>>>>>>> required packet size is used. >>>>>>>>> >>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>>> re- >>>>>> assembly >>>>>>>>> in section 5.4. == >>>>>>>>> >>>>>>>>> * The text is weak for a Standard track document that is >>>>>>>>> intended to solve the problem in >>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>> 2.12. >>>>>>>>> There should be a clear behavior to be followed by an >>>>> implementation. >>>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>>> >>>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>>> operations, it does not discuss the treatment of a fragment >>>>>>>>> when received in an SFC domain. IMHO, the draft should also >>>>>>>>> specify the behavior of the Classifier with regards to >>>>>>>>> fragments for the sake of proper SFC operation. Applying >>>>>>>>> classification policies may require the >>>>>>>> full packet, not only a fragment. >>>>>>>>> In particular, dedicated resources should dedicated for >>>>>>>>> handling out of order fragments. Of course, it is out of scope >>>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>>> >>>>>>>>> * If an SFC header is prepended for all fragments, I'm not >>>>>>>>> sure there is any particular issue at the SFF level...except >>>>>>>>> if stripping/adding context TLVs depends on the full packet >>>>>>>>> (not just fragment). It is warranted to consider a little bit >>>>>>>>> this point before declaring there >>>>>> is >>>>>>>> no issue. >>>>>>>>> >>>>>>>>> * The text states "several options". This may be interpreted >>>>>>>>> as if implementing one of them is sufficient...which is not >>>>>>>>> true. The first two points contribute to minimize the >>>>>>>>> fragmentation risk, but fragmentation may still be experienced >>>>>>>>> (e.g., other shims are prepended by other nodes for some other >>>>>>>>> purposes, nested nsh, etc.) >>>>>>>>> >>>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>>> >>>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>>> that it can make use of it. Appropriate MTU configuration >>>>>>>>> should be undertaken in a consistent manner within an SFC >>>>>>>>> domain. The text should be updated to make it is about >>>>>>>>> (consistent) MTU >>>>> configuration. >>>>>>>>> >>>>>>>>> * BTW, shouldn't the text be reworded to recommended to >>>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by >>>>>>>>> at least the length of SFC header + transport header? >>>>>>>>> >>>>>>>>> * Bullet 2, how PMTU discovery is actually used in this >>>>>>>>> context? Do you assume that all SFC-aware nodes will issue >>>>>>>>> such messages towards other SFC-aware node, arbitrary >>>>>>>>> destination, else? >>>>>>>>> >>>>>>>>> * Bullet 2, I would drop "describes a technique for >>>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>> >>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>> >>>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>>> and one comment: >>>>>>>>> >>>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>>> by the network are passed to their ultimate destinations as >>>>>>>>> such >>>>> (stateless). >>>>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>>> (responsible for fragmentation) not passed away. (2) Does the >>>>>>>>> stateful mode require all SFC data plane elements maintain a >>>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>>> domain? >>>>>>>>> >>>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>>> normative reference (not an informative one). I would >>>>>>>>> personally favor removing the reference to LISP (as it is an >>>>>>>>> Experimental RFC). >>>>>>>>> >>>>>>>>> * The security section of the draft may be augmented with >>>>>>>>> informational fragmentation-related pointers to: >>>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny >>>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High >>>>>>>>> Data Rates). >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>>> mohamed.boucadair@orange.com Envoyé : lundi 11 avril >>>>>>>>>> 2016 13:14 À : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear Thomas, all, >>>>>>>>>> >>>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>>> already provided examples of the issues offline as requested >>>>>>>>>> by Martin. >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>>>>>> Envoyé : jeudi 31 mars 2016 04:48 À : >>>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for >>>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear WG: >>>>>>>>>>> >>>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> The editors of the NSH document have indicated that they have >>>>>>>>>>> addressed all known comments and that there are no open >>>>>>>>>>> issues with the current version of the document. >>>>>>>>>>> >>>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>>> can go directly to the document editors. >>>>>>>>>>> >>>>>>>>>>> We'll also get a brief update from the editors at next >>>>>>>>>>> week's meeting. If there are any remaining issues with the >>>>>>>>>>> document, raising them before the meeting would be >>>>>>>>>>> especially helpful. >>>>>>>>>>> >>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ 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 Wed Apr 27 13:33: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 E463A12D1C8 for ; Wed, 27 Apr 2016 13:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 YeYF9GwMdTas for ; Wed, 27 Apr 2016 13:33:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD5B12B02F for ; Wed, 27 Apr 2016 13:33:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIQ68050; Wed, 27 Apr 2016 20:33:31 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Apr 2016 21:33:30 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 27 Apr 2016 13:33:26 -0700 From: Linda Dunbar To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLyqrLBdZa9hMkm7UAhBhKf8W5+euAMA//+Nf/A= Date: Wed, 27 Apr 2016 20:33:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657E7D9B4@dfweml501-mbb> References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> In-Reply-To: <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5721221C.025B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 432587ec47f2b36095e7ed9394d938f6 Archived-At: Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 20:33:43 -0000 Joel,=20 If you think "both methods are valid", then the implication of both methods= should be included in the document. I don't believe the current description in the Section 6 is adequate enough= . Otherwise, there won't be so much debate on the list.=20 Linda=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, April 27, 2016 3:19 PM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; sfc@ietf.org Subject: Re: Suggested wording addtion to the Section 6 (Fragmentation Cons= ideration) of the draft-ietf-sfc-nsh-04.txt Both methods are valid, and both depend upon details of the underlying pack= et and the transport. As such, I don't see why this document benefits from= describing them, much less why it should mark one method as a "should". I= mplementation details are likely to be more significant than any bit consum= ption difference between the two alternatives. Yours, Joel On 4/27/16 3:40 PM, Linda Dunbar wrote: > I suggest adding the following paragraphs after the Bullet 3 of the Secti= on 6 Fragmentation Consideration to make the process more clear and less co= ntroversial: > > > -------------------------------- > > RFC6830 describes the fragmentation method of breaking the original packe= t into two equal sub-frames and encapsulating [LISP Header + Transport head= er] to each sub-frame. > > If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Tr= ansport Header] will be added to each half frame (or the original data fram= e). As the Transport Header is terminated by the next SFF node's tunnel tra= nsport layer, the combined two sub-frames will have two SFC Headers. > > Therefore, the fragmentation for NSH encapsulated data frame should be do= ne completely by the node tunnel transport layer, which should break the [S= FC + original packet] into two equal sub-frames and each sub-frame being en= capsulated with its respective tunnel header. The next SFF node's tunnel t= ransport layer should combine the two sub-frames before sending to the next= node. > > ------------------------------------------------------ > > > By the way, there are to typo in the Section 6: > 3rd line: "In order the" =3D=3D> "In order to" > Last line of Bullet 2: extra "the" in the "utilized to ensure the the req= uired packet". > > > Hope it helps. > > Linda > > > > -----Original Message----- > From: mohamed.boucadair@orange.com=20 > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, April 27, 2016 12:40 AM > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Hi Joel, all, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : mardi 26=20 >> avril 2016 19:18 =C0 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur,=20 >> Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for=20 >> draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, that seems an issue=20 >> for the transport protocol. I don't actually object to a sentence,=20 >> but it does not seem that it will accomplish anything. > > [Med] I would like to see some text added to the draft. > >> >> With regard to packets fragmented by the source, I completely=20 >> disagree with your assertion. If an SFF were to reassemble the=20 >> packets, that would be a violation of its job. > > [Med] I agree with you. > > There is no reason for an SFF to >> reassemble a packet fragmented by the source. The classifier may=20 >> have to do some interesting things in order to properly classify=20 >> succeeding fragments, but that is an implementation issue (most=20 >> commonly addressed with virtual reassembly, which doe snot delay the >> fragments.) We don't specity that. > > [Med] Still, the external behavior of the classifier needs to be clear=20 > in the document. I don't find any text in the draft saying for=20 > instance that an NSH header must be present in all fragments. (There=20 > some processing that might be needed at the SFF to "do its job" with=20 > regards to fragments (receive out of order fragments + forwarding=20 > policy on the full packet).) > >> >> If an SF needs to reassemble fragments to do its job, that is up to=20 >> the SF. Some will need to actually reassemble. Some will need to=20 >> perform virtual reassembly, and some will happily process the=20 >> fragments. I can not see what the NSH document could possibly mandate. > > [Med] Fully agree. > >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> Joel, >>> >>> I think the document should add the description on the following two=20 >>> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a packet=20 >>> fragmentation is caused by transport tunnel (i.e. various=20 >>> encapsulations), the termination point of the transport tunnel is=20 >>> responsible for re-assembling the fragmented pieces of the packet. >>> Since there won't be any SFF nodes in between the Transport Tunnel,=20 >>> the tunnel generated fragmentation does not require any actions by=20 >>> SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on the NSH >>> header): When fragmentation has to be performed for a packet being=20 >>> encapsulated with the NSH header, either the intermediate SFF nodes=20 >>> or the SF nodes have to be able to reassemble the fragmented pieces. >>> >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern=20 >>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >>> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;=20 >>> sfc@ietf.org Subject: Re: [sfc] WG last call for=20 >>> draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are referring only to=20 >>> the case of transport generated fragmentation of the outer packet. >>> I had assumed you were not talking about that, since the resulting=20 >>> fragments will not all have NSH headers. As with any tunnel=20 >>> technology, if the tunnel chooses to fragment at its layer, then the=20 >>> tunnel is responsible for reassembly. That would be invisible to=20 >>> the SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>> Agree with Med. >>>> >>>> Even if each fragment piece of a packet with NSH header carries the=20 >>>> NSH header, the intermediate SFF nodes still need to put together=20 >>>> all the fragments together before passing the whole data frame to=20 >>>> the SF. >>>> >>>> Linda >>>> >>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-, >>>> >>>> How do you instruct the transport layer to ALWAYS prepend an NSH=20 >>>> header even for fragments? Or you don't care about that? >>>> >>>> Thank you. >>>> >>>> Cheers, Med >>>> >>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 >>>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet >>>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Med >>>>> >>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>>> *NOT* a transport, dealing with fragmentation is left to the=20 >>>>> Transport used. >>>>> >>>>> The model I use for NSH, is basically similar to VXLAN . It is an=20 >>>>> overly. >>>>> >>>>> Thx >>>>> >>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>> >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]=20 >>>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>>>> 2016 7:18 AM To: Joel M. Halpern ;=20 >>>>> sfc@ietf.org >>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Hi Joel, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, Med >>>>> >>>>>> -----Message d'origine----- De : Joel M. Halpern=20 >>>>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 15:48 = =C0 >>>>>> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG=20 >>>>>> last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> If I am understanding you correctly Med, you are asking that the=20 >>>>>> NSH draft specify how service chaining should cope with packets=20 >>>>>> that have been fragmented? >>>>>> >>>>> >>>>> [Med] To be accurate, I'm asking to assess whether there are=20 >>>>> implications. If there are, then the draft should be updated=20 >>>>> accordingly. >>>>> >>>>>> NSH, and the SFF functionality, does not care. >>>>> >>>>> [Med] I'm not that sure. Some typical implications are listed >>>>> below: >>>>> >>>>> * SFF: If the NSH header is present only in the a fragment but SFF=20 >>>>> didn't maintained a state, subsequent fragments won't be=20 >>>>> appropriately processed. * SFC-aware function: if prepending a=20 >>>>> context information depends on the full packet, not only a=20 >>>>> fragment. >>>>> >>>>> It just does its job. >>>>> >>>>> [Med] which may be disturbed in some situations as listed in the=20 >>>>> examples above. >>>>> >>>>>> Ingress and intermediate classifiers may cope with fragments in=20 >>>>>> any number of ways. >>>>> Specifying such is clearly out of scope for this draft. >>>>> >>>>> [Med] The purpose is not to specify the internal implementation=20 >>>>> details but the external behavior of the classifier function when=20 >>>>> it comes to handle fragments. That behavior may have an incidence=20 >>>>> on SFF, in particular. The purpose is not to recommend the maximum=20 >>>>> resources to be dedicated to out of order fragments nor the=20 >>>>> timeout to cache those; these considerations are of course out of=20 >>>>> scope. Nevertheless, an implementation should offer a configurable=20 >>>>> parameter so that an operator tweak those according to its=20 >>>>> context. >>>>> >>>>>> I suppose one could write an informational draft on possible ways=20 >>>>>> of coping. The IETF has not usually published such. >>>>>> Service functions have to cope with fragmented packets just as=20 >>>>>> they had to before the advent of NSH, so describing that is=20 >>>>>> clearly not needed here. >>>>> >>>>> [Med] The advent of NSH has the following implications: * it=20 >>>>> exacerbates fragmentation. Handing over this issue to the=20 >>>>> transport layer may lead to interoperability issues. * the=20 >>>>> chaining may not be efficient if fragments are inappropriately=20 >>>>> handled. >>>>> >>>>> Introducing NSH should not degrade the overall service compared to=20 >>>>> legacy service deployment schemes. >>>>> >>>>>> >>>>>> Yours, Joel >>>>>> >>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Re-, >>>>>>> >>>>>>> I hear you, but my comment is that we need, as a WG, to decide=20 >>>>>>> what to >>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>> issues: >>>>>>> >>>>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>>> >>>>>>> Increasing the MTU is for sure a recommendation is to be=20 >>>>>>> explicitly >>>>>> called out in the text (see my first message). >>>>>>> >>>>>>> There are other issues that need to be discussed, e.g., how to=20 >>>>>>> deal with >>>>>> fragments in SFFs/Classifiers? >>>>>>> >>>>>>> It is also "prudent" to check that no issues will be experienced=20 >>>>>>> in SFF >>>>>> to handle fragments. If an SFC header is prepended for all=20 >>>>>> fragments, I'm not sure there >>>>>>> is any particular issue at the SFF level, except if=20 >>>>>>> stripping/adding >>>>>> context TLVs depends on the full packet (not just fragment). It=20 >>>>>> is warranted to consider a little bit this point before declaring=20 >>>>>> there is no issue. >>>>>>> >>>>>>> For point (1), declaring fragmentation out of scope would be=20 >>>>>>> meant that >>>>>> an implementation must be prepared to receive fragments with or=20 >>>>>> without NSH header as this is a decision that is left to the=20 >>>>>> transport encapsulation. This is a requirement per se! >>>>>>> >>>>>>> I won't reiterate all the comments I have about the current=20 >>>>>>> wording of >>>>>> this section. >>>>>>> >>>>>>> Cheers, Med >>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 >>>>>>>> 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Med >>>>>>>> >>>>>>>> My point is that Fragmentation is yet another transport related=20 >>>>>>>> issue >>>>>> that >>>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so=20 >>>>>>>> it >>>>>> doesn't >>>>>>>> really belong in the draft. We are providing an advice as=20 >>>>>>>> extending the size of the packet may lead to fragmentation, but=20 >>>>>>>> as you check RFC 7348 VxLAN, which my create the same issue,=20 >>>>>>>> you'll find it doesn't even >>>>>> relate >>>>>>>> to it. >>>>>>>> >>>>>>>> Thx >>>>>>>> >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: sfc=20 >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 >>>>>>>> 10:32 PM To: Elzur, Uri ; Thomas Narten >>>>>> ; >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for=20 >>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>> >>>>>>>> Hi Uri, >>>>>>>> >>>>>>>> That's another option that needs to be discussed/investigated. >>>>>>>> I'm >>>>>> afraid >>>>>>>> this is not the rationale adopted in -04 since it includes some=20 >>>>>>>> text >>>>>> that >>>>>>>> is far to be sufficient to ensure interoperable=20 >>>>>>>> implementations. >>>>>>>> >>>>>>>> BTW, saying that nsh does not need to deal with fragmentation=20 >>>>>>>> because >>>>>> it >>>>>>>> is transport-independent is not IMHO a good strategy to adopt=20 >>>>>>>> here >>>>>> because >>>>>>>> it opens the door for interoperable issues, it may lead to=20 >>>>>>>> sub-optimal implementations if the sfc information is present=20 >>>>>>>> only in one >>>>>> fragments, >>>>>>>> etc. >>>>>>>> >>>>>>>> My comments are related to the current text in the -04. >>>>>>>> This text needs >>>>>> to >>>>>>>> be fixed somehow. >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri=20 >>>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 avril >>>>>>>>> 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;=20 >>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for=20 >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> I see no need to specify the exact behavior as NSH is=20 >>>>>>>>> transport independent i.e. like NSH interaction with any other=20 >>>>>>>>> Transport eh issue of Fragmentation is to be dealt in a way=20 >>>>>>>>> that matches the mechanisms supported by the Transport used=20 >>>>>>>>> and do not belong in the NSH draft >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc=20 >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of=20 >>>>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14, >>>>>>>>> 2016 12:43 AM To: Thomas Narten ;=20 >>>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for=20 >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> R-, >>>>>>>>> >>>>>>>>> In addition to other pending issues raised for this draft, I=20 >>>>>>>>> would like to raise this additional one about Section 6. >>>>>>>>> >>>>>>>>> =3D=3D 6. Fragmentation Considerations >>>>>>>>> >>>>>>>>> NSH and the associated transport header are "added" to the=20 >>>>>>>>> encapsulated packet/frame. This additional information=20 >>>>>>>>> increases >>>>>> the >>>>>>>>> size of the packet. In order the ensure proper forwarding of=20 >>>>>>>>> NSH data, several options for handling fragmentation and=20 >>>>>>>>> re-assembly exist: >>>>>>>>> >>>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH=20 >>>>>>>>> and associated transport packets without requiring=20 >>>>>>>>> fragmentation. >>>>>>>>> >>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for=20 >>>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>>> an >>>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>>> the >>>>>>>>> required packet size is used. >>>>>>>>> >>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>>> re- >>>>>> assembly >>>>>>>>> in section 5.4. =3D=3D >>>>>>>>> >>>>>>>>> * The text is weak for a Standard track document that is=20 >>>>>>>>> intended to solve the problem in >>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>> 2.12. >>>>>>>>> There should be a clear behavior to be followed by an >>>>> implementation. >>>>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>>> >>>>>>>>> * The text covers only fragmentation when it is induced by SFC=20 >>>>>>>>> operations, it does not discuss the treatment of a fragment=20 >>>>>>>>> when received in an SFC domain. IMHO, the draft should also=20 >>>>>>>>> specify the behavior of the Classifier with regards to=20 >>>>>>>>> fragments for the sake of proper SFC operation. Applying=20 >>>>>>>>> classification policies may require the >>>>>>>> full packet, not only a fragment. >>>>>>>>> In particular, dedicated resources should dedicated for=20 >>>>>>>>> handling out of order fragments. Of course, it is out of scope=20 >>>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>>> >>>>>>>>> * If an SFC header is prepended for all fragments, I'm not=20 >>>>>>>>> sure there is any particular issue at the SFF level...except=20 >>>>>>>>> if stripping/adding context TLVs depends on the full packet=20 >>>>>>>>> (not just fragment). It is warranted to consider a little bit=20 >>>>>>>>> this point before declaring there >>>>>> is >>>>>>>> no issue. >>>>>>>>> >>>>>>>>> * The text states "several options". This may be interpreted=20 >>>>>>>>> as if implementing one of them is sufficient...which is not=20 >>>>>>>>> true. The first two points contribute to minimize the=20 >>>>>>>>> fragmentation risk, but fragmentation may still be experienced=20 >>>>>>>>> (e.g., other shims are prepended by other nodes for some other=20 >>>>>>>>> purposes, nested nsh, etc.) >>>>>>>>> >>>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>>> >>>>>>>>> * The support of jumbo frames by a router/device does not mean=20 >>>>>>>>> that it can make use of it. Appropriate MTU configuration=20 >>>>>>>>> should be undertaken in a consistent manner within an SFC=20 >>>>>>>>> domain. The text should be updated to make it is about >>>>>>>>> (consistent) MTU >>>>> configuration. >>>>>>>>> >>>>>>>>> * BTW, shouldn't the text be reworded to recommended to=20 >>>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by=20 >>>>>>>>> at least the length of SFC header + transport header? >>>>>>>>> >>>>>>>>> * Bullet 2, how PMTU discovery is actually used in this=20 >>>>>>>>> context? Do you assume that all SFC-aware nodes will issue=20 >>>>>>>>> such messages towards other SFC-aware node, arbitrary=20 >>>>>>>>> destination, else? >>>>>>>>> >>>>>>>>> * Bullet 2, I would drop "describes a technique for=20 >>>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>> >>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>> >>>>>>>>> * The reference to the LISP specification raises two concerns=20 >>>>>>>>> and one comment: >>>>>>>>> >>>>>>>>> (1) I don't think it is a good approach that fragments induced=20 >>>>>>>>> by the network are passed to their ultimate destinations as=20 >>>>>>>>> such >>>>> (stateless). >>>>>>>>> IMO, reassembly should be done within the SFC domain=20 >>>>>>>>> (responsible for fragmentation) not passed away. (2) Does the=20 >>>>>>>>> stateful mode require all SFC data plane elements maintain a=20 >>>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>>> domain? >>>>>>>>> >>>>>>>>> The current text suggests that [RFC6830] should be listed as=20 >>>>>>>>> normative reference (not an informative one). I would=20 >>>>>>>>> personally favor removing the reference to LISP (as it is an=20 >>>>>>>>> Experimental RFC). >>>>>>>>> >>>>>>>>> * The security section of the draft may be augmented with=20 >>>>>>>>> informational fragmentation-related pointers to: >>>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment=20 >>>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny=20 >>>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High=20 >>>>>>>>> Data Rates). >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de=20 >>>>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 avril >>>>>>>>>> 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Dear Thomas, all, >>>>>>>>>> >>>>>>>>>> As I mentioned during the meeting, there are several issues=20 >>>>>>>>>> that are not covered in the last version of the draft. I=20 >>>>>>>>>> already provided examples of the issues offline as requested=20 >>>>>>>>>> by Martin. >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc=20 >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten=20 >>>>>>>>>>> Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : >>>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for=20 >>>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear WG: >>>>>>>>>>> >>>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt=20 >>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> The editors of the NSH document have indicated that they have >>>>>>>>>>> addressed all known comments and that there are no open=20 >>>>>>>>>>> issues with the current version of the document. >>>>>>>>>>> >>>>>>>>>>> Substantive comments to the list please, editorial comments=20 >>>>>>>>>>> can go directly to the document editors. >>>>>>>>>>> >>>>>>>>>>> We'll also get a brief update from the editors at next=20 >>>>>>>>>>> week's meeting. If there are any remaining issues with the=20 >>>>>>>>>>> document, raising them before the meeting would be=20 >>>>>>>>>>> especially helpful. >>>>>>>>>>> >>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing=20 >>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>>>> _______________________________________________ sfc mailing list=20 >>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list=20 >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> _______________________________________________ sfc mailing list=20 >>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>> > From nobody Wed Apr 27 16:03:12 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 4951912B048 for ; Wed, 27 Apr 2016 16:03:11 -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 9CANkdsvUGvp for ; Wed, 27 Apr 2016 16:03:06 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 6466812D19B for ; Wed, 27 Apr 2016 16:03:04 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v145so32591906oie.0 for ; Wed, 27 Apr 2016 16:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qu00wJRBT3vSKsKZddz1E1Bw/pYOn4dTtRsp2GRPwoE=; b=07appwoHtvJ4ovkrOhcAtE9YBMWiEAntfIYIKkZGtEeWiu8Dy0gJXIg6jsoMP4DSnx 4QlBtqv6DJW/SaitWHS+Awy9c/YYqQDksc82bj1qH00hjBxB/ncEFvLUMslGwsmAhMKE aA8X/VsWP098TWhucrA4YZj0LsCDjfmNGd8CFrCdqgubuJd46cw2j9baxYCNR7PUrP0f yiugEDxM3qVY38VxGnjjcTvgDfIdpspVvCpidkwg4jQzMslc0txp1zX54AjetzkljRzC yWi5ci9TYXgT4G/PlFao0zo4OvZyn/Rf/f0M/CjrEwjV2w0m/pZzzsHgpjRhI9QvxSqQ lNfA== 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=qu00wJRBT3vSKsKZddz1E1Bw/pYOn4dTtRsp2GRPwoE=; b=R7+xsFCE7J2IvQwNIBXUASYka0u5lUeMh5BsbYH13R98uOvtyDZBsrJVliN1SpjsuG sMN8hOOk8vePhmdlMM3p4X/22bnL8m1RdSbFyzn2X3HPM7dGpBoFj66svDr9XucZHg4L n9lNnSf0MaW+qy1lg55qD5TfiTwG8P7nGKw1Ti+YFXGnXZ62zNayu/RT7FX7uYipEoJw pzk8nneEcm7sf5ySran9m4TLgKVr+BrEBDEFkvo+Atpl0hxY9g4pKHqCe70zdtNvjHCl 2wRZBKT0TiBhl+tc9djjjKqcV38mFxdmHmmDDyHPTcSoc9CoJaxie4uR1a3U+pZ8XNRR x0Ew== X-Gm-Message-State: AOPr4FX0GBdEaCQgvcCgCRMjXvf3hAMAMIHC8yRSgG9YkFtQ0Y0/p+2icF3D+WQLF0iP9jH2DHeVGQedNW19OQ== X-Received: by 10.157.48.98 with SMTP id w31mr4681377otd.61.1461798183556; Wed, 27 Apr 2016 16:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Wed, 27 Apr 2016 16:02:44 -0700 (PDT) In-Reply-To: <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> From: "Andrew G. Malis" Date: Wed, 27 Apr 2016 19:02:44 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a114187be76da1e05317f696d Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 23:03:11 -0000 --001a114187be76da1e05317f696d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joel et al, All this talk about fragmentation prompted me to re-read section 6 of the draft, which recommends (as option 3) using the procedures in section 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80=9D replacing the= =E2=80=9CLISP header=E2=80=9D in the description of the procedures in that section). So that led me to read that section (and the LISP header definition in section 5.1), and I see that LISP does fragmentation and reassembly identically to IPv4, using the Fragment Offset field so that fragments can be correctly reassembled in the proper order. However, the NSH Header doesn=E2=80=99t have a Fragment Offset field or any= other way to order the fragments. So how can the procedures in Section 5.4 of 6830 be used? Thanks, Andy On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern wrote: > Both methods are valid, and both depend upon details of the underlying > packet and the transport. As such, I don't see why this document benefit= s > from describing them, much less why it should mark one method as a > "should". Implementation details are likely to be more significant than > any bit consumption difference between the two alternatives. > > Yours, > Joel > > > On 4/27/16 3:40 PM, Linda Dunbar wrote: > >> I suggest adding the following paragraphs after the Bullet 3 of the >> Section 6 Fragmentation Consideration to make the process more clear and >> less controversial: >> >> >> -------------------------------- >> >> RFC6830 describes the fragmentation method of breaking the original >> packet into two equal sub-frames and encapsulating [LISP Header + Transp= ort >> header] to each sub-frame. >> >> If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + >> Transport Header] will be added to each half frame (or the original data >> frame). As the Transport Header is terminated by the next SFF node's tun= nel >> transport layer, the combined two sub-frames will have two SFC Headers. >> >> Therefore, the fragmentation for NSH encapsulated data frame should be >> done completely by the node tunnel transport layer, which should break t= he >> [SFC + original packet] into two equal sub-frames and each sub-frame bei= ng >> encapsulated with its respective tunnel header. The next SFF node's tun= nel >> transport layer should combine the two sub-frames before sending to the >> next node. >> >> ------------------------------------------------------ >> >> >> By the way, there are to typo in the Section 6: >> 3rd line: "In order the" =3D=3D> "In order to" >> Last line of Bullet 2: extra "the" in the "utilized to ensure the the >> required packet". >> >> >> Hope it helps. >> >> Linda >> >> >> >> -----Original Message----- >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >> Sent: Wednesday, April 27, 2016 12:40 AM >> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org >> Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, all, >> >> Please see inline. >> >> Cheers, >> Med >> >> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : mardi 2= 6 >>> avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzu= r, >>> Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> With regard to Transport tunnel fragementation, that seems an issue >>> for the transport protocol. I don't actually object to a sentence, >>> but it does not seem that it will accomplish anything. >>> >> >> [Med] I would like to see some text added to the draft. >> >> >>> With regard to packets fragmented by the source, I completely disagree >>> with your assertion. If an SFF were to reassemble the packets, that >>> would be a violation of its job. >>> >> >> [Med] I agree with you. >> >> There is no reason for an SFF to >> >>> reassemble a packet fragmented by the source. The classifier may have >>> to do some interesting things in order to properly classify succeeding >>> fragments, but that is an implementation issue (most commonly >>> addressed with virtual reassembly, which doe snot delay the >>> fragments.) We don't specity that. >>> >> >> [Med] Still, the external behavior of the classifier needs to be clear i= n >> the document. I don't find any text in the draft saying for instance tha= t >> an NSH header must be present in all fragments. (There some processing t= hat >> might be needed at the SFF to "do its job" with regards to fragments >> (receive out of order fragments + forwarding policy on the full packet).= ) >> >> >>> If an SF needs to reassemble fragments to do its job, that is up to >>> the SF. Some will need to actually reassemble. Some will need to >>> perform virtual reassembly, and some will happily process the >>> fragments. I can not see what the NSH document could possibly mandate. >>> >> >> [Med] Fully agree. >> >> >>> Yours, >>> Joel >>> >>> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> >>>> Joel, >>>> >>>> I think the document should add the description on the following two >>>> fragmentation scenarios: >>>> >>>> - Transport tunnel generated fragmentation: When a packet >>>> fragmentation is caused by transport tunnel (i.e. various >>>> encapsulations), the termination point of the transport tunnel is >>>> responsible for re-assembling the fragmented pieces of the packet. >>>> Since there won't be any SFF nodes in between the Transport Tunnel, >>>> the tunnel generated fragmentation does not require any actions by >>>> SFF nodes or SF nodes. >>>> >>>> >>>> - Source node generated fragmentation (after adding on the NSH >>>> header): When fragmentation has to be performed for a packet being >>>> encapsulated with the NSH header, either the intermediate SFF nodes >>>> or the SF nodes have to be able to reassemble the fragmented pieces. >>>> >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> Linda >>>> >>>> -----Original Message----- From: Joel M. Halpern >>>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM >>>> To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; >>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>> draft-ietf-sfc-nsh-04.txt >>>> >>>> Re-reading your note, it is possible that you are referring only to >>>> the case of transport generated fragmentation of the outer packet. >>>> I had assumed you were not talking about that, since the resulting >>>> fragments will not all have NSH headers. As with any tunnel >>>> technology, if the tunnel chooses to fragment at its layer, then the >>>> tunnel is responsible for reassembly. That would be invisible to >>>> the SFF. >>>> >>>> Yours, Joel >>>> >>>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>> >>>>> Agree with Med. >>>>> >>>>> Even if each fragment piece of a packet with NSH header carries the >>>>> NSH header, the intermediate SFF nodes still need to put together >>>>> all the fragments together before passing the whole data frame to >>>>> the SF. >>>>> >>>>> Linda >>>>> >>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>>>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: >>>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>> >>>>> Re-, >>>>> >>>>> How do you instruct the transport layer to ALWAYS prepend an NSH >>>>> header even for fragments? Or you don't care about that? >>>>> >>>>> Thank you. >>>>> >>>>> Cheers, Med >>>>> >>>>> -----Message d'origine----- De : Elzur, Uri >>>>>> [mailto:uri.elzur@intel.com] Envoy=C3=A9 : lundi 25 avril 2016 16:26= =C3=80 >>>>>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet >>>>>> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Med >>>>>> >>>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH is >>>>>> *NOT* a transport, dealing with fragmentation is left to the >>>>>> Transport used. >>>>>> >>>>>> The model I use for NSH, is basically similar to VXLAN . It is an >>>>>> overly. >>>>>> >>>>>> Thx >>>>>> >>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>> >>>>>> >>>>>> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] >>>>>> On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, >>>>>> 2016 7:18 AM To: Joel M. Halpern ; >>>>>> sfc@ietf.org >>>>>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>> >>>>>> Hi Joel, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>> -----Message d'origine----- De : Joel M. Halpern >>>>>>> [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : lundi 25 avril 2016 15:4= 8 =C3=80 >>>>>>> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG >>>>>>> last call for draft-ietf-sfc-nsh-04.txt >>>>>>> >>>>>>> If I am understanding you correctly Med, you are asking that the >>>>>>> NSH draft specify how service chaining should cope with packets >>>>>>> that have been fragmented? >>>>>>> >>>>>>> >>>>>> [Med] To be accurate, I'm asking to assess whether there are >>>>>> implications. If there are, then the draft should be updated >>>>>> accordingly. >>>>>> >>>>>> NSH, and the SFF functionality, does not care. >>>>>>> >>>>>> >>>>>> [Med] I'm not that sure. Some typical implications are listed >>>>>> below: >>>>>> >>>>>> * SFF: If the NSH header is present only in the a fragment but SFF >>>>>> didn't maintained a state, subsequent fragments won't be >>>>>> appropriately processed. * SFC-aware function: if prepending a >>>>>> context information depends on the full packet, not only a >>>>>> fragment. >>>>>> >>>>>> It just does its job. >>>>>> >>>>>> [Med] which may be disturbed in some situations as listed in the >>>>>> examples above. >>>>>> >>>>>> Ingress and intermediate classifiers may cope with fragments in >>>>>>> any number of ways. >>>>>>> >>>>>> Specifying such is clearly out of scope for this draft. >>>>>> >>>>>> [Med] The purpose is not to specify the internal implementation >>>>>> details but the external behavior of the classifier function when >>>>>> it comes to handle fragments. That behavior may have an incidence >>>>>> on SFF, in particular. The purpose is not to recommend the maximum >>>>>> resources to be dedicated to out of order fragments nor the >>>>>> timeout to cache those; these considerations are of course out of >>>>>> scope. Nevertheless, an implementation should offer a configurable >>>>>> parameter so that an operator tweak those according to its >>>>>> context. >>>>>> >>>>>> I suppose one could write an informational draft on possible ways >>>>>>> of coping. The IETF has not usually published such. >>>>>>> Service functions have to cope with fragmented packets just as >>>>>>> they had to before the advent of NSH, so describing that is >>>>>>> clearly not needed here. >>>>>>> >>>>>> >>>>>> [Med] The advent of NSH has the following implications: * it >>>>>> exacerbates fragmentation. Handing over this issue to the >>>>>> transport layer may lead to interoperability issues. * the >>>>>> chaining may not be efficient if fragments are inappropriately >>>>>> handled. >>>>>> >>>>>> Introducing NSH should not degrade the overall service compared to >>>>>> legacy service deployment schemes. >>>>>> >>>>>> >>>>>>> Yours, Joel >>>>>>> >>>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: >>>>>>> >>>>>>>> Re-, >>>>>>>> >>>>>>>> I hear you, but my comment is that we need, as a WG, to decide >>>>>>>> what to >>>>>>>> >>>>>>> put in the draft. FWIW, I'm discussing two fragmentation >>>>>>> issues: >>>>>>> >>>>>>>> >>>>>>>> (1) Fragmentation that is caused by prepending an SFC header. >>>>>>>> (2) Handling fragments at the ingress of an SFC-enabled domain. >>>>>>>> >>>>>>>> Increasing the MTU is for sure a recommendation is to be >>>>>>>> explicitly >>>>>>>> >>>>>>> called out in the text (see my first message). >>>>>>> >>>>>>>> >>>>>>>> There are other issues that need to be discussed, e.g., how to >>>>>>>> deal with >>>>>>>> >>>>>>> fragments in SFFs/Classifiers? >>>>>>> >>>>>>>> >>>>>>>> It is also "prudent" to check that no issues will be experienced >>>>>>>> in SFF >>>>>>>> >>>>>>> to handle fragments. If an SFC header is prepended for all >>>>>>> fragments, I'm not sure there >>>>>>> >>>>>>>> is any particular issue at the SFF level, except if >>>>>>>> stripping/adding >>>>>>>> >>>>>>> context TLVs depends on the full packet (not just fragment). It >>>>>>> is warranted to consider a little bit this point before declaring >>>>>>> there is no issue. >>>>>>> >>>>>>>> >>>>>>>> For point (1), declaring fragmentation out of scope would be >>>>>>>> meant that >>>>>>>> >>>>>>> an implementation must be prepared to receive fragments with or >>>>>>> without NSH header as this is a decision that is left to the >>>>>>> transport encapsulation. This is a requirement per se! >>>>>>> >>>>>>>> >>>>>>>> I won't reiterate all the comments I have about the current >>>>>>>> wording of >>>>>>>> >>>>>>> this section. >>>>>>> >>>>>>>> >>>>>>>> Cheers, Med >>>>>>>> >>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>> [mailto:uri.elzur@intel.com] Envoy=C3=A9 : lundi 25 avril 2016 >>>>>>>>> 08:30 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Med >>>>>>>>> >>>>>>>>> My point is that Fragmentation is yet another transport related >>>>>>>>> issue >>>>>>>>> >>>>>>>> that >>>>>>> >>>>>>>> is beyond the scope of NSH and beyond the charter of the WG, so >>>>>>>>> it >>>>>>>>> >>>>>>>> doesn't >>>>>>> >>>>>>>> really belong in the draft. We are providing an advice as >>>>>>>>> extending the size of the packet may lead to fragmentation, but >>>>>>>>> as you check RFC 7348 VxLAN, which my create the same issue, >>>>>>>>> you'll find it doesn't even >>>>>>>>> >>>>>>>> relate >>>>>>> >>>>>>>> to it. >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- From: sfc >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 >>>>>>>>> 10:32 PM To: Elzur, Uri ; Thomas Narten >>>>>>>>> >>>>>>>> ; >>>>>>> >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>> >>>>>>>>> Hi Uri, >>>>>>>>> >>>>>>>>> That's another option that needs to be discussed/investigated. >>>>>>>>> I'm >>>>>>>>> >>>>>>>> afraid >>>>>>> >>>>>>>> this is not the rationale adopted in -04 since it includes some >>>>>>>>> text >>>>>>>>> >>>>>>>> that >>>>>>> >>>>>>>> is far to be sufficient to ensure interoperable >>>>>>>>> implementations. >>>>>>>>> >>>>>>>>> BTW, saying that nsh does not need to deal with fragmentation >>>>>>>>> because >>>>>>>>> >>>>>>>> it >>>>>>> >>>>>>>> is transport-independent is not IMHO a good strategy to adopt >>>>>>>>> here >>>>>>>>> >>>>>>>> because >>>>>>> >>>>>>>> it opens the door for interoperable issues, it may lead to >>>>>>>>> sub-optimal implementations if the sfc information is present >>>>>>>>> only in one >>>>>>>>> >>>>>>>> fragments, >>>>>>> >>>>>>>> etc. >>>>>>>>> >>>>>>>>> My comments are related to the current text in the -04. >>>>>>>>> This text needs >>>>>>>>> >>>>>>>> to >>>>>>> >>>>>>>> be fixed somehow. >>>>>>>>> >>>>>>>>> Cheers, Med >>>>>>>>> >>>>>>>>> -----Message d'origine----- De : Elzur, Uri >>>>>>>>>> [mailto:uri.elzur@intel.com] Envoy=C3=A9 : dimanche 24 avril >>>>>>>>>> 2016 17:36 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; >>>>>>>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for >>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> Hi Med >>>>>>>>>> >>>>>>>>>> I see no need to specify the exact behavior as NSH is >>>>>>>>>> transport independent i.e. like NSH interaction with any other >>>>>>>>>> Transport eh issue of Fragmentation is to be dealt in a way >>>>>>>>>> that matches the mechanisms supported by the Transport used >>>>>>>>>> and do not belong in the NSH draft >>>>>>>>>> >>>>>>>>>> Thx >>>>>>>>>> >>>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- From: sfc >>>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of >>>>>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April 14, >>>>>>>>>> 2016 12:43 AM To: Thomas Narten ; >>>>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for >>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>> >>>>>>>>>> R-, >>>>>>>>>> >>>>>>>>>> In addition to other pending issues raised for this draft, I >>>>>>>>>> would like to raise this additional one about Section 6. >>>>>>>>>> >>>>>>>>>> =3D=3D 6. Fragmentation Considerations >>>>>>>>>> >>>>>>>>>> NSH and the associated transport header are "added" to the >>>>>>>>>> encapsulated packet/frame. This additional information >>>>>>>>>> increases >>>>>>>>>> >>>>>>>>> the >>>>>>> >>>>>>>> size of the packet. In order the ensure proper forwarding of >>>>>>>>>> NSH data, several options for handling fragmentation and >>>>>>>>>> re-assembly exist: >>>>>>>>>> >>>>>>>>>> 1. Jumbo Frames, when supported, enable the transport of NSH >>>>>>>>>> and associated transport packets without requiring >>>>>>>>>> fragmentation. >>>>>>>>>> >>>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a technique for >>>>>>>>>> dynamically discovering the maximum transmission unit (MTU) of >>>>>>>>>> >>>>>>>>> an >>>>>>> >>>>>>>> arbitrary internet path" and can be utilized to ensure the >>>>>>>>>> >>>>>>>>> the >>>>>> >>>>>>> required packet size is used. >>>>>>>>>> >>>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation and >>>>>>>>>> re- >>>>>>>>>> >>>>>>>>> assembly >>>>>>> >>>>>>>> in section 5.4. =3D=3D >>>>>>>>>> >>>>>>>>>> * The text is weak for a Standard track document that is >>>>>>>>>> intended to solve the problem in >>>>>>>>>> https://tools.ietf.org/html/rfc7498#section- >>>>>>>>>> >>>>>>>>> 2.12. >>>>>> >>>>>>> There should be a clear behavior to be followed by an >>>>>>>>>> >>>>>>>>> implementation. >>>>>> >>>>>>> Further, I would avoid the use of words such as "can". >>>>>>>>>> >>>>>>>>>> * The text covers only fragmentation when it is induced by SFC >>>>>>>>>> operations, it does not discuss the treatment of a fragment >>>>>>>>>> when received in an SFC domain. IMHO, the draft should also >>>>>>>>>> specify the behavior of the Classifier with regards to >>>>>>>>>> fragments for the sake of proper SFC operation. Applying >>>>>>>>>> classification policies may require the >>>>>>>>>> >>>>>>>>> full packet, not only a fragment. >>>>>>>>> >>>>>>>>>> In particular, dedicated resources should dedicated for >>>>>>>>>> handling out of order fragments. Of course, it is out of scope >>>>>>>>>> of this document to describe how SFs handle fragments. >>>>>>>>>> >>>>>>>>>> * If an SFC header is prepended for all fragments, I'm not >>>>>>>>>> sure there is any particular issue at the SFF level...except >>>>>>>>>> if stripping/adding context TLVs depends on the full packet >>>>>>>>>> (not just fragment). It is warranted to consider a little bit >>>>>>>>>> this point before declaring there >>>>>>>>>> >>>>>>>>> is >>>>>>> >>>>>>>> no issue. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> * The text states "several options". This may be interpreted >>>>>>>>>> as if implementing one of them is sufficient...which is not >>>>>>>>>> true. The first two points contribute to minimize the >>>>>>>>>> fragmentation risk, but fragmentation may still be experienced >>>>>>>>>> (e.g., other shims are prepended by other nodes for some other >>>>>>>>>> purposes, nested nsh, etc.) >>>>>>>>>> >>>>>>>>>> * The first two points have nothing to do with reassembly. >>>>>>>>>> >>>>>>>>>> * The support of jumbo frames by a router/device does not mean >>>>>>>>>> that it can make use of it. Appropriate MTU configuration >>>>>>>>>> should be undertaken in a consistent manner within an SFC >>>>>>>>>> domain. The text should be updated to make it is about >>>>>>>>>> (consistent) MTU >>>>>>>>>> >>>>>>>>> configuration. >>>>>> >>>>>>> >>>>>>>>>> * BTW, shouldn't the text be reworded to recommended to >>>>>>>>>> increase the MTU of **all nodes** of an SFC-enabled domain by >>>>>>>>>> at least the length of SFC header + transport header? >>>>>>>>>> >>>>>>>>>> * Bullet 2, how PMTU discovery is actually used in this >>>>>>>>>> context? Do you assume that all SFC-aware nodes will issue >>>>>>>>>> such messages towards other SFC-aware node, arbitrary >>>>>>>>>> destination, else? >>>>>>>>>> >>>>>>>>>> * Bullet 2, I would drop "describes a technique for >>>>>>>>>> dynamically discovering the maximum transmission unit >>>>>>>>>> (MTU) of an arbitrary internet path". >>>>>>>>>> >>>>>>>>>> * Bullet 2, s/ the the/the. >>>>>>>>>> >>>>>>>>>> * The reference to the LISP specification raises two concerns >>>>>>>>>> and one comment: >>>>>>>>>> >>>>>>>>>> (1) I don't think it is a good approach that fragments induced >>>>>>>>>> by the network are passed to their ultimate destinations as >>>>>>>>>> such >>>>>>>>>> >>>>>>>>> (stateless). >>>>>> >>>>>>> IMO, reassembly should be done within the SFC domain >>>>>>>>>> (responsible for fragmentation) not passed away. (2) Does the >>>>>>>>>> stateful mode require all SFC data plane elements maintain a >>>>>>>>>> full list of MTU for the any SFF/SF instance of the SFC >>>>>>>>>> >>>>>>>>> domain? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The current text suggests that [RFC6830] should be listed as >>>>>>>>>> normative reference (not an informative one). I would >>>>>>>>>> personally favor removing the reference to LISP (as it is an >>>>>>>>>> Experimental RFC). >>>>>>>>>> >>>>>>>>>> * The security section of the draft may be augmented with >>>>>>>>>> informational fragmentation-related pointers to: >>>>>>>>>> e.g., RFC1858 (Security Considerations for IP Fragment >>>>>>>>>> Filtering), RFC3128 (Protection Against a Variant of the Tiny >>>>>>>>>> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High >>>>>>>>>> Data Rates). >>>>>>>>>> >>>>>>>>>> Cheers, Med >>>>>>>>>> >>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de >>>>>>>>>>> mohamed.boucadair@orange.com Envoy=C3=A9 : lundi 11 avril >>>>>>>>>>> 2016 13:14 =C3=80 : Thomas Narten; sfc@ietf.org Objet : Re: >>>>>>>>>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>>>>>>>>>> >>>>>>>>>>> Dear Thomas, all, >>>>>>>>>>> >>>>>>>>>>> As I mentioned during the meeting, there are several issues >>>>>>>>>>> that are not covered in the last version of the draft. I >>>>>>>>>>> already provided examples of the issues offline as requested >>>>>>>>>>> by Martin. >>>>>>>>>>> >>>>>>>>>>> Cheers, Med >>>>>>>>>>> >>>>>>>>>>> -----Message d'origine----- De : sfc >>>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten >>>>>>>>>>>> Envoy=C3=A9 : jeudi 31 mars 2016 04:48 =C3=80 : >>>>>>>>>>>> sfc@ietf.org Objet : [sfc] WG last call for >>>>>>>>>>>> draft-ietf-sfc-nsh-04.txt >>>>>>>>>>>> >>>>>>>>>>>> Dear WG: >>>>>>>>>>>> >>>>>>>>>>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt >>>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The editors of the NSH document have indicated that they have >>> >>>> addressed all known comments and that there are no open >>>>>>>>>>>> issues with the current version of the document. >>>>>>>>>>>> >>>>>>>>>>>> Substantive comments to the list please, editorial comments >>>>>>>>>>>> can go directly to the document editors. >>>>>>>>>>>> >>>>>>>>>>>> We'll also get a brief update from the editors at next >>>>>>>>>>>> week's meeting. If there are any remaining issues with the >>>>>>>>>>>> document, raising them before the meeting would be >>>>>>>>>>>> especially helpful. >>>>>>>>>>>> >>>>>>>>>>>> For the chairs, Thomas >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ sfc mailing >>>>>>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ sfc mailing list >>>>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ sfc mailing list >>>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>>> _______________________________________________ sfc mailing list >>>>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>>> >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a114187be76da1e05317f696d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Joel et al,

All this talk about fragmen= tation prompted me to re-read section 6 of the draft, which recommends (as = option 3) using the procedures in section 5.4 of RFC 6830 (presumably with = the =E2=80=9CNSH header=E2=80=9D replacing the =E2=80=9CLISP header=E2=80= =9D in the description of the procedures in that section).

So that led me to read that section (and the LISP header definitio= n in section 5.1), and I see that LISP does fragmentation and reassembly id= entically to IPv4, using the Fragment Offset field so that fragments can be= correctly reassembled in the proper order.

Howeve= r, the NSH Header doesn=E2=80=99t have a Fragment Offset field or any other= way to order the fragments.

So how can the proced= ures in Section 5.4 of 6830 be used?

Thanks,
=
Andy

On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
Both methods are = valid, and both depend upon details of the underlying packet and the transp= ort.=C2=A0 As such, I don't see why this document benefits from describ= ing them, much less why it should mark one method as a "should".= =C2=A0 Implementation details are likely to be more significant than any bi= t consumption difference between the two alternatives.

Yours,
Joel


On 4/27/16 3:40 PM, Linda Dunbar wrote:
I suggest adding the following paragraphs after the Bullet 3 of the Section= 6 Fragmentation Consideration to make the process more clear and less cont= roversial:


--------------------------------

RFC6830 describes the fragmentation method of breaking the original packet = into two equal sub-frames and encapsulating [LISP Header + Transport header= ] to each sub-frame.

If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Tran= sport Header] will be added to each half frame (or the original data frame)= . As the Transport Header is terminated by the next SFF node's tunnel t= ransport layer, the combined two sub-frames will have two SFC Headers.

Therefore, the fragmentation for NSH encapsulated data frame should be done= completely by the node tunnel transport layer, which should break the [SFC= + original packet] into two equal sub-frames and each sub-frame being enca= psulated with its respective tunnel header.=C2=A0 The next SFF node's t= unnel transport layer should combine the two sub-frames before sending to t= he next node.

------------------------------------------------------


By the way, there are to typo in the Section 6:
3rd line: "In order the" =3D=3D> "In order to"
Last line of Bullet 2: extra "the" in the "utilized to ensur= e the the required packet".


Hope it helps.

Linda



-----Original Message-----
From: moh= amed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, April 27, 2016 12:40 AM
To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org
Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Hi Joel, all,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : mardi 26
avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur, Uri; sfc@ietf.org Obj= et : Re: [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

With regard to Transport tunnel fragementation, that seems an issue
for the transport protocol.=C2=A0 I don't actually object to a sentence= ,
but it does not seem that it will accomplish anything.

[Med] I would like to see some text added to the draft.


With regard to packets fragmented by the source, I completely disagree
with your assertion.=C2=A0 If an SFF were to reassemble the packets, that would be a violation of its job.

[Med] I agree with you.

=C2=A0 There is no reason for an SFF to
reassemble a packet fragmented by the source.=C2=A0 The classifier may have=
to do some interesting things in order to properly classify succeeding
fragments, but that is an implementation issue (most commonly
addressed with virtual reassembly, which doe snot delay the
fragments.)=C2=A0 We don't specity that.

[Med] Still, the external behavior of the classifier needs to be clear in t= he document. I don't find any text in the draft saying for instance tha= t an NSH header must be present in all fragments. (There some processing th= at might be needed at the SFF to "do its job" with regards to fra= gments (receive out of order fragments + forwarding policy on the full pack= et).)


If an SF needs to reassemble fragments to do its job, that is up to
the SF.=C2=A0 Some will need to actually reassemble.=C2=A0 Some will need t= o
perform virtual reassembly, and some will happily process the
fragments.=C2=A0 I can not see what the NSH document could possibly mandate= .

[Med] Fully agree.


Yours,
Joel

On 4/26/16 11:47 AM, Linda Dunbar wrote:
Joel,

I think the document should add the description on the following two
fragmentation scenarios:

- Transport tunnel generated fragmentation: When a packet
fragmentation is caused by transport tunnel (i.e. various
encapsulations), the termination point of the transport tunnel is
responsible for re-assembling the fragmented pieces of the packet.
Since there won't be any SFF nodes in between the Transport Tunnel,
the tunnel generated fragmentation does not require any actions by
SFF nodes or SF nodes.


- Source node generated fragmentation (after adding on the NSH
header): When fragmentation has to be performed for a packet being
encapsulated with the NSH header, either the intermediate SFF nodes
or the SF nodes have to be able to reassemble the fragmented pieces.




Cheers,


Linda

-----Original Message----- From: Joel M. Halpern
[mailto:jmh@joelha= lpern.com] Sent: Tuesday, April 26, 2016 10:33 AM
To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri;
sfc@ietf.org Subject:= Re: [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

Re-reading your note, it is possible that you are referring only to
the case of transport generated fragmentation of the outer packet.
I had assumed you were not talking about that, since the resulting
fragments will not all have NSH headers.=C2=A0 As with any tunnel
technology, if the tunnel chooses to fragment at its layer, then the
tunnel is responsible for reassembly.=C2=A0 That would be invisible to
the SFF.

Yours, Joel

On 4/26/16 11:10 AM, Linda Dunbar wrote:
Agree with Med.

Even if each fragment piece of a packet with NSH header carries the
NSH header, the intermediate SFF nodes still need to put together
all the fragments together before passing the whole data frame to
the SF.

Linda

-----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25,
2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject:
Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Re-,

How do you instruct the transport layer to ALWAYS prepend an NSH
header even for fragments? Or you don't care about that?

Thank you.

Cheers, Med

-----Message d'origine----- De : Elzur, Uri
[mailto:uri.elzur@= intel.com] Envoy=C3=A9 : lundi 25 avril 2016 16:26 =C3=80
: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet
: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Hi Med

Not to repeat my position, but I'll do it anyhow :-) As NSH is
*NOT* a transport, dealing with fragmentation is left to the
Transport used.

The model I use for NSH, is basically similar to VXLAN . It is an
overly.

Thx

Uri ("Oo-Ree") C: 949-378-7568


-----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25,
2016 7:18 AM To: Joel M. Halpern <jmh@joelhalpern.com>;
sfc@ietf.org
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Hi Joel,

Please see inline.

Cheers, Med

-----Message d'origine----- De : Joel M. Halpern
[mailto:jmh@joelha= lpern.com] Envoy=C3=A9 : lundi 25 avril 2016 15:48 =C3=80
: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG
last call for draft-ietf-sfc-nsh-04.txt

If I am understanding you correctly Med, you are asking that the
NSH draft specify how service chaining should cope with packets
that have been fragmented?


[Med] To be accurate, I'm asking to assess whether there are
implications. If there are, then the draft should be updated
accordingly.

NSH, and the SFF functionality, does not care.

[Med] I'm not that sure. Some typical implications are listed
below:

* SFF: If the NSH header is present only in the a fragment but SFF
didn't maintained a state, subsequent fragments won't be
appropriately processed. * SFC-aware function: if prepending a
context information depends on the full packet, not only a
fragment.

It just does its job.

[Med] which may be disturbed in some situations as listed in the
examples above.

Ingress and intermediate classifiers may cope with fragments in
any number of ways.
Specifying such is clearly out of scope for this draft.

[Med] The purpose is not to specify the internal implementation
details but the external behavior of the classifier function when
it comes to handle fragments. That behavior may have an incidence
on SFF, in particular. The purpose is not to recommend the maximum
resources to be dedicated to out of order fragments nor the
timeout to cache those; these considerations are of course out of
scope. Nevertheless, an implementation should offer a configurable
parameter so that an operator tweak those according to its
context.

I suppose one could write an informational draft on possible ways
of coping.=C2=A0 The IETF has not usually published such.
Service functions have to cope with fragmented packets just as
they had to before the advent of NSH, so describing that is
clearly not needed here.

[Med] The advent of NSH has the following implications: * it
exacerbates fragmentation. Handing over this issue to the
transport layer may lead to interoperability issues. * the
chaining may not be efficient if fragments are inappropriately
handled.

Introducing NSH should not degrade the overall service compared to
legacy service deployment schemes.


Yours, Joel

On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote:
Re-,

I hear you, but my comment is that we need, as a WG, to decide
what to
put in the draft. FWIW, I'm discussing two fragmentation
issues:

(1) Fragmentation that is caused by prepending an SFC header.
(2) Handling fragments at the ingress of an SFC-enabled domain.

Increasing the MTU is for sure a recommendation is to be
explicitly
called out in the text (see my first message).

There are other issues that need to be discussed, e.g., how to
deal with
fragments in SFFs/Classifiers?

It is also "prudent" to check that no issues will be experienced<= br> in SFF
to handle fragments. If an SFC header is prepended for all
fragments, I'm not sure there
is any particular issue at the SFF level, except if
stripping/adding
context TLVs depends on the full packet (not just fragment). It
is warranted to consider a little bit this point before declaring
there is no issue.

For point (1), declaring fragmentation out of scope would be
meant that
an implementation must be prepared to receive fragments with or
without NSH header as this is a decision that is left to the
transport encapsulation. This is a requirement per se!

I won't reiterate all the comments I have about the current
wording of
this section.

Cheers, Med

-----Message d'origine----- De : Elzur, Uri
[mailto:uri.elzur@= intel.com] Envoy=C3=A9 : lundi 25 avril 2016
08:30 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;
sfc@ietf.org Objet : = RE: [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

Hi Med

My point is that Fragmentation is yet another transport related
issue
that
is beyond the scope of NSH and beyond the charter of the WG, so
it
doesn't
really belong in the draft. We are providing an advice as
extending the size of the packet may lead to fragmentation, but
as you check RFC 7348 VxLAN, which my create the same issue,
you'll find it doesn't even
relate
to it.

Thx

Uri ("Oo-Ree") C: 949-378-7568


-----Original Message----- From: sfc
[mailto:sfc-bounc= es@ietf.org] On Behalf Of
mohamed.b= oucadair@orange.com Sent: Sunday, April 24, 2016
10:32 PM To: Elzur, Uri <uri.elzur@intel.com>; Thomas Narten
<narten@us.ibm.co= m>;
sfc@ietf.org Subject:= Re: [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

Hi Uri,

That's another option that needs to be discussed/investigated.
I'm
afraid
this is not the rationale adopted in -04 since it includes some
text
that
is far to be sufficient to ensure interoperable
implementations.

BTW, saying that nsh does not need to deal with fragmentation
because
it
is transport-independent is not IMHO a good strategy to adopt
here
because
it opens the door for interoperable issues, it may lead to
sub-optimal implementations if the sfc information is present
only in one
fragments,
etc.

My comments are related to the current text in the -04.
This text needs
to
be fixed somehow.

Cheers, Med

-----Message d'origine----- De : Elzur, Uri
[mailto:uri.elzur@= intel.com] Envoy=C3=A9 : dimanche 24 avril
2016 17:36 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;
sfc@ietf.org Objet : = RE: [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

Hi Med

I see no need to specify the exact behavior as NSH is
transport independent i.e. like NSH interaction with any other
Transport eh issue of Fragmentation is to be dealt in a way
that matches the mechanisms supported by the Transport used
and do not belong in the NSH draft

Thx

Uri ("Oo-Ree") C: 949-378-7568


-----Original Message----- From: sfc
[mailto:sfc-bounc= es@ietf.org] On Behalf Of
mohamed.b= oucadair@orange.com Sent: Thursday, April 14,
2016 12:43 AM To: Thomas Narten <narten@us.ibm.com>;
sfc@ietf.org Subject:= Re: [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

R-,

In addition to other pending issues raised for this draft, I
would like to raise this additional one about Section 6.

=3D=3D 6.=C2=A0 Fragmentation Considerations

NSH and the associated transport header are "added" to the
encapsulated packet/frame.=C2=A0 This additional information
increases
the
size of the packet.=C2=A0 In order the ensure proper forwarding of
NSH data, several options for handling fragmentation and
re-assembly exist:

1.=C2=A0 Jumbo Frames, when supported, enable the transport of NSH
and associated transport packets without requiring
fragmentation.

2.=C2=A0 Path MTU Discovery [RFC1191]"describes a technique for
dynamically discovering the maximum transmission unit (MTU) of
an
arbitrary internet path" and can be utilized to ensure the
the
required packet size is used.

3.=C2=A0 [RFC6830] describes two schemes for fragmentation and
re-
assembly
in section 5.4. =3D=3D

* The text is weak for a Standard track document that is
intended to solve the problem in
https://tools.ietf.org/html/rfc7498#section-
2.12.
There should be a clear behavior to be followed by an
implementation.
Further, I would avoid the use of words such as "can".

* The text covers only fragmentation when it is induced by SFC
operations, it does not discuss the treatment of a fragment
when received in an SFC domain. IMHO, the draft should also
specify the behavior of the Classifier with regards to
fragments for the sake of proper SFC operation. Applying
classification policies may require the
full packet, not only a fragment.
In particular, dedicated resources should dedicated for
handling out of order fragments. Of course, it is out of scope
of this document to describe how SFs handle fragments.

* If an SFC header is prepended for all fragments, I'm not
sure there is any particular issue at the SFF level...except
if stripping/adding context TLVs depends on the full packet
(not just fragment). It is warranted to consider a little bit
this point before declaring there
is
no issue.

* The text states "several options". This may be interpreted
as if implementing one of them is sufficient...which is not
true. The first two points contribute to minimize the
fragmentation risk, but fragmentation may still be experienced
(e.g., other shims are prepended by other nodes for some other
purposes, nested nsh, etc.)

* The first two points have nothing to do with reassembly.

* The support of jumbo frames by a router/device does not mean
that it can make use of it. Appropriate MTU configuration
should be undertaken in a consistent manner within an SFC
domain. The text should be updated to make it is about
(consistent) MTU
configuration.

* BTW, shouldn't the text be reworded to recommended to
increase the MTU of **all nodes** of an SFC-enabled domain by
at least the length of SFC header + transport header?

* Bullet 2, how PMTU discovery is actually used in this
context? Do you assume that all SFC-aware nodes will issue
such messages towards other SFC-aware node, arbitrary
destination, else?

* Bullet 2, I would drop "describes a technique for
dynamically discovering the maximum transmission unit
(MTU) of an arbitrary internet path".

* Bullet 2, s/ the the/the.

* The reference to the LISP specification raises two concerns
and one comment:

(1) I don't think it is a good approach that fragments induced
by the network are passed to their ultimate destinations as
such
(stateless).
IMO, reassembly should be done within the SFC domain
(responsible for fragmentation) not passed away. (2) Does the
stateful mode require all SFC data plane elements maintain a
full list of MTU for the any SFF/SF instance of the SFC
domain?

The current text suggests that [RFC6830] should be listed as
normative reference (not an informative one). I would
personally favor removing the reference to LISP (as it is an
Experimental RFC).

* The security section of the draft may be augmented with
informational fragmentation-related pointers to:
e.g., RFC1858 (Security Considerations for IP Fragment
Filtering), RFC3128 (Protection Against a Variant of the Tiny
Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High
Data Rates).

Cheers, Med

-----Message d'origine----- De : sfc
[mailto:sfc-bounc= es@ietf.org] De la part de
mohamed.b= oucadair@orange.com Envoy=C3=A9 : lundi 11 avril
2016 13:14 =C3=80 : Thomas Narten; sfc@ietf.org Objet : Re:
[sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Dear Thomas, all,

As I mentioned during the meeting, there are several issues
that are not covered in the last version of the draft. I
already provided examples of the issues offline as requested
by Martin.

Cheers, Med

-----Message d'origine----- De : sfc
[mailto:sfc-bounc= es@ietf.org] De la part de Thomas Narten
Envoy=C3=A9 : jeudi 31 mars 2016 04:48 =C3=80 :
sfc@ietf.org Objet : = [sfc] WG last call for
draft-ietf-sfc-nsh-04.txt

Dear WG:

This note begins a WG last call on draft-ietf-sfc-nsh-04.txt
(https://datatracker.ietf.org/doc/draft-ietf-sfc= -nsh/).



The editors of the NSH document have indicated that they have
addressed all known comments and that there are no open
issues with the current version of the document.

Substantive comments to the list please, editorial comments
can go directly to the document editors.

We'll also get a brief update from the editors at next
week's meeting. If there are any remaining issues with the
document, raising them before the meeting would be
especially helpful.

For the chairs, Thomas

_______________________________________________ sfc mailing
list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing
list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing
list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing
list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc


_______________________________________________ sfc mailing list
sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________ sfc mailing list
sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc



_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--001a114187be76da1e05317f696d-- From nobody Wed Apr 27 16:10:45 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 F24B712D1E3 for ; Wed, 27 Apr 2016 16:10:43 -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 dQC1ywm71W5D for ; Wed, 27 Apr 2016 16:10:41 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 0FAF312B02B for ; Wed, 27 Apr 2016 16:10:41 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id r5so25072529pag.1 for ; Wed, 27 Apr 2016 16:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBEFAYervPnRIZnu+axHdm+esJplUDTkS2AdtaIOR1U=; b=Kwf4Gr9mCSeoedr4bVEwC8BuStrlSWdfRc4plINmaqnH4Jbb/usSUp4dBHw2zJq73h u+HrDCOwQaW8q6EZ6BGTuWw3wH5nCfIaanIs1fOkZHr5t/ZLc+bMq+nDUCbxoIQmiZx9 0Z54LzBav1eOvIiV5UtWc2LjisXVydN2b8qT9KxnF6J1+f1DENr7ffeT46CmW9DYyJDG 7fgdrZ7TC0fEUgnMC9Ft8ah4CO0Xff3Q7jFqpRLQGgSCfh8wGQC6cyHzps3XlEDLydIV 0ohLtOuqCMb1bZMk7V5WbOt89f46z6hVMtggj2NhE/R+Xc9iSXMrd5XQhMSXgxVhXS/U Y2CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBEFAYervPnRIZnu+axHdm+esJplUDTkS2AdtaIOR1U=; b=HFgVfltgJ4TUXl5lSouVqOZvOUCuy8Sb0urhAwmr4Cw/xik3m808s8feTOXxljb7vf ShFGBX+8mydJYo7b6gBpl9yTS79TU+E6EdrvwjZXe9bX44Oj6gDn3orduxK4YT8SA5nJ zkzU+Qxe6eNyTb1ujZwXFVGLkV+poenz0wHOoeUY7RzK1gJbSHFxSHBkFx4ruSs9bRPq i0XDeN92kI1MB8L+NNyp5w2Adu+rh/FpM1fFUk9NuCFbcceHHEhBIPG81RFx30FX+haA 92YQkssRJjWTRF61FWkq1S+j8Nvn1NDrdgw+PNJHzuQPI+wiA+/2DaguunIu+BfsTXWx SwRg== X-Gm-Message-State: AOPr4FXaL2YvIf18GEf61sDFTLHmFEGY9P2CFzlJDLjWLeF2545OLIZZEJV80mBwySrs6A== X-Received: by 10.66.21.102 with SMTP id u6mr12471947pae.118.1461798640650; Wed, 27 Apr 2016 16:10:40 -0700 (PDT) Received: from ?IPv6:2601:646:8d00:25f0:1d30:818b:fd9f:29bb? ([2601:646:8d00:25f0:1d30:818b:fd9f:29bb]) by smtp.gmail.com with ESMTPSA id 17sm9267721pfp.96.2016.04.27.16.10.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 16:10:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dino Farinacci In-Reply-To: Date: Wed, 27 Apr 2016 16:10:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B6F7441-A67B-4577-A842-6FDCF7D85C13@gmail.com> References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> To: "Andrew G. Malis" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Elzur, Uri" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 23:10:44 -0000 Andy, there is a difference though. RFC6830 says an ITR can fragment but = an ETR does not reassemble. That is, an arrived packet at the ITR causes = the =E2=80=9Cuser=E2=80=99s header=E2=80=9D to be fragmented and then = each fragment is encapsulated. So the fragment reassembly is done at the = destination host. For NSH, I think you want the reassembly to happen at the end of the = SFF. But I=E2=80=99m not sure, so for you all to comment on. Dino > On Apr 27, 2016, at 4:02 PM, Andrew G. Malis = wrote: >=20 > Joel et al, >=20 > All this talk about fragmentation prompted me to re-read section 6 of = the draft, which recommends (as option 3) using the procedures in = section 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80=9D = replacing the =E2=80=9CLISP header=E2=80=9D in the description of the = procedures in that section). >=20 > So that led me to read that section (and the LISP header definition in = section 5.1), and I see that LISP does fragmentation and reassembly = identically to IPv4, using the Fragment Offset field so that fragments = can be correctly reassembled in the proper order. >=20 > However, the NSH Header doesn=E2=80=99t have a Fragment Offset field = or any other way to order the fragments. >=20 > So how can the procedures in Section 5.4 of 6830 be used? >=20 > Thanks, > Andy >=20 > On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern = wrote: > Both methods are valid, and both depend upon details of the underlying = packet and the transport. As such, I don't see why this document = benefits from describing them, much less why it should mark one method = as a "should". Implementation details are likely to be more significant = than any bit consumption difference between the two alternatives. >=20 > Yours, > Joel >=20 >=20 > On 4/27/16 3:40 PM, Linda Dunbar wrote: > I suggest adding the following paragraphs after the Bullet 3 of the = Section 6 Fragmentation Consideration to make the process more clear and = less controversial: >=20 >=20 > -------------------------------- >=20 > RFC6830 describes the fragmentation method of breaking the original = packet into two equal sub-frames and encapsulating [LISP Header + = Transport header] to each sub-frame. >=20 > If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + = Transport Header] will be added to each half frame (or the original data = frame). As the Transport Header is terminated by the next SFF node's = tunnel transport layer, the combined two sub-frames will have two SFC = Headers. >=20 > Therefore, the fragmentation for NSH encapsulated data frame should be = done completely by the node tunnel transport layer, which should break = the [SFC + original packet] into two equal sub-frames and each sub-frame = being encapsulated with its respective tunnel header. The next SFF = node's tunnel transport layer should combine the two sub-frames before = sending to the next node. >=20 > ------------------------------------------------------ >=20 >=20 > By the way, there are to typo in the Section 6: > 3rd line: "In order the" =3D=3D> "In order to" > Last line of Bullet 2: extra "the" in the "utilized to ensure the the = required packet". >=20 >=20 > Hope it helps. >=20 > Linda >=20 >=20 >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, April 27, 2016 12:40 AM > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Joel, all, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : mardi = 26 > avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; = Elzur, > Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > With regard to Transport tunnel fragementation, that seems an issue > for the transport protocol. I don't actually object to a sentence, > but it does not seem that it will accomplish anything. >=20 > [Med] I would like to see some text added to the draft. >=20 >=20 > With regard to packets fragmented by the source, I completely disagree > with your assertion. If an SFF were to reassemble the packets, that > would be a violation of its job. >=20 > [Med] I agree with you. >=20 > There is no reason for an SFF to > reassemble a packet fragmented by the source. The classifier may have > to do some interesting things in order to properly classify succeeding > fragments, but that is an implementation issue (most commonly > addressed with virtual reassembly, which doe snot delay the > fragments.) We don't specity that. >=20 > [Med] Still, the external behavior of the classifier needs to be clear = in the document. I don't find any text in the draft saying for instance = that an NSH header must be present in all fragments. (There some = processing that might be needed at the SFF to "do its job" with regards = to fragments (receive out of order fragments + forwarding policy on the = full packet).) >=20 >=20 > If an SF needs to reassemble fragments to do its job, that is up to > the SF. Some will need to actually reassemble. Some will need to > perform virtual reassembly, and some will happily process the > fragments. I can not see what the NSH document could possibly = mandate. >=20 > [Med] Fully agree. >=20 >=20 > Yours, > Joel >=20 > On 4/26/16 11:47 AM, Linda Dunbar wrote: > Joel, >=20 > I think the document should add the description on the following two > fragmentation scenarios: >=20 > - Transport tunnel generated fragmentation: When a packet > fragmentation is caused by transport tunnel (i.e. various > encapsulations), the termination point of the transport tunnel is > responsible for re-assembling the fragmented pieces of the packet. > Since there won't be any SFF nodes in between the Transport Tunnel, > the tunnel generated fragmentation does not require any actions by > SFF nodes or SF nodes. >=20 >=20 > - Source node generated fragmentation (after adding on the NSH > header): When fragmentation has to be performed for a packet being > encapsulated with the NSH header, either the intermediate SFF nodes > or the SF nodes have to be able to reassemble the fragmented pieces. >=20 >=20 >=20 >=20 > Cheers, >=20 >=20 > Linda >=20 > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; > sfc@ietf.org Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > Re-reading your note, it is possible that you are referring only to > the case of transport generated fragmentation of the outer packet. > I had assumed you were not talking about that, since the resulting > fragments will not all have NSH headers. As with any tunnel > technology, if the tunnel chooses to fragment at its layer, then the > tunnel is responsible for reassembly. That would be invisible to > the SFF. >=20 > Yours, Joel >=20 > On 4/26/16 11:10 AM, Linda Dunbar wrote: > Agree with Med. >=20 > Even if each fragment piece of a packet with NSH header carries the > NSH header, the intermediate SFF nodes still need to put together > all the fragments together before passing the whole data frame to > the SF. >=20 > Linda >=20 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] > On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, > 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: > Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Re-, >=20 > How do you instruct the transport layer to ALWAYS prepend an NSH > header even for fragments? Or you don't care about that? >=20 > Thank you. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Elzur, Uri > [mailto:uri.elzur@intel.com] Envoy=C3=A9 : lundi 25 avril 2016 16:26 = =C3=80 > : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet > : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > Not to repeat my position, but I'll do it anyhow :-) As NSH is > *NOT* a transport, dealing with fragmentation is left to the > Transport used. >=20 > The model I use for NSH, is basically similar to VXLAN . It is an > overly. >=20 > Thx >=20 > Uri ("Oo-Ree") C: 949-378-7568 >=20 >=20 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] > On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, > 2016 7:18 AM To: Joel M. Halpern ; > sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Hi Joel, >=20 > Please see inline. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Joel M. Halpern > [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : lundi 25 avril 2016 15:48 = =C3=80 > : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG > last call for draft-ietf-sfc-nsh-04.txt >=20 > If I am understanding you correctly Med, you are asking that the > NSH draft specify how service chaining should cope with packets > that have been fragmented? >=20 >=20 > [Med] To be accurate, I'm asking to assess whether there are > implications. If there are, then the draft should be updated > accordingly. >=20 > NSH, and the SFF functionality, does not care. >=20 > [Med] I'm not that sure. Some typical implications are listed > below: >=20 > * SFF: If the NSH header is present only in the a fragment but SFF > didn't maintained a state, subsequent fragments won't be > appropriately processed. * SFC-aware function: if prepending a > context information depends on the full packet, not only a > fragment. >=20 > It just does its job. >=20 > [Med] which may be disturbed in some situations as listed in the > examples above. >=20 > Ingress and intermediate classifiers may cope with fragments in > any number of ways. > Specifying such is clearly out of scope for this draft. >=20 > [Med] The purpose is not to specify the internal implementation > details but the external behavior of the classifier function when > it comes to handle fragments. That behavior may have an incidence > on SFF, in particular. The purpose is not to recommend the maximum > resources to be dedicated to out of order fragments nor the > timeout to cache those; these considerations are of course out of > scope. Nevertheless, an implementation should offer a configurable > parameter so that an operator tweak those according to its > context. >=20 > I suppose one could write an informational draft on possible ways > of coping. The IETF has not usually published such. > Service functions have to cope with fragmented packets just as > they had to before the advent of NSH, so describing that is > clearly not needed here. >=20 > [Med] The advent of NSH has the following implications: * it > exacerbates fragmentation. Handing over this issue to the > transport layer may lead to interoperability issues. * the > chaining may not be efficient if fragments are inappropriately > handled. >=20 > Introducing NSH should not degrade the overall service compared to > legacy service deployment schemes. >=20 >=20 > Yours, Joel >=20 > On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > Re-, >=20 > I hear you, but my comment is that we need, as a WG, to decide > what to > put in the draft. FWIW, I'm discussing two fragmentation > issues: >=20 > (1) Fragmentation that is caused by prepending an SFC header. > (2) Handling fragments at the ingress of an SFC-enabled domain. >=20 > Increasing the MTU is for sure a recommendation is to be > explicitly > called out in the text (see my first message). >=20 > There are other issues that need to be discussed, e.g., how to > deal with > fragments in SFFs/Classifiers? >=20 > It is also "prudent" to check that no issues will be experienced > in SFF > to handle fragments. If an SFC header is prepended for all > fragments, I'm not sure there > is any particular issue at the SFF level, except if > stripping/adding > context TLVs depends on the full packet (not just fragment). It > is warranted to consider a little bit this point before declaring > there is no issue. >=20 > For point (1), declaring fragmentation out of scope would be > meant that > an implementation must be prepared to receive fragments with or > without NSH header as this is a decision that is left to the > transport encapsulation. This is a requirement per se! >=20 > I won't reiterate all the comments I have about the current > wording of > this section. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Elzur, Uri > [mailto:uri.elzur@intel.com] Envoy=C3=A9 : lundi 25 avril 2016 > 08:30 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > sfc@ietf.org Objet : RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > My point is that Fragmentation is yet another transport related > issue > that > is beyond the scope of NSH and beyond the charter of the WG, so > it > doesn't > really belong in the draft. We are providing an advice as > extending the size of the packet may lead to fragmentation, but > as you check RFC 7348 VxLAN, which my create the same issue, > you'll find it doesn't even > relate > to it. >=20 > Thx >=20 > Uri ("Oo-Ree") C: 949-378-7568 >=20 >=20 > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 > 10:32 PM To: Elzur, Uri ; Thomas Narten > ; > sfc@ietf.org Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > Hi Uri, >=20 > That's another option that needs to be discussed/investigated. > I'm > afraid > this is not the rationale adopted in -04 since it includes some > text > that > is far to be sufficient to ensure interoperable > implementations. >=20 > BTW, saying that nsh does not need to deal with fragmentation > because > it > is transport-independent is not IMHO a good strategy to adopt > here > because > it opens the door for interoperable issues, it may lead to > sub-optimal implementations if the sfc information is present > only in one > fragments, > etc. >=20 > My comments are related to the current text in the -04. > This text needs > to > be fixed somehow. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Elzur, Uri > [mailto:uri.elzur@intel.com] Envoy=C3=A9 : dimanche 24 avril > 2016 17:36 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > sfc@ietf.org Objet : RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > Hi Med >=20 > I see no need to specify the exact behavior as NSH is > transport independent i.e. like NSH interaction with any other > Transport eh issue of Fragmentation is to be dealt in a way > that matches the mechanisms supported by the Transport used > and do not belong in the NSH draft >=20 > Thx >=20 > Uri ("Oo-Ree") C: 949-378-7568 >=20 >=20 > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com Sent: Thursday, April 14, > 2016 12:43 AM To: Thomas Narten ; > sfc@ietf.org Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > R-, >=20 > In addition to other pending issues raised for this draft, I > would like to raise this additional one about Section 6. >=20 > =3D=3D 6. Fragmentation Considerations >=20 > NSH and the associated transport header are "added" to the > encapsulated packet/frame. This additional information > increases > the > size of the packet. In order the ensure proper forwarding of > NSH data, several options for handling fragmentation and > re-assembly exist: >=20 > 1. Jumbo Frames, when supported, enable the transport of NSH > and associated transport packets without requiring > fragmentation. >=20 > 2. Path MTU Discovery [RFC1191]"describes a technique for > dynamically discovering the maximum transmission unit (MTU) of > an > arbitrary internet path" and can be utilized to ensure the > the > required packet size is used. >=20 > 3. [RFC6830] describes two schemes for fragmentation and > re- > assembly > in section 5.4. =3D=3D >=20 > * The text is weak for a Standard track document that is > intended to solve the problem in > https://tools.ietf.org/html/rfc7498#section- > 2.12. > There should be a clear behavior to be followed by an > implementation. > Further, I would avoid the use of words such as "can". >=20 > * The text covers only fragmentation when it is induced by SFC > operations, it does not discuss the treatment of a fragment > when received in an SFC domain. IMHO, the draft should also > specify the behavior of the Classifier with regards to > fragments for the sake of proper SFC operation. Applying > classification policies may require the > full packet, not only a fragment. > In particular, dedicated resources should dedicated for > handling out of order fragments. Of course, it is out of scope > of this document to describe how SFs handle fragments. >=20 > * If an SFC header is prepended for all fragments, I'm not > sure there is any particular issue at the SFF level...except > if stripping/adding context TLVs depends on the full packet > (not just fragment). It is warranted to consider a little bit > this point before declaring there > is > no issue. >=20 > * The text states "several options". This may be interpreted > as if implementing one of them is sufficient...which is not > true. The first two points contribute to minimize the > fragmentation risk, but fragmentation may still be experienced > (e.g., other shims are prepended by other nodes for some other > purposes, nested nsh, etc.) >=20 > * The first two points have nothing to do with reassembly. >=20 > * The support of jumbo frames by a router/device does not mean > that it can make use of it. Appropriate MTU configuration > should be undertaken in a consistent manner within an SFC > domain. The text should be updated to make it is about > (consistent) MTU > configuration. >=20 > * BTW, shouldn't the text be reworded to recommended to > increase the MTU of **all nodes** of an SFC-enabled domain by > at least the length of SFC header + transport header? >=20 > * Bullet 2, how PMTU discovery is actually used in this > context? Do you assume that all SFC-aware nodes will issue > such messages towards other SFC-aware node, arbitrary > destination, else? >=20 > * Bullet 2, I would drop "describes a technique for > dynamically discovering the maximum transmission unit > (MTU) of an arbitrary internet path". >=20 > * Bullet 2, s/ the the/the. >=20 > * The reference to the LISP specification raises two concerns > and one comment: >=20 > (1) I don't think it is a good approach that fragments induced > by the network are passed to their ultimate destinations as > such > (stateless). > IMO, reassembly should be done within the SFC domain > (responsible for fragmentation) not passed away. (2) Does the > stateful mode require all SFC data plane elements maintain a > full list of MTU for the any SFF/SF instance of the SFC > domain? >=20 > The current text suggests that [RFC6830] should be listed as > normative reference (not an informative one). I would > personally favor removing the reference to LISP (as it is an > Experimental RFC). >=20 > * The security section of the draft may be augmented with > informational fragmentation-related pointers to: > e.g., RFC1858 (Security Considerations for IP Fragment > Filtering), RFC3128 (Protection Against a Variant of the Tiny > Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High > Data Rates). >=20 > Cheers, Med >=20 > -----Message d'origine----- De : sfc > [mailto:sfc-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com Envoy=C3=A9 : lundi 11 avril > 2016 13:14 =C3=80 : Thomas Narten; sfc@ietf.org Objet : Re: > [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Dear Thomas, all, >=20 > As I mentioned during the meeting, there are several issues > that are not covered in the last version of the draft. I > already provided examples of the issues offline as requested > by Martin. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : sfc > [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten > Envoy=C3=A9 : jeudi 31 mars 2016 04:48 =C3=80 : > sfc@ietf.org Objet : [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt >=20 > Dear WG: >=20 > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >=20 >=20 >=20 > The editors of the NSH document have indicated that they have > addressed all known comments and that there are no open > issues with the current version of the document. >=20 > Substantive comments to the list please, editorial comments > can go directly to the document editors. >=20 > We'll also get a brief update from the editors at next > week's meeting. If there are any remaining issues with the > document, raising them before the meeting would be > especially helpful. >=20 > For the chairs, Thomas >=20 > _______________________________________________ sfc mailing > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ sfc mailing > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ sfc mailing > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ sfc mailing > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ sfc mailing list > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 >=20 > _______________________________________________ sfc mailing list > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ sfc mailing list > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Apr 27 16:16:59 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 5A2CC12D0F1 for ; Wed, 27 Apr 2016 16:16:56 -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 J6jAqTtR3uGL for ; Wed, 27 Apr 2016 16:16:52 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAD712B020 for ; Wed, 27 Apr 2016 16:16:52 -0700 (PDT) Received: by mail-ob0-x22f.google.com with SMTP id x1so11359942obt.0 for ; Wed, 27 Apr 2016 16:16:52 -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=Oc8YgbbVw6Ef//4EdOXOxTz6CLzMPjG/Ruew2wvM3HE=; b=faCMT8Yvt6GfRN1aC4YMva7AmE3/8XG3P25vKLAnX4dtv4z2AHgDG1+SFQRysHrY0N bcOpDsmIqi6mbUk0G7rOPpxGUEn7aHFeMmohrBE+Bzf1zr7TqKqItSs+v2SKfwgKmaEV bspR8K8XaT5RgND+ue5nkdyg57kaAR/WhyS7OL4JtTS9l25Mao57pU9ve8P4D+IOU7He WIKggnlD00VfsQbDCRv0kWKuS88kCZrO+1IG0LqPyN7JK44a0CTJKEJNfB59pJ5m/Xay VGhlpmii+yfHom29z8GO+7rwkkc4UFnVG/CSkd+dRV/MqSMPbgtnwVDQAZ738IV3o6Y1 CobA== 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=Oc8YgbbVw6Ef//4EdOXOxTz6CLzMPjG/Ruew2wvM3HE=; b=KoSMT2/RG9MI3ZWz5GLColrStEfIDGcAXFqqGlgGf60YnLYilw+9ywmjMYswZKrbti ncNlC1iqPtS91noYLcklZ32w+TQFgtG7UcKoNZPngGCI3OEwE+oGaTdLYM0LyLPBj7uu zQKr8j8ZXkRjneOUwgY80FNzgwLTZ7K+4iUnRx9coLskMmYvplDlBQ4d5lt8wqPfSH/w eumvqWPWY8U71wIkTOJZE2MoaWiMk1ZkUENMR4kA1AnsJC+sSxs8UGPyLfhag6nG9k+m dQVNAaqGNyC3NHaEmSUVvdeZRnSwCUVKdJ0zYwAtMF6SR8virx4KxO7T471UsHjmeBlE NoiA== X-Gm-Message-State: AOPr4FUun8rS0tEsDuH8peEzAOP5xInFIi2IaLHKbYKqikl+u/FgXzK/geXqe/hxTmGvONnF6ogB6oC3S+qaAQ== X-Received: by 10.60.173.210 with SMTP id bm18mr4937984oec.30.1461799011433; Wed, 27 Apr 2016 16:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Wed, 27 Apr 2016 16:16:31 -0700 (PDT) In-Reply-To: <3B6F7441-A67B-4577-A842-6FDCF7D85C13@gmail.com> References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <3B6F7441-A67B-4577-A842-6FDCF7D85C13@gmail.com> From: "Andrew G. Malis" Date: Wed, 27 Apr 2016 19:16:31 -0400 Message-ID: To: Dino Farinacci Content-Type: multipart/alternative; boundary=089e011826a4cf44c805317f9aab Archived-At: Cc: "Elzur, Uri" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 23:16:56 -0000 --089e011826a4cf44c805317f9aab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey, Dino! Regardless of where the reassembly is done, it needs to be done correctly. I=E2=80=99m just wondering how that can happen without the necessary header= fields. Cheers, Andy On Wed, Apr 27, 2016 at 7:10 PM, Dino Farinacci wrote= : > Andy, there is a difference though. RFC6830 says an ITR can fragment but > an ETR does not reassemble. That is, an arrived packet at the ITR causes > the =E2=80=9Cuser=E2=80=99s header=E2=80=9D to be fragmented and then eac= h fragment is > encapsulated. So the fragment reassembly is done at the destination host. > > For NSH, I think you want the reassembly to happen at the end of the SFF. > But I=E2=80=99m not sure, so for you all to comment on. > > Dino > > > On Apr 27, 2016, at 4:02 PM, Andrew G. Malis wrote: > > > > Joel et al, > > > > All this talk about fragmentation prompted me to re-read section 6 of > the draft, which recommends (as option 3) using the procedures in section > 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80=9D replaci= ng the =E2=80=9CLISP > header=E2=80=9D in the description of the procedures in that section). > > > > So that led me to read that section (and the LISP header definition in > section 5.1), and I see that LISP does fragmentation and reassembly > identically to IPv4, using the Fragment Offset field so that fragments ca= n > be correctly reassembled in the proper order. > > > > However, the NSH Header doesn=E2=80=99t have a Fragment Offset field or= any > other way to order the fragments. > > > > So how can the procedures in Section 5.4 of 6830 be used? > > > > Thanks, > > Andy > > > > On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern > wrote: > > Both methods are valid, and both depend upon details of the underlying > packet and the transport. As such, I don't see why this document benefit= s > from describing them, much less why it should mark one method as a > "should". Implementation details are likely to be more significant than > any bit consumption difference between the two alternatives. > > > > Yours, > > Joel > > > > > > On 4/27/16 3:40 PM, Linda Dunbar wrote: > > I suggest adding the following paragraphs after the Bullet 3 of the > Section 6 Fragmentation Consideration to make the process more clear and > less controversial: > > > > > > -------------------------------- > > > > RFC6830 describes the fragmentation method of breaking the original > packet into two equal sub-frames and encapsulating [LISP Header + Transpo= rt > header] to each sub-frame. > > > > If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + > Transport Header] will be added to each half frame (or the original data > frame). As the Transport Header is terminated by the next SFF node's tunn= el > transport layer, the combined two sub-frames will have two SFC Headers. > > > > Therefore, the fragmentation for NSH encapsulated data frame should be > done completely by the node tunnel transport layer, which should break th= e > [SFC + original packet] into two equal sub-frames and each sub-frame bein= g > encapsulated with its respective tunnel header. The next SFF node's tunn= el > transport layer should combine the two sub-frames before sending to the > next node. > > > > ------------------------------------------------------ > > > > > > By the way, there are to typo in the Section 6: > > 3rd line: "In order the" =3D=3D> "In order to" > > Last line of Bullet 2: extra "the" in the "utilized to ensure the the > required packet". > > > > > > Hope it helps. > > > > Linda > > > > > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com= ] > > Sent: Wednesday, April 27, 2016 12:40 AM > > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Hi Joel, all, > > > > Please see inline. > > > > Cheers, > > Med > > > > -----Message d'origine----- > > De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : mardi 2= 6 > > avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzu= r, > > Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > With regard to Transport tunnel fragementation, that seems an issue > > for the transport protocol. I don't actually object to a sentence, > > but it does not seem that it will accomplish anything. > > > > [Med] I would like to see some text added to the draft. > > > > > > With regard to packets fragmented by the source, I completely disagree > > with your assertion. If an SFF were to reassemble the packets, that > > would be a violation of its job. > > > > [Med] I agree with you. > > > > There is no reason for an SFF to > > reassemble a packet fragmented by the source. The classifier may have > > to do some interesting things in order to properly classify succeeding > > fragments, but that is an implementation issue (most commonly > > addressed with virtual reassembly, which doe snot delay the > > fragments.) We don't specity that. > > > > [Med] Still, the external behavior of the classifier needs to be clear > in the document. I don't find any text in the draft saying for instance > that an NSH header must be present in all fragments. (There some processi= ng > that might be needed at the SFF to "do its job" with regards to fragments > (receive out of order fragments + forwarding policy on the full packet).) > > > > > > If an SF needs to reassemble fragments to do its job, that is up to > > the SF. Some will need to actually reassemble. Some will need to > > perform virtual reassembly, and some will happily process the > > fragments. I can not see what the NSH document could possibly mandate. > > > > [Med] Fully agree. > > > > > > Yours, > > Joel > > > > On 4/26/16 11:47 AM, Linda Dunbar wrote: > > Joel, > > > > I think the document should add the description on the following two > > fragmentation scenarios: > > > > - Transport tunnel generated fragmentation: When a packet > > fragmentation is caused by transport tunnel (i.e. various > > encapsulations), the termination point of the transport tunnel is > > responsible for re-assembling the fragmented pieces of the packet. > > Since there won't be any SFF nodes in between the Transport Tunnel, > > the tunnel generated fragmentation does not require any actions by > > SFF nodes or SF nodes. > > > > > > - Source node generated fragmentation (after adding on the NSH > > header): When fragmentation has to be performed for a packet being > > encapsulated with the NSH header, either the intermediate SFF nodes > > or the SF nodes have to be able to reassemble the fragmented pieces. > > > > > > > > > > Cheers, > > > > > > Linda > > > > -----Original Message----- From: Joel M. Halpern > > [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 AM > > To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; > > sfc@ietf.org Subject: Re: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Re-reading your note, it is possible that you are referring only to > > the case of transport generated fragmentation of the outer packet. > > I had assumed you were not talking about that, since the resulting > > fragments will not all have NSH headers. As with any tunnel > > technology, if the tunnel chooses to fragment at its layer, then the > > tunnel is responsible for reassembly. That would be invisible to > > the SFF. > > > > Yours, Joel > > > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > > Agree with Med. > > > > Even if each fragment piece of a packet with NSH header carries the > > NSH header, the intermediate SFF nodes still need to put together > > all the fragments together before passing the whole data frame to > > the SF. > > > > Linda > > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] > > On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, > > 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: > > Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Re-, > > > > How do you instruct the transport layer to ALWAYS prepend an NSH > > header even for fragments? Or you don't care about that? > > > > Thank you. > > > > Cheers, Med > > > > -----Message d'origine----- De : Elzur, Uri > > [mailto:uri.elzur@intel.com] Envoy=C3=A9 : lundi 25 avril 2016 16:26 = =C3=80 > > : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet > > : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Hi Med > > > > Not to repeat my position, but I'll do it anyhow :-) As NSH is > > *NOT* a transport, dealing with fragmentation is left to the > > Transport used. > > > > The model I use for NSH, is basically similar to VXLAN . It is an > > overly. > > > > Thx > > > > Uri ("Oo-Ree") C: 949-378-7568 > > > > > > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] > > On Behalf Of mohamed.boucadair@orange.com Sent: Monday, April 25, > > 2016 7:18 AM To: Joel M. Halpern ; > > sfc@ietf.org > > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Hi Joel, > > > > Please see inline. > > > > Cheers, Med > > > > -----Message d'origine----- De : Joel M. Halpern > > [mailto:jmh@joelhalpern.com] Envoy=C3=A9 : lundi 25 avril 2016 15:48 = =C3=80 > > : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : Re: [sfc] WG > > last call for draft-ietf-sfc-nsh-04.txt > > > > If I am understanding you correctly Med, you are asking that the > > NSH draft specify how service chaining should cope with packets > > that have been fragmented? > > > > > > [Med] To be accurate, I'm asking to assess whether there are > > implications. If there are, then the draft should be updated > > accordingly. > > > > NSH, and the SFF functionality, does not care. > > > > [Med] I'm not that sure. Some typical implications are listed > > below: > > > > * SFF: If the NSH header is present only in the a fragment but SFF > > didn't maintained a state, subsequent fragments won't be > > appropriately processed. * SFC-aware function: if prepending a > > context information depends on the full packet, not only a > > fragment. > > > > It just does its job. > > > > [Med] which may be disturbed in some situations as listed in the > > examples above. > > > > Ingress and intermediate classifiers may cope with fragments in > > any number of ways. > > Specifying such is clearly out of scope for this draft. > > > > [Med] The purpose is not to specify the internal implementation > > details but the external behavior of the classifier function when > > it comes to handle fragments. That behavior may have an incidence > > on SFF, in particular. The purpose is not to recommend the maximum > > resources to be dedicated to out of order fragments nor the > > timeout to cache those; these considerations are of course out of > > scope. Nevertheless, an implementation should offer a configurable > > parameter so that an operator tweak those according to its > > context. > > > > I suppose one could write an informational draft on possible ways > > of coping. The IETF has not usually published such. > > Service functions have to cope with fragmented packets just as > > they had to before the advent of NSH, so describing that is > > clearly not needed here. > > > > [Med] The advent of NSH has the following implications: * it > > exacerbates fragmentation. Handing over this issue to the > > transport layer may lead to interoperability issues. * the > > chaining may not be efficient if fragments are inappropriately > > handled. > > > > Introducing NSH should not degrade the overall service compared to > > legacy service deployment schemes. > > > > > > Yours, Joel > > > > On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > I hear you, but my comment is that we need, as a WG, to decide > > what to > > put in the draft. FWIW, I'm discussing two fragmentation > > issues: > > > > (1) Fragmentation that is caused by prepending an SFC header. > > (2) Handling fragments at the ingress of an SFC-enabled domain. > > > > Increasing the MTU is for sure a recommendation is to be > > explicitly > > called out in the text (see my first message). > > > > There are other issues that need to be discussed, e.g., how to > > deal with > > fragments in SFFs/Classifiers? > > > > It is also "prudent" to check that no issues will be experienced > > in SFF > > to handle fragments. If an SFC header is prepended for all > > fragments, I'm not sure there > > is any particular issue at the SFF level, except if > > stripping/adding > > context TLVs depends on the full packet (not just fragment). It > > is warranted to consider a little bit this point before declaring > > there is no issue. > > > > For point (1), declaring fragmentation out of scope would be > > meant that > > an implementation must be prepared to receive fragments with or > > without NSH header as this is a decision that is left to the > > transport encapsulation. This is a requirement per se! > > > > I won't reiterate all the comments I have about the current > > wording of > > this section. > > > > Cheers, Med > > > > -----Message d'origine----- De : Elzur, Uri > > [mailto:uri.elzur@intel.com] Envoy=C3=A9 : lundi 25 avril 2016 > > 08:30 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > > sfc@ietf.org Objet : RE: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Hi Med > > > > My point is that Fragmentation is yet another transport related > > issue > > that > > is beyond the scope of NSH and beyond the charter of the WG, so > > it > > doesn't > > really belong in the draft. We are providing an advice as > > extending the size of the packet may lead to fragmentation, but > > as you check RFC 7348 VxLAN, which my create the same issue, > > you'll find it doesn't even > > relate > > to it. > > > > Thx > > > > Uri ("Oo-Ree") C: 949-378-7568 > > > > > > -----Original Message----- From: sfc > > [mailto:sfc-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com Sent: Sunday, April 24, 2016 > > 10:32 PM To: Elzur, Uri ; Thomas Narten > > ; > > sfc@ietf.org Subject: Re: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Hi Uri, > > > > That's another option that needs to be discussed/investigated. > > I'm > > afraid > > this is not the rationale adopted in -04 since it includes some > > text > > that > > is far to be sufficient to ensure interoperable > > implementations. > > > > BTW, saying that nsh does not need to deal with fragmentation > > because > > it > > is transport-independent is not IMHO a good strategy to adopt > > here > > because > > it opens the door for interoperable issues, it may lead to > > sub-optimal implementations if the sfc information is present > > only in one > > fragments, > > etc. > > > > My comments are related to the current text in the -04. > > This text needs > > to > > be fixed somehow. > > > > Cheers, Med > > > > -----Message d'origine----- De : Elzur, Uri > > [mailto:uri.elzur@intel.com] Envoy=C3=A9 : dimanche 24 avril > > 2016 17:36 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; > > sfc@ietf.org Objet : RE: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Hi Med > > > > I see no need to specify the exact behavior as NSH is > > transport independent i.e. like NSH interaction with any other > > Transport eh issue of Fragmentation is to be dealt in a way > > that matches the mechanisms supported by the Transport used > > and do not belong in the NSH draft > > > > Thx > > > > Uri ("Oo-Ree") C: 949-378-7568 > > > > > > -----Original Message----- From: sfc > > [mailto:sfc-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com Sent: Thursday, April 14, > > 2016 12:43 AM To: Thomas Narten ; > > sfc@ietf.org Subject: Re: [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > R-, > > > > In addition to other pending issues raised for this draft, I > > would like to raise this additional one about Section 6. > > > > =3D=3D 6. Fragmentation Considerations > > > > NSH and the associated transport header are "added" to the > > encapsulated packet/frame. This additional information > > increases > > the > > size of the packet. In order the ensure proper forwarding of > > NSH data, several options for handling fragmentation and > > re-assembly exist: > > > > 1. Jumbo Frames, when supported, enable the transport of NSH > > and associated transport packets without requiring > > fragmentation. > > > > 2. Path MTU Discovery [RFC1191]"describes a technique for > > dynamically discovering the maximum transmission unit (MTU) of > > an > > arbitrary internet path" and can be utilized to ensure the > > the > > required packet size is used. > > > > 3. [RFC6830] describes two schemes for fragmentation and > > re- > > assembly > > in section 5.4. =3D=3D > > > > * The text is weak for a Standard track document that is > > intended to solve the problem in > > https://tools.ietf.org/html/rfc7498#section- > > 2.12. > > There should be a clear behavior to be followed by an > > implementation. > > Further, I would avoid the use of words such as "can". > > > > * The text covers only fragmentation when it is induced by SFC > > operations, it does not discuss the treatment of a fragment > > when received in an SFC domain. IMHO, the draft should also > > specify the behavior of the Classifier with regards to > > fragments for the sake of proper SFC operation. Applying > > classification policies may require the > > full packet, not only a fragment. > > In particular, dedicated resources should dedicated for > > handling out of order fragments. Of course, it is out of scope > > of this document to describe how SFs handle fragments. > > > > * If an SFC header is prepended for all fragments, I'm not > > sure there is any particular issue at the SFF level...except > > if stripping/adding context TLVs depends on the full packet > > (not just fragment). It is warranted to consider a little bit > > this point before declaring there > > is > > no issue. > > > > * The text states "several options". This may be interpreted > > as if implementing one of them is sufficient...which is not > > true. The first two points contribute to minimize the > > fragmentation risk, but fragmentation may still be experienced > > (e.g., other shims are prepended by other nodes for some other > > purposes, nested nsh, etc.) > > > > * The first two points have nothing to do with reassembly. > > > > * The support of jumbo frames by a router/device does not mean > > that it can make use of it. Appropriate MTU configuration > > should be undertaken in a consistent manner within an SFC > > domain. The text should be updated to make it is about > > (consistent) MTU > > configuration. > > > > * BTW, shouldn't the text be reworded to recommended to > > increase the MTU of **all nodes** of an SFC-enabled domain by > > at least the length of SFC header + transport header? > > > > * Bullet 2, how PMTU discovery is actually used in this > > context? Do you assume that all SFC-aware nodes will issue > > such messages towards other SFC-aware node, arbitrary > > destination, else? > > > > * Bullet 2, I would drop "describes a technique for > > dynamically discovering the maximum transmission unit > > (MTU) of an arbitrary internet path". > > > > * Bullet 2, s/ the the/the. > > > > * The reference to the LISP specification raises two concerns > > and one comment: > > > > (1) I don't think it is a good approach that fragments induced > > by the network are passed to their ultimate destinations as > > such > > (stateless). > > IMO, reassembly should be done within the SFC domain > > (responsible for fragmentation) not passed away. (2) Does the > > stateful mode require all SFC data plane elements maintain a > > full list of MTU for the any SFF/SF instance of the SFC > > domain? > > > > The current text suggests that [RFC6830] should be listed as > > normative reference (not an informative one). I would > > personally favor removing the reference to LISP (as it is an > > Experimental RFC). > > > > * The security section of the draft may be augmented with > > informational fragmentation-related pointers to: > > e.g., RFC1858 (Security Considerations for IP Fragment > > Filtering), RFC3128 (Protection Against a Variant of the Tiny > > Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High > > Data Rates). > > > > Cheers, Med > > > > -----Message d'origine----- De : sfc > > [mailto:sfc-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com Envoy=C3=A9 : lundi 11 avril > > 2016 13:14 =C3=80 : Thomas Narten; sfc@ietf.org Objet : Re: > > [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > > > Dear Thomas, all, > > > > As I mentioned during the meeting, there are several issues > > that are not covered in the last version of the draft. I > > already provided examples of the issues offline as requested > > by Martin. > > > > Cheers, Med > > > > -----Message d'origine----- De : sfc > > [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten > > Envoy=C3=A9 : jeudi 31 mars 2016 04:48 =C3=80 : > > sfc@ietf.org Objet : [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > > > Dear WG: > > > > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > > > > > The editors of the NSH document have indicated that they have > > addressed all known comments and that there are no open > > issues with the current version of the document. > > > > Substantive comments to the list please, editorial comments > > can go directly to the document editors. > > > > We'll also get a brief update from the editors at next > > week's meeting. If there are any remaining issues with the > > document, raising them before the meeting would be > > especially helpful. > > > > For the chairs, Thomas > > > > _______________________________________________ sfc mailing > > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ sfc mailing > > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ sfc mailing > > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ sfc mailing > > list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ sfc mailing list > > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ sfc mailing list > > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ sfc mailing list > > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > --089e011826a4cf44c805317f9aab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey, Dino!

Regardless of where the reas= sembly is done, it needs to be done correctly. I=E2=80=99m just wondering h= ow that can happen without the necessary header fields.

Cheers,
Andy

On Wed, Apr 27, 2016 at 7:10 PM, Dino Farinacci <= farinacci@gmail.com> wrote:
Andy, there is a difference though. RFC6830 says an ITR can fragment but a= n ETR does not reassemble. That is, an arrived packet at the ITR causes the= =E2=80=9Cuser=E2=80=99s header=E2=80=9D to be fragmented and then each fra= gment is encapsulated. So the fragment reassembly is done at the destinatio= n host.

For NSH, I think you want the reassembly to happen at the end of the SFF. B= ut I=E2=80=99m not sure, so for you all to comment on.

Dino

> On Apr 27, 2016, at 4:02 PM, Andrew G. Malis <agmalis@gmail.com> wrote:
>
> Joel et al,
>
> All this talk about fragmentation prompted me to re-read section 6 of = the draft, which recommends (as option 3) using the procedures in section 5= .4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80=9D replacing = the =E2=80=9CLISP header=E2=80=9D in the description of the procedures in t= hat section).
>
> So that led me to read that section (and the LISP header definition in= section 5.1), and I see that LISP does fragmentation and reassembly identi= cally to IPv4, using the Fragment Offset field so that fragments can be cor= rectly reassembled in the proper order.
>
> However, the NSH Header doesn=E2=80=99t have a Fragment Offset field o= r any other way to order the fragments.
>
> So how can the procedures in Section 5.4 of 6830 be used?
>
> Thanks,
> Andy
>
> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> Both methods are valid, and both depend upon details of the underlying= packet and the transport.=C2=A0 As such, I don't see why this document= benefits from describing them, much less why it should mark one method as = a "should".=C2=A0 Implementation details are likely to be more si= gnificant than any bit consumption difference between the two alternatives.=
>
> Yours,
> Joel
>
>
> On 4/27/16 3:40 PM, Linda Dunbar wrote:
> I suggest adding the following paragraphs after the Bullet 3 of the Se= ction 6 Fragmentation Consideration to make the process more clear and less= controversial:
>
>
> --------------------------------
>
> RFC6830 describes the fragmentation method of breaking the original pa= cket into two equal sub-frames and encapsulating [LISP Header + Transport h= eader] to each sub-frame.
>
> If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header += Transport Header] will be added to each half frame (or the original data f= rame). As the Transport Header is terminated by the next SFF node's tun= nel transport layer, the combined two sub-frames will have two SFC Headers.=
>
> Therefore, the fragmentation for NSH encapsulated data frame should be= done completely by the node tunnel transport layer, which should break the= [SFC + original packet] into two equal sub-frames and each sub-frame being= encapsulated with its respective tunnel header.=C2=A0 The next SFF node= 9;s tunnel transport layer should combine the two sub-frames before sending= to the next node.
>
> ------------------------------------------------------
>
>
> By the way, there are to typo in the Section 6:
> 3rd line: "In order the" =3D=3D> "In order to"<= br> > Last line of Bullet 2: extra "the" in the "utilized to = ensure the the required packet".
>
>
> Hope it helps.
>
> Linda
>
>
>
> -----Original Message-----
> From: mohamed.boucadai= r@orange.com [mailto:mo= hamed.boucadair@orange.com]
> Sent: Wednesday, April 27, 2016 12:40 AM
> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org
> Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>
> Hi Joel, all,
>
> Please see inline.
>
> Cheers,
> Med
>
> -----Message d'origine-----
> De : Joel M. Halpern [mailto:jm= h@joelhalpern.com] Envoy=C3=A9 : mardi 26
> avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elz= ur,
> Uri; sfc@ietf.org Objet : Re: [sfc= ] WG last call for
> draft-ietf-sfc-nsh-04.txt
>
> With regard to Transport tunnel fragementation, that seems an issue > for the transport protocol.=C2=A0 I don't actually object to a sen= tence,
> but it does not seem that it will accomplish anything.
>
> [Med] I would like to see some text added to the draft.
>
>
> With regard to packets fragmented by the source, I completely disagree=
> with your assertion.=C2=A0 If an SFF were to reassemble the packets, t= hat
> would be a violation of its job.
>
> [Med] I agree with you.
>
>=C2=A0 =C2=A0There is no reason for an SFF to
> reassemble a packet fragmented by the source.=C2=A0 The classifier may= have
> to do some interesting things in order to properly classify succeeding=
> fragments, but that is an implementation issue (most commonly
> addressed with virtual reassembly, which doe snot delay the
> fragments.)=C2=A0 We don't specity that.
>
> [Med] Still, the external behavior of the classifier needs to be clear= in the document. I don't find any text in the draft saying for instanc= e that an NSH header must be present in all fragments. (There some processi= ng that might be needed at the SFF to "do its job" with regards t= o fragments (receive out of order fragments + forwarding policy on the full= packet).)
>
>
> If an SF needs to reassemble fragments to do its job, that is up to > the SF.=C2=A0 Some will need to actually reassemble.=C2=A0 Some will n= eed to
> perform virtual reassembly, and some will happily process the
> fragments.=C2=A0 I can not see what the NSH document could possibly ma= ndate.
>
> [Med] Fully agree.
>
>
> Yours,
> Joel
>
> On 4/26/16 11:47 AM, Linda Dunbar wrote:
> Joel,
>
> I think the document should add the description on the following two > fragmentation scenarios:
>
> - Transport tunnel generated fragmentation: When a packet
> fragmentation is caused by transport tunnel (i.e. various
> encapsulations), the termination point of the transport tunnel is
> responsible for re-assembling the fragmented pieces of the packet.
> Since there won't be any SFF nodes in between the Transport Tunnel= ,
> the tunnel generated fragmentation does not require any actions by
> SFF nodes or SF nodes.
>
>
> - Source node generated fragmentation (after adding on the NSH
> header): When fragmentation has to be performed for a packet being
> encapsulated with the NSH header, either the intermediate SFF nodes > or the SF nodes have to be able to reassemble the fragmented pieces. >
>
>
>
> Cheers,
>
>
> Linda
>
> -----Original Message----- From: Joel M. Halpern
> [mailto:jmh@joelhalpern.com= ] Sent: Tuesday, April 26, 2016 10:33 AM
> To: Linda Dunbar; moha= med.boucadair@orange.com; Elzur, Uri;
> sfc@ietf.org Subject: Re: [sfc] WG= last call for
> draft-ietf-sfc-nsh-04.txt
>
> Re-reading your note, it is possible that you are referring only to > the case of transport generated fragmentation of the outer packet.
> I had assumed you were not talking about that, since the resulting
> fragments will not all have NSH headers.=C2=A0 As with any tunnel
> technology, if the tunnel chooses to fragment at its layer, then the > tunnel is responsible for reassembly.=C2=A0 That would be invisible to=
> the SFF.
>
> Yours, Joel
>
> On 4/26/16 11:10 AM, Linda Dunbar wrote:
> Agree with Med.
>
> Even if each fragment piece of a packet with NSH header carries the > NSH header, the intermediate SFF nodes still need to put together
> all the fragments together before passing the whole data frame to
> the SF.
>
> Linda
>
> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
> On Behalf Of mohamed.b= oucadair@orange.com Sent: Monday, April 25,
> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject:
> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>
> Re-,
>
> How do you instruct the transport layer to ALWAYS prepend an NSH
> header even for fragments? Or you don't care about that?
>
> Thank you.
>
> Cheers, Med
>
> -----Message d'origine----- De : Elzur, Uri
> [mailto:uri.elzur@intel.com= ] Envoy=C3=A9 : lundi 25 avril 2016 16:26 =C3=80
> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org Objet
> : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>
> Hi Med
>
> Not to repeat my position, but I'll do it anyhow :-) As NSH is
> *NOT* a transport, dealing with fragmentation is left to the
> Transport used.
>
> The model I use for NSH, is basically similar to VXLAN . It is an
> overly.
>
> Thx
>
> Uri ("Oo-Ree") C: 949-378-7568
>
>
> -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org]
> On Behalf Of mohamed.b= oucadair@orange.com Sent: Monday, April 25,
> 2016 7:18 AM To: Joel M. Halpern <jmh@joelhalpern.com>;
> sfc@ietf.org
> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>
> Hi Joel,
>
> Please see inline.
>
> Cheers, Med
>
> -----Message d'origine----- De : Joel M. Halpern
> [mailto:jmh@joelhalpern.com= ] Envoy=C3=A9 : lundi 25 avril 2016 15:48 =C3=80
> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.= org Objet : Re: [sfc] WG
> last call for draft-ietf-sfc-nsh-04.txt
>
> If I am understanding you correctly Med, you are asking that the
> NSH draft specify how service chaining should cope with packets
> that have been fragmented?
>
>
> [Med] To be accurate, I'm asking to assess whether there are
> implications. If there are, then the draft should be updated
> accordingly.
>
> NSH, and the SFF functionality, does not care.
>
> [Med] I'm not that sure. Some typical implications are listed
> below:
>
> * SFF: If the NSH header is present only in the a fragment but SFF
> didn't maintained a state, subsequent fragments won't be
> appropriately processed. * SFC-aware function: if prepending a
> context information depends on the full packet, not only a
> fragment.
>
> It just does its job.
>
> [Med] which may be disturbed in some situations as listed in the
> examples above.
>
> Ingress and intermediate classifiers may cope with fragments in
> any number of ways.
> Specifying such is clearly out of scope for this draft.
>
> [Med] The purpose is not to specify the internal implementation
> details but the external behavior of the classifier function when
> it comes to handle fragments. That behavior may have an incidence
> on SFF, in particular. The purpose is not to recommend the maximum
> resources to be dedicated to out of order fragments nor the
> timeout to cache those; these considerations are of course out of
> scope. Nevertheless, an implementation should offer a configurable
> parameter so that an operator tweak those according to its
> context.
>
> I suppose one could write an informational draft on possible ways
> of coping.=C2=A0 The IETF has not usually published such.
> Service functions have to cope with fragmented packets just as
> they had to before the advent of NSH, so describing that is
> clearly not needed here.
>
> [Med] The advent of NSH has the following implications: * it
> exacerbates fragmentation. Handing over this issue to the
> transport layer may lead to interoperability issues. * the
> chaining may not be efficient if fragments are inappropriately
> handled.
>
> Introducing NSH should not degrade the overall service compared to
> legacy service deployment schemes.
>
>
> Yours, Joel
>
> On 4/25/16 3:00 AM, mo= hamed.boucadair@orange.com wrote:
> Re-,
>
> I hear you, but my comment is that we need, as a WG, to decide
> what to
> put in the draft. FWIW, I'm discussing two fragmentation
> issues:
>
> (1) Fragmentation that is caused by prepending an SFC header.
> (2) Handling fragments at the ingress of an SFC-enabled domain.
>
> Increasing the MTU is for sure a recommendation is to be
> explicitly
> called out in the text (see my first message).
>
> There are other issues that need to be discussed, e.g., how to
> deal with
> fragments in SFFs/Classifiers?
>
> It is also "prudent" to check that no issues will be experie= nced
> in SFF
> to handle fragments. If an SFC header is prepended for all
> fragments, I'm not sure there
> is any particular issue at the SFF level, except if
> stripping/adding
> context TLVs depends on the full packet (not just fragment). It
> is warranted to consider a little bit this point before declaring
> there is no issue.
>
> For point (1), declaring fragmentation out of scope would be
> meant that
> an implementation must be prepared to receive fragments with or
> without NSH header as this is a decision that is left to the
> transport encapsulation. This is a requirement per se!
>
> I won't reiterate all the comments I have about the current
> wording of
> this section.
>
> Cheers, Med
>
> -----Message d'origine----- De : Elzur, Uri
> [mailto:uri.elzur@intel.com= ] Envoy=C3=A9 : lundi 25 avril 2016
> 08:30 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;
> sfc@ietf.org Objet : RE: [sfc] WG = last call for
> draft-ietf-sfc-nsh-04.txt
>
> Hi Med
>
> My point is that Fragmentation is yet another transport related
> issue
> that
> is beyond the scope of NSH and beyond the charter of the WG, so
> it
> doesn't
> really belong in the draft. We are providing an advice as
> extending the size of the packet may lead to fragmentation, but
> as you check RFC 7348 VxLAN, which my create the same issue,
> you'll find it doesn't even
> relate
> to it.
>
> Thx
>
> Uri ("Oo-Ree") C: 949-378-7568
>
>
> -----Original Message----- From: sfc
> [mailto:sfc-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@oran= ge.com Sent: Sunday, April 24, 2016
> 10:32 PM To: Elzur, Uri <uri= .elzur@intel.com>; Thomas Narten
> <narten@us.ibm.com>; > sfc@ietf.org Subject: Re: [sfc] WG= last call for
> draft-ietf-sfc-nsh-04.txt
>
> Hi Uri,
>
> That's another option that needs to be discussed/investigated.
> I'm
> afraid
> this is not the rationale adopted in -04 since it includes some
> text
> that
> is far to be sufficient to ensure interoperable
> implementations.
>
> BTW, saying that nsh does not need to deal with fragmentation
> because
> it
> is transport-independent is not IMHO a good strategy to adopt
> here
> because
> it opens the door for interoperable issues, it may lead to
> sub-optimal implementations if the sfc information is present
> only in one
> fragments,
> etc.
>
> My comments are related to the current text in the -04.
> This text needs
> to
> be fixed somehow.
>
> Cheers, Med
>
> -----Message d'origine----- De : Elzur, Uri
> [mailto:uri.elzur@intel.com= ] Envoy=C3=A9 : dimanche 24 avril
> 2016 17:36 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten;
> sfc@ietf.org Objet : RE: [sfc] WG = last call for
> draft-ietf-sfc-nsh-04.txt
>
> Hi Med
>
> I see no need to specify the exact behavior as NSH is
> transport independent i.e. like NSH interaction with any other
> Transport eh issue of Fragmentation is to be dealt in a way
> that matches the mechanisms supported by the Transport used
> and do not belong in the NSH draft
>
> Thx
>
> Uri ("Oo-Ree") C: 949-378-7568
>
>
> -----Original Message----- From: sfc
> [mailto:sfc-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@oran= ge.com Sent: Thursday, April 14,
> 2016 12:43 AM To: Thomas Narten <narten@us.ibm.com>;
> sfc@ietf.org Subject: Re: [sfc] WG= last call for
> draft-ietf-sfc-nsh-04.txt
>
> R-,
>
> In addition to other pending issues raised for this draft, I
> would like to raise this additional one about Section 6.
>
> =3D=3D 6.=C2=A0 Fragmentation Considerations
>
> NSH and the associated transport header are "added" to the > encapsulated packet/frame.=C2=A0 This additional information
> increases
> the
> size of the packet.=C2=A0 In order the ensure proper forwarding of
> NSH data, several options for handling fragmentation and
> re-assembly exist:
>
> 1.=C2=A0 Jumbo Frames, when supported, enable the transport of NSH
> and associated transport packets without requiring
> fragmentation.
>
> 2.=C2=A0 Path MTU Discovery [RFC1191]"describes a technique for > dynamically discovering the maximum transmission unit (MTU) of
> an
> arbitrary internet path" and can be utilized to ensure the
> the
> required packet size is used.
>
> 3.=C2=A0 [RFC6830] describes two schemes for fragmentation and
> re-
> assembly
> in section 5.4. =3D=3D
>
> * The text is weak for a Standard track document that is
> intended to solve the problem in
> https://tools.ietf.org/html/rfc7498#section- > 2.12.
> There should be a clear behavior to be followed by an
> implementation.
> Further, I would avoid the use of words such as "can".
>
> * The text covers only fragmentation when it is induced by SFC
> operations, it does not discuss the treatment of a fragment
> when received in an SFC domain. IMHO, the draft should also
> specify the behavior of the Classifier with regards to
> fragments for the sake of proper SFC operation. Applying
> classification policies may require the
> full packet, not only a fragment.
> In particular, dedicated resources should dedicated for
> handling out of order fragments. Of course, it is out of scope
> of this document to describe how SFs handle fragments.
>
> * If an SFC header is prepended for all fragments, I'm not
> sure there is any particular issue at the SFF level...except
> if stripping/adding context TLVs depends on the full packet
> (not just fragment). It is warranted to consider a little bit
> this point before declaring there
> is
> no issue.
>
> * The text states "several options". This may be interpreted=
> as if implementing one of them is sufficient...which is not
> true. The first two points contribute to minimize the
> fragmentation risk, but fragmentation may still be experienced
> (e.g., other shims are prepended by other nodes for some other
> purposes, nested nsh, etc.)
>
> * The first two points have nothing to do with reassembly.
>
> * The support of jumbo frames by a router/device does not mean
> that it can make use of it. Appropriate MTU configuration
> should be undertaken in a consistent manner within an SFC
> domain. The text should be updated to make it is about
> (consistent) MTU
> configuration.
>
> * BTW, shouldn't the text be reworded to recommended to
> increase the MTU of **all nodes** of an SFC-enabled domain by
> at least the length of SFC header + transport header?
>
> * Bullet 2, how PMTU discovery is actually used in this
> context? Do you assume that all SFC-aware nodes will issue
> such messages towards other SFC-aware node, arbitrary
> destination, else?
>
> * Bullet 2, I would drop "describes a technique for
> dynamically discovering the maximum transmission unit
> (MTU) of an arbitrary internet path".
>
> * Bullet 2, s/ the the/the.
>
> * The reference to the LISP specification raises two concerns
> and one comment:
>
> (1) I don't think it is a good approach that fragments induced
> by the network are passed to their ultimate destinations as
> such
> (stateless).
> IMO, reassembly should be done within the SFC domain
> (responsible for fragmentation) not passed away. (2) Does the
> stateful mode require all SFC data plane elements maintain a
> full list of MTU for the any SFF/SF instance of the SFC
> domain?
>
> The current text suggests that [RFC6830] should be listed as
> normative reference (not an informative one). I would
> personally favor removing the reference to LISP (as it is an
> Experimental RFC).
>
> * The security section of the draft may be augmented with
> informational fragmentation-related pointers to:
> e.g., RFC1858 (Security Considerations for IP Fragment
> Filtering), RFC3128 (Protection Against a Variant of the Tiny
> Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High
> Data Rates).
>
> Cheers, Med
>
> -----Message d'origine----- De : sfc
> [mailto:sfc-bounces@ietf.org] De la part de
> mohamed.boucadair@oran= ge.com Envoy=C3=A9 : lundi 11 avril
> 2016 13:14 =C3=80 : Thomas Narten; sfc= @ietf.org Objet : Re:
> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
>
> Dear Thomas, all,
>
> As I mentioned during the meeting, there are several issues
> that are not covered in the last version of the draft. I
> already provided examples of the issues offline as requested
> by Martin.
>
> Cheers, Med
>
> -----Message d'origine----- De : sfc
> [mailto:sfc-bounces@ietf.org] De la part de Thomas Narten
> Envoy=C3=A9 : jeudi 31 mars 2016 04:48 =C3=80 :
> sfc@ietf.org Objet : [sfc] WG last= call for
> draft-ietf-sfc-nsh-04.txt
>
> Dear WG:
>
> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt
> (https://datatracker.ietf.org/doc/draft-ie= tf-sfc-nsh/).
>
>
>
> The editors of the NSH document have indicated that they have
> addressed all known comments and that there are no open
> issues with the current version of the document.
>
> Substantive comments to the list please, editorial comments
> can go directly to the document editors.
>
> We'll also get a brief update from the editors at next
> week's meeting. If there are any remaining issues with the
> document, raising them before the meeting would be
> especially helpful.
>
> For the chairs, Thomas
>
> _______________________________________________ sfc mailing
> list sfc@ietf.org = https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing
> list sfc@ietf.org = https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing
> list sfc@ietf.org = https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing
> list sfc@ietf.org = https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing list
> sfc@ietf.org https= ://www.ietf.org/mailman/listinfo/sfc
>
>
> _______________________________________________ sfc mailing list
> sfc@ietf.org https= ://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________ sfc mailing list
> sfc@ietf.org https= ://www.ietf.org/mailman/listinfo/sfc
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


--089e011826a4cf44c805317f9aab-- From nobody Wed Apr 27 16:46:30 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 32F5C12D09F for ; Wed, 27 Apr 2016 16:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 q-hrmbCF7RS6 for ; Wed, 27 Apr 2016 16:46:25 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C15A12B029 for ; Wed, 27 Apr 2016 16:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CE2A9240EFB; Wed, 27 Apr 2016 16:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461800784; bh=RwMk6jPr9WtRWI1F3YITdgmojW2Qfnho8eDAO+VjAMA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RHAKMxUA2V+3PfM+YSq9dIwFj35r/5UJomWmPD1or1lNo3evBUFp4fllgn0vR3nG0 zeuum2VHQ7fiEnOrmgIrJuWwk+IOvFkqZ49aMhU/sQ2sypR8ETejGlOurUqFVF9yxQ PJfKIwX0KrAws+GvnGbqmVACaHiFCqw1/DgOPQWE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A7AF22403A3; Wed, 27 Apr 2016 16:46:21 -0700 (PDT) To: "Andrew G. Malis" References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> From: Joel Halpern Direct Message-ID: <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> Date: Wed, 27 Apr 2016 19:46:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.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" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 27 Apr 2016 23:46:28 -0000 The LISP header does not have a fragment flag or fragment offset. The diagrams in section 6 include the outer encapsulating header (the equivalent of the transport header in SFC.) Yes, the text is a little hard to follow in this regard. The LISP working group is going to be rewriting RFC 6830 as part of moving to standards track. So there is no difference in this regard between NSH and LISP. Yours, Joel On 4/27/16 7:02 PM, Andrew G. Malis wrote: > Joel et al, > > All this talk about fragmentation prompted me to re-read section 6 of > the draft, which recommends (as option 3) using the procedures in > section 5.4 of RFC 6830 (presumably with the “NSH header†replacing the > “LISP header†in the description of the procedures in that section). > > So that led me to read that section (and the LISP header definition in > section 5.1), and I see that LISP does fragmentation and reassembly > identically to IPv4, using the Fragment Offset field so that fragments > can be correctly reassembled in the proper order. > > However, the NSH Header doesn’t have a Fragment Offset field or any > other way to order the fragments. > > So how can the procedures in Section 5.4 of 6830 be used? > > Thanks, > Andy > > On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern > wrote: > > Both methods are valid, and both depend upon details of the > underlying packet and the transport. As such, I don't see why this > document benefits from describing them, much less why it should mark > one method as a "should". Implementation details are likely to be > more significant than any bit consumption difference between the two > alternatives. > > Yours, > Joel > > > On 4/27/16 3:40 PM, Linda Dunbar wrote: > > I suggest adding the following paragraphs after the Bullet 3 of > the Section 6 Fragmentation Consideration to make the process > more clear and less controversial: > > > -------------------------------- > > RFC6830 describes the fragmentation method of breaking the > original packet into two equal sub-frames and encapsulating > [LISP Header + Transport header] to each sub-frame. > > If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC > Header + Transport Header] will be added to each half frame (or > the original data frame). As the Transport Header is terminated > by the next SFF node's tunnel transport layer, the combined two > sub-frames will have two SFC Headers. > > Therefore, the fragmentation for NSH encapsulated data frame > should be done completely by the node tunnel transport layer, > which should break the [SFC + original packet] into two equal > sub-frames and each sub-frame being encapsulated with its > respective tunnel header. The next SFF node's tunnel transport > layer should combine the two sub-frames before sending to the > next node. > > ------------------------------------------------------ > > > By the way, there are to typo in the Section 6: > 3rd line: "In order the" ==> "In order to" > Last line of Bullet 2: extra "the" in the "utilized to ensure > the the required packet". > > > Hope it helps. > > Linda > > > > -----Original Message----- > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com > ] > Sent: Wednesday, April 27, 2016 12:40 AM > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Hi Joel, all, > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Joel M. Halpern [mailto:jmh@joelhalpern.com > ] Envoyé : mardi 26 > avril 2016 19:18 À : Linda Dunbar; BOUCADAIR Mohamed > IMT/OLN; Elzur, > Uri; sfc@ietf.org Objet : Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > With regard to Transport tunnel fragementation, that seems > an issue > for the transport protocol. I don't actually object to a > sentence, > but it does not seem that it will accomplish anything. > > > [Med] I would like to see some text added to the draft. > > > With regard to packets fragmented by the source, I > completely disagree > with your assertion. If an SFF were to reassemble the > packets, that > would be a violation of its job. > > > [Med] I agree with you. > > There is no reason for an SFF to > > reassemble a packet fragmented by the source. The > classifier may have > to do some interesting things in order to properly classify > succeeding > fragments, but that is an implementation issue (most commonly > addressed with virtual reassembly, which doe snot delay the > fragments.) We don't specity that. > > > [Med] Still, the external behavior of the classifier needs to be > clear in the document. I don't find any text in the draft saying > for instance that an NSH header must be present in all > fragments. (There some processing that might be needed at the > SFF to "do its job" with regards to fragments (receive out of > order fragments + forwarding policy on the full packet).) > > > If an SF needs to reassemble fragments to do its job, that > is up to > the SF. Some will need to actually reassemble. Some will > need to > perform virtual reassembly, and some will happily process the > fragments. I can not see what the NSH document could > possibly mandate. > > > [Med] Fully agree. > > > Yours, > Joel > > On 4/26/16 11:47 AM, Linda Dunbar wrote: > > Joel, > > I think the document should add the description on the > following two > fragmentation scenarios: > > - Transport tunnel generated fragmentation: When a packet > fragmentation is caused by transport tunnel (i.e. various > encapsulations), the termination point of the transport > tunnel is > responsible for re-assembling the fragmented pieces of > the packet. > Since there won't be any SFF nodes in between the > Transport Tunnel, > the tunnel generated fragmentation does not require any > actions by > SFF nodes or SF nodes. > > > - Source node generated fragmentation (after adding on > the NSH > header): When fragmentation has to be performed for a > packet being > encapsulated with the NSH header, either the > intermediate SFF nodes > or the SF nodes have to be able to reassemble the > fragmented pieces. > > > > > Cheers, > > > Linda > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com > ] Sent: Tuesday, April 26, > 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com > ; Elzur, Uri; > sfc@ietf.org Subject: Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that you are > referring only to > the case of transport generated fragmentation of the > outer packet. > I had assumed you were not talking about that, since the > resulting > fragments will not all have NSH headers. As with any tunnel > technology, if the tunnel chooses to fragment at its > layer, then the > tunnel is responsible for reassembly. That would be > invisible to > the SFF. > > Yours, Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > > Agree with Med. > > Even if each fragment piece of a packet with NSH > header carries the > NSH header, the intermediate SFF nodes still need to > put together > all the fragments together before passing the whole > data frame to > the SF. > > Linda > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] > On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, > April 25, > 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; > sfc@ietf.org Subject: > Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to ALWAYS > prepend an NSH > header even for fragments? Or you don't care about that? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : Elzur, Uri > [mailto:uri.elzur@intel.com > ] Envoyé : lundi 25 > avril 2016 16:26 À > : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; > sfc@ietf.org Objet > : RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > Not to repeat my position, but I'll do it anyhow > :-) As NSH is > *NOT* a transport, dealing with fragmentation is > left to the > Transport used. > > The model I use for NSH, is basically similar to > VXLAN . It is an > overly. > > Thx > > Uri ("Oo-Ree") C: 949-378-7568 > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] > On Behalf Of mohamed.boucadair@orange.com > Sent: > Monday, April 25, > 2016 7:18 AM To: Joel M. Halpern > >; > sfc@ietf.org > Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Joel, > > Please see inline. > > Cheers, Med > > -----Message d'origine----- De : Joel M. Halpern > [mailto:jmh@joelhalpern.com > ] Envoyé : lundi > 25 avril 2016 15:48 À > : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Objet : Re: [sfc] WG > last call for draft-ietf-sfc-nsh-04.txt > > If I am understanding you correctly Med, you > are asking that the > NSH draft specify how service chaining > should cope with packets > that have been fragmented? > > > [Med] To be accurate, I'm asking to assess > whether there are > implications. If there are, then the draft > should be updated > accordingly. > > NSH, and the SFF functionality, does not care. > > > [Med] I'm not that sure. Some typical > implications are listed > below: > > * SFF: If the NSH header is present only in the > a fragment but SFF > didn't maintained a state, subsequent fragments > won't be > appropriately processed. * SFC-aware function: > if prepending a > context information depends on the full packet, > not only a > fragment. > > It just does its job. > > [Med] which may be disturbed in some situations > as listed in the > examples above. > > Ingress and intermediate classifiers may > cope with fragments in > any number of ways. > > Specifying such is clearly out of scope for this > draft. > > [Med] The purpose is not to specify the internal > implementation > details but the external behavior of the > classifier function when > it comes to handle fragments. That behavior may > have an incidence > on SFF, in particular. The purpose is not to > recommend the maximum > resources to be dedicated to out of order > fragments nor the > timeout to cache those; these considerations are > of course out of > scope. Nevertheless, an implementation should > offer a configurable > parameter so that an operator tweak those > according to its > context. > > I suppose one could write an informational > draft on possible ways > of coping. The IETF has not usually > published such. > Service functions have to cope with > fragmented packets just as > they had to before the advent of NSH, so > describing that is > clearly not needed here. > > > [Med] The advent of NSH has the following > implications: * it > exacerbates fragmentation. Handing over this > issue to the > transport layer may lead to interoperability > issues. * the > chaining may not be efficient if fragments are > inappropriately > handled. > > Introducing NSH should not degrade the overall > service compared to > legacy service deployment schemes. > > > Yours, Joel > > On 4/25/16 3:00 AM, > mohamed.boucadair@orange.com > wrote: > > Re-, > > I hear you, but my comment is that we > need, as a WG, to decide > what to > > put in the draft. FWIW, I'm discussing two > fragmentation > issues: > > > (1) Fragmentation that is caused by > prepending an SFC header. > (2) Handling fragments at the ingress of > an SFC-enabled domain. > > Increasing the MTU is for sure a > recommendation is to be > explicitly > > called out in the text (see my first message). > > > There are other issues that need to be > discussed, e.g., how to > deal with > > fragments in SFFs/Classifiers? > > > It is also "prudent" to check that no > issues will be experienced > in SFF > > to handle fragments. If an SFC header is > prepended for all > fragments, I'm not sure there > > is any particular issue at the SFF > level, except if > stripping/adding > > context TLVs depends on the full packet (not > just fragment). It > is warranted to consider a little bit this > point before declaring > there is no issue. > > > For point (1), declaring fragmentation > out of scope would be > meant that > > an implementation must be prepared to > receive fragments with or > without NSH header as this is a decision > that is left to the > transport encapsulation. This is a > requirement per se! > > > I won't reiterate all the comments I > have about the current > wording of > > this section. > > > Cheers, Med > > -----Message d'origine----- De : > Elzur, Uri > [mailto:uri.elzur@intel.com > ] Envoyé > : lundi 25 avril 2016 > 08:30 À : BOUCADAIR Mohamed IMT/OLN; > Thomas Narten; > sfc@ietf.org > Objet : RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > My point is that Fragmentation is > yet another transport related > issue > > that > > is beyond the scope of NSH and > beyond the charter of the WG, so > it > > doesn't > > really belong in the draft. We are > providing an advice as > extending the size of the packet may > lead to fragmentation, but > as you check RFC 7348 VxLAN, which > my create the same issue, > you'll find it doesn't even > > relate > > to it. > > Thx > > Uri ("Oo-Ree") C: 949-378-7568 > > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] On > Behalf Of > mohamed.boucadair@orange.com > Sent: > Sunday, April 24, 2016 > 10:32 PM To: Elzur, Uri > >; > Thomas Narten > > >; > > sfc@ietf.org > Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Uri, > > That's another option that needs to > be discussed/investigated. > I'm > > afraid > > this is not the rationale adopted in > -04 since it includes some > text > > that > > is far to be sufficient to ensure > interoperable > implementations. > > BTW, saying that nsh does not need > to deal with fragmentation > because > > it > > is transport-independent is not IMHO > a good strategy to adopt > here > > because > > it opens the door for interoperable > issues, it may lead to > sub-optimal implementations if the > sfc information is present > only in one > > fragments, > > etc. > > My comments are related to the > current text in the -04. > This text needs > > to > > be fixed somehow. > > Cheers, Med > > -----Message d'origine----- De : > Elzur, Uri > [mailto:uri.elzur@intel.com > ] > Envoyé : dimanche 24 avril > 2016 17:36 À : BOUCADAIR Mohamed > IMT/OLN; Thomas Narten; > sfc@ietf.org > Objet : > RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > I see no need to specify the > exact behavior as NSH is > transport independent i.e. like > NSH interaction with any other > Transport eh issue of > Fragmentation is to be dealt in > a way > that matches the mechanisms > supported by the Transport used > and do not belong in the NSH draft > > Thx > > Uri ("Oo-Ree") C: 949-378-7568 > > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > ] > On Behalf Of > mohamed.boucadair@orange.com > > Sent: Thursday, April 14, > 2016 12:43 AM To: Thomas Narten > >; > sfc@ietf.org > Subject: > Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > R-, > > In addition to other pending > issues raised for this draft, I > would like to raise this > additional one about Section 6. > > == 6. Fragmentation Considerations > > NSH and the associated transport > header are "added" to the > encapsulated packet/frame. This > additional information > increases > > the > > size of the packet. In order > the ensure proper forwarding of > NSH data, several options for > handling fragmentation and > re-assembly exist: > > 1. Jumbo Frames, when > supported, enable the transport > of NSH > and associated transport packets > without requiring > fragmentation. > > 2. Path MTU Discovery > [RFC1191]"describes a technique for > dynamically discovering the > maximum transmission unit (MTU) of > > an > > arbitrary internet path" and can > be utilized to ensure the > > the > > required packet size is used. > > 3. [RFC6830] describes two > schemes for fragmentation and > re- > > assembly > > in section 5.4. == > > * The text is weak for a > Standard track document that is > intended to solve the problem in > https://tools.ietf.org/html/rfc7498#section- > > 2.12. > > There should be a clear behavior > to be followed by an > > implementation. > > Further, I would avoid the use > of words such as "can". > > * The text covers only > fragmentation when it is induced > by SFC > operations, it does not discuss > the treatment of a fragment > when received in an SFC domain. > IMHO, the draft should also > specify the behavior of the > Classifier with regards to > fragments for the sake of proper > SFC operation. Applying > classification policies may > require the > > full packet, not only a fragment. > > In particular, dedicated > resources should dedicated for > handling out of order fragments. > Of course, it is out of scope > of this document to describe how > SFs handle fragments. > > * If an SFC header is prepended > for all fragments, I'm not > sure there is any particular > issue at the SFF level...except > if stripping/adding context TLVs > depends on the full packet > (not just fragment). It is > warranted to consider a little bit > this point before declaring there > > is > > no issue. > > > * The text states "several > options". This may be interpreted > as if implementing one of them > is sufficient...which is not > true. The first two points > contribute to minimize the > fragmentation risk, but > fragmentation may still be > experienced > (e.g., other shims are prepended > by other nodes for some other > purposes, nested nsh, etc.) > > * The first two points have > nothing to do with reassembly. > > * The support of jumbo frames by > a router/device does not mean > that it can make use of it. > Appropriate MTU configuration > should be undertaken in a > consistent manner within an SFC > domain. The text should be > updated to make it is about > (consistent) MTU > > configuration. > > > * BTW, shouldn't the text be > reworded to recommended to > increase the MTU of **all > nodes** of an SFC-enabled domain by > at least the length of SFC > header + transport header? > > * Bullet 2, how PMTU discovery > is actually used in this > context? Do you assume that all > SFC-aware nodes will issue > such messages towards other > SFC-aware node, arbitrary > destination, else? > > * Bullet 2, I would drop > "describes a technique for > dynamically discovering the > maximum transmission unit > (MTU) of an arbitrary internet > path". > > * Bullet 2, s/ the the/the. > > * The reference to the LISP > specification raises two concerns > and one comment: > > (1) I don't think it is a good > approach that fragments induced > by the network are passed to > their ultimate destinations as > such > > (stateless). > > IMO, reassembly should be done > within the SFC domain > (responsible for fragmentation) > not passed away. (2) Does the > stateful mode require all SFC > data plane elements maintain a > full list of MTU for the any > SFF/SF instance of the SFC > > domain? > > > The current text suggests that > [RFC6830] should be listed as > normative reference (not an > informative one). I would > personally favor removing the > reference to LISP (as it is an > Experimental RFC). > > * The security section of the > draft may be augmented with > informational > fragmentation-related pointers to: > e.g., RFC1858 (Security > Considerations for IP Fragment > Filtering), RFC3128 (Protection > Against a Variant of the Tiny > Fragment Attack), and RFC 4963 > (IPv4 Reassembly Errors at High > Data Rates). > > Cheers, Med > > -----Message d'origine----- > De : sfc > [mailto:sfc-bounces@ietf.org > ] > De la part de > mohamed.boucadair@orange.com > > Envoyé : lundi 11 avril > 2016 13:14 À : Thomas > Narten; sfc@ietf.org > Objet > : Re: > [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Dear Thomas, all, > > As I mentioned during the > meeting, there are several > issues > that are not covered in the > last version of the draft. I > already provided examples of > the issues offline as requested > by Martin. > > Cheers, Med > > -----Message > d'origine----- De : sfc > [mailto:sfc-bounces@ietf.org > ] > De la part de Thomas Narten > Envoyé : jeudi 31 mars > 2016 04:48 À : > sfc@ietf.org > > Objet : [sfc] WG last > call for > draft-ietf-sfc-nsh-04.txt > > Dear WG: > > This note begins a WG > last call on > draft-ietf-sfc-nsh-04.txt > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > The editors of the NSH document have indicated that they have > > addressed all known > comments and that there > are no open > issues with the current > version of the document. > > Substantive comments to > the list please, > editorial comments > can go directly to the > document editors. > > We'll also get a brief > update from the editors > at next > week's meeting. If there > are any remaining issues > with the > document, raising them > before the meeting would be > especially helpful. > > For the chairs, Thomas > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ sfc > mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Apr 27 18:05:59 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 6B63512B040 for ; Wed, 27 Apr 2016 18:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 LAMIkhb7phEV for ; Wed, 27 Apr 2016 18:05:55 -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 F3237120047 for ; Wed, 27 Apr 2016 18:05:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNL03048; Thu, 28 Apr 2016 01:05:52 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 28 Apr 2016 02:05:51 +0100 Received: from SZXEMA506-MBX.china.huawei.com ([169.254.3.126]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 28 Apr 2016 09:05:46 +0800 From: "Huangyong (Oliver)" To: Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1iU0PcZg0k+ke2A/Hr//oAEZ+ekzvw Date: Thu, 28 Apr 2016 01:05:45 +0000 Message-ID: <8172B566C79A4A4C8EB6C7B1F6529EFC8B7435C1@szxema506-mbx.china.huawei.com> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> In-Reply-To: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.158.105] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.572161F1.006B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.126, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 95c8649cdd91b71b3c28533f926e658a Archived-At: Subject: [sfc] =?gb2312?b?tPC4tDogIFdHTEMgZm9yIGRyYWZ0LWlldGYtc2ZjLWNvbnRy?= =?gb2312?b?b2wtcGxhbmUtMDQudHh0?= 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, 28 Apr 2016 01:05:57 -0000 RGVhciBNYXJ0aW4sDQoNCiAgICBBcyB0aGUgZWFybHkgdmVyc2lvbiBhdXRob3Igb2YgdGhlIGRy YWZ0LiAgSSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCkJSDQpPbGl2ZXIN Cg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIE1hcnRpbiBTdGllbWVybGluZw0Kt6LLzcqxvOQ6IDIwMTbE6jTUwjI3yNUg MTI6MjkNCsrVvP7Iyzogc2ZjQGlldGYub3JnDQrW98ziOiBbc2ZjXSBXR0xDIGZvciBkcmFmdC1p ZXRmLXNmYy1jb250cm9sLXBsYW5lLTA0LnR4dA0KDQpEZWFyIGFsbCwNCg0KVGhpcyBpcyB0aGUg c3RhcnQgb2YgdGhlIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIChXR0xDKSBmb3INCg0KZHJhZnQt aWV0Zi1zZmMtY29udHJvbC1wbGFuZS0wNC50eHQNCg0KVGhlIFdHTEMgbGFzdHMgZm9yIDIgd2Vl a3MgYW5kIHdpbGwgZW5kIE1heSAxMXRoIGF0IDEwIHBtIFBEVC4NCg0KUGxlYXNlIHNlbmQgeW91 ciBjb21tZW50cyBhbmQgcmV2aWV3cyB0byB0aGUgc2ZjQGlldGYub3JnIGxpc3QuDQoNClJlZ2Fy ZHMsDQoNCiAgIE1hcnRpbiAoU0ZDIGNvLWNoYWlyKQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Wed Apr 27 23:58:49 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 A381212D1E5 for ; Wed, 27 Apr 2016 23:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 uBQFyNkL0MJQ for ; Wed, 27 Apr 2016 23:58:45 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D799512B02E for ; Wed, 27 Apr 2016 23:58:44 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 61233A0581; Thu, 28 Apr 2016 08:58:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 32D9A4007A; Thu, 28 Apr 2016 08:58:43 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 08:58:42 +0200 From: To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1hgqCe3Pkr6EKnc83IMsxhI5+d714AgAD0McA= Date: Thu, 28 Apr 2016 06:58:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6100C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> 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.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6100COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 06:58:48 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6100COPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jim, Thank you for the review. Please see inline. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : mercredi 27 avril 2016 16:18 =C0 : Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. [Med] Fair point. I suggest to make these modifications: (1) OLD: The following information that is likely to be provided to the SFC control plane at bootstrapping includes (non-exhaustive list): NEW: The following information that is RECOMMENDED to be provided to the SFC control plane prior to bootstrapping includes: (2) Remove this bullet from the list and insert it right after the list. o Optionally, (traffic/CPU/memory) load balancing objectives at the SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy [Med] Fixed. Thanks. * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. [Med] That sentence is related to the rich set of transport encapsulation s= chemes, but also that nsh header includes a version number. The current nsh spec does not specify how nodes with distinct nsh versions = are supposed to behave. Also, we don't know in 2016 (because there is no ns= h v2) whether v0 and v2 will be backward compatible. If these versions are = not backward compatible, this will lead to failures when two adjacent eleme= nts in a service chain do not support the same version. The cp is key to ensure coherent setup of an SFC-domain to avoid failures t= hat are due to unsupported version and/or unsupported transport encapsulati= on. * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. [Med] I agree RSP is not explicitly mentioned in Section 3.1, but the point= you raised is what is under this bullet: o Determine a forwarding path in the context of a centralized deployment model (see Section 3.2). Section 3.2 states the following: For some traffic engineering proposes, the SFP may be constrained by the control plane; as such, some SFPs can be fully specified (i.e., list all the SFF/SFs that need to be solicited) or partially specified (e.g., exclude some nodes, explicitly select which instance of a given SF needs to be invoked, etc.). Do you think a change is still needed to the text? Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. [Med] Good point. I suggest this change in Section 3.3.3 that I believe is = sufficient to take into account this comment: OLD: The SFC control plane uses this interface to interact with SFC-aware SFs. NEW: The SFC control plane uses this interface to interact with SFC-aware SFs. This interaction may be direct or via dedicated SF management syste= ms. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. [Med] Makes sense. I made the change in my local copy. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. [Med] FWIW, there was a call about this section (https://www.ietf.org/mail-= archive/web/sfc/current/msg03756.html). This section does not recommend nor= exclude source routes. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. [Med] I will defer to Linda/Andrew to clarify this part of that text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_787AE7BB302AE849A7480A190F8B933008D6100COPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

Thank you for the review.

 

Please see inline.

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mercredi 27 avril 2016 16:18
=C0 : Martin Stiemerling; sfc@ietf.org
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt<= o:p>

 

Hi Martin & WG:

 

A few comments that I would= like to see addressed in the document before it can move forward to the ne= xt step.

  • Section 2.2 SFC Control Plane Bootstrapping.=

This section is too wishy w= ashy. It makes the statement “this document assumes the SFC control p= lane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

[Med] Fair point. I suggest to = make these modifications:

 

(1)

 

OLD:

   The following information= that is likely to be provided to the SFC

   control plane at bootstrapping= includes (non-exhaustive list):

 

NEW:

   The following information that is RE=
COMMENDED to be provided to the SFC
   control plane prior to bootstrapping=
 includes:

 

(2)

 

Remove this bullet from the lis= t and insert it right after the list.

 

   o  Optionally, (traffic/CPU/mem=
ory) load balancing objectives at the
      SFC level or on a =
per node (e.g., per-SF/SFF/SFP proxy) basis.

 

Minor point = -> typo in bullet point 6 – SFP proxy should read SFC proxy

[Med] Fixed. Thanks.

  • Section 2.3 Coherent Setup of an SFC-enabled Domain=

What does the sentence R= 20;various transport encapsulation schemes and/or variations of SFC header = implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or som= ething else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

 

[M= ed] That sentence is related to the rich set of transport encapsulation sch= emes, but also that nsh header includes a version number.

 

Th= e current nsh spec does not specify how nodes with distinct nsh versions ar= e supposed to behave. Also, we don’t know in 2016 (because there is no nsh v2) whether v0 and v2 will be backward compatible= . If these versions are not backward compatible, this will lead to failures= when two adjacent elements in a service chain do not support the same vers= ion.

 

Th= e cp is key to ensure coherent setup of an SFC-domain to avoid failures tha= t are due to unsupported version and/or unsupported transport encapsulation.

  • Section 3.1 Reference Architecture

Second bullet point “= mapping between service function chains and SFPs” - this is a general= comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned only o= nce in the entire document. The architecture is explicit in that the SFP wh= en rendered into the network is an RSP and therefore the SFC control plane = element needs to have information on currently deployed RSPs.

 

[Med] I agree RSP is not explic= itly mentioned in Section 3.1, but the point you raised is what is under th= is bullet:

 

   o  Determine a forwarding path =
in the context of a centralized
      deployment =
model (see Section 3.2).

 

Section 3.2 states the followin= g:

 

      For some traffic e=
ngineering proposes, the SFP may be constrained
      by the control pla=
ne; as such, some SFPs can be fully specified
      (i.e., list all th=
e SFF/SFs that need to be solicited) or
      partially specifie=
d (e.g., exclude some nodes, explicitly select
      which instance of =
a given SF needs to be invoked, etc.).
 
Do you think a change is still needed to the text=
? 
 

Additionally= there is no interface specified for communication between the SFC Control = Plane Element and SF management systems. This is an important aspect as many SF̵= 7;s may require that SFC information be communicated to their management sy= stems that will be responsible for communicating directly with their respective SF’s. 

 

[Med] Good point. I suggest thi= s change in Section 3.3.3 that I believe is sufficient to take into account= this comment:

 

OLD:

 

   The SFC control plane uses this inte=
rface to interact with SFC-aware
   SFs.

 

NEW:

 

   The SFC control plane uses this inte=
rface to interact with SFC-aware
   SFs. This interaction may be direct =
or via dedicated SF management systems.
  • Section 3.1.1. C1: Interface between SFC Control Plane & S= FC Classifier

The sentence “The con= trol plane may instruct the classifier about the initial values of the Serv= ice Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. 

 

[Med] Makes sense. I made the c= hange in my local copy.

  • Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Pac= kets

This section does not actua= lly provide any meaning or indication of relationship with the SFC Control = Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire= section should be removed from the document.

 

[Med] FWIW, there was a call ab= out this section (https://www.ietf.org/mail-archive/web/sfc/current/msg037= 56.html). This section does not recommend nor exclude source routes.

  • Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP

Figure 2 lists 3 different = SFP-id’s whereas the text mentions only SFP-id #1. Is this simply a t= ypo or are you trying to convey something else ?

 

Further you state that R= 20;the steering policies to a SFF node for service function chain depends o= n if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= ” -  this is an inaccurate statement as the combination of the S= FP-id and service-index determines the forwarding behavior (as specified in= section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

 

[Med] I will defer to Linda/And= rew to clarify this part of that text.    =

 

Jim

 

 

 

On 4/27/16, 12:29 AM, "= ;sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,=

 

This is the start of the Wo= rking Group Last Call (WGLC) for

 

draft-ietf-sfc-control-plan= e-04.txt

 

The WGLC lasts for 2 weeks = and will end May 11th at 10 pm PDT.

 

Please send your comments a= nd reviews to the sfc@ietf.org list.

 

Regards,<= /p>

 

   Martin (SFC co= -chair)

 

___________________________= ____________________

sfc mailing list=

 

--_000_787AE7BB302AE849A7480A190F8B933008D6100COPEXCLILMA3corp_-- From nobody Thu Apr 28 01:07:00 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 5B77612D1E5 for ; Thu, 28 Apr 2016 01:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 BTS81ld6XUqF for ; Thu, 28 Apr 2016 01:06:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FE512B052 for ; Thu, 28 Apr 2016 01:06:54 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0B22E3B46A3; Thu, 28 Apr 2016 10:06:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D5AFF27C053; Thu, 28 Apr 2016 10:06:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 10:06:52 +0200 From: To: "Joel M. Halpern" , Ron Parker , "Elzur, Uri" , "sfc@ietf.org" Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoI2umc2+lVuP1Eu9qKRylYgewZ+e4ZPg Date: Thu, 28 Apr 2016 08:06:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D61111@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D5EEAB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <0f0e8705-1ca4-6df0-81c3-93db0f94a99f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D604F7@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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 28 Apr 2016 08:06:59 -0000 Hi Joel, Now that we agree on the scope, shouldn't the text be /updated to reflect a= nd clarify what was discussed in this thread? >From where I stand, I would like to see added in particular text saying tha= t nsh header is present in every fragment. =20 Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mercredi 27 avril 2016 16:04 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Ron Parker; Elzur, Uri; sfc@ietf.org > Objet=A0: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > On the Classifier<->SFF communication, you have a fiar point. My > personal model is off in that regard. My apologies. >=20 > I believe that the assumption there is that just as with an SFF, it will > use a local means to couple to a transport encapsulator. I tend to > think of this as putting an SFF co-located with the classifier, and then > using SFF functionality, but that is not required by the architecture. >=20 > The external behavior of the SFF,_>SF interface, where the SF speaks > NSH, is that an NSH encapsulated frame is communicated between the two. > The transport mechanism (which may need to fragment) is out of scope. >=20 > Yours, > Joel >=20 > On 4/27/16 1:46 AM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > Please see inline. > > > > Cheers, Med > > > >> -----Message d'origine----- De : Joel M. Halpern > >> [mailto:jmh@joelhalpern.com] Envoy=E9 : mardi 26 avril 2016 19:22 =C0 = : > >> Ron Parker; Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN; Elzur, > >> Uri; sfc@ietf.org Objet : Re: [sfc] WG last call for > >> draft-ietf-sfc-nsh-04.txt > >> > >> At least so far, we have treated the communication between > >> classifier and SFF (ingress or intermediate) as outside of the > >> scope of our work. > > > > [Med] I'm afraid I don't get this one. Isn't this what is depicted in > > https://tools.ietf.org/html/rfc7665#section-4? > > > >> For SF <-> SFF communication we have ntoed the need for a proxy to > >> handle the case when the SF can not accept and return the NSH > >> header, since we assume that is preserved. Other than that > >> preservation, similar to the above, we have treated the details as > >> outside of our scope. That is because they depend so heavily on the > >> implementation technique used. (Hypervisor ,_> application > >> communication vs communication inside a user space or communication > >> over an actual Ethernet are all very different.) > > > > [Med] Specifying the external behavior of the interface between an > > SFF and an SFC-aware SF is completely in scope, imho. > > > >> > >> Trying to extend the NSH document to address these would be a > >> major change, and would step into the issues related to transport > >> selection, which are explicitly out of scope. > >> > >> Yours, Joel > >> > >> On 4/26/16 11:58 AM, Ron Parker wrote: > >>> Linda, > >>> > >>> I like the first clause (transport tunnel based fragmentation). > >>> > >>> Regarding the second (source based), I think there are more > >>> subcases to > >> consider: > >>> > >>> 1. Propagation of NSH encapsulated packet from classifier to > >>> SFF 2. Propagation of NSH encapsulated packet from SFF to SF 3. > >>> Propagation of NSH encapsulated packet from SF to SFF (including > >> possibility that NSH size increased at SF) > >>> 4. Propagation of NSH encapsulated packet from SFF to SFF > >>> > >>> In each of the 4 cases above, there is the possibility that MTU > >>> will be > >> exceeded and therefore there are procedures to be defined in that > >> eventuality. > >>> > >>> Thanks. > >>> > >>> Ron > >>> > >>> > >>> -----Original Message----- From: sfc > >>> [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: > >>> Tuesday, April 26, 2016 11:48 AM To: Joel M. Halpern > >>> ; mohamed.boucadair@orange.com; > >> Elzur, Uri ; sfc@ietf.org > >>> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>> > >>> Joel, > >>> > >>> I think the document should add the description on the following > >>> two > >> fragmentation scenarios: > >>> > >>> - Transport tunnel generated fragmentation: When a packet > >>> fragmentation is caused by transport tunnel (i.e. > >> various encapsulations), the termination point of the transport > >> tunnel is responsible for re-assembling the fragmented pieces of > >> the packet. Since there won't be any SFF nodes in between the > >> Transport Tunnel, the tunnel generated fragmentation does not > >> require any actions by SFF nodes or SF nodes. > >>> > >>> > >>> - Source node generated fragmentation (after adding on the NSH > >>> header): When fragmentation has to be performed for a packet > >>> being > >> encapsulated with the NSH header, either the intermediate SFF nodes > >> or the SF nodes have to be able to reassemble the fragmented > >> pieces. > >>> > >>> > >>> > >>> Cheers, > >>> > >>> > >>> Linda > >>> > >>> -----Original Message----- From: Joel M. Halpern > >>> [mailto:jmh@joelhalpern.com] Sent: Tuesday, April 26, 2016 10:33 > >>> AM To: Linda Dunbar; mohamed.boucadair@orange.com; Elzur, Uri; > >>> sfc@ietf.org Subject: Re: [sfc] WG last call for > >>> draft-ietf-sfc-nsh-04.txt > >>> > >>> Re-reading your note, it is possible that you are referring only > >>> to the > >> case of transport generated fragmentation of the outer packet. I > >> had assumed you were not talking about that, since the resulting > >> fragments will not all have NSH headers. As with any tunnel > >> technology, if the tunnel chooses to fragment at its layer, then > >> the tunnel is responsible for reassembly. That would be invisible > >> to the SFF. > >>> > >>> Yours, Joel > >>> > >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: > >>>> Agree with Med. > >>>> > >>>> Even if each fragment piece of a packet with NSH header carries > >>>> the NSH > >> header, the intermediate SFF nodes still need to put together all > >> the fragments together before passing the whole data frame to the > >> SF. > >>>> > >>>> Linda > >>>> > >>>> -----Original Message----- From: sfc > >>>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>> mohamed.boucadair@orange.com Sent: Monday, April 25, 2016 9:42 > >>>> AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org Subject: Re: > >>>> [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> Re-, > >>>> > >>>> How do you instruct the transport layer to ALWAYS prepend an > >>>> NSH header > >> even for fragments? Or you don't care about that? > >>>> > >>>> Thank you. > >>>> > >>>> Cheers, Med > >>>> > >>>>> -----Message d'origine----- De : Elzur, Uri > >>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril 2016 > >>>>> 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; > >>>>> sfc@ietf.org Objet : RE: [sfc] WG last call for > >>>>> draft-ietf-sfc-nsh-04.txt > >>>>> > >>>>> Hi Med > >>>>> > >>>>> Not to repeat my position, but I'll do it anyhow :-) As NSH > >>>>> is *NOT* a transport, dealing with fragmentation is left to > >>>>> the Transport used. > >>>>> > >>>>> The model I use for NSH, is basically similar to VXLAN . It > >>>>> is an > >> overly. > >>>>> > >>>>> Thx > >>>>> > >>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>> > >>>>> > >>>>> -----Original Message----- From: sfc > >>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>> mohamed.boucadair@orange.com Sent: Monday, April 25, 2016 > >>>>> 7:18 AM To: Joel M. Halpern ; > >>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for > >>>>> draft-ietf-sfc-nsh-04.txt > >>>>> > >>>>> Hi Joel, > >>>>> > >>>>> Please see inline. > >>>>> > >>>>> Cheers, Med > >>>>> > >>>>>> -----Message d'origine----- De : Joel M. Halpern > >>>>>> [mailto:jmh@joelhalpern.com] Envoy=E9 : lundi 25 avril 2016 > >>>>>> 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : > >>>>>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>> > >>>>>> If I am understanding you correctly Med, you are asking > >>>>>> that the NSH draft specify how service chaining should cope > >>>>>> with packets that have been fragmented? > >>>>>> > >>>>> > >>>>> [Med] To be accurate, I'm asking to assess whether there are > >> implications. > >>>>> If there are, then the draft should be updated accordingly. > >>>>> > >>>>>> NSH, and the SFF functionality, does not care. > >>>>> > >>>>> [Med] I'm not that sure. Some typical implications are listed > >>>>> below: > >>>>> > >>>>> * SFF: If the NSH header is present only in the a fragment > >>>>> but SFF didn't maintained a state, subsequent fragments won't > >>>>> be appropriately > >> processed. > >>>>> * SFC-aware function: if prepending a context information > >>>>> depends on the full packet, not only a fragment. > >>>>> > >>>>> It just does its job. > >>>>> > >>>>> [Med] which may be disturbed in some situations as listed in > >>>>> the examples above. > >>>>> > >>>>>> Ingress and intermediate classifiers may cope with > >>>>>> fragments in any number of ways. > >>>>> Specifying such is clearly out of scope for this draft. > >>>>> > >>>>> [Med] The purpose is not to specify the internal > >>>>> implementation details but the external behavior of the > >>>>> classifier function when it comes to handle fragments. That > >>>>> behavior may have an incidence on SFF, in particular. The > >>>>> purpose is not to recommend the maximum resources to be > >>>>> dedicated to out of order fragments nor the timeout to cache > >>>>> those; these considerations are of course out of scope. > >>>>> Nevertheless, an implementation should offer a configurable > >>>>> parameter so that an operator tweak those according to its > >>>>> context. > >>>>> > >>>>>> I suppose one could write an informational draft on > >>>>>> possible ways of coping. The IETF has not usually > >>>>>> published such. Service functions have to cope with > >>>>>> fragmented packets just as they had to before the advent of > >>>>>> NSH, so describing that is clearly not needed here. > >>>>> > >>>>> [Med] The advent of NSH has the following implications: * it > >>>>> exacerbates fragmentation. Handing over this issue to the > >>>>> transport layer may lead to interoperability issues. * the > >>>>> chaining may not be efficient if fragments are > >>>>> inappropriately handled. > >>>>> > >>>>> Introducing NSH should not degrade the overall service > >>>>> compared to legacy service deployment schemes. > >>>>> > >>>>>> > >>>>>> Yours, Joel > >>>>>> > >>>>>> On 4/25/16 3:00 AM, mohamed.boucadair@orange.com wrote: > >>>>>>> Re-, > >>>>>>> > >>>>>>> I hear you, but my comment is that we need, as a WG, to > >>>>>>> decide what to > >>>>>> put in the draft. FWIW, I'm discussing two fragmentation > >>>>>> issues: > >>>>>>> > >>>>>>> (1) Fragmentation that is caused by prepending an SFC > >>>>>>> header. (2) Handling fragments at the ingress of an > >>>>>>> SFC-enabled domain. > >>>>>>> > >>>>>>> Increasing the MTU is for sure a recommendation is to be > >>>>>>> explicitly > >>>>>> called out in the text (see my first message). > >>>>>>> > >>>>>>> There are other issues that need to be discussed, e.g., > >>>>>>> how to deal with > >>>>>> fragments in SFFs/Classifiers? > >>>>>>> > >>>>>>> It is also "prudent" to check that no issues will be > >>>>>>> experienced in SFF > >>>>>> to handle fragments. If an SFC header is prepended for all > >>>>>> fragments, I'm not sure there > >>>>>>> is any particular issue at the SFF level, except if > >>>>>>> stripping/adding > >>>>>> context TLVs depends on the full packet (not just > >>>>>> fragment). It is warranted to consider a little bit this > >>>>>> point before declaring there is no issue. > >>>>>>> > >>>>>>> For point (1), declaring fragmentation out of scope would > >>>>>>> be meant that > >>>>>> an implementation must be prepared to receive fragments > >>>>>> with or without NSH header as this is a decision that is > >>>>>> left to the transport encapsulation. This is a requirement > >>>>>> per se! > >>>>>>> > >>>>>>> I won't reiterate all the comments I have about the > >>>>>>> current wording of > >>>>>> this section. > >>>>>>> > >>>>>>> Cheers, Med > >>>>>>> > >>>>>>>> -----Message d'origine----- De : Elzur, Uri > >>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : lundi 25 avril > >>>>>>>> 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas > >>>>>>>> Narten; sfc@ietf.org Objet : RE: [sfc] WG last call > >>>>>>>> for draft-ietf-sfc-nsh-04.txt > >>>>>>>> > >>>>>>>> Hi Med > >>>>>>>> > >>>>>>>> My point is that Fragmentation is yet another transport > >>>>>>>> related issue > >>>>>> that > >>>>>>>> is beyond the scope of NSH and beyond the charter of > >>>>>>>> the WG, so it > >>>>>> doesn't > >>>>>>>> really belong in the draft. We are providing an advice > >>>>>>>> as extending the size of the packet may lead to > >>>>>>>> fragmentation, but as you check RFC 7348 VxLAN, which > >>>>>>>> my create the same issue, you'll find it doesn't even > >>>>>> relate > >>>>>>>> to it. > >>>>>>>> > >>>>>>>> Thx > >>>>>>>> > >>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- From: sfc > >>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>>>>> mohamed.boucadair@orange.com Sent: Sunday, April 24, > >>>>>>>> 2016 10:32 PM To: Elzur, Uri ; > >>>>>>>> Thomas Narten > >>>>>> ; > >>>>>>>> sfc@ietf.org Subject: Re: [sfc] WG last call for > >>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>> > >>>>>>>> Hi Uri, > >>>>>>>> > >>>>>>>> That's another option that needs to be > >>>>>>>> discussed/investigated. I'm > >>>>>> afraid > >>>>>>>> this is not the rationale adopted in -04 since it > >>>>>>>> includes some text > >>>>>> that > >>>>>>>> is far to be sufficient to ensure interoperable > >>>>>>>> implementations. > >>>>>>>> > >>>>>>>> BTW, saying that nsh does not need to deal with > >>>>>>>> fragmentation because > >>>>>> it > >>>>>>>> is transport-independent is not IMHO a good strategy to > >>>>>>>> adopt here > >>>>>> because > >>>>>>>> it opens the door for interoperable issues, it may lead > >>>>>>>> to sub-optimal implementations if the sfc information > >>>>>>>> is present only in one > >>>>>> fragments, > >>>>>>>> etc. > >>>>>>>> > >>>>>>>> My comments are related to the current text in the -04. > >>>>>>>> This text needs > >>>>>> to > >>>>>>>> be fixed somehow. > >>>>>>>> > >>>>>>>> Cheers, Med > >>>>>>>> > >>>>>>>>> -----Message d'origine----- De : Elzur, Uri > >>>>>>>>> [mailto:uri.elzur@intel.com] Envoy=E9 : dimanche 24 > >>>>>>>>> avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; > >>>>>>>>> Thomas Narten; sfc@ietf.org Objet : RE: [sfc] WG last > >>>>>>>>> call for draft-ietf-sfc-nsh-04.txt > >>>>>>>>> > >>>>>>>>> Hi Med > >>>>>>>>> > >>>>>>>>> I see no need to specify the exact behavior as NSH is > >>>>>>>>> transport independent i.e. like NSH interaction with > >>>>>>>>> any other Transport eh issue of Fragmentation is to > >>>>>>>>> be dealt in a way that matches the mechanisms > >>>>>>>>> supported by the Transport used and do not belong in > >>>>>>>>> the NSH draft > >>>>>>>>> > >>>>>>>>> Thx > >>>>>>>>> > >>>>>>>>> Uri ("Oo-Ree") C: 949-378-7568 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -----Original Message----- From: sfc > >>>>>>>>> [mailto:sfc-bounces@ietf.org] On Behalf Of > >>>>>>>>> mohamed.boucadair@orange.com Sent: Thursday, April > >>>>>>>>> 14, 2016 12:43 AM To: Thomas Narten > >>>>>>>>> ; sfc@ietf.org Subject: Re: [sfc] > >>>>>>>>> WG last call for draft-ietf-sfc-nsh-04.txt > >>>>>>>>> > >>>>>>>>> R-, > >>>>>>>>> > >>>>>>>>> In addition to other pending issues raised for this > >>>>>>>>> draft, I would like to raise this additional one > >>>>>>>>> about Section 6. > >>>>>>>>> > >>>>>>>>> =3D=3D 6. Fragmentation Considerations > >>>>>>>>> > >>>>>>>>> NSH and the associated transport header are "added" > >>>>>>>>> to the encapsulated packet/frame. This additional > >>>>>>>>> information increases > >>>>>> the > >>>>>>>>> size of the packet. In order the ensure proper > >>>>>>>>> forwarding of > >> NSH > >>>>>>>>> data, several options for handling fragmentation and > >>>>>>>>> re- > >> assembly > >>>>>>>>> exist: > >>>>>>>>> > >>>>>>>>> 1. Jumbo Frames, when supported, enable the > >>>>>>>>> transport of NSH > >> and > >>>>>>>>> associated transport packets without requiring > >> fragmentation. > >>>>>>>>> > >>>>>>>>> 2. Path MTU Discovery [RFC1191]"describes a > >>>>>>>>> technique for dynamically discovering the maximum > >>>>>>>>> transmission unit (MTU) of > >>>>>> an > >>>>>>>>> arbitrary internet path" and can be utilized to > >>>>>>>>> ensure the > >>>>> the > >>>>>>>>> required packet size is used. > >>>>>>>>> > >>>>>>>>> 3. [RFC6830] describes two schemes for fragmentation > >>>>>>>>> and re- > >>>>>> assembly > >>>>>>>>> in section 5.4. =3D=3D > >>>>>>>>> > >>>>>>>>> * The text is weak for a Standard track document that > >>>>>>>>> is intended to solve the problem in > >>>>>>>>> https://tools.ietf.org/html/rfc7498#section- > >>>>> 2.12. > >>>>>>>>> There should be a clear behavior to be followed by > >>>>>>>>> an > >>>>> implementation. > >>>>>>>>> Further, I would avoid the use of words such as > >>>>>>>>> "can". > >>>>>>>>> > >>>>>>>>> * The text covers only fragmentation when it is > >>>>>>>>> induced by SFC operations, it does not discuss the > >>>>>>>>> treatment of a fragment when received in an SFC > >>>>>>>>> domain. IMHO, the draft should also specify the > >>>>>>>>> behavior of the Classifier with regards to fragments > >>>>>>>>> for the sake of proper SFC operation. Applying > >>>>>>>>> classification policies may require the > >>>>>>>> full packet, not only a fragment. > >>>>>>>>> In particular, dedicated resources should dedicated > >>>>>>>>> for handling out of order fragments. Of course, it is > >>>>>>>>> out of scope of this document to describe how SFs > >>>>>>>>> handle fragments. > >>>>>>>>> > >>>>>>>>> * If an SFC header is prepended for all fragments, > >>>>>>>>> I'm not sure there is any particular issue at the SFF > >>>>>>>>> level...except if stripping/adding context TLVs > >>>>>>>>> depends on the full packet (not just fragment). It is > >>>>>>>>> warranted to consider a little bit this point before > >>>>>>>>> declaring there > >>>>>> is > >>>>>>>> no issue. > >>>>>>>>> > >>>>>>>>> * The text states "several options". This may be > >>>>>>>>> interpreted as if implementing one of them is > >>>>>>>>> sufficient...which is not true. The first two points > >>>>>>>>> contribute to minimize the fragmentation risk, but > >>>>>>>>> fragmentation may still be experienced (e.g., other > >>>>>>>>> shims are prepended by other nodes for some other > >>>>>>>>> purposes, nested nsh, etc.) > >>>>>>>>> > >>>>>>>>> * The first two points have nothing to do with > >>>>>>>>> reassembly. > >>>>>>>>> > >>>>>>>>> * The support of jumbo frames by a router/device does > >>>>>>>>> not mean that it can make use of it. Appropriate MTU > >>>>>>>>> configuration should be undertaken in a consistent > >>>>>>>>> manner within an SFC domain. The text should be > >>>>>>>>> updated to make it is about (consistent) MTU > >>>>> configuration. > >>>>>>>>> > >>>>>>>>> * BTW, shouldn't the text be reworded to recommended > >>>>>>>>> to increase the MTU of **all nodes** of an > >>>>>>>>> SFC-enabled domain by at least the length of SFC > >>>>>>>>> header + transport header? > >>>>>>>>> > >>>>>>>>> * Bullet 2, how PMTU discovery is actually used in > >>>>>>>>> this context? Do you assume that all SFC-aware nodes > >>>>>>>>> will issue such messages towards other SFC-aware > >>>>>>>>> node, arbitrary destination, else? > >>>>>>>>> > >>>>>>>>> * Bullet 2, I would drop "describes a technique for > >>>>>>>>> dynamically discovering the maximum transmission unit > >>>>>>>>> (MTU) of an arbitrary internet path". > >>>>>>>>> > >>>>>>>>> * Bullet 2, s/ the the/the. > >>>>>>>>> > >>>>>>>>> * The reference to the LISP specification raises two > >>>>>>>>> concerns and one comment: > >>>>>>>>> > >>>>>>>>> (1) I don't think it is a good approach that > >>>>>>>>> fragments induced by the network are passed to their > >>>>>>>>> ultimate destinations as such > >>>>> (stateless). > >>>>>>>>> IMO, reassembly should be done within the SFC domain > >>>>>>>>> (responsible for fragmentation) not passed away. (2) > >>>>>>>>> Does the stateful mode require all SFC data plane > >>>>>>>>> elements maintain a full list of MTU for the any > >>>>>>>>> SFF/SF instance of the SFC > >>>>>>>> domain? > >>>>>>>>> > >>>>>>>>> The current text suggests that [RFC6830] should be > >>>>>>>>> listed as normative reference (not an informative > >>>>>>>>> one). I would personally favor removing the reference > >>>>>>>>> to LISP (as it is an Experimental > >> RFC). > >>>>>>>>> > >>>>>>>>> * The security section of the draft may be augmented > >>>>>>>>> with informational fragmentation-related pointers to: > >>>>>>>>> e.g., RFC1858 (Security Considerations for IP > >>>>>>>>> Fragment Filtering), RFC3128 (Protection Against a > >>>>>>>>> Variant of the Tiny Fragment Attack), and RFC 4963 > >>>>>>>>> (IPv4 Reassembly Errors at High Data Rates). > >>>>>>>>> > >>>>>>>>> Cheers, Med > >>>>>>>>> > >>>>>>>>>> -----Message d'origine----- De : sfc > >>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de > >>>>>>>>>> mohamed.boucadair@orange.com Envoy=E9 : lundi 11 > >>>>>>>>>> avril 2016 13:14 =C0 > >> : > >>>>>>>>>> Thomas Narten; sfc@ietf.org Objet : Re: [sfc] WG > >>>>>>>>>> last call for draft-ietf-sfc-nsh-04.txt > >>>>>>>>>> > >>>>>>>>>> Dear Thomas, all, > >>>>>>>>>> > >>>>>>>>>> As I mentioned during the meeting, there are > >>>>>>>>>> several issues that are not covered in the last > >>>>>>>>>> version of the draft. I already provided examples > >>>>>>>>>> of the issues offline as requested by Martin. > >>>>>>>>>> > >>>>>>>>>> Cheers, Med > >>>>>>>>>> > >>>>>>>>>>> -----Message d'origine----- De : sfc > >>>>>>>>>>> [mailto:sfc-bounces@ietf.org] De la part de > >>>>>>>>>>> Thomas Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 > >>>>>>>>>>> : sfc@ietf.org Objet : [sfc] WG last call for > >>>>>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>>>>> > >>>>>>>>>>> Dear WG: > >>>>>>>>>>> > >>>>>>>>>>> This note begins a WG last call on > >>>>>>>>>>> draft-ietf-sfc-nsh-04.txt > >>>>>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > The editors of the NSH document have indicated that they have > >>>>>>>>>>> addressed all known comments and that there are > >>>>>>>>>>> no open issues with the current version of the > >>>>>>>>>>> document. > >>>>>>>>>>> > >>>>>>>>>>> Substantive comments to the list please, > >>>>>>>>>>> editorial comments can go directly to the > >>>>>>>>>>> document editors. > >>>>>>>>>>> > >>>>>>>>>>> We'll also get a brief update from the editors at > >>>>>>>>>>> next week's meeting. If there are any remaining > >>>>>>>>>>> issues with the document, raising them before the > >>>>>>>>>>> meeting would be especially helpful. > >>>>>>>>>>> > >>>>>>>>>>> For the chairs, Thomas > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> sfc mailing list sfc@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ sfc > >>>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>>> > >>>>>>>>> _______________________________________________ sfc > >>>>>>>>> mailing list sfc@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>>> > >>>>>>>> _______________________________________________ sfc > >>>>>>>> mailing list sfc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>>>> _______________________________________________ sfc > >>>>>>> mailing list sfc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>>>> > >>>>> > >>>>> _______________________________________________ sfc mailing > >>>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>>> _______________________________________________ sfc mailing > >>>> list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>>> > >>> > >>> _______________________________________________ sfc mailing list > >>> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc > >>> > > From nobody Thu Apr 28 05:17: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 08DE412B05C for ; Thu, 28 Apr 2016 05:17:50 -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 vMeTBEoMrcq6 for ; Thu, 28 Apr 2016 05:17:44 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F2612D0A2 for ; Thu, 28 Apr 2016 05:17:44 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id x201so81155654oif.3 for ; Thu, 28 Apr 2016 05:17:44 -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=JHC8PIDzIxjmmu2gmsng1f4KAHfQ9zVHaYG1N/EVjqM=; b=PlmumaLcOUiiOXv+ftBZd4w96DyekP05k3C+YQpkKLkLTxqEKxMt32UDrBOCXzbiL1 rhHJDruR648FGX6CKCYtB3A7cw5MiVLcgaH27oNX9Vz2aAHyTOOIjNKER5d9vuje8tpT LUo67YOZ8blAggk4IMFsf0ZH/JwFNLo0ApiT4grUfhwIgZQQXwhP7vaTm8pT8H1NntI7 YeBZ/gO1e/Seg+cwXN+eXv9Js15iQXgjADA7Nx4pQlvI5lrxJpwPaX20bm6OC8nvB0OR okEn+oWLufa4ZV6RBkaZJLoqUVkiz3uVHFthEKUNnh4NisFChbD4OlDK9DKe0ZWsUfKe AKKw== 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=JHC8PIDzIxjmmu2gmsng1f4KAHfQ9zVHaYG1N/EVjqM=; b=AE4oiI8FGd2+t5yEfbxdAFDl7d1AN+nLr8z9cjIz1qrPn8SVDosBLOI0YuPtH7+MKx Ve3WQb4oJcZwYJ5GK3hr3T7KrIZzkfrTCAuAb5HVsGXefadTSfkyYyJsaWCW76XNLqZM GfuMyBHaZF08UzrS4bo47hbX4MHcMmaSRvlDTDCuxIXDwWowdaA0McNpPXvxCQhJjbJK +uzWD8YHgWXujnFH2rUQXY7bm9mSgXjgSwXwY2d0OlOwwsHJi4q1lCTpmfjIn/OAeL4X CdIcfcvOzkPWgrqGfBMXMaFYxuL+sHv5h3K1o7VCIwPA62rkkbSldi4oyyrmUrBhY0U0 Z9yg== X-Gm-Message-State: AOPr4FUYQo+lBCNZu3cPpmTv3vvlLkb0aM71qNFwPs9UzF41yDmUiTBsTmZSSsHQPslDghZCzaprNXCypJllMQ== X-Received: by 10.157.13.227 with SMTP id 90mr6904856ots.79.1461845863565; Thu, 28 Apr 2016 05:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Thu, 28 Apr 2016 05:17:24 -0700 (PDT) In-Reply-To: <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 28 Apr 2016 08:17:24 -0400 Message-ID: To: Joel Halpern Direct Content-Type: multipart/alternative; boundary=94eb2c1100146a10f205318a831a Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 12:17:50 -0000 --94eb2c1100146a10f205318a831a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joel, The diagrams in section 6 of RFC 6830 are control plane, not data plane. The data plane diagrams are in section 5. But the overriding question is - without any fields in the NSH header to sequence fragments, how can the fragments be correctly reassembled? Cheers, Andy On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct < jmh.direct@joelhalpern.com> wrote: > The LISP header does not have a fragment flag or fragment offset. The > diagrams in section 6 include the outer encapsulating header (the > equivalent of the transport header in SFC.) Yes, the text is a little ha= rd > to follow in this regard. The LISP working group is going to be rewritin= g > RFC 6830 as part of moving to standards track. > > So there is no difference in this regard between NSH and LISP. > > Yours, > Joel > > On 4/27/16 7:02 PM, Andrew G. Malis wrote: > >> Joel et al, >> >> All this talk about fragmentation prompted me to re-read section 6 of >> the draft, which recommends (as option 3) using the procedures in >> section 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80= =9D replacing the >> =E2=80=9CLISP header=E2=80=9D in the description of the procedures in th= at section). >> >> So that led me to read that section (and the LISP header definition in >> section 5.1), and I see that LISP does fragmentation and reassembly >> identically to IPv4, using the Fragment Offset field so that fragments >> can be correctly reassembled in the proper order. >> >> However, the NSH Header doesn=E2=80=99t have a Fragment Offset field or = any >> other way to order the fragments. >> >> So how can the procedures in Section 5.4 of 6830 be used? >> >> Thanks, >> Andy >> >> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern > > wrote: >> >> Both methods are valid, and both depend upon details of the >> underlying packet and the transport. As such, I don't see why this >> document benefits from describing them, much less why it should mark >> one method as a "should". Implementation details are likely to be >> more significant than any bit consumption difference between the two >> alternatives. >> >> Yours, >> Joel >> >> >> On 4/27/16 3:40 PM, Linda Dunbar wrote: >> >> I suggest adding the following paragraphs after the Bullet 3 of >> the Section 6 Fragmentation Consideration to make the process >> more clear and less controversial: >> >> >> -------------------------------- >> >> RFC6830 describes the fragmentation method of breaking the >> original packet into two equal sub-frames and encapsulating >> [LISP Header + Transport header] to each sub-frame. >> >> If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC >> Header + Transport Header] will be added to each half frame (or >> the original data frame). As the Transport Header is terminated >> by the next SFF node's tunnel transport layer, the combined two >> sub-frames will have two SFC Headers. >> >> Therefore, the fragmentation for NSH encapsulated data frame >> should be done completely by the node tunnel transport layer, >> which should break the [SFC + original packet] into two equal >> sub-frames and each sub-frame being encapsulated with its >> respective tunnel header. The next SFF node's tunnel transport >> layer should combine the two sub-frames before sending to the >> next node. >> >> ------------------------------------------------------ >> >> >> By the way, there are to typo in the Section 6: >> 3rd line: "In order the" =3D=3D> "In order to" >> Last line of Bullet 2: extra "the" in the "utilized to ensure >> the the required packet". >> >> >> Hope it helps. >> >> Linda >> >> >> >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> >> [mailto:mohamed.boucadair@orange.com >> ] >> Sent: Wednesday, April 27, 2016 12:40 AM >> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org >> >> Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, all, >> >> Please see inline. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com >> ] Envoy=C3=A9 : mardi 26 >> avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed >> IMT/OLN; Elzur, >> Uri; sfc@ietf.org Objet : Re: [sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, that seems >> an issue >> for the transport protocol. I don't actually object to a >> sentence, >> but it does not seem that it will accomplish anything. >> >> >> [Med] I would like to see some text added to the draft. >> >> >> With regard to packets fragmented by the source, I >> completely disagree >> with your assertion. If an SFF were to reassemble the >> packets, that >> would be a violation of its job. >> >> >> [Med] I agree with you. >> >> There is no reason for an SFF to >> >> reassemble a packet fragmented by the source. The >> classifier may have >> to do some interesting things in order to properly classify >> succeeding >> fragments, but that is an implementation issue (most commonl= y >> addressed with virtual reassembly, which doe snot delay the >> fragments.) We don't specity that. >> >> >> [Med] Still, the external behavior of the classifier needs to be >> clear in the document. I don't find any text in the draft saying >> for instance that an NSH header must be present in all >> fragments. (There some processing that might be needed at the >> SFF to "do its job" with regards to fragments (receive out of >> order fragments + forwarding policy on the full packet).) >> >> >> If an SF needs to reassemble fragments to do its job, that >> is up to >> the SF. Some will need to actually reassemble. Some will >> need to >> perform virtual reassembly, and some will happily process th= e >> fragments. I can not see what the NSH document could >> possibly mandate. >> >> >> [Med] Fully agree. >> >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >> >> Joel, >> >> I think the document should add the description on the >> following two >> fragmentation scenarios: >> >> - Transport tunnel generated fragmentation: When a packe= t >> fragmentation is caused by transport tunnel (i.e. variou= s >> encapsulations), the termination point of the transport >> tunnel is >> responsible for re-assembling the fragmented pieces of >> the packet. >> Since there won't be any SFF nodes in between the >> Transport Tunnel, >> the tunnel generated fragmentation does not require any >> actions by >> SFF nodes or SF nodes. >> >> >> - Source node generated fragmentation (after adding on >> the NSH >> header): When fragmentation has to be performed for a >> packet being >> encapsulated with the NSH header, either the >> intermediate SFF nodes >> or the SF nodes have to be able to reassemble the >> fragmented pieces. >> >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com >> ] Sent: Tuesday, April 26, >> 2016 10:33 AM >> To: Linda Dunbar; mohamed.boucadair@orange.com >> ; Elzur, Uri; >> sfc@ietf.org Subject: Re: [sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that you are >> referring only to >> the case of transport generated fragmentation of the >> outer packet. >> I had assumed you were not talking about that, since the >> resulting >> fragments will not all have NSH headers. As with any >> tunnel >> technology, if the tunnel chooses to fragment at its >> layer, then the >> tunnel is responsible for reassembly. That would be >> invisible to >> the SFF. >> >> Yours, Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >> >> Agree with Med. >> >> Even if each fragment piece of a packet with NSH >> header carries the >> NSH header, the intermediate SFF nodes still need to >> put together >> all the fragments together before passing the whole >> data frame to >> the SF. >> >> Linda >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> ] >> On Behalf Of mohamed.boucadair@orange.com >> Sent: Monday, >> April 25, >> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; >> sfc@ietf.org Subject: >> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer to ALWAYS >> prepend an NSH >> header even for fragments? Or you don't care about >> that? >> >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : Elzur, Uri >> [mailto:uri.elzur@intel.com >> ] Envoy=C3=A9 : lund= i 25 >> avril 2016 16:26 =C3=80 >> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >> sfc@ietf.org Objet >> : RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do it anyhow >> :-) As NSH is >> *NOT* a transport, dealing with fragmentation is >> left to the >> Transport used. >> >> The model I use for NSH, is basically similar to >> VXLAN . It is an >> overly. >> >> Thx >> >> Uri ("Oo-Ree") C: 949-378-7568 >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> ] >> On Behalf Of mohamed.boucadair@orange.com >> Sent: >> Monday, April 25, >> 2016 7:18 AM To: Joel M. Halpern >> > >>; >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, Med >> >> -----Message d'origine----- De : Joel M. >> Halpern >> [mailto:jmh@joelhalpern.com >> ] Envoy=C3=A9 : = lundi >> 25 avril 2016 15:48 =C3=80 >> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >> Objet : Re: [sfc] WG >> last call for draft-ietf-sfc-nsh-04.txt >> >> If I am understanding you correctly Med, you >> are asking that the >> NSH draft specify how service chaining >> should cope with packets >> that have been fragmented? >> >> >> [Med] To be accurate, I'm asking to assess >> whether there are >> implications. If there are, then the draft >> should be updated >> accordingly. >> >> NSH, and the SFF functionality, does not car= e. >> >> >> [Med] I'm not that sure. Some typical >> implications are listed >> below: >> >> * SFF: If the NSH header is present only in the >> a fragment but SFF >> didn't maintained a state, subsequent fragments >> won't be >> appropriately processed. * SFC-aware function: >> if prepending a >> context information depends on the full packet, >> not only a >> fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some situations >> as listed in the >> examples above. >> >> Ingress and intermediate classifiers may >> cope with fragments in >> any number of ways. >> >> Specifying such is clearly out of scope for this >> draft. >> >> [Med] The purpose is not to specify the internal >> implementation >> details but the external behavior of the >> classifier function when >> it comes to handle fragments. That behavior may >> have an incidence >> on SFF, in particular. The purpose is not to >> recommend the maximum >> resources to be dedicated to out of order >> fragments nor the >> timeout to cache those; these considerations are >> of course out of >> scope. Nevertheless, an implementation should >> offer a configurable >> parameter so that an operator tweak those >> according to its >> context. >> >> I suppose one could write an informational >> draft on possible ways >> of coping. The IETF has not usually >> published such. >> Service functions have to cope with >> fragmented packets just as >> they had to before the advent of NSH, so >> describing that is >> clearly not needed here. >> >> >> [Med] The advent of NSH has the following >> implications: * it >> exacerbates fragmentation. Handing over this >> issue to the >> transport layer may lead to interoperability >> issues. * the >> chaining may not be efficient if fragments are >> inappropriately >> handled. >> >> Introducing NSH should not degrade the overall >> service compared to >> legacy service deployment schemes. >> >> >> Yours, Joel >> >> On 4/25/16 3:00 AM, >> mohamed.boucadair@orange.com >> wrote: >> >> Re-, >> >> I hear you, but my comment is that we >> need, as a WG, to decide >> what to >> >> put in the draft. FWIW, I'm discussing two >> fragmentation >> issues: >> >> >> (1) Fragmentation that is caused by >> prepending an SFC header. >> (2) Handling fragments at the ingress of >> an SFC-enabled domain. >> >> Increasing the MTU is for sure a >> recommendation is to be >> explicitly >> >> called out in the text (see my first message= ). >> >> >> There are other issues that need to be >> discussed, e.g., how to >> deal with >> >> fragments in SFFs/Classifiers? >> >> >> It is also "prudent" to check that no >> issues will be experienced >> in SFF >> >> to handle fragments. If an SFC header is >> prepended for all >> fragments, I'm not sure there >> >> is any particular issue at the SFF >> level, except if >> stripping/adding >> >> context TLVs depends on the full packet (not >> just fragment). It >> is warranted to consider a little bit this >> point before declaring >> there is no issue. >> >> >> For point (1), declaring fragmentation >> out of scope would be >> meant that >> >> an implementation must be prepared to >> receive fragments with or >> without NSH header as this is a decision >> that is left to the >> transport encapsulation. This is a >> requirement per se! >> >> >> I won't reiterate all the comments I >> have about the current >> wording of >> >> this section. >> >> >> Cheers, Med >> >> -----Message d'origine----- De : >> Elzur, Uri >> [mailto:uri.elzur@intel.com >> ] Envoy= =C3=A9 >> : lundi 25 avril 2016 >> 08:30 =C3=80 : BOUCADAIR Mohamed IMT= /OLN; >> Thomas Narten; >> sfc@ietf.org >> Objet : RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> My point is that Fragmentation is >> yet another transport related >> issue >> >> that >> >> is beyond the scope of NSH and >> beyond the charter of the WG, so >> it >> >> doesn't >> >> really belong in the draft. We are >> providing an advice as >> extending the size of the packet may >> lead to fragmentation, but >> as you check RFC 7348 VxLAN, which >> my create the same issue, >> you'll find it doesn't even >> >> relate >> >> to it. >> >> Thx >> >> Uri ("Oo-Ree") C: 949-378-7568 >> >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> ] On >> Behalf Of >> mohamed.boucadair@orange.com >> >> Sent: >> Sunday, April 24, 2016 >> 10:32 PM To: Elzur, Uri >> > >; >> Thomas Narten >> >> > >>; >> >> sfc@ietf.org >> Subject: Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Uri, >> >> That's another option that needs to >> be discussed/investigated. >> I'm >> >> afraid >> >> this is not the rationale adopted in >> -04 since it includes some >> text >> >> that >> >> is far to be sufficient to ensure >> interoperable >> implementations. >> >> BTW, saying that nsh does not need >> to deal with fragmentation >> because >> >> it >> >> is transport-independent is not IMHO >> a good strategy to adopt >> here >> >> because >> >> it opens the door for interoperable >> issues, it may lead to >> sub-optimal implementations if the >> sfc information is present >> only in one >> >> fragments, >> >> etc. >> >> My comments are related to the >> current text in the -04. >> This text needs >> >> to >> >> be fixed somehow. >> >> Cheers, Med >> >> -----Message d'origine----- De : >> Elzur, Uri >> [mailto:uri.elzur@intel.com >> ] >> Envoy=C3=A9 : dimanche 24 avril >> 2016 17:36 =C3=80 : BOUCADAIR Mo= hamed >> IMT/OLN; Thomas Narten; >> sfc@ietf.org >> Objet : >> RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> I see no need to specify the >> exact behavior as NSH is >> transport independent i.e. like >> NSH interaction with any other >> Transport eh issue of >> Fragmentation is to be dealt in >> a way >> that matches the mechanisms >> supported by the Transport used >> and do not belong in the NSH dra= ft >> >> Thx >> >> Uri ("Oo-Ree") C: 949-378-7568 >> >> >> >> -----Original Message----- From: >> sfc >> [mailto:sfc-bounces@ietf.org >> ] >> On Behalf Of >> mohamed.boucadair@orange.com >> > mohamed.boucadair@orange.com> >> Sent: Thursday, April 14, >> 2016 12:43 AM To: Thomas Narten >> > >; >> sfc@ietf.org >> Subject: >> Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> R-, >> >> In addition to other pending >> issues raised for this draft, I >> would like to raise this >> additional one about Section 6. >> >> =3D=3D 6. Fragmentation >> Considerations >> >> NSH and the associated transport >> header are "added" to the >> encapsulated packet/frame. This >> additional information >> increases >> >> the >> >> size of the packet. In order >> the ensure proper forwarding of >> NSH data, several options for >> handling fragmentation and >> re-assembly exist: >> >> 1. Jumbo Frames, when >> supported, enable the transport >> of NSH >> and associated transport packets >> without requiring >> fragmentation. >> >> 2. Path MTU Discovery >> [RFC1191]"describes a technique >> for >> dynamically discovering the >> maximum transmission unit (MTU) = of >> >> an >> >> arbitrary internet path" and can >> be utilized to ensure the >> >> the >> >> required packet size is used. >> >> 3. [RFC6830] describes two >> schemes for fragmentation and >> re- >> >> assembly >> >> in section 5.4. =3D=3D >> >> * The text is weak for a >> Standard track document that is >> intended to solve the problem in >> >> https://tools.ietf.org/html/rfc7498#section- >> >> 2.12. >> >> There should be a clear behavior >> to be followed by an >> >> implementation. >> >> Further, I would avoid the use >> of words such as "can". >> >> * The text covers only >> fragmentation when it is induced >> by SFC >> operations, it does not discuss >> the treatment of a fragment >> when received in an SFC domain. >> IMHO, the draft should also >> specify the behavior of the >> Classifier with regards to >> fragments for the sake of proper >> SFC operation. Applying >> classification policies may >> require the >> >> full packet, not only a fragment. >> >> In particular, dedicated >> resources should dedicated for >> handling out of order fragments. >> Of course, it is out of scope >> of this document to describe how >> SFs handle fragments. >> >> * If an SFC header is prepended >> for all fragments, I'm not >> sure there is any particular >> issue at the SFF level...except >> if stripping/adding context TLVs >> depends on the full packet >> (not just fragment). It is >> warranted to consider a little b= it >> this point before declaring ther= e >> >> is >> >> no issue. >> >> >> * The text states "several >> options". This may be interprete= d >> as if implementing one of them >> is sufficient...which is not >> true. The first two points >> contribute to minimize the >> fragmentation risk, but >> fragmentation may still be >> experienced >> (e.g., other shims are prepended >> by other nodes for some other >> purposes, nested nsh, etc.) >> >> * The first two points have >> nothing to do with reassembly. >> >> * The support of jumbo frames by >> a router/device does not mean >> that it can make use of it. >> Appropriate MTU configuration >> should be undertaken in a >> consistent manner within an SFC >> domain. The text should be >> updated to make it is about >> (consistent) MTU >> >> configuration. >> >> >> * BTW, shouldn't the text be >> reworded to recommended to >> increase the MTU of **all >> nodes** of an SFC-enabled domain >> by >> at least the length of SFC >> header + transport header? >> >> * Bullet 2, how PMTU discovery >> is actually used in this >> context? Do you assume that all >> SFC-aware nodes will issue >> such messages towards other >> SFC-aware node, arbitrary >> destination, else? >> >> * Bullet 2, I would drop >> "describes a technique for >> dynamically discovering the >> maximum transmission unit >> (MTU) of an arbitrary internet >> path". >> >> * Bullet 2, s/ the the/the. >> >> * The reference to the LISP >> specification raises two concern= s >> and one comment: >> >> (1) I don't think it is a good >> approach that fragments induced >> by the network are passed to >> their ultimate destinations as >> such >> >> (stateless). >> >> IMO, reassembly should be done >> within the SFC domain >> (responsible for fragmentation) >> not passed away. (2) Does the >> stateful mode require all SFC >> data plane elements maintain a >> full list of MTU for the any >> SFF/SF instance of the SFC >> >> domain? >> >> >> The current text suggests that >> [RFC6830] should be listed as >> normative reference (not an >> informative one). I would >> personally favor removing the >> reference to LISP (as it is an >> Experimental RFC). >> >> * The security section of the >> draft may be augmented with >> informational >> fragmentation-related pointers t= o: >> e.g., RFC1858 (Security >> Considerations for IP Fragment >> Filtering), RFC3128 (Protection >> Against a Variant of the Tiny >> Fragment Attack), and RFC 4963 >> (IPv4 Reassembly Errors at High >> Data Rates). >> >> Cheers, Med >> >> -----Message d'origine----- >> De : sfc >> [mailto:sfc-bounces@ietf.org >> > >] >> De la part de >> mohamed.boucadair@orange.com >> > mohamed.boucadair@orange.com> >> Envoy=C3=A9 : lundi 11 avril >> 2016 13:14 =C3=80 : Thomas >> Narten; sfc@ietf.org >> Objet >> : Re: >> [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Dear Thomas, all, >> >> As I mentioned during the >> meeting, there are several >> issues >> that are not covered in the >> last version of the draft. I >> already provided examples of >> the issues offline as >> requested >> by Martin. >> >> Cheers, Med >> >> -----Message >> d'origine----- De : sfc >> [mailto: >> sfc-bounces@ietf.org >> > sfc-bounces@ietf.org>] >> De la part de Thomas >> Narten >> Envoy=C3=A9 : jeudi 31 m= ars >> 2016 04:48 =C3=80 : >> sfc@ietf.org >> >> Objet : [sfc] WG last >> call for >> draft-ietf-sfc-nsh-04.tx= t >> >> Dear WG: >> >> This note begins a WG >> last call on >> draft-ietf-sfc-nsh-04.tx= t >> ( >> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >> >> >> >> The editors of the NSH document have indicated that they hav= e >> >> addressed all known >> comments and that there >> are no open >> issues with the current >> version of the document. >> >> Substantive comments to >> the list please, >> editorial comments >> can go directly to the >> document editors. >> >> We'll also get a brief >> update from the editors >> at next >> week's meeting. If there >> are any remaining issues >> with the >> document, raising them >> before the meeting would >> be >> especially helpful. >> >> For the chairs, Thomas >> >> >> _______________________________________________ >> sfc mailing >> list sfc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing >> list sfc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing >> list sfc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing > > --94eb2c1100146a10f205318a831a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+Sm9lbCw8ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBkaWFncmFtcyBpbiBz ZWN0aW9uIDYgb2YgUkZDIDY4MzAgYXJlIGNvbnRyb2wgcGxhbmUsIG5vdCBkYXRhIHBsYW5lLiBU aGUgZGF0YSBwbGFuZSBkaWFncmFtcyBhcmUgaW4gc2VjdGlvbiA1LjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+QnV0IHRoZSBvdmVycmlkaW5nIHF1ZXN0aW9uIGlzIC0gd2l0aG91dCBhbnkgZmll bGRzIGluIHRoZSBOU0ggaGVhZGVyIHRvIHNlcXVlbmNlIGZyYWdtZW50cywgaG93IGNhbiB0aGUg ZnJhZ21lbnRzIGJlIGNvcnJlY3RseSByZWFzc2VtYmxlZD88L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PkNoZWVycyw8L2Rpdj48ZGl2PkFuZHk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgQXByIDI3LCAy MDE2IGF0IDc6NDYgUE0sIEpvZWwgSGFscGVybiBEaXJlY3QgPHNwYW4gZGlyPSJsdHIiPiZsdDs8 YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5r Ij5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+VGhlIExJU1AgaGVhZGVy IGRvZXMgbm90IGhhdmUgYSBmcmFnbWVudCBmbGFnIG9yIGZyYWdtZW50IG9mZnNldC7CoCBUaGUg ZGlhZ3JhbXMgaW4gc2VjdGlvbiA2IGluY2x1ZGUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpbmcgaGVh ZGVyICh0aGUgZXF1aXZhbGVudCBvZiB0aGUgdHJhbnNwb3J0IGhlYWRlciBpbiBTRkMuKcKgIFll cywgdGhlIHRleHQgaXMgYSBsaXR0bGUgaGFyZCB0byBmb2xsb3cgaW4gdGhpcyByZWdhcmQuwqAg VGhlIExJU1Agd29ya2luZyBncm91cCBpcyBnb2luZyB0byBiZSByZXdyaXRpbmcgUkZDIDY4MzAg YXMgcGFydCBvZiBtb3ZpbmcgdG8gc3RhbmRhcmRzIHRyYWNrLjxicj4NCjxicj4NClNvIHRoZXJl IGlzIG5vIGRpZmZlcmVuY2UgaW4gdGhpcyByZWdhcmQgYmV0d2VlbiBOU0ggYW5kIExJU1AuPGJy Pg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxicj4NCk9uIDQvMjcvMTYgNzowMiBQTSwg QW5kcmV3IEcuIE1hbGlzIHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPg0KSm9lbCBldCBhbCw8YnI+DQo8YnI+DQpBbGwgdGhpcyB0YWxrIGFi b3V0IGZyYWdtZW50YXRpb24gcHJvbXB0ZWQgbWUgdG8gcmUtcmVhZCBzZWN0aW9uIDYgb2Y8YnI+ DQp0aGUgZHJhZnQsIHdoaWNoIHJlY29tbWVuZHMgKGFzIG9wdGlvbiAzKSB1c2luZyB0aGUgcHJv Y2VkdXJlcyBpbjxicj4NCnNlY3Rpb24gNS40IG9mIFJGQyA2ODMwIChwcmVzdW1hYmx5IHdpdGgg dGhlIOKAnE5TSCBoZWFkZXLigJ0gcmVwbGFjaW5nIHRoZTxicj4NCuKAnExJU1AgaGVhZGVy4oCd IGluIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2VkdXJlcyBpbiB0aGF0IHNlY3Rpb24pLjxi cj4NCjxicj4NClNvIHRoYXQgbGVkIG1lIHRvIHJlYWQgdGhhdCBzZWN0aW9uIChhbmQgdGhlIExJ U1AgaGVhZGVyIGRlZmluaXRpb24gaW48YnI+DQpzZWN0aW9uIDUuMSksIGFuZCBJIHNlZSB0aGF0 IExJU1AgZG9lcyBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2VtYmx5PGJyPg0KaWRlbnRpY2FsbHkg dG8gSVB2NCwgdXNpbmcgdGhlIEZyYWdtZW50IE9mZnNldCBmaWVsZCBzbyB0aGF0IGZyYWdtZW50 czxicj4NCmNhbiBiZSBjb3JyZWN0bHkgcmVhc3NlbWJsZWQgaW4gdGhlIHByb3BlciBvcmRlci48 YnI+DQo8YnI+DQpIb3dldmVyLCB0aGUgTlNIIEhlYWRlciBkb2VzbuKAmXQgaGF2ZSBhIEZyYWdt ZW50IE9mZnNldCBmaWVsZCBvciBhbnk8YnI+DQpvdGhlciB3YXkgdG8gb3JkZXIgdGhlIGZyYWdt ZW50cy48YnI+DQo8YnI+DQpTbyBob3cgY2FuIHRoZSBwcm9jZWR1cmVzIGluIFNlY3Rpb24gNS40 IG9mIDY4MzAgYmUgdXNlZD88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KQW5keTxicj4NCjxicj4N Ck9uIFdlZCwgQXByIDI3LCAyMDE2IGF0IDQ6MTkgUE0sIEpvZWwgTS4gSGFscGVybiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPjxicj4NCiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsm Z3Q7IHdyb3RlOjxicj4NCjxicj4NCsKgIMKgIEJvdGggbWV0aG9kcyBhcmUgdmFsaWQsIGFuZCBi b3RoIGRlcGVuZCB1cG9uIGRldGFpbHMgb2YgdGhlPGJyPg0KwqAgwqAgdW5kZXJseWluZyBwYWNr ZXQgYW5kIHRoZSB0cmFuc3BvcnQuwqAgQXMgc3VjaCwgSSBkb24mIzM5O3Qgc2VlIHdoeSB0aGlz PGJyPg0KwqAgwqAgZG9jdW1lbnQgYmVuZWZpdHMgZnJvbSBkZXNjcmliaW5nIHRoZW0sIG11Y2gg bGVzcyB3aHkgaXQgc2hvdWxkIG1hcms8YnI+DQrCoCDCoCBvbmUgbWV0aG9kIGFzIGEgJnF1b3Q7 c2hvdWxkJnF1b3Q7LsKgIEltcGxlbWVudGF0aW9uIGRldGFpbHMgYXJlIGxpa2VseSB0byBiZTxi cj4NCsKgIMKgIG1vcmUgc2lnbmlmaWNhbnQgdGhhbiBhbnkgYml0IGNvbnN1bXB0aW9uIGRpZmZl cmVuY2UgYmV0d2VlbiB0aGUgdHdvPGJyPg0KwqAgwqAgYWx0ZXJuYXRpdmVzLjxicj4NCjxicj4N CsKgIMKgIFlvdXJzLDxicj4NCsKgIMKgIEpvZWw8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCBPbiA0 LzI3LzE2IDM6NDAgUE0sIExpbmRhIER1bmJhciB3cm90ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCBJIHN1Z2dlc3QgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBocyBhZnRlciB0aGUgQnVs bGV0IDMgb2Y8YnI+DQrCoCDCoCDCoCDCoCB0aGUgU2VjdGlvbiA2IEZyYWdtZW50YXRpb24gQ29u c2lkZXJhdGlvbiB0byBtYWtlIHRoZSBwcm9jZXNzPGJyPg0KwqAgwqAgwqAgwqAgbW9yZSBjbGVh ciBhbmQgbGVzcyBjb250cm92ZXJzaWFsOjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgUkZD NjgzMCBkZXNjcmliZXMgdGhlIGZyYWdtZW50YXRpb24gbWV0aG9kIG9mIGJyZWFraW5nIHRoZTxi cj4NCsKgIMKgIMKgIMKgIG9yaWdpbmFsIHBhY2tldCBpbnRvIHR3byBlcXVhbCBzdWItZnJhbWVz IGFuZCBlbmNhcHN1bGF0aW5nPGJyPg0KwqAgwqAgwqAgwqAgW0xJU1AgSGVhZGVyICsgVHJhbnNw b3J0IGhlYWRlcl0gdG8gZWFjaCBzdWItZnJhbWUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgSWYg TElTUCBmcmFnbWVudGF0aW9uIFtSRkM2ODMwIFNlY3Rpb24gNS40XSBpcyB1c2VkLCB0aGUgW1NG Qzxicj4NCsKgIMKgIMKgIMKgIEhlYWRlciArIFRyYW5zcG9ydCBIZWFkZXJdIHdpbGwgYmUgYWRk ZWQgdG8gZWFjaCBoYWxmIGZyYW1lIChvcjxicj4NCsKgIMKgIMKgIMKgIHRoZSBvcmlnaW5hbCBk YXRhIGZyYW1lKS4gQXMgdGhlIFRyYW5zcG9ydCBIZWFkZXIgaXMgdGVybWluYXRlZDxicj4NCsKg IMKgIMKgIMKgIGJ5IHRoZSBuZXh0IFNGRiBub2RlJiMzOTtzIHR1bm5lbCB0cmFuc3BvcnQgbGF5 ZXIsIHRoZSBjb21iaW5lZCB0d288YnI+DQrCoCDCoCDCoCDCoCBzdWItZnJhbWVzIHdpbGwgaGF2 ZSB0d28gU0ZDIEhlYWRlcnMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgVGhlcmVmb3JlLCB0aGUg ZnJhZ21lbnRhdGlvbiBmb3IgTlNIIGVuY2Fwc3VsYXRlZCBkYXRhIGZyYW1lPGJyPg0KwqAgwqAg wqAgwqAgc2hvdWxkIGJlIGRvbmUgY29tcGxldGVseSBieSB0aGUgbm9kZSB0dW5uZWwgdHJhbnNw b3J0IGxheWVyLDxicj4NCsKgIMKgIMKgIMKgIHdoaWNoIHNob3VsZCBicmVhayB0aGUgW1NGQyAr IG9yaWdpbmFsIHBhY2tldF0gaW50byB0d28gZXF1YWw8YnI+DQrCoCDCoCDCoCDCoCBzdWItZnJh bWVzIGFuZCBlYWNoIHN1Yi1mcmFtZSBiZWluZyBlbmNhcHN1bGF0ZWQgd2l0aCBpdHM8YnI+DQrC oCDCoCDCoCDCoCByZXNwZWN0aXZlIHR1bm5lbCBoZWFkZXIuwqAgVGhlIG5leHQgU0ZGIG5vZGUm IzM5O3MgdHVubmVsIHRyYW5zcG9ydDxicj4NCsKgIMKgIMKgIMKgIGxheWVyIHNob3VsZCBjb21i aW5lIHRoZSB0d28gc3ViLWZyYW1lcyBiZWZvcmUgc2VuZGluZyB0byB0aGU8YnI+DQrCoCDCoCDC oCDCoCBuZXh0IG5vZGUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgQnkgdGhlIHdheSwgdGhlcmUgYXJlIHRvIHR5cG8gaW4gdGhlIFNlY3Rpb24gNjo8 YnI+DQrCoCDCoCDCoCDCoCAzcmQgbGluZTogJnF1b3Q7SW4gb3JkZXIgdGhlJnF1b3Q7ID09Jmd0 OyAmcXVvdDtJbiBvcmRlciB0byZxdW90Ozxicj4NCsKgIMKgIMKgIMKgIExhc3QgbGluZSBvZiBC dWxsZXQgMjogZXh0cmEgJnF1b3Q7dGhlJnF1b3Q7IGluIHRoZSAmcXVvdDt1dGlsaXplZCB0byBl bnN1cmU8YnI+DQrCoCDCoCDCoCDCoCB0aGUgdGhlIHJlcXVpcmVkIHBhY2tldCZxdW90Oy48YnI+ DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBIb3BlIGl0IGhlbHBzLjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIExpbmRhPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQrCoCDCoCDCoCDCoCBGcm9tOiA8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKg ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i IHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDtdPGJy Pg0KwqAgwqAgwqAgwqAgU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNywgMjAxNiAxMjo0MCBBTTxi cj4NCsKgIMKgIMKgIMKgIFRvOiBKb2VsIE0uIEhhbHBlcm47IExpbmRhIER1bmJhcjsgRWx6dXIs IFVyaTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0Bp ZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKg IMKgIMKgIMKgIFN1YmplY3Q6IFJFOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYt c2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBIaSBKb2VsLCBhbGwsPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgUGxlYXNlIHNlZSBpbmxpbmUuPGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgQ2hlZXJzLDxicj4NCsKgIMKgIMKgIMKgIE1lZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS08YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCBEZSA6IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT48YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7XSBFbnZv ecOpIDogbWFyZGkgMjY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBhdnJpbCAyMDE2IDE5OjE4IMOA IDogTGluZGEgRHVuYmFyOyBCT1VDQURBSVIgTW9oYW1lZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IElNVC9PTE47IEVsenVyLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIFVyaTsgPGEgaHJlZj0ibWFp bHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGll dGYub3JnPC9hPiZndDsgT2JqZXQgOiBSZTogW3NmY10gV0c8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNo LTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIFdpdGggcmVnYXJkIHRvIFRyYW5z cG9ydCB0dW5uZWwgZnJhZ2VtZW50YXRpb24sIHRoYXQgc2VlbXM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCBhbiBpc3N1ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGZvciB0aGUgdHJhbnNwb3J0IHBy b3RvY29sLsKgIEkgZG9uJiMzOTt0IGFjdHVhbGx5IG9iamVjdCB0byBhPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgc2VudGVuY2UsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgYnV0IGl0IGRvZXMgbm90 IHNlZW0gdGhhdCBpdCB3aWxsIGFjY29tcGxpc2ggYW55dGhpbmcuPGJyPg0KPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgW01lZF0gSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIHRleHQgYWRkZWQgdG8g dGhlIGRyYWZ0Ljxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIFdpdGggcmVnYXJk IHRvIHBhY2tldHMgZnJhZ21lbnRlZCBieSB0aGUgc291cmNlLCBJPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgY29tcGxldGVseSBkaXNhZ3JlZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHdpdGggeW91 ciBhc3NlcnRpb24uwqAgSWYgYW4gU0ZGIHdlcmUgdG8gcmVhc3NlbWJsZSB0aGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCBwYWNrZXRzLCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgd291bGQg YmUgYSB2aW9sYXRpb24gb2YgaXRzIGpvYi48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBb TWVkXSBJIGFncmVlIHdpdGggeW91Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIFRoZXJlIGlz IG5vIHJlYXNvbiBmb3IgYW4gU0ZGIHRvPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgcmVh c3NlbWJsZSBhIHBhY2tldCBmcmFnbWVudGVkIGJ5IHRoZSBzb3VyY2UuwqAgVGhlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgY2xhc3NpZmllciBtYXkgaGF2ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IHRvIGRvIHNvbWUgaW50ZXJlc3RpbmcgdGhpbmdzIGluIG9yZGVyIHRvIHByb3Blcmx5IGNsYXNz aWZ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgc3VjY2VlZGluZzxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIGZyYWdtZW50cywgYnV0IHRoYXQgaXMgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUgKG1vc3Qg Y29tbW9ubHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBhZGRyZXNzZWQgd2l0aCB2aXJ0dWFsIHJl YXNzZW1ibHksIHdoaWNoIGRvZSBzbm90IGRlbGF5IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IGZyYWdtZW50cy4pwqAgV2UgZG9uJiMzOTt0IHNwZWNpdHkgdGhhdC48YnI+DQo8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCBbTWVkXSBTdGlsbCwgdGhlIGV4dGVybmFsIGJlaGF2aW9yIG9mIHRoZSBj bGFzc2lmaWVyIG5lZWRzIHRvIGJlPGJyPg0KwqAgwqAgwqAgwqAgY2xlYXIgaW4gdGhlIGRvY3Vt ZW50LiBJIGRvbiYjMzk7dCBmaW5kIGFueSB0ZXh0IGluIHRoZSBkcmFmdCBzYXlpbmc8YnI+DQrC oCDCoCDCoCDCoCBmb3IgaW5zdGFuY2UgdGhhdCBhbiBOU0ggaGVhZGVyIG11c3QgYmUgcHJlc2Vu dCBpbiBhbGw8YnI+DQrCoCDCoCDCoCDCoCBmcmFnbWVudHMuIChUaGVyZSBzb21lIHByb2Nlc3Np bmcgdGhhdCBtaWdodCBiZSBuZWVkZWQgYXQgdGhlPGJyPg0KwqAgwqAgwqAgwqAgU0ZGIHRvICZx dW90O2RvIGl0cyBqb2ImcXVvdDsgd2l0aCByZWdhcmRzIHRvIGZyYWdtZW50cyAocmVjZWl2ZSBv dXQgb2Y8YnI+DQrCoCDCoCDCoCDCoCBvcmRlciBmcmFnbWVudHMgKyBmb3J3YXJkaW5nIHBvbGlj eSBvbiB0aGUgZnVsbCBwYWNrZXQpLik8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCBJZiBhbiBTRiBuZWVkcyB0byByZWFzc2VtYmxlIGZyYWdtZW50cyB0byBkbyBpdHMgam9iLCB0 aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgaXMgdXAgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCB0aGUgU0YuwqAgU29tZSB3aWxsIG5lZWQgdG8gYWN0dWFsbHkgcmVhc3NlbWJsZS7CoCBTb21l IHdpbGw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBuZWVkIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgcGVyZm9ybSB2aXJ0dWFsIHJlYXNzZW1ibHksIGFuZCBzb21lIHdpbGwgaGFwcGlseSBwcm9j ZXNzIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50cy7CoCBJIGNhbiBub3Qgc2Vl IHdoYXQgdGhlIE5TSCBkb2N1bWVudCBjb3VsZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHBvc3Np Ymx5IG1hbmRhdGUuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgW01lZF0gRnVsbHkgYWdy ZWUuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgWW91cnMsPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgSm9lbDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIE9uIDQvMjYvMTYg MTE6NDcgQU0sIExpbmRhIER1bmJhciB3cm90ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBKb2VsLDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgdGhpbmsg dGhlIGRvY3VtZW50IHNob3VsZCBhZGQgdGhlIGRlc2NyaXB0aW9uIG9uIHRoZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGZvbGxvd2luZyB0d288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBmcmFnbWVudGF0aW9uIHNjZW5hcmlvczo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAtIFRyYW5zcG9ydCB0dW5uZWwgZ2VuZXJhdGVkIGZyYWdtZW50YXRpb246IFdoZW4g YSBwYWNrZXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudGF0aW9uIGlzIGNh dXNlZCBieSB0cmFuc3BvcnQgdHVubmVsIChpLmUuIHZhcmlvdXM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBlbmNhcHN1bGF0aW9ucyksIHRoZSB0ZXJtaW5hdGlvbiBwb2ludCBvZiB0aGUg dHJhbnNwb3J0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHVubmVsIGlzPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVzcG9uc2libGUgZm9yIHJlLWFzc2VtYmxpbmcgdGhlIGZy YWdtZW50ZWQgcGllY2VzIG9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIHBhY2tl dC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTaW5jZSB0aGVyZSB3b24mIzM5O3QgYmUg YW55IFNGRiBub2RlcyBpbiBiZXR3ZWVuIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFRyYW5zcG9ydCBUdW5uZWwsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIHR1bm5l bCBnZW5lcmF0ZWQgZnJhZ21lbnRhdGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGFjdGlvbnMgYnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBTRkYgbm9kZXMgb3IgU0Ygbm9kZXMuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgLSBTb3VyY2Ugbm9kZSBnZW5lcmF0ZWQgZnJhZ21lbnRhdGlvbiAoYWZ0ZXIgYWRk aW5nIG9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIE5TSDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGhlYWRlcik6IFdoZW4gZnJhZ21lbnRhdGlvbiBoYXMgdG8gYmUgcGVy Zm9ybWVkIGZvciBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGFja2V0IGJlaW5nPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZW5jYXBzdWxhdGVkIHdpdGggdGhlIE5TSCBoZWFk ZXIsIGVpdGhlciB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbnRlcm1lZGlhdGUg U0ZGIG5vZGVzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3IgdGhlIFNGIG5vZGVzIGhh dmUgdG8gYmUgYWJsZSB0byByZWFzc2VtYmxlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGZyYWdtZW50ZWQgcGllY2VzLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIENoZWVycyw8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBMaW5kYTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEpvZWwgTS4gSGFscGVybjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDtdIFNlbnQ6 IFR1ZXNkYXksIEFwcmlsIDI2LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDIwMTYgMTA6 MzMgQU08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUbzogTGluZGEgRHVuYmFyOyA8YSBo cmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0 OzsgRWx6dXIsIFVyaTs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0 Zi5vcmc8L2E+Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gV0c8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQt aWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJl LXJlYWRpbmcgeW91ciBub3RlLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHlvdSBhcmU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCByZWZlcnJpbmcgb25seSB0bzxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHRoZSBjYXNlIG9mIHRyYW5zcG9ydCBnZW5lcmF0ZWQgZnJhZ21lbnRhdGlvbiBv ZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvdXRlciBwYWNrZXQuPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBoYWQgYXNzdW1lZCB5b3Ugd2VyZSBub3QgdGFsa2luZyBh Ym91dCB0aGF0LCBzaW5jZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXN1bHRp bmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMgd2lsbCBub3QgYWxsIGhh dmUgTlNIIGhlYWRlcnMuwqAgQXMgd2l0aCBhbnkgdHVubmVsPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgdGVjaG5vbG9neSwgaWYgdGhlIHR1bm5lbCBjaG9vc2VzIHRvIGZyYWdtZW50IGF0 IGl0czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxheWVyLCB0aGVuIHRoZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHR1bm5lbCBpcyByZXNwb25zaWJsZSBmb3IgcmVhc3NlbWJs eS7CoCBUaGF0IHdvdWxkIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW52aXNpYmxl IHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIFNGRi48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBZb3VycywgSm9lbDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE9uIDQvMjYvMTYgMTE6MTAgQU0sIExpbmRhIER1bmJhciB3cm90ZTo8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBZ3JlZSB3aXRoIE1lZC48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFdmVuIGlmIGVhY2ggZnJhZ21lbnQg cGllY2Ugb2YgYSBwYWNrZXQgd2l0aCBOU0g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBoZWFkZXIgY2FycmllcyB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBOU0ggaGVhZGVyLCB0aGUgaW50ZXJtZWRpYXRlIFNGRiBub2RlcyBzdGlsbCBuZWVkIHRvPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHV0IHRvZ2V0aGVyPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWxsIHRoZSBmcmFnbWVudHMgdG9nZXRoZXIgYmVmb3Jl IHBhc3NpbmcgdGhlIHdob2xlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGF0 YSBmcmFtZSB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBTRi48YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBMaW5kYTxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZy b206IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE9uIEJlaGFsZiBPZiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyBTZW50OiBNb25kYXksPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXByaWwgMjUsPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgMjAxNiA5OjQyIEFNIFRvOiBFbHp1ciwgVXJpOyBKb2VsIE0uIEhhbHBl cm47PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNm Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3Jn PC9hPiZndDsgU3ViamVjdDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZTog W3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUmUtLDxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhvdyBkbyB5b3UgaW5zdHJ1Y3QgdGhlIHRyYW5zcG9ydCBs YXllciB0byBBTFdBWVM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcmVwZW5k IGFuIE5TSDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlYWRlciBldmVuIGZv ciBmcmFnbWVudHM/IE9yIHlvdSBkb24mIzM5O3QgY2FyZSBhYm91dCB0aGF0Pzxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoYW5rIHlvdS48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0t LS0gRGUgOiBFbHp1ciwgVXJpPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVs LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+Jmd0O10gRW52b3nD qSA6IGx1bmRpIDI1PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXZy aWwgMjAxNiAxNjoyNiDDgDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgSm9lbCBNLiBIYWxwZXJuOzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 IE9iamV0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBSRTogW3Nm Y10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBNZWQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBOb3QgdG8gcmVwZWF0IG15IHBvc2l0aW9uLCBidXQgSSYjMzk7bGwg ZG8gaXQgYW55aG93PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOi0p IEFzIE5TSCBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICpOT1Qq IGEgdHJhbnNwb3J0LCBkZWFsaW5nIHdpdGggZnJhZ21lbnRhdGlvbiBpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxlZnQgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVHJhbnNwb3J0IHVzZWQuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlIG1vZGVsIEkgdXNlIGZvciBOU0gsIGlz IGJhc2ljYWxseSBzaW1pbGFyIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgVlhMQU4gLiBJdCBpcyBhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG92ZXJseS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBUaHg8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBV cmkgKCZxdW90O09vLVJlZSZxdW90OykgQzogPGEgaHJlZj0idGVsOjk0OS0zNzgtNzU2OCIgdmFs dWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPjk0OS0zNzgtNzU2ODwvYT4gJmx0O3Rl bDo8YSBocmVmPSJ0ZWw6OTQ5LTM3OC03NTY4IiB2YWx1ZT0iKzE5NDkzNzg3NTY4IiB0YXJnZXQ9 Il9ibGFuayI+OTQ5LTM3OC03NTY4PC9hPiZndDs8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9t OiBzZmM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1i b3VuY2VzQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O108YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiBCZWhhbGYgT2YgPGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsg U2VudDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBNb25kYXksIEFw cmlsIDI1LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDIwMTYgNzox OCBBTSBUbzogSm9lbCBNLiBIYWxwZXJuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9 Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5j b208L2E+Jmd0OyZndDs7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBTdWJqZWN0OiBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBKb2VsLDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFBsZWFzZSBzZWUg aW5saW5lLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENo ZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgLS0tLS1NZXNzYWdlIGQmIzM5O29yaWdpbmUtLS0tLSBEZSA6IEpvZWwgTS4gSGFscGVy bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDtdIEVudm95w6kgOiBs dW5kaTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDI1IGF2 cmlsIDIwMTYgMTU6NDggw4A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsgT2Jq ZXQgOiBSZTogW3NmY10gV0c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJZiBJIGFtIHVuZGVy c3RhbmRpbmcgeW91IGNvcnJlY3RseSBNZWQsIHlvdTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZSBhc2tpbmcgdGhhdCB0aGU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggZHJhZnQgc3BlY2lmeSBob3cgc2Vy dmljZSBjaGFpbmluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHNob3VsZCBjb3BlIHdpdGggcGFja2V0czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaGF2ZSBiZWVuIGZyYWdtZW50ZWQ/PGJyPg0KPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gVG8gYmUgYWNj dXJhdGUsIEkmIzM5O20gYXNraW5nIHRvIGFzc2Vzczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHdoZXRoZXIgdGhlcmUgYXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaW1wbGljYXRpb25zLiBJZiB0aGVyZSBhcmUsIHRoZW4gdGhlIGRy YWZ0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2hvdWxkIGJlIHVw ZGF0ZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhY2NvcmRpbmds eS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBO U0gsIGFuZCB0aGUgU0ZGIGZ1bmN0aW9uYWxpdHksIGRvZXMgbm90IGNhcmUuPGJyPg0KPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gSSYjMzk7bSBu b3QgdGhhdCBzdXJlLiBTb21lIHR5cGljYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpbXBsaWNhdGlvbnMgYXJlIGxpc3RlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGJlbG93Ojxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICogU0ZGOiBJZiB0aGUgTlNIIGhlYWRlciBpcyBwcmVzZW50IG9ubHkg aW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSBmcmFnbWVu dCBidXQgU0ZGPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGlkbiYj Mzk7dCBtYWludGFpbmVkIGEgc3RhdGUsIHN1YnNlcXVlbnQgZnJhZ21lbnRzPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd29uJiMzOTt0IGJlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXBwcm9wcmlhdGVseSBwcm9jZXNzZWQuICogU0ZD LWF3YXJlIGZ1bmN0aW9uOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGlmIHByZXBlbmRpbmcgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGNvbnRleHQgaW5mb3JtYXRpb24gZGVwZW5kcyBvbiB0aGUgZnVsbCBwYWNrZXQsPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbm90IG9ubHkgYTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50Ljxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEl0IGp1c3QgZG9lcyBpdHMgam9iLjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtNZWRdIHdoaWNoIG1heSBi ZSBkaXN0dXJiZWQgaW4gc29tZSBzaXR1YXRpb25zPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYXMgbGlzdGVkIGluIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGV4YW1wbGVzIGFib3ZlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEluZ3Jlc3MgYW5kIGludGVybWVkaWF0ZSBjbGFz c2lmaWVycyBtYXk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBjb3BlIHdpdGggZnJhZ21lbnRzIGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYW55IG51bWJlciBvZiB3YXlzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNwZWNpZnlpbmcgc3VjaCBpcyBjbGVhcmx5IG91dCBv ZiBzY29wZSBmb3IgdGhpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGRyYWZ0Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtN ZWRdIFRoZSBwdXJwb3NlIGlzIG5vdCB0byBzcGVjaWZ5IHRoZSBpbnRlcm5hbDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGltcGxlbWVudGF0aW9uPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGV0YWlscyBidXQgdGhlIGV4dGVybmFsIGJl aGF2aW9yIG9mIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNs YXNzaWZpZXIgZnVuY3Rpb24gd2hlbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGl0IGNvbWVzIHRvIGhhbmRsZSBmcmFnbWVudHMuIFRoYXQgYmVoYXZpb3IgbWF5PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGF2ZSBhbiBpbmNpZGVuY2U8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvbiBTRkYsIGluIHBhcnRp Y3VsYXIuIFRoZSBwdXJwb3NlIGlzIG5vdCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHJlY29tbWVuZCB0aGUgbWF4aW11bTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHJlc291cmNlcyB0byBiZSBkZWRpY2F0ZWQgdG8gb3V0IG9mIG9y ZGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzIG5v ciB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aW1lb3V0IHRv IGNhY2hlIHRob3NlOyB0aGVzZSBjb25zaWRlcmF0aW9ucyBhcmU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiBjb3Vyc2Ugb3V0IG9mPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2NvcGUuIE5ldmVydGhlbGVzcywgYW4gaW1wbGVtZW50 YXRpb24gc2hvdWxkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2Zm ZXIgYSBjb25maWd1cmFibGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBwYXJhbWV0ZXIgc28gdGhhdCBhbiBvcGVyYXRvciB0d2VhayB0aG9zZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFjY29yZGluZyB0byBpdHM8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb250ZXh0Ljxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgc3VwcG9zZSBvbmUgY291bGQgd3Jp dGUgYW4gaW5mb3JtYXRpb25hbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGRyYWZ0IG9uIHBvc3NpYmxlIHdheXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiBjb3BpbmcuwqAgVGhlIElFVEYgaGFzIG5vdCB1c3Vh bGx5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHVibGlz aGVkIHN1Y2guPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg U2VydmljZSBmdW5jdGlvbnMgaGF2ZSB0byBjb3BlIHdpdGg8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudGVkIHBhY2tldHMganVzdCBhczxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZXkgaGFkIHRvIGJl Zm9yZSB0aGUgYWR2ZW50IG9mIE5TSCwgc288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBkZXNjcmliaW5nIHRoYXQgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjbGVhcmx5IG5vdCBuZWVkZWQgaGVyZS48YnI+DQo8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVkXSBUaGUg YWR2ZW50IG9mIE5TSCBoYXMgdGhlIGZvbGxvd2luZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGltcGxpY2F0aW9uczogKiBpdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGV4YWNlcmJhdGVzIGZyYWdtZW50YXRpb24uIEhhbmRpbmcgb3Zl ciB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWUgdG8g dGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJhbnNwb3J0IGxh eWVyIG1heSBsZWFkIHRvIGludGVyb3BlcmFiaWxpdHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMuICogdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgY2hhaW5pbmcgbWF5IG5vdCBiZSBlZmZpY2llbnQgaWYgZnJhZ21lbnRz IGFyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluYXBwcm9wcmlh dGVseTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhhbmRsZWQuPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSW50cm9kdWNpbmcg TlNIIHNob3VsZCBub3QgZGVncmFkZSB0aGUgb3ZlcmFsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZpY2UgY29tcGFyZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsZWdhY3kgc2VydmljZSBkZXBsb3ltZW50IHNjaGVtZXMu PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgWW91cnMsIEpvZWw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBPbiA0LzI1LzE2IDM6MDAgQU0sPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h Pjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUmUt LDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIEkgaGVhciB5b3UsIGJ1dCBteSBjb21tZW50IGlzIHRoYXQgd2U8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBuZWVkLCBhcyBhIFdHLCB0byBk ZWNpZGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB3aGF0IHRvPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgcHV0IGluIHRoZSBkcmFmdC4gRldJVywgSSYjMzk7bSBkaXNjdXNzaW5nIHR3bzxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50YXRpb248 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXM6PGJy Pg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgKDEpIEZyYWdtZW50YXRpb24gdGhhdCBpcyBjYXVzZWQgYnk8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcmVwZW5kaW5nIGFuIFNGQyBo ZWFkZXIuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKDIpIEhhbmRsaW5nIGZyYWdtZW50cyBhdCB0aGUgaW5ncmVzcyBvZjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuIFNGQy1lbmFibGVkIGRv bWFpbi48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBJbmNyZWFzaW5nIHRoZSBNVFUgaXMgZm9yIHN1cmUgYTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlY29tbWVuZGF0aW9uIGlzIHRv IGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg ZXhwbGljaXRseTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGNhbGxlZCBvdXQgaW4gdGhlIHRleHQgKHNlZSBteSBmaXJzdCBtZXNzYWdlKS48YnI+ DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBUaGVyZSBhcmUgb3RoZXIgaXNzdWVzIHRoYXQgbmVlZCB0byBiZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRpc2N1c3NlZCwgZS5nLiwg aG93IHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZGVhbCB3aXRoPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgZnJhZ21lbnRzIGluIFNGRnMvQ2xhc3NpZmllcnM/PGJyPg0KPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSXQgaXMgYWxz byAmcXVvdDtwcnVkZW50JnF1b3Q7IHRvIGNoZWNrIHRoYXQgbm88YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMgd2lsbCBiZSBleHBlcmll bmNlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGluIFNGRjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHRvIGhhbmRsZSBmcmFnbWVudHMuIElmIGFuIFNGQyBoZWFkZXIgaXM8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcmVwZW5kZWQgZm9yIGFsbDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50cywgSSYj Mzk7bSBub3Qgc3VyZSB0aGVyZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIGFueSBwYXJ0aWN1bGFyIGlzc3VlIGF0IHRoZSBTRkY8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsZXZl bCwgZXhjZXB0IGlmPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgc3RyaXBwaW5nL2FkZGluZzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnRleHQgVExWcyBkZXBlbmRzIG9uIHRoZSBmdWxsIHBh Y2tldCAobm90PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg anVzdCBmcmFnbWVudCkuIEl0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgaXMgd2FycmFudGVkIHRvIGNvbnNpZGVyIGEgbGl0dGxlIGJpdCB0aGlzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcG9pbnQgYmVmb3JlIGRl Y2xhcmluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRo ZXJlIGlzIG5vIGlzc3VlLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZvciBwb2ludCAoMSksIGRlY2xhcmluZyBmcmFnbWVu dGF0aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgb3V0IG9mIHNjb3BlIHdvdWxkIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgbWVhbnQgdGhhdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuIGltcGxlbWVudGF0aW9uIG11c3QgYmUgcHJl cGFyZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBy ZWNlaXZlIGZyYWdtZW50cyB3aXRoIG9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgd2l0aG91dCBOU0ggaGVhZGVyIGFzIHRoaXMgaXMgYSBkZWNpc2lvbjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaXMgbGVm dCB0byB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0 cmFuc3BvcnQgZW5jYXBzdWxhdGlvbi4gVGhpcyBpcyBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVxdWlyZW1lbnQgcGVyIHNlITxicj4NCjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgd29u JiMzOTt0IHJlaXRlcmF0ZSBhbGwgdGhlIGNvbW1lbnRzIEk8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYXZlIGFib3V0IHRoZSBjdXJyZW50PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd29yZGlu ZyBvZjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHRoaXMgc2VjdGlvbi48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tTWVzc2FnZSBk JiMzOTtvcmlnaW5lLS0tLS0gRGUgOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVsenVyLCBVcmk8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVs LmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT4mZ3Q7XSBFbnZvecOpPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg OiBsdW5kaSAyNSBhdnJpbCAyMDE2PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMDg6MzAgw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFRob21hcyBOYXJ0ZW47PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPYmpl dCA6IFJFOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4 dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIEhpIE1lZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE15IHBvaW50IGlzIHRoYXQgRnJhZ21lbnRhdGlvbiBp czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHlldCBhbm90aGVyIHRyYW5zcG9ydCByZWxhdGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWU8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXMgYmV5 b25kIHRoZSBzY29wZSBvZiBOU0ggYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmV5b25kIHRoZSBjaGFydGVyIG9mIHRoZSBXRywg c288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBpdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGRvZXNuJiMzOTt0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVhbGx5IGJlbG9uZyBpbiB0aGUgZHJhZnQuIFdlIGFy ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHByb3ZpZGluZyBhbiBhZHZpY2UgYXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleHRlbmRpbmcgdGhlIHNpemUgb2YgdGhlIHBh Y2tldCBtYXk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBsZWFkIHRvIGZyYWdtZW50YXRpb24sIGJ1dDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzIHlvdSBjaGVjayBSRkMg NzM0OCBWeExBTiwgd2hpY2g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBteSBjcmVhdGUgdGhlIHNhbWUgaXNzdWUsPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgeW91JiMzOTts bCBmaW5kIGl0IGRvZXNuJiMzOTt0IGV2ZW48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWxhdGU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBpdC48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaHg8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBVcmkgKCZxdW90O09vLVJlZSZxdW90OykgQzogPGEgaHJlZj0idGVsOjk0OS0zNzgt NzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPjk0OS0zNzgtNzU2ODwv YT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAmbHQ7dGVsOjxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0OTM3ODc1 NjgiIHRhcmdldD0iX2JsYW5rIj45NDktMzc4LTc1Njg8L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XSBPbjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJl aGFsZiBPZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IFNlbnQ6PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3Vu ZGF5LCBBcHJpbCAyNCwgMjAxNjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDEwOjMyIFBNIFRvOiBFbHp1ciwgVXJpPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0OzxhIGhy ZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVy QGludGVsLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50 ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT4mZ3Q7Jmd0Ozs8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBUaG9tYXMgTmFydGVuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0OzxhIGhyZWY9Im1haWx0bzpuYXJ0ZW5AdXMuaWJtLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm5hcnRlbkB1cy5pYm0uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpuYXJ0ZW5AdXMuaWJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5hcnRlbkB1cy5pYm0uY29tPC9h PiZndDsmZ3Q7Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3ViamVjdDog UmU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgSGkgVXJpLDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoYXQmIzM5O3MgYW5vdGhlciBvcHRpb24gdGhhdCBuZWVk cyB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGJlIGRpc2N1c3NlZC9pbnZlc3RpZ2F0ZWQuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSYjMzk7bTxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFmcmFpZDxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRo aXMgaXMgbm90IHRoZSByYXRpb25hbGUgYWRvcHRlZCBpbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0wNCBzaW5jZSBpdCBpbmNsdWRl cyBzb21lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgdGV4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHRoYXQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyBmYXIgdG8gYmUgc3VmZmljaWVudCB0byBlbnN1cmU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBpbnRlcm9wZXJhYmxlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50YXRpb25zLjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJUVywgc2F5aW5nIHRo YXQgbnNoIGRvZXMgbm90IG5lZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBkZWFsIHdpdGggZnJhZ21lbnRhdGlvbjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJlY2F1 c2U8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBp dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGlzIHRyYW5zcG9ydC1pbmRlcGVuZGVudCBpcyBub3QgSU1ITzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGEgZ29vZCBz dHJhdGVneSB0byBhZG9wdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGhlcmU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBiZWNhdXNlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQgb3BlbnMgdGhlIGRvb3IgZm9y IGludGVyb3BlcmFibGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMsIGl0IG1heSBsZWFkIHRvPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3ViLW9wdGltYWwgaW1w bGVtZW50YXRpb25zIGlmIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNmYyBpbmZvcm1hdGlvbiBpcyBwcmVzZW50PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb25seSBp biBvbmU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBmcmFnbWVudHMsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZXRjLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE15IGNvbW1lbnRzIGFyZSByZWxhdGVk IHRvIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGN1cnJlbnQgdGV4dCBpbiB0aGUgLTA0Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMgdGV4dCBuZWVkczxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRvPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYmUgZml4ZWQgc29tZWhvdy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0t LS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS0gRGUgOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVsenVyLCBVcmk8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVy QGludGVsLmNvbTwvYT4mZ3Q7XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVudm95w6kgOiBkaW1hbmNoZSAyNCBhdnJpbDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIDIwMTYgMTc6MzYgw4AgOiBCT1VDQURBSVIgTW9oYW1lZDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElNVC9PTE47 IFRob21hcyBOYXJ0ZW47PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0 OyBPYmpldCA6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgUkU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFm dC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSGkgTWVkPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg SSBzZWUgbm8gbmVlZCB0byBzcGVjaWZ5IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4YWN0IGJlaGF2aW9yIGFzIE5T SCBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHRyYW5zcG9ydCBpbmRlcGVuZGVudCBpLmUuIGxpa2U8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0gg aW50ZXJhY3Rpb24gd2l0aCBhbnkgb3RoZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUcmFuc3BvcnQgZWggaXNzdWUgb2Y8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBGcmFnbWVudGF0aW9uIGlzIHRvIGJlIGRlYWx0IGluPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSB3YXk8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0aGF0IG1hdGNoZXMgdGhlIG1lY2hhbmlzbXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdXBwb3J0ZWQgYnkgdGhl IFRyYW5zcG9ydCB1c2VkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIGRvIG5vdCBiZWxvbmcgaW4gdGhlIE5TSCBkcmFm dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFRoeDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFVyaSAoJnF1b3Q7T28tUmVlJnF1b3Q7 KSBDOiA8YSBocmVmPSJ0ZWw6OTQ5LTM3OC03NTY4IiB2YWx1ZT0iKzE5NDkzNzg3NTY4IiB0YXJn ZXQ9Il9ibGFuayI+OTQ5LTM3OC03NTY4PC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDt0ZWw6PGEgaHJlZj0idGVs Ojk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPjk0OS0z NzgtNzU2ODwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gRnJvbTogc2ZjPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtdPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gQmVo YWxmIE9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBTZW50OiBUaHVyc2RheSwgQXByaWwgMTQsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMjAxNiAxMjo0MyBBTSBU bzogVGhvbWFzIE5hcnRlbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmli bS5jb20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT48YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuYXJ0ZW5AdXMuaWJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm5hcnRlbkB1cy5pYm0uY29tPC9hPiZndDsmZ3Q7Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Zj QGlldGYub3JnPC9hPiZndDsgU3ViamVjdDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZTogW3NmY10gV0cgbGFzdCBjYWxs IGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSLSw8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBJbiBhZGRpdGlvbiB0byBvdGhlciBwZW5kaW5nPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVz IHJhaXNlZCBmb3IgdGhpcyBkcmFmdCwgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdvdWxkIGxpa2UgdG8gcmFpc2UgdGhp czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGFkZGl0aW9uYWwgb25lIGFib3V0IFNlY3Rpb24gNi48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA9 PSA2LsKgIEZyYWdtZW50YXRpb24gQ29uc2lkZXJhdGlvbnM8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggYW5k IHRoZSBhc3NvY2lhdGVkIHRyYW5zcG9ydDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlYWRlciBhcmUgJnF1b3Q7YWRkZWQm cXVvdDsgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZW5jYXBzdWxhdGVkIHBhY2tldC9mcmFtZS7CoCBUaGlzPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluY3JlYXNlczxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZTxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHNpemUgb2YgdGhlIHBhY2tldC7CoCBJbiBvcmRlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBlbnN1cmUgcHJv cGVyIGZvcndhcmRpbmcgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggZGF0YSwgc2V2ZXJhbCBvcHRpb25zIGZvcjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGhhbmRsaW5nIGZyYWdtZW50YXRpb24gYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmUtYXNzZW1ibHkgZXhp c3Q6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgMS7CoCBKdW1ibyBGcmFtZXMsIHdoZW48YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdXBwb3J0 ZWQsIGVuYWJsZSB0aGUgdHJhbnNwb3J0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgTlNIPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIGFzc29j aWF0ZWQgdHJhbnNwb3J0IHBhY2tldHM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aXRob3V0IHJlcXVpcmluZzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGZyYWdtZW50YXRpb24uPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMi7CoCBQYXRoIE1UVSBEaXNjb3Zlcnk8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBbUkZDMTE5MV0mcXVvdDtkZXNjcmliZXMgYSB0ZWNobmlxdWUgZm9yPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHlu YW1pY2FsbHkgZGlzY292ZXJpbmcgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbWF4aW11bSB0cmFuc21pc3Npb24gdW5p dCAoTVRVKSBvZjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGFuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXJiaXRyYXJ5IGludGVybmV0IHBhdGgmcXVvdDsgYW5k IGNhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGJlIHV0aWxpemVkIHRvIGVuc3VyZSB0aGU8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXF1aXJlZCBw YWNrZXQgc2l6ZSBpcyB1c2VkLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDMuwqAgW1JGQzY4MzBdIGRlc2NyaWJl cyB0d288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzY2hlbWVzIGZvciBmcmFnbWVudGF0aW9uIGFuZDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlLTxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzc2Vt Ymx5PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaW4gc2VjdGlvbiA1LjQuID09PGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBUaGUg dGV4dCBpcyB3ZWFrIGZvciBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQgdGhhdCBp czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGludGVuZGVkIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGluPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0OTgjc2VjdGlvbi0iIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 NDk4I3NlY3Rpb24tPC9hPjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIDIuMTIuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlcmUgc2hvdWxkIGJlIGEgY2xlYXIgYmVoYXZp b3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB0byBiZSBmb2xsb3dlZCBieSBhbjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGltcGxlbWVudGF0aW9uLjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZ1cnRo ZXIsIEkgd291bGQgYXZvaWQgdGhlIHVzZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9mIHdvcmRzIHN1Y2ggYXMgJnF1b3Q7 Y2FuJnF1b3Q7Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIHRleHQgY292ZXJzIG9ubHk8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBm cmFnbWVudGF0aW9uIHdoZW4gaXQgaXMgaW5kdWNlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJ5IFNGQzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9w ZXJhdGlvbnMsIGl0IGRvZXMgbm90IGRpc2N1c3M8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgdHJlYXRtZW50IG9mIGEg ZnJhZ21lbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB3aGVuIHJlY2VpdmVkIGluIGFuIFNGQyBkb21haW4uPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg SU1ITywgdGhlIGRyYWZ0IHNob3VsZCBhbHNvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3BlY2lmeSB0aGUgYmVoYXZpb3Ig b2YgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgQ2xhc3NpZmllciB3aXRoIHJlZ2FyZHMgdG88YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVu dHMgZm9yIHRoZSBzYWtlIG9mIHByb3Blcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNGQyBvcGVyYXRpb24uIEFwcGx5aW5n PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgY2xhc3NpZmljYXRpb24gcG9saWNpZXMgbWF5PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVxdWlyZSB0aGU8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBmdWxsIHBhY2tldCwgbm90IG9ubHkgYSBmcmFnbWVudC48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJ biBwYXJ0aWN1bGFyLCBkZWRpY2F0ZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXNvdXJjZXMgc2hvdWxkIGRlZGljYXRl ZCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBoYW5kbGluZyBvdXQgb2Ygb3JkZXIgZnJhZ21lbnRzLjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE9m IGNvdXJzZSwgaXQgaXMgb3V0IG9mIHNjb3BlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgdGhpcyBkb2N1bWVudCB0byBk ZXNjcmliZSBob3c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBTRnMgaGFuZGxlIGZyYWdtZW50cy48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAq IElmIGFuIFNGQyBoZWFkZXIgaXMgcHJlcGVuZGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZm9yIGFsbCBmcmFnbWVudHMs IEkmIzM5O20gbm90PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgc3VyZSB0aGVyZSBpcyBhbnkgcGFydGljdWxhcjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGlzc3VlIGF0IHRoZSBTRkYgbGV2ZWwuLi5leGNlcHQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZiBzdHJpcHBpbmcvYWRk aW5nIGNvbnRleHQgVExWczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRlcGVuZHMgb24gdGhlIGZ1bGwgcGFja2V0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKG5vdCBqdXN0IGZyYWdtZW50KS4gSXQgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3YXJyYW50ZWQgdG8gY29uc2lk ZXIgYSBsaXR0bGUgYml0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhpcyBwb2ludCBiZWZvcmUgZGVjbGFyaW5nIHRoZXJl PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXM8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBubyBpc3N1ZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIFRoZSB0ZXh0IHN0YXRlcyAm cXVvdDtzZXZlcmFsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgb3B0aW9ucyZxdW90Oy4gVGhpcyBtYXkgYmUgaW50ZXJwcmV0 ZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBhcyBpZiBpbXBsZW1lbnRpbmcgb25lIG9mIHRoZW08YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyBzdWZm aWNpZW50Li4ud2hpY2ggaXMgbm90PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJ1ZS4gVGhlIGZpcnN0IHR3byBwb2ludHM8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBjb250cmlidXRlIHRvIG1pbmltaXplIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50YXRpb24g cmlzaywgYnV0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbiBtYXkgc3RpbGwgYmU8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleHBl cmllbmNlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIChlLmcuLCBvdGhlciBzaGltcyBhcmUgcHJlcGVuZGVkPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Ynkgb3RoZXIgbm9kZXMgZm9yIHNvbWUgb3RoZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwdXJwb3NlcywgbmVzdGVkIG5z aCwgZXRjLik8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIFRoZSBmaXJzdCB0d28gcG9pbnRzIGhhdmU8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBub3RoaW5nIHRvIGRvIHdpdGggcmVhc3NlbWJseS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIFRoZSBzdXBw b3J0IG9mIGp1bWJvIGZyYW1lcyBieTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGEgcm91dGVyL2RldmljZSBkb2VzIG5vdCBt ZWFuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgdGhhdCBpdCBjYW4gbWFrZSB1c2Ugb2YgaXQuPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXBwcm9wcmlh dGUgTVRVIGNvbmZpZ3VyYXRpb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaG91bGQgYmUgdW5kZXJ0YWtlbiBpbiBhPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgY29uc2lzdGVudCBtYW5uZXIgd2l0aGluIGFuIFNGQzxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvbWFpbi4gVGhl IHRleHQgc2hvdWxkIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdXBkYXRlZCB0byBtYWtlIGl0IGlzIGFib3V0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKGNvbnNpc3RlbnQpIE1UVTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGNvbmZpZ3VyYXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBCVFcsIHNob3Vs ZG4mIzM5O3QgdGhlIHRleHQgYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXdvcmRlZCB0byByZWNvbW1lbmRlZCB0bzxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGluY3JlYXNlIHRoZSBNVFUgb2YgKiphbGw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBub2RlcyoqIG9mIGFuIFNG Qy1lbmFibGVkIGRvbWFpbiBieTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGF0IGxlYXN0IHRoZSBsZW5ndGggb2YgU0ZDPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaGVhZGVyICsgdHJhbnNwb3J0IGhlYWRlcj88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIEJ1bGxldCAy LCBob3cgUE1UVSBkaXNjb3Zlcnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyBhY3R1YWxseSB1c2VkIGluIHRoaXM8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBjb250ZXh0PyBEbyB5b3UgYXNzdW1lIHRoYXQgYWxsPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU0ZDLWF3YXJlIG5v ZGVzIHdpbGwgaXNzdWU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdWNoIG1lc3NhZ2VzIHRvd2FyZHMgb3RoZXI8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBTRkMtYXdhcmUgbm9kZSwgYXJiaXRyYXJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVzdGluYXRpb24sIGVsc2U/PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKiBCdWxsZXQgMiwgSSB3b3VsZCBkcm9wPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7ZGVzY3Jp YmVzIGEgdGVjaG5pcXVlIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGR5bmFtaWNhbGx5IGRpc2NvdmVyaW5nIHRoZTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG1heGltdW0gdHJhbnNtaXNzaW9uIHVuaXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoTVRVKSBvZiBhbiBhcmJp dHJhcnkgaW50ZXJuZXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwYXRoJnF1b3Q7Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogQnVsbGV0 IDIsIHMvIHRoZSB0aGUvdGhlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIHJlZmVyZW5jZSB0byB0aGUg TElTUDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHNwZWNpZmljYXRpb24gcmFpc2VzIHR3byBjb25jZXJuczxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFu ZCBvbmUgY29tbWVudDo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoMSkgSSBkb24mIzM5O3QgdGhpbmsgaXQgaXMg YSBnb29kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYXBwcm9hY2ggdGhhdCBmcmFnbWVudHMgaW5kdWNlZDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJ5 IHRoZSBuZXR3b3JrIGFyZSBwYXNzZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGVpciB1bHRpbWF0ZSBkZXN0aW5h dGlvbnMgYXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBzdWNoPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKHN0YXRlbGVzcykuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSU1PLCByZWFzc2VtYmx5IHNo b3VsZCBiZSBkb25lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgd2l0aGluIHRoZSBTRkMgZG9tYWluPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKHJlc3Bv bnNpYmxlIGZvciBmcmFnbWVudGF0aW9uKTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG5vdCBwYXNzZWQgYXdheS4gKDIpIERv ZXMgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgc3RhdGVmdWwgbW9kZSByZXF1aXJlIGFsbCBTRkM8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkYXRh IHBsYW5lIGVsZW1lbnRzIG1haW50YWluIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmdWxsIGxpc3Qgb2YgTVRVIGZvciB0 aGUgYW55PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgU0ZGL1NGIGluc3RhbmNlIG9mIHRoZSBTRkM8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb21haW4/ PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgW1JGQzY4MzBdIHNob3VsZCBiZSBsaXN0ZWQgYXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBub3JtYXRpdmUgcmVmZXJl bmNlIChub3QgYW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBpbmZvcm1hdGl2ZSBvbmUpLiBJIHdvdWxkPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGVy c29uYWxseSBmYXZvciByZW1vdmluZyB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWZlcmVuY2UgdG8gTElTUCAoYXMg aXQgaXMgYW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBFeHBlcmltZW50YWwgUkZDKS48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIFRoZSBz ZWN1cml0eSBzZWN0aW9uIG9mIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0IG1heSBiZSBhdWdtZW50ZWQgd2l0 aDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGluZm9ybWF0aW9uYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudGF0aW9uLXJlbGF0ZWQgcG9p bnRlcnMgdG86PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZS5nLiwgUkZDMTg1OCAoU2VjdXJpdHk8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDb25zaWRl cmF0aW9ucyBmb3IgSVAgRnJhZ21lbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBGaWx0ZXJpbmcpLCBSRkMzMTI4IChQcm90 ZWN0aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgQWdhaW5zdCBhIFZhcmlhbnQgb2YgdGhlIFRpbnk8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBGcmFn bWVudCBBdHRhY2spLCBhbmQgUkZDIDQ5NjM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoSVB2NCBSZWFzc2VtYmx5IEVycm9y cyBhdCBIaWdoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgRGF0YSBSYXRlcykuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ2hlZXJzLCBNZWQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU1lc3NhZ2UgZCYjMzk7b3JpZ2luZS0tLS0tPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgRGUgOiBzZmM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O108 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBEZSBsYSBwYXJ0IGRlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFbnZvecOpIDog bHVuZGkgMTEgYXZyaWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2IDEzOjE0IMOAIDogVGhvbWFzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgTmFydGVuOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 IE9iamV0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBSZTo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbc2ZjXSBXRyBsYXN0IGNh bGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIERlYXIgVGhvbWFzLCBhbGwsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXMgSSBtZW50 aW9uZWQgZHVyaW5nIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1lZXRpbmcsIHRoZXJlIGFyZSBzZXZlcmFs PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgaXNzdWVzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCBhcmUgbm90IGNvdmVyZWQg aW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgbGFzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gSTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGFscmVhZHkgcHJvdmlkZWQgZXhhbXBsZXMgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgaXNz dWVzIG9mZmxpbmUgYXMgcmVxdWVzdGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkgTWFydGluLjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIENoZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1N ZXNzYWdlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZCYjMzk7b3JpZ2luZS0tLS0tIERlIDogc2ZjPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtdPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgRGUgbGEgcGFydCBkZSBUaG9tYXMgTmFydGVuPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgRW52b3nDqSA6IGpldWRpIDMxIG1hcnM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2IDA0OjQ4 IMOAIDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT2JqZXQgOiBbc2ZjXSBXRyBsYXN0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1p ZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGVhciBXRzo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGlzIG5vdGUgYmVnaW5zIGEgV0c8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBsYXN0IGNhbGwgb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1u c2gtMDQudHh0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC8iIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt c2ZjLW5zaC88L2E+KS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBU aGUgZWRpdG9ycyBvZiB0aGUgTlNIIGRvY3VtZW50IGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSBo YXZlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWRkcmVzc2VkIGFsbCBrbm93bjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGNvbW1lbnRzIGFuZCB0aGF0IHRoZXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg YXJlIG5vIG9wZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMgd2l0aCB0aGUgY3VycmVudDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50Ljxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFN1YnN0YW50aXZlIGNvbW1lbnRzIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dGhlIGxpc3QgcGxlYXNlLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVkaXRvcmlhbCBjb21tZW50czxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGNhbiBnbyBkaXJlY3RseSB0byB0aGU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBkb2N1bWVudCBlZGl0b3JzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdlJiMzOTts bCBhbHNvIGdldCBhIGJyaWVmPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdXBkYXRlIGZyb20gdGhlIGVk aXRvcnM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhdCBuZXh0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2Vl ayYjMzk7cyBtZWV0aW5nLiBJZiB0aGVyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZSBhbnkgcmVt YWluaW5nIGlzc3Vlczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdpdGggdGhlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgZG9jdW1lbnQsIHJhaXNpbmcgdGhlbTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJlZm9yZSB0 aGUgbWVldGluZyB3b3VsZCBiZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVzcGVjaWFsbHkgaGVscGZ1 bC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBGb3IgdGhlIGNoYWlycywgVGhvbWFzPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZmMgbWFpbGluZzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGxpc3QgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQo8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHNmYyBtYWlsaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGlzdCA8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9h Pjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgc2ZjIG1haWxpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaXN0IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBz ZmMgbWFpbGluZzwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9k aXY+DQo= --94eb2c1100146a10f205318a831a-- From nobody Thu Apr 28 05:45:47 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 C207F12D690 for ; Thu, 28 Apr 2016 05:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 FdmHvkZT8NRZ for ; Thu, 28 Apr 2016 05:45:43 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410ED12D692 for ; Thu, 28 Apr 2016 05:45:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id E8E4E25348E; Thu, 28 Apr 2016 05:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461847542; bh=p9d0tkkaTez/P4G+eR6RGZs2wcqxE7x9eKp+yfuLLN0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=JjLUO/GgJuJM6DSCFQI2LFQE6z3MmZnK9Fdd0F0rcqJi/ASP1RtBkEfJo3KOUyAya qhwMLHwQ+U8xYmClpg36LzcDriTcUaiq2LBiUMQhigZXjzRfRqPucVQ4uu0rQRuehu bYtKR2ELlLOrpclQsCsOKZGM/ZJ8vUI5iFGDH9P0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 90EAE240F47; Thu, 28 Apr 2016 05:45:41 -0700 (PDT) To: "Andrew G. Malis" References: <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 28 Apr 2016 08:45:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.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" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 12:45:47 -0000 The fragmentation fields shown in all the diagrams in the LISP spec are the IP fragmentation fields. There is no LISP fragmentation information. Thus, in parallel, I don't see nay need for NSH to have fragmentation information. Yes, there is an implication. Inner packet fragmentation can only be used as a response to an MTU issue when the inner packet format supports fragmentation. As far as I know, that is only IPv4. Outer (transport) packet fragmentation can only be used to address the MTU issue when the outer (transport) packet supports fragmentation, that being IPv4 and IPv6. Note that a corollary of this is that SFC simply puts NSH headers on the packets it (the classifier or SFF) sends. Yours, Joel On 4/28/16 8:17 AM, Andrew G. Malis wrote: > Joel, > > The diagrams in section 6 of RFC 6830 are control plane, not data plane. > The data plane diagrams are in section 5. > > But the overriding question is - without any fields in the NSH header to > sequence fragments, how can the fragments be correctly reassembled? > > Cheers, > Andy > > On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct > > wrote: > > The LISP header does not have a fragment flag or fragment offset. > The diagrams in section 6 include the outer encapsulating header > (the equivalent of the transport header in SFC.) Yes, the text is a > little hard to follow in this regard. The LISP working group is > going to be rewriting RFC 6830 as part of moving to standards track. > > So there is no difference in this regard between NSH and LISP. > > Yours, > Joel > > On 4/27/16 7:02 PM, Andrew G. Malis wrote: > > Joel et al, > > All this talk about fragmentation prompted me to re-read section > 6 of > the draft, which recommends (as option 3) using the procedures in > section 5.4 of RFC 6830 (presumably with the “NSH header†> replacing the > “LISP header†in the description of the procedures in that section). > > So that led me to read that section (and the LISP header > definition in > section 5.1), and I see that LISP does fragmentation and reassembly > identically to IPv4, using the Fragment Offset field so that > fragments > can be correctly reassembled in the proper order. > > However, the NSH Header doesn’t have a Fragment Offset field or any > other way to order the fragments. > > So how can the procedures in Section 5.4 of 6830 be used? > > Thanks, > Andy > > On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern > > >> wrote: > > Both methods are valid, and both depend upon details of the > underlying packet and the transport. As such, I don't see > why this > document benefits from describing them, much less why it > should mark > one method as a "should". Implementation details are likely > to be > more significant than any bit consumption difference between > the two > alternatives. > > Yours, > Joel > > > On 4/27/16 3:40 PM, Linda Dunbar wrote: > > I suggest adding the following paragraphs after the > Bullet 3 of > the Section 6 Fragmentation Consideration to make the > process > more clear and less controversial: > > > -------------------------------- > > RFC6830 describes the fragmentation method of breaking the > original packet into two equal sub-frames and encapsulating > [LISP Header + Transport header] to each sub-frame. > > If LISP fragmentation [RFC6830 Section 5.4] is used, the > [SFC > Header + Transport Header] will be added to each half > frame (or > the original data frame). As the Transport Header is > terminated > by the next SFF node's tunnel transport layer, the > combined two > sub-frames will have two SFC Headers. > > Therefore, the fragmentation for NSH encapsulated data frame > should be done completely by the node tunnel transport > layer, > which should break the [SFC + original packet] into two > equal > sub-frames and each sub-frame being encapsulated with its > respective tunnel header. The next SFF node's tunnel > transport > layer should combine the two sub-frames before sending > to the > next node. > > ------------------------------------------------------ > > > By the way, there are to typo in the Section 6: > 3rd line: "In order the" ==> "In order to" > Last line of Bullet 2: extra "the" in the "utilized to > ensure > the the required packet". > > > Hope it helps. > > Linda > > > > -----Original Message----- > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com > > >] > Sent: Wednesday, April 27, 2016 12:40 AM > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; > sfc@ietf.org > > > Subject: RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Joel, all, > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Joel M. Halpern [mailto:jmh@joelhalpern.com > > >] Envoyé : mardi 26 > avril 2016 19:18 À : Linda Dunbar; BOUCADAIR Mohamed > IMT/OLN; Elzur, > Uri; sfc@ietf.org > > Objet : Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > With regard to Transport tunnel fragementation, that > seems > an issue > for the transport protocol. I don't actually object > to a > sentence, > but it does not seem that it will accomplish anything. > > > [Med] I would like to see some text added to the draft. > > > With regard to packets fragmented by the source, I > completely disagree > with your assertion. If an SFF were to reassemble the > packets, that > would be a violation of its job. > > > [Med] I agree with you. > > There is no reason for an SFF to > > reassemble a packet fragmented by the source. The > classifier may have > to do some interesting things in order to properly > classify > succeeding > fragments, but that is an implementation issue (most > commonly > addressed with virtual reassembly, which doe snot > delay the > fragments.) We don't specity that. > > > [Med] Still, the external behavior of the classifier > needs to be > clear in the document. I don't find any text in the > draft saying > for instance that an NSH header must be present in all > fragments. (There some processing that might be needed > at the > SFF to "do its job" with regards to fragments (receive > out of > order fragments + forwarding policy on the full packet).) > > > If an SF needs to reassemble fragments to do its > job, that > is up to > the SF. Some will need to actually reassemble. > Some will > need to > perform virtual reassembly, and some will happily > process the > fragments. I can not see what the NSH document could > possibly mandate. > > > [Med] Fully agree. > > > Yours, > Joel > > On 4/26/16 11:47 AM, Linda Dunbar wrote: > > Joel, > > I think the document should add the description > on the > following two > fragmentation scenarios: > > - Transport tunnel generated fragmentation: When > a packet > fragmentation is caused by transport tunnel > (i.e. various > encapsulations), the termination point of the > transport > tunnel is > responsible for re-assembling the fragmented > pieces of > the packet. > Since there won't be any SFF nodes in between the > Transport Tunnel, > the tunnel generated fragmentation does not > require any > actions by > SFF nodes or SF nodes. > > > - Source node generated fragmentation (after > adding on > the NSH > header): When fragmentation has to be performed > for a > packet being > encapsulated with the NSH header, either the > intermediate SFF nodes > or the SF nodes have to be able to reassemble the > fragmented pieces. > > > > > Cheers, > > > Linda > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com > > >] Sent: Tuesday, April 26, > 2016 10:33 AM > To: Linda Dunbar; mohamed.boucadair@orange.com > > >; Elzur, Uri; > sfc@ietf.org > > Subject: Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that you are > referring only to > the case of transport generated fragmentation of the > outer packet. > I had assumed you were not talking about that, > since the > resulting > fragments will not all have NSH headers. As > with any tunnel > technology, if the tunnel chooses to fragment at its > layer, then the > tunnel is responsible for reassembly. That would be > invisible to > the SFF. > > Yours, Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > > Agree with Med. > > Even if each fragment piece of a packet with NSH > header carries the > NSH header, the intermediate SFF nodes still > need to > put together > all the fragments together before passing > the whole > data frame to > the SF. > > Linda > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > > >] > On Behalf Of mohamed.boucadair@orange.com > > > Sent: Monday, > April 25, > 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; > sfc@ietf.org > > Subject: > Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer to > ALWAYS > prepend an NSH > header even for fragments? Or you don't care > about that? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : Elzur, Uri > [mailto:uri.elzur@intel.com > > >] Envoyé : lundi 25 > avril 2016 16:26 À > : BOUCADAIR Mohamed IMT/OLN; Joel M. > Halpern; > sfc@ietf.org > > Objet > : RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > Not to repeat my position, but I'll do > it anyhow > :-) As NSH is > *NOT* a transport, dealing with > fragmentation is > left to the > Transport used. > > The model I use for NSH, is basically > similar to > VXLAN . It is an > overly. > > Thx > > Uri ("Oo-Ree") C: 949-378-7568 > > > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > > >] > On Behalf Of > mohamed.boucadair@orange.com > > Sent: > Monday, April 25, > 2016 7:18 AM To: Joel M. Halpern > >>; > sfc@ietf.org > > > Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Joel, > > Please see inline. > > Cheers, Med > > -----Message d'origine----- De : > Joel M. Halpern > [mailto:jmh@joelhalpern.com > > >] Envoyé : lundi > 25 avril 2016 15:48 À > : BOUCADAIR Mohamed IMT/OLN; > sfc@ietf.org > > Objet : Re: [sfc] WG > last call for draft-ietf-sfc-nsh-04.txt > > If I am understanding you correctly > Med, you > are asking that the > NSH draft specify how service chaining > should cope with packets > that have been fragmented? > > > [Med] To be accurate, I'm asking to assess > whether there are > implications. If there are, then the draft > should be updated > accordingly. > > NSH, and the SFF functionality, does > not care. > > > [Med] I'm not that sure. Some typical > implications are listed > below: > > * SFF: If the NSH header is present only > in the > a fragment but SFF > didn't maintained a state, subsequent > fragments > won't be > appropriately processed. * SFC-aware > function: > if prepending a > context information depends on the full > packet, > not only a > fragment. > > It just does its job. > > [Med] which may be disturbed in some > situations > as listed in the > examples above. > > Ingress and intermediate classifiers may > cope with fragments in > any number of ways. > > Specifying such is clearly out of scope > for this > draft. > > [Med] The purpose is not to specify the > internal > implementation > details but the external behavior of the > classifier function when > it comes to handle fragments. That > behavior may > have an incidence > on SFF, in particular. The purpose is not to > recommend the maximum > resources to be dedicated to out of order > fragments nor the > timeout to cache those; these > considerations are > of course out of > scope. Nevertheless, an implementation > should > offer a configurable > parameter so that an operator tweak those > according to its > context. > > I suppose one could write an > informational > draft on possible ways > of coping. The IETF has not usually > published such. > Service functions have to cope with > fragmented packets just as > they had to before the advent of NSH, so > describing that is > clearly not needed here. > > > [Med] The advent of NSH has the following > implications: * it > exacerbates fragmentation. Handing over this > issue to the > transport layer may lead to interoperability > issues. * the > chaining may not be efficient if > fragments are > inappropriately > handled. > > Introducing NSH should not degrade the > overall > service compared to > legacy service deployment schemes. > > > Yours, Joel > > On 4/25/16 3:00 AM, > mohamed.boucadair@orange.com > > > wrote: > > Re-, > > I hear you, but my comment is > that we > need, as a WG, to decide > what to > > put in the draft. FWIW, I'm > discussing two > fragmentation > issues: > > > (1) Fragmentation that is caused by > prepending an SFC header. > (2) Handling fragments at the > ingress of > an SFC-enabled domain. > > Increasing the MTU is for sure a > recommendation is to be > explicitly > > called out in the text (see my first > message). > > > There are other issues that need > to be > discussed, e.g., how to > deal with > > fragments in SFFs/Classifiers? > > > It is also "prudent" to check > that no > issues will be experienced > in SFF > > to handle fragments. If an SFC header is > prepended for all > fragments, I'm not sure there > > is any particular issue at the SFF > level, except if > stripping/adding > > context TLVs depends on the full > packet (not > just fragment). It > is warranted to consider a little > bit this > point before declaring > there is no issue. > > > For point (1), declaring > fragmentation > out of scope would be > meant that > > an implementation must be prepared to > receive fragments with or > without NSH header as this is a decision > that is left to the > transport encapsulation. This is a > requirement per se! > > > I won't reiterate all the comments I > have about the current > wording of > > this section. > > > Cheers, Med > > -----Message d'origine----- De : > Elzur, Uri > [mailto:uri.elzur@intel.com > > >] Envoyé > : lundi 25 avril 2016 > 08:30 À : BOUCADAIR Mohamed > IMT/OLN; > Thomas Narten; > sfc@ietf.org > > > Objet : RE: [sfc] WG last > call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > My point is that > Fragmentation is > yet another transport related > issue > > that > > is beyond the scope of NSH and > beyond the charter of the WG, so > it > > doesn't > > really belong in the draft. > We are > providing an advice as > extending the size of the > packet may > lead to fragmentation, but > as you check RFC 7348 VxLAN, > which > my create the same issue, > you'll find it doesn't even > > relate > > to it. > > Thx > > Uri ("Oo-Ree") C: > 949-378-7568 > > > > > -----Original Message----- > From: sfc > [mailto:sfc-bounces@ietf.org > > >] On > Behalf Of > mohamed.boucadair@orange.com > > > > Sent: > Sunday, April 24, 2016 > 10:32 PM To: Elzur, Uri > > >>; > Thomas Narten > > >>; > > sfc@ietf.org > > > Subject: Re: [sfc] WG last > call for > draft-ietf-sfc-nsh-04.txt > > Hi Uri, > > That's another option that > needs to > be discussed/investigated. > I'm > > afraid > > this is not the rationale > adopted in > -04 since it includes some > text > > that > > is far to be sufficient to > ensure > interoperable > implementations. > > BTW, saying that nsh does > not need > to deal with fragmentation > because > > it > > is transport-independent is > not IMHO > a good strategy to adopt > here > > because > > it opens the door for > interoperable > issues, it may lead to > sub-optimal implementations > if the > sfc information is present > only in one > > fragments, > > etc. > > My comments are related to the > current text in the -04. > This text needs > > to > > be fixed somehow. > > Cheers, Med > > -----Message > d'origine----- De : > Elzur, Uri > > [mailto:uri.elzur@intel.com > > >] > Envoyé : dimanche 24 avril > 2016 17:36 À : BOUCADAIR > Mohamed > IMT/OLN; Thomas Narten; > sfc@ietf.org > > > Objet : > RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > I see no need to specify the > exact behavior as NSH is > transport independent > i.e. like > NSH interaction with any > other > Transport eh issue of > Fragmentation is to be > dealt in > a way > that matches the mechanisms > supported by the > Transport used > and do not belong in the > NSH draft > > Thx > > Uri ("Oo-Ree") C: > 949-378-7568 > > > > > -----Original > Message----- From: sfc > > [mailto:sfc-bounces@ietf.org > > >] > On Behalf Of > > mohamed.boucadair@orange.com > > > > Sent: Thursday, April 14, > 2016 12:43 AM To: Thomas > Narten > > > >>; > sfc@ietf.org > > > Subject: > Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > R-, > > In addition to other pending > issues raised for this > draft, I > would like to raise this > additional one about > Section 6. > > == 6. Fragmentation > Considerations > > NSH and the associated > transport > header are "added" to the > encapsulated > packet/frame. This > additional information > increases > > the > > size of the packet. In > order > the ensure proper > forwarding of > NSH data, several > options for > handling fragmentation and > re-assembly exist: > > 1. Jumbo Frames, when > supported, enable the > transport > of NSH > and associated transport > packets > without requiring > fragmentation. > > 2. Path MTU Discovery > [RFC1191]"describes a > technique for > dynamically discovering the > maximum transmission > unit (MTU) of > > an > > arbitrary internet path" > and can > be utilized to ensure the > > the > > required packet size is > used. > > 3. [RFC6830] describes two > schemes for > fragmentation and > re- > > assembly > > in section 5.4. == > > * The text is weak for a > Standard track document > that is > intended to solve the > problem in > > https://tools.ietf.org/html/rfc7498#section- > > 2.12. > > There should be a clear > behavior > to be followed by an > > implementation. > > Further, I would avoid > the use > of words such as "can". > > * The text covers only > fragmentation when it is > induced > by SFC > operations, it does not > discuss > the treatment of a fragment > when received in an SFC > domain. > IMHO, the draft should also > specify the behavior of the > Classifier with regards to > fragments for the sake > of proper > SFC operation. Applying > classification policies may > require the > > full packet, not only a > fragment. > > In particular, dedicated > resources should > dedicated for > handling out of order > fragments. > Of course, it is out of > scope > of this document to > describe how > SFs handle fragments. > > * If an SFC header is > prepended > for all fragments, I'm not > sure there is any particular > issue at the SFF > level...except > if stripping/adding > context TLVs > depends on the full packet > (not just fragment). It is > warranted to consider a > little bit > this point before > declaring there > > is > > no issue. > > > * The text states "several > options". This may be > interpreted > as if implementing one > of them > is sufficient...which is not > true. The first two points > contribute to minimize the > fragmentation risk, but > fragmentation may still be > experienced > (e.g., other shims are > prepended > by other nodes for some > other > purposes, nested nsh, etc.) > > * The first two points have > nothing to do with > reassembly. > > * The support of jumbo > frames by > a router/device does not > mean > that it can make use of it. > Appropriate MTU > configuration > should be undertaken in a > consistent manner within > an SFC > domain. The text should be > updated to make it is about > (consistent) MTU > > configuration. > > > * BTW, shouldn't the text be > reworded to recommended to > increase the MTU of **all > nodes** of an > SFC-enabled domain by > at least the length of SFC > header + transport header? > > * Bullet 2, how PMTU > discovery > is actually used in this > context? Do you assume > that all > SFC-aware nodes will issue > such messages towards other > SFC-aware node, arbitrary > destination, else? > > * Bullet 2, I would drop > "describes a technique for > dynamically discovering the > maximum transmission unit > (MTU) of an arbitrary > internet > path". > > * Bullet 2, s/ the the/the. > > * The reference to the LISP > specification raises two > concerns > and one comment: > > (1) I don't think it is > a good > approach that fragments > induced > by the network are passed to > their ultimate > destinations as > such > > (stateless). > > IMO, reassembly should > be done > within the SFC domain > (responsible for > fragmentation) > not passed away. (2) > Does the > stateful mode require > all SFC > data plane elements > maintain a > full list of MTU for the any > SFF/SF instance of the SFC > > domain? > > > The current text > suggests that > [RFC6830] should be > listed as > normative reference (not an > informative one). I would > personally favor > removing the > reference to LISP (as it > is an > Experimental RFC). > > * The security section > of the > draft may be augmented with > informational > fragmentation-related > pointers to: > e.g., RFC1858 (Security > Considerations for IP > Fragment > Filtering), RFC3128 > (Protection > Against a Variant of the > Tiny > Fragment Attack), and > RFC 4963 > (IPv4 Reassembly Errors > at High > Data Rates). > > Cheers, Med > > -----Message > d'origine----- > De : sfc > > [mailto:sfc-bounces@ietf.org > > >] > De la part de > > mohamed.boucadair@orange.com > > > > Envoyé : lundi 11 avril > 2016 13:14 À : Thomas > Narten; sfc@ietf.org > > > Objet > : Re: > [sfc] WG last call for > > draft-ietf-sfc-nsh-04.txt > > Dear Thomas, all, > > As I mentioned > during the > meeting, there are > several > issues > that are not covered > in the > last version of the > draft. I > already provided > examples of > the issues offline > as requested > by Martin. > > Cheers, Med > > -----Message > d'origine----- > De : sfc > > [mailto:sfc-bounces@ietf.org > > >] > De la part de > Thomas Narten > Envoyé : jeudi > 31 mars > 2016 04:48 À : > sfc@ietf.org > > > > > Objet : [sfc] WG > last > call for > > draft-ietf-sfc-nsh-04.txt > > Dear WG: > > This note begins > a WG > last call on > > draft-ietf-sfc-nsh-04.txt > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > The editors of the NSH document have indicated that > they have > > addressed all known > comments and > that there > are no open > issues with the > current > version of the > document. > > Substantive > comments to > the list please, > editorial comments > can go directly > to the > document editors. > > We'll also get a > brief > update from the > editors > at next > week's meeting. > If there > are any > remaining issues > with the > document, > raising them > before the > meeting would be > especially helpful. > > For the chairs, > Thomas > > > _______________________________________________ > sfc mailing > list > sfc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing > > From nobody Thu Apr 28 06:23:02 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 068A612D6F8 for ; Thu, 28 Apr 2016 06:23:00 -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 SOnUmTNfbchK for ; Thu, 28 Apr 2016 06:22:55 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 2D80012D73A for ; Thu, 28 Apr 2016 06:22:33 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v145so49818358oie.0 for ; Thu, 28 Apr 2016 06:22:33 -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=lddZI4e0lO0kUqFj5BcHGagnQMMLmS5v0fFM2l7Of2o=; b=ACduZRWvL3VbzzNTuNGI15Ace80o8lmzGDN2edzsXTvPILMHJphbRqHLV9oDM9O0Qb JwMWeamIOEXrgDPbfZURQQkfX3/n0ejn6DO3Rdq5iQiqTbq/UxwufF1Ugbi0nIriIlHW kq5sGzKC0Bt+gyPAaB0N4obwU92NJegx1qt0UdMgTRLEm4wwBwR7IhLZ23bwf1gntN6w MlJCjAr6d4Yny4+k4BfPXt1vDfPzu6nG7WPoIC/BAhZtZsSxRtQibkdiY12S3d3d0NDX rAShb9GVEebozbes+hjtC+H3sEzqF+uMIiXJLHlZW8L0nHX+Zb0qGQxC9NLIclQIZqSG jmbw== 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=lddZI4e0lO0kUqFj5BcHGagnQMMLmS5v0fFM2l7Of2o=; b=P0id0SR4mx4CaGShEz9WnARi58O9UwE1+e9Ux3v3d03j1bOeoO4E3dAXvKMZhDleS+ jFiQpBvDfD16RV0leYcuteKtpnxRu1IaBdT6sK9DF4ve/OftYdeSUpdLkFwx/bJWPkSh ri+du8sE5o/kYM/Zg/mLSEYBZRoUSe8XywNbT+RoCmBcL27rj57KeK2En/qyFzsh03QT FqYfBT28ziZf3FFAPGg7HLo+xgN8K4dTWG0UkN8U0A3Ii0S5A7HZXLA8/A2LxISI17Cn zUs0m4ncLyLYed0KPpOG75e+jHwfbsrex5bFtAJF1MKW1Qb0iTBSA+cciKSnn0M1oiUt HlRg== X-Gm-Message-State: AOPr4FW85gv1MoUlq/qu4NgmMDwYf7YuaXBVpGdqcveE6KfqqUs7nb96Nl0oTu4arelma4MuJedBGXqVa2CrTw== X-Received: by 10.202.102.36 with SMTP id a36mr5768867oic.122.1461849751644; Thu, 28 Apr 2016 06:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Thu, 28 Apr 2016 06:22:11 -0700 (PDT) In-Reply-To: References: <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 28 Apr 2016 09:22:11 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11408aa42978c305318b6b4c Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 13:23:00 -0000 --001a11408aa42978c305318b6b4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joel, If this is actually how section 6 should work, there should be text to make it clear. I=E2=80=99m curious if any of the existing implementations of this draft ha= ve implemented fragmentation, and if so, if they=E2=80=99re interoperable. Thanks, Andy On Thu, Apr 28, 2016 at 8:45 AM, Joel M. Halpern wrote: > The fragmentation fields shown in all the diagrams in the LISP spec are > the IP fragmentation fields. There is no LISP fragmentation information. > > Thus, in parallel, I don't see nay need for NSH to have fragmentation > information. > > Yes, there is an implication. Inner packet fragmentation can only be use= d > as a response to an MTU issue when the inner packet format supports > fragmentation. As far as I know, that is only IPv4. > > Outer (transport) packet fragmentation can only be used to address the MT= U > issue when the outer (transport) packet supports fragmentation, that bein= g > IPv4 and IPv6. > > Note that a corollary of this is that SFC simply puts NSH headers on the > packets it (the classifier or SFF) sends. > > Yours, > Joel > > On 4/28/16 8:17 AM, Andrew G. Malis wrote: > >> Joel, >> >> The diagrams in section 6 of RFC 6830 are control plane, not data plane. >> The data plane diagrams are in section 5. >> >> But the overriding question is - without any fields in the NSH header to >> sequence fragments, how can the fragments be correctly reassembled? >> >> Cheers, >> Andy >> >> On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct >> > wrote: >> >> The LISP header does not have a fragment flag or fragment offset. >> The diagrams in section 6 include the outer encapsulating header >> (the equivalent of the transport header in SFC.) Yes, the text is a >> little hard to follow in this regard. The LISP working group is >> going to be rewriting RFC 6830 as part of moving to standards track. >> >> So there is no difference in this regard between NSH and LISP. >> >> Yours, >> Joel >> >> On 4/27/16 7:02 PM, Andrew G. Malis wrote: >> >> Joel et al, >> >> All this talk about fragmentation prompted me to re-read section >> 6 of >> the draft, which recommends (as option 3) using the procedures i= n >> section 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header= =E2=80=9D >> replacing the >> =E2=80=9CLISP header=E2=80=9D in the description of the procedur= es in that >> section). >> >> So that led me to read that section (and the LISP header >> definition in >> section 5.1), and I see that LISP does fragmentation and >> reassembly >> identically to IPv4, using the Fragment Offset field so that >> fragments >> can be correctly reassembled in the proper order. >> >> However, the NSH Header doesn=E2=80=99t have a Fragment Offset f= ield or >> any >> other way to order the fragments. >> >> So how can the procedures in Section 5.4 of 6830 be used? >> >> Thanks, >> Andy >> >> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> >> >> wrote= : >> >> Both methods are valid, and both depend upon details of the >> underlying packet and the transport. As such, I don't see >> why this >> document benefits from describing them, much less why it >> should mark >> one method as a "should". Implementation details are likely >> to be >> more significant than any bit consumption difference between >> the two >> alternatives. >> >> Yours, >> Joel >> >> >> On 4/27/16 3:40 PM, Linda Dunbar wrote: >> >> I suggest adding the following paragraphs after the >> Bullet 3 of >> the Section 6 Fragmentation Consideration to make the >> process >> more clear and less controversial: >> >> >> -------------------------------- >> >> RFC6830 describes the fragmentation method of breaking t= he >> original packet into two equal sub-frames and >> encapsulating >> [LISP Header + Transport header] to each sub-frame. >> >> If LISP fragmentation [RFC6830 Section 5.4] is used, the >> [SFC >> Header + Transport Header] will be added to each half >> frame (or >> the original data frame). As the Transport Header is >> terminated >> by the next SFF node's tunnel transport layer, the >> combined two >> sub-frames will have two SFC Headers. >> >> Therefore, the fragmentation for NSH encapsulated data >> frame >> should be done completely by the node tunnel transport >> layer, >> which should break the [SFC + original packet] into two >> equal >> sub-frames and each sub-frame being encapsulated with it= s >> respective tunnel header. The next SFF node's tunnel >> transport >> layer should combine the two sub-frames before sending >> to the >> next node. >> >> ------------------------------------------------------ >> >> >> By the way, there are to typo in the Section 6: >> 3rd line: "In order the" =3D=3D> "In order to" >> Last line of Bullet 2: extra "the" in the "utilized to >> ensure >> the the required packet". >> >> >> Hope it helps. >> >> Linda >> >> >> >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> >> > > >> [mailto:mohamed.boucadair@orange.com >> >> > >] >> Sent: Wednesday, April 27, 2016 12:40 AM >> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; >> sfc@ietf.org >> > >> Subject: RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, all, >> >> Please see inline. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com >> >> > >] Envoy=C3=A9 : mardi 26 >> avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mo= hamed >> IMT/OLN; Elzur, >> Uri; sfc@ietf.org >> > Objet : Re: [sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, that >> seems >> an issue >> for the transport protocol. I don't actually object >> to a >> sentence, >> but it does not seem that it will accomplish anythin= g. >> >> >> [Med] I would like to see some text added to the draft. >> >> >> With regard to packets fragmented by the source, I >> completely disagree >> with your assertion. If an SFF were to reassemble t= he >> packets, that >> would be a violation of its job. >> >> >> [Med] I agree with you. >> >> There is no reason for an SFF to >> >> reassemble a packet fragmented by the source. The >> classifier may have >> to do some interesting things in order to properly >> classify >> succeeding >> fragments, but that is an implementation issue (most >> commonly >> addressed with virtual reassembly, which doe snot >> delay the >> fragments.) We don't specity that. >> >> >> [Med] Still, the external behavior of the classifier >> needs to be >> clear in the document. I don't find any text in the >> draft saying >> for instance that an NSH header must be present in all >> fragments. (There some processing that might be needed >> at the >> SFF to "do its job" with regards to fragments (receive >> out of >> order fragments + forwarding policy on the full packet).= ) >> >> >> If an SF needs to reassemble fragments to do its >> job, that >> is up to >> the SF. Some will need to actually reassemble. >> Some will >> need to >> perform virtual reassembly, and some will happily >> process the >> fragments. I can not see what the NSH document coul= d >> possibly mandate. >> >> >> [Med] Fully agree. >> >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >> >> Joel, >> >> I think the document should add the description >> on the >> following two >> fragmentation scenarios: >> >> - Transport tunnel generated fragmentation: When >> a packet >> fragmentation is caused by transport tunnel >> (i.e. various >> encapsulations), the termination point of the >> transport >> tunnel is >> responsible for re-assembling the fragmented >> pieces of >> the packet. >> Since there won't be any SFF nodes in between th= e >> Transport Tunnel, >> the tunnel generated fragmentation does not >> require any >> actions by >> SFF nodes or SF nodes. >> >> >> - Source node generated fragmentation (after >> adding on >> the NSH >> header): When fragmentation has to be performed >> for a >> packet being >> encapsulated with the NSH header, either the >> intermediate SFF nodes >> or the SF nodes have to be able to reassemble th= e >> fragmented pieces. >> >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- From: Joel M. Halpern >> [mailto:jmh@joelhalpern.com >> >> > >] Sent: Tuesday, April 26, >> 2016 10:33 AM >> To: Linda Dunbar; mohamed.boucadair@orange.com >> >> > >; Elzur, Uri; >> sfc@ietf.org >> > Subject: Re: [sfc] W= G >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that you ar= e >> referring only to >> the case of transport generated fragmentation of >> the >> outer packet. >> I had assumed you were not talking about that, >> since the >> resulting >> fragments will not all have NSH headers. As >> with any tunnel >> technology, if the tunnel chooses to fragment at >> its >> layer, then the >> tunnel is responsible for reassembly. That woul= d >> be >> invisible to >> the SFF. >> >> Yours, Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >> >> Agree with Med. >> >> Even if each fragment piece of a packet with >> NSH >> header carries the >> NSH header, the intermediate SFF nodes still >> need to >> put together >> all the fragments together before passing >> the whole >> data frame to >> the SF. >> >> Linda >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> >> > >] >> On Behalf Of mohamed.boucadair@orange.com >> >> > > Sent: Monday, >> April 25, >> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern= ; >> sfc@ietf.org >> > Subject: >> Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer to >> ALWAYS >> prepend an NSH >> header even for fragments? Or you don't care >> about that? >> >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : Elzur, >> Uri >> [mailto:uri.elzur@intel.com >> >> > >] Envoy=C3=A9 : lundi 25 >> avril 2016 16:26 =C3=80 >> : BOUCADAIR Mohamed IMT/OLN; Joel M. >> Halpern; >> sfc@ietf.org >> > Objet >> : RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll do >> it anyhow >> :-) As NSH is >> *NOT* a transport, dealing with >> fragmentation is >> left to the >> Transport used. >> >> The model I use for NSH, is basically >> similar to >> VXLAN . It is an >> overly. >> >> Thx >> >> Uri ("Oo-Ree") C: 949-378-7568 >> > >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> >> > >] >> On Behalf Of >> mohamed.boucadair@orange.com > > >> > > Sent: >> Monday, April 25, >> 2016 7:18 AM To: Joel M. Halpern >> > > >>; >> sfc@ietf.org >> > >> Subject: Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, Med >> >> -----Message d'origine----- De : >> Joel M. Halpern >> [mailto:jmh@joelhalpern.com >> >> > >] Envoy=C3=A9 : lundi >> 25 avril 2016 15:48 =C3=80 >> : BOUCADAIR Mohamed IMT/OLN; >> sfc@ietf.org >> > > Objet : Re: [sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> If I am understanding you correctly >> Med, you >> are asking that the >> NSH draft specify how service chaini= ng >> should cope with packets >> that have been fragmented? >> >> >> [Med] To be accurate, I'm asking to asse= ss >> whether there are >> implications. If there are, then the dra= ft >> should be updated >> accordingly. >> >> NSH, and the SFF functionality, does >> not care. >> >> >> [Med] I'm not that sure. Some typical >> implications are listed >> below: >> >> * SFF: If the NSH header is present only >> in the >> a fragment but SFF >> didn't maintained a state, subsequent >> fragments >> won't be >> appropriately processed. * SFC-aware >> function: >> if prepending a >> context information depends on the full >> packet, >> not only a >> fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some >> situations >> as listed in the >> examples above. >> >> Ingress and intermediate classifiers >> may >> cope with fragments in >> any number of ways. >> >> Specifying such is clearly out of scope >> for this >> draft. >> >> [Med] The purpose is not to specify the >> internal >> implementation >> details but the external behavior of the >> classifier function when >> it comes to handle fragments. That >> behavior may >> have an incidence >> on SFF, in particular. The purpose is no= t >> to >> recommend the maximum >> resources to be dedicated to out of orde= r >> fragments nor the >> timeout to cache those; these >> considerations are >> of course out of >> scope. Nevertheless, an implementation >> should >> offer a configurable >> parameter so that an operator tweak thos= e >> according to its >> context. >> >> I suppose one could write an >> informational >> draft on possible ways >> of coping. The IETF has not usually >> published such. >> Service functions have to cope with >> fragmented packets just as >> they had to before the advent of NSH= , >> so >> describing that is >> clearly not needed here. >> >> >> [Med] The advent of NSH has the followin= g >> implications: * it >> exacerbates fragmentation. Handing over >> this >> issue to the >> transport layer may lead to >> interoperability >> issues. * the >> chaining may not be efficient if >> fragments are >> inappropriately >> handled. >> >> Introducing NSH should not degrade the >> overall >> service compared to >> legacy service deployment schemes. >> >> >> Yours, Joel >> >> On 4/25/16 3:00 AM, >> mohamed.boucadair@orange.com >> >> > > wrote: >> >> Re-, >> >> I hear you, but my comment is >> that we >> need, as a WG, to decide >> what to >> >> put in the draft. FWIW, I'm >> discussing two >> fragmentation >> issues: >> >> >> (1) Fragmentation that is caused >> by >> prepending an SFC header. >> (2) Handling fragments at the >> ingress of >> an SFC-enabled domain. >> >> Increasing the MTU is for sure a >> recommendation is to be >> explicitly >> >> called out in the text (see my first >> message). >> >> >> There are other issues that need >> to be >> discussed, e.g., how to >> deal with >> >> fragments in SFFs/Classifiers? >> >> >> It is also "prudent" to check >> that no >> issues will be experienced >> in SFF >> >> to handle fragments. If an SFC heade= r >> is >> prepended for all >> fragments, I'm not sure there >> >> is any particular issue at the S= FF >> level, except if >> stripping/adding >> >> context TLVs depends on the full >> packet (not >> just fragment). It >> is warranted to consider a little >> bit this >> point before declaring >> there is no issue. >> >> >> For point (1), declaring >> fragmentation >> out of scope would be >> meant that >> >> an implementation must be prepared t= o >> receive fragments with or >> without NSH header as this is a >> decision >> that is left to the >> transport encapsulation. This is a >> requirement per se! >> >> >> I won't reiterate all the >> comments I >> have about the current >> wording of >> >> this section. >> >> >> Cheers, Med >> >> -----Message d'origine----- >> De : >> Elzur, Uri >> [mailto:uri.elzur@intel.com >> >> > >] Envoy=C3=A9 >> : lundi 25 avril 2016 >> 08:30 =C3=80 : BOUCADAIR Moh= amed >> IMT/OLN; >> Thomas Narten; >> sfc@ietf.org >> = > >> Objet : RE: [sfc] WG last >> call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> My point is that >> Fragmentation is >> yet another transport relate= d >> issue >> >> that >> >> is beyond the scope of NSH a= nd >> beyond the charter of the WG= , >> so >> it >> >> doesn't >> >> really belong in the draft. >> We are >> providing an advice as >> extending the size of the >> packet may >> lead to fragmentation, but >> as you check RFC 7348 VxLAN, >> which >> my create the same issue, >> you'll find it doesn't even >> >> relate >> >> to it. >> >> Thx >> >> Uri ("Oo-Ree") C: >> 949-378-7568 >> > > >> >> >> -----Original Message----- >> From: sfc >> [mailto:sfc-bounces@ietf.org >> >> > >] On >> Behalf Of >> mohamed.boucadair@orange.com >> >> >> > > Sent: >> Sunday, April 24, 2016 >> 10:32 PM To: Elzur, Uri >> > >> > >>; >> Thomas Narten >> >> > > >>; >> >> sfc@ietf.org >> = > >> Subject: Re: [sfc] WG last >> call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Uri, >> >> That's another option that >> needs to >> be discussed/investigated. >> I'm >> >> afraid >> >> this is not the rationale >> adopted in >> -04 since it includes some >> text >> >> that >> >> is far to be sufficient to >> ensure >> interoperable >> implementations. >> >> BTW, saying that nsh does >> not need >> to deal with fragmentation >> because >> >> it >> >> is transport-independent is >> not IMHO >> a good strategy to adopt >> here >> >> because >> >> it opens the door for >> interoperable >> issues, it may lead to >> sub-optimal implementations >> if the >> sfc information is present >> only in one >> >> fragments, >> >> etc. >> >> My comments are related to t= he >> current text in the -04. >> This text needs >> >> to >> >> be fixed somehow. >> >> Cheers, Med >> >> -----Message >> d'origine----- De : >> Elzur, Uri >> >> [mailto:uri.elzur@intel.com >> >> >] >> Envoy=C3=A9 : dimanche 2= 4 avril >> 2016 17:36 =C3=80 : BOUC= ADAIR >> Mohamed >> IMT/OLN; Thomas Narten; >> sfc@ietf.org >> >> > > Objet : >> RE: [sfc] WG last call f= or >> draft-ietf-sfc-nsh-04.tx= t >> >> Hi Med >> >> I see no need to specify >> the >> exact behavior as NSH is >> transport independent >> i.e. like >> NSH interaction with any >> other >> Transport eh issue of >> Fragmentation is to be >> dealt in >> a way >> that matches the >> mechanisms >> supported by the >> Transport used >> and do not belong in the >> NSH draft >> >> Thx >> >> Uri ("Oo-Ree") C: >> 949-378-7568 >> > > >> >> >> -----Original >> Message----- From: sfc >> >> [mailto:sfc-bounces@ietf.org >> >> >] >> On Behalf Of >> >> mohamed.boucadair@orange.com > > >> >> > > >> Sent: Thursday, April 14= , >> 2016 12:43 AM To: Thomas >> Narten >> > >> >> >>; >> sfc@ietf.org >> >> > > Subject: >> Re: [sfc] WG last call f= or >> draft-ietf-sfc-nsh-04.tx= t >> >> R-, >> >> In addition to other >> pending >> issues raised for this >> draft, I >> would like to raise this >> additional one about >> Section 6. >> >> =3D=3D 6. Fragmentation >> Considerations >> >> NSH and the associated >> transport >> header are "added" to th= e >> encapsulated >> packet/frame. This >> additional information >> increases >> >> the >> >> size of the packet. In >> order >> the ensure proper >> forwarding of >> NSH data, several >> options for >> handling fragmentation a= nd >> re-assembly exist: >> >> 1. Jumbo Frames, when >> supported, enable the >> transport >> of NSH >> and associated transport >> packets >> without requiring >> fragmentation. >> >> 2. Path MTU Discovery >> [RFC1191]"describes a >> technique for >> dynamically discovering >> the >> maximum transmission >> unit (MTU) of >> >> an >> >> arbitrary internet path" >> and can >> be utilized to ensure th= e >> >> the >> >> required packet size is >> used. >> >> 3. [RFC6830] describes >> two >> schemes for >> fragmentation and >> re- >> >> assembly >> >> in section 5.4. =3D=3D >> >> * The text is weak for a >> Standard track document >> that is >> intended to solve the >> problem in >> >> https://tools.ietf.org/html/rfc7498#section- >> >> 2.12. >> >> There should be a clear >> behavior >> to be followed by an >> >> implementation. >> >> Further, I would avoid >> the use >> of words such as "can". >> >> * The text covers only >> fragmentation when it is >> induced >> by SFC >> operations, it does not >> discuss >> the treatment of a >> fragment >> when received in an SFC >> domain. >> IMHO, the draft should >> also >> specify the behavior of >> the >> Classifier with regards = to >> fragments for the sake >> of proper >> SFC operation. Applying >> classification policies >> may >> require the >> >> full packet, not only a >> fragment. >> >> In particular, dedicated >> resources should >> dedicated for >> handling out of order >> fragments. >> Of course, it is out of >> scope >> of this document to >> describe how >> SFs handle fragments. >> >> * If an SFC header is >> prepended >> for all fragments, I'm n= ot >> sure there is any >> particular >> issue at the SFF >> level...except >> if stripping/adding >> context TLVs >> depends on the full pack= et >> (not just fragment). It = is >> warranted to consider a >> little bit >> this point before >> declaring there >> >> is >> >> no issue. >> >> >> * The text states "sever= al >> options". This may be >> interpreted >> as if implementing one >> of them >> is sufficient...which is >> not >> true. The first two poin= ts >> contribute to minimize t= he >> fragmentation risk, but >> fragmentation may still = be >> experienced >> (e.g., other shims are >> prepended >> by other nodes for some >> other >> purposes, nested nsh, >> etc.) >> >> * The first two points >> have >> nothing to do with >> reassembly. >> >> * The support of jumbo > > --001a11408aa42978c305318b6b4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+Sm9lbCw8ZGl2Pjxicj48L2Rpdj48ZGl2PklmIHRoaXMgaXMgYWN0dWFs bHkgaG93IHNlY3Rpb24gNiBzaG91bGQgd29yaywgdGhlcmUgc2hvdWxkIGJlIHRleHQgdG8gbWFr ZSBpdCBjbGVhci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PknigJltIGN1cmlvdXMgaWYgYW55 IG9mIHRoZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBkcmFmdCBoYXZlIGltcGxl bWVudGVkIGZyYWdtZW50YXRpb24sIGFuZCBpZiBzbywgaWYgdGhleeKAmXJlIGludGVyb3BlcmFi bGUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFua3MsPC9kaXY+PGRpdj5BbmR5PC9kaXY+ PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBBcHIgMjgsIDIwMTYgYXQgODo0NSBBTSwgSm9lbCBN LiBIYWxwZXJuIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8L3Nw YW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij5UaGUgZnJhZ21lbnRhdGlvbiBmaWVsZHMgc2hvd24gaW4gYWxsIHRoZSBkaWFncmFtcyBpbiB0 aGUgTElTUCBzcGVjIGFyZSB0aGUgSVAgZnJhZ21lbnRhdGlvbiBmaWVsZHMuwqAgVGhlcmUgaXMg bm8gTElTUCBmcmFnbWVudGF0aW9uIGluZm9ybWF0aW9uLjxicj4NCjxicj4NClRodXMsIGluIHBh cmFsbGVsLCBJIGRvbiYjMzk7dCBzZWUgbmF5IG5lZWQgZm9yIE5TSCB0byBoYXZlIGZyYWdtZW50 YXRpb24gaW5mb3JtYXRpb24uPGJyPg0KPGJyPg0KWWVzLCB0aGVyZSBpcyBhbiBpbXBsaWNhdGlv bi7CoCBJbm5lciBwYWNrZXQgZnJhZ21lbnRhdGlvbiBjYW4gb25seSBiZSB1c2VkIGFzIGEgcmVz cG9uc2UgdG8gYW4gTVRVIGlzc3VlIHdoZW4gdGhlIGlubmVyIHBhY2tldCBmb3JtYXQgc3VwcG9y dHMgZnJhZ21lbnRhdGlvbi7CoCBBcyBmYXIgYXMgSSBrbm93LCB0aGF0IGlzIG9ubHkgSVB2NC48 YnI+DQo8YnI+DQpPdXRlciAodHJhbnNwb3J0KSBwYWNrZXQgZnJhZ21lbnRhdGlvbiBjYW4gb25s eSBiZSB1c2VkIHRvIGFkZHJlc3MgdGhlIE1UVSBpc3N1ZSB3aGVuIHRoZSBvdXRlciAodHJhbnNw b3J0KSBwYWNrZXQgc3VwcG9ydHMgZnJhZ21lbnRhdGlvbiwgdGhhdCBiZWluZyBJUHY0IGFuZCBJ UHY2Ljxicj4NCjxicj4NCk5vdGUgdGhhdCBhIGNvcm9sbGFyeSBvZiB0aGlzIGlzIHRoYXQgU0ZD IHNpbXBseSBwdXRzIE5TSCBoZWFkZXJzIG9uIHRoZSBwYWNrZXRzIGl0ICh0aGUgY2xhc3NpZmll ciBvciBTRkYpIHNlbmRzLjxicj4NCjxicj4NCllvdXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+DQpP biA0LzI4LzE2IDg6MTcgQU0sIEFuZHJldyBHLiBNYWxpcyB3cm90ZTo8YnI+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkpvZWwsPGJyPg0KPGJyPg0KVGhl IGRpYWdyYW1zIGluIHNlY3Rpb24gNiBvZiBSRkMgNjgzMCBhcmUgY29udHJvbCBwbGFuZSwgbm90 IGRhdGEgcGxhbmUuPGJyPg0KVGhlIGRhdGEgcGxhbmUgZGlhZ3JhbXMgYXJlIGluIHNlY3Rpb24g NS48YnI+DQo8YnI+DQpCdXQgdGhlIG92ZXJyaWRpbmcgcXVlc3Rpb24gaXMgLSB3aXRob3V0IGFu eSBmaWVsZHMgaW4gdGhlIE5TSCBoZWFkZXIgdG88YnI+DQpzZXF1ZW5jZSBmcmFnbWVudHMsIGhv dyBjYW4gdGhlIGZyYWdtZW50cyBiZSBjb3JyZWN0bHkgcmVhc3NlbWJsZWQ/PGJyPg0KPGJyPg0K Q2hlZXJzLDxicj4NCkFuZHk8YnI+DQo8YnI+DQpPbiBXZWQsIEFwciAyNywgMjAxNiBhdCA3OjQ2 IFBNLCBKb2VsIEhhbHBlcm4gRGlyZWN0PGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpqbWguZGly ZWN0QGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaC5kaXJlY3RAam9lbGhhbHBl cm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxw ZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaC5kaXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPiZn dDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCsKgIMKgIFRoZSBMSVNQIGhlYWRlciBkb2VzIG5vdCBo YXZlIGEgZnJhZ21lbnQgZmxhZyBvciBmcmFnbWVudCBvZmZzZXQuPGJyPg0KwqAgwqAgVGhlIGRp YWdyYW1zIGluIHNlY3Rpb24gNiBpbmNsdWRlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW5nIGhlYWRl cjxicj4NCsKgIMKgICh0aGUgZXF1aXZhbGVudCBvZiB0aGUgdHJhbnNwb3J0IGhlYWRlciBpbiBT RkMuKcKgIFllcywgdGhlIHRleHQgaXMgYTxicj4NCsKgIMKgIGxpdHRsZSBoYXJkIHRvIGZvbGxv dyBpbiB0aGlzIHJlZ2FyZC7CoCBUaGUgTElTUCB3b3JraW5nIGdyb3VwIGlzPGJyPg0KwqAgwqAg Z29pbmcgdG8gYmUgcmV3cml0aW5nIFJGQyA2ODMwIGFzIHBhcnQgb2YgbW92aW5nIHRvIHN0YW5k YXJkcyB0cmFjay48YnI+DQo8YnI+DQrCoCDCoCBTbyB0aGVyZSBpcyBubyBkaWZmZXJlbmNlIGlu IHRoaXMgcmVnYXJkIGJldHdlZW4gTlNIIGFuZCBMSVNQLjxicj4NCjxicj4NCsKgIMKgIFlvdXJz LDxicj4NCsKgIMKgIEpvZWw8YnI+DQo8YnI+DQrCoCDCoCBPbiA0LzI3LzE2IDc6MDIgUE0sIEFu ZHJldyBHLiBNYWxpcyB3cm90ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBKb2VsIGV0IGFsLDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIEFsbCB0aGlzIHRhbGsgYWJvdXQgZnJhZ21lbnRhdGlvbiBw cm9tcHRlZCBtZSB0byByZS1yZWFkIHNlY3Rpb248YnI+DQrCoCDCoCDCoCDCoCA2IG9mPGJyPg0K wqAgwqAgwqAgwqAgdGhlIGRyYWZ0LCB3aGljaCByZWNvbW1lbmRzIChhcyBvcHRpb24gMykgdXNp bmcgdGhlIHByb2NlZHVyZXMgaW48YnI+DQrCoCDCoCDCoCDCoCBzZWN0aW9uIDUuNCBvZiBSRkMg NjgzMCAocHJlc3VtYWJseSB3aXRoIHRoZSDigJxOU0ggaGVhZGVy4oCdPGJyPg0KwqAgwqAgwqAg wqAgcmVwbGFjaW5nIHRoZTxicj4NCsKgIMKgIMKgIMKgIOKAnExJU1AgaGVhZGVy4oCdIGluIHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2VkdXJlcyBpbiB0aGF0IHNlY3Rpb24pLjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIFNvIHRoYXQgbGVkIG1lIHRvIHJlYWQgdGhhdCBzZWN0aW9uIChhbmQg dGhlIExJU1AgaGVhZGVyPGJyPg0KwqAgwqAgwqAgwqAgZGVmaW5pdGlvbiBpbjxicj4NCsKgIMKg IMKgIMKgIHNlY3Rpb24gNS4xKSwgYW5kIEkgc2VlIHRoYXQgTElTUCBkb2VzIGZyYWdtZW50YXRp b24gYW5kIHJlYXNzZW1ibHk8YnI+DQrCoCDCoCDCoCDCoCBpZGVudGljYWxseSB0byBJUHY0LCB1 c2luZyB0aGUgRnJhZ21lbnQgT2Zmc2V0IGZpZWxkIHNvIHRoYXQ8YnI+DQrCoCDCoCDCoCDCoCBm cmFnbWVudHM8YnI+DQrCoCDCoCDCoCDCoCBjYW4gYmUgY29ycmVjdGx5IHJlYXNzZW1ibGVkIGlu IHRoZSBwcm9wZXIgb3JkZXIuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgSG93ZXZlciwgdGhlIE5T SCBIZWFkZXIgZG9lc27igJl0IGhhdmUgYSBGcmFnbWVudCBPZmZzZXQgZmllbGQgb3IgYW55PGJy Pg0KwqAgwqAgwqAgwqAgb3RoZXIgd2F5IHRvIG9yZGVyIHRoZSBmcmFnbWVudHMuPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgU28gaG93IGNhbiB0aGUgcHJvY2VkdXJlcyBpbiBTZWN0aW9uIDUuNCBv ZiA2ODMwIGJlIHVzZWQ/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgVGhhbmtzLDxicj4NCsKgIMKg IMKgIMKgIEFuZHk8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBPbiBXZWQsIEFwciAyNywgMjAxNiBh dCA0OjE5IFBNLCBKb2VsIE0uIEhhbHBlcm48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBl cm4uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t IiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBl cm4uY29tPC9hPiZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCBCb3RoIG1ldGhvZHMgYXJlIHZhbGlkLCBhbmQgYm90aCBkZXBlbmQgdXBvbiBkZXRhaWxzIG9m IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHVuZGVybHlpbmcgcGFja2V0IGFuZCB0aGUgdHJh bnNwb3J0LsKgIEFzIHN1Y2gsIEkgZG9uJiMzOTt0IHNlZTxicj4NCsKgIMKgIMKgIMKgIHdoeSB0 aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgZG9jdW1lbnQgYmVuZWZpdHMgZnJvbSBkZXNjcmli aW5nIHRoZW0sIG11Y2ggbGVzcyB3aHkgaXQ8YnI+DQrCoCDCoCDCoCDCoCBzaG91bGQgbWFyazxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIG9uZSBtZXRob2QgYXMgYSAmcXVvdDtzaG91bGQmcXVvdDsu wqAgSW1wbGVtZW50YXRpb24gZGV0YWlscyBhcmUgbGlrZWx5PGJyPg0KwqAgwqAgwqAgwqAgdG8g YmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBtb3JlIHNpZ25pZmljYW50IHRoYW4gYW55IGJpdCBj b25zdW1wdGlvbiBkaWZmZXJlbmNlIGJldHdlZW48YnI+DQrCoCDCoCDCoCDCoCB0aGUgdHdvPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgYWx0ZXJuYXRpdmVzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIFlvdXJzLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIEpvZWw8YnI+DQo8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCBPbiA0LzI3LzE2IDM6NDAgUE0sIExpbmRhIER1bmJhciB3cm90 ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIHN1Z2dlc3QgYWRkaW5nIHRo ZSBmb2xsb3dpbmcgcGFyYWdyYXBocyBhZnRlciB0aGU8YnI+DQrCoCDCoCDCoCDCoCBCdWxsZXQg MyBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBTZWN0aW9uIDYgRnJhZ21lbnRh dGlvbiBDb25zaWRlcmF0aW9uIHRvIG1ha2UgdGhlPGJyPg0KwqAgwqAgwqAgwqAgcHJvY2Vzczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1vcmUgY2xlYXIgYW5kIGxlc3MgY29udHJvdmVy c2lhbDo8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFJGQzY4MzAgZGVzY3JpYmVzIHRoZSBmcmFnbWVudGF0aW9uIG1ldGhvZCBvZiBicmVha2luZyB0 aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvcmlnaW5hbCBwYWNrZXQgaW50byB0d28g ZXF1YWwgc3ViLWZyYW1lcyBhbmQgZW5jYXBzdWxhdGluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFtMSVNQIEhlYWRlciArIFRyYW5zcG9ydCBoZWFkZXJdIHRvIGVhY2ggc3ViLWZyYW1l Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElmIExJU1AgZnJhZ21lbnRhdGlv biBbUkZDNjgzMCBTZWN0aW9uIDUuNF0gaXMgdXNlZCwgdGhlPGJyPg0KwqAgwqAgwqAgwqAgW1NG Qzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhlYWRlciArIFRyYW5zcG9ydCBIZWFkZXJd IHdpbGwgYmUgYWRkZWQgdG8gZWFjaCBoYWxmPGJyPg0KwqAgwqAgwqAgwqAgZnJhbWUgKG9yPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIG9yaWdpbmFsIGRhdGEgZnJhbWUpLiBBcyB0 aGUgVHJhbnNwb3J0IEhlYWRlciBpczxicj4NCsKgIMKgIMKgIMKgIHRlcm1pbmF0ZWQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBieSB0aGUgbmV4dCBTRkYgbm9kZSYjMzk7cyB0dW5uZWwg dHJhbnNwb3J0IGxheWVyLCB0aGU8YnI+DQrCoCDCoCDCoCDCoCBjb21iaW5lZCB0d288YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdWItZnJhbWVzIHdpbGwgaGF2ZSB0d28gU0ZDIEhlYWRl cnMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlcmVmb3JlLCB0aGUgZnJh Z21lbnRhdGlvbiBmb3IgTlNIIGVuY2Fwc3VsYXRlZCBkYXRhIGZyYW1lPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgc2hvdWxkIGJlIGRvbmUgY29tcGxldGVseSBieSB0aGUgbm9kZSB0dW5u ZWwgdHJhbnNwb3J0PGJyPg0KwqAgwqAgwqAgwqAgbGF5ZXIsPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgd2hpY2ggc2hvdWxkIGJyZWFrIHRoZSBbU0ZDICsgb3JpZ2luYWwgcGFja2V0XSBp bnRvIHR3bzxicj4NCsKgIMKgIMKgIMKgIGVxdWFsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc3ViLWZyYW1lcyBhbmQgZWFjaCBzdWItZnJhbWUgYmVpbmcgZW5jYXBzdWxhdGVkIHdpdGgg aXRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVzcGVjdGl2ZSB0dW5uZWwgaGVhZGVy LsKgIFRoZSBuZXh0IFNGRiBub2RlJiMzOTtzIHR1bm5lbDxicj4NCsKgIMKgIMKgIMKgIHRyYW5z cG9ydDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxheWVyIHNob3VsZCBjb21iaW5lIHRo ZSB0d28gc3ViLWZyYW1lcyBiZWZvcmUgc2VuZGluZzxicj4NCsKgIMKgIMKgIMKgIHRvIHRoZTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG5leHQgbm9kZS48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBC eSB0aGUgd2F5LCB0aGVyZSBhcmUgdG8gdHlwbyBpbiB0aGUgU2VjdGlvbiA2Ojxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIDNyZCBsaW5lOiAmcXVvdDtJbiBvcmRlciB0aGUmcXVvdDsgPT0m Z3Q7ICZxdW90O0luIG9yZGVyIHRvJnF1b3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg TGFzdCBsaW5lIG9mIEJ1bGxldCAyOiBleHRyYSAmcXVvdDt0aGUmcXVvdDsgaW4gdGhlICZxdW90 O3V0aWxpemVkIHRvPGJyPg0KwqAgwqAgwqAgwqAgZW5zdXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgdGhlIHRoZSByZXF1aXJlZCBwYWNrZXQmcXVvdDsuPGJyPg0KPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSG9wZSBpdCBoZWxwcy48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBMaW5kYTxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgRnJvbTogPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxi cj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7Jmd0Ozxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDCoCDC oCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7 Jmd0O108YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZW50OiBXZWRuZXNkYXksIEFwcmls IDI3LCAyMDE2IDEyOjQwIEFNPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVG86IEpvZWwg TS4gSGFscGVybjsgTGluZGEgRHVuYmFyOyBFbHp1ciwgVXJpOzxicj4NCsKgIMKgIMKgIMKgIDxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Zj QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBTdWJqZWN0OiBSRTogW3NmY10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKg IMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBIaSBKb2VsLCBhbGwsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgUGxlYXNlIHNlZSBpbmxpbmUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Q2hlZXJzLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE1lZDxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS08 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEZSA6IEpvZWwgTS4gSGFscGVybiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFu ayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpt aEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDtdIEVudm95w6kgOiBtYXJkaSAyNjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGF2cmlsIDIwMTYgMTk6MTggw4AgOiBMaW5kYSBE dW5iYXI7IEJPVUNBREFJUiBNb2hhbWVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgSU1UL09MTjsgRWx6dXIsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVXJp OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYu b3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsmZ3Q7IE9iamV0IDogUmU6IFtzZmNdIFdHPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBXaXRoIHJlZ2FyZCB0byBUcmFuc3BvcnQg dHVubmVsIGZyYWdlbWVudGF0aW9uLCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgc2VlbXM8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbiBpc3N1ZTxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGZvciB0aGUgdHJhbnNwb3J0IHByb3RvY29sLsKgIEkgZG9uJiMzOTt0 IGFjdHVhbGx5IG9iamVjdDxicj4NCsKgIMKgIMKgIMKgIHRvIGE8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBzZW50ZW5jZSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBidXQgaXQgZG9lcyBub3Qgc2VlbSB0aGF0IGl0IHdpbGwgYWNjb21wbGlzaCBhbnl0aGlu Zy48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVkXSBJIHdvdWxk IGxpa2UgdG8gc2VlIHNvbWUgdGV4dCBhZGRlZCB0byB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2l0aCByZWdhcmQgdG8gcGFja2V0cyBm cmFnbWVudGVkIGJ5IHRoZSBzb3VyY2UsIEk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBjb21wbGV0ZWx5IGRpc2FncmVlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgd2l0aCB5b3VyIGFzc2VydGlvbi7CoCBJZiBhbiBTRkYgd2VyZSB0byByZWFzc2VtYmxlIHRo ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBhY2tldHMsIHRoYXQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b3VsZCBiZSBhIHZpb2xhdGlvbiBvZiBpdHMg am9iLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtNZWRdIEkgYWdy ZWUgd2l0aCB5b3UuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlcmUg aXMgbm8gcmVhc29uIGZvciBhbiBTRkYgdG88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCByZWFzc2VtYmxlIGEgcGFja2V0IGZyYWdtZW50ZWQgYnkgdGhlIHNvdXJjZS7C oCBUaGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjbGFzc2lmaWVyIG1heSBo YXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gZG8gc29tZSBpbnRlcmVz dGluZyB0aGluZ3MgaW4gb3JkZXIgdG8gcHJvcGVybHk8YnI+DQrCoCDCoCDCoCDCoCBjbGFzc2lm eTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1Y2NlZWRpbmc8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMsIGJ1dCB0aGF0IGlzIGFuIGltcGxl bWVudGF0aW9uIGlzc3VlIChtb3N0PGJyPg0KwqAgwqAgwqAgwqAgY29tbW9ubHk8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhZGRyZXNzZWQgd2l0aCB2aXJ0dWFsIHJlYXNzZW1i bHksIHdoaWNoIGRvZSBzbm90PGJyPg0KwqAgwqAgwqAgwqAgZGVsYXkgdGhlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzLinCoCBXZSBkb24mIzM5O3Qgc3BlY2l0 eSB0aGF0Ljxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtNZWRdIFN0 aWxsLCB0aGUgZXh0ZXJuYWwgYmVoYXZpb3Igb2YgdGhlIGNsYXNzaWZpZXI8YnI+DQrCoCDCoCDC oCDCoCBuZWVkcyB0byBiZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsZWFyIGluIHRo ZSBkb2N1bWVudC4gSSBkb24mIzM5O3QgZmluZCBhbnkgdGV4dCBpbiB0aGU8YnI+DQrCoCDCoCDC oCDCoCBkcmFmdCBzYXlpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmb3IgaW5zdGFu Y2UgdGhhdCBhbiBOU0ggaGVhZGVyIG11c3QgYmUgcHJlc2VudCBpbiBhbGw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMuIChUaGVyZSBzb21lIHByb2Nlc3NpbmcgdGhhdCBt aWdodCBiZSBuZWVkZWQ8YnI+DQrCoCDCoCDCoCDCoCBhdCB0aGU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBTRkYgdG8gJnF1b3Q7ZG8gaXRzIGpvYiZxdW90OyB3aXRoIHJlZ2FyZHMgdG8g ZnJhZ21lbnRzIChyZWNlaXZlPGJyPg0KwqAgwqAgwqAgwqAgb3V0IG9mPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgb3JkZXIgZnJhZ21lbnRzICsgZm9yd2FyZGluZyBwb2xpY3kgb24gdGhl IGZ1bGwgcGFja2V0KS4pPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgSWYgYW4gU0YgbmVlZHMgdG8gcmVhc3NlbWJsZSBmcmFnbWVudHMgdG8gZG8gaXRzPGJy Pg0KwqAgwqAgwqAgwqAgam9iLCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaXMgdXAgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgU0YuwqAg U29tZSB3aWxsIG5lZWQgdG8gYWN0dWFsbHkgcmVhc3NlbWJsZS48YnI+DQrCoCDCoCDCoCDCoCBT b21lIHdpbGw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBuZWVkIHRvPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGVyZm9ybSB2aXJ0dWFsIHJlYXNzZW1ibHks IGFuZCBzb21lIHdpbGwgaGFwcGlseTxicj4NCsKgIMKgIMKgIMKgIHByb2Nlc3MgdGhlPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzLsKgIEkgY2FuIG5vdCBzZWUg d2hhdCB0aGUgTlNIIGRvY3VtZW50IGNvdWxkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgcG9zc2libHkgbWFuZGF0ZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBbTWVkXSBGdWxseSBhZ3JlZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBZb3Vycyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBKb2VsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gNC8yNi8x NiAxMTo0NyBBTSwgTGluZGEgRHVuYmFyIHdyb3RlOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIEpvZWwsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIGFkZCB0aGUgZGVz Y3JpcHRpb248YnI+DQrCoCDCoCDCoCDCoCBvbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBmb2xsb3dpbmcgdHdvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbiBzY2VuYXJpb3M6PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLSBUcmFuc3BvcnQgdHVubmVsIGdlbmVyYXRl ZCBmcmFnbWVudGF0aW9uOiBXaGVuPGJyPg0KwqAgwqAgwqAgwqAgYSBwYWNrZXQ8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudGF0aW9uIGlzIGNhdXNlZCBi eSB0cmFuc3BvcnQgdHVubmVsPGJyPg0KwqAgwqAgwqAgwqAgKGkuZS4gdmFyaW91czxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVuY2Fwc3VsYXRpb25zKSwgdGhlIHRl cm1pbmF0aW9uIHBvaW50IG9mIHRoZTxicj4NCsKgIMKgIMKgIMKgIHRyYW5zcG9ydDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHR1bm5lbCBpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlc3BvbnNpYmxlIGZvciByZS1hc3NlbWJsaW5n IHRoZSBmcmFnbWVudGVkPGJyPg0KwqAgwqAgwqAgwqAgcGllY2VzIG9mPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIHBhY2tldC48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTaW5jZSB0aGVyZSB3b24mIzM5O3QgYmUgYW55IFNGRiBu b2RlcyBpbiBiZXR3ZWVuIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFRyYW5zcG9ydCBUdW5uZWwsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgdGhlIHR1bm5lbCBnZW5lcmF0ZWQgZnJhZ21lbnRhdGlvbiBkb2VzIG5vdDxicj4NCsKg IMKgIMKgIMKgIHJlcXVpcmUgYW55PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYWN0aW9ucyBieTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFNGRiBub2RlcyBvciBTRiBub2Rlcy48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAtIFNvdXJjZSBub2RlIGdlbmVyYXRlZCBmcmFnbWVudGF0aW9u IChhZnRlcjxicj4NCsKgIMKgIMKgIMKgIGFkZGluZyBvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBOU0g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBoZWFkZXIpOiBXaGVuIGZyYWdtZW50YXRpb24gaGFzIHRvIGJlIHBlcmZvcm1l ZDxicj4NCsKgIMKgIMKgIMKgIGZvciBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgcGFja2V0IGJlaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgZW5jYXBzdWxhdGVkIHdpdGggdGhlIE5TSCBoZWFkZXIsIGVpdGhlciB0aGU8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbnRlcm1lZGlhdGUgU0ZGIG5vZGVz PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3IgdGhlIFNGIG5vZGVz IGhhdmUgdG8gYmUgYWJsZSB0byByZWFzc2VtYmxlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50ZWQgcGllY2VzLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENoZWVycyw8YnI+ DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBMaW5kYTxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIEZyb206IEpvZWwgTS4gSGFscGVybjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCsKg IMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0 O10gU2VudDogVHVlc2RheSwgQXByaWwgMjYsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgMjAxNiAxMDozMyBBTTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFRvOiBMaW5kYSBEdW5iYXI7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJy Pg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208L2E+Jmd0OyZndDs7IEVsenVyLCBVcmk7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z ZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3Nm Y10gV0c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsYXN0IGNhbGwg Zm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1z ZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFJlLXJlYWRpbmcgeW91ciBub3RlLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHlvdSBhcmU8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWZlcnJpbmcgb25seSB0bzxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBjYXNlIG9mIHRyYW5z cG9ydCBnZW5lcmF0ZWQgZnJhZ21lbnRhdGlvbiBvZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBvdXRlciBwYWNrZXQuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSSBoYWQgYXNzdW1lZCB5b3Ugd2VyZSBub3QgdGFsa2luZyBhYm91 dCB0aGF0LDxicj4NCsKgIMKgIMKgIMKgIHNpbmNlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHJlc3VsdGluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGZyYWdtZW50cyB3aWxsIG5vdCBhbGwgaGF2ZSBOU0ggaGVhZGVycy7CoCBB czxicj4NCsKgIMKgIMKgIMKgIHdpdGggYW55IHR1bm5lbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHRlY2hub2xvZ3ksIGlmIHRoZSB0dW5uZWwgY2hvb3NlcyB0byBm cmFnbWVudCBhdCBpdHM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBs YXllciwgdGhlbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0 dW5uZWwgaXMgcmVzcG9uc2libGUgZm9yIHJlYXNzZW1ibHkuwqAgVGhhdCB3b3VsZCBiZTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGludmlzaWJsZSB0bzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBTRkYuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgWW91cnMsIEpvZWw8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiA0LzI2LzE2IDExOjEwIEFNLCBM aW5kYSBEdW5iYXIgd3JvdGU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgQWdyZWUgd2l0aCBNZWQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRXZlbiBpZiBlYWNoIGZyYWdtZW50IHBpZWNlIG9m IGEgcGFja2V0IHdpdGggTlNIPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgaGVhZGVyIGNhcnJpZXMgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgTlNIIGhlYWRlciwgdGhlIGludGVybWVkaWF0ZSBTRkYgbm9kZXMg c3RpbGw8YnI+DQrCoCDCoCDCoCDCoCBuZWVkIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgcHV0IHRvZ2V0aGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWxsIHRoZSBmcmFnbWVudHMgdG9nZXRoZXIgYmVmb3Jl IHBhc3Npbmc8YnI+DQrCoCDCoCDCoCDCoCB0aGUgd2hvbGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkYXRhIGZyYW1lIHRvPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIFNGLjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIExpbmRhPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gRnJvbTogc2ZjPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPjxi cj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDtd PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gQmVoYWxm IE9mIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDC oCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t IiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyZndDsgU2Vu dDogTW9uZGF5LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IEFwcmlsIDI1LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IDIwMTYgOTo0MiBBTSBUbzogRWx6dXIsIFVyaTsgSm9lbCBNLiBIYWxwZXJuOzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0OyZndDsgU3ViamVjdDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIGRyYWZ0 LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBSZS0sPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSG93IGRvIHlvdSBpbnN0cnVjdCB0aGUgdHJhbnNwb3J0IGxheWVy IHRvPGJyPg0KwqAgwqAgwqAgwqAgQUxXQVlTPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgcHJlcGVuZCBhbiBOU0g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoZWFkZXIgZXZlbiBmb3IgZnJhZ21lbnRzPyBPciB5b3Ug ZG9uJiMzOTt0IGNhcmU8YnI+DQrCoCDCoCDCoCDCoCBhYm91dCB0aGF0Pzxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoYW5rIHlvdS48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1l ZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS0gRGUgOiBFbHp1ciwgVXJpPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5l bHp1ckBpbnRlbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRl bC5jb208L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5jb20i IHRhcmdldD0iX2JsYW5rIj51cmkuZWx6dXJAaW50ZWwuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKg ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5jb20iIHRhcmdldD0i X2JsYW5rIj51cmkuZWx6dXJAaW50ZWwuY29tPC9hPiZndDsmZ3Q7XSBFbnZvecOpIDogbHVuZGkg MjU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBh dnJpbCAyMDE2IDE2OjI2IMOAPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb2VsIE0uPGJyPg0K wqAgwqAgwqAgwqAgSGFscGVybjs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsmZ3Q7IE9iamV0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBSRTogW3Nm Y10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBNZWQ8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOb3Qg dG8gcmVwZWF0IG15IHBvc2l0aW9uLCBidXQgSSYjMzk7bGwgZG88YnI+DQrCoCDCoCDCoCDCoCBp dCBhbnlob3c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCA6LSkgQXMgTlNIIGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgKk5PVCogYSB0cmFuc3BvcnQsIGRlYWxpbmcgd2l0aDxicj4NCsKgIMKg IMKgIMKgIGZyYWdtZW50YXRpb24gaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBsZWZ0IHRvIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRyYW5zcG9ydCB1c2VkLjxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBtb2RlbCBJ IHVzZSBmb3IgTlNILCBpcyBiYXNpY2FsbHk8YnI+DQrCoCDCoCDCoCDCoCBzaW1pbGFyIHRvPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVlhMQU4g LiBJdCBpcyBhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG92ZXJseS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBUaHg8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBVcmkgKCZxdW90O09vLVJlZSZxdW90OykgQzogPGEgaHJl Zj0idGVsOjk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsi Pjk0OS0zNzgtNzU2ODwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7dGVsOjxhIGhyZWY9InRlbDo5 NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0OTM3ODc1NjgiIHRhcmdldD0iX2JsYW5rIj45NDktMzc4 LTc1Njg8L2E+Jmd0OyAmbHQ7dGVsOjxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIr MTk0OTM3ODc1NjgiIHRhcmdldD0iX2JsYW5rIj45NDktMzc4LTc1Njg8L2E+ICZsdDt0ZWw6PGEg aHJlZj0idGVsOjk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxh bmsiPjk0OS0zNzgtNzU2ODwvYT4mZ3Q7Jmd0Ozxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIEZyb206IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAg wqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0Bp ZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsmZ3Q7XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE9uIEJlaGFsZiBPZjxicj4NCsKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PC9hPjxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPiZndDsmZ3Q7IFNlbnQ6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTW9uZGF5LCBBcHJpbCAyNSw8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2IDc6MTggQU0gVG86IEpv ZWwgTS4gSGFscGVybjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7Jmd0 OyZndDs7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRm Lm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5v cmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0IGNh bGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhpIEpvZWwsPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUGxlYXNlIHNlZSBpbmxp bmUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgQ2hlZXJzLCBNZWQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU1lc3NhZ2UgZCYjMzk7b3JpZ2luZS0tLS0t IERlIDo8YnI+DQrCoCDCoCDCoCDCoCBKb2VsIE0uIEhhbHBlcm48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDtdIEVudm95w6kgOiBsdW5kaTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IDI1IGF2cmlsIDIwMTYgMTU6NDggw4A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47PGJy Pg0KwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsmZ3Q7IE9iamV0IDogUmU6 IFtzZmNdIFdHPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgSWYgSSBhbSB1bmRlcnN0YW5kaW5nIHlvdSBjb3JyZWN0bHk8YnI+DQrCoCDCoCDCoCDCoCBN ZWQsIHlvdTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGFyZSBhc2tpbmcgdGhhdCB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggZHJhZnQgc3BlY2lmeSBob3cgc2Vy dmljZSBjaGFpbmluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNob3VsZCBjb3BlIHdpdGggcGFja2V0czxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaGF2ZSBiZWVu IGZyYWdtZW50ZWQ/PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gVG8gYmUgYWNjdXJhdGUsIEkmIzM5O20gYXNraW5n IHRvIGFzc2Vzczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHdoZXRoZXIgdGhlcmUgYXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1wbGljYXRpb25zLiBJZiB0aGVyZSBhcmUsIHRoZW4gdGhl IGRyYWZ0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc2hvdWxkIGJlIHVwZGF0ZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhY2NvcmRpbmdseS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0gsIGFuZCB0aGUgU0ZGIGZ1 bmN0aW9uYWxpdHksIGRvZXM8YnI+DQrCoCDCoCDCoCDCoCBub3QgY2FyZS48YnI+DQo8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVk XSBJJiMzOTttIG5vdCB0aGF0IHN1cmUuIFNvbWUgdHlwaWNhbDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGltcGxpY2F0aW9ucyBhcmUgbGlzdGVk PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmVs b3c6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgKiBTRkY6IElmIHRoZSBOU0ggaGVhZGVyIGlzIHByZXNlbnQgb25seTxicj4NCsKgIMKg IMKgIMKgIGluIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGEgZnJhZ21lbnQgYnV0IFNGRjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRpZG4mIzM5O3QgbWFpbnRhaW5lZCBhIHN0YXRlLCBz dWJzZXF1ZW50PGJyPg0KwqAgwqAgwqAgwqAgZnJhZ21lbnRzPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd29uJiMzOTt0IGJlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXBwcm9wcmlhdGVseSBw cm9jZXNzZWQuICogU0ZDLWF3YXJlPGJyPg0KwqAgwqAgwqAgwqAgZnVuY3Rpb246PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWYgcHJlcGVuZGlu ZyBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Y29udGV4dCBpbmZvcm1hdGlvbiBkZXBlbmRzIG9uIHRoZSBmdWxsPGJyPg0KwqAgwqAgwqAgwqAg cGFja2V0LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIG5vdCBvbmx5IGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBmcmFnbWVudC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJdCBqdXN0IGRvZXMgaXRzIGpvYi48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVkXSB3aGlj aCBtYXkgYmUgZGlzdHVyYmVkIGluIHNvbWU8YnI+DQrCoCDCoCDCoCDCoCBzaXR1YXRpb25zPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgbGlz dGVkIGluIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGV4YW1wbGVzIGFib3ZlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEluZ3Jlc3MgYW5kIGludGVybWVkaWF0ZSBj bGFzc2lmaWVycyBtYXk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBjb3BlIHdpdGggZnJhZ21lbnRzIGluPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW55IG51bWJlciBvZiB3 YXlzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFNwZWNpZnlpbmcgc3VjaCBpcyBjbGVhcmx5IG91dCBvZiBzY29wZTxicj4NCsKgIMKg IMKgIMKgIGZvciB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgZHJhZnQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gVGhlIHB1cnBvc2UgaXMgbm90IHRvIHNwZWNpZnkg dGhlPGJyPg0KwqAgwqAgwqAgwqAgaW50ZXJuYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbXBsZW1lbnRhdGlvbjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRldGFpbHMgYnV0IHRoZSBleHRl cm5hbCBiZWhhdmlvciBvZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBjbGFzc2lmaWVyIGZ1bmN0aW9uIHdoZW48YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpdCBjb21lcyB0byBoYW5kbGUg ZnJhZ21lbnRzLiBUaGF0PGJyPg0KwqAgwqAgwqAgwqAgYmVoYXZpb3IgbWF5PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGF2ZSBhbiBpbmNpZGVu Y2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBv biBTRkYsIGluIHBhcnRpY3VsYXIuIFRoZSBwdXJwb3NlIGlzIG5vdCB0bzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlY29tbWVuZCB0aGUgbWF4 aW11bTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHJlc291cmNlcyB0byBiZSBkZWRpY2F0ZWQgdG8gb3V0IG9mIG9yZGVyPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzIG5vciB0aGU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aW1l b3V0IHRvIGNhY2hlIHRob3NlOyB0aGVzZTxicj4NCsKgIMKgIMKgIMKgIGNvbnNpZGVyYXRpb25z IGFyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IG9mIGNvdXJzZSBvdXQgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzY29wZS4gTmV2ZXJ0aGVsZXNzLCBhbiBpbXBsZW1lbnRhdGlvbjxicj4N CsKgIMKgIMKgIMKgIHNob3VsZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIG9mZmVyIGEgY29uZmlndXJhYmxlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGFyYW1ldGVyIHNvIHRoYXQgYW4gb3Bl cmF0b3IgdHdlYWsgdGhvc2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBhY2NvcmRpbmcgdG8gaXRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29udGV4dC48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIHN1cHBvc2Ugb25l IGNvdWxkIHdyaXRlIGFuPGJyPg0KwqAgwqAgwqAgwqAgaW5mb3JtYXRpb25hbDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0IG9u IHBvc3NpYmxlIHdheXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBvZiBjb3BpbmcuwqAgVGhlIElFVEYgaGFzIG5vdCB1c3VhbGx5PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cHVibGlzaGVkIHN1Y2guPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgU2VydmljZSBmdW5jdGlvbnMgaGF2ZSB0byBjb3BlIHdpdGg8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBm cmFnbWVudGVkIHBhY2tldHMganVzdCBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZXkgaGFkIHRvIGJlZm9yZSB0aGUgYWR2ZW50 IG9mIE5TSCwgc288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBkZXNjcmliaW5nIHRoYXQgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjbGVhcmx5IG5vdCBuZWVkZWQgaGVy ZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBbTWVkXSBUaGUgYWR2ZW50IG9mIE5TSCBoYXMgdGhlIGZvbGxvd2luZzxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGltcGxpY2F0 aW9uczogKiBpdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGV4YWNlcmJhdGVzIGZyYWdtZW50YXRpb24uIEhhbmRpbmcgb3ZlciB0aGlzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWUgdG8g dGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dHJhbnNwb3J0IGxheWVyIG1heSBsZWFkIHRvIGludGVyb3BlcmFiaWxpdHk8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMuICogdGhlPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2hhaW5p bmcgbWF5IG5vdCBiZSBlZmZpY2llbnQgaWY8YnI+DQrCoCDCoCDCoCDCoCBmcmFnbWVudHMgYXJl PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5h cHByb3ByaWF0ZWx5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgaGFuZGxlZC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBJbnRyb2R1Y2luZyBOU0ggc2hvdWxkIG5vdCBkZWdyYWRlIHRo ZTxicj4NCsKgIMKgIMKgIMKgIG92ZXJhbGw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzZXJ2aWNlIGNvbXBhcmVkIHRvPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGVnYWN5IHNlcnZpY2UgZGVw bG95bWVudCBzY2hlbWVzLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFlvdXJzLCBKb2VsPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gNC8y NS8xNiAzOjAwIEFNLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+ DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUmUtLDxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIEkgaGVhciB5b3UsIGJ1dCBteSBjb21tZW50IGlzPGJyPg0KwqAgwqAgwqAgwqAgdGhhdCB3 ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIG5lZWQsIGFzIGEgV0csIHRvIGRlY2lkZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdoYXQgdG88YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBwdXQgaW4gdGhlIGRyYWZ0LiBGV0lXLCBJJiMzOTttPGJyPg0KwqAgwqAgwqAgwqAgZGlzY3Vz c2luZyB0d288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBmcmFnbWVudGF0aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVzOjxicj4NCjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICgx KSBGcmFnbWVudGF0aW9uIHRoYXQgaXMgY2F1c2VkIGJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJlcGVuZGluZyBhbiBT RkMgaGVhZGVyLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICgyKSBIYW5kbGluZyBmcmFnbWVudHMgYXQgdGhlPGJyPg0KwqAg wqAgwqAgwqAgaW5ncmVzcyBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuIFNGQy1lbmFibGVkIGRvbWFpbi48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBJbmNyZWFzaW5nIHRoZSBNVFUgaXMgZm9yIHN1cmUgYTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlY29tbWVu ZGF0aW9uIGlzIHRvIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXhwbGljaXRseTxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNhbGxlZCBvdXQgaW4g dGhlIHRleHQgKHNlZSBteSBmaXJzdDxicj4NCsKgIMKgIMKgIMKgIG1lc3NhZ2UpLjxicj4NCjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFRoZXJlIGFyZSBvdGhlciBpc3N1ZXMgdGhhdCBuZWVkPGJyPg0KwqAgwqAg wqAgwqAgdG8gYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBkaXNjdXNzZWQsIGUuZy4sIGhvdyB0bzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRlYWwg d2l0aDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGZyYWdtZW50cyBpbiBTRkZzL0NsYXNzaWZpZXJzPzxicj4NCjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIEl0IGlzIGFsc28gJnF1b3Q7cHJ1ZGVudCZxdW90OyB0byBjaGVjazxicj4NCsKgIMKg IMKgIMKgIHRoYXQgbm88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMgd2lsbCBiZSBleHBlcmllbmNlZDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGluIFNGRjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHRvIGhhbmRsZSBmcmFnbWVudHMuIElmIGFuIFNGQyBoZWFkZXIgaXM8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBwcmVwZW5kZWQgZm9yIGFsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50cywgSSYjMzk7bSBub3Qgc3VyZSB0aGVyZTxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGlzIGFueSBwYXJ0aWN1bGFyIGlzc3VlIGF0IHRoZSBTRkY8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBs ZXZlbCwgZXhjZXB0IGlmPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3RyaXBwaW5nL2FkZGluZzxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnRleHQg VExWcyBkZXBlbmRzIG9uIHRoZSBmdWxsPGJyPg0KwqAgwqAgwqAgwqAgcGFja2V0IChub3Q8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBq dXN0IGZyYWdtZW50KS4gSXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBpcyB3YXJyYW50ZWQgdG8gY29uc2lkZXIgYSBsaXR0bGU8YnI+ DQrCoCDCoCDCoCDCoCBiaXQgdGhpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBvaW50IGJlZm9yZSBkZWNsYXJpbmc8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGVyZSBp cyBubyBpc3N1ZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBGb3IgcG9pbnQgKDEpLCBkZWNsYXJpbmc8 YnI+DQrCoCDCoCDCoCDCoCBmcmFnbWVudGF0aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3V0IG9mIHNjb3BlIHdvdWxk IGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgbWVhbnQgdGhhdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuIGltcGxlbWVudGF0aW9uIG11c3QgYmUg cHJlcGFyZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCByZWNlaXZlIGZyYWdtZW50cyB3aXRoIG9yPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2l0aG91dCBOU0ggaGVh ZGVyIGFzIHRoaXMgaXMgYSBkZWNpc2lvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaXMgbGVmdCB0byB0aGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0cmFuc3Bv cnQgZW5jYXBzdWxhdGlvbi4gVGhpcyBpcyBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVxdWlyZW1lbnQgcGVyIHNlITxicj4NCjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEkgd29uJiMzOTt0IHJlaXRlcmF0ZSBhbGwgdGhlIGNvbW1lbnRzIEk8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBoYXZlIGFib3V0IHRoZSBjdXJyZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd29yZGluZyBvZjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRo aXMgc2VjdGlvbi48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS0gRGUgOjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IEVsenVyLCBVcmk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6 dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT48YnI+ DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT4mZ3Q7PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+Jmd0OyZndDtdIEVudm95w6k8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCA6IGx1bmRpIDI1IGF2cmlsIDIwMTY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAwODozMCDDgCA6IEJPVUNBREFJ UiBNb2hhbWVkPGJyPg0KwqAgwqAgwqAgwqAgSU1UL09MTjs8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaG9tYXMg TmFydGVuOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3Jn PC9hPiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBPYmpldCA6IFJFOiBbc2ZjXSBXRyBsYXN0PGJyPg0KwqAgwqAgwqAgwqAgY2FsbCBm b3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgSGkgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTXkgcG9pbnQgaXMgdGhhdDxicj4NCsKg IMKgIMKgIMKgIEZyYWdtZW50YXRpb24gaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB5ZXQgYW5vdGhlciB0cmFu c3BvcnQgcmVsYXRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzc3VlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdDxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgTlNIIGFuZDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJl eW9uZCB0aGUgY2hhcnRlciBvZiB0aGUgV0csIHNvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQ8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBk b2VzbiYjMzk7dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlYWxseSBiZWxvbmcgaW4gdGhlIGRyYWZ0 Ljxicj4NCsKgIMKgIMKgIMKgIFdlIGFyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb3ZpZGluZyBhbiBhZHZp Y2UgYXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBleHRlbmRpbmcgdGhlIHNpemUgb2YgdGhlPGJyPg0KwqAgwqAg wqAgwqAgcGFja2V0IG1heTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxlYWQgdG8gZnJhZ21lbnRhdGlvbiwgYnV0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYXMgeW91IGNoZWNrIFJGQyA3MzQ4IFZ4TEFOLDxicj4NCsKgIMKgIMKg IMKgIHdoaWNoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbXkgY3JlYXRlIHRoZSBzYW1lIGlzc3VlLDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHlvdSYjMzk7bGwgZmluZCBpdCBkb2VzbiYjMzk7dCBldmVuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVsYXRl PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gaXQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGh4PGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgVXJpICgmcXVvdDtPby1SZWUmcXVvdDspIEM6PGJyPg0KwqAgwqAgwqAg wqAgPGEgaHJlZj0idGVsOjk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0 PSJfYmxhbmsiPjk0OS0zNzgtNzU2ODwvYT4gJmx0O3RlbDo8YSBocmVmPSJ0ZWw6OTQ5LTM3OC03 NTY4IiB2YWx1ZT0iKzE5NDkzNzg3NTY4IiB0YXJnZXQ9Il9ibGFuayI+OTQ5LTM3OC03NTY4PC9h PiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7dGVsOjxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZh bHVlPSIrMTk0OTM3ODc1NjgiIHRhcmdldD0iX2JsYW5rIj45NDktMzc4LTc1Njg8L2E+PGJyPg0K wqAgwqAgwqAgwqAgJmx0O3RlbDo8YSBocmVmPSJ0ZWw6OTQ5LTM3OC03NTY4IiB2YWx1ZT0iKzE5 NDkzNzg3NTY4IiB0YXJnZXQ9Il9ibGFuayI+OTQ5LTM3OC03NTY4PC9hPiZndDsmZ3Q7PGJyPg0K PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQrCoCDC oCDCoCDCoCBGcm9tOiBzZmM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3Jn PC9hPjxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0O10gT248YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBCZWhhbGYgT2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsm Z3Q7IFNlbnQ6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3VuZGF5LCBBcHJpbCAyNCwgMjAxNjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIDEwOjMyIFBNIFRvOiBFbHp1ciwgVXJpPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0OzxhIGhyZWY9Im1h aWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVs LmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmku ZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT4m Z3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGlu dGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+PGJyPg0KwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+Jmd0OyZndDsmZ3Q7Ozxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFRob21hcyBOYXJ0ZW48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hcnRl bkB1cy5pYm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+bmFydGVuQHVzLmlibS5jb208L2E+PGJyPg0K wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5jb20i IHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT4mZ3Q7ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm5hcnRlbkB1cy5pYm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+bmFydGVuQHVz LmlibS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bmFydGVuQHVzLmlibS5jb20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT4m Z3Q7Jmd0OyZndDs7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5z ZmNAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFN1YmplY3Q6IFJlOiBbc2ZjXSBXRyBsYXN0PGJyPg0KwqAgwqAg wqAgwqAgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSGkgVXJpLDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoYXQmIzM5O3Mg YW5vdGhlciBvcHRpb24gdGhhdDxicj4NCsKgIMKgIMKgIMKgIG5lZWRzIHRvPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYmUgZGlzY3Vzc2VkL2ludmVzdGlnYXRlZC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJJiMzOTttPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYWZyYWlkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhpcyBpcyBub3QgdGhlIHJhdGlvbmFsZTxi cj4NCsKgIMKgIMKgIMKgIGFkb3B0ZWQgaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtMDQgc2luY2UgaXQgaW5j bHVkZXMgc29tZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRleHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaXMgZmFyIHRvIGJlIHN1ZmZpY2llbnQgdG88YnI+DQrCoCDCoCDCoCDCoCBlbnN1cmU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBpbnRlcm9wZXJhYmxlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50YXRpb25z Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJUVywgc2F5aW5nIHRoYXQgbnNoIGRvZXM8YnI+DQrCoCDC oCDCoCDCoCBub3QgbmVlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRvIGRlYWwgd2l0aCBmcmFnbWVudGF0aW9u PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYmVjYXVzZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGl0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXMg dHJhbnNwb3J0LWluZGVwZW5kZW50IGlzPGJyPg0KwqAgwqAgwqAgwqAgbm90IElNSE88YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBhIGdvb2Qgc3RyYXRlZ3kgdG8gYWRvcHQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoZXJlPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYmVjYXVzZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGl0IG9wZW5zIHRoZSBkb29yIGZvcjxicj4N CsKgIMKgIMKgIMKgIGludGVyb3BlcmFibGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMsIGl0IG1heSBs ZWFkIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgc3ViLW9wdGltYWwgaW1wbGVtZW50YXRpb25zPGJyPg0KwqAg wqAgwqAgwqAgaWYgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2ZjIGluZm9ybWF0aW9uIGlzIHByZXNlbnQ8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBvbmx5IGluIG9uZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50cyw8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBldGMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTXkgY29tbWVudHMgYXJlIHJlbGF0ZWQg dG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgY3VycmVudCB0ZXh0IGluIHRoZSAtMDQuPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgVGhpcyB0ZXh0IG5lZWRzPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZSBmaXhl ZCBzb21laG93Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENoZWVycywgTWVkPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgLS0tLS1NZXNzYWdlPGJyPg0KwqAgwqAgwqAgwqAgZCYjMzk7b3JpZ2luZS0t LS0tIERlIDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFbHp1ciwgVXJpPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnVyaS5lbHp1ckBpbnRlbC5jb20iIHRhcmdldD0iX2JsYW5rIj51cmkuZWx6dXJAaW50ZWwu Y29tPC9hPiZndDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVs LmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+Jmd0OyZndDtdPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgRW52b3nDqSA6IGRpbWFuY2hlIDI0IGF2cmlsPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgMjAxNiAxNzozNiDDgCA6IEJPVUNBREFJUjxicj4NCsKgIMKgIMKgIMKgIE1vaGFtZWQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBJTVQvT0xOOyBUaG9tYXMgTmFydGVuOzxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0 Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3Jn PC9hPiZndDsmZ3Q7IE9iamV0IDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSRTogW3NmY10gV0cgbGFz dCBjYWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBNZWQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBJIHNlZSBubyBuZWVkIHRvIHNwZWNpZnkgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXhhY3Qg YmVoYXZpb3IgYXMgTlNIIGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJhbnNwb3J0IGluZGVwZW5k ZW50PGJyPg0KwqAgwqAgwqAgwqAgaS5lLiBsaWtlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTlNIIGlu dGVyYWN0aW9uIHdpdGggYW55PGJyPg0KwqAgwqAgwqAgwqAgb3RoZXI8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBUcmFuc3BvcnQgZWggaXNzdWUgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBGcmFnbWVudGF0 aW9uIGlzIHRvIGJlPGJyPg0KwqAgwqAgwqAgwqAgZGVhbHQgaW48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBhIHdheTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgbWF0Y2hlcyB0aGUgbWVjaGFuaXNtczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHN1cHBvcnRlZCBieSB0aGU8YnI+DQrCoCDCoCDCoCDCoCBUcmFu c3BvcnQgdXNlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuZCBkbyBub3QgYmVsb25nIGluIHRoZTxi cj4NCsKgIMKgIMKgIMKgIE5TSCBkcmFmdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoeDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFVyaSAoJnF1b3Q7T28tUmVlJnF1b3Q7KSBDOjxicj4N CsKgIMKgIMKgIMKgIDxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0OTM3ODc1 NjgiIHRhcmdldD0iX2JsYW5rIj45NDktMzc4LTc1Njg8L2E+ICZsdDt0ZWw6PGEgaHJlZj0idGVs Ojk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPjk0OS0z NzgtNzU2ODwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O3RlbDo8YSBocmVmPSJ0ZWw6 OTQ5LTM3OC03NTY4IiB2YWx1ZT0iKzE5NDkzNzg3NTY4IiB0YXJnZXQ9Il9ibGFuayI+OTQ5LTM3 OC03NTY4PC9hPjxicj4NCsKgIMKgIMKgIMKgICZsdDt0ZWw6PGEgaHJlZj0idGVsOjk0OS0zNzgt NzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPjk0OS0zNzgtNzU2ODwv YT4mZ3Q7Jmd0Ozxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2luYWw8 YnI+DQrCoCDCoCDCoCDCoCBNZXNzYWdlLS0tLS0gRnJvbTogc2ZjPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNl c0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0O108 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBPbiBCZWhhbGYgT2Y8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCA8 YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDC oCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4m Z3Q7Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCw8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAyMDE2IDEyOjQzIEFNIFRvOiBUaG9tYXM8YnI+DQrCoCDCoCDCoCDC oCBOYXJ0ZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hcnRlbkB1 cy5pYm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+bmFydGVuQHVzLmlibS5jb208L2E+PGJyPg0KwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5jb20iIHRh cmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5jb20iIHRhcmdl dD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86bmFydGVuQHVzLmlibS5jb20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwv YT4mZ3Q7Jmd0OyZndDs7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDC oCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwv YT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgU3ViamVjdDo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBSLSw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJbiBhZGRpdGlvbiB0byBvdGhlciBwZW5k aW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVzIHJhaXNlZCBmb3IgdGhpczxicj4NCsKgIMKg IMKgIMKgIGRyYWZ0LCBJPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd291bGQgbGlrZSB0byByYWlzZSB0 aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWRkaXRpb25hbCBvbmUgYWJvdXQ8YnI+DQrCoCDCoCDC oCDCoCBTZWN0aW9uIDYuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPT0gNi7CoCBGcmFnbWVu dGF0aW9uPGJyPg0KwqAgwqAgwqAgwqAgQ29uc2lkZXJhdGlvbnM8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBOU0ggYW5kIHRoZSBhc3NvY2lhdGVkPGJyPg0KwqAgwqAgwqAgwqAgdHJhbnNwb3J0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgaGVhZGVyIGFyZSAmcXVvdDthZGRlZCZxdW90OyB0byB0aGU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBlbmNhcHN1bGF0ZWQ8YnI+DQrCoCDCoCDCoCDCoCBwYWNrZXQv ZnJhbWUuwqAgVGhpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb248 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBpbmNyZWFzZXM8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGU8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBzaXplIG9mIHRoZSBwYWNrZXQuwqAgSW48YnI+DQrCoCDCoCDCoCDCoCBvcmRl cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBlbnN1cmUgcHJvcGVyPGJyPg0KwqAgwqAgwqAgwqAg Zm9yd2FyZGluZyBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5TSCBkYXRhLCBzZXZlcmFsPGJyPg0K wqAgwqAgwqAgwqAgb3B0aW9ucyBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYW5kbGluZyBmcmFn bWVudGF0aW9uIGFuZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlLWFzc2VtYmx5IGV4aXN0Ojxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDEuwqAgSnVtYm8gRnJhbWVzLCB3aGVuPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgc3VwcG9ydGVkLCBlbmFibGUgdGhlPGJyPg0KwqAgwqAgwqAgwqAgdHJhbnNwb3J0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgTlNIPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIGFzc29j aWF0ZWQgdHJhbnNwb3J0PGJyPg0KwqAgwqAgwqAgwqAgcGFja2V0czxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHdpdGhvdXQgcmVxdWlyaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbi48 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyLsKgIFBhdGggTVRVIERpc2NvdmVyeTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIFtSRkMxMTkxXSZxdW90O2Rlc2NyaWJlcyBhPGJyPg0KwqAgwqAgwqAgwqAg dGVjaG5pcXVlIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGR5bmFtaWNhbGx5IGRpc2NvdmVyaW5n IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1heGltdW0gdHJhbnNtaXNzaW9uPGJyPg0KwqAgwqAg wqAgwqAgdW5pdCAoTVRVKSBvZjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg YXJiaXRyYXJ5IGludGVybmV0IHBhdGgmcXVvdDs8YnI+DQrCoCDCoCDCoCDCoCBhbmQgY2FuPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgYmUgdXRpbGl6ZWQgdG8gZW5zdXJlIHRoZTxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZTxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHJlcXVpcmVkIHBhY2tldCBzaXplIGlzPGJyPg0KwqAgwqAgwqAg wqAgdXNlZC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAzLsKgIFtSRkM2ODMwXSBkZXNjcmli ZXMgdHdvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2NoZW1lcyBmb3I8YnI+DQrCoCDCoCDCoCDCoCBm cmFnbWVudGF0aW9uIGFuZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlLTxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzc2VtYmx5 PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW4gc2VjdGlvbiA1LjQuID09PGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgKiBUaGUgdGV4dCBpcyB3ZWFrIGZvciBhPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgU3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQ8YnI+DQrCoCDCoCDCoCDCoCB0aGF0IGlzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgaW50ZW5kZWQgdG8gc29sdmUgdGhlPGJyPg0KwqAgwqAgwqAgwqAgcHJv YmxlbSBpbjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3NDk4I3NlY3Rpb24tIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ5OCNzZWN0aW9uLTwvYT48YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAy LjEyLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZXJlIHNob3VsZCBiZSBhIGNsZWFyPGJy Pg0KwqAgwqAgwqAgwqAgYmVoYXZpb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBiZSBmb2xsb3dl ZCBieSBhbjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGltcGxlbWVudGF0aW9uLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZ1cnRo ZXIsIEkgd291bGQgYXZvaWQ8YnI+DQrCoCDCoCDCoCDCoCB0aGUgdXNlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgb2Ygd29yZHMgc3VjaCBhcyAmcXVvdDtjYW4mcXVvdDsuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgKiBUaGUgdGV4dCBjb3ZlcnMgb25seTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdt ZW50YXRpb24gd2hlbiBpdCBpczxicj4NCsKgIMKgIMKgIMKgIGluZHVjZWQ8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBieSBTRkM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvcGVyYXRpb25zLCBpdCBkb2VzIG5v dDxicj4NCsKgIMKgIMKgIMKgIGRpc2N1c3M8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgdHJlYXRt ZW50IG9mIGEgZnJhZ21lbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aGVuIHJlY2VpdmVkIGluIGFu IFNGQzxicj4NCsKgIMKgIMKgIMKgIGRvbWFpbi48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJTUhPLCB0 aGUgZHJhZnQgc2hvdWxkIGFsc288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzcGVjaWZ5IHRoZSBiZWhh dmlvciBvZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDbGFzc2lmaWVyIHdpdGggcmVnYXJkcyB0 bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50cyBmb3IgdGhlIHNha2U8YnI+DQrCoCDCoCDC oCDCoCBvZiBwcm9wZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTRkMgb3BlcmF0aW9uLiBBcHBseWlu Zzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsYXNzaWZpY2F0aW9uIHBvbGljaWVzIG1heTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHJlcXVpcmUgdGhlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnVsbCBwYWNrZXQs IG5vdCBvbmx5IGE8YnI+DQrCoCDCoCDCoCDCoCBmcmFnbWVudC48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBJbiBwYXJ0aWN1bGFyLCBkZWRpY2F0ZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXNv dXJjZXMgc2hvdWxkPGJyPg0KwqAgwqAgwqAgwqAgZGVkaWNhdGVkIGZvcjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGhhbmRsaW5nIG91dCBvZiBvcmRlcjxicj4NCsKgIMKgIMKgIMKgIGZyYWdtZW50cy48 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBPZiBjb3Vyc2UsIGl0IGlzIG91dCBvZjxicj4NCsKgIMKgIMKg IMKgIHNjb3BlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgdGhpcyBkb2N1bWVudCB0bzxicj4NCsKg IMKgIMKgIMKgIGRlc2NyaWJlIGhvdzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNGcyBoYW5kbGUgZnJh Z21lbnRzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogSWYgYW4gU0ZDIGhlYWRlciBpczxi cj4NCsKgIMKgIMKgIMKgIHByZXBlbmRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZvciBhbGwgZnJh Z21lbnRzLCBJJiMzOTttIG5vdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1cmUgdGhlcmUgaXMgYW55 IHBhcnRpY3VsYXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZSBhdCB0aGUgU0ZGPGJyPg0KwqAg wqAgwqAgwqAgbGV2ZWwuLi5leGNlcHQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZiBzdHJpcHBpbmcv YWRkaW5nPGJyPg0KwqAgwqAgwqAgwqAgY29udGV4dCBUTFZzPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg ZGVwZW5kcyBvbiB0aGUgZnVsbCBwYWNrZXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAobm90IGp1c3Qg ZnJhZ21lbnQpLiBJdCBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdhcnJhbnRlZCB0byBjb25zaWRl ciBhPGJyPg0KwqAgwqAgwqAgwqAgbGl0dGxlIGJpdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoaXMg cG9pbnQgYmVmb3JlPGJyPg0KwqAgwqAgwqAgwqAgZGVjbGFyaW5nIHRoZXJlPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXM8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBubyBpc3N1ZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAqIFRoZSB0ZXh0IHN0YXRlcyAmcXVvdDtzZXZlcmFsPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg b3B0aW9ucyZxdW90Oy4gVGhpcyBtYXkgYmU8YnI+DQrCoCDCoCDCoCDCoCBpbnRlcnByZXRlZDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGFzIGlmIGltcGxlbWVudGluZyBvbmU8YnI+DQrCoCDCoCDCoCDC oCBvZiB0aGVtPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXMgc3VmZmljaWVudC4uLndoaWNoIGlzIG5v dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRydWUuIFRoZSBmaXJzdCB0d28gcG9pbnRzPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgY29udHJpYnV0ZSB0byBtaW5pbWl6ZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBmcmFnbWVudGF0aW9uIHJpc2ssIGJ1dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50YXRp b24gbWF5IHN0aWxsIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXhwZXJpZW5jZWQ8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAoZS5nLiwgb3RoZXIgc2hpbXMgYXJlPGJyPg0KwqAgwqAgwqAgwqAgcHJlcGVu ZGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkgb3RoZXIgbm9kZXMgZm9yIHNvbWU8YnI+DQrCoCDC oCDCoCDCoCBvdGhlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHB1cnBvc2VzLCBuZXN0ZWQgbnNoLCBl dGMuKTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIGZpcnN0IHR3byBwb2ludHMgaGF2 ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIG5vdGhpbmcgdG8gZG8gd2l0aDxicj4NCsKgIMKgIMKgIMKg IHJlYXNzZW1ibHkuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBUaGUgc3VwcG9ydCBvZiBq dW1ibzwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo= --001a11408aa42978c305318b6b4c-- From nobody Thu Apr 28 06:24: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 3FEF812D6F8 for ; Thu, 28 Apr 2016 06:24:42 -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 1aRvlB2C1OjY for ; Thu, 28 Apr 2016 06:24:37 -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 A87BC12D6FF for ; Thu, 28 Apr 2016 06:24:16 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id k142so83144823oib.1 for ; Thu, 28 Apr 2016 06:24:16 -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=mjodXZ3F37tv2SoXjm8HFNfcO+VOaSzetyOduuzsXF0=; b=jVhMuE1pprkJZXBPw1zX/gXhXUn8DLCfX+Nx9F56z0Rfy8P3/hJQdn/BP2u6LHMUao RuI+fNDkeNFRAdOPfP8OYDCspUqNO3j8iV/TcwsUg4dL23EMG1o8NGXH1YvUKkiPUtLb vnk4nj0Oygx8An62HeesI8mwSSgv8oj2K5TATwx0dLIKjZck99uBpfvZpulbgroVBB2J eVQGm8jivxM4FHbsbrdygcI/OTVUH98g+XaroXHajz/PIWm5JlECSM7EnRdBxJaHiq7Y wLwA79EMj0s+gtJXjfxkqgyBmmg6QD1v2aIZ8nWqp0VIVhH16x9H6b37I3uFI0ZxI95Z cFyA== 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=mjodXZ3F37tv2SoXjm8HFNfcO+VOaSzetyOduuzsXF0=; b=W4wAwcXGPcc9PDS34wdWSTP6ytpTxoTRE5cBf5x/MEm6COJEA0aFZldKwVH6jt/dMo zWvErbKCCQQMbfFoj3neWzgZUrpxGR5g4jOV9808btTyHGkqDymGvLfenQA+LffdMZmk TUTnng8KWGddM/RdiXxspFdRCj7vz9c5vSauFclE+gIfF6nhBPHVeEt/B867nT8Uip5I EeqFuw0COz7Itfu8o5/SsW9jKrYqXOnlpfcg7gO7KshojoB7nUuJszNOn0FW1e5J8tHm 5AeIb490OlgrfpN0UTOi9mcroMeGi8awqrRl31wxfd64FaYLxE/7yjj+HNf9sUCci0fu z1eQ== X-Gm-Message-State: AOPr4FVQie4tZqFKLSJFxVP5VhwHbZtdyE5uJhv+ytP/qrk8RLnwcL8xkc1kDZCS0KlPc2sN2EcOy+0yj7Or+A== X-Received: by 10.157.48.98 with SMTP id w31mr6114139otd.61.1461849855950; Thu, 28 Apr 2016 06:24:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Thu, 28 Apr 2016 06:23:56 -0700 (PDT) In-Reply-To: References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 28 Apr 2016 09:23:56 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a114187be61056505318b71f9 Archived-At: Cc: "Elzur, Uri" , Joel Halpern Direct , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 13:24:42 -0000 --001a114187be61056505318b71f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, Thanks. To paraphrase what I just said to Joel, if that=E2=80=99s the inten= t, then the text should make it clear. Thanks, Andy On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar) wrote: > Hi Andy, > > I think the key point is that NSH !=3D network overlay but rather utilize= s a > network overlay for packet transport between SFC network elements. The > reference is just an example of how a network overlay might deal with > fragmentation and is not a suggestion that NSH adopt that mechanism but > rather makes the point that it can utilize the existing network overlay > mechanics. > > Jim > > From: sfc on behalf of "Andrew G. Malis" < > agmalis@gmail.com> > Date: Thursday, April 28, 2016 at 8:17 AM > To: Joel Halpern Direct > Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" < > mohamed.boucadair@orange.com>, "sfc@ietf.org" , Linda > Dunbar > Subject: Re: [sfc] Suggested wording addtion to the Section 6 > (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt > > Joel, > > The diagrams in section 6 of RFC 6830 are control plane, not data plane. > The data plane diagrams are in section 5. > > But the overriding question is - without any fields in the NSH header to > sequence fragments, how can the fragments be correctly reassembled? > > Cheers, > Andy > > On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct < > jmh.direct@joelhalpern.com> wrote: > >> The LISP header does not have a fragment flag or fragment offset. The >> diagrams in section 6 include the outer encapsulating header (the >> equivalent of the transport header in SFC.) Yes, the text is a little h= ard >> to follow in this regard. The LISP working group is going to be rewriti= ng >> RFC 6830 as part of moving to standards track. >> >> So there is no difference in this regard between NSH and LISP. >> >> Yours, >> Joel >> >> On 4/27/16 7:02 PM, Andrew G. Malis wrote: >> >>> Joel et al, >>> >>> All this talk about fragmentation prompted me to re-read section 6 of >>> the draft, which recommends (as option 3) using the procedures in >>> section 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80= =9D replacing the >>> =E2=80=9CLISP header=E2=80=9D in the description of the procedures in t= hat section). >>> >>> So that led me to read that section (and the LISP header definition in >>> section 5.1), and I see that LISP does fragmentation and reassembly >>> identically to IPv4, using the Fragment Offset field so that fragments >>> can be correctly reassembled in the proper order. >>> >>> However, the NSH Header doesn=E2=80=99t have a Fragment Offset field or= any >>> other way to order the fragments. >>> >>> So how can the procedures in Section 5.4 of 6830 be used? >>> >>> Thanks, >>> Andy >>> >>> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> > wrote: >>> >>> Both methods are valid, and both depend upon details of the >>> underlying packet and the transport. As such, I don't see why this >>> document benefits from describing them, much less why it should mar= k >>> one method as a "should". Implementation details are likely to be >>> more significant than any bit consumption difference between the tw= o >>> alternatives. >>> >>> Yours, >>> Joel >>> >>> >>> On 4/27/16 3:40 PM, Linda Dunbar wrote: >>> >>> I suggest adding the following paragraphs after the Bullet 3 of >>> the Section 6 Fragmentation Consideration to make the process >>> more clear and less controversial: >>> >>> >>> -------------------------------- >>> >>> RFC6830 describes the fragmentation method of breaking the >>> original packet into two equal sub-frames and encapsulating >>> [LISP Header + Transport header] to each sub-frame. >>> >>> If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC >>> Header + Transport Header] will be added to each half frame (or >>> the original data frame). As the Transport Header is terminated >>> by the next SFF node's tunnel transport layer, the combined two >>> sub-frames will have two SFC Headers. >>> >>> Therefore, the fragmentation for NSH encapsulated data frame >>> should be done completely by the node tunnel transport layer, >>> which should break the [SFC + original packet] into two equal >>> sub-frames and each sub-frame being encapsulated with its >>> respective tunnel header. The next SFF node's tunnel transport >>> layer should combine the two sub-frames before sending to the >>> next node. >>> >>> ------------------------------------------------------ >>> >>> >>> By the way, there are to typo in the Section 6: >>> 3rd line: "In order the" =3D=3D> "In order to" >>> Last line of Bullet 2: extra "the" in the "utilized to ensure >>> the the required packet". >>> >>> >>> Hope it helps. >>> >>> Linda >>> >>> >>> >>> -----Original Message----- >>> From: mohamed.boucadair@orange.com >>> >>> [mailto:mohamed.boucadair@orange.com >>> ] >>> Sent: Wednesday, April 27, 2016 12:40 AM >>> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org >>> >>> Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, all, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] Envoy=C3=A9 : mardi 26 >>> avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed >>> IMT/OLN; Elzur, >>> Uri; sfc@ietf.org Objet : Re: [sfc] W= G >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> With regard to Transport tunnel fragementation, that seems >>> an issue >>> for the transport protocol. I don't actually object to a >>> sentence, >>> but it does not seem that it will accomplish anything. >>> >>> >>> [Med] I would like to see some text added to the draft. >>> >>> >>> With regard to packets fragmented by the source, I >>> completely disagree >>> with your assertion. If an SFF were to reassemble the >>> packets, that >>> would be a violation of its job. >>> >>> >>> [Med] I agree with you. >>> >>> There is no reason for an SFF to >>> >>> reassemble a packet fragmented by the source. The >>> classifier may have >>> to do some interesting things in order to properly classify >>> succeeding >>> fragments, but that is an implementation issue (most common= ly >>> addressed with virtual reassembly, which doe snot delay the >>> fragments.) We don't specity that. >>> >>> >>> [Med] Still, the external behavior of the classifier needs to b= e >>> clear in the document. I don't find any text in the draft sayin= g >>> for instance that an NSH header must be present in all >>> fragments. (There some processing that might be needed at the >>> SFF to "do its job" with regards to fragments (receive out of >>> order fragments + forwarding policy on the full packet).) >>> >>> >>> If an SF needs to reassemble fragments to do its job, that >>> is up to >>> the SF. Some will need to actually reassemble. Some will >>> need to >>> perform virtual reassembly, and some will happily process t= he >>> fragments. I can not see what the NSH document could >>> possibly mandate. >>> >>> >>> [Med] Fully agree. >>> >>> >>> Yours, >>> Joel >>> >>> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> >>> Joel, >>> >>> I think the document should add the description on the >>> following two >>> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a pack= et >>> fragmentation is caused by transport tunnel (i.e. vario= us >>> encapsulations), the termination point of the transport >>> tunnel is >>> responsible for re-assembling the fragmented pieces of >>> the packet. >>> Since there won't be any SFF nodes in between the >>> Transport Tunnel, >>> the tunnel generated fragmentation does not require any >>> actions by >>> SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on >>> the NSH >>> header): When fragmentation has to be performed for a >>> packet being >>> encapsulated with the NSH header, either the >>> intermediate SFF nodes >>> or the SF nodes have to be able to reassemble the >>> fragmented pieces. >>> >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Sent: Tuesday, April 26, >>> 2016 10:33 AM >>> To: Linda Dunbar; mohamed.boucadair@orange.com >>> ; Elzur, Uri; >>> sfc@ietf.org Subject: Re: [sfc] W= G >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are >>> referring only to >>> the case of transport generated fragmentation of the >>> outer packet. >>> I had assumed you were not talking about that, since th= e >>> resulting >>> fragments will not all have NSH headers. As with any >>> tunnel >>> technology, if the tunnel chooses to fragment at its >>> layer, then the >>> tunnel is responsible for reassembly. That would be >>> invisible to >>> the SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>> >>> Agree with Med. >>> >>> Even if each fragment piece of a packet with NSH >>> header carries the >>> NSH header, the intermediate SFF nodes still need t= o >>> put together >>> all the fragments together before passing the whole >>> data frame to >>> the SF. >>> >>> Linda >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of mohamed.boucadair@orange.com >>> Sent: Monday, >>> April 25, >>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; >>> sfc@ietf.org Subject: >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.tx= t >>> >>> Re-, >>> >>> How do you instruct the transport layer to ALWAYS >>> prepend an NSH >>> header even for fragments? Or you don't care about >>> that? >>> >>> Thank you. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> ] Envoy=C3=A9 : lun= di 25 >>> avril 2016 16:26 =C3=80 >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >>> sfc@ietf.org Objet >>> : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> Not to repeat my position, but I'll do it anyho= w >>> :-) As NSH is >>> *NOT* a transport, dealing with fragmentation i= s >>> left to the >>> Transport used. >>> >>> The model I use for NSH, is basically similar t= o >>> VXLAN . It is an >>> overly. >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >> > >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of mohamed.boucadair@orange.com >>> Sent: >>> Monday, April 25, >>> 2016 7:18 AM To: Joel M. Halpern >>> >> >>; >>> sfc@ietf.org >>> Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, >>> >>> Please see inline. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : Joel M. >>> Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Envoy=C3=A9 := lundi >>> 25 avril 2016 15:48 =C3=80 >>> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>> Objet : Re: [sfc] WG >>> last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, yo= u >>> are asking that the >>> NSH draft specify how service chaining >>> should cope with packets >>> that have been fragmented? >>> >>> >>> [Med] To be accurate, I'm asking to assess >>> whether there are >>> implications. If there are, then the draft >>> should be updated >>> accordingly. >>> >>> NSH, and the SFF functionality, does not >>> care. >>> >>> >>> [Med] I'm not that sure. Some typical >>> implications are listed >>> below: >>> >>> * SFF: If the NSH header is present only in the >>> a fragment but SFF >>> didn't maintained a state, subsequent fragments >>> won't be >>> appropriately processed. * SFC-aware function: >>> if prepending a >>> context information depends on the full packet, >>> not only a >>> fragment. >>> >>> It just does its job. >>> >>> [Med] which may be disturbed in some situations >>> as listed in the >>> examples above. >>> >>> Ingress and intermediate classifiers may >>> cope with fragments in >>> any number of ways. >>> >>> Specifying such is clearly out of scope for thi= s >>> draft. >>> >>> [Med] The purpose is not to specify the interna= l >>> implementation >>> details but the external behavior of the >>> classifier function when >>> it comes to handle fragments. That behavior may >>> have an incidence >>> on SFF, in particular. The purpose is not to >>> recommend the maximum >>> resources to be dedicated to out of order >>> fragments nor the >>> timeout to cache those; these considerations ar= e >>> of course out of >>> scope. Nevertheless, an implementation should >>> offer a configurable >>> parameter so that an operator tweak those >>> according to its >>> context. >>> >>> I suppose one could write an informational >>> draft on possible ways >>> of coping. The IETF has not usually >>> published such. >>> Service functions have to cope with >>> fragmented packets just as >>> they had to before the advent of NSH, so >>> describing that is >>> clearly not needed here. >>> >>> >>> [Med] The advent of NSH has the following >>> implications: * it >>> exacerbates fragmentation. Handing over this >>> issue to the >>> transport layer may lead to interoperability >>> issues. * the >>> chaining may not be efficient if fragments are >>> inappropriately >>> handled. >>> >>> Introducing NSH should not degrade the overall >>> service compared to >>> legacy service deployment schemes. >>> >>> >>> Yours, Joel >>> >>> On 4/25/16 3:00 AM, >>> mohamed.boucadair@orange.com >>> wrote= : >>> >>> Re-, >>> >>> I hear you, but my comment is that we >>> need, as a WG, to decide >>> what to >>> >>> put in the draft. FWIW, I'm discussing two >>> fragmentation >>> issues: >>> >>> >>> (1) Fragmentation that is caused by >>> prepending an SFC header. >>> (2) Handling fragments at the ingress o= f >>> an SFC-enabled domain. >>> >>> Increasing the MTU is for sure a >>> recommendation is to be >>> explicitly >>> >>> called out in the text (see my first >>> message). >>> >>> >>> There are other issues that need to be >>> discussed, e.g., how to >>> deal with >>> >>> fragments in SFFs/Classifiers? >>> >>> >>> It is also "prudent" to check that no >>> issues will be experienced >>> in SFF >>> >>> to handle fragments. If an SFC header is >>> prepended for all >>> fragments, I'm not sure there >>> >>> is any particular issue at the SFF >>> level, except if >>> stripping/adding >>> >>> context TLVs depends on the full packet (no= t >>> just fragment). It >>> is warranted to consider a little bit this >>> point before declaring >>> there is no issue. >>> >>> >>> For point (1), declaring fragmentation >>> out of scope would be >>> meant that >>> >>> an implementation must be prepared to >>> receive fragments with or >>> without NSH header as this is a decision >>> that is left to the >>> transport encapsulation. This is a >>> requirement per se! >>> >>> >>> I won't reiterate all the comments I >>> have about the current >>> wording of >>> >>> this section. >>> >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : >>> Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> ] Envoy= =C3=A9 >>> : lundi 25 avril 2016 >>> 08:30 =C3=80 : BOUCADAIR Mohamed IM= T/OLN; >>> Thomas Narten; >>> sfc@ietf.org >>> Objet : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> My point is that Fragmentation is >>> yet another transport related >>> issue >>> >>> that >>> >>> is beyond the scope of NSH and >>> beyond the charter of the WG, so >>> it >>> >>> doesn't >>> >>> really belong in the draft. We are >>> providing an advice as >>> extending the size of the packet ma= y >>> lead to fragmentation, but >>> as you check RFC 7348 VxLAN, which >>> my create the same issue, >>> you'll find it doesn't even >>> >>> relate >>> >>> to it. >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >>> >>> >>> >>> -----Original Message----- From: sf= c >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of >>> mohamed.boucadair@orange.com >>> >>> Sent: >>> Sunday, April 24, 2016 >>> 10:32 PM To: Elzur, Uri >>> >> >; >>> Thomas Narten >>> >>> >> >>; >>> >>> sfc@ietf.org >>> Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Uri, >>> >>> That's another option that needs to >>> be discussed/investigated. >>> I'm >>> >>> afraid >>> >>> this is not the rationale adopted i= n >>> -04 since it includes some >>> text >>> >>> that >>> >>> is far to be sufficient to ensure >>> interoperable >>> implementations. >>> >>> BTW, saying that nsh does not need >>> to deal with fragmentation >>> because >>> >>> it >>> >>> is transport-independent is not IMH= O >>> a good strategy to adopt >>> here >>> >>> because >>> >>> it opens the door for interoperable >>> issues, it may lead to >>> sub-optimal implementations if the >>> sfc information is present >>> only in one >>> >>> fragments, >>> >>> etc. >>> >>> My comments are related to the >>> current text in the -04. >>> This text needs >>> >>> to >>> >>> be fixed somehow. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De = : >>> Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> ] >>> Envoy=C3=A9 : dimanche 24 avril >>> 2016 17:36 =C3=80 : BOUCADAIR M= ohamed >>> IMT/OLN; Thomas Narten; >>> sfc@ietf.org >>> Objet : >>> RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> I see no need to specify the >>> exact behavior as NSH is >>> transport independent i.e. like >>> NSH interaction with any other >>> Transport eh issue of >>> Fragmentation is to be dealt in >>> a way >>> that matches the mechanisms >>> supported by the Transport used >>> and do not belong in the NSH >>> draft >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >>> >>> >>> >>> -----Original Message----- From= : >>> sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of >>> mohamed.boucadair@orange.com >>> >> mohamed.boucadair@orange.com> >>> Sent: Thursday, April 14, >>> 2016 12:43 AM To: Thomas Narten >>> >> >; >>> sfc@ietf.org >>> Subject: >>> Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> R-, >>> >>> In addition to other pending >>> issues raised for this draft, I >>> would like to raise this >>> additional one about Section 6. >>> >>> =3D=3D 6. Fragmentation >>> Considerations >>> >>> NSH and the associated transpor= t >>> header are "added" to the >>> encapsulated packet/frame. Thi= s >>> additional information >>> increases >>> >>> the >>> >>> size of the packet. In order >>> the ensure proper forwarding of >>> NSH data, several options for >>> handling fragmentation and >>> re-assembly exist: >>> >>> 1. Jumbo Frames, when >>> supported, enable the transport >>> of NSH >>> and associated transport packet= s >>> without requiring >>> fragmentation. >>> >>> 2. Path MTU Discovery >>> [RFC1191]"describes a technique >>> for >>> dynamically discovering the >>> maximum transmission unit (MTU) >>> of >>> >>> an >>> >>> arbitrary internet path" and ca= n >>> be utilized to ensure the >>> >>> the >>> >>> required packet size is used. >>> >>> 3. [RFC6830] describes two >>> schemes for fragmentation and >>> re- >>> >>> assembly >>> >>> in section 5.4. =3D=3D >>> >>> * The text is weak for a >>> Standard track document that is >>> intended to solve the problem i= n >>> >>> https://tools.ietf.org/html/rfc7498#section- >>> >>> 2.12. >>> >>> There should be a clear behavio= r >>> to be followed by an >>> >>> implementation. >>> >>> Further, I would avoid the use >>> of words such as "can". >>> >>> * The text covers only >>> fragmentation when it is induce= d >>> by SFC >>> operations, it does not discuss >>> the treatment of a fragment >>> when received in an SFC domain. >>> IMHO, the draft should also >>> specify the behavior of the >>> Classifier with regards to >>> fragments for the sake of prope= r >>> SFC operation. Applying >>> classification policies may >>> require the >>> >>> full packet, not only a fragment. >>> >>> In particular, dedicated >>> resources should dedicated for >>> handling out of order fragments= . >>> Of course, it is out of scope >>> of this document to describe ho= w >>> SFs handle fragments. >>> >>> * If an SFC header is prepended >>> for all fragments, I'm not >>> sure there is any particular >>> issue at the SFF level...except >>> if stripping/adding context TLV= s >>> depends on the full packet >>> (not just fragment). It is >>> warranted to consider a little >>> bit >>> this point before declaring the= re >>> >>> is >>> >>> no issue. >>> >>> >>> * The text states "several >>> options". This may be interpret= ed >>> as if implementing one of them >>> is sufficient...which is not >>> true. The first two points >>> contribute to minimize the >>> fragmentation risk, but >>> fragmentation may still be >>> experienced >>> (e.g., other shims are prepende= d >>> by other nodes for some other >>> purposes, nested nsh, etc.) >>> >>> * The first two points have >>> nothing to do with reassembly. >>> >>> * The support of jumbo frames b= y >>> a router/device does not mean >>> that it can make use of it. >>> Appropriate MTU configuration >>> should be undertaken in a >>> consistent manner within an SFC >>> domain. The text should be >>> updated to make it is about >>> (consistent) MTU >>> >>> configuration. >>> >>> >>> * BTW, shouldn't the text be >>> reworded to recommended to >>> increase the MTU of **all >>> nodes** of an SFC-enabled domai= n >>> by >>> at least the length of SFC >>> header + transport header? >>> >>> * Bullet 2, how PMTU discovery >>> is actually used in this >>> context? Do you assume that all >>> SFC-aware nodes will issue >>> such messages towards other >>> SFC-aware node, arbitrary >>> destination, else? >>> >>> * Bullet 2, I would drop >>> "describes a technique for >>> dynamically discovering the >>> maximum transmission unit >>> (MTU) of an arbitrary internet >>> path". >>> >>> * Bullet 2, s/ the the/the. >>> >>> * The reference to the LISP >>> specification raises two concer= ns >>> and one comment: >>> >>> (1) I don't think it is a good >>> approach that fragments induced >>> by the network are passed to >>> their ultimate destinations as >>> such >>> >>> (stateless). >>> >>> IMO, reassembly should be done >>> within the SFC domain >>> (responsible for fragmentation) >>> not passed away. (2) Does the >>> stateful mode require all SFC >>> data plane elements maintain a >>> full list of MTU for the any >>> SFF/SF instance of the SFC >>> >>> domain? >>> >>> >>> The current text suggests that >>> [RFC6830] should be listed as >>> normative reference (not an >>> informative one). I would >>> personally favor removing the >>> reference to LISP (as it is an >>> Experimental RFC). >>> >>> * The security section of the >>> draft may be augmented with >>> informational >>> fragmentation-related pointers >>> to: >>> e.g., RFC1858 (Security >>> Considerations for IP Fragment >>> Filtering), RFC3128 (Protection >>> Against a Variant of the Tiny >>> Fragment Attack), and RFC 4963 >>> (IPv4 Reassembly Errors at High >>> Data Rates). >>> >>> Cheers, Med >>> >>> -----Message d'origine----- >>> De : sfc >>> [mailto:sfc-bounces@ietf.or= g >>> >> >] >>> De la part de >>> mohamed.boucadair@orange.co= m >>> >> mohamed.boucadair@orange.com> >>> Envoy=C3=A9 : lundi 11 avri= l >>> 2016 13:14 =C3=80 : Thomas >>> Narten; sfc@ietf.org >>> Objet >>> : Re: >>> [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Dear Thomas, all, >>> >>> As I mentioned during the >>> meeting, there are several >>> issues >>> that are not covered in the >>> last version of the draft. = I >>> already provided examples o= f >>> the issues offline as >>> requested >>> by Martin. >>> >>> Cheers, Med >>> >>> -----Message >>> d'origine----- De : sfc >>> [mailto: >>> sfc-bounces@ietf.org >>> >> sfc-bounces@ietf.org>] >>> De la part de Thomas >>> Narten >>> Envoy=C3=A9 : jeudi 31 = mars >>> 2016 04:48 =C3=80 : >>> sfc@ietf.org >>> >>> Objet : [sfc] WG last >>> call for >>> draft-ietf-sfc-nsh-04.t= xt >>> >>> Dear WG: >>> >>> This note begins a WG >>> last call on >>> draft-ietf-sfc-nsh-04.t= xt >>> ( >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>> >>> >>> >>> The editors of the NSH document have indicated that they ha= ve >>> >>> addressed all known >>> comments and that there >>> are no open >>> issues with the current >>> version of the document= . >>> >>> Substantive comments to >>> the list please, >>> editorial comments >>> can go directly to the >>> document editors. >>> >>> We'll also get a brief >>> update from the editors >>> at next >>> week's meeting. If ther= e >>> are any remaining issue= s >>> with the >>> document, raising them >>> before the meeting woul= d >>> be >>> especially helpful. >>> >>> For the chairs, Thomas >>> >>> >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing >> >> > --001a114187be61056505318b71f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SmltLDxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLiBUbyBwYXJhcGhy YXNlIHdoYXQgSSBqdXN0IHNhaWQgdG8gSm9lbCwgaWYgdGhhdOKAmXMgdGhlIGludGVudCwgdGhl biB0aGUgdGV4dCBzaG91bGQgbWFrZSBpdCBjbGVhci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PlRoYW5rcyw8L2Rpdj48ZGl2PkFuZHk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEFw ciAyOCwgMjAxNiBhdCA5OjIyIEFNLCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSA8c3BhbiBkaXI9 Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqZ3VpY2hhckBjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj5qZ3VpY2hhckBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KDQoNCg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5IaSBBbmR5LDwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayB0aGUga2V5IHBvaW50IGlzIHRoYXQgTlNIICE9IG5l dHdvcmsgb3ZlcmxheSBidXQgcmF0aGVyIHV0aWxpemVzIGE8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+wqA8L3NwYW4+bmV0d29yayBvdmVybGF5IGZvciBwYWNrZXQgdHJhbnNwb3J0IGJl dHdlZW4gU0ZDIG5ldHdvcmsgZWxlbWVudHMuIFRoZSByZWZlcmVuY2UgaXMganVzdCBhbiBleGFt cGxlIG9mIGhvdyBhIG5ldHdvcmsgb3ZlcmxheSBtaWdodCBkZWFsIHdpdGgNCiBmcmFnbWVudGF0 aW9uIGFuZCBpcyBub3QgYSBzdWdnZXN0aW9uIHRoYXQgTlNIIGFkb3B0IHRoYXQgbWVjaGFuaXNt IGJ1dCByYXRoZXIgbWFrZXMgdGhlIHBvaW50IHRoYXQgaXQgY2FuIHV0aWxpemUgdGhlIGV4aXN0 aW5nIG5ldHdvcmsgb3ZlcmxheSBtZWNoYW5pY3MuwqA8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkppbTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuPg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6 YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JERVItTEVGVDptZWRpdW0gbm9uZTtQ QURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQQURESU5HLVJJR0hUOjBpbjtCT1JE RVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdIVDptZWRpdW0gbm9uZTtQQURESU5H LVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5z ZmMgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90O0FuZHJl dyBHLiBNYWxpcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFnbWFsaXNAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YWdtYWxpc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIEFwcmlsIDI4LCAyMDE2 IGF0IDg6MTcgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj5Kb2VsIEhhbHBlcm4gRGlyZWN0ICZsdDs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2Vs aGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1 b3Q7RWx6dXIsIFVyaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5j b20iIHRhcmdldD0iX2JsYW5rIj51cmkuZWx6dXJAaW50ZWwuY29tPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3Jn PC9hPiZndDssIExpbmRhIER1bmJhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpbmRhLmR1bmJhckBo dWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6 IFtzZmNdIFN1Z2dlc3RlZCB3b3JkaW5nIGFkZHRpb24gdG8gdGhlIFNlY3Rpb24gNiAoRnJhZ21l bnRhdGlvbiBDb25zaWRlcmF0aW9uKSBvZiB0aGUgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+Sm9lbCwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBkaWFncmFtcyBpbiBzZWN0aW9u IDYgb2YgUkZDIDY4MzAgYXJlIGNvbnRyb2wgcGxhbmUsIG5vdCBkYXRhIHBsYW5lLiBUaGUgZGF0 YSBwbGFuZSBkaWFncmFtcyBhcmUgaW4gc2VjdGlvbiA1LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+QnV0IHRoZSBvdmVycmlkaW5nIHF1ZXN0aW9uIGlzIC0gd2l0aG91dCBhbnkgZmll bGRzIGluIHRoZSBOU0ggaGVhZGVyIHRvIHNlcXVlbmNlIGZyYWdtZW50cywgaG93IGNhbiB0aGUg ZnJhZ21lbnRzIGJlIGNvcnJlY3RseSByZWFzc2VtYmxlZD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biBXZWQsIEFwciAyNywgMjAxNiBhdCA3OjQ2IFBNLCBKb2VsIEhhbHBlcm4gRGlyZWN0IDxzcGFu IGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5j b20iIHRhcmdldD0iX2JsYW5rIj5qbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij4NClRoZSBMSVNQIGhlYWRlciBkb2VzIG5vdCBoYXZlIGEgZnJhZ21lbnQgZmxhZyBvciBm cmFnbWVudCBvZmZzZXQuwqAgVGhlIGRpYWdyYW1zIGluIHNlY3Rpb24gNiBpbmNsdWRlIHRoZSBv dXRlciBlbmNhcHN1bGF0aW5nIGhlYWRlciAodGhlIGVxdWl2YWxlbnQgb2YgdGhlIHRyYW5zcG9y dCBoZWFkZXIgaW4gU0ZDLinCoCBZZXMsIHRoZSB0ZXh0IGlzIGEgbGl0dGxlIGhhcmQgdG8gZm9s bG93IGluIHRoaXMgcmVnYXJkLsKgIFRoZSBMSVNQIHdvcmtpbmcNCiBncm91cCBpcyBnb2luZyB0 byBiZSByZXdyaXRpbmcgUkZDIDY4MzAgYXMgcGFydCBvZiBtb3ZpbmcgdG8gc3RhbmRhcmRzIHRy YWNrLjxicj4NCjxicj4NClNvIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgaW4gdGhpcyByZWdhcmQg YmV0d2VlbiBOU0ggYW5kIExJU1AuPGJyPg0KPGJyPg0KWW91cnMsPGJyPg0KSm9lbDxicj4NCjxi cj4NCk9uIDQvMjcvMTYgNzowMiBQTSwgQW5kcmV3IEcuIE1hbGlzIHdyb3RlOjxicj4NCjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KSm9lbCBldCBhbCw8YnI+ DQo8YnI+DQpBbGwgdGhpcyB0YWxrIGFib3V0IGZyYWdtZW50YXRpb24gcHJvbXB0ZWQgbWUgdG8g cmUtcmVhZCBzZWN0aW9uIDYgb2Y8YnI+DQp0aGUgZHJhZnQsIHdoaWNoIHJlY29tbWVuZHMgKGFz IG9wdGlvbiAzKSB1c2luZyB0aGUgcHJvY2VkdXJlcyBpbjxicj4NCnNlY3Rpb24gNS40IG9mIFJG QyA2ODMwIChwcmVzdW1hYmx5IHdpdGggdGhlIOKAnE5TSCBoZWFkZXLigJ0gcmVwbGFjaW5nIHRo ZTxicj4NCuKAnExJU1AgaGVhZGVy4oCdIGluIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvY2Vk dXJlcyBpbiB0aGF0IHNlY3Rpb24pLjxicj4NCjxicj4NClNvIHRoYXQgbGVkIG1lIHRvIHJlYWQg dGhhdCBzZWN0aW9uIChhbmQgdGhlIExJU1AgaGVhZGVyIGRlZmluaXRpb24gaW48YnI+DQpzZWN0 aW9uIDUuMSksIGFuZCBJIHNlZSB0aGF0IExJU1AgZG9lcyBmcmFnbWVudGF0aW9uIGFuZCByZWFz c2VtYmx5PGJyPg0KaWRlbnRpY2FsbHkgdG8gSVB2NCwgdXNpbmcgdGhlIEZyYWdtZW50IE9mZnNl dCBmaWVsZCBzbyB0aGF0IGZyYWdtZW50czxicj4NCmNhbiBiZSBjb3JyZWN0bHkgcmVhc3NlbWJs ZWQgaW4gdGhlIHByb3BlciBvcmRlci48YnI+DQo8YnI+DQpIb3dldmVyLCB0aGUgTlNIIEhlYWRl ciBkb2VzbuKAmXQgaGF2ZSBhIEZyYWdtZW50IE9mZnNldCBmaWVsZCBvciBhbnk8YnI+DQpvdGhl ciB3YXkgdG8gb3JkZXIgdGhlIGZyYWdtZW50cy48YnI+DQo8YnI+DQpTbyBob3cgY2FuIHRoZSBw cm9jZWR1cmVzIGluIFNlY3Rpb24gNS40IG9mIDY4MzAgYmUgdXNlZD88YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KQW5keTxicj4NCjxicj4NCk9uIFdlZCwgQXByIDI3LCAyMDE2IGF0IDQ6MTkgUE0s IEpvZWwgTS4gSGFscGVybiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPjxicj4NCiZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCsKgIMKgIEJvdGgg bWV0aG9kcyBhcmUgdmFsaWQsIGFuZCBib3RoIGRlcGVuZCB1cG9uIGRldGFpbHMgb2YgdGhlPGJy Pg0KwqAgwqAgdW5kZXJseWluZyBwYWNrZXQgYW5kIHRoZSB0cmFuc3BvcnQuwqAgQXMgc3VjaCwg SSBkb24mIzM5O3Qgc2VlIHdoeSB0aGlzPGJyPg0KwqAgwqAgZG9jdW1lbnQgYmVuZWZpdHMgZnJv bSBkZXNjcmliaW5nIHRoZW0sIG11Y2ggbGVzcyB3aHkgaXQgc2hvdWxkIG1hcms8YnI+DQrCoCDC oCBvbmUgbWV0aG9kIGFzIGEgJnF1b3Q7c2hvdWxkJnF1b3Q7LsKgIEltcGxlbWVudGF0aW9uIGRl dGFpbHMgYXJlIGxpa2VseSB0byBiZTxicj4NCsKgIMKgIG1vcmUgc2lnbmlmaWNhbnQgdGhhbiBh bnkgYml0IGNvbnN1bXB0aW9uIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvPGJyPg0KwqAgwqAg YWx0ZXJuYXRpdmVzLjxicj4NCjxicj4NCsKgIMKgIFlvdXJzLDxicj4NCsKgIMKgIEpvZWw8YnI+ DQo8YnI+DQo8YnI+DQrCoCDCoCBPbiA0LzI3LzE2IDM6NDAgUE0sIExpbmRhIER1bmJhciB3cm90 ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBJIHN1Z2dlc3QgYWRkaW5nIHRoZSBmb2xsb3dpbmcg cGFyYWdyYXBocyBhZnRlciB0aGUgQnVsbGV0IDMgb2Y8YnI+DQrCoCDCoCDCoCDCoCB0aGUgU2Vj dGlvbiA2IEZyYWdtZW50YXRpb24gQ29uc2lkZXJhdGlvbiB0byBtYWtlIHRoZSBwcm9jZXNzPGJy Pg0KwqAgwqAgwqAgwqAgbW9yZSBjbGVhciBhbmQgbGVzcyBjb250cm92ZXJzaWFsOjxicj4NCjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgUkZDNjgzMCBkZXNjcmliZXMgdGhlIGZyYWdtZW50YXRpb24g bWV0aG9kIG9mIGJyZWFraW5nIHRoZTxicj4NCsKgIMKgIMKgIMKgIG9yaWdpbmFsIHBhY2tldCBp bnRvIHR3byBlcXVhbCBzdWItZnJhbWVzIGFuZCBlbmNhcHN1bGF0aW5nPGJyPg0KwqAgwqAgwqAg wqAgW0xJU1AgSGVhZGVyICsgVHJhbnNwb3J0IGhlYWRlcl0gdG8gZWFjaCBzdWItZnJhbWUuPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgSWYgTElTUCBmcmFnbWVudGF0aW9uIFtSRkM2ODMwIFNlY3Rp b24gNS40XSBpcyB1c2VkLCB0aGUgW1NGQzxicj4NCsKgIMKgIMKgIMKgIEhlYWRlciArIFRyYW5z cG9ydCBIZWFkZXJdIHdpbGwgYmUgYWRkZWQgdG8gZWFjaCBoYWxmIGZyYW1lIChvcjxicj4NCsKg IMKgIMKgIMKgIHRoZSBvcmlnaW5hbCBkYXRhIGZyYW1lKS4gQXMgdGhlIFRyYW5zcG9ydCBIZWFk ZXIgaXMgdGVybWluYXRlZDxicj4NCsKgIMKgIMKgIMKgIGJ5IHRoZSBuZXh0IFNGRiBub2RlJiMz OTtzIHR1bm5lbCB0cmFuc3BvcnQgbGF5ZXIsIHRoZSBjb21iaW5lZCB0d288YnI+DQrCoCDCoCDC oCDCoCBzdWItZnJhbWVzIHdpbGwgaGF2ZSB0d28gU0ZDIEhlYWRlcnMuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgVGhlcmVmb3JlLCB0aGUgZnJhZ21lbnRhdGlvbiBmb3IgTlNIIGVuY2Fwc3VsYXRl ZCBkYXRhIGZyYW1lPGJyPg0KwqAgwqAgwqAgwqAgc2hvdWxkIGJlIGRvbmUgY29tcGxldGVseSBi eSB0aGUgbm9kZSB0dW5uZWwgdHJhbnNwb3J0IGxheWVyLDxicj4NCsKgIMKgIMKgIMKgIHdoaWNo IHNob3VsZCBicmVhayB0aGUgW1NGQyArIG9yaWdpbmFsIHBhY2tldF0gaW50byB0d28gZXF1YWw8 YnI+DQrCoCDCoCDCoCDCoCBzdWItZnJhbWVzIGFuZCBlYWNoIHN1Yi1mcmFtZSBiZWluZyBlbmNh cHN1bGF0ZWQgd2l0aCBpdHM8YnI+DQrCoCDCoCDCoCDCoCByZXNwZWN0aXZlIHR1bm5lbCBoZWFk ZXIuwqAgVGhlIG5leHQgU0ZGIG5vZGUmIzM5O3MgdHVubmVsIHRyYW5zcG9ydDxicj4NCsKgIMKg IMKgIMKgIGxheWVyIHNob3VsZCBjb21iaW5lIHRoZSB0d28gc3ViLWZyYW1lcyBiZWZvcmUgc2Vu ZGluZyB0byB0aGU8YnI+DQrCoCDCoCDCoCDCoCBuZXh0IG5vZGUuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgQnkgdGhlIHdheSwgdGhlcmUgYXJlIHRv IHR5cG8gaW4gdGhlIFNlY3Rpb24gNjo8YnI+DQrCoCDCoCDCoCDCoCAzcmQgbGluZTogJnF1b3Q7 SW4gb3JkZXIgdGhlJnF1b3Q7ID09Jmd0OyAmcXVvdDtJbiBvcmRlciB0byZxdW90Ozxicj4NCsKg IMKgIMKgIMKgIExhc3QgbGluZSBvZiBCdWxsZXQgMjogZXh0cmEgJnF1b3Q7dGhlJnF1b3Q7IGlu IHRoZSAmcXVvdDt1dGlsaXplZCB0byBlbnN1cmU8YnI+DQrCoCDCoCDCoCDCoCB0aGUgdGhlIHJl cXVpcmVkIHBhY2tldCZxdW90Oy48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBIb3BlIGl0 IGhlbHBzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIExpbmRhPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQrCoCDCoCDCoCDC oCBGcm9tOiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0 Ozxicj4NCsKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPC9hPjxicj4NCsKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPC9hPiZndDtdPGJyPg0KwqAgwqAgwqAgwqAgU2VudDogV2VkbmVzZGF5LCBB cHJpbCAyNywgMjAxNiAxMjo0MCBBTTxicj4NCsKgIMKgIMKgIMKgIFRvOiBKb2VsIE0uIEhhbHBl cm47IExpbmRhIER1bmJhcjsgRWx6dXIsIFVyaTsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKgIMKgICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNm Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgU3ViamVjdDogUkU6IFtzZmNdIFdH IGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKgIMKg IMKgIMKgIEhpIEpvZWwsIGFsbCw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBQbGVhc2Ugc2VlIGlu bGluZS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBDaGVlcnMsPGJyPg0KwqAgwqAgwqAgwqAgTWVk PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1NZXNzYWdlIGQmIzM5O29yaWdpbmUt LS0tLTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIERlIDogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhAam9l bGhhbHBlcm4uY29tPC9hPiZndDtdIEVudm95w6kgOiBtYXJkaSAyNjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIGF2cmlsIDIwMTYgMTk6MTggw4AgOiBMaW5kYSBEdW5iYXI7IEJPVUNBREFJUiBNb2hh bWVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgSU1UL09MTjsgRWx6dXIsPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgVXJpOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyBPYmpldCA6IFJlOiBbc2Zj XSBXRzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgV2l0aCByZWdhcmQgdG8gVHJhbnNwb3J0IHR1bm5lbCBmcmFnZW1lbnRhdGlvbiwgdGhh dCBzZWVtczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGFuIGlzc3VlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgZm9yIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wuwqAgSSBkb24mIzM5O3QgYWN0dWFsbHkg b2JqZWN0IHRvIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBzZW50ZW5jZSw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCBidXQgaXQgZG9lcyBub3Qgc2VlbSB0aGF0IGl0IHdpbGwgYWNjb21wbGlzaCBh bnl0aGluZy48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBbTWVkXSBJIHdvdWxkIGxpa2Ug dG8gc2VlIHNvbWUgdGV4dCBhZGRlZCB0byB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgV2l0aCByZWdhcmQgdG8gcGFja2V0cyBmcmFnbWVudGVkIGJ5IHRoZSBz b3VyY2UsIEk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBjb21wbGV0ZWx5IGRpc2FncmVlPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgd2l0aCB5b3VyIGFzc2VydGlvbi7CoCBJZiBhbiBTRkYgd2VyZSB0 byByZWFzc2VtYmxlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHBhY2tldHMsIHRoYXQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCB3b3VsZCBiZSBhIHZpb2xhdGlvbiBvZiBpdHMgam9iLjxicj4N Cjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIFtNZWRdIEkgYWdyZWUgd2l0aCB5b3UuPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgVGhlcmUgaXMgbm8gcmVhc29uIGZvciBhbiBTRkYgdG88YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCByZWFzc2VtYmxlIGEgcGFja2V0IGZyYWdtZW50ZWQgYnkg dGhlIHNvdXJjZS7CoCBUaGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBjbGFzc2lmaWVyIG1heSBo YXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgdG8gZG8gc29tZSBpbnRlcmVzdGluZyB0aGluZ3Mg aW4gb3JkZXIgdG8gcHJvcGVybHkgY2xhc3NpZnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBzdWNj ZWVkaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzLCBidXQgdGhhdCBpcyBhbiBp bXBsZW1lbnRhdGlvbiBpc3N1ZSAobW9zdCBjb21tb25seTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IGFkZHJlc3NlZCB3aXRoIHZpcnR1YWwgcmVhc3NlbWJseSwgd2hpY2ggZG9lIHNub3QgZGVsYXkg dGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzLinCoCBXZSBkb24mIzM5O3Qgc3Bl Y2l0eSB0aGF0Ljxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIFtNZWRdIFN0aWxsLCB0aGUg ZXh0ZXJuYWwgYmVoYXZpb3Igb2YgdGhlIGNsYXNzaWZpZXIgbmVlZHMgdG8gYmU8YnI+DQrCoCDC oCDCoCDCoCBjbGVhciBpbiB0aGUgZG9jdW1lbnQuIEkgZG9uJiMzOTt0IGZpbmQgYW55IHRleHQg aW4gdGhlIGRyYWZ0IHNheWluZzxicj4NCsKgIMKgIMKgIMKgIGZvciBpbnN0YW5jZSB0aGF0IGFu IE5TSCBoZWFkZXIgbXVzdCBiZSBwcmVzZW50IGluIGFsbDxicj4NCsKgIMKgIMKgIMKgIGZyYWdt ZW50cy4gKFRoZXJlIHNvbWUgcHJvY2Vzc2luZyB0aGF0IG1pZ2h0IGJlIG5lZWRlZCBhdCB0aGU8 YnI+DQrCoCDCoCDCoCDCoCBTRkYgdG8gJnF1b3Q7ZG8gaXRzIGpvYiZxdW90OyB3aXRoIHJlZ2Fy ZHMgdG8gZnJhZ21lbnRzIChyZWNlaXZlIG91dCBvZjxicj4NCsKgIMKgIMKgIMKgIG9yZGVyIGZy YWdtZW50cyArIGZvcndhcmRpbmcgcG9saWN5IG9uIHRoZSBmdWxsIHBhY2tldCkuKTxicj4NCjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIElmIGFuIFNGIG5lZWRzIHRvIHJlYXNzZW1ibGUg ZnJhZ21lbnRzIHRvIGRvIGl0cyBqb2IsIHRoYXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBpcyB1 cCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHRoZSBTRi7CoCBTb21lIHdpbGwgbmVlZCB0byBh Y3R1YWxseSByZWFzc2VtYmxlLsKgIFNvbWUgd2lsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIG5l ZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBwZXJmb3JtIHZpcnR1YWwgcmVhc3NlbWJseSwg YW5kIHNvbWUgd2lsbCBoYXBwaWx5IHByb2Nlc3MgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg ZnJhZ21lbnRzLsKgIEkgY2FuIG5vdCBzZWUgd2hhdCB0aGUgTlNIIGRvY3VtZW50IGNvdWxkPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgcG9zc2libHkgbWFuZGF0ZS48YnI+DQo8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCBbTWVkXSBGdWxseSBhZ3JlZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCBZb3Vycyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBKb2VsPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgT24gNC8yNi8xNiAxMTo0NyBBTSwgTGluZGEgRHVuYmFyIHdyb3RlOjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEpvZWwsPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSSB0aGluayB0aGUgZG9jdW1lbnQgc2hvdWxkIGFkZCB0aGUgZGVz Y3JpcHRpb24gb24gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZm9sbG93aW5nIHR3 bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50YXRpb24gc2NlbmFyaW9zOjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0gVHJhbnNwb3J0IHR1bm5lbCBnZW5l cmF0ZWQgZnJhZ21lbnRhdGlvbjogV2hlbiBhIHBhY2tldDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGZyYWdtZW50YXRpb24gaXMgY2F1c2VkIGJ5IHRyYW5zcG9ydCB0dW5uZWwgKGkuZS4g dmFyaW91czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVuY2Fwc3VsYXRpb25zKSwgdGhl IHRlcm1pbmF0aW9uIHBvaW50IG9mIHRoZSB0cmFuc3BvcnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0dW5uZWwgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXNwb25zaWJs ZSBmb3IgcmUtYXNzZW1ibGluZyB0aGUgZnJhZ21lbnRlZCBwaWVjZXMgb2Y8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB0aGUgcGFja2V0Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFNpbmNlIHRoZXJlIHdvbiYjMzk7dCBiZSBhbnkgU0ZGIG5vZGVzIGluIGJldHdlZW4gdGhlPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVHJhbnNwb3J0IFR1bm5lbCw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB0aGUgdHVubmVsIGdlbmVyYXRlZCBmcmFnbWVudGF0aW9uIGRvZXMg bm90IHJlcXVpcmUgYW55PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWN0aW9ucyBieTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNGRiBub2RlcyBvciBTRiBub2Rlcy48YnI+DQo8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtIFNvdXJjZSBub2RlIGdlbmVyYXRl ZCBmcmFnbWVudGF0aW9uIChhZnRlciBhZGRpbmcgb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0aGUgTlNIPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGVhZGVyKTogV2hlbiBm cmFnbWVudGF0aW9uIGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIGE8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBwYWNrZXQgYmVpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbmNh cHN1bGF0ZWQgd2l0aCB0aGUgTlNIIGhlYWRlciwgZWl0aGVyIHRoZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGludGVybWVkaWF0ZSBTRkYgbm9kZXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBvciB0aGUgU0Ygbm9kZXMgaGF2ZSB0byBiZSBhYmxlIHRvIHJlYXNzZW1ibGUgdGhl PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRlZCBwaWVjZXMuPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ2hlZXJzLDxicj4N Cjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIExpbmRhPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogSm9l bCBNLiBIYWxwZXJuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVm PSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFs cGVybi5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2Vs aGFscGVybi5jb208L2E+Jmd0O10gU2VudDogVHVlc2RheSwgQXByaWwgMjYsPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgMjAxNiAxMDozMyBBTTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFRvOiBMaW5kYSBEdW5iYXI7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs7IEVsenVyLCBVcmk7PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsgU3ViamVjdDogUmU6IFtz ZmNdIFdHPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGFzdCBjYWxsIGZvcjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZS1yZWFkaW5nIHlvdXIgbm90ZSwgaXQgaXMgcG9z c2libGUgdGhhdCB5b3UgYXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVmZXJyaW5n IG9ubHkgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgY2FzZSBvZiB0cmFuc3Bv cnQgZ2VuZXJhdGVkIGZyYWdtZW50YXRpb24gb2YgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgb3V0ZXIgcGFja2V0Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgaGFkIGFz c3VtZWQgeW91IHdlcmUgbm90IHRhbGtpbmcgYWJvdXQgdGhhdCwgc2luY2UgdGhlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVzdWx0aW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZnJhZ21lbnRzIHdpbGwgbm90IGFsbCBoYXZlIE5TSCBoZWFkZXJzLsKgIEFzIHdpdGggYW55 IHR1bm5lbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRlY2hub2xvZ3ksIGlmIHRoZSB0 dW5uZWwgY2hvb3NlcyB0byBmcmFnbWVudCBhdCBpdHM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBsYXllciwgdGhlbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0dW5uZWwg aXMgcmVzcG9uc2libGUgZm9yIHJlYXNzZW1ibHkuwqAgVGhhdCB3b3VsZCBiZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGludmlzaWJsZSB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHRoZSBTRkYuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgWW91cnMsIEpv ZWw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiA0LzI2LzE2IDExOjEwIEFN LCBMaW5kYSBEdW5iYXIgd3JvdGU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgQWdyZWUgd2l0aCBNZWQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgRXZlbiBpZiBlYWNoIGZyYWdtZW50IHBpZWNlIG9mIGEgcGFja2V0IHdpdGggTlNIPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGVhZGVyIGNhcnJpZXMgdGhlPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTlNIIGhlYWRlciwgdGhlIGludGVybWVkaWF0 ZSBTRkYgbm9kZXMgc3RpbGwgbmVlZCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHB1dCB0b2dldGhlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFsbCB0 aGUgZnJhZ21lbnRzIHRvZ2V0aGVyIGJlZm9yZSBwYXNzaW5nIHRoZSB3aG9sZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRhdGEgZnJhbWUgdG88YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB0aGUgU0YuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgTGluZGE8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBzZmM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 O108YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiBCZWhhbGYgT2YgPGEgaHJl Zj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj4N Cm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208 L2E+Jmd0OyBTZW50OiBNb25kYXksPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg QXByaWwgMjUsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMjAxNiA5OjQyIEFN IFRvOiBFbHp1ciwgVXJpOyBKb2VsIE0uIEhhbHBlcm47PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsgU3ViamVjdDo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFm dC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgUmUtLDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhvdyBk byB5b3UgaW5zdHJ1Y3QgdGhlIHRyYW5zcG9ydCBsYXllciB0byBBTFdBWVM8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcmVwZW5kIGFuIE5TSDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGhlYWRlciBldmVuIGZvciBmcmFnbWVudHM/IE9yIHlvdSBkb24mIzM5 O3QgY2FyZSBhYm91dCB0aGF0Pzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFRoYW5rIHlvdS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBD aGVlcnMsIE1lZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS0gRGUgOiBFbHp1ciwgVXJpPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208 L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5l bHp1ckBpbnRlbC5jb208L2E+Jmd0O10gRW52b3nDqSA6IGx1bmRpIDI1PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXZyaWwgMjAxNiAxNjoyNiDDgDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M TjsgSm9lbCBNLiBIYWxwZXJuOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0 Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7IE9iamV0PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBSRTogW3NmY10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50 eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBNZWQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOb3QgdG8gcmVw ZWF0IG15IHBvc2l0aW9uLCBidXQgSSYjMzk7bGwgZG8gaXQgYW55aG93PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOi0pIEFzIE5TSCBpczxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICpOT1QqIGEgdHJhbnNwb3J0LCBkZWFsaW5nIHdpdGgg ZnJhZ21lbnRhdGlvbiBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGxlZnQgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVHJh bnNwb3J0IHVzZWQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgVGhlIG1vZGVsIEkgdXNlIGZvciBOU0gsIGlzIGJhc2ljYWxseSBzaW1pbGFyIHRvPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVlhMQU4gLiBJdCBpcyBhbjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG92ZXJseS48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaHg8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBVcmkgKCZxdW90O09vLVJlZSZxdW90OykgQzog PGEgaHJlZj0idGVsOjk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJf YmxhbmsiPg0KOTQ5LTM3OC03NTY4PC9hPiAmbHQ7dGVsOjxhIGhyZWY9InRlbDo5NDktMzc4LTc1 NjgiIHZhbHVlPSIrMTk0OTM3ODc1NjgiIHRhcmdldD0iX2JsYW5rIj45NDktMzc4LTc1Njg8L2E+ Jmd0Ozxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IE9uIEJlaGFsZiBPZiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IFNlbnQ6PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTW9uZGF5LCBBcHJpbCAyNSw8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2IDc6MTggQU0gVG86IEpvZWwgTS4gSGFscGVy bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVy bi5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDsmZ3Q7Ozxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3ViamVjdDogUmU6 IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSGkgSm9lbCw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBQbGVhc2Ugc2VlIGlubGluZS48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tTWVzc2FnZSBkJiMz OTtvcmlnaW5lLS0tLS0gRGUgOiBKb2VsIE0uIEhhbHBlcm48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT48YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpv ZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7XSBFbnZvecOpIDogbHVuZGk8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyNSBhdnJpbCAyMDE2IDE1OjQ4IMOAPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBCT1VDQURBSVIgTW9o YW1lZCBJTVQvT0xOOyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsgT2JqZXQgOiBSZTogW3NmY10gV0c8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsYXN0IGNhbGwgZm9y IGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJZiBJIGFtIHVuZGVyc3RhbmRpbmcgeW91IGNvcnJlY3Rs eSBNZWQsIHlvdTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGFyZSBhc2tpbmcgdGhhdCB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBOU0ggZHJhZnQgc3BlY2lmeSBob3cgc2VydmljZSBjaGFpbmluZzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNob3VsZCBjb3BlIHdpdGgg cGFja2V0czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRo YXQgaGF2ZSBiZWVuIGZyYWdtZW50ZWQ/PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gVG8gYmUgYWNjdXJhdGUsIEkmIzM5O20gYXNraW5n IHRvIGFzc2Vzczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdoZXRo ZXIgdGhlcmUgYXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1w bGljYXRpb25zLiBJZiB0aGVyZSBhcmUsIHRoZW4gdGhlIGRyYWZ0PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2hvdWxkIGJlIHVwZGF0ZWQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhY2NvcmRpbmdseS48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0gsIGFuZCB0aGUgU0ZGIGZ1bmN0 aW9uYWxpdHksIGRvZXMgbm90IGNhcmUuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gSSYjMzk7bSBub3QgdGhhdCBzdXJlLiBTb21lIHR5 cGljYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbXBsaWNhdGlv bnMgYXJlIGxpc3RlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJl bG93Ojxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogU0ZG OiBJZiB0aGUgTlNIIGhlYWRlciBpcyBwcmVzZW50IG9ubHkgaW4gdGhlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSBmcmFnbWVudCBidXQgU0ZGPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGlkbiYjMzk7dCBtYWludGFpbmVkIGEgc3Rh dGUsIHN1YnNlcXVlbnQgZnJhZ21lbnRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgd29uJiMzOTt0IGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYXBwcm9wcmlhdGVseSBwcm9jZXNzZWQuICogU0ZDLWF3YXJlIGZ1bmN0aW9uOjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIHByZXBlbmRpbmcgYTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnRleHQgaW5mb3JtYXRpb24g ZGVwZW5kcyBvbiB0aGUgZnVsbCBwYWNrZXQsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgbm90IG9ubHkgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGZyYWdtZW50Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIEl0IGp1c3QgZG9lcyBpdHMgam9iLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFtNZWRdIHdoaWNoIG1heSBiZSBkaXN0dXJiZWQgaW4gc29tZSBz aXR1YXRpb25zPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgbGlz dGVkIGluIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4YW1w bGVzIGFib3ZlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIEluZ3Jlc3MgYW5kIGludGVybWVkaWF0ZSBjbGFzc2lmaWVycyBtYXk8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb3BlIHdpdGggZnJhZ21lbnRz IGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW55IG51 bWJlciBvZiB3YXlzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFNwZWNpZnlpbmcgc3VjaCBpcyBjbGVhcmx5IG91dCBvZiBzY29wZSBmb3IgdGhpczxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0Ljxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtNZWRdIFRoZSBwdXJwb3NlIGlzIG5v dCB0byBzcGVjaWZ5IHRoZSBpbnRlcm5hbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGltcGxlbWVudGF0aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgZGV0YWlscyBidXQgdGhlIGV4dGVybmFsIGJlaGF2aW9yIG9mIHRoZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsYXNzaWZpZXIgZnVuY3Rpb24gd2hl bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGl0IGNvbWVzIHRvIGhh bmRsZSBmcmFnbWVudHMuIFRoYXQgYmVoYXZpb3IgbWF5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaGF2ZSBhbiBpbmNpZGVuY2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBvbiBTRkYsIGluIHBhcnRpY3VsYXIuIFRoZSBwdXJwb3NlIGlz IG5vdCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlY29tbWVu ZCB0aGUgbWF4aW11bTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJl c291cmNlcyB0byBiZSBkZWRpY2F0ZWQgdG8gb3V0IG9mIG9yZGVyPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzIG5vciB0aGU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aW1lb3V0IHRvIGNhY2hlIHRob3NlOyB0aGVzZSBj b25zaWRlcmF0aW9ucyBhcmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBvZiBjb3Vyc2Ugb3V0IG9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc2NvcGUuIE5ldmVydGhlbGVzcywgYW4gaW1wbGVtZW50YXRpb24gc2hvdWxkPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2ZmZXIgYSBjb25maWd1cmFibGU8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwYXJhbWV0ZXIgc28gdGhhdCBh biBvcGVyYXRvciB0d2VhayB0aG9zZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGFjY29yZGluZyB0byBpdHM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBjb250ZXh0Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEkgc3VwcG9zZSBvbmUgY291bGQgd3JpdGUgYW4gaW5mb3JtYXRpb25hbDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0IG9uIHBv c3NpYmxlIHdheXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBvZiBjb3BpbmcuwqAgVGhlIElFVEYgaGFzIG5vdCB1c3VhbGx5PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHVibGlzaGVkIHN1Y2guPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU2VydmljZSBmdW5jdGlvbnMgaGF2 ZSB0byBjb3BlIHdpdGg8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBmcmFnbWVudGVkIHBhY2tldHMganVzdCBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZXkgaGFkIHRvIGJlZm9yZSB0aGUgYWR2ZW50IG9mIE5T SCwgc288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZXNj cmliaW5nIHRoYXQgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBjbGVhcmx5IG5vdCBuZWVkZWQgaGVyZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVkXSBUaGUgYWR2ZW50IG9mIE5TSCBoYXMgdGhl IGZvbGxvd2luZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGltcGxp Y2F0aW9uczogKiBpdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4 YWNlcmJhdGVzIGZyYWdtZW50YXRpb24uIEhhbmRpbmcgb3ZlciB0aGlzPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWUgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJhbnNwb3J0IGxheWVyIG1heSBsZWFkIHRvIGludGVy b3BlcmFiaWxpdHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1 ZXMuICogdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2hhaW5p bmcgbWF5IG5vdCBiZSBlZmZpY2llbnQgaWYgZnJhZ21lbnRzIGFyZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluYXBwcm9wcmlhdGVseTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhhbmRsZWQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSW50cm9kdWNpbmcgTlNIIHNob3VsZCBub3QgZGVncmFk ZSB0aGUgb3ZlcmFsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNl cnZpY2UgY29tcGFyZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBsZWdhY3kgc2VydmljZSBkZXBsb3ltZW50IHNjaGVtZXMuPGJyPg0KPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgWW91cnMsIEpvZWw8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiA0LzI1LzE2 IDM6MDAgQU0sPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2Js YW5rIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZS0sPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBoZWFyIHlvdSwgYnV0 IG15IGNvbW1lbnQgaXMgdGhhdCB3ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIG5lZWQsIGFzIGEgV0csIHRvIGRlY2lkZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdoYXQgdG88YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwdXQgaW4gdGhlIGRy YWZ0LiBGV0lXLCBJJiMzOTttIGRpc2N1c3NpbmcgdHdvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzc3Vlczo8YnI+DQo8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoMSkgRnJhZ21lbnRh dGlvbiB0aGF0IGlzIGNhdXNlZCBieTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHByZXBlbmRpbmcgYW4gU0ZDIGhlYWRlci48YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoMikgSGFuZGxpbmcgZnJh Z21lbnRzIGF0IHRoZSBpbmdyZXNzIG9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgYW4gU0ZDLWVuYWJsZWQgZG9tYWluLjxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEluY3JlYXNpbmcg dGhlIE1UVSBpcyBmb3Igc3VyZSBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgcmVjb21tZW5kYXRpb24gaXMgdG8gYmU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleHBsaWNpdGx5PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2FsbGVkIG91dCBp biB0aGUgdGV4dCAoc2VlIG15IGZpcnN0IG1lc3NhZ2UpLjxicj4NCjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZXJlIGFyZSBvdGhl ciBpc3N1ZXMgdGhhdCBuZWVkIHRvIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZGlzY3Vzc2VkLCBlLmcuLCBob3cgdG88YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZWFsIHdpdGg8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMg aW4gU0ZGcy9DbGFzc2lmaWVycz88YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJdCBpcyBhbHNvICZxdW90O3BydWRlbnQmcXVv dDsgdG8gY2hlY2sgdGhhdCBubzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGlzc3VlcyB3aWxsIGJlIGV4cGVyaWVuY2VkPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW4gU0ZGPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gaGFuZGxlIGZyYWdt ZW50cy4gSWYgYW4gU0ZDIGhlYWRlciBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHByZXBlbmRlZCBmb3IgYWxsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzLCBJJiMzOTttIG5vdCBzdXJlIHRoZXJl PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaXMgYW55IHBhcnRpY3VsYXIgaXNzdWUgYXQgdGhlIFNGRjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxldmVsLCBleGNlcHQgaWY8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdHJpcHBpbmcv YWRkaW5nPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgY29udGV4dCBUTFZzIGRlcGVuZHMgb24gdGhlIGZ1bGwgcGFja2V0IChub3Q8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBqdXN0IGZyYWdtZW50KS4gSXQ8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyB3YXJyYW50 ZWQgdG8gY29uc2lkZXIgYSBsaXR0bGUgYml0IHRoaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwb2ludCBiZWZvcmUgZGVjbGFyaW5nPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlcmUgaXMgbm8gaXNzdWUuPGJy Pg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgRm9yIHBvaW50ICgxKSwgZGVjbGFyaW5nIGZyYWdtZW50YXRpb248YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvdXQgb2Ygc2NvcGUgd291 bGQgYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBtZWFudCB0aGF0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYW4gaW1wbGVtZW50YXRpb24gbXVzdCBiZSBwcmVwYXJlZCB0bzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlY2VpdmUgZnJhZ21lbnRzIHdp dGggb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aXRo b3V0IE5TSCBoZWFkZXIgYXMgdGhpcyBpcyBhIGRlY2lzaW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCBpcyBsZWZ0IHRvIHRoZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRyYW5zcG9ydCBlbmNhcHN1bGF0 aW9uLiBUaGlzIGlzIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCByZXF1aXJlbWVudCBwZXIgc2UhPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSB3b24mIzM5O3QgcmVpdGVyYXRlIGFs bCB0aGUgY29tbWVudHMgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGhhdmUgYWJvdXQgdGhlIGN1cnJlbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b3JkaW5nIG9mPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhpcyBzZWN0aW9uLjxicj4N Cjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIENoZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1NZXNzYWdlIGQmIzM5O29yaWdpbmUtLS0tLSBE ZSA6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgRWx6dXIsIFVyaTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVyaS5lbHp1ckBpbnRl bC5jb20iIHRhcmdldD0iX2JsYW5rIj51cmkuZWx6dXJAaW50ZWwuY29tPC9hPjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5jb20iIHRhcmdldD0iX2JsYW5rIj51 cmkuZWx6dXJAaW50ZWwuY29tPC9hPiZndDtdIEVudm95w6k8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6IGx1bmRpIDI1IGF2cmlsIDIw MTY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCAwODozMCDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhvbWFzIE5hcnRl bjs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT2JqZXQgOiBSRTogW3NmY10gV0cg bGFzdCBjYWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBNZWQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBNeSBwb2ludCBpcyB0aGF0IEZyYWdtZW50YXRpb24gaXM8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB5ZXQgYW5vdGhlciB0 cmFuc3BvcnQgcmVsYXRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGlzc3VlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIGJleW9uZCB0aGUgc2NvcGUgb2Yg TlNIIGFuZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGJleW9uZCB0aGUgY2hhcnRlciBvZiB0aGUgV0csIHNvPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQ8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb2VzbiYjMzk7dDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHJlYWxseSBiZWxvbmcgaW4gdGhlIGRyYWZ0LiBXZSBhcmU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm92aWRpbmcgYW4g YWR2aWNlIGFzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgZXh0ZW5kaW5nIHRoZSBzaXplIG9mIHRoZSBwYWNrZXQgbWF5PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGVhZCB0 byBmcmFnbWVudGF0aW9uLCBidXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcyB5b3UgY2hlY2sgUkZDIDczNDggVnhMQU4sIHdoaWNo PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgbXkgY3JlYXRlIHRoZSBzYW1lIGlzc3VlLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHlvdSYjMzk7bGwgZmluZCBpdCBkb2VzbiYj Mzk7dCBldmVuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgcmVsYXRlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gaXQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGh4PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVXJpICgmcXVv dDtPby1SZWUmcXVvdDspIEM6IDxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0 OTM3ODc1NjgiIHRhcmdldD0iX2JsYW5rIj4NCjk0OS0zNzgtNzU2ODwvYT48YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7dGVsOjxh IGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0OTM3ODc1NjgiIHRhcmdldD0iX2Js YW5rIj45NDktMzc4LTc1Njg8L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tIEZyb206IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0 O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XSBPbjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJlaGFsZiBPZjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhy ZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgU2VudDo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdW5kYXksIEFwcmlsIDI0 LCAyMDE2PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgMTA6MzIgUE0gVG86IEVsenVyLCBVcmk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVy aS5lbHp1ckBpbnRlbC5jb20iIHRhcmdldD0iX2JsYW5rIj51cmkuZWx6dXJAaW50ZWwuY29tPC9h Pjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVyaS5lbHp1ckBpbnRlbC5jb20iIHRhcmdl dD0iX2JsYW5rIj51cmkuZWx6dXJAaW50ZWwuY29tPC9hPiZndDsmZ3Q7Ozxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRob21hcyBOYXJ0 ZW48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5hcnRlbkB1cy5pYm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+bmFy dGVuQHVzLmlibS5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5hcnRlbkB1cy5p Ym0uY29tIiB0YXJnZXQ9Il9ibGFuayI+bmFydGVuQHVzLmlibS5jb208L2E+Jmd0OyZndDs7PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc2Zj QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFN1YmplY3Q6IFJlOiBbc2ZjXSBX RyBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhpIFVy aSw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBUaGF0JiMzOTtzIGFub3RoZXIgb3B0aW9uIHRoYXQgbmVlZHMgdG88YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZSBk aXNjdXNzZWQvaW52ZXN0aWdhdGVkLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkmIzM5O208YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhZnJhaWQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGlzIGlzIG5vdCB0 aGUgcmF0aW9uYWxlIGFkb3B0ZWQgaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtMDQgc2luY2UgaXQgaW5jbHVkZXMgc29tZTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRl eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0 aGF0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgaXMgZmFyIHRvIGJlIHN1ZmZpY2llbnQgdG8gZW5zdXJlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW50ZXJvcGVy YWJsZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGltcGxlbWVudGF0aW9ucy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBCVFcsIHNheWluZyB0aGF0IG5zaCBkb2Vz IG5vdCBuZWVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgdG8gZGVhbCB3aXRoIGZyYWdtZW50YXRpb248YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZWNhdXNlPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQ8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBp cyB0cmFuc3BvcnQtaW5kZXBlbmRlbnQgaXMgbm90IElNSE88YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhIGdvb2Qgc3RyYXRlZ3kgdG8g YWRvcHQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBoZXJlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYmVjYXVzZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGl0IG9wZW5zIHRoZSBkb29yIGZvciBpbnRlcm9wZXJh YmxlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaXNzdWVzLCBpdCBtYXkgbGVhZCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1Yi1vcHRpbWFsIGltcGxlbWVudGF0aW9u cyBpZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBzZmMgaW5mb3JtYXRpb24gaXMgcHJlc2VudDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9ubHkgaW4gb25lPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRz LDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGV0Yy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBNeSBjb21tZW50cyBhcmUgcmVsYXRlZCB0byB0aGU8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBj dXJyZW50IHRleHQgaW4gdGhlIC0wNC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGlzIHRleHQgbmVlZHM8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0bzxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJlIGZpeGVk IHNvbWVob3cuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgQ2hlZXJzLCBNZWQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU1lc3NhZ2Ug ZCYjMzk7b3JpZ2luZS0tLS0tIERlIDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFbHp1ciwgVXJpPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVy aS5lbHp1ckBpbnRlbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208 L2E+Jmd0O108YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBFbnZvecOpIDogZGltYW5jaGUgMjQgYXZyaWw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2 IDE3OjM2IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJTVQvT0xOOyBUaG9tYXMgTmFy dGVuOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyBPYmpldCA6 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgUkU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLXNm Yy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSGkgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBzZWUgbm8g bmVlZCB0byBzcGVjaWZ5IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4YWN0IGJlaGF2aW9yIGFzIE5TSCBpczxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHRyYW5zcG9ydCBpbmRlcGVuZGVudCBpLmUuIGxpa2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggaW50ZXJhY3Rp b24gd2l0aCBhbnkgb3RoZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUcmFuc3BvcnQgZWggaXNzdWUgb2Y8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBG cmFnbWVudGF0aW9uIGlzIHRvIGJlIGRlYWx0IGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSB3YXk8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0 IG1hdGNoZXMgdGhlIG1lY2hhbmlzbXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdXBwb3J0ZWQgYnkgdGhlIFRyYW5zcG9y dCB1c2VkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYW5kIGRvIG5vdCBiZWxvbmcgaW4gdGhlIE5TSCBkcmFmdDxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFRoeDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFVyaSAoJnF1b3Q7T28tUmVlJnF1b3Q7KSBDOiA8YSBo cmVmPSJ0ZWw6OTQ5LTM3OC03NTY4IiB2YWx1ZT0iKzE5NDkzNzg3NTY4IiB0YXJnZXQ9Il9ibGFu ayI+DQo5NDktMzc4LTc1Njg8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O3RlbDo8YSBocmVmPSJ0ZWw6OTQ5LTM3 OC03NTY4IiB2YWx1ZT0iKzE5NDkzNzg3NTY4IiB0YXJnZXQ9Il9ibGFuayI+OTQ5LTM3OC03NTY4 PC9hPiZndDs8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBG cm9tOiBzZmM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZs dDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O108YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiBCZWhhbGYgT2Y8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgU2VudDogVGh1cnNkYXksIEFwcmlsIDE0LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDIwMTYgMTI6NDMgQU0gVG86IFRo b21hcyBOYXJ0ZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hcnRlbkB1cy5pYm0uY29t IiB0YXJnZXQ9Il9ibGFuayI+bmFydGVuQHVzLmlibS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5jb20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0 ZW5AdXMuaWJtLmNvbTwvYT4mZ3Q7Jmd0Ozs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGll dGYub3JnPC9hPiZndDsgU3ViamVjdDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZv cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSLSw8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBJbiBhZGRpdGlvbiB0byBvdGhlciBwZW5kaW5nPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVzIHJh aXNlZCBmb3IgdGhpcyBkcmFmdCwgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdvdWxkIGxpa2UgdG8gcmFpc2UgdGhpczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGFkZGl0aW9uYWwgb25lIGFib3V0IFNlY3Rpb24gNi48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA9PSA2 LsKgIEZyYWdtZW50YXRpb24gQ29uc2lkZXJhdGlvbnM8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggYW5kIHRo ZSBhc3NvY2lhdGVkIHRyYW5zcG9ydDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlYWRlciBhcmUgJnF1b3Q7YWRkZWQmcXVv dDsgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZW5jYXBzdWxhdGVkIHBhY2tldC9mcmFtZS7CoCBUaGlzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluY3JlYXNlczxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZTxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHNpemUgb2YgdGhlIHBhY2tldC7CoCBJbiBvcmRlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBlbnN1cmUgcHJvcGVy IGZvcndhcmRpbmcgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0ggZGF0YSwgc2V2ZXJhbCBvcHRpb25zIGZvcjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGhhbmRsaW5nIGZyYWdtZW50YXRpb24gYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmUtYXNzZW1ibHkgZXhpc3Q6 PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgMS7CoCBKdW1ibyBGcmFtZXMsIHdoZW48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdXBwb3J0ZWQs IGVuYWJsZSB0aGUgdHJhbnNwb3J0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgTlNIPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5kIGFzc29jaWF0 ZWQgdHJhbnNwb3J0IHBhY2tldHM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aXRob3V0IHJlcXVpcmluZzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZy YWdtZW50YXRpb24uPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMi7CoCBQYXRoIE1UVSBEaXNjb3Zlcnk8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBbUkZDMTE5MV0mcXVvdDtkZXNjcmliZXMgYSB0ZWNobmlxdWUgZm9yPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHluYW1p Y2FsbHkgZGlzY292ZXJpbmcgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbWF4aW11bSB0cmFuc21pc3Npb24gdW5pdCAo TVRVKSBvZjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGFuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgYXJiaXRyYXJ5IGludGVybmV0IHBhdGgmcXVvdDsgYW5kIGNh bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGJlIHV0aWxpemVkIHRvIGVuc3VyZSB0aGU8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXF1aXJlZCBwYWNr ZXQgc2l6ZSBpcyB1c2VkLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDMuwqAgW1JGQzY4MzBdIGRlc2NyaWJlcyB0 d288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBzY2hlbWVzIGZvciBmcmFnbWVudGF0aW9uIGFuZDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlLTxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzc2VtYmx5 PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgaW4gc2VjdGlvbiA1LjQuID09PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBUaGUgdGV4 dCBpcyB3ZWFrIGZvciBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3RhbmRhcmQgdHJhY2sgZG9jdW1lbnQgdGhhdCBpczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGludGVuZGVkIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGluPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0OTgjc2VjdGlvbi0iIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc0 OTgjc2VjdGlvbi08L2E+PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgMi4xMi48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGVyZSBzaG91bGQgYmUgYSBjbGVhciBiZWhhdmlv cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHRvIGJlIGZvbGxvd2VkIGJ5IGFuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50YXRpb24uPGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRnVydGhl ciwgSSB3b3VsZCBhdm9pZCB0aGUgdXNlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2Ygd29yZHMgc3VjaCBhcyAmcXVvdDtj YW4mcXVvdDsuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBUaGUgdGV4dCBjb3ZlcnMgb25seTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZy YWdtZW50YXRpb24gd2hlbiBpdCBpcyBpbmR1Y2VkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkgU0ZDPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3Bl cmF0aW9ucywgaXQgZG9lcyBub3QgZGlzY3Vzczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSB0cmVhdG1lbnQgb2YgYSBm cmFnbWVudDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHdoZW4gcmVjZWl2ZWQgaW4gYW4gU0ZDIGRvbWFpbi48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJ TUhPLCB0aGUgZHJhZnQgc2hvdWxkIGFsc288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzcGVjaWZ5IHRoZSBiZWhhdmlvciBv ZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBDbGFzc2lmaWVyIHdpdGggcmVnYXJkcyB0bzxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50 cyBmb3IgdGhlIHNha2Ugb2YgcHJvcGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU0ZDIG9wZXJhdGlvbi4gQXBwbHlpbmc8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBjbGFzc2lmaWNhdGlvbiBwb2xpY2llcyBtYXk8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXF1aXJlIHRoZTxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGZ1bGwgcGFja2V0LCBub3Qgb25seSBhIGZyYWdtZW50Ljxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElu IHBhcnRpY3VsYXIsIGRlZGljYXRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlc291cmNlcyBzaG91bGQgZGVkaWNhdGVk IGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGhhbmRsaW5nIG91dCBvZiBvcmRlciBmcmFnbWVudHMuPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT2Yg Y291cnNlLCBpdCBpcyBvdXQgb2Ygc2NvcGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiB0aGlzIGRvY3VtZW50IHRvIGRl c2NyaWJlIGhvdzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFNGcyBoYW5kbGUgZnJhZ21lbnRzLjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICog SWYgYW4gU0ZDIGhlYWRlciBpcyBwcmVwZW5kZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmb3IgYWxsIGZyYWdtZW50cywg SSYjMzk7bSBub3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBzdXJlIHRoZXJlIGlzIGFueSBwYXJ0aWN1bGFyPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg aXNzdWUgYXQgdGhlIFNGRiBsZXZlbC4uLmV4Y2VwdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlmIHN0cmlwcGluZy9hZGRp bmcgY29udGV4dCBUTFZzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVwZW5kcyBvbiB0aGUgZnVsbCBwYWNrZXQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAobm90IGp1c3QgZnJhZ21lbnQpLiBJdCBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdhcnJhbnRlZCB0byBjb25zaWRl ciBhIGxpdHRsZSBiaXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGlzIHBvaW50IGJlZm9yZSBkZWNsYXJpbmcgdGhlcmU8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpczxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG5vIGlzc3VlLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIHRleHQgc3RhdGVzICZx dW90O3NldmVyYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBvcHRpb25zJnF1b3Q7LiBUaGlzIG1heSBiZSBpbnRlcnByZXRl ZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGFzIGlmIGltcGxlbWVudGluZyBvbmUgb2YgdGhlbTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIHN1ZmZp Y2llbnQuLi53aGljaCBpcyBub3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0cnVlLiBUaGUgZmlyc3QgdHdvIHBvaW50czxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGNvbnRyaWJ1dGUgdG8gbWluaW1pemUgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbiBy aXNrLCBidXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudGF0aW9uIG1heSBzdGlsbCBiZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4cGVy aWVuY2VkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgKGUuZy4sIG90aGVyIHNoaW1zIGFyZSBwcmVwZW5kZWQ8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBi eSBvdGhlciBub2RlcyBmb3Igc29tZSBvdGhlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHB1cnBvc2VzLCBuZXN0ZWQgbnNo LCBldGMuKTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIGZpcnN0IHR3byBwb2ludHMgaGF2ZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IG5vdGhpbmcgdG8gZG8gd2l0aCByZWFzc2VtYmx5Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIHN1cHBv cnQgb2YganVtYm8gZnJhbWVzIGJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSByb3V0ZXIvZGV2aWNlIGRvZXMgbm90IG1l YW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB0aGF0IGl0IGNhbiBtYWtlIHVzZSBvZiBpdC48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBcHByb3ByaWF0 ZSBNVFUgY29uZmlndXJhdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNob3VsZCBiZSB1bmRlcnRha2VuIGluIGE8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBjb25zaXN0ZW50IG1hbm5lciB3aXRoaW4gYW4gU0ZDPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZG9tYWluLiBUaGUg dGV4dCBzaG91bGQgYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1cGRhdGVkIHRvIG1ha2UgaXQgaXMgYWJvdXQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAoY29uc2lzdGVudCkgTVRVPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgY29uZmlndXJhdGlvbi48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIEJUVywgc2hvdWxk biYjMzk7dCB0aGUgdGV4dCBiZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJld29yZGVkIHRvIHJlY29tbWVuZGVkIHRvPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaW5jcmVhc2UgdGhlIE1UVSBvZiAqKmFsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG5vZGVzKiogb2YgYW4gU0ZD LWVuYWJsZWQgZG9tYWluIGJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXQgbGVhc3QgdGhlIGxlbmd0aCBvZiBTRkM8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBoZWFkZXIgKyB0cmFuc3BvcnQgaGVhZGVyPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogQnVsbGV0IDIs IGhvdyBQTVRVIGRpc2NvdmVyeTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIGFjdHVhbGx5IHVzZWQgaW4gdGhpczxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGNvbnRleHQ/IERvIHlvdSBhc3N1bWUgdGhhdCBhbGw8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTRkMtYXdhcmUgbm9k ZXMgd2lsbCBpc3N1ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1Y2ggbWVzc2FnZXMgdG93YXJkcyBvdGhlcjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFNGQy1hd2FyZSBub2RlLCBhcmJpdHJhcnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZXN0aW5hdGlvbiwgZWxzZT88YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAqIEJ1bGxldCAyLCBJIHdvdWxkIGRyb3A8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtkZXNjcmli ZXMgYSB0ZWNobmlxdWUgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHluYW1pY2FsbHkgZGlzY292ZXJpbmcgdGhlPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgbWF4aW11bSB0cmFuc21pc3Npb24gdW5pdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChNVFUpIG9mIGFuIGFyYml0 cmFyeSBpbnRlcm5ldDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBhdGgmcXVvdDsuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBCdWxsZXQg Miwgcy8gdGhlIHRoZS90aGUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBUaGUgcmVmZXJlbmNlIHRvIHRoZSBM SVNQPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgc3BlY2lmaWNhdGlvbiByYWlzZXMgdHdvIGNvbmNlcm5zPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW5k IG9uZSBjb21tZW50Ojxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICgxKSBJIGRvbiYjMzk7dCB0aGluayBpdCBpcyBh IGdvb2Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBhcHByb2FjaCB0aGF0IGZyYWdtZW50cyBpbmR1Y2VkPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkg dGhlIG5ldHdvcmsgYXJlIHBhc3NlZCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZWlyIHVsdGltYXRlIGRlc3RpbmF0 aW9ucyBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHN1Y2g8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAoc3RhdGVsZXNzKS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJTU8sIHJlYXNzZW1ibHkgc2hv dWxkIGJlIGRvbmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB3aXRoaW4gdGhlIFNGQyBkb21haW48YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAocmVzcG9u c2libGUgZm9yIGZyYWdtZW50YXRpb24pPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbm90IHBhc3NlZCBhd2F5LiAoMikgRG9l cyB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzdGF0ZWZ1bCBtb2RlIHJlcXVpcmUgYWxsIFNGQzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRhdGEg cGxhbmUgZWxlbWVudHMgbWFpbnRhaW4gYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZ1bGwgbGlzdCBvZiBNVFUgZm9yIHRo ZSBhbnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBTRkYvU0YgaW5zdGFuY2Ugb2YgdGhlIFNGQzxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvbWFpbj88 YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgY3VycmVudCB0ZXh0IHN1Z2dlc3RzIHRoYXQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBbUkZDNjgzMF0gc2hvdWxkIGJlIGxpc3RlZCBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG5vcm1hdGl2ZSByZWZlcmVu Y2UgKG5vdCBhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGluZm9ybWF0aXZlIG9uZSkuIEkgd291bGQ8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwZXJz b25hbGx5IGZhdm9yIHJlbW92aW5nIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlZmVyZW5jZSB0byBMSVNQIChhcyBp dCBpcyBhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIEV4cGVyaW1lbnRhbCBSRkMpLjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogVGhlIHNl Y3VyaXR5IHNlY3Rpb24gb2YgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQgbWF5IGJlIGF1Z21lbnRlZCB3aXRo PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgaW5mb3JtYXRpb25hbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50YXRpb24tcmVsYXRlZCBwb2lu dGVycyB0bzo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBlLmcuLCBSRkMxODU4IChTZWN1cml0eTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENvbnNpZGVy YXRpb25zIGZvciBJUCBGcmFnbWVudDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZpbHRlcmluZyksIFJGQzMxMjggKFByb3Rl Y3Rpb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBBZ2FpbnN0IGEgVmFyaWFudCBvZiB0aGUgVGlueTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZyYWdt ZW50IEF0dGFjayksIGFuZCBSRkMgNDk2Mzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChJUHY0IFJlYXNzZW1ibHkgRXJyb3Jz IGF0IEhpZ2g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBEYXRhIFJhdGVzKS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS08YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBEZSA6IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIERlIGxhIHBhcnQgZGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86 bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRW52b3nDqSA6 IGx1bmRpIDExIGF2cmlsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMjAxNiAxMzoxNCDDgCA6IFRob21hczxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE5hcnRlbjsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4m Z3Q7IE9iamV0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBSZTo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbc2ZjXSBXRyBsYXN0 IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIERlYXIgVGhvbWFzLCBhbGwsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXMgSSBt ZW50aW9uZWQgZHVyaW5nIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1lZXRpbmcsIHRoZXJlIGFyZSBzZXZl cmFsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCBhcmUgbm90IGNvdmVy ZWQgaW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGFzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gSTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGFscmVhZHkgcHJvdmlkZWQgZXhhbXBsZXMgb2Y8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUg aXNzdWVzIG9mZmxpbmUgYXMgcmVxdWVzdGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnkgTWFydGluLjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIENoZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0t LS1NZXNzYWdlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZCYjMzk7b3JpZ2luZS0tLS0tIERlIDogc2Zj PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtdPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgRGUgbGEgcGFydCBkZSBUaG9tYXMgTmFydGVuPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgRW52b3nDqSA6IGpldWRpIDMxIG1hcnM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2IDA0 OjQ4IMOAIDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPYmpldCA6IFtzZmNdIFdH IGxhc3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjYWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRy YWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEZWFyIFdH Ojxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMgbm90ZSBiZWdpbnMgYSBXRzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGxhc3QgY2FsbCBvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYt c2ZjLW5zaC0wNC50eHQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLyIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zZmMtbnNoLzwvYT4pLjxicj4NCjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIFRoZSBlZGl0b3JzIG9mIHRoZSBOU0ggZG9jdW1lbnQgaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0 aGV5IGhhdmU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhZGRyZXNzZWQgYWxsIGtub3duPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgY29tbWVudHMgYW5kIHRoYXQgdGhlcmU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBhcmUgbm8gb3Blbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzc3VlcyB3aXRoIHRoZSBjdXJy ZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuPGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgU3Vic3RhbnRpdmUgY29tbWVudHMgdG88YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0aGUgbGlzdCBwbGVhc2UsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZWRpdG9yaWFsIGNvbW1l bnRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2FuIGdvIGRpcmVjdGx5IHRvIHRoZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGRvY3VtZW50IGVkaXRvcnMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2Um IzM5O2xsIGFsc28gZ2V0IGEgYnJpZWY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1cGRhdGUgZnJvbSB0 aGUgZWRpdG9yczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGF0IG5leHQ8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB3ZWVrJiMzOTtzIG1lZXRpbmcuIElmIHRoZXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXJlIGFu eSByZW1haW5pbmcgaXNzdWVzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2l0aCB0aGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBkb2N1bWVudCwgcmFpc2luZyB0aGVtPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmVm b3JlIHRoZSBtZWV0aW5nIHdvdWxkIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXNwZWNpYWxseSBo ZWxwZnVsLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZvciB0aGUgY2hhaXJzLCBUaG9tYXM8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNmYyBtYWlsaW5nPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgbGlzdCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3Jn PC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNmYyBtYWlsaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGlzdCA8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYzwvYT48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNmYyBtYWlsaW5nPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGlz dCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0 Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYzwvYT48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNmYyBtYWlsaW5nPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwv ZGl2Pg0KDQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --001a114187be61056505318b71f9-- From nobody Thu Apr 28 06:32:36 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 8DDB012D14E for ; Thu, 28 Apr 2016 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 7hLDq2Nu9jzI for ; Thu, 28 Apr 2016 06:32:31 -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 6ACCE12D720 for ; Thu, 28 Apr 2016 06:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=157925; q=dns/txt; s=iport; t=1461849755; x=1463059355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DqUtCgIxxcX1at+Wr3OMbCOFa/ixSnWJWHy97Pmdc48=; b=ZLM/h4/RxFu1GMcQjDyyXaI7Za8/rYrPRB6tgpZ/s1KIObkoD0pRYo3P Rkm8LxHfnlELjkXvWD8WqlLuMBPXuuO4YJ4oMDDeeYgjofHk2f34f7J9k 2pMiB3emOp1IlcStwYeupzBVt4i1GOdMDfL8mgv0zodrBqE+qf7dOu688 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAgAWDiJX/49dJa1bA4JsTFN9Bq4Qi?= =?us-ascii?q?14BDYFyBBcBCoVtAoEnOBQBAQEBAQEBZSeEQQEBAQQBAQEXAQJKBwsMBAIBCBE?= =?us-ascii?q?DAQEBIQECBAchBgsUCQgCBAENBYgVAxIOvlINhEsBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQERBIYhhEuCQYIcASaFDwWHdIsrhEAxAYV7gneDLoF2gWeETYMphTSGJIE?= =?us-ascii?q?th14BHgEBQoI2gTVshml/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208,217";a="267110899" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 13:22:33 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3SDMWlY002718 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 13:22:32 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 08:22:31 -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.1104.009; Thu, 28 Apr 2016 08:22:31 -0500 From: "Jim Guichard (jguichar)" To: "Andrew G. Malis" , Joel Halpern Direct Thread-Topic: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLy5gODJbPprtEyKsV065fH5RJ+elnwAgAAtrACAAAwigIAA0eUA///PIYA= Date: Thu, 28 Apr 2016 13:22:31 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D34786324C66Ajguicharciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 13:32:34 -0000 --_000_D34786324C66Ajguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, I think the key point is that NSH !=3D network overlay but rather utilizes = a network overlay for packet transport between SFC network elements. The re= ference is just an example of how a network overlay might deal with fragmen= tation and is not a suggestion that NSH adopt that mechanism but rather mak= es the point that it can utilize the existing network overlay mechanics. Jim From: sfc > on behalf of = "Andrew G. Malis" > Date: Thursday, April 28, 2016 at 8:17 AM To: Joel Halpern Direct > Cc: "Elzur, Uri" >, "mohame= d.boucadair@orange.com" >, "sfc@ietf.org" >, Linda Dunbar > Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentatio= n Consideration) of the draft-ietf-sfc-nsh-04.txt Joel, The diagrams in section 6 of RFC 6830 are control plane, not data plane. Th= e data plane diagrams are in section 5. But the overriding question is - without any fields in the NSH header to se= quence fragments, how can the fragments be correctly reassembled? Cheers, Andy On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct > wrote: The LISP header does not have a fragment flag or fragment offset. The diag= rams in section 6 include the outer encapsulating header (the equivalent of= the transport header in SFC.) Yes, the text is a little hard to follow in= this regard. The LISP working group is going to be rewriting RFC 6830 as = part of moving to standards track. So there is no difference in this regard between NSH and LISP. Yours, Joel On 4/27/16 7:02 PM, Andrew G. Malis wrote: Joel et al, All this talk about fragmentation prompted me to re-read section 6 of the draft, which recommends (as option 3) using the procedures in section 5.4 of RFC 6830 (presumably with the =93NSH header=94 replacing the =93LISP header=94 in the description of the procedures in that section). So that led me to read that section (and the LISP header definition in section 5.1), and I see that LISP does fragmentation and reassembly identically to IPv4, using the Fragment Offset field so that fragments can be correctly reassembled in the proper order. However, the NSH Header doesn=92t have a Fragment Offset field or any other way to order the fragments. So how can the procedures in Section 5.4 of 6830 be used? Thanks, Andy On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> wrote: Both methods are valid, and both depend upon details of the underlying packet and the transport. As such, I don't see why this document benefits from describing them, much less why it should mark one method as a "should". Implementation details are likely to be more significant than any bit consumption difference between the two alternatives. Yours, Joel On 4/27/16 3:40 PM, Linda Dunbar wrote: I suggest adding the following paragraphs after the Bullet 3 of the Section 6 Fragmentation Consideration to make the process more clear and less controversial: -------------------------------- RFC6830 describes the fragmentation method of breaking the original packet into two equal sub-frames and encapsulating [LISP Header + Transport header] to each sub-frame. If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Transport Header] will be added to each half frame (or the original data frame). As the Transport Header is terminated by the next SFF node's tunnel transport layer, the combined two sub-frames will have two SFC Headers. Therefore, the fragmentation for NSH encapsulated data frame should be done completely by the node tunnel transport layer, which should break the [SFC + original packet] into two equal sub-frames and each sub-frame being encapsulated with its respective tunnel header. The next SFF node's tunnel transport layer should combine the two sub-frames before sending to the next node. ------------------------------------------------------ By the way, there are to typo in the Section 6: 3rd line: "In order the" =3D=3D> "In order to" Last line of Bullet 2: extra "the" in the "utilized to ensure the the required packet". Hope it helps. Linda -----Original Message----- From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com >] Sent: Wednesday, April 27, 2016 12:40 AM To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, all, Please see inline. Cheers, Med -----Message d'origine----- De : Joel M. Halpern [mailto:jmh@joelhalpern.com >] Envoy= =E9 : mardi 26 avril 2016 19:18 =C0 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur, Uri; sfc@ietf.org > Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt With regard to Transport tunnel fragementation, that seems an issue for the transport protocol. I don't actually object to a sentence, but it does not seem that it will accomplish anything. [Med] I would like to see some text added to the draft. With regard to packets fragmented by the source, I completely disagree with your assertion. If an SFF were to reassemble the packets, that would be a violation of its job. [Med] I agree with you. There is no reason for an SFF to reassemble a packet fragmented by the source. The classifier may have to do some interesting things in order to properly classify succeeding fragments, but that is an implementation issue (most commonly addressed with virtual reassembly, which doe snot delay the fragments.) We don't specity that. [Med] Still, the external behavior of the classifier needs to be clear in the document. I don't find any text in the draft saying for instance that an NSH header must be present in all fragments. (There some processing that might be needed at the SFF to "do its job" with regards to fragments (receive out of order fragments + forwarding policy on the full packet).) If an SF needs to reassemble fragments to do its job, that is up to the SF. Some will need to actually reassemble. Some will need to perform virtual reassembly, and some will happily process the fragments. I can not see what the NSH document could possibly mandate. [Med] Fully agree. Yours, Joel On 4/26/16 11:47 AM, Linda Dunbar wrote: Joel, I think the document should add the description on the following two fragmentation scenarios: - Transport tunnel generated fragmentation: When a packet fragmentation is caused by transport tunnel (i.e. various encapsulations), the termination point of the transport tunnel is responsible for re-assembling the fragmented pieces of the packet. Since there won't be any SFF nodes in between the Transport Tunnel, the tunnel generated fragmentation does not require any actions by SFF nodes or SF nodes. - Source node generated fragmentation (after adding on the NSH header): When fragmentation has to be performed for a packet being encapsulated with the NSH header, either the intermediate SFF nodes or the SF nodes have to be able to reassemble the fragmented pieces. Cheers, Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com >] S= ent: Tuesday, April 26, 2016 10:33 AM To: Linda Dunbar; mohamed.boucadair@orange.com >; Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-reading your note, it is possible that you are referring only to the case of transport generated fragmentation of the outer packet. I had assumed you were not talking about that, since the resulting fragments will not all have NSH headers. As with any tunne= l technology, if the tunnel chooses to fragment at its layer, then the tunnel is responsible for reassembly. That would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: Agree with Med. Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-, How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that= ? Thank you. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a transport, dealing with fragmentation is left to the Transport used. The model I use for NSH, is basically similar to VXLAN . It is an overly. Thx Uri ("Oo-Ree") C: 949-378-7568 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 7:18 AM To: Joel M. Halpern >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, Please see inline. Cheers, Med -----Message d'origine----- De : Joel M. Halper= n [mailto:jmh@joelhalpern.com >] Envoy=E9 : lundi 25 avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Obje= t : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt If I am understanding you correctly Med, you are asking that the NSH draft specify how service chaining should cope with packets that have been fragmented? [Med] To be accurate, I'm asking to assess whether there are implications. If there are, then the draft should be updated accordingly. NSH, and the SFF functionality, does not care. [Med] I'm not that sure. Some typical implications are listed below: * SFF: If the NSH header is present only in the a fragment but SFF didn't maintained a state, subsequent fragments won't be appropriately processed. * SFC-aware function: if prepending a context information depends on the full packet, not only a fragment. It just does its job. [Med] which may be disturbed in some situations as listed in the examples above. Ingress and intermediate classifiers may cope with fragments in any number of ways. Specifying such is clearly out of scope for this draft. [Med] The purpose is not to specify the internal implementation details but the external behavior of the classifier function when it comes to handle fragments. That behavior may have an incidence on SFF, in particular. The purpose is not to recommend the maximum resources to be dedicated to out of order fragments nor the timeout to cache those; these considerations are of course out of scope. Nevertheless, an implementation should offer a configurable parameter so that an operator tweak those according to its context. I suppose one could write an informational draft on possible ways of coping. The IETF has not usually published such. Service functions have to cope with fragmented packets just as they had to before the advent of NSH, so describing that is clearly not needed here. [Med] The advent of NSH has the following implications: * it exacerbates fragmentation. Handing over this issue to the transport layer may lead to interoperability issues. * the chaining may not be efficient if fragments are inappropriately handled. Introducing NSH should not degrade the overall service compared to legacy service deployment schemes. Yours, Joel On 4/25/16 3:00 AM, mohamed.boucadair@orange.com > wrote: Re-, I hear you, but my comment is that we need, as a WG, to decide what to put in the draft. FWIW, I'm discussing two fragmentation issues: (1) Fragmentation that is caused by prepending an SFC header. (2) Handling fragments at the ingress of an SFC-enabled domain. Increasing the MTU is for sure a recommendation is to be explicitly called out in the text (see my first message). There are other issues that need to be discussed, e.g., how to deal with fragments in SFFs/Classifiers? It is also "prudent" to check that no issues will be experienced in SFF to handle fragments. If an SFC header is prepended for all fragments, I'm not sure there is any particular issue at the SFF level, except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. For point (1), declaring fragmentation out of scope would be meant that an implementation must be prepared to receive fragments with or without NSH header as this is a decision that is left to the transport encapsulation. This is a requirement per se! I won't reiterate all the comments I have about the current wording of this section. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : lundi 25 avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med My point is that Fragmentation is yet another transport related issue that is beyond the scope of NSH and beyond the charter of the WG, so it doesn't really belong in the draft. We are providing an advice as extending the size of the packet may lead to fragmentation, but as you check RFC 7348 VxLAN, which my create the same issue, you'll find it doesn't even relate to it. Thx Uri ("Oo-Ree") C: 949-378-7568 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Sunday, April 24, 2016 10:32 PM To: Elzur, Uri >>; Thomas Narten >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Uri, That's another option that needs to be discussed/investigated. I'm afraid this is not the rationale adopted in -04 since it includes some text that is far to be sufficient to ensure interoperable implementations. BTW, saying that nsh does not need to deal with fragmentation because it is transport-independent is not IMHO a good strategy to adopt here because it opens the door for interoperable issues, it may lead to sub-optimal implementations if the sfc information is present only in one fragments, etc. My comments are related to the current text in the -04. This text needs to be fixed somehow. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : dimanche 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med I see no need to specify the exact behavior as NSH is transport independent i.e. like NSH interaction with any other Transport eh issue of Fragmentation is to be dealt in a way that matches the mechanisms supported by the Transport used and do not belong in the NSH draft Thx Uri ("Oo-Ree") C: 949-378-7568 = > -----Original Message----- From: sf= c [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Thursday, April 14, 2016 12:43 AM To: Thomas Narten >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt R-, In addition to other pending issues raised for this draft, I would like to raise this additional one about Section 6. =3D=3D 6. Fragmentation Considerat= ions NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. In order the ensure proper forwarding of NSH data, several options for handling fragmentation and re-assembly exist: 1. Jumbo Frames, when supported, enable the transport of NSH and associated transport packets without requiring fragmentation. 2. Path MTU Discovery [RFC1191]"describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path" and can be utilized to ensure the the required packet size is used. 3. [RFC6830] describes two schemes for fragmentation and re- assembly in section 5.4. =3D=3D * The text is weak for a Standard track document that is intended to solve the problem in https://tools.ietf.org/html/rfc7498= #section- 2.12. There should be a clear behavior to be followed by an implementation. Further, I would avoid the use of words such as "can". * The text covers only fragmentation when it is induced by SFC operations, it does not discuss the treatment of a fragment when received in an SFC domain. IMHO, the draft should also specify the behavior of the Classifier with regards to fragments for the sake of proper SFC operation. Applying classification policies may require the full packet, not only a fragment. In particular, dedicated resources should dedicated for handling out of order fragments. Of course, it is out of scope of this document to describe how SFs handle fragments. * If an SFC header is prepended for all fragments, I'm not sure there is any particular issue at the SFF level...except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. * The text states "several options". This may be interpreted as if implementing one of them is sufficient...which is not true. The first two points contribute to minimize the fragmentation risk, but fragmentation may still be experienced (e.g., other shims are prepended by other nodes for some other purposes, nested nsh, etc.) * The first two points have nothing to do with reassembly. * The support of jumbo frames by a router/device does not mean that it can make use of it. Appropriate MTU configuration should be undertaken in a consistent manner within an SFC domain. The text should be updated to make it is about (consistent) MTU configuration. * BTW, shouldn't the text be reworded to recommended to increase the MTU of **all nodes** of an SFC-enabled domain by at least the length of SFC header + transport header? * Bullet 2, how PMTU discovery is actually used in this context? Do you assume that all SFC-aware nodes will issue such messages towards other SFC-aware node, arbitrary destination, else? * Bullet 2, I would drop "describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path". * Bullet 2, s/ the the/the. * The reference to the LISP specification raises two concerns and one comment: (1) I don't think it is a good approach that fragments induced by the network are passed to their ultimate destinations as such (stateless). IMO, reassembly should be done within the SFC domain (responsible for fragmentation) not passed away. (2) Does the stateful mode require all SFC data plane elements maintain a full list of MTU for the any SFF/SF instance of the SFC domain? The current text suggests that [RFC6830] should be listed as normative reference (not an informative one). I would personally favor removing the reference to LISP (as it is an Experimental RFC). * The security section of the draft may be augmented with informational fragmentation-related pointers to: e.g., RFC1858 (Security Considerations for IP Fragment Filtering), RFC3128 (Protection Against a Variant of the Tiny Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High Data Rates). Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org >] De la part de mohamed.boucadair@orange.com > Envoy=E9 : lundi 11 avril 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org > Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear Thomas, all, As I mentioned during the meeting, there are several issues that are not covered in the last version of the draft. I already provided examples of the issues offline as requested by Martin. Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.or= g >] De la part de Thomas Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org > Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear WG: This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datatracker.ietf.o= rg/doc/draft-ietf-sfc-nsh/). The editors of the NSH document have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. Substantive comments to the list please, editorial comments can go directly to the document editors. We'll also get a brief update from the editors at next week's meeting. If there are any remaining issues with the document, raising them before the meeting would be especially helpful. For the chairs, Thomas ___________________________= ____________________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailma= n/listinfo/sfc _______________________________= ________________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailman/li= stinfo/sfc ___________________________________= ____________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailman/listin= fo/sfc _______________________________________= ________ sfc mailing --_000_D34786324C66Ajguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <51CC8F4E024A9A46AF1B627BFFFD8B92@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Andy,

I think the key point is that NSH !=3D network overlay but rather util= izes a network overlay for p= acket transport between SFC network elements. The reference is just an exam= ple of how a network overlay might deal with fragmentation and is not a suggestion that NSH adopt that mechanism but ra= ther makes the point that it can utilize the existing network overlay mecha= nics. 

Jim

From: sfc <sfc-bounces@ietf.org> on behalf of "Andrew G= . Malis" <agmalis@gmail.com>
Date: Thursday, April 28, 2016 at 8= :17 AM
To: Joel Halpern Direct <jmh.direct@joelhalpern.com> Cc: "Elzur, Uri" <uri.elzur@intel.com>, "mohamed.boucadair@orange.com= " <mohamed.boucadai= r@orange.com>, "sfc@ietf.org" <sfc@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [sfc] Suggested wordin= g addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-= sfc-nsh-04.txt

Joel,

The diagrams in section 6 of RFC 6830 are control plane, not data plan= e. The data plane diagrams are in section 5.

But the overriding question is - without any fields in the NSH header = to sequence fragments, how can the fragments be correctly reassembled?

Cheers,
Andy

On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Di= rect <jmh.dir= ect@joelhalpern.com> wrote:
The LISP header does not have a fragment flag or fragment offset.  The= diagrams in section 6 include the outer encapsulating header (the equivale= nt of the transport header in SFC.)  Yes, the text is a little hard to= follow in this regard.  The LISP working group is going to be rewriting RFC 6830 as part of moving to standards tra= ck.

So there is no difference in this regard between NSH and LISP.

Yours,
Joel

On 4/27/16 7:02 PM, Andrew G. Malis wrote:
Joel et al,

All this talk about fragmentation prompted me to re-read section 6 of
the draft, which recommends (as option 3) using the procedures in
section 5.4 of RFC 6830 (presumably with the =93NSH header=94 replacing the=
=93LISP header=94 in the description of the procedures in that section).
So that led me to read that section (and the LISP header definition in
section 5.1), and I see that LISP does fragmentation and reassembly
identically to IPv4, using the Fragment Offset field so that fragments
can be correctly reassembled in the proper order.

However, the NSH Header doesn=92t have a Fragment Offset field or any
other way to order the fragments.

So how can the procedures in Section 5.4 of 6830 be used?

Thanks,
Andy

On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

    Both methods are valid, and both depend upon details of the     underlying packet and the transport.  As such, I don't s= ee why this
    document benefits from describing them, much less why it shou= ld mark
    one method as a "should".  Implementation deta= ils are likely to be
    more significant than any bit consumption difference between = the two
    alternatives.

    Yours,
    Joel


    On 4/27/16 3:40 PM, Linda Dunbar wrote:

        I suggest adding the following paragraphs after= the Bullet 3 of
        the Section 6 Fragmentation Consideration to ma= ke the process
        more clear and less controversial:


        --------------------------------

        RFC6830 describes the fragmentation method of b= reaking the
        original packet into two equal sub-frames and e= ncapsulating
        [LISP Header + Transport header] to each su= b-frame.

        If LISP fragmentation [RFC6830 Section 5.4] is = used, the [SFC
        Header + Transport Header] will be added to= each half frame (or
        the original data frame). As the Transport Head= er is terminated
        by the next SFF node's tunnel transport layer, = the combined two
        sub-frames will have two SFC Headers.

        Therefore, the fragmentation for NSH encapsulat= ed data frame
        should be done completely by the node tunnel tr= ansport layer,
        which should break the [SFC + original pack= et] into two equal
        sub-frames and each sub-frame being encapsulate= d with its
        respective tunnel header.  The next SFF no= de's tunnel transport
        layer should combine the two sub-frames before = sending to the
        next node.

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


        By the way, there are to typo in the Section 6:=
        3rd line: "In order the" =3D=3D> &= quot;In order to"
        Last line of Bullet 2: extra "the" in= the "utilized to ensure
        the the required packet".


        Hope it helps.

        Linda



        -----Original Message-----
        From: mohamed.boucadair@orange.com
        <mailto:mohamed.boucadair@orange.com>
        [mailto:mohamed.boucadair@orange.com
        <mailto:mohamed.boucadair@orange.com>]
        Sent: Wednesday, April 27, 2016 12:40 AM
        To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; = sfc@ietf.org
        <mailto:sfc@ietf.org>
        Subject: RE: [sfc] WG last call for draft-ietf-= sfc-nsh-04.txt

        Hi Joel, all,

        Please see inline.

        Cheers,
        Med

            -----Message d'origine-----
            De : Joel M. Halpern [mailto:jmh@joelhalpern.com
            <mailto:jmh@joelhalpern.com>] Envoy=E9 : = mardi 26
            avril 2016 19:18 =C0 : Linda Dunb= ar; BOUCADAIR Mohamed
            IMT/OLN; Elzur,
            Uri; sfc@ietf.org <mailto:sfc@ietf.org> Objet : Re: [sfc] WG
            last call for
            draft-ietf-sfc-nsh-04.txt

            With regard to Transport tunnel f= ragementation, that seems
            an issue
            for the transport protocol. = I don't actually object to a
            sentence,
            but it does not seem that it will= accomplish anything.


        [Med] I would like to see some text added to th= e draft.


            With regard to packets fragmented= by the source, I
            completely disagree
            with your assertion.  If an = SFF were to reassemble the
            packets, that
            would be a violation of its job.<= br>

        [Med] I agree with you.

          There is no reason for an SFF to

            reassemble a packet fragmented by= the source.  The
            classifier may have
            to do some interesting things in = order to properly classify
            succeeding
            fragments, but that is an impleme= ntation issue (most commonly
            addressed with virtual reassembly= , which doe snot delay the
            fragments.)  We don't specit= y that.


        [Med] Still, the external behavior of the class= ifier needs to be
        clear in the document. I don't find any text in= the draft saying
        for instance that an NSH header must be present= in all
        fragments. (There some processing that might be= needed at the
        SFF to "do its job" with regards to f= ragments (receive out of
        order fragments + forwarding policy on the = full packet).)


            If an SF needs to reassemble frag= ments to do its job, that
            is up to
            the SF.  Some will need to a= ctually reassemble.  Some will
            need to
            perform virtual reassembly, and s= ome will happily process the
            fragments.  I can not see wh= at the NSH document could
            possibly mandate.


        [Med] Fully agree.


            Yours,
            Joel

            On 4/26/16 11:47 AM, Linda Dunbar= wrote:

                Joel,

                I think the documen= t should add the description on the
                following two
                fragmentation scena= rios:

                - Transport tunnel = generated fragmentation: When a packet
                fragmentation is ca= used by transport tunnel (i.e. various
                encapsulations), th= e termination point of the transport
                tunnel is
                responsible for re-= assembling the fragmented pieces of
                the packet.
                Since there won't b= e any SFF nodes in between the
                Transport Tunnel,                 the tunnel generate= d fragmentation does not require any
                actions by
                SFF nodes or SF nod= es.


                - Source node gener= ated fragmentation (after adding on
                the NSH
                header): When fragm= entation has to be performed for a
                packet being
                encapsulated with t= he NSH header, either the
                intermediate SFF no= des
                or the SF nodes hav= e to be able to reassemble the
                fragmented pieces.<= br>



                Cheers,


                Linda

                -----Original Messa= ge----- From: Joel M. Halpern
                [mailto:jmh@joelhalpern.com
                <mailto:jmh@joelhalpern.com&g= t;] Sent: Tuesday, April 26,
                2016 10:33 AM
                To: Linda Dunbar; <= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com
                <mailto:mohamed.boucadai= r@orange.com>; Elzur, Uri;
                sfc@ietf.org <mailto:sfc@ietf.org> Subject: Re: [sfc] W= G
                last call for
                draft-ietf-sfc-nsh-= 04.txt

                Re-reading your not= e, it is possible that you are
                referring only to                 the case of transpo= rt generated fragmentation of the
                outer packet.
                I had assumed you w= ere not talking about that, since the
                resulting
                fragments will not = all have NSH headers.  As with any tunnel
                technology, if the = tunnel chooses to fragment at its
                layer, then the
                tunnel is responsib= le for reassembly.  That would be
                invisible to
                the SFF.

                Yours, Joel

                On 4/26/16 11:10 AM= , Linda Dunbar wrote:

                    Agree= with Med.

                    Even = if each fragment piece of a packet with NSH
                    heade= r carries the
                    NSH h= eader, the intermediate SFF nodes still need to
                    put t= ogether
                    all t= he fragments together before passing the whole
                    data = frame to
                    the S= F.

                    Linda=

                    -----= Original Message----- From: sfc
                    [mail= to:sfc-bounces@ie= tf.org
                    <m= ailto:sfc-bounces= @ietf.org>]
                    On Be= half Of mohamed.boucadair@orange.com
                    <m= ailto:moh= amed.boucadair@orange.com> Sent: Monday,
                    April= 25,
                    2016 = 9:42 AM To: Elzur, Uri; Joel M. Halpern;
                    sfc@ietf.org <mailto:sfc@ietf.org> Subjec= t:
                    Re: [= sfc] WG last call for draft-ietf-sfc-nsh-04.txt

                    Re-,<= br>
                    How d= o you instruct the transport layer to ALWAYS
                    prepe= nd an NSH
                    heade= r even for fragments? Or you don't care about that?

                    Thank= you.

                    Cheer= s, Med

                     = ;   -----Message d'origine----- De : Elzur, Uri
                     = ;   [mailto:u= ri.elzur@intel.com
                     = ;   <mailto:uri.elzur@intel.com>] Envoy=E9 : lundi 25
                     = ;   avril 2016 16:26 =C0
                     = ;   : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;
                     = ;   sfc@ietf.org= <mailto:sfc@ietf.org<= /a>> Objet
                     = ;   : RE: [sfc] WG last call for
                     = ;   draft-ietf-sfc-nsh-04.txt

                     = ;   Hi Med

                     = ;   Not to repeat my position, but I'll do it anyhow
                     = ;   :-) As NSH is
                     = ;   *NOT* a transport, dealing with fragmentation is
                     = ;   left to the
                     = ;   Transport used.

                     = ;   The model I use for NSH, is basically similar to
                     = ;   VXLAN . It is an
                     = ;   overly.

                     = ;   Thx

                     = ;   Uri ("Oo-Ree") C: 949-378-7568 <tel:949-378-7568>


                     = ;   -----Original Message----- From: sfc
                     = ;   [mailto:= sfc-bounces@ietf.org
                     = ;   <mailto:sfc-bounces@ietf.org>]
                     = ;   On Behalf Of mohamed.boucadair@orange.com
                     = ;   <mailto:mohamed.boucadair@orange.com> Sent:
                     = ;   Monday, April 25,
                     = ;   2016 7:18 AM To: Joel M. Halpern
                     = ;   <jmh@j= oelhalpern.com <mailto:jmh@joelhalpern.com>>;
                     = ;   sfc@ietf.org= <mailto:sfc@ietf.org<= /a>>
                     = ;   Subject: Re: [sfc] WG last call for
                     = ;   draft-ietf-sfc-nsh-04.txt

                     = ;   Hi Joel,

                     = ;   Please see inline.

                     = ;   Cheers, Med

                     = ;       -----Message d'origine----- De : Joel M. Halpern
                     = ;       [mailto:jmh@joelhalpern.com
                     = ;       <mailto:jmh@joelhalpern.com>] Envoy=E9 : lundi
                     = ;       25 avril 2016 15:48 =C0
                     = ;       : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
                     = ;       <mailto:sfc@ietf.org> Objet : Re: [sfc] WG
                     = ;       last call for draft-ietf-sfc-nsh-04.txt

                     = ;       If I am understanding you correctly Med, you
                     = ;       are asking that the
                     = ;       NSH draft specify how service chaining
                     = ;       should cope with packets
                     = ;       that have been fragmented?


                     = ;   [Med] To be accurate, I'm asking to assess
                     = ;   whether there are
                     = ;   implications. If there are, then the draft
                     = ;   should be updated
                     = ;   accordingly.

                     = ;       NSH, and the SFF functionality, does not care.


                     = ;   [Med] I'm not that sure. Some typical
                     = ;   implications are listed
                     = ;   below:

                     = ;   * SFF: If the NSH header is present only in the
                     = ;   a fragment but SFF
                     = ;   didn't maintained a state, subsequent fragments
                     = ;   won't be
                     = ;   appropriately processed. * SFC-aware function:
                     = ;   if prepending a
                     = ;   context information depends on the full packet,
                     = ;   not only a
                     = ;   fragment.

                     = ;   It just does its job.

                     = ;   [Med] which may be disturbed in some situations
                     = ;   as listed in the
                     = ;   examples above.

                     = ;       Ingress and intermediate classifiers may
                     = ;       cope with fragments in
                     = ;       any number of ways.

                     = ;   Specifying such is clearly out of scope for this
                     = ;   draft.

                     = ;   [Med] The purpose is not to specify the internal
                     = ;   implementation
                     = ;   details but the external behavior of the
                     = ;   classifier function when
                     = ;   it comes to handle fragments. That behavior may
                     = ;   have an incidence
                     = ;   on SFF, in particular. The purpose is not to
                     = ;   recommend the maximum
                     = ;   resources to be dedicated to out of order
                     = ;   fragments nor the
                     = ;   timeout to cache those; these considerations are
                     = ;   of course out of
                     = ;   scope. Nevertheless, an implementation should
                     = ;   offer a configurable
                     = ;   parameter so that an operator tweak those
                     = ;   according to its
                     = ;   context.

                     = ;       I suppose one could write an informational
                     = ;       draft on possible ways
                     = ;       of coping.  The IETF has not usually
                     = ;       published such.
                     = ;       Service functions have to cope with
                     = ;       fragmented packets just as
                     = ;       they had to before the advent of NSH, so
                     = ;       describing that is
                     = ;       clearly not needed here.


                     = ;   [Med] The advent of NSH has the following
                     = ;   implications: * it
                     = ;   exacerbates fragmentation. Handing over this
                     = ;   issue to the
                     = ;   transport layer may lead to interoperability
                     = ;   issues. * the
                     = ;   chaining may not be efficient if fragments are
                     = ;   inappropriately
                     = ;   handled.

                     = ;   Introducing NSH should not degrade the overall
                     = ;   service compared to
                     = ;   legacy service deployment schemes.


                     = ;       Yours, Joel

                     = ;       On 4/25/16 3:00 AM,
                     = ;       mohamed.boucadair@orange.com
                     = ;       <mailto:mohamed.boucadair@orange.com> wrote:

                     = ;           Re-,

                     = ;           I hear you, but my comment is that we<= br>                      = ;           need, as a WG, to decide
                     = ;           what to

                     = ;       put in the draft. FWIW, I'm discussing two
                     = ;       fragmentation
                     = ;       issues:


                     = ;           (1) Fragmentation that is caused by                      = ;           prepending an SFC header.
                     = ;           (2) Handling fragments at the ingress = of
                     = ;           an SFC-enabled domain.

                     = ;           Increasing the MTU is for sure a
                     = ;           recommendation is to be
                     = ;           explicitly

                     = ;       called out in the text (see my first message).


                     = ;           There are other issues that need to be=
                     = ;           discussed, e.g., how to
                     = ;           deal with

                     = ;       fragments in SFFs/Classifiers?


                     = ;           It is also "prudent" to chec= k that no
                     = ;           issues will be experienced
                     = ;           in SFF

                     = ;       to handle fragments. If an SFC header is
                     = ;       prepended for all
                     = ;       fragments, I'm not sure there

                     = ;           is any particular issue at the SFF
                     = ;           level, except if
                     = ;           stripping/adding

                     = ;       context TLVs depends on the full packet (not
                     = ;       just fragment). It
                     = ;       is warranted to consider a little bit this
                     = ;       point before declaring
                     = ;       there is no issue.


                     = ;           For point (1), declaring fragmentation=
                     = ;           out of scope would be
                     = ;           meant that

                     = ;       an implementation must be prepared to
                     = ;       receive fragments with or
                     = ;       without NSH header as this is a decision
                     = ;       that is left to the
                     = ;       transport encapsulation. This is a
                     = ;       requirement per se!


                     = ;           I won't reiterate all the comments I                      = ;           have about the current
                     = ;           wording of

                     = ;       this section.


                     = ;           Cheers, Med

                     = ;               -----Message d'origine--= --- De :
                     = ;               Elzur, Uri
                     = ;               [mailto:uri.elzur@intel.com
                     = ;               <mailto:uri.elzur@intel.com>] En= voy=E9
                     = ;               : lundi 25 avril 2016                      = ;               08:30 =C0 : BOUCADAIR Mo= hamed IMT/OLN;
                     = ;               Thomas Narten;
                     = ;               sfc@ietf.org <mailto:sfc@ietf.org>
                     = ;               Objet : RE: [sfc] WG las= t call for
                     = ;               draft-ietf-sfc-nsh-04.tx= t

                     = ;               Hi Med

                     = ;               My point is that Fragmen= tation is
                     = ;               yet another transport re= lated
                     = ;               issue

                     = ;       that

                     = ;               is beyond the scope of N= SH and
                     = ;               beyond the charter of th= e WG, so
                     = ;               it

                     = ;       doesn't

                     = ;               really belong in the dra= ft. We are
                     = ;               providing an advice as                      = ;               extending the size of th= e packet may
                     = ;               lead to fragmentation, b= ut
                     = ;               as you check RFC 7348 Vx= LAN, which
                     = ;               my create the same issue= ,
                     = ;               you'll find it doesn't e= ven

                     = ;       relate

                     = ;               to it.

                     = ;               Thx

                     = ;               Uri ("Oo-Ree")= C: 949-378-7568
                     = ;               <tel:949-378-7568&= gt;


                     = ;               -----Original Message---= -- From: sfc
                     = ;               [mailto:sfc-bounces@ietf.org
                     = ;               <mailto:sfc-bounces@ietf.org>] = On
                     = ;               Behalf Of
                     = ;               mohamed.boucadair@orange.com
                     = ;               <mailto:mohamed.boucadair@oran= ge.com> Sent:
                     = ;               Sunday, April 24, 2016                      = ;               10:32 PM To: Elzur, Uri<= br>                      = ;               <uri.elzur@intel.com
                     = ;               <mailto:uri.elzur@intel.com>>= ;
                     = ;               Thomas Narten

                     = ;       <narten@us.ibm.com <mailto:narten@us.ibm.com>>;

                     = ;               sfc@ietf.org <mailto:sfc@ietf.org>
                     = ;               Subject: Re: [sfc] WG la= st call for
                     = ;               draft-ietf-sfc-nsh-04.tx= t

                     = ;               Hi Uri,

                     = ;               That's another option th= at needs to
                     = ;               be discussed/investigate= d.
                     = ;               I'm

                     = ;       afraid

                     = ;               this is not the rational= e adopted in
                     = ;               -04 since it includes so= me
                     = ;               text

                     = ;       that

                     = ;               is far to be sufficient = to ensure
                     = ;               interoperable
                     = ;               implementations.

                     = ;               BTW, saying that nsh doe= s not need
                     = ;               to deal with fragmentati= on
                     = ;               because

                     = ;       it

                     = ;               is transport-independent= is not IMHO
                     = ;               a good strategy to adopt=
                     = ;               here

                     = ;       because

                     = ;               it opens the door for in= teroperable
                     = ;               issues, it may lead to                      = ;               sub-optimal implementati= ons if the
                     = ;               sfc information is prese= nt
                     = ;               only in one

                     = ;       fragments,

                     = ;               etc.

                     = ;               My comments are related = to the
                     = ;               current text in the -04.=
                     = ;               This text needs

                     = ;       to

                     = ;               be fixed somehow.

                     = ;               Cheers, Med

                     = ;                   -----Messa= ge d'origine----- De :
                     = ;                   Elzur, Uri=
                     = ;                   [mailto:uri.elzur@intel.com<= /a>
                     = ;                   <mailto= :uri.elzur@intel.c= om>]
                     = ;                   Envoy=E9 := dimanche 24 avril
                     = ;                   2016 17:36= =C0 : BOUCADAIR Mohamed
                     = ;                   IMT/OLN; T= homas Narten;
                     = ;                   sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org> Obj= et :
                     = ;                   RE: [sfc] = WG last call for
                     = ;                   draft-ietf= -sfc-nsh-04.txt

                     = ;                   Hi Med

                     = ;                   I see no n= eed to specify the
                     = ;                   exact beha= vior as NSH is
                     = ;                   transport = independent i.e. like
                     = ;                   NSH intera= ction with any other
                     = ;                   Transport = eh issue of
                     = ;                   Fragmentat= ion is to be dealt in
                     = ;                   a way
                     = ;                   that match= es the mechanisms
                     = ;                   supported = by the Transport used
                     = ;                   and do not= belong in the NSH draft

                     = ;                   Thx

                     = ;                   Uri ("= ;Oo-Ree") C: 949-378-7568
                     = ;                   <tel:949= -378-7568>


                     = ;                   -----Origi= nal Message----- From: sfc
                     = ;                   [mailto:sfc-bounces@ietf.or= g
                     = ;                   <mailto= :sfc-bounces@ietf= .org>]
                     = ;                   On Behalf = Of
                     = ;                   mohamed.boucadair@orange.com
                     = ;                   <mailto= :mohamed.= boucadair@orange.com>
                     = ;                   Sent: Thur= sday, April 14,
                     = ;                   2016 12:43= AM To: Thomas Narten
                     = ;                   <narten@us.ibm.com
                     = ;                   <mailto= :narten@us.ibm.com>>;
                     = ;                   sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org> Sub= ject:
                     = ;                   Re: [sfc] = WG last call for
                     = ;                   draft-ietf= -sfc-nsh-04.txt

                     = ;                   R-,

                     = ;                   In additio= n to other pending
                     = ;                   issues rai= sed for this draft, I
                     = ;                   would like= to raise this
                     = ;                   additional= one about Section 6.

                     = ;                   =3D=3D 6.&= nbsp; Fragmentation Considerations

                     = ;                   NSH and th= e associated transport
                     = ;                   header are= "added" to the
                     = ;                   encapsulat= ed packet/frame.  This
                     = ;                   additional= information
                     = ;                   increases<= br>
                     = ;       the

                     = ;                   size of th= e packet.  In order
                     = ;                   the ensure= proper forwarding of
                     = ;                   NSH data, = several options for
                     = ;                   handling f= ragmentation and
                     = ;                   re-assembl= y exist:

                     = ;                   1.  J= umbo Frames, when
                     = ;                   supported,= enable the transport
                     = ;                   of NSH
                     = ;                   and associ= ated transport packets
                     = ;                   without re= quiring
                     = ;                   fragmentat= ion.

                     = ;                   2.  P= ath MTU Discovery
                     = ;                   [RFC1191]&= quot;describes a technique for
                     = ;                   dynamicall= y discovering the
                     = ;                   maximum tr= ansmission unit (MTU) of

                     = ;       an

                     = ;                   arbitrary = internet path" and can
                     = ;                   be utilize= d to ensure the

                     = ;   the

                     = ;                   required p= acket size is used.

                     = ;                   3.  [= RFC6830] describes two
                     = ;                   schemes fo= r fragmentation and
                     = ;                   re-

                     = ;       assembly

                     = ;                   in section= 5.4. =3D=3D

                     = ;                   * The text= is weak for a
                     = ;                   Standard t= rack document that is
                     = ;                   intended t= o solve the problem in
                     = ;                   https://tools.ietf.org/html/rfc7498#section-

                     = ;   2.12.

                     = ;                   There shou= ld be a clear behavior
                     = ;                   to be foll= owed by an

                     = ;   implementation.

                     = ;                   Further, I= would avoid the use
                     = ;                   of words s= uch as "can".

                     = ;                   * The text= covers only
                     = ;                   fragmentat= ion when it is induced
                     = ;                   by SFC
                     = ;                   operations= , it does not discuss
                     = ;                   the treatm= ent of a fragment
                     = ;                   when recei= ved in an SFC domain.
                     = ;                   IMHO, the = draft should also
                     = ;                   specify th= e behavior of the
                     = ;                   Classifier= with regards to
                     = ;                   fragments = for the sake of proper
                     = ;                   SFC operat= ion. Applying
                     = ;                   classifica= tion policies may
                     = ;                   require th= e

                     = ;               full packet, not only a = fragment.

                     = ;                   In particu= lar, dedicated
                     = ;                   resources = should dedicated for
                     = ;                   handling o= ut of order fragments.
                     = ;                   Of course,= it is out of scope
                     = ;                   of this do= cument to describe how
                     = ;                   SFs handle= fragments.

                     = ;                   * If an SF= C header is prepended
                     = ;                   for all fr= agments, I'm not
                     = ;                   sure there= is any particular
                     = ;                   issue at t= he SFF level...except
                     = ;                   if strippi= ng/adding context TLVs
                     = ;                   depends on= the full packet
                     = ;                   (not just = fragment). It is
                     = ;                   warranted = to consider a little bit
                     = ;                   this point= before declaring there

                     = ;       is

                     = ;               no issue.


                     = ;                   * The text= states "several
                     = ;                   options&qu= ot;. This may be interpreted
                     = ;                   as if impl= ementing one of them
                     = ;                   is suffici= ent...which is not
                     = ;                   true. The = first two points
                     = ;                   contribute= to minimize the
                     = ;                   fragmentat= ion risk, but
                     = ;                   fragmentat= ion may still be
                     = ;                   experience= d
                     = ;                   (e.g., oth= er shims are prepended
                     = ;                   by other n= odes for some other
                     = ;                   purposes, = nested nsh, etc.)

                     = ;                   * The firs= t two points have
                     = ;                   nothing to= do with reassembly.

                     = ;                   * The supp= ort of jumbo frames by
                     = ;                   a router/d= evice does not mean
                     = ;                   that it ca= n make use of it.
                     = ;                   Appropriat= e MTU configuration
                     = ;                   should be = undertaken in a
                     = ;                   consistent= manner within an SFC
                     = ;                   domain. Th= e text should be
                     = ;                   updated to= make it is about
                     = ;                   (consisten= t) MTU

                     = ;   configuration.


                     = ;                   * BTW, sho= uldn't the text be
                     = ;                   reworded t= o recommended to
                     = ;                   increase t= he MTU of **all
                     = ;                   nodes** of= an SFC-enabled domain by
                     = ;                   at least t= he length of SFC
                     = ;                   header = 3; transport header?

                     = ;                   * Bullet 2= , how PMTU discovery
                     = ;                   is actuall= y used in this
                     = ;                   context? D= o you assume that all
                     = ;                   SFC-aware = nodes will issue
                     = ;                   such messa= ges towards other
                     = ;                   SFC-aware = node, arbitrary
                     = ;                   destinatio= n, else?

                     = ;                   * Bullet 2= , I would drop
                     = ;                   "desc= ribes a technique for
                     = ;                   dynamicall= y discovering the
                     = ;                   maximum tr= ansmission unit
                     = ;                   (MTU) of a= n arbitrary internet
                     = ;                   path"= .

                     = ;                   * Bullet 2= , s/ the the/the.

                     = ;                   * The refe= rence to the LISP
                     = ;                   specificat= ion raises two concerns
                     = ;                   and one co= mment:

                     = ;                   (1) I don'= t think it is a good
                     = ;                   approach t= hat fragments induced
                     = ;                   by the net= work are passed to
                     = ;                   their ulti= mate destinations as
                     = ;                   such

                     = ;   (stateless).

                     = ;                   IMO, reass= embly should be done
                     = ;                   within the= SFC domain
                     = ;                   (responsib= le for fragmentation)
                     = ;                   not passed= away. (2) Does the
                     = ;                   stateful m= ode require all SFC
                     = ;                   data plane= elements maintain a
                     = ;                   full list = of MTU for the any
                     = ;                   SFF/SF ins= tance of the SFC

                     = ;               domain?


                     = ;                   The curren= t text suggests that
                     = ;                   [RFC6830] = should be listed as
                     = ;                   normative = reference (not an
                     = ;                   informativ= e one). I would
                     = ;                   personally= favor removing the
                     = ;                   reference = to LISP (as it is an
                     = ;                   Experiment= al RFC).

                     = ;                   * The secu= rity section of the
                     = ;                   draft may = be augmented with
                     = ;                   informatio= nal
                     = ;                   fragmentat= ion-related pointers to:
                     = ;                   e.g., RFC1= 858 (Security
                     = ;                   Considerat= ions for IP Fragment
                     = ;                   Filtering)= , RFC3128 (Protection
                     = ;                   Against a = Variant of the Tiny
                     = ;                   Fragment A= ttack), and RFC 4963
                     = ;                   (IPv4 Reas= sembly Errors at High
                     = ;                   Data Rates= ).

                     = ;                   Cheers, Me= d

                     = ;                     &nb= sp; -----Message d'origine-----
                     = ;                     &nb= sp; De : sfc
                     = ;                     &nb= sp; [mailto:sfc-b= ounces@ietf.org
                     = ;                     &nb= sp; <mailto:sf= c-bounces@ietf.org>]
                     = ;                     &nb= sp; De la part de
                     = ;                     &nb= sp; mohamed.boucadair@orange.com
                     = ;                     &nb= sp; <mailto:mohamed.boucadair@orange.com>
                     = ;                     &nb= sp; Envoy=E9 : lundi 11 avril
                     = ;                     &nb= sp; 2016 13:14 =C0 : Thomas
                     = ;                     &nb= sp; Narten; sfc@ietf.org
                     = ;                     &nb= sp; <mailto:sfc@ietf.o= rg> Objet
                     = ;                     &nb= sp; : Re:
                     = ;                     &nb= sp; [sfc] WG last call for
                     = ;                     &nb= sp; draft-ietf-sfc-nsh-04.txt

                     = ;                     &nb= sp; Dear Thomas, all,

                     = ;                     &nb= sp; As I mentioned during the
                     = ;                     &nb= sp; meeting, there are several
                     = ;                     &nb= sp; issues
                     = ;                     &nb= sp; that are not covered in the
                     = ;                     &nb= sp; last version of the draft. I
                     = ;                     &nb= sp; already provided examples of
                     = ;                     &nb= sp; the issues offline as requested
                     = ;                     &nb= sp; by Martin.

                     = ;                     &nb= sp; Cheers, Med

                     = ;                     &nb= sp;     -----Message
                     = ;                     &nb= sp;     d'origine----- De : sfc
                     = ;                     &nb= sp;     [mailto:sfc-bounces@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc-bounces@ietf.org>]
                     = ;                     &nb= sp;     De la part de Thomas Narten
                     = ;                     &nb= sp;     Envoy=E9 : jeudi 31 mars
                     = ;                     &nb= sp;     2016 04:48 =C0 :
                     = ;                     &nb= sp;     sfc@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc@ietf.org>
                     = ;                     &nb= sp;     Objet : [sfc] WG last
                     = ;                     &nb= sp;     call for
                     = ;                     &nb= sp;     draft-ietf-sfc-nsh-04.txt

                     = ;                     &nb= sp;     Dear WG:

                     = ;                     &nb= sp;     This note begins a WG
                     = ;                     &nb= sp;     last call on
                     = ;                     &nb= sp;     draft-ietf-sfc-nsh-04.txt
                     = ;                     &nb= sp;     (https://datatracker.ietf.org/= doc/draft-ietf-sfc-nsh/).



            The editors of the NSH document h= ave indicated that they have

                     = ;                     &nb= sp;     addressed all known
                     = ;                     &nb= sp;     comments and that there
                     = ;                     &nb= sp;     are no open
                     = ;                     &nb= sp;     issues with the current
                     = ;                     &nb= sp;     version of the document.

                     = ;                     &nb= sp;     Substantive comments to
                     = ;                     &nb= sp;     the list please,
                     = ;                     &nb= sp;     editorial comments
                     = ;                     &nb= sp;     can go directly to the
                     = ;                     &nb= sp;     document editors.

                     = ;                     &nb= sp;     We'll also get a brief
                     = ;                     &nb= sp;     update from the editors
                     = ;                     &nb= sp;     at next
                     = ;                     &nb= sp;     week's meeting. If there
                     = ;                     &nb= sp;     are any remaining issues
                     = ;                     &nb= sp;     with the
                     = ;                     &nb= sp;     document, raising them
                     = ;                     &nb= sp;     before the meeting would be
                     = ;                     &nb= sp;     especially helpful.

                     = ;                     &nb= sp;     For the chairs, Thomas

                     = ;                     &nb= sp;     _______________________________________________
                     = ;                     &nb= sp;     sfc mailing
                     = ;                     &nb= sp;     list sfc@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc@ietf.org>
                     = ;                     &nb= sp;     https://www.ietf.org/mailman/listinfo/sfc


                     = ;                     &nb= sp; _______________________________________________
                     = ;                     &nb= sp; sfc mailing
                     = ;                     &nb= sp; list sfc@ietf.org
                     = ;                     &nb= sp; <mailto:sfc@ietf.o= rg>
                     = ;                     &nb= sp; https://www.ietf.org/mailman/listinfo/sfc


                     = ;                   __________= _____________________________________
                     = ;                   sfc mailin= g
                     = ;                   list sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org>
                     = ;                   https://www.ietf.org/mailman/listinfo/sfc


                     = ;               ________________________= _______________________
                     = ;               sfc mailing

--_000_D34786324C66Ajguicharciscocom_-- From nobody Thu Apr 28 06:57: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 0B71612D78E for ; Thu, 28 Apr 2016 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 Q4nSPKFuGWK1 for ; Thu, 28 Apr 2016 06:57:40 -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 F0BED12D790 for ; Thu, 28 Apr 2016 06:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55291; q=dns/txt; s=iport; t=1461851848; x=1463061448; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=W3WLAOyx2zgkyDQAJBBncYg1hi3LlAlR/78krWaukxo=; b=nETC+cWl14hA2wXzNWvLwVuAKIwCHUd0N/KBtU0CEl2dRxu/W4W1SVKr McvgDOQ4HaGr4T2Jzf7wy3T7zrf3FYKPnoyWv3+oEvBXUVIqvVK/Krpsr H+uoFZGIO7dTTQBmm6OodLCiyjbEHGQSqn7kAkcgUrp7IW/NO0OG5DQVh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAgCUFSJX/4QNJK1egmxMU30GrhGLX?= =?us-ascii?q?gENgXIEFwEKhW0CgSc4FAEBAQEBAQFlJ4RBAQEBBAEBASQGQQQXAgEIEQECAQI?= =?us-ascii?q?WCwEGByEGCxQDBggCBAESiBUDEg6+Sg2ESwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?REEhiGES4JBgV8BATsWCYUXBZMME4RAMQGFe4YlgXaBZ4RNgyl7hDmHUYdeAR4?= =?us-ascii?q?BAUKDa2wBhjI2fwEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,546,1454976000"; d="scan'208,217"; a="98902571" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 13:57:27 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3SDvRCx014103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 13:57:27 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.1104.5; Thu, 28 Apr 2016 08:57:26 -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.1104.009; Thu, 28 Apr 2016 08:57:26 -0500 From: "Jim Guichard (jguichar)" To: "mohamed.boucadair@orange.com" , "Martin Stiemerling" , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1hgqCe3Pkr6EKnc83IMsxhI5+d714AgAD0McCAAJiAgA== Date: Thu, 28 Apr 2016 13:57:26 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <787AE7BB302AE849A7480A190F8B933008D6100C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6100C@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/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D3478CFF4C690jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 13:57:44 -0000 --_000_D3478CFF4C690jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Med, Inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Thursday, April 28, 2016 at 2:58 AM To: Jim Guichard >, Martin St= iemerling >, "sfc@ietf.org" > Subject: RE: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Jim, Thank you for the review. Please see inline. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : mercredi 27 avril 2016 16:18 =C0 : Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement =93this document as= sumes the SFC control plane is provided with a set of information that is r= equired for proper SFC operation=94 but then goes on to list bullets that a= re likely to be provided or may be provided. It does not actually provide a= ny information on what is required for proper SFC operation. In the list of= likely information there is no indication of whether this information must= exist in the network prior to bootstrapping the SFC control plane element;= this is true also for the list of may information. Surely we should provid= e guidelines on what must be available before the SFC control plane element= can actually function although it is reasonable to assume that it can boot= strap without any information (albeit it can=92t actually do anything). On = this point I would argue that several of the may elements are actually requ= ired such as SFF, SF, SFC-proxy locators and may exist prior to bootstrappi= ng the SFC control plane element, or may be added later through some contro= l interface. [Med] Fair point. I suggest to make these modifications: (1) OLD: The following information that is likely to be provided to the SFC control plane at bootstrapping includes (non-exhaustive list): NEW: The following information that is RECOMMENDED to be provided to the SFC control plane prior to bootstrapping includes: (2) Remove this bullet from the list and insert it right after the list. o Optionally, (traffic/CPU/memory) load balancing objectives at the SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis. Jim> that seems fine. Minor point -> typo in bullet point 6 =96 SFP proxy should read SFC proxy [Med] Fixed. Thanks. * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence =93various transport encapsulation schemes and/or va= riations of SFC header implementations may be supported=94 actually mean ? = Are we referring to the fact that the SFC header may carry type-1 or type-2= metadata or something else ? Note that there is only one SFC header implem= entation based on the WG charter so if we are referring to different SFC fo= rmats (meaning metadata) then please make this clear in the text, and if no= t, please remove this sentence. [Med] That sentence is related to the rich set of transport encapsulation s= chemes, but also that nsh header includes a version number. The current nsh spec does not specify how nodes with distinct nsh versions = are supposed to behave. Also, we don=92t know in 2016 (because there is no = nsh v2) whether v0 and v2 will be backward compatible. If these versions ar= e not backward compatible, this will lead to failures when two adjacent ele= ments in a service chain do not support the same version. The cp is key to ensure coherent setup of an SFC-domain to avoid failures t= hat are due to unsupported version and/or unsupported transport encapsulati= on. Jim> maybe just replace =93variations=94 with =93versions=94 so that it is = clear what is being talked about ? * Section 3.1 Reference Architecture Second bullet point =93mapping between service function chains and SFPs=94 = - this is a general comment for the entire document but applies here also. = There is no mention of mapping SFPs -> RSPs =96 in fact RSP is mentioned on= ly once in the entire document. The architecture is explicit in that the SF= P when rendered into the network is an RSP and therefore the SFC control pl= ane element needs to have information on currently deployed RSPs. [Med] I agree RSP is not explicitly mentioned in Section 3.1, but the point= you raised is what is under this bullet: o Determine a forwarding path in the context of a centralized deployment model (see Section 3.2). Section 3.2 states the following: For some traffic engineering proposes, the SFP may be constrained by the control plane; as such, some SFPs can be fully specified (i.e., list all the SFF/SFs that need to be solicited) or partially specified (e.g., exclude some nodes, explicitly select which instance of a given SF needs to be invoked, etc.). Do you think a change is still needed to the text? Jim> no I am fine with the text as it stands. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF=92s may require that SFC information be communicated to th= eir management systems that will be responsible for communicating directly = with their respective SF=92s. [Med] Good point. I suggest this change in Section 3.3.3 that I believe is = sufficient to take into account this comment: OLD: The SFC control plane uses this interface to interact with SFC-aware SFs. NEW: The SFC control plane uses this interface to interact with SFC-aware SFs. This interaction may be direct or via dedicated SF management syste= ms. Jim> that looks good. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence =93The control plane may instruct the classifier about the ini= tial values of the Service Index (SI)=94 should be changed to say MUST as o= therwise if a classifier chooses whatever value it wants then that may not = align with what is programmed into the SFFs by the SFC Control Plane elemen= t. [Med] Makes sense. I made the change in my local copy. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. [Med] FWIW, there was a call about this section (https://www.ietf.org/mail-= archive/web/sfc/current/msg03756.html). This section does not recommend nor= exclude source routes. Jim> the title of the section is =93Encoding the exact SFF/SF sequence in d= ata packets=94 which is pretty clear what that means. The only encoding of = the SFF/SF sequence supported by the SFC encapsulation (taking type-2 metad= ata out of the equation) is the SPI + SI (which is actually a reference to = the placement within the service path rather than an encoding directly of a= service sequence in the data plane) hence again I think this section shoul= d be removed from the document. Jim * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id=92s whereas the text mentions only SFP-id= #1. Is this simply a typo or are you trying to convey something else ? Further you state that =93the steering policies to a SFF node for service f= unction chain depends on if the packet comes from previous SFF or comes fro= m a specific SF i.e., the SFP Forwarding Table entries have to be ingress p= ort specific=94 - this is an inaccurate statement as the combination of th= e SFP-id and service-index determines the forwarding behavior (as specified= in section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence shoul= d be removed from the text. [Med] I will defer to Linda/Andrew to clarify this part of that text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_D3478CFF4C690jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Med,

Inline .. 

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Thursday, April 28, 2016 at 2= :58 AM
To: Jim Guichard <jguichar@cisco.com>, Martin Stiemerling <= mls.ietf@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
Subject: RE: [sfc] WGLC for draft-i= etf-sfc-control-plane-04.txt

Hi Jim,

 

Thank you for the review.

 

Please see inline.

 

Cheers,

Med

 

De : sfc [m= ailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mercredi 27 avril 2016 16:18
=C0 : Martin Stiemerling; sfc@i= etf.org
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt<= o:p>

 

Hi Martin & WG:

 

A few comments that I would like to see addr= essed in the document before it can move forward to the next step.

  • Sectio= n 2.2 SFC Control Plane Bootstrapping.

This section is too wishy washy. It makes th= e statement =93this document assumes the SFC control plane is provided with= a set of information that is required for proper SFC operation=94 but then goes on to list bullet= s that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can=92t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

[Med] Fair point. I suggest to = make these modifications:

 

(1)

 

OLD:

   The following information= that is likely to be provided to the SFC

   control plane at bootstrapping= includes (non-exhaustive list):

 

NEW:

   The following information that is RE=
COMMENDED to be provided to the SFC
   control plane prior to bootstrapping=
 includes:

 

(2)

 

Remove this bullet from the lis= t and insert it right after the list.

 

   o  Optionally, (traffic/CPU/mem=
ory) load balancing objectives at the
      SFC level or on a =
per node (e.g., per-SF/SFF/SFP proxy) basis.

 

Jim> that seems fine.

Minor point -> typo in bul= let point 6 =96 SFP proxy should read SFC proxy

[Med] Fixed. Thanks.

  • Sectio= n 2.3 Coherent Setup of an SFC-enabled Domain

What does the sentence =93various transport = encapsulation schemes and/or variations of SFC header implementations may b= e supported=94 actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or som= ething else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

 

[M= ed] That sentence is related to the rich set of transport encapsulation sch= emes, but also that nsh header includes a version number.

 

Th= e current nsh spec does not specify how nodes with distinct nsh versions ar= e supposed to behave. Also, we don=92t know in 2016 (because there is no nsh v2) whether v0 and v2 will be backward compatible= . If these versions are not backward compatible, this will lead to failures= when two adjacent elements in a service chain do not support the same vers= ion.

 

Th= e cp is key to ensure coherent setup of an SFC-domain to avoid failures tha= t are due to unsupported version and/or unsupported transport encapsulation.

Jim> maybe just replace =93variations=94 with =93versions=94 so tha= t it is clear what is being talked about ?

  • Sectio= n 3.1 Reference Architecture

Second bullet point =93mapping between servi= ce function chains and SFPs=94 - this is a general comment for the entire d= ocument but applies here also. There is no mention of mapping SFPs -> RSPs =96 in fact RSP is mentioned only on= ce in the entire document. The architecture is explicit in that the SFP whe= n rendered into the network is an RSP and therefore the SFC control plane e= lement needs to have information on currently deployed RSPs.

 

[Med] I agree RSP is not explic= itly mentioned in Section 3.1, but the point you raised is what is under th= is bullet:

 

   o  Determine a forwarding path =
in the context of a centralized
      deployment =
model (see Section 3.2).

 

Section 3.2 states the followin= g:

 

      For some traffic e=
ngineering proposes, the SFP may be constrained
      by the control pla=
ne; as such, some SFPs can be fully specified
      (i.e., list all th=
e SFF/SFs that need to be solicited) or
      partially specifie=
d (e.g., exclude some nodes, explicitly select
      which instance of =
a given SF needs to be invoked, etc.).
 
Do you think a change is still needed to the text=
?

Jim> no I am fine with the text as it stands.

 

Additionally there is no inte= rface specified for communication between the SFC Control Plane Element and= SF management systems. This is an important aspect as many SF=92s may require that = SFC information be communicated to their management systems that will be re= sponsible for communicating directly with their respective SF=92s. 

 

[Med] Good point. I suggest thi= s change in Section 3.3.3 that I believe is sufficient to take into account= this comment:

 

OLD:

 

   The SFC control plane uses this inte=
rface to interact with SFC-aware
   SFs.

 

NEW:

 

   The SFC control plane uses this inte=
rface to interact with SFC-aware
   SFs. This interaction may be direct =
or via dedicated SF management systems.

Jim> that looks good.
  • Sectio= n 3.1.1. C1: Interface between SFC Control Plane & SFC Classifier<= /o:p>

The sentence =93The control plane may instru= ct the classifier about the initial values of the Service Index (SI)=94 sho= uld be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. 

 

[Med] Makes sense. I made the c= hange in my local copy.

  • Sectio= n 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets

This section does not actually provide any m= eaning or indication of relationship with the SFC Control Plane element. Fu= rthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire= section should be removed from the document.

 

[Med] FWIW, there was a call ab= out this section (https://www.ietf.org/mail-archive/web/sfc/current/msg037= 56.html). This section does not recommend nor exclude source routes.

Jim> the title of the section is =93Encoding the exact SFF/SF seque= nce in data packets=94 which is pretty clear what that means. The only encoding of the SFF/SF sequence supported by the SFC encapsulat= ion (taking type-2 metadata out of the equation) is the SPI + SI (which= is actually a reference to the placement within the service path rather th= an an encoding directly of a service sequence in the data plane) hence again I think this section should be rem= oved from the document. 

Jim

  • Sectio= n 4.10.5. Fully Controlled SFF/SF Sequence for a SFP
    • =

Figure 2 lists 3 different SFP-id=92s wherea= s the text mentions only SFP-id #1. Is this simply a typo or are you trying= to convey something else ?

 

Further you state that =93the steering polic= ies to a SFF node for service function chain depends on if the packet comes= from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= =94 -  this is an inaccurate statement as the combination of the SFP-i= d and service-index determines the forwarding behavior (as specified in sec= tion 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

 

[Med] I will defer to Linda/And= rew to clarify this part of that text.    =

 

Jim

 

 

 

On 4/27/16, 12:29 AM, "sfc on behalf of= Martin Stiemerling" <sfc-b= ounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,

 

This is the start of the Working Group Last = Call (WGLC) for

 

draft-ietf-sfc-control-plane-04.txt

 

The WGLC lasts for 2 weeks and will end May = 11th at 10 pm PDT.

 

Please send your comments and reviews to the sfc@ietf.org list.

 

Regards,

 

   Martin (SFC co-chair)

 

____________________________________________= ___

sfc mailing list

 

 --_000_D3478CFF4C690jguicharciscocom_-- From nobody Thu Apr 28 07:11: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 CAFDA12D7A2 for ; Thu, 28 Apr 2016 07:11:23 -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 y1i1OLeDaHFO for ; Thu, 28 Apr 2016 07:11:22 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 657FD12D7A4 for ; Thu, 28 Apr 2016 07:11:22 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x19so84549659oix.2 for ; Thu, 28 Apr 2016 07:11:22 -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=Tx/x2SRtpmtzw+hiUFwig8kSpOrmr+h1ynKoKzs0qx4=; b=FmM1UHsN7X5ppr1ZhXobNs86F/09OKMYqE6H8dJv0kebVrm8dMwP+tmuzoLCqDr0tv 5EtjQIbgVUEGnb/x4iiSGG0uZchCwiobZnuJG8t9ethT8Z1UAwHKd6Wi75xubLif2TJ2 jtC6qNY353XzwrLRDnkwqGGMLu6qRKdPUys0jC9wC4fyWujrDJtKBeUzH3wGJA57D7kT qEIyjl/vQhTgspKYFCgOBLYIyC2fLHsGaFxAzM4S8Hk1qtDhLiTzgMpmzVUXuLGMLiLh RnVjdxZh/Ra9M603irdsEHHSSFAbS5mDGoOpn57f2QuOnTkh3pw6PqFf+AgTjLXOUap7 r6NA== 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=Tx/x2SRtpmtzw+hiUFwig8kSpOrmr+h1ynKoKzs0qx4=; b=dmJtx2RWvXG6jSUmVf+mgg/LfVERTsQzZoaQvMaux1SO3v1Qrr11g31yp6IVpZHa9Z DgiWr6rq8r3BonVzU6ayFj6fmKy57xKNsLT76HFQ5XCYhKNyENwC6KeCDA3RFfHqbQ4p hjzv4vIoFGADrOrX4qqQ+tJOnQ+BcaVIcWVcVl0gIXgFxYpgEwrfsN4VhLiUqWtTqx4u DGyDimWU5JyufqwL8rv+0dM/DlEZMfwkxBoptB/jYgbjQNjILV+YZFlxYe9kmYr22YTD vVMerTy5CUkq1NfOPX1nlQoHGMrrppHEEZv7jjN2n1TPIAUmyn1VyJyms1Khuw7tkEEY ACcA== X-Gm-Message-State: AOPr4FWF/+v/VDBBYcg11rPevznBqL+VzJdg3/Nk+HGu+LhCRIsmkgkG7RkrM9bnGiUOUC6QuC95QTHcK/NTqw== X-Received: by 10.202.91.8 with SMTP id p8mr5802664oib.99.1461852681847; Thu, 28 Apr 2016 07:11:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.216.166 with HTTP; Thu, 28 Apr 2016 07:11:00 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6100C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <787AE7BB302AE849A7480A190F8B933008D6100C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Andrew G. Malis" Date: Thu, 28 Apr 2016 10:11:00 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=001a113d3a88d0c74705318c191a Archived-At: Cc: Martin Stiemerling , BOUCADAIR Mohamed IMT/OLN , "sfc@ietf.org" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 14:11:24 -0000 --001a113d3a88d0c74705318c191a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, Regarding your comments on section 4.10.5: > > - Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP > > Figure 2 lists 3 different SFP-id=E2=80=99s whereas the text mentions onl= y SFP-id > #1. Is this simply a typo or are you trying to convey something else ? > Figure 2 is meant as an example of a set of steering policies. You=E2=80=99= re right, it=E2=80=99s confusing to refer to just #1, when we really don=E2=80= =99t need to. I think we can improve the introductory sentence above the figure by just saying: For illustration purposes, an example set of steering policies for an SFF is depicted in Figure 2. > > > Further you state that =E2=80=9Cthe steering policies to a SFF node for s= ervice > function chain depends on if the packet comes from previous SFF or comes > from a specific SF i.e., the SFP Forwarding Table entries have to be > ingress port specific=E2=80=9D - this is an inaccurate statement as the > combination of the SFP-id and service-index determines the forwarding > behavior (as specified in section 3.3 & section 7 of > draft-ietf-sfc-nsh-04). This sentence should be removed from the text. > > > > > I agree, thanks for spotting! Cheers, Andy --001a113d3a88d0c74705318c191a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim,

Regarding your comments on section= 4.10.5:



  • Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP<= /u>

Figure 2 lists 3 different = SFP-id=E2=80=99s whereas the text mentions only SFP-id #1. Is this simply a= typo or are you trying to convey something else ?

<= /div>


Figure 2 i= s meant as an example of a set of steering policies. You=E2=80=99re right, = it=E2=80=99s confusing to refer to just #1, when we really don=E2=80=99t ne= ed to. I think we can improve the introductory sentence above the figure by= just saying:

For illustration purposes, an exampl= e set of steering policies for an SFF is depicted in Figure 2.
= =C2=A0

=C2=A0=

Further you state that =E2= =80=9Cthe steering policies to a SFF node for service function chain depend= s on if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= =E2=80=9D - =C2=A0this is an inaccurate statement as the combination of the= SFP-id and service-index determines the forwarding behavior (as specified = in section 3.3 & section 7 of draft-ietf-sfc-nsh-04). =C2=A0This sentence should be removed from the text.<= /p>

=C2=A0=


=C2=A0I agree, thanks for spotting!

C= heers,
Andy

--001a113d3a88d0c74705318c191a-- From nobody Thu Apr 28 07:52: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 6327C12B05F for ; Thu, 28 Apr 2016 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 CPvTFbX248NZ for ; Thu, 28 Apr 2016 07:52:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C939E12D7BA for ; Thu, 28 Apr 2016 07:45:51 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 253B32649C9; Thu, 28 Apr 2016 16:45:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 008C527C087; Thu, 28 Apr 2016 16:45:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 16:45:49 +0200 From: To: "Jim Guichard (jguichar)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1hgqCe3Pkr6EKnc83IMsxhI5+d714AgAD0McCAAJiAgP//+zUQ Date: Thu, 28 Apr 2016 14:45:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6153F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <787AE7BB302AE849A7480A190F8B933008D6100C@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.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6153FOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.28.135717 Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 14:52:41 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6153FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I made the required change in my local copy to address this comment: Jim> maybe just replace "variations" with "versions" so that it is clear wh= at is being talked about ? The only pending point is about Section 4.10.4. I'm neutral on this point. Cheers, Med De : Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Envoy=E9 : jeudi 28 avril 2016 15:57 =C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Med, Inline .. From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Thursday, April 28, 2016 at 2:58 AM To: Jim Guichard >, Martin St= iemerling >, "sfc@ietf.org" > Subject: RE: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Jim, Thank you for the review. Please see inline. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : mercredi 27 avril 2016 16:18 =C0 : Martin Stiemerling; sfc@ietf.org Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. [Med] Fair point. I suggest to make these modifications: (1) OLD: The following information that is likely to be provided to the SFC control plane at bootstrapping includes (non-exhaustive list): NEW: The following information that is RECOMMENDED to be provided to the SFC control plane prior to bootstrapping includes: (2) Remove this bullet from the list and insert it right after the list. o Optionally, (traffic/CPU/memory) load balancing objectives at the SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis. Jim> that seems fine. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy [Med] Fixed. Thanks. * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. [Med] That sentence is related to the rich set of transport encapsulation s= chemes, but also that nsh header includes a version number. The current nsh spec does not specify how nodes with distinct nsh versions = are supposed to behave. Also, we don't know in 2016 (because there is no ns= h v2) whether v0 and v2 will be backward compatible. If these versions are = not backward compatible, this will lead to failures when two adjacent eleme= nts in a service chain do not support the same version. The cp is key to ensure coherent setup of an SFC-domain to avoid failures t= hat are due to unsupported version and/or unsupported transport encapsulati= on. Jim> maybe just replace "variations" with "versions" so that it is clear wh= at is being talked about ? * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. [Med] I agree RSP is not explicitly mentioned in Section 3.1, but the point= you raised is what is under this bullet: o Determine a forwarding path in the context of a centralized deployment model (see Section 3.2). Section 3.2 states the following: For some traffic engineering proposes, the SFP may be constrained by the control plane; as such, some SFPs can be fully specified (i.e., list all the SFF/SFs that need to be solicited) or partially specified (e.g., exclude some nodes, explicitly select which instance of a given SF needs to be invoked, etc.). Do you think a change is still needed to the text? Jim> no I am fine with the text as it stands. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. [Med] Good point. I suggest this change in Section 3.3.3 that I believe is = sufficient to take into account this comment: OLD: The SFC control plane uses this interface to interact with SFC-aware SFs. NEW: The SFC control plane uses this interface to interact with SFC-aware SFs. This interaction may be direct or via dedicated SF management syste= ms. Jim> that looks good. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. [Med] Makes sense. I made the change in my local copy. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. [Med] FWIW, there was a call about this section (https://www.ietf.org/mail-= archive/web/sfc/current/msg03756.html). This section does not recommend nor= exclude source routes. Jim> the title of the section is "Encoding the exact SFF/SF sequence in dat= a packets" which is pretty clear what that means. The only encoding of the = SFF/SF sequence supported by the SFC encapsulation (taking type-2 metadata = out of the equation) is the SPI + SI (which is actually a reference to the = placement within the service path rather than an encoding directly of a ser= vice sequence in the data plane) hence again I think this section should be= removed from the document. Jim * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. [Med] I will defer to Linda/Andrew to clarify this part of that text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_787AE7BB302AE849A7480A190F8B933008D6153FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I made the required change in m= y local copy to address this comment:

 

Jim> mayb= e just replace “variations” with “versions” so that= it is clear what is being talked about ?

 

The only pending point is about= Section 4.10.4. I’m neutral on this point.

 

Cheers,

Med

 

De : Jim Guichard (jguichar) [mailto:jguichar@cisco.co= m]
Envoy=E9 : jeudi 28 avril 2016 15:57
=C0 : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; sfc@ietf.o= rg
Objet : Re: [sfc] WGLC for draft-ietf-sfc-co= ntrol-plane-04.txt

 

Hi Med,

 

Inline .. <= /span>

 

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Date: Thursday, April 28, 2016 at 2:58 AM
To: Jim Guichard <jguichar@= cisco.com>, Martin Stiemerling <mls.ietf@gmail.com>, "sfc@= ietf.org" <sfc@ietf.org>=
Subject: RE: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Hi Jim,

 =

Thank you for the review.

 =

Please see inline.

 =

Cheers,

Med

 =

De : sfc [mailto:sfc= -bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoy=E9 : mercredi 27 avril 2016 16:18
=C0 : Martin Stiemerling; sfc@i= etf.org
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt<= /span>

 =

Hi Martin & WG:<= span style=3D"color:black">

 

A few comments that I would= like to see addressed in the document before it can move forward to the ne= xt step.

  • Section 2.2 SFC Control Plane Bootstrapping.=

This section is too wishy w= ashy. It makes the statement “this document assumes the SFC control p= lane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 =

[Med] Fair point. I suggest to = make these modifications:

 

(1)

 

OLD:

   The following= information that is likely to be provided to the SFC

   control plane at b= ootstrapping includes (non-exhaustive list):

 

NEW:

   The following =
information that is RECOMMENDED to be provided to the SFC
   control plane =
prior to bootstrapping includes:

 

(2)

 

Remove this bullet from the lis= t and insert it right after the list.

 

   o  Option=
ally, (traffic/CPU/memory) load balancing objectives at the
    &nb=
sp; SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis.

 

 

Jim> that seems fine.

 

Minor point = -> typo in bullet point 6 – SFP proxy should read SFC proxy<= /p>

[Med] Fixed. Thanks.

  • Section 2.3 Coherent Setup of an SFC-enabled Domain

What does the sentence R= 20;various transport encapsulation schemes and/or variations of SFC header = implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or som= ething else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

 =

[M= ed] That sentence is related to the rich set of transport encapsulation sch= emes, but also that nsh header includes a version number.

&n= bsp;

Th= e current nsh spec does not specify how nodes with distinct nsh versions ar= e supposed to behave. Also, we don’t know in 2016 (because there is no nsh v2) whether v0 and v2 will be backward compatible= . If these versions are not backward compatible, this will lead to failures= when two adjacent elements in a service chain do not support the same vers= ion.

&n= bsp;

Th= e cp is key to ensure coherent setup of an SFC-domain to avoid failures tha= t are due to unsupported version and/or unsupported transport encapsulation.

 

Jim> maybe just replace = “variations” with “versions” so that it is clear wh= at is being talked about ?

  • Section 3.1 Reference Architecture

Second bullet point “= mapping between service function chains and SFPs” - this is a general= comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned only o= nce in the entire document. The architecture is explicit in that the SFP wh= en rendered into the network is an RSP and therefore the SFC control plane = element needs to have information on currently deployed RSPs.

 =

[Med] I agree RSP is not explic= itly mentioned in Section 3.1, but the point you raised is what is under th= is bullet:

 

   o  Determ=
ine a forwarding path in the context of a centralized
    &nb=
sp; deployment model (see Secti=
on 3.2).

 

Section 3.2 states the followin= g:

 

    &nb=
sp; For some traffic engineering proposes, the SFP may be constrained
    &nb=
sp; by the control plane; as such, some SFPs can be fully specified<=
span style=3D"color:black">
    &nb=
sp; (i.e., list all the SFF/SFs that need to be solicited) or
    &nb=
sp; partially specified (e.g., exclude some nodes, explicitly select=

    &nb=
sp; which instance of a given SF needs to be invoked, etc.).
 
Do you think a change is st=
ill needed to the text?

 

Jim> no I am fine with t= he text as it stands.

  

 

Additionally= there is no interface specified for communication between the SFC Control = Plane Element and SF management systems. This is an important aspect as many SF̵= 7;s may require that SFC information be communicated to their management sy= stems that will be responsible for communicating directly with their respective SF’s. =

 =

[Med] Good point. I suggest thi= s change in Section 3.3.3 that I believe is sufficient to take into account= this comment:

 

OLD:

 

   The SFC contro=
l plane uses this interface to interact with SFC-aware
   SFs.

 

NEW:

 

   The SFC contro=
l plane uses this interface to interact with SFC-aware
   SFs. This inte=
raction may be direct or via dedicated SF management systems.

 

Jim> that looks good.

  • Section 3.1.1. C1: Interface between SFC Control Plane & S= FC Classifier

The sentence “The con= trol plane may instruct the classifier about the initial values of the Serv= ice Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. 

 =

[Med] Makes sense. I made the c= hange in my local copy.

  • Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Pac= kets

This section does not actua= lly provide any meaning or indication of relationship with the SFC Control = Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire= section should be removed from the document.

 =

[Med] FWIW, there was a call ab= out this section (https://www.ietf.org/mail-archive/web/sfc/current/msg037= 56.html). This section does not recommend nor exclude source routes.

 

Jim> the title of the se= ction is “Encoding the exact SFF/SF sequence in data packets” w= hich is pretty clear what that means. The only encoding of the SFF/SF sequence supported by the SFC encapsulat= ion (taking type-2 metadata out of the equation) is the SPI + SI (which= is actually a reference to the placement within the service path rather th= an an encoding directly of a service sequence in the data plane) hence again I think this section should be rem= oved from the document. 

 

Jim

  • Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP

Figure 2 lists 3 different = SFP-id’s whereas the text mentions only SFP-id #1. Is this simply a t= ypo or are you trying to convey something else ?

 

Further you state that R= 20;the steering policies to a SFF node for service function chain depends o= n if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= ” -  this is an inaccurate statement as the combination of the S= FP-id and service-index determines the forwarding behavior (as specified in= section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

 

[Med] I will defer to Linda/And= rew to clarify this part of that text.    

 

Jim

 

 

 

On 4/27/16, 12:29 AM, "= ;sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,

 

This is the start of the Wo= rking Group Last Call (WGLC) for

 

draft-ietf-sfc-control-plan= e-04.txt

 

The WGLC lasts for 2 weeks = and will end May 11th at 10 pm PDT.=

 

Please send your comments a= nd reviews to the sfc@ietf.org list.

 

Regards,

 

   Martin (SFC co= -chair)

 

___________________________= ____________________

sfc mailing list

sfc@ietf.org<= /p>

 

--_000_787AE7BB302AE849A7480A190F8B933008D6153FOPEXCLILMA3corp_-- From nobody Thu Apr 28 08:02:44 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 67D5212D6A2 for ; Thu, 28 Apr 2016 08:02:42 -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 dLDxTqW6KBJT for ; Thu, 28 Apr 2016 08:02:36 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 388DC12D815 for ; Thu, 28 Apr 2016 08:02:30 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id v145so53243942oie.0 for ; Thu, 28 Apr 2016 08:02:30 -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=BbYSioZ9KsetwM4ybsDaRLTZndWMx6BikT/tG2ceaK0=; b=gDnR7758GmOzRztk0ARx9QaGNYiHb79fCUzVywnC5k0ykEbNthE6lSfNwxKRiIUTju lvIcBnCeOiZYdp6tImG5xsbaeX2civIaH7p/qQxonK8eR+1jqu7SlBMCWunCotBB8r53 cyh5J0Qm2QyiTeINYlI8jS8RQAy/qnEcGGoNOfU8WhD2kDOZkeui5o251wfKy+h1vcpb oi6iYIIAapZbWJ1lKiG/rhHxwfPRen/DF8Qn3P3O31TT9xu56khVNyjasMjhapCYUdos lZZf9ZPTDErAe1Z+59k37/n5/cnExSocul1LMSbS5deCXePWdCLgnEd2L7J97yTRwVAr euIQ== 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=BbYSioZ9KsetwM4ybsDaRLTZndWMx6BikT/tG2ceaK0=; b=fPQ/0lEJ7PG8vLWLevIfM1Qhv4ZSXcpHDQdAAMsvVHfBKUVV0aTXoME312HkFKJLlE 6vQRH+hBJ99/A9SsCmwO+p1mASiYWGj5QrGSegFurwuW3Kzu8+hvaFdxVJHcLaa1O3SB cQtIUYECEh6aji1N7EbU0h7+6KT1iVRqiYXtSpMdhTvFOGo/HH9nSrHRIgcahiBZLl9k DXvR4EGoMeoBHKnuIjL1LHbtNmL+LI0lCaSzRoiDZK+Bh3M0nyYyexzr9NcYV4r/xvAR InACIutxZ+nw69WUxXWsk6q6WYXe3Cq1UPL98XZKxcfqOLTKa+CcbmvJYfY6HEChBgiR 9eYg== X-Gm-Message-State: AOPr4FVSK2KgUSMhE/ixMn5mq1U76PuDTFDzc7DYmR4VZvqAHqcUKbec4xLke6ixHzH38N2Gu+LwiL0IKq5rNg== X-Received: by 10.157.13.227 with SMTP id 90mr7553125ots.79.1461855750058; Thu, 28 Apr 2016 08:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Thu, 28 Apr 2016 08:02:10 -0700 (PDT) In-Reply-To: References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> From: "Andrew G. Malis" Date: Thu, 28 Apr 2016 11:02:10 -0400 Message-ID: To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=94eb2c110014b22d7005318cd06d Archived-At: Cc: "Elzur, Uri" , Joel Halpern Direct , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 15:02:42 -0000 --94eb2c110014b22d7005318cd06d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jim, The way option 3 is currently worded, there=E2=80=99s no indication that th= is is just an example, and not a direction to use RFC 6830, section 5.4. I just had an offline discussion with Joel, and he and I agree that a better wording for option 3 would be "Use the fragmentation provided by the network overlay mechanics. One example can be found in RFC 6830, section 5.4.=E2=80=9D Thanks, Andy On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar) wrote: > Hi Andy, > > I think the key point is that NSH !=3D network overlay but rather utilize= s a > network overlay for packet transport between SFC network elements. The > reference is just an example of how a network overlay might deal with > fragmentation and is not a suggestion that NSH adopt that mechanism but > rather makes the point that it can utilize the existing network overlay > mechanics. > > Jim > > From: sfc on behalf of "Andrew G. Malis" < > agmalis@gmail.com> > Date: Thursday, April 28, 2016 at 8:17 AM > To: Joel Halpern Direct > Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" < > mohamed.boucadair@orange.com>, "sfc@ietf.org" , Linda > Dunbar > Subject: Re: [sfc] Suggested wording addtion to the Section 6 > (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt > > Joel, > > The diagrams in section 6 of RFC 6830 are control plane, not data plane. > The data plane diagrams are in section 5. > > But the overriding question is - without any fields in the NSH header to > sequence fragments, how can the fragments be correctly reassembled? > > Cheers, > Andy > > On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct < > jmh.direct@joelhalpern.com> wrote: > >> The LISP header does not have a fragment flag or fragment offset. The >> diagrams in section 6 include the outer encapsulating header (the >> equivalent of the transport header in SFC.) Yes, the text is a little h= ard >> to follow in this regard. The LISP working group is going to be rewriti= ng >> RFC 6830 as part of moving to standards track. >> >> So there is no difference in this regard between NSH and LISP. >> >> Yours, >> Joel >> >> On 4/27/16 7:02 PM, Andrew G. Malis wrote: >> >>> Joel et al, >>> >>> All this talk about fragmentation prompted me to re-read section 6 of >>> the draft, which recommends (as option 3) using the procedures in >>> section 5.4 of RFC 6830 (presumably with the =E2=80=9CNSH header=E2=80= =9D replacing the >>> =E2=80=9CLISP header=E2=80=9D in the description of the procedures in t= hat section). >>> >>> So that led me to read that section (and the LISP header definition in >>> section 5.1), and I see that LISP does fragmentation and reassembly >>> identically to IPv4, using the Fragment Offset field so that fragments >>> can be correctly reassembled in the proper order. >>> >>> However, the NSH Header doesn=E2=80=99t have a Fragment Offset field or= any >>> other way to order the fragments. >>> >>> So how can the procedures in Section 5.4 of 6830 be used? >>> >>> Thanks, >>> Andy >>> >>> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> > wrote: >>> >>> Both methods are valid, and both depend upon details of the >>> underlying packet and the transport. As such, I don't see why this >>> document benefits from describing them, much less why it should mar= k >>> one method as a "should". Implementation details are likely to be >>> more significant than any bit consumption difference between the tw= o >>> alternatives. >>> >>> Yours, >>> Joel >>> >>> >>> On 4/27/16 3:40 PM, Linda Dunbar wrote: >>> >>> I suggest adding the following paragraphs after the Bullet 3 of >>> the Section 6 Fragmentation Consideration to make the process >>> more clear and less controversial: >>> >>> >>> -------------------------------- >>> >>> RFC6830 describes the fragmentation method of breaking the >>> original packet into two equal sub-frames and encapsulating >>> [LISP Header + Transport header] to each sub-frame. >>> >>> If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC >>> Header + Transport Header] will be added to each half frame (or >>> the original data frame). As the Transport Header is terminated >>> by the next SFF node's tunnel transport layer, the combined two >>> sub-frames will have two SFC Headers. >>> >>> Therefore, the fragmentation for NSH encapsulated data frame >>> should be done completely by the node tunnel transport layer, >>> which should break the [SFC + original packet] into two equal >>> sub-frames and each sub-frame being encapsulated with its >>> respective tunnel header. The next SFF node's tunnel transport >>> layer should combine the two sub-frames before sending to the >>> next node. >>> >>> ------------------------------------------------------ >>> >>> >>> By the way, there are to typo in the Section 6: >>> 3rd line: "In order the" =3D=3D> "In order to" >>> Last line of Bullet 2: extra "the" in the "utilized to ensure >>> the the required packet". >>> >>> >>> Hope it helps. >>> >>> Linda >>> >>> >>> >>> -----Original Message----- >>> From: mohamed.boucadair@orange.com >>> >>> [mailto:mohamed.boucadair@orange.com >>> ] >>> Sent: Wednesday, April 27, 2016 12:40 AM >>> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org >>> >>> Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, all, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com >>> ] Envoy=C3=A9 : mardi 26 >>> avril 2016 19:18 =C3=80 : Linda Dunbar; BOUCADAIR Mohamed >>> IMT/OLN; Elzur, >>> Uri; sfc@ietf.org Objet : Re: [sfc] W= G >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> With regard to Transport tunnel fragementation, that seems >>> an issue >>> for the transport protocol. I don't actually object to a >>> sentence, >>> but it does not seem that it will accomplish anything. >>> >>> >>> [Med] I would like to see some text added to the draft. >>> >>> >>> With regard to packets fragmented by the source, I >>> completely disagree >>> with your assertion. If an SFF were to reassemble the >>> packets, that >>> would be a violation of its job. >>> >>> >>> [Med] I agree with you. >>> >>> There is no reason for an SFF to >>> >>> reassemble a packet fragmented by the source. The >>> classifier may have >>> to do some interesting things in order to properly classify >>> succeeding >>> fragments, but that is an implementation issue (most common= ly >>> addressed with virtual reassembly, which doe snot delay the >>> fragments.) We don't specity that. >>> >>> >>> [Med] Still, the external behavior of the classifier needs to b= e >>> clear in the document. I don't find any text in the draft sayin= g >>> for instance that an NSH header must be present in all >>> fragments. (There some processing that might be needed at the >>> SFF to "do its job" with regards to fragments (receive out of >>> order fragments + forwarding policy on the full packet).) >>> >>> >>> If an SF needs to reassemble fragments to do its job, that >>> is up to >>> the SF. Some will need to actually reassemble. Some will >>> need to >>> perform virtual reassembly, and some will happily process t= he >>> fragments. I can not see what the NSH document could >>> possibly mandate. >>> >>> >>> [Med] Fully agree. >>> >>> >>> Yours, >>> Joel >>> >>> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>> >>> Joel, >>> >>> I think the document should add the description on the >>> following two >>> fragmentation scenarios: >>> >>> - Transport tunnel generated fragmentation: When a pack= et >>> fragmentation is caused by transport tunnel (i.e. vario= us >>> encapsulations), the termination point of the transport >>> tunnel is >>> responsible for re-assembling the fragmented pieces of >>> the packet. >>> Since there won't be any SFF nodes in between the >>> Transport Tunnel, >>> the tunnel generated fragmentation does not require any >>> actions by >>> SFF nodes or SF nodes. >>> >>> >>> - Source node generated fragmentation (after adding on >>> the NSH >>> header): When fragmentation has to be performed for a >>> packet being >>> encapsulated with the NSH header, either the >>> intermediate SFF nodes >>> or the SF nodes have to be able to reassemble the >>> fragmented pieces. >>> >>> >>> >>> >>> Cheers, >>> >>> >>> Linda >>> >>> -----Original Message----- From: Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Sent: Tuesday, April 26, >>> 2016 10:33 AM >>> To: Linda Dunbar; mohamed.boucadair@orange.com >>> ; Elzur, Uri; >>> sfc@ietf.org Subject: Re: [sfc] W= G >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Re-reading your note, it is possible that you are >>> referring only to >>> the case of transport generated fragmentation of the >>> outer packet. >>> I had assumed you were not talking about that, since th= e >>> resulting >>> fragments will not all have NSH headers. As with any >>> tunnel >>> technology, if the tunnel chooses to fragment at its >>> layer, then the >>> tunnel is responsible for reassembly. That would be >>> invisible to >>> the SFF. >>> >>> Yours, Joel >>> >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>> >>> Agree with Med. >>> >>> Even if each fragment piece of a packet with NSH >>> header carries the >>> NSH header, the intermediate SFF nodes still need t= o >>> put together >>> all the fragments together before passing the whole >>> data frame to >>> the SF. >>> >>> Linda >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of mohamed.boucadair@orange.com >>> Sent: Monday, >>> April 25, >>> 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; >>> sfc@ietf.org Subject: >>> Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.tx= t >>> >>> Re-, >>> >>> How do you instruct the transport layer to ALWAYS >>> prepend an NSH >>> header even for fragments? Or you don't care about >>> that? >>> >>> Thank you. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> ] Envoy=C3=A9 : lun= di 25 >>> avril 2016 16:26 =C3=80 >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; >>> sfc@ietf.org Objet >>> : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> Not to repeat my position, but I'll do it anyho= w >>> :-) As NSH is >>> *NOT* a transport, dealing with fragmentation i= s >>> left to the >>> Transport used. >>> >>> The model I use for NSH, is basically similar t= o >>> VXLAN . It is an >>> overly. >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >> > >>> >>> >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of mohamed.boucadair@orange.com >>> Sent: >>> Monday, April 25, >>> 2016 7:18 AM To: Joel M. Halpern >>> >> >>; >>> sfc@ietf.org >>> Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Joel, >>> >>> Please see inline. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : Joel M. >>> Halpern >>> [mailto:jmh@joelhalpern.com >>> ] Envoy=C3=A9 := lundi >>> 25 avril 2016 15:48 =C3=80 >>> : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >>> Objet : Re: [sfc] WG >>> last call for draft-ietf-sfc-nsh-04.txt >>> >>> If I am understanding you correctly Med, yo= u >>> are asking that the >>> NSH draft specify how service chaining >>> should cope with packets >>> that have been fragmented? >>> >>> >>> [Med] To be accurate, I'm asking to assess >>> whether there are >>> implications. If there are, then the draft >>> should be updated >>> accordingly. >>> >>> NSH, and the SFF functionality, does not >>> care. >>> >>> >>> [Med] I'm not that sure. Some typical >>> implications are listed >>> below: >>> >>> * SFF: If the NSH header is present only in the >>> a fragment but SFF >>> didn't maintained a state, subsequent fragments >>> won't be >>> appropriately processed. * SFC-aware function: >>> if prepending a >>> context information depends on the full packet, >>> not only a >>> fragment. >>> >>> It just does its job. >>> >>> [Med] which may be disturbed in some situations >>> as listed in the >>> examples above. >>> >>> Ingress and intermediate classifiers may >>> cope with fragments in >>> any number of ways. >>> >>> Specifying such is clearly out of scope for thi= s >>> draft. >>> >>> [Med] The purpose is not to specify the interna= l >>> implementation >>> details but the external behavior of the >>> classifier function when >>> it comes to handle fragments. That behavior may >>> have an incidence >>> on SFF, in particular. The purpose is not to >>> recommend the maximum >>> resources to be dedicated to out of order >>> fragments nor the >>> timeout to cache those; these considerations ar= e >>> of course out of >>> scope. Nevertheless, an implementation should >>> offer a configurable >>> parameter so that an operator tweak those >>> according to its >>> context. >>> >>> I suppose one could write an informational >>> draft on possible ways >>> of coping. The IETF has not usually >>> published such. >>> Service functions have to cope with >>> fragmented packets just as >>> they had to before the advent of NSH, so >>> describing that is >>> clearly not needed here. >>> >>> >>> [Med] The advent of NSH has the following >>> implications: * it >>> exacerbates fragmentation. Handing over this >>> issue to the >>> transport layer may lead to interoperability >>> issues. * the >>> chaining may not be efficient if fragments are >>> inappropriately >>> handled. >>> >>> Introducing NSH should not degrade the overall >>> service compared to >>> legacy service deployment schemes. >>> >>> >>> Yours, Joel >>> >>> On 4/25/16 3:00 AM, >>> mohamed.boucadair@orange.com >>> wrote= : >>> >>> Re-, >>> >>> I hear you, but my comment is that we >>> need, as a WG, to decide >>> what to >>> >>> put in the draft. FWIW, I'm discussing two >>> fragmentation >>> issues: >>> >>> >>> (1) Fragmentation that is caused by >>> prepending an SFC header. >>> (2) Handling fragments at the ingress o= f >>> an SFC-enabled domain. >>> >>> Increasing the MTU is for sure a >>> recommendation is to be >>> explicitly >>> >>> called out in the text (see my first >>> message). >>> >>> >>> There are other issues that need to be >>> discussed, e.g., how to >>> deal with >>> >>> fragments in SFFs/Classifiers? >>> >>> >>> It is also "prudent" to check that no >>> issues will be experienced >>> in SFF >>> >>> to handle fragments. If an SFC header is >>> prepended for all >>> fragments, I'm not sure there >>> >>> is any particular issue at the SFF >>> level, except if >>> stripping/adding >>> >>> context TLVs depends on the full packet (no= t >>> just fragment). It >>> is warranted to consider a little bit this >>> point before declaring >>> there is no issue. >>> >>> >>> For point (1), declaring fragmentation >>> out of scope would be >>> meant that >>> >>> an implementation must be prepared to >>> receive fragments with or >>> without NSH header as this is a decision >>> that is left to the >>> transport encapsulation. This is a >>> requirement per se! >>> >>> >>> I won't reiterate all the comments I >>> have about the current >>> wording of >>> >>> this section. >>> >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De : >>> Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> ] Envoy= =C3=A9 >>> : lundi 25 avril 2016 >>> 08:30 =C3=80 : BOUCADAIR Mohamed IM= T/OLN; >>> Thomas Narten; >>> sfc@ietf.org >>> Objet : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> My point is that Fragmentation is >>> yet another transport related >>> issue >>> >>> that >>> >>> is beyond the scope of NSH and >>> beyond the charter of the WG, so >>> it >>> >>> doesn't >>> >>> really belong in the draft. We are >>> providing an advice as >>> extending the size of the packet ma= y >>> lead to fragmentation, but >>> as you check RFC 7348 VxLAN, which >>> my create the same issue, >>> you'll find it doesn't even >>> >>> relate >>> >>> to it. >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >>> >>> >>> >>> -----Original Message----- From: sf= c >>> [mailto:sfc-bounces@ietf.org >>> ] On >>> Behalf Of >>> mohamed.boucadair@orange.com >>> >>> Sent: >>> Sunday, April 24, 2016 >>> 10:32 PM To: Elzur, Uri >>> >> >; >>> Thomas Narten >>> >>> >> >>; >>> >>> sfc@ietf.org >>> Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Uri, >>> >>> That's another option that needs to >>> be discussed/investigated. >>> I'm >>> >>> afraid >>> >>> this is not the rationale adopted i= n >>> -04 since it includes some >>> text >>> >>> that >>> >>> is far to be sufficient to ensure >>> interoperable >>> implementations. >>> >>> BTW, saying that nsh does not need >>> to deal with fragmentation >>> because >>> >>> it >>> >>> is transport-independent is not IMH= O >>> a good strategy to adopt >>> here >>> >>> because >>> >>> it opens the door for interoperable >>> issues, it may lead to >>> sub-optimal implementations if the >>> sfc information is present >>> only in one >>> >>> fragments, >>> >>> etc. >>> >>> My comments are related to the >>> current text in the -04. >>> This text needs >>> >>> to >>> >>> be fixed somehow. >>> >>> Cheers, Med >>> >>> -----Message d'origine----- De = : >>> Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> ] >>> Envoy=C3=A9 : dimanche 24 avril >>> 2016 17:36 =C3=80 : BOUCADAIR M= ohamed >>> IMT/OLN; Thomas Narten; >>> sfc@ietf.org >>> Objet : >>> RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Hi Med >>> >>> I see no need to specify the >>> exact behavior as NSH is >>> transport independent i.e. like >>> NSH interaction with any other >>> Transport eh issue of >>> Fragmentation is to be dealt in >>> a way >>> that matches the mechanisms >>> supported by the Transport used >>> and do not belong in the NSH >>> draft >>> >>> Thx >>> >>> Uri ("Oo-Ree") C: 949-378-7568 >>> >>> >>> >>> -----Original Message----- From= : >>> sfc >>> [mailto:sfc-bounces@ietf.org >>> ] >>> On Behalf Of >>> mohamed.boucadair@orange.com >>> >> mohamed.boucadair@orange.com> >>> Sent: Thursday, April 14, >>> 2016 12:43 AM To: Thomas Narten >>> >> >; >>> sfc@ietf.org >>> Subject: >>> Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> R-, >>> >>> In addition to other pending >>> issues raised for this draft, I >>> would like to raise this >>> additional one about Section 6. >>> >>> =3D=3D 6. Fragmentation >>> Considerations >>> >>> NSH and the associated transpor= t >>> header are "added" to the >>> encapsulated packet/frame. Thi= s >>> additional information >>> increases >>> >>> the >>> >>> size of the packet. In order >>> the ensure proper forwarding of >>> NSH data, several options for >>> handling fragmentation and >>> re-assembly exist: >>> >>> 1. Jumbo Frames, when >>> supported, enable the transport >>> of NSH >>> and associated transport packet= s >>> without requiring >>> fragmentation. >>> >>> 2. Path MTU Discovery >>> [RFC1191]"describes a technique >>> for >>> dynamically discovering the >>> maximum transmission unit (MTU) >>> of >>> >>> an >>> >>> arbitrary internet path" and ca= n >>> be utilized to ensure the >>> >>> the >>> >>> required packet size is used. >>> >>> 3. [RFC6830] describes two >>> schemes for fragmentation and >>> re- >>> >>> assembly >>> >>> in section 5.4. =3D=3D >>> >>> * The text is weak for a >>> Standard track document that is >>> intended to solve the problem i= n >>> >>> https://tools.ietf.org/html/rfc7498#section- >>> >>> 2.12. >>> >>> There should be a clear behavio= r >>> to be followed by an >>> >>> implementation. >>> >>> Further, I would avoid the use >>> of words such as "can". >>> >>> * The text covers only >>> fragmentation when it is induce= d >>> by SFC >>> operations, it does not discuss >>> the treatment of a fragment >>> when received in an SFC domain. >>> IMHO, the draft should also >>> specify the behavior of the >>> Classifier with regards to >>> fragments for the sake of prope= r >>> SFC operation. Applying >>> classification policies may >>> require the >>> >>> full packet, not only a fragment. >>> >>> In particular, dedicated >>> resources should dedicated for >>> handling out of order fragments= . >>> Of course, it is out of scope >>> of this document to describe ho= w >>> SFs handle fragments. >>> >>> * If an SFC header is prepended >>> for all fragments, I'm not >>> sure there is any particular >>> issue at the SFF level...except >>> if stripping/adding context TLV= s >>> depends on the full packet >>> (not just fragment). It is >>> warranted to consider a little >>> bit >>> this point before declaring the= re >>> >>> is >>> >>> no issue. >>> >>> >>> * The text states "several >>> options". This may be interpret= ed >>> as if implementing one of them >>> is sufficient...which is not >>> true. The first two points >>> contribute to minimize the >>> fragmentation risk, but >>> fragmentation may still be >>> experienced >>> (e.g., other shims are prepende= d >>> by other nodes for some other >>> purposes, nested nsh, etc.) >>> >>> * The first two points have >>> nothing to do with reassembly. >>> >>> * The support of jumbo frames b= y >>> a router/device does not mean >>> that it can make use of it. >>> Appropriate MTU configuration >>> should be undertaken in a >>> consistent manner within an SFC >>> domain. The text should be >>> updated to make it is about >>> (consistent) MTU >>> >>> configuration. >>> >>> >>> * BTW, shouldn't the text be >>> reworded to recommended to >>> increase the MTU of **all >>> nodes** of an SFC-enabled domai= n >>> by >>> at least the length of SFC >>> header + transport header? >>> >>> * Bullet 2, how PMTU discovery >>> is actually used in this >>> context? Do you assume that all >>> SFC-aware nodes will issue >>> such messages towards other >>> SFC-aware node, arbitrary >>> destination, else? >>> >>> * Bullet 2, I would drop >>> "describes a technique for >>> dynamically discovering the >>> maximum transmission unit >>> (MTU) of an arbitrary internet >>> path". >>> >>> * Bullet 2, s/ the the/the. >>> >>> * The reference to the LISP >>> specification raises two concer= ns >>> and one comment: >>> >>> (1) I don't think it is a good >>> approach that fragments induced >>> by the network are passed to >>> their ultimate destinations as >>> such >>> >>> (stateless). >>> >>> IMO, reassembly should be done >>> within the SFC domain >>> (responsible for fragmentation) >>> not passed away. (2) Does the >>> stateful mode require all SFC >>> data plane elements maintain a >>> full list of MTU for the any >>> SFF/SF instance of the SFC >>> >>> domain? >>> >>> >>> The current text suggests that >>> [RFC6830] should be listed as >>> normative reference (not an >>> informative one). I would >>> personally favor removing the >>> reference to LISP (as it is an >>> Experimental RFC). >>> >>> * The security section of the >>> draft may be augmented with >>> informational >>> fragmentation-related pointers >>> to: >>> e.g., RFC1858 (Security >>> Considerations for IP Fragment >>> Filtering), RFC3128 (Protection >>> Against a Variant of the Tiny >>> Fragment Attack), and RFC 4963 >>> (IPv4 Reassembly Errors at High >>> Data Rates). >>> >>> Cheers, Med >>> >>> -----Message d'origine----- >>> De : sfc >>> [mailto:sfc-bounces@ietf.or= g >>> >> >] >>> De la part de >>> mohamed.boucadair@orange.co= m >>> >> mohamed.boucadair@orange.com> >>> Envoy=C3=A9 : lundi 11 avri= l >>> 2016 13:14 =C3=80 : Thomas >>> Narten; sfc@ietf.org >>> Objet >>> : Re: >>> [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>> >>> Dear Thomas, all, >>> >>> As I mentioned during the >>> meeting, there are several >>> issues >>> that are not covered in the >>> last version of the draft. = I >>> already provided examples o= f >>> the issues offline as >>> requested >>> by Martin. >>> >>> Cheers, Med >>> >>> -----Message >>> d'origine----- De : sfc >>> [mailto: >>> sfc-bounces@ietf.org >>> >> sfc-bounces@ietf.org>] >>> De la part de Thomas >>> Narten >>> Envoy=C3=A9 : jeudi 31 = mars >>> 2016 04:48 =C3=80 : >>> sfc@ietf.org >>> >>> Objet : [sfc] WG last >>> call for >>> draft-ietf-sfc-nsh-04.t= xt >>> >>> Dear WG: >>> >>> This note begins a WG >>> last call on >>> draft-ietf-sfc-nsh-04.t= xt >>> ( >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>> >>> >>> >>> The editors of the NSH document have indicated that they ha= ve >>> >>> addressed all known >>> comments and that there >>> are no open >>> issues with the current >>> version of the document= . >>> >>> Substantive comments to >>> the list please, >>> editorial comments >>> can go directly to the >>> document editors. >>> >>> We'll also get a brief >>> update from the editors >>> at next >>> week's meeting. If ther= e >>> are any remaining issue= s >>> with the >>> document, raising them >>> before the meeting woul= d >>> be >>> especially helpful. >>> >>> For the chairs, Thomas >>> >>> >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing >> >> > --94eb2c110014b22d7005318cd06d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SmltLDxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIHdheSBvcHRpb24gMyBp cyBjdXJyZW50bHkgd29yZGVkLCB0aGVyZeKAmXMgbm8gaW5kaWNhdGlvbiB0aGF0IHRoaXMgaXMg anVzdCBhbiBleGFtcGxlLCBhbmQgbm90IGEgZGlyZWN0aW9uIHRvIHVzZSBSRkMgNjgzMCwgc2Vj dGlvbiA1LjQuIEkganVzdCBoYWQgYW4gb2ZmbGluZSBkaXNjdXNzaW9uIHdpdGggSm9lbCwgYW5k IGhlIGFuZCBJIGFncmVlIHRoYXQgYSBiZXR0ZXIgd29yZGluZyBmb3Igb3B0aW9uIDMgd291bGQg YmUgJnF1b3Q7VXNlIHRoZSBmcmFnbWVudGF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBuZXR3b3JrIG92 ZXJsYXkgbWVjaGFuaWNzLiBPbmUgZXhhbXBsZSBjYW4gYmUgZm91bmQgaW4gUkZDIDY4MzAsIHNl Y3Rpb24gNS40LuKAnTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLDwvZGl2PjxkaXY+ QW5keTwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIFRodSwgQXByIDI4LCAyMDE2IGF0IDk6MjIgQU0sIEppbSBHdWljaGFy ZCAoamd1aWNoYXIpIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmpndWljaGFy QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpndWljaGFyQGNpc2NvLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQoNCg0KDQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCww LDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2 PkhpIEFuZHksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoZSBrZXkg cG9pbnQgaXMgdGhhdCBOU0ggIT0gbmV0d29yayBvdmVybGF5IGJ1dCByYXRoZXIgdXRpbGl6ZXMg YTxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj7CoDwvc3Bhbj5uZXR3b3JrIG92ZXJsYXkg Zm9yIHBhY2tldCB0cmFuc3BvcnQgYmV0d2VlbiBTRkMgbmV0d29yayBlbGVtZW50cy4gVGhlIHJl ZmVyZW5jZSBpcyBqdXN0IGFuIGV4YW1wbGUgb2YgaG93IGEgbmV0d29yayBvdmVybGF5IG1pZ2h0 IGRlYWwgd2l0aA0KIGZyYWdtZW50YXRpb24gYW5kIGlzIG5vdCBhIHN1Z2dlc3Rpb24gdGhhdCBO U0ggYWRvcHQgdGhhdCBtZWNoYW5pc20gYnV0IHJhdGhlciBtYWtlcyB0aGUgcG9pbnQgdGhhdCBp dCBjYW4gdXRpbGl6ZSB0aGUgZXhpc3RpbmcgbmV0d29yayBvdmVybGF5IG1lY2hhbmljcy7CoDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SmltPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPHNwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0 O3RleHQtYWxpZ246bGVmdDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JP UkRFUi1MRUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGlu O1BBRERJTkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJ R0hUOm1lZGl1bSBub25lO1BBRERJTkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnNmYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBv biBiZWhhbGYgb2YgJnF1b3Q7QW5kcmV3IEcuIE1hbGlzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86YWdtYWxpc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hZ21hbGlzQGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U aHVyc2RheSwgQXByaWwgMjgsIDIwMTYgYXQgODoxNyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkpvZWwgSGFscGVybiBEaXJlY3QgJmx0OzxhIGhyZWY9 Im1haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaC5k aXJlY3RAam9lbGhhbHBlcm4uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDtFbHp1ciwgVXJpJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRl bC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20i IHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDssDQog JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OywgTGluZGEgRHVuYmFyICZsdDs8YSBocmVm PSJtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5saW5kYS5k dW5iYXJAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3NmY10gU3VnZ2VzdGVkIHdvcmRpbmcgYWRkdGlvbiB0 byB0aGUgU2VjdGlvbiA2IChGcmFnbWVudGF0aW9uIENvbnNpZGVyYXRpb24pIG9mIHRoZSBkcmFm dC1pZXRmLXNmYy1uc2gtMDQudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5Kb2VsLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhlIGRpYWdyYW1zIGluIHNlY3Rpb24gNiBvZiBSRkMgNjgzMCBhcmUgY29udHJvbCBwbGFuZSwg bm90IGRhdGEgcGxhbmUuIFRoZSBkYXRhIHBsYW5lIGRpYWdyYW1zIGFyZSBpbiBzZWN0aW9uIDUu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CdXQgdGhlIG92ZXJyaWRpbmcgcXVlc3Rp b24gaXMgLSB3aXRob3V0IGFueSBmaWVsZHMgaW4gdGhlIE5TSCBoZWFkZXIgdG8gc2VxdWVuY2Ug ZnJhZ21lbnRzLCBob3cgY2FuIHRoZSBmcmFnbWVudHMgYmUgY29ycmVjdGx5IHJlYXNzZW1ibGVk PzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj5BbmR5 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgQXByIDI3LCAyMDE2IGF0IDc6NDYgUE0sIEpv ZWwgSGFscGVybiBEaXJlY3QgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpq bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaC5kaXJlY3RAam9l bGhhbHBlcm4uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KVGhlIExJU1AgaGVhZGVyIGRvZXMgbm90IGhh dmUgYSBmcmFnbWVudCBmbGFnIG9yIGZyYWdtZW50IG9mZnNldC7CoCBUaGUgZGlhZ3JhbXMgaW4g c2VjdGlvbiA2IGluY2x1ZGUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpbmcgaGVhZGVyICh0aGUgZXF1 aXZhbGVudCBvZiB0aGUgdHJhbnNwb3J0IGhlYWRlciBpbiBTRkMuKcKgIFllcywgdGhlIHRleHQg aXMgYSBsaXR0bGUgaGFyZCB0byBmb2xsb3cgaW4gdGhpcyByZWdhcmQuwqAgVGhlIExJU1Agd29y a2luZw0KIGdyb3VwIGlzIGdvaW5nIHRvIGJlIHJld3JpdGluZyBSRkMgNjgzMCBhcyBwYXJ0IG9m IG1vdmluZyB0byBzdGFuZGFyZHMgdHJhY2suPGJyPg0KPGJyPg0KU28gdGhlcmUgaXMgbm8gZGlm ZmVyZW5jZSBpbiB0aGlzIHJlZ2FyZCBiZXR3ZWVuIE5TSCBhbmQgTElTUC48YnI+DQo8YnI+DQpZ b3Vycyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gNC8yNy8xNiA3OjAyIFBNLCBBbmRyZXcgRy4g TWFsaXMgd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQpKb2VsIGV0IGFsLDxicj4NCjxicj4NCkFsbCB0aGlzIHRhbGsgYWJvdXQgZnJhZ21l bnRhdGlvbiBwcm9tcHRlZCBtZSB0byByZS1yZWFkIHNlY3Rpb24gNiBvZjxicj4NCnRoZSBkcmFm dCwgd2hpY2ggcmVjb21tZW5kcyAoYXMgb3B0aW9uIDMpIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGlu PGJyPg0Kc2VjdGlvbiA1LjQgb2YgUkZDIDY4MzAgKHByZXN1bWFibHkgd2l0aCB0aGUg4oCcTlNI IGhlYWRlcuKAnSByZXBsYWNpbmcgdGhlPGJyPg0K4oCcTElTUCBoZWFkZXLigJ0gaW4gdGhlIGRl c2NyaXB0aW9uIG9mIHRoZSBwcm9jZWR1cmVzIGluIHRoYXQgc2VjdGlvbikuPGJyPg0KPGJyPg0K U28gdGhhdCBsZWQgbWUgdG8gcmVhZCB0aGF0IHNlY3Rpb24gKGFuZCB0aGUgTElTUCBoZWFkZXIg ZGVmaW5pdGlvbiBpbjxicj4NCnNlY3Rpb24gNS4xKSwgYW5kIEkgc2VlIHRoYXQgTElTUCBkb2Vz IGZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHk8YnI+DQppZGVudGljYWxseSB0byBJUHY0LCB1 c2luZyB0aGUgRnJhZ21lbnQgT2Zmc2V0IGZpZWxkIHNvIHRoYXQgZnJhZ21lbnRzPGJyPg0KY2Fu IGJlIGNvcnJlY3RseSByZWFzc2VtYmxlZCBpbiB0aGUgcHJvcGVyIG9yZGVyLjxicj4NCjxicj4N Ckhvd2V2ZXIsIHRoZSBOU0ggSGVhZGVyIGRvZXNu4oCZdCBoYXZlIGEgRnJhZ21lbnQgT2Zmc2V0 IGZpZWxkIG9yIGFueTxicj4NCm90aGVyIHdheSB0byBvcmRlciB0aGUgZnJhZ21lbnRzLjxicj4N Cjxicj4NClNvIGhvdyBjYW4gdGhlIHByb2NlZHVyZXMgaW4gU2VjdGlvbiA1LjQgb2YgNjgzMCBi ZSB1c2VkPzxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpBbmR5PGJyPg0KPGJyPg0KT24gV2VkLCBB cHIgMjcsIDIwMTYgYXQgNDoxOSBQTSwgSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5j b208L2E+PGJyPg0KJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyZndDsgd3JvdGU6 PGJyPg0KPGJyPg0KwqAgwqAgQm90aCBtZXRob2RzIGFyZSB2YWxpZCwgYW5kIGJvdGggZGVwZW5k IHVwb24gZGV0YWlscyBvZiB0aGU8YnI+DQrCoCDCoCB1bmRlcmx5aW5nIHBhY2tldCBhbmQgdGhl IHRyYW5zcG9ydC7CoCBBcyBzdWNoLCBJIGRvbiYjMzk7dCBzZWUgd2h5IHRoaXM8YnI+DQrCoCDC oCBkb2N1bWVudCBiZW5lZml0cyBmcm9tIGRlc2NyaWJpbmcgdGhlbSwgbXVjaCBsZXNzIHdoeSBp dCBzaG91bGQgbWFyazxicj4NCsKgIMKgIG9uZSBtZXRob2QgYXMgYSAmcXVvdDtzaG91bGQmcXVv dDsuwqAgSW1wbGVtZW50YXRpb24gZGV0YWlscyBhcmUgbGlrZWx5IHRvIGJlPGJyPg0KwqAgwqAg bW9yZSBzaWduaWZpY2FudCB0aGFuIGFueSBiaXQgY29uc3VtcHRpb24gZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZSB0d288YnI+DQrCoCDCoCBhbHRlcm5hdGl2ZXMuPGJyPg0KPGJyPg0KwqAgwqAgWW91 cnMsPGJyPg0KwqAgwqAgSm9lbDxicj4NCjxicj4NCjxicj4NCsKgIMKgIE9uIDQvMjcvMTYgMzo0 MCBQTSwgTGluZGEgRHVuYmFyIHdyb3RlOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIEkgc3VnZ2Vz dCBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGhzIGFmdGVyIHRoZSBCdWxsZXQgMyBvZjxi cj4NCsKgIMKgIMKgIMKgIHRoZSBTZWN0aW9uIDYgRnJhZ21lbnRhdGlvbiBDb25zaWRlcmF0aW9u IHRvIG1ha2UgdGhlIHByb2Nlc3M8YnI+DQrCoCDCoCDCoCDCoCBtb3JlIGNsZWFyIGFuZCBsZXNz IGNvbnRyb3ZlcnNpYWw6PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBSRkM2ODMwIGRlc2Ny aWJlcyB0aGUgZnJhZ21lbnRhdGlvbiBtZXRob2Qgb2YgYnJlYWtpbmcgdGhlPGJyPg0KwqAgwqAg wqAgwqAgb3JpZ2luYWwgcGFja2V0IGludG8gdHdvIGVxdWFsIHN1Yi1mcmFtZXMgYW5kIGVuY2Fw c3VsYXRpbmc8YnI+DQrCoCDCoCDCoCDCoCBbTElTUCBIZWFkZXIgKyBUcmFuc3BvcnQgaGVhZGVy XSB0byBlYWNoIHN1Yi1mcmFtZS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBJZiBMSVNQIGZyYWdt ZW50YXRpb24gW1JGQzY4MzAgU2VjdGlvbiA1LjRdIGlzIHVzZWQsIHRoZSBbU0ZDPGJyPg0KwqAg wqAgwqAgwqAgSGVhZGVyICsgVHJhbnNwb3J0IEhlYWRlcl0gd2lsbCBiZSBhZGRlZCB0byBlYWNo IGhhbGYgZnJhbWUgKG9yPGJyPg0KwqAgwqAgwqAgwqAgdGhlIG9yaWdpbmFsIGRhdGEgZnJhbWUp LiBBcyB0aGUgVHJhbnNwb3J0IEhlYWRlciBpcyB0ZXJtaW5hdGVkPGJyPg0KwqAgwqAgwqAgwqAg YnkgdGhlIG5leHQgU0ZGIG5vZGUmIzM5O3MgdHVubmVsIHRyYW5zcG9ydCBsYXllciwgdGhlIGNv bWJpbmVkIHR3bzxicj4NCsKgIMKgIMKgIMKgIHN1Yi1mcmFtZXMgd2lsbCBoYXZlIHR3byBTRkMg SGVhZGVycy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBUaGVyZWZvcmUsIHRoZSBmcmFnbWVudGF0 aW9uIGZvciBOU0ggZW5jYXBzdWxhdGVkIGRhdGEgZnJhbWU8YnI+DQrCoCDCoCDCoCDCoCBzaG91 bGQgYmUgZG9uZSBjb21wbGV0ZWx5IGJ5IHRoZSBub2RlIHR1bm5lbCB0cmFuc3BvcnQgbGF5ZXIs PGJyPg0KwqAgwqAgwqAgwqAgd2hpY2ggc2hvdWxkIGJyZWFrIHRoZSBbU0ZDICsgb3JpZ2luYWwg cGFja2V0XSBpbnRvIHR3byBlcXVhbDxicj4NCsKgIMKgIMKgIMKgIHN1Yi1mcmFtZXMgYW5kIGVh Y2ggc3ViLWZyYW1lIGJlaW5nIGVuY2Fwc3VsYXRlZCB3aXRoIGl0czxicj4NCsKgIMKgIMKgIMKg IHJlc3BlY3RpdmUgdHVubmVsIGhlYWRlci7CoCBUaGUgbmV4dCBTRkYgbm9kZSYjMzk7cyB0dW5u ZWwgdHJhbnNwb3J0PGJyPg0KwqAgwqAgwqAgwqAgbGF5ZXIgc2hvdWxkIGNvbWJpbmUgdGhlIHR3 byBzdWItZnJhbWVzIGJlZm9yZSBzZW5kaW5nIHRvIHRoZTxicj4NCsKgIMKgIMKgIMKgIG5leHQg bm9kZS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBC eSB0aGUgd2F5LCB0aGVyZSBhcmUgdG8gdHlwbyBpbiB0aGUgU2VjdGlvbiA2Ojxicj4NCsKgIMKg IMKgIMKgIDNyZCBsaW5lOiAmcXVvdDtJbiBvcmRlciB0aGUmcXVvdDsgPT0mZ3Q7ICZxdW90O0lu IG9yZGVyIHRvJnF1b3Q7PGJyPg0KwqAgwqAgwqAgwqAgTGFzdCBsaW5lIG9mIEJ1bGxldCAyOiBl eHRyYSAmcXVvdDt0aGUmcXVvdDsgaW4gdGhlICZxdW90O3V0aWxpemVkIHRvIGVuc3VyZTxicj4N CsKgIMKgIMKgIMKgIHRoZSB0aGUgcmVxdWlyZWQgcGFja2V0JnF1b3Q7Ljxicj4NCjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIEhvcGUgaXQgaGVscHMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgTGlu ZGE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCsKgIMKgIMKgIMKgIEZyb206IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVm PSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0O108YnI+DQrCoCDCoCDC oCDCoCBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDE2IDEyOjQwIEFNPGJyPg0KwqAgwqAg wqAgwqAgVG86IEpvZWwgTS4gSGFscGVybjsgTGluZGEgRHVuYmFyOyBFbHp1ciwgVXJpOyA8YSBo cmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8 L2E+PGJyPg0KwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDC oCBTdWJqZWN0OiBSRTogW3NmY10gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNmYy1uc2gt MDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgSGkgSm9lbCwgYWxsLDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIFBsZWFzZSBzZWUgaW5saW5lLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIENoZWVy cyw8YnI+DQrCoCDCoCDCoCDCoCBNZWQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCAtLS0t LU1lc3NhZ2UgZCYjMzk7b3JpZ2luZS0tLS0tPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgRGUgOiBK b2VsIE0uIEhhbHBlcm4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0O10gRW52b3nDqSA6IG1h cmRpIDI2PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgYXZyaWwgMjAxNiAxOToxOCDDgCA6IExpbmRh IER1bmJhcjsgQk9VQ0FEQUlSIE1vaGFtZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBJTVQvT0xO OyBFbHp1ciw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBVcmk7IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwv YT4mZ3Q7IE9iamV0IDogUmU6IFtzZmNdIFdHPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgbGFzdCBj YWxsIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBXaXRoIHJlZ2FyZCB0byBUcmFuc3BvcnQgdHVu bmVsIGZyYWdlbWVudGF0aW9uLCB0aGF0IHNlZW1zPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgYW4g aXNzdWU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBmb3IgdGhlIHRyYW5zcG9ydCBwcm90b2NvbC7C oCBJIGRvbiYjMzk7dCBhY3R1YWxseSBvYmplY3QgdG8gYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IHNlbnRlbmNlLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGJ1dCBpdCBkb2VzIG5vdCBzZWVtIHRo YXQgaXQgd2lsbCBhY2NvbXBsaXNoIGFueXRoaW5nLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIFtNZWRdIEkgd291bGQgbGlrZSB0byBzZWUgc29tZSB0ZXh0IGFkZGVkIHRvIHRoZSBkcmFm dC48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBXaXRoIHJlZ2FyZCB0byBwYWNr ZXRzIGZyYWdtZW50ZWQgYnkgdGhlIHNvdXJjZSwgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIGNv bXBsZXRlbHkgZGlzYWdyZWU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCB3aXRoIHlvdXIgYXNzZXJ0 aW9uLsKgIElmIGFuIFNGRiB3ZXJlIHRvIHJlYXNzZW1ibGUgdGhlPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgcGFja2V0cywgdGhhdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHdvdWxkIGJlIGEgdmlv bGF0aW9uIG9mIGl0cyBqb2IuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgW01lZF0gSSBh Z3JlZSB3aXRoIHlvdS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCBUaGVyZSBpcyBubyByZWFz b24gZm9yIGFuIFNGRiB0bzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHJlYXNzZW1ibGUg YSBwYWNrZXQgZnJhZ21lbnRlZCBieSB0aGUgc291cmNlLsKgIFRoZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIGNsYXNzaWZpZXIgbWF5IGhhdmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCB0byBkbyBz b21lIGludGVyZXN0aW5nIHRoaW5ncyBpbiBvcmRlciB0byBwcm9wZXJseSBjbGFzc2lmeTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIHN1Y2NlZWRpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBmcmFn bWVudHMsIGJ1dCB0aGF0IGlzIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIChtb3N0IGNvbW1vbmx5 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgYWRkcmVzc2VkIHdpdGggdmlydHVhbCByZWFzc2VtYmx5 LCB3aGljaCBkb2Ugc25vdCBkZWxheSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVu dHMuKcKgIFdlIGRvbiYjMzk7dCBzcGVjaXR5IHRoYXQuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgW01lZF0gU3RpbGwsIHRoZSBleHRlcm5hbCBiZWhhdmlvciBvZiB0aGUgY2xhc3NpZmll ciBuZWVkcyB0byBiZTxicj4NCsKgIMKgIMKgIMKgIGNsZWFyIGluIHRoZSBkb2N1bWVudC4gSSBk b24mIzM5O3QgZmluZCBhbnkgdGV4dCBpbiB0aGUgZHJhZnQgc2F5aW5nPGJyPg0KwqAgwqAgwqAg wqAgZm9yIGluc3RhbmNlIHRoYXQgYW4gTlNIIGhlYWRlciBtdXN0IGJlIHByZXNlbnQgaW4gYWxs PGJyPg0KwqAgwqAgwqAgwqAgZnJhZ21lbnRzLiAoVGhlcmUgc29tZSBwcm9jZXNzaW5nIHRoYXQg bWlnaHQgYmUgbmVlZGVkIGF0IHRoZTxicj4NCsKgIMKgIMKgIMKgIFNGRiB0byAmcXVvdDtkbyBp dHMgam9iJnF1b3Q7IHdpdGggcmVnYXJkcyB0byBmcmFnbWVudHMgKHJlY2VpdmUgb3V0IG9mPGJy Pg0KwqAgwqAgwqAgwqAgb3JkZXIgZnJhZ21lbnRzICsgZm9yd2FyZGluZyBwb2xpY3kgb24gdGhl IGZ1bGwgcGFja2V0KS4pPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgSWYgYW4g U0YgbmVlZHMgdG8gcmVhc3NlbWJsZSBmcmFnbWVudHMgdG8gZG8gaXRzIGpvYiwgdGhhdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIGlzIHVwIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgdGhlIFNG LsKgIFNvbWUgd2lsbCBuZWVkIHRvIGFjdHVhbGx5IHJlYXNzZW1ibGUuwqAgU29tZSB3aWxsPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgbmVlZCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHBlcmZv cm0gdmlydHVhbCByZWFzc2VtYmx5LCBhbmQgc29tZSB3aWxsIGhhcHBpbHkgcHJvY2VzcyB0aGU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMuwqAgSSBjYW4gbm90IHNlZSB3aGF0IHRo ZSBOU0ggZG9jdW1lbnQgY291bGQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBwb3NzaWJseSBtYW5k YXRlLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIFtNZWRdIEZ1bGx5IGFncmVlLjxicj4N Cjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIFlvdXJzLDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIEpvZWw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBPbiA0LzI2LzE2IDExOjQ3IEFN LCBMaW5kYSBEdW5iYXIgd3JvdGU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Sm9lbCw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIHRoaW5rIHRoZSBkb2N1 bWVudCBzaG91bGQgYWRkIHRoZSBkZXNjcmlwdGlvbiBvbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBmb2xsb3dpbmcgdHdvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJh Z21lbnRhdGlvbiBzY2VuYXJpb3M6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg LSBUcmFuc3BvcnQgdHVubmVsIGdlbmVyYXRlZCBmcmFnbWVudGF0aW9uOiBXaGVuIGEgcGFja2V0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbiBpcyBjYXVzZWQgYnkg dHJhbnNwb3J0IHR1bm5lbCAoaS5lLiB2YXJpb3VzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZW5jYXBzdWxhdGlvbnMpLCB0aGUgdGVybWluYXRpb24gcG9pbnQgb2YgdGhlIHRyYW5zcG9y dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHR1bm5lbCBpczxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHJlc3BvbnNpYmxlIGZvciByZS1hc3NlbWJsaW5nIHRoZSBmcmFnbWVudGVk IHBpZWNlcyBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBwYWNrZXQuPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU2luY2UgdGhlcmUgd29uJiMzOTt0IGJlIGFueSBTRkYg bm9kZXMgaW4gYmV0d2VlbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUcmFuc3Bv cnQgVHVubmVsLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSB0dW5uZWwgZ2VuZXJh dGVkIGZyYWdtZW50YXRpb24gZG9lcyBub3QgcmVxdWlyZSBhbnk8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBhY3Rpb25zIGJ5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU0ZGIG5v ZGVzIG9yIFNGIG5vZGVzLjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IC0gU291cmNlIG5vZGUgZ2VuZXJhdGVkIGZyYWdtZW50YXRpb24gKGFmdGVyIGFkZGluZyBvbjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBOU0g8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBoZWFkZXIpOiBXaGVuIGZyYWdtZW50YXRpb24gaGFzIHRvIGJlIHBlcmZvcm1lZCBm b3IgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBhY2tldCBiZWluZzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGVuY2Fwc3VsYXRlZCB3aXRoIHRoZSBOU0ggaGVhZGVyLCBlaXRo ZXIgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW50ZXJtZWRpYXRlIFNGRiBub2Rl czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9yIHRoZSBTRiBub2RlcyBoYXZlIHRvIGJl IGFibGUgdG8gcmVhc3NlbWJsZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFn bWVudGVkIHBpZWNlcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBDaGVlcnMsPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgTGluZGE8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSBGcm9tOiBKb2VsIE0uIEhhbHBlcm48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJn ZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0 YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7XSBTZW50OiBUdWVzZGF5 LCBBcHJpbCAyNiw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2IDEwOjMzIEFNPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVG86IExpbmRhIER1bmJhcjsgPGEgaHJlZj0ibWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OzsgRWx6 dXIsIFVyaTs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxh IGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8 L2E+Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gV0c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1z ZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJlLXJlYWRp bmcgeW91ciBub3RlLCBpdCBpcyBwb3NzaWJsZSB0aGF0IHlvdSBhcmU8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCByZWZlcnJpbmcgb25seSB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHRoZSBjYXNlIG9mIHRyYW5zcG9ydCBnZW5lcmF0ZWQgZnJhZ21lbnRhdGlvbiBvZiB0aGU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvdXRlciBwYWNrZXQuPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgSSBoYWQgYXNzdW1lZCB5b3Ugd2VyZSBub3QgdGFsa2luZyBhYm91dCB0 aGF0LCBzaW5jZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZXN1bHRpbmc8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMgd2lsbCBub3QgYWxsIGhhdmUgTlNI IGhlYWRlcnMuwqAgQXMgd2l0aCBhbnkgdHVubmVsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdGVjaG5vbG9neSwgaWYgdGhlIHR1bm5lbCBjaG9vc2VzIHRvIGZyYWdtZW50IGF0IGl0czxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxheWVyLCB0aGVuIHRoZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHR1bm5lbCBpcyByZXNwb25zaWJsZSBmb3IgcmVhc3NlbWJseS7CoCBU aGF0IHdvdWxkIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW52aXNpYmxlIHRvPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhlIFNGRi48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBZb3VycywgSm9lbDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIE9uIDQvMjYvMTYgMTE6MTAgQU0sIExpbmRhIER1bmJhciB3cm90ZTo8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBZ3JlZSB3aXRoIE1lZC48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFdmVuIGlmIGVhY2ggZnJhZ21lbnQgcGllY2Ug b2YgYSBwYWNrZXQgd2l0aCBOU0g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBo ZWFkZXIgY2FycmllcyB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOU0gg aGVhZGVyLCB0aGUgaW50ZXJtZWRpYXRlIFNGRiBub2RlcyBzdGlsbCBuZWVkIHRvPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHV0IHRvZ2V0aGVyPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgYWxsIHRoZSBmcmFnbWVudHMgdG9nZXRoZXIgYmVmb3JlIHBhc3Np bmcgdGhlIHdob2xlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGF0YSBmcmFt ZSB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBTRi48YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBMaW5kYTxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHNm Yzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIE9uIEJlaGFsZiBPZiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IFNlbnQ6IE1vbmRheSw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBcHJpbCAyNSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAyMDE2IDk6NDIgQU0gVG86IEVsenVyLCBVcmk7IEpvZWwgTS4gSGFscGVybjs8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0OyBTdWJqZWN0Ojxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJlOiBbc2Zj XSBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZS0sPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSG93IGRvIHlvdSBpbnN0cnVjdCB0aGUgdHJhbnNwb3J0IGxheWVy IHRvIEFMV0FZUzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByZXBlbmQgYW4g TlNIPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGVhZGVyIGV2ZW4gZm9yIGZy YWdtZW50cz8gT3IgeW91IGRvbiYjMzk7dCBjYXJlIGFib3V0IHRoYXQ/PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhhbmsgeW91Ljxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIENoZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1NZXNzYWdlIGQmIzM5O29yaWdpbmUtLS0tLSBE ZSA6IEVsenVyLCBVcmk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT4mZ3Q7XSBFbnZvecOpIDog bHVuZGkgMjU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhdnJpbCAy MDE2IDE2OjI2IMOAPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOiBC T1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBKb2VsIE0uIEhhbHBlcm47PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsgT2Jq ZXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6IFJFOiBbc2ZjXSBX RyBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg ZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIEhpIE1lZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIE5vdCB0byByZXBlYXQgbXkgcG9zaXRpb24sIGJ1dCBJJiMzOTtsbCBkbyBp dCBhbnlob3c8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6LSkgQXMg TlNIIGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKk5PVCogYSB0 cmFuc3BvcnQsIGRlYWxpbmcgd2l0aCBmcmFnbWVudGF0aW9uIGlzPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGVmdCB0byB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBUcmFuc3BvcnQgdXNlZC48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgbW9kZWwgSSB1c2UgZm9yIE5TSCwgaXMgYmFz aWNhbGx5IHNpbWlsYXIgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBWWExBTiAuIEl0IGlzIGFuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgb3Zlcmx5Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFRoeDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFVyaSAo JnF1b3Q7T28tUmVlJnF1b3Q7KSBDOiA8YSBocmVmPSJ0ZWw6OTQ5LTM3OC03NTY4IiB2YWx1ZT0i KzE5NDkzNzg3NTY4IiB0YXJnZXQ9Il9ibGFuayI+DQo5NDktMzc4LTc1Njg8L2E+ICZsdDt0ZWw6 PGEgaHJlZj0idGVsOjk0OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJf YmxhbmsiPjk0OS0zNzgtNzU2ODwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTog c2ZjPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91 bmNlc0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtdPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gQmVoYWxmIE9mIDxhIGhyZWY9Im1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsg U2VudDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBNb25kYXksIEFw cmlsIDI1LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDIwMTYgNzox OCBBTSBUbzogSm9lbCBNLiBIYWxwZXJuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9 Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5j b208L2E+Jmd0OyZndDs7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9y ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBTdWJqZWN0OiBSZTogW3NmY10gV0cgbGFzdCBjYWxsIGZvcjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBKb2VsLDxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFBsZWFzZSBzZWUg aW5saW5lLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENo ZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgLS0tLS1NZXNzYWdlIGQmIzM5O29yaWdpbmUtLS0tLSBEZSA6IEpvZWwgTS4gSGFscGVy bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWhA am9lbGhhbHBlcm4uY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20i IHRhcmdldD0iX2JsYW5rIj5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDtdIEVudm95w6kgOiBs dW5kaTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDI1IGF2 cmlsIDIwMTYgMTU6NDggw4A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IDxhIGhyZWY9Im1haWx0bzpzZmNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyBP YmpldCA6IFJlOiBbc2ZjXSBXRzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElmIEkgYW0gdW5k ZXJzdGFuZGluZyB5b3UgY29ycmVjdGx5IE1lZCwgeW91PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXJlIGFza2luZyB0aGF0IHRoZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5TSCBkcmFmdCBzcGVjaWZ5IGhvdyBz ZXJ2aWNlIGNoYWluaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgc2hvdWxkIGNvcGUgd2l0aCBwYWNrZXRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCBoYXZlIGJlZW4gZnJhZ21lbnRlZD88YnI+DQo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVkXSBUbyBiZSBh Y2N1cmF0ZSwgSSYjMzk7bSBhc2tpbmcgdG8gYXNzZXNzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgd2hldGhlciB0aGVyZSBhcmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBpbXBsaWNhdGlvbnMuIElmIHRoZXJlIGFyZSwgdGhlbiB0aGUg ZHJhZnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaG91bGQgYmUg dXBkYXRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFjY29yZGlu Z2x5Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IE5TSCwgYW5kIHRoZSBTRkYgZnVuY3Rpb25hbGl0eSwgZG9lcyBub3QgY2FyZS48YnI+DQo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbTWVkXSBJJiMzOTtt IG5vdCB0aGF0IHN1cmUuIFNvbWUgdHlwaWNhbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGltcGxpY2F0aW9ucyBhcmUgbGlzdGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgYmVsb3c6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgKiBTRkY6IElmIHRoZSBOU0ggaGVhZGVyIGlzIHByZXNlbnQgb25s eSBpbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhIGZyYWdt ZW50IGJ1dCBTRkY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaWRu JiMzOTt0IG1haW50YWluZWQgYSBzdGF0ZSwgc3Vic2VxdWVudCBmcmFnbWVudHM8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b24mIzM5O3QgYmU8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcHByb3ByaWF0ZWx5IHByb2Nlc3NlZC4gKiBT RkMtYXdhcmUgZnVuY3Rpb246PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaWYgcHJlcGVuZGluZyBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgY29udGV4dCBpbmZvcm1hdGlvbiBkZXBlbmRzIG9uIHRoZSBmdWxsIHBhY2tldCw8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBub3Qgb25seSBhPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnQuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSXQganVzdCBkb2VzIGl0cyBqb2IuPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW01lZF0gd2hpY2ggbWF5 IGJlIGRpc3R1cmJlZCBpbiBzb21lIHNpdHVhdGlvbnM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhcyBsaXN0ZWQgaW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZXhhbXBsZXMgYWJvdmUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSW5ncmVzcyBhbmQgaW50ZXJtZWRpYXRlIGNs YXNzaWZpZXJzIG1heTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGNvcGUgd2l0aCBmcmFnbWVudHMgaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhbnkgbnVtYmVyIG9mIHdheXMuPGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3BlY2lmeWluZyBzdWNoIGlzIGNsZWFybHkgb3V0 IG9mIHNjb3BlIGZvciB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZHJhZnQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg W01lZF0gVGhlIHB1cnBvc2UgaXMgbm90IHRvIHNwZWNpZnkgdGhlIGludGVybmFsPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50YXRpb248YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZXRhaWxzIGJ1dCB0aGUgZXh0ZXJuYWwg YmVoYXZpb3Igb2YgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Y2xhc3NpZmllciBmdW5jdGlvbiB3aGVuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgaXQgY29tZXMgdG8gaGFuZGxlIGZyYWdtZW50cy4gVGhhdCBiZWhhdmlvciBtYXk8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoYXZlIGFuIGluY2lkZW5j ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9uIFNGRiwgaW4gcGFy dGljdWxhci4gVGhlIHB1cnBvc2UgaXMgbm90IHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgcmVjb21tZW5kIHRoZSBtYXhpbXVtPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVzb3VyY2VzIHRvIGJlIGRlZGljYXRlZCB0byBvdXQgb2Yg b3JkZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMg bm9yIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRpbWVvdXQg dG8gY2FjaGUgdGhvc2U7IHRoZXNlIGNvbnNpZGVyYXRpb25zIGFyZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9mIGNvdXJzZSBvdXQgb2Y8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzY29wZS4gTmV2ZXJ0aGVsZXNzLCBhbiBpbXBsZW1l bnRhdGlvbiBzaG91bGQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBv ZmZlciBhIGNvbmZpZ3VyYWJsZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHBhcmFtZXRlciBzbyB0aGF0IGFuIG9wZXJhdG9yIHR3ZWFrIHRob3NlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWNjb3JkaW5nIHRvIGl0czxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnRleHQuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBzdXBwb3NlIG9uZSBjb3VsZCB3 cml0ZSBhbiBpbmZvcm1hdGlvbmFsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgZHJhZnQgb24gcG9zc2libGUgd2F5czxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9mIGNvcGluZy7CoCBUaGUgSUVURiBoYXMgbm90IHVz dWFsbHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwdWJs aXNoZWQgc3VjaC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBTZXJ2aWNlIGZ1bmN0aW9ucyBoYXZlIHRvIGNvcGUgd2l0aDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50ZWQgcGFja2V0cyBqdXN0IGFzPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhleSBoYWQgdG8g YmVmb3JlIHRoZSBhZHZlbnQgb2YgTlNILCBzbzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGRlc2NyaWJpbmcgdGhhdCBpczxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsZWFybHkgbm90IG5lZWRlZCBoZXJlLjxicj4N Cjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtNZWRdIFRo ZSBhZHZlbnQgb2YgTlNIIGhhcyB0aGUgZm9sbG93aW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgaW1wbGljYXRpb25zOiAqIGl0PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZXhhY2VyYmF0ZXMgZnJhZ21lbnRhdGlvbi4gSGFuZGluZyBv dmVyIHRoaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZSB0 byB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0cmFuc3BvcnQg bGF5ZXIgbWF5IGxlYWQgdG8gaW50ZXJvcGVyYWJpbGl0eTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGlzc3Vlcy4gKiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBjaGFpbmluZyBtYXkgbm90IGJlIGVmZmljaWVudCBpZiBmcmFnbWVu dHMgYXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5hcHByb3By aWF0ZWx5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGFuZGxlZC48 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJbnRyb2R1Y2lu ZyBOU0ggc2hvdWxkIG5vdCBkZWdyYWRlIHRoZSBvdmVyYWxsPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgc2VydmljZSBjb21wYXJlZCB0bzxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxlZ2FjeSBzZXJ2aWNlIGRlcGxveW1lbnQgc2NoZW1l cy48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBZb3VycywgSm9lbDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIE9uIDQvMjUvMTYgMzowMCBBTSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFJlLSw8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBJIGhlYXIgeW91LCBidXQgbXkgY29tbWVudCBpcyB0aGF0IHdlPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbmVlZCwgYXMgYSBXRywg dG8gZGVjaWRlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgd2hhdCB0bzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHB1dCBpbiB0aGUgZHJhZnQuIEZXSVcsIEkmIzM5O20gZGlzY3Vzc2luZyB0d288 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudGF0 aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVz Ojxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICgxKSBGcmFnbWVudGF0aW9uIHRoYXQgaXMgY2F1c2VkIGJ5PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJlcGVuZGluZyBhbiBT RkMgaGVhZGVyLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgICgyKSBIYW5kbGluZyBmcmFnbWVudHMgYXQgdGhlIGluZ3Jlc3Mgb2Y8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbiBTRkMtZW5hYmxl ZCBkb21haW4uPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgSW5jcmVhc2luZyB0aGUgTVRVIGlzIGZvciBzdXJlIGE8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWNvbW1lbmRhdGlvbiBp cyB0byBiZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGV4cGxpY2l0bHk8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBjYWxsZWQgb3V0IGluIHRoZSB0ZXh0IChzZWUgbXkgZmlyc3QgbWVzc2FnZSku PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgVGhlcmUgYXJlIG90aGVyIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaXNjdXNzZWQsIGUu Zy4sIGhvdyB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGRlYWwgd2l0aDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGZyYWdtZW50cyBpbiBTRkZzL0NsYXNzaWZpZXJzPzxicj4NCjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEl0IGlz IGFsc28gJnF1b3Q7cHJ1ZGVudCZxdW90OyB0byBjaGVjayB0aGF0IG5vPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWVzIHdpbGwgYmUgZXhw ZXJpZW5jZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBpbiBTRkY8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB0byBoYW5kbGUgZnJhZ21lbnRzLiBJZiBhbiBTRkMgaGVhZGVyIGlzPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJlcGVuZGVkIGZvciBhbGw8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcmFnbWVudHMs IEkmIzM5O20gbm90IHN1cmUgdGhlcmU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyBhbnkgcGFydGljdWxhciBpc3N1ZSBhdCB0aGUg U0ZGPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg bGV2ZWwsIGV4Y2VwdCBpZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHN0cmlwcGluZy9hZGRpbmc8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb250ZXh0IFRMVnMgZGVwZW5kcyBvbiB0aGUgZnVs bCBwYWNrZXQgKG5vdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGp1c3QgZnJhZ21lbnQpLiBJdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGlzIHdhcnJhbnRlZCB0byBjb25zaWRlciBhIGxpdHRsZSBiaXQgdGhpczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBvaW50IGJlZm9y ZSBkZWNsYXJpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB0aGVyZSBpcyBubyBpc3N1ZS48YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBGb3IgcG9pbnQgKDEpLCBkZWNsYXJpbmcgZnJh Z21lbnRhdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG91dCBvZiBzY29wZSB3b3VsZCBiZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1lYW50IHRoYXQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbiBpbXBsZW1lbnRhdGlvbiBtdXN0IGJl IHByZXBhcmVkIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgcmVjZWl2ZSBmcmFnbWVudHMgd2l0aCBvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHdpdGhvdXQgTlNIIGhlYWRlciBhcyB0aGlzIGlzIGEgZGVjaXNp b248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0IGlz IGxlZnQgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24uIFRoaXMgaXMgYTxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlcXVpcmVtZW50IHBlciBzZSE8YnI+DQo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJ IHdvbiYjMzk7dCByZWl0ZXJhdGUgYWxsIHRoZSBjb21tZW50cyBJPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGF2ZSBhYm91dCB0aGUgY3VycmVu dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdv cmRpbmcgb2Y8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0aGlzIHNlY3Rpb24uPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ2hlZXJzLCBNZWQ8YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU1lc3Nh Z2UgZCYjMzk7b3JpZ2luZS0tLS0tIERlIDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFbHp1ciwgVXJpPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBocmVm PSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBp bnRlbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVs LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+Jmd0O10gRW52b3nD qTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIDogbHVuZGkgMjUgYXZyaWwgMjAxNjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDA4OjMwIMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQg SU1UL09MTjs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBUaG9tYXMgTmFydGVuOzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDs8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBPYmpldCA6IFJFOiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNo LTA0LnR4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIEhpIE1lZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE15IHBvaW50IGlzIHRoYXQgRnJhZ21lbnRh dGlvbiBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHlldCBhbm90aGVyIHRyYW5zcG9ydCByZWxhdGVkPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXNzdWU8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg aXMgYmV5b25kIHRoZSBzY29wZSBvZiBOU0ggYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmV5b25kIHRoZSBjaGFydGVyIG9mIHRo ZSBXRywgc288YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGRvZXNuJiMzOTt0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVhbGx5IGJlbG9uZyBpbiB0aGUgZHJhZnQu IFdlIGFyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHByb3ZpZGluZyBhbiBhZHZpY2UgYXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleHRlbmRpbmcgdGhlIHNpemUgb2Yg dGhlIHBhY2tldCBtYXk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBsZWFkIHRvIGZyYWdtZW50YXRpb24sIGJ1dDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzIHlvdSBjaGVj ayBSRkMgNzM0OCBWeExBTiwgd2hpY2g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBteSBjcmVhdGUgdGhlIHNhbWUgaXNzdWUsPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgeW91 JiMzOTtsbCBmaW5kIGl0IGRvZXNuJiMzOTt0IGV2ZW48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWxhdGU8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBpdC48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBUaHg8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBVcmkgKCZxdW90O09vLVJlZSZxdW90OykgQzogPGEgaHJlZj0idGVsOjk0 OS0zNzgtNzU2OCIgdmFsdWU9IisxOTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPg0KOTQ5LTM3 OC03NTY4PC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZsdDt0ZWw6PGEgaHJlZj0idGVsOjk0OS0zNzgtNzU2OCIgdmFsdWU9Iisx OTQ5Mzc4NzU2OCIgdGFyZ2V0PSJfYmxhbmsiPjk0OS0zNzgtNzU2ODwvYT4mZ3Q7PGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogc2ZjPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91 bmNlc0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtd IE9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgQmVoYWxmIE9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyBT ZW50Ojxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFN1bmRheSwgQXByaWwgMjQsIDIwMTY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAxMDozMiBQTSBUbzogRWx6dXIsIFVyaTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICZsdDs8YSBocmVmPSJtYWlsdG86dXJpLmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnVyaS5lbHp1ckBpbnRlbC5jb208L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dXJp LmVsenVyQGludGVsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnVyaS5lbHp1ckBpbnRlbC5jb208L2E+ Jmd0OyZndDs7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgVGhvbWFzIE5hcnRlbjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5j b20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5jb20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMu aWJtLmNvbTwvYT4mZ3Q7Jmd0Ozs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgU3ViamVjdDogUmU6IFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRmLXNmYy1u c2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSGkgVXJpLDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoYXQmIzM5O3MgYW5vdGhlciBvcHRp b24gdGhhdCBuZWVkcyB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGJlIGRpc2N1c3NlZC9pbnZlc3RpZ2F0ZWQuPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSYjMzk7bTxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFmcmFp ZDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHRoaXMgaXMgbm90IHRoZSByYXRpb25hbGUgYWRvcHRlZCBpbjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0wNCBzaW5j ZSBpdCBpbmNsdWRlcyBzb21lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdGV4dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyBmYXIgdG8gYmUgc3VmZmljaWVu dCB0byBlbnN1cmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBpbnRlcm9wZXJhYmxlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1wbGVtZW50YXRpb25zLjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJU Vywgc2F5aW5nIHRoYXQgbnNoIGRvZXMgbm90IG5lZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBkZWFsIHdpdGggZnJhZ21lbnRh dGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGJlY2F1c2U8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpdDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIHRyYW5zcG9ydC1pbmRlcGVuZGVudCBpcyBub3QgSU1I Tzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGEgZ29vZCBzdHJhdGVneSB0byBhZG9wdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlcmU8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZWNhdXNlPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQgb3BlbnMg dGhlIGRvb3IgZm9yIGludGVyb3BlcmFibGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXMsIGl0IG1heSBsZWFkIHRvPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3Vi LW9wdGltYWwgaW1wbGVtZW50YXRpb25zIGlmIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNmYyBpbmZvcm1hdGlvbiBpcyBwcmVz ZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgb25seSBpbiBvbmU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBmcmFnbWVudHMsPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXRjLjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE15IGNvbW1lbnRz IGFyZSByZWxhdGVkIHRvIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGN1cnJlbnQgdGV4dCBpbiB0aGUgLTA0Ljxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMgdGV4 dCBuZWVkczxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHRvPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYmUgZml4ZWQgc29tZWhvdy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBDaGVlcnMsIE1lZDxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS0gRGUgOjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVs enVyLCBVcmk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT48YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1cmkuZWx6dXJAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dXJpLmVsenVyQGludGVsLmNvbTwvYT4mZ3Q7XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVudm95w6kgOiBkaW1hbmNo ZSAyNCBhdnJpbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIDIwMTYgMTc6MzYgw4AgOiBCT1VDQURBSVIgTW9oYW1lZDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIElNVC9PTE47IFRob21hcyBOYXJ0ZW47PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc2ZjQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0Bp ZXRmLm9yZzwvYT4mZ3Q7IE9iamV0IDo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSRTogW3NmY10gV0cgbGFzdCBjYWxsIGZv cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGRyYWZ0LWlldGYtc2ZjLW5zaC0wNC50eHQ8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIaSBNZWQ8 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBJIHNlZSBubyBuZWVkIHRvIHNwZWNpZnkgdGhlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXhhY3Qg YmVoYXZpb3IgYXMgTlNIIGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdHJhbnNwb3J0IGluZGVwZW5kZW50IGkuZS4gbGlr ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE5TSCBpbnRlcmFjdGlvbiB3aXRoIGFueSBvdGhlcjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRyYW5zcG9y dCBlaCBpc3N1ZSBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIEZyYWdtZW50YXRpb24gaXMgdG8gYmUgZGVhbHQgaW48YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBhIHdheTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgbWF0Y2hlcyB0aGUgbWVjaGFuaXNtczxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1 cHBvcnRlZCBieSB0aGUgVHJhbnNwb3J0IHVzZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQgZG8gbm90IGJlbG9uZyBp biB0aGUgTlNIIGRyYWZ0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGh4PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVXJpICgmcXVv dDtPby1SZWUmcXVvdDspIEM6IDxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0 OTM3ODc1NjgiIHRhcmdldD0iX2JsYW5rIj4NCjk0OS0zNzgtNzU2ODwvYT48YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7 dGVsOjxhIGhyZWY9InRlbDo5NDktMzc4LTc1NjgiIHZhbHVlPSIrMTk0OTM3ODc1NjgiIHRhcmdl dD0iX2JsYW5rIj45NDktMzc4LTc1Njg8L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHNmYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNA aWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE9uIEJlaGFsZiBPZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQptb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPiZndDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZW50OiBUaHVyc2RheSwgQXByaWwgMTQsPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgMjAxNiAxMjo0MyBBTSBUbzogVGhvbWFzIE5hcnRlbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDs8YSBocmVmPSJt YWlsdG86bmFydGVuQHVzLmlibS5jb20iIHRhcmdldD0iX2JsYW5rIj5uYXJ0ZW5AdXMuaWJtLmNv bTwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuYXJ0ZW5AdXMuaWJtLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm5hcnRlbkB1cy5pYm0uY29tPC9hPiZndDsmZ3Q7Ozxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNmY0BpZXRm Lm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0OyBTdWJqZWN0Ojxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJl OiBbc2ZjXSBXRyBsYXN0IGNhbGwgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4 dDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFItLDxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEluIGFkZGl0aW9uIHRvIG90aGVyIHBl bmRpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBpc3N1ZXMgcmFpc2VkIGZvciB0aGlzIGRyYWZ0LCBJPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd291 bGQgbGlrZSB0byByYWlzZSB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWRkaXRpb25hbCBvbmUgYWJvdXQgU2VjdGlv biA2Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgID09IDYuwqAgRnJhZ21lbnRhdGlvbiBDb25zaWRlcmF0aW9uczxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIE5TSCBhbmQgdGhlIGFzc29jaWF0ZWQgdHJhbnNwb3J0PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGVh ZGVyIGFyZSAmcXVvdDthZGRlZCZxdW90OyB0byB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbmNhcHN1bGF0ZWQgcGFj a2V0L2ZyYW1lLsKgIFRoaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg aW5jcmVhc2VzPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgdGhlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2l6ZSBvZiB0aGUgcGFja2V0LsKgIEluIG9yZGVyPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgdGhlIGVuc3VyZSBwcm9wZXIgZm9yd2FyZGluZyBvZjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5TSCBkYXRhLCBz ZXZlcmFsIG9wdGlvbnMgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGFuZGxpbmcgZnJhZ21lbnRhdGlvbiBhbmQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCByZS1hc3NlbWJseSBleGlzdDo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAxLsKgIEp1bWJvIEZyYW1lcywg d2hlbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHN1cHBvcnRlZCwgZW5hYmxlIHRoZSB0cmFuc3BvcnQ8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiBO U0g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBhbmQgYXNzb2NpYXRlZCB0cmFuc3BvcnQgcGFja2V0czxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdpdGhv dXQgcmVxdWlyaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbi48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyLsKgIFBh dGggTVRVIERpc2NvdmVyeTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtSRkMxMTkxXSZxdW90O2Rlc2NyaWJlcyBhIHRlY2hu aXF1ZSBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBkeW5hbWljYWxseSBkaXNjb3ZlcmluZyB0aGU8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtYXhp bXVtIHRyYW5zbWlzc2lvbiB1bml0IChNVFUpIG9mPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcmJpdHJhcnkgaW50 ZXJuZXQgcGF0aCZxdW90OyBhbmQgY2FuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmUgdXRpbGl6ZWQgdG8gZW5zdXJlIHRo ZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZTxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHJlcXVpcmVkIHBhY2tldCBzaXplIGlzIHVzZWQuPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMy7C oCBbUkZDNjgzMF0gZGVzY3JpYmVzIHR3bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNjaGVtZXMgZm9yIGZyYWdtZW50YXRp b24gYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgcmUtPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYXNzZW1ibHk8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbiBzZWN0aW9uIDUuNC4gPT08 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAqIFRoZSB0ZXh0IGlzIHdlYWsgZm9yIGE8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdGFuZGFyZCB0 cmFjayBkb2N1bWVudCB0aGF0IGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW50ZW5kZWQgdG8gc29sdmUgdGhlIHByb2Js ZW0gaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ5 OCNzZWN0aW9uLSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzQ5OCNzZWN0aW9uLTwvYT48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyLjEyLjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZXJlIHNo b3VsZCBiZSBhIGNsZWFyIGJlaGF2aW9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gYmUgZm9sbG93ZWQgYnkgYW48YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbXBsZW1lbnRhdGlv bi48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBGdXJ0aGVyLCBJIHdvdWxkIGF2b2lkIHRoZSB1c2U8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBv ZiB3b3JkcyBzdWNoIGFzICZxdW90O2NhbiZxdW90Oy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAqIFRoZSB0ZXh0 IGNvdmVycyBvbmx5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRhdGlvbiB3aGVuIGl0IGlzIGluZHVjZWQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBieSBTRkM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBvcGVyYXRpb25zLCBpdCBkb2VzIG5vdCBkaXNjdXNzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdGhlIHRyZWF0bWVudCBvZiBhIGZyYWdtZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2hlbiByZWNlaXZlZCBpbiBh biBTRkMgZG9tYWluLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIElNSE8sIHRoZSBkcmFmdCBzaG91bGQgYWxzbzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHNwZWNpZnkgdGhlIGJlaGF2aW9yIG9mIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENsYXNzaWZpZXIgd2l0aCByZWdh cmRzIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgZnJhZ21lbnRzIGZvciB0aGUgc2FrZSBvZiBwcm9wZXI8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBT RkMgb3BlcmF0aW9uLiBBcHBseWluZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNsYXNzaWZpY2F0aW9uIHBvbGljaWVzIG1h eTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHJlcXVpcmUgdGhlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnVsbCBwYWNrZXQsIG5vdCBvbmx5IGEgZnJh Z21lbnQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgSW4gcGFydGljdWxhciwgZGVkaWNhdGVkPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVz b3VyY2VzIHNob3VsZCBkZWRpY2F0ZWQgZm9yPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaGFuZGxpbmcgb3V0IG9mIG9yZGVy IGZyYWdtZW50cy48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBPZiBjb3Vyc2UsIGl0IGlzIG91dCBvZiBzY29wZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IG9mIHRoaXMgZG9jdW1lbnQgdG8gZGVzY3JpYmUgaG93PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU0ZzIGhhbmRsZSBmcmFn bWVudHMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBJZiBhbiBTRkMgaGVhZGVyIGlzIHByZXBlbmRlZDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGZvciBhbGwgZnJhZ21lbnRzLCBJJiMzOTttIG5vdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1cmUgdGhlcmUgaXMg YW55IHBhcnRpY3VsYXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZSBhdCB0aGUgU0ZGIGxldmVsLi4uZXhjZXB0PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaWYgc3RyaXBwaW5nL2FkZGluZyBjb250ZXh0IFRMVnM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZXBlbmRzIG9u IHRoZSBmdWxsIHBhY2tldDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChub3QganVzdCBmcmFnbWVudCkuIEl0IGlzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgd2FycmFudGVkIHRvIGNvbnNpZGVyIGEgbGl0dGxlIGJpdDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoaXMgcG9pbnQg YmVmb3JlIGRlY2xhcmluZyB0aGVyZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGlzPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbm8gaXNzdWUuPGJyPg0KPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgKiBUaGUgdGV4dCBzdGF0ZXMgJnF1b3Q7c2V2ZXJhbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9wdGlvbnMmcXVvdDsu IFRoaXMgbWF5IGJlIGludGVycHJldGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgaWYgaW1wbGVtZW50aW5nIG9uZSBv ZiB0aGVtPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgaXMgc3VmZmljaWVudC4uLndoaWNoIGlzIG5vdDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRydWUu IFRoZSBmaXJzdCB0d28gcG9pbnRzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29udHJpYnV0ZSB0byBtaW5pbWl6ZSB0aGU8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBmcmFnbWVudGF0aW9uIHJpc2ssIGJ1dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZyYWdtZW50YXRpb24gbWF5 IHN0aWxsIGJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZXhwZXJpZW5jZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoZS5nLiwgb3RoZXIgc2hpbXMg YXJlIHByZXBlbmRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJ5IG90aGVyIG5vZGVzIGZvciBzb21lIG90aGVyPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgcHVycG9zZXMsIG5lc3RlZCBuc2gsIGV0Yy4pPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKiBUaGUgZmlyc3Qg dHdvIHBvaW50cyBoYXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbm90aGluZyB0byBkbyB3aXRoIHJlYXNzZW1ibHkuPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKiBUaGUgc3VwcG9ydCBvZiBqdW1ibyBmcmFtZXMgYnk8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhIHJv dXRlci9kZXZpY2UgZG9lcyBub3QgbWVhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoYXQgaXQgY2FuIG1ha2UgdXNlIG9m IGl0Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEFwcHJvcHJpYXRlIE1UVSBjb25maWd1cmF0aW9uPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2hvdWxk IGJlIHVuZGVydGFrZW4gaW4gYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnNpc3RlbnQgbWFubmVyIHdpdGhpbiBhbiBT RkM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBkb21haW4uIFRoZSB0ZXh0IHNob3VsZCBiZTxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVwZGF0ZWQgdG8g bWFrZSBpdCBpcyBhYm91dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChjb25zaXN0ZW50KSBNVFU8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb25maWd1cmF0aW9uLjxicj4NCjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICogQlRXLCBzaG91bGRuJiMzOTt0IHRoZSB0ZXh0IGJlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmV3b3Jk ZWQgdG8gcmVjb21tZW5kZWQgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmNyZWFzZSB0aGUgTVRVIG9mICoqYWxsPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgbm9kZXMqKiBvZiBhbiBTRkMtZW5hYmxlZCBkb21haW4gYnk8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhdCBsZWFz dCB0aGUgbGVuZ3RoIG9mIFNGQzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGhlYWRlciArIHRyYW5zcG9ydCBoZWFkZXI/PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKiBCdWxsZXQgMiwgaG93IFBNVFUgZGlzY292ZXJ5PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXMgYWN0 dWFsbHkgdXNlZCBpbiB0aGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY29udGV4dD8gRG8geW91IGFzc3VtZSB0aGF0IGFs bDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFNGQy1hd2FyZSBub2RlcyB3aWxsIGlzc3VlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3VjaCBtZXNzYWdl cyB0b3dhcmRzIG90aGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU0ZDLWF3YXJlIG5vZGUsIGFyYml0cmFyeTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGRlc3RpbmF0aW9uLCBlbHNlPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICogQnVsbGV0IDIsIEkgd291bGQgZHJv cDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZxdW90O2Rlc2NyaWJlcyBhIHRlY2huaXF1ZSBmb3I8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkeW5hbWlj YWxseSBkaXNjb3ZlcmluZyB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgKE1UVSkgb2YgYW4gYXJiaXRyYXJ5IGludGVybmV0PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGF0aCZxdW90Oy48 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAqIEJ1bGxldCAyLCBzLyB0aGUgdGhlL3RoZS48YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAq IFRoZSByZWZlcmVuY2UgdG8gdGhlIExJU1A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzcGVjaWZpY2F0aW9uIHJhaXNlcyB0 d28gY29uY2VybnM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQgb25lIGNvbW1lbnQ6PGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKDEpIEkg ZG9uJiMzOTt0IHRoaW5rIGl0IGlzIGEgZ29vZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFwcHJvYWNoIHRoYXQgZnJhZ21l bnRzIGluZHVjZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBieSB0aGUgbmV0d29yayBhcmUgcGFzc2VkIHRvPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dGhlaXIgdWx0aW1hdGUgZGVzdGluYXRpb25zIGFzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3VjaDxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChzdGF0ZWxlc3MpLjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIElNTywgcmVhc3NlbWJseSBzaG91bGQgYmUgZG9uZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdpdGhpbiB0aGUgU0ZD IGRvbWFpbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIChyZXNwb25zaWJsZSBmb3IgZnJhZ21lbnRhdGlvbik8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBu b3QgcGFzc2VkIGF3YXkuICgyKSBEb2VzIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN0YXRlZnVsIG1vZGUgcmVxdWly ZSBhbGwgU0ZDPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgZGF0YSBwbGFuZSBlbGVtZW50cyBtYWludGFpbiBhPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg ZnVsbCBsaXN0IG9mIE1UVSBmb3IgdGhlIGFueTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNGRi9TRiBpbnN0YW5jZSBvZiB0 aGUgU0ZDPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgZG9tYWluPzxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBjdXJyZW50IHRl eHQgc3VnZ2VzdHMgdGhhdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtSRkM2ODMwXSBzaG91bGQgYmUgbGlzdGVkIGFzPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgbm9ybWF0aXZlIHJlZmVyZW5jZSAobm90IGFuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5mb3JtYXRpdmUgb25l KS4gSSB3b3VsZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHBlcnNvbmFsbHkgZmF2b3IgcmVtb3ZpbmcgdGhlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cmVmZXJlbmNlIHRvIExJU1AgKGFzIGl0IGlzIGFuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRXhwZXJpbWVudGFsIFJGQyku PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgKiBUaGUgc2VjdXJpdHkgc2VjdGlvbiBvZiB0aGU8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFm dCBtYXkgYmUgYXVnbWVudGVkIHdpdGg8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmZvcm1hdGlvbmFsPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZnJh Z21lbnRhdGlvbi1yZWxhdGVkIHBvaW50ZXJzIHRvOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGUuZy4sIFJGQzE4NTggKFNl Y3VyaXR5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgQ29uc2lkZXJhdGlvbnMgZm9yIElQIEZyYWdtZW50PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRmls dGVyaW5nKSwgUkZDMzEyOCAoUHJvdGVjdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFnYWluc3QgYSBWYXJpYW50IG9m IHRoZSBUaW55PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgRnJhZ21lbnQgQXR0YWNrKSwgYW5kIFJGQyA0OTYzPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg KElQdjQgUmVhc3NlbWJseSBFcnJvcnMgYXQgSGlnaDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIERhdGEgUmF0ZXMpLjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIENoZWVycywgTWVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS0tLS1NZXNzYWdlIGQm IzM5O29yaWdpbmUtLS0tLTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIERlIDogc2ZjPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDtdPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGUgbGEgcGFydCBkZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20iIHRhcmdldD0iX2JsYW5rIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDs8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBFbnZvecOpIDogbHVuZGkgMTEgYXZyaWw8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyMDE2 IDEzOjE0IMOAIDogVGhvbWFzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTmFydGVuOyA8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2ZjQGlldGYub3JnPC9hPiZndDsgT2JqZXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6IFJlOjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFtzZmNdIFdHIGxhc3QgY2FsbCBmb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkcmFmdC1pZXRm LXNmYy1uc2gtMDQudHh0PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGVhciBUaG9tYXMsIGFsbCw8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBBcyBJIG1lbnRpb25lZCBkdXJpbmcgdGhlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg bWVldGluZywgdGhlcmUgYXJlIHNldmVyYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpc3N1ZXM8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB0aGF0IGFyZSBub3QgY292ZXJlZCBpbiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsYXN0IHZlcnNp b24gb2YgdGhlIGRyYWZ0LiBJPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWxyZWFkeSBwcm92aWRlZCBleGFtcGxl cyBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBpc3N1ZXMgb2ZmbGluZSBhcyByZXF1ZXN0ZWQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBieSBNYXJ0aW4uPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ2hlZXJzLCBNZWQ8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU1lc3NhZ2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkJiMz OTtvcmlnaW5lLS0tLS0gRGUgOiBzZmM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0O108YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEZSBsYSBwYXJ0IGRlIFRob21h cyBOYXJ0ZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFbnZvecOpIDogamV1ZGkgMzEgbWFyczxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIDIwMTYgMDQ6NDggw4AgOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwv YT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIE9iamV0IDogW3NmY10gV0cgbGFzdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNhbGwgZm9y PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIERlYXIgV0c6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhpcyBu b3RlIGJlZ2lucyBhIFdHPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGFzdCBjYWxsIG9uPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgZHJhZnQtaWV0Zi1zZmMtbnNoLTA0LnR4dDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNm Yy1uc2gvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gvPC9hPikuPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgVGhlIGVkaXRvcnMgb2YgdGhlIE5TSCBkb2N1bWVu dCBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgaGF2ZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGFkZHJlc3NlZCBhbGwga25vd248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb21tZW50cyBhbmQgdGhh dCB0aGVyZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZSBubyBvcGVuPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgaXNzdWVzIHdpdGggdGhlIGN1cnJlbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB2ZXJzaW9uIG9m IHRoZSBkb2N1bWVudC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdWJzdGFudGl2ZSBjb21t ZW50cyB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBsaXN0IHBsZWFzZSw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBlZGl0b3JpYWwgY29tbWVudHM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjYW4gZ28gZGly ZWN0bHkgdG8gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZG9jdW1lbnQgZWRpdG9ycy48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBXZSYjMzk7bGwgYWxzbyBnZXQgYSBicmllZjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHVwZGF0ZSBmcm9tIHRoZSBlZGl0b3JzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXQg bmV4dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdlZWsmIzM5O3MgbWVldGluZy4gSWYgdGhlcmU8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBhcmUgYW55IHJlbWFpbmluZyBpc3N1ZXM8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB3aXRoIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvY3VtZW50LCByYWlzaW5nIHRoZW08 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBiZWZvcmUgdGhlIG1lZXRpbmcgd291bGQgYmU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBlc3BlY2lhbGx5IGhlbHBmdWwuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Rm9yIHRoZSBjaGFpcnMsIFRob21hczxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc2ZjIG1haWxpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaXN0IDxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjPC9hPjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2ZjIG1haWxpbmc8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCjxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg c2ZjIG1haWxpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBsaXN0IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4NCnNmY0BpZXRmLm9yZzwvYT48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2ZjIG1haWxpbmc8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9k aXY+DQo= --94eb2c110014b22d7005318cd06d-- From nobody Thu Apr 28 08:05:59 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 3933612D6A2 for ; Thu, 28 Apr 2016 08:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 rVDDUOIJM_qU for ; Thu, 28 Apr 2016 08:05:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C1912D1A4 for ; Thu, 28 Apr 2016 08:05:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D1AFE240F47; Thu, 28 Apr 2016 08:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461855950; bh=QRFmRzHQN9ST3hVGyoJCNsfe8bvd/aiHk4phw4A6Mxk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=V2OWVd37EtkYzbrQ0qDxLBxf6d6tHAFajRysqTwwyZfZvGWJjnRMEO3Ddlg8pglJj K5KijNBO/SY5fd7iS7IiDCFLa600SRzhVk8NJTnTbTYOKJ1tGYxbSsvXJHWHj+eSql PpAURGOoXvy4tR4UPIz3fJTxYSQYbmM+MgkjuILs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id ADBB1240609; Thu, 28 Apr 2016 08:05:48 -0700 (PDT) To: "Andrew G. Malis" , "Jim Guichard (jguichar)" References: <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> From: Joel Halpern Direct Message-ID: <888c5567-c459-f29f-6f20-02aad39f1f76@joelhalpern.com> Date: Thu, 28 Apr 2016 11:05:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.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" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 15:05:58 -0000 Thanks Andy. That wording would indeed work for me. Yours, Joel On 4/28/16 11:02 AM, Andrew G. Malis wrote: > Jim, > > The way option 3 is currently worded, there’s no indication that this is > just an example, and not a direction to use RFC 6830, section 5.4. I > just had an offline discussion with Joel, and he and I agree that a > better wording for option 3 would be "Use the fragmentation provided by > the network overlay mechanics. One example can be found in RFC 6830, > section 5.4.†> > Thanks, > Andy > > On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar) > > wrote: > > Hi Andy, > > I think the key point is that NSH != network overlay but rather > utilizes a network overlay for packet transport between SFC network > elements. The reference is just an example of how a network overlay > might deal with fragmentation and is not a suggestion that NSH adopt > that mechanism but rather makes the point that it can utilize the > existing network overlay mechanics. > > Jim > > From: sfc > on > behalf of "Andrew G. Malis" > > Date: Thursday, April 28, 2016 at 8:17 AM > To: Joel Halpern Direct > > Cc: "Elzur, Uri" >, > "mohamed.boucadair@orange.com " > >, "sfc@ietf.org > " >, Linda > Dunbar > > Subject: Re: [sfc] Suggested wording addtion to the Section 6 > (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt > > Joel, > > The diagrams in section 6 of RFC 6830 are control plane, not data > plane. The data plane diagrams are in section 5. > > But the overriding question is - without any fields in the NSH > header to sequence fragments, how can the fragments be correctly > reassembled? > > Cheers, > Andy > > On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct > > wrote: > > The LISP header does not have a fragment flag or fragment > offset. The diagrams in section 6 include the outer > encapsulating header (the equivalent of the transport header in > SFC.) Yes, the text is a little hard to follow in this regard. > The LISP working group is going to be rewriting RFC 6830 as part > of moving to standards track. > > So there is no difference in this regard between NSH and LISP. > > Yours, > Joel > > On 4/27/16 7:02 PM, Andrew G. Malis wrote: > > Joel et al, > > All this talk about fragmentation prompted me to re-read > section 6 of > the draft, which recommends (as option 3) using the > procedures in > section 5.4 of RFC 6830 (presumably with the “NSH header†> replacing the > “LISP header†in the description of the procedures in that > section). > > So that led me to read that section (and the LISP header > definition in > section 5.1), and I see that LISP does fragmentation and > reassembly > identically to IPv4, using the Fragment Offset field so that > fragments > can be correctly reassembled in the proper order. > > However, the NSH Header doesn’t have a Fragment Offset field > or any > other way to order the fragments. > > So how can the procedures in Section 5.4 of 6830 be used? > > Thanks, > Andy > > On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern > > >> > wrote: > > Both methods are valid, and both depend upon details of the > underlying packet and the transport. As such, I don't > see why this > document benefits from describing them, much less why it > should mark > one method as a "should". Implementation details are > likely to be > more significant than any bit consumption difference > between the two > alternatives. > > Yours, > Joel > > > On 4/27/16 3:40 PM, Linda Dunbar wrote: > > I suggest adding the following paragraphs after the > Bullet 3 of > the Section 6 Fragmentation Consideration to make > the process > more clear and less controversial: > > > -------------------------------- > > RFC6830 describes the fragmentation method of > breaking the > original packet into two equal sub-frames and > encapsulating > [LISP Header + Transport header] to each sub-frame. > > If LISP fragmentation [RFC6830 Section 5.4] is used, > the [SFC > Header + Transport Header] will be added to each > half frame (or > the original data frame). As the Transport Header is > terminated > by the next SFF node's tunnel transport layer, the > combined two > sub-frames will have two SFC Headers. > > Therefore, the fragmentation for NSH encapsulated > data frame > should be done completely by the node tunnel > transport layer, > which should break the [SFC + original packet] into > two equal > sub-frames and each sub-frame being encapsulated > with its > respective tunnel header. The next SFF node's > tunnel transport > layer should combine the two sub-frames before > sending to the > next node. > > ------------------------------------------------------ > > > By the way, there are to typo in the Section 6: > 3rd line: "In order the" ==> "In order to" > Last line of Bullet 2: extra "the" in the "utilized > to ensure > the the required packet". > > > Hope it helps. > > Linda > > > > -----Original Message----- > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com > > >] > Sent: Wednesday, April 27, 2016 12:40 AM > To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; > sfc@ietf.org > > > Subject: RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Joel, all, > > Please see inline. > > Cheers, > Med > > -----Message d'origine----- > De : Joel M. Halpern [mailto:jmh@joelhalpern.com > > >] Envoyé : mardi 26 > avril 2016 19:18 À : Linda Dunbar; BOUCADAIR Mohamed > IMT/OLN; Elzur, > Uri; sfc@ietf.org > > Objet : Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > With regard to Transport tunnel fragementation, > that seems > an issue > for the transport protocol. I don't actually > object to a > sentence, > but it does not seem that it will accomplish > anything. > > > [Med] I would like to see some text added to the draft. > > > With regard to packets fragmented by the source, I > completely disagree > with your assertion. If an SFF were to > reassemble the > packets, that > would be a violation of its job. > > > [Med] I agree with you. > > There is no reason for an SFF to > > reassemble a packet fragmented by the source. The > classifier may have > to do some interesting things in order to > properly classify > succeeding > fragments, but that is an implementation issue > (most commonly > addressed with virtual reassembly, which doe > snot delay the > fragments.) We don't specity that. > > > [Med] Still, the external behavior of the classifier > needs to be > clear in the document. I don't find any text in the > draft saying > for instance that an NSH header must be present in all > fragments. (There some processing that might be > needed at the > SFF to "do its job" with regards to fragments > (receive out of > order fragments + forwarding policy on the full > packet).) > > > If an SF needs to reassemble fragments to do its > job, that > is up to > the SF. Some will need to actually reassemble. > Some will > need to > perform virtual reassembly, and some will > happily process the > fragments. I can not see what the NSH document > could > possibly mandate. > > > [Med] Fully agree. > > > Yours, > Joel > > On 4/26/16 11:47 AM, Linda Dunbar wrote: > > Joel, > > I think the document should add the > description on the > following two > fragmentation scenarios: > > - Transport tunnel generated fragmentation: > When a packet > fragmentation is caused by transport tunnel > (i.e. various > encapsulations), the termination point of > the transport > tunnel is > responsible for re-assembling the fragmented > pieces of > the packet. > Since there won't be any SFF nodes in > between the > Transport Tunnel, > the tunnel generated fragmentation does not > require any > actions by > SFF nodes or SF nodes. > > > - Source node generated fragmentation (after > adding on > the NSH > header): When fragmentation has to be > performed for a > packet being > encapsulated with the NSH header, either the > intermediate SFF nodes > or the SF nodes have to be able to > reassemble the > fragmented pieces. > > > > > Cheers, > > > Linda > > -----Original Message----- From: Joel M. Halpern > [mailto:jmh@joelhalpern.com > > >] Sent: Tuesday, April 26, > 2016 10:33 AM > To: Linda Dunbar; > mohamed.boucadair@orange.com > > >; Elzur, Uri; > sfc@ietf.org > > Subject: Re: > [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > Re-reading your note, it is possible that > you are > referring only to > the case of transport generated > fragmentation of the > outer packet. > I had assumed you were not talking about > that, since the > resulting > fragments will not all have NSH headers. As > with any tunnel > technology, if the tunnel chooses to > fragment at its > layer, then the > tunnel is responsible for reassembly. That > would be > invisible to > the SFF. > > Yours, Joel > > On 4/26/16 11:10 AM, Linda Dunbar wrote: > > Agree with Med. > > Even if each fragment piece of a packet > with NSH > header carries the > NSH header, the intermediate SFF nodes > still need to > put together > all the fragments together before > passing the whole > data frame to > the SF. > > Linda > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > > >] > On Behalf Of > mohamed.boucadair@orange.com > > > Sent: Monday, > April 25, > 2016 9:42 AM To: Elzur, Uri; Joel M. > Halpern; > sfc@ietf.org > > Subject: > Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Re-, > > How do you instruct the transport layer > to ALWAYS > prepend an NSH > header even for fragments? Or you don't > care about that? > > Thank you. > > Cheers, Med > > -----Message d'origine----- De : > Elzur, Uri > [mailto:uri.elzur@intel.com > > >] Envoyé : lundi 25 > avril 2016 16:26 À > : BOUCADAIR Mohamed IMT/OLN; Joel M. > Halpern; > sfc@ietf.org > > Objet > : RE: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > Not to repeat my position, but I'll > do it anyhow > :-) As NSH is > *NOT* a transport, dealing with > fragmentation is > left to the > Transport used. > > The model I use for NSH, is > basically similar to > VXLAN . It is an > overly. > > Thx > > Uri ("Oo-Ree") C: 949-378-7568 > > > > > -----Original Message----- From: sfc > [mailto:sfc-bounces@ietf.org > > >] > On Behalf Of > mohamed.boucadair@orange.com > > > Sent: > Monday, April 25, > 2016 7:18 AM To: Joel M. Halpern > >>; > sfc@ietf.org > > > Subject: Re: [sfc] WG last call for > draft-ietf-sfc-nsh-04.txt > > Hi Joel, > > Please see inline. > > Cheers, Med > > -----Message d'origine----- De : > Joel M. Halpern > [mailto:jmh@joelhalpern.com > > >] Envoyé : lundi > 25 avril 2016 15:48 À > : BOUCADAIR Mohamed IMT/OLN; > sfc@ietf.org > > Objet : Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > If I am understanding you > correctly Med, you > are asking that the > NSH draft specify how service > chaining > should cope with packets > that have been fragmented? > > > [Med] To be accurate, I'm asking to > assess > whether there are > implications. If there are, then the > draft > should be updated > accordingly. > > NSH, and the SFF functionality, > does not care. > > > [Med] I'm not that sure. Some typical > implications are listed > below: > > * SFF: If the NSH header is present > only in the > a fragment but SFF > didn't maintained a state, > subsequent fragments > won't be > appropriately processed. * SFC-aware > function: > if prepending a > context information depends on the > full packet, > not only a > fragment. > > It just does its job. > > [Med] which may be disturbed in some > situations > as listed in the > examples above. > > Ingress and intermediate > classifiers may > cope with fragments in > any number of ways. > > Specifying such is clearly out of > scope for this > draft. > > [Med] The purpose is not to specify > the internal > implementation > details but the external behavior of the > classifier function when > it comes to handle fragments. That > behavior may > have an incidence > on SFF, in particular. The purpose > is not to > recommend the maximum > resources to be dedicated to out of > order > fragments nor the > timeout to cache those; these > considerations are > of course out of > scope. Nevertheless, an > implementation should > offer a configurable > parameter so that an operator tweak > those > according to its > context. > > I suppose one could write an > informational > draft on possible ways > of coping. The IETF has not usually > published such. > Service functions have to cope with > fragmented packets just as > they had to before the advent of > NSH, so > describing that is > clearly not needed here. > > > [Med] The advent of NSH has the > following > implications: * it > exacerbates fragmentation. Handing > over this > issue to the > transport layer may lead to > interoperability > issues. * the > chaining may not be efficient if > fragments are > inappropriately > handled. > > Introducing NSH should not degrade > the overall > service compared to > legacy service deployment schemes. > > > Yours, Joel > > On 4/25/16 3:00 AM, > mohamed.boucadair@orange.com > > > > wrote: > > Re-, > > I hear you, but my comment > is that we > need, as a WG, to decide > what to > > put in the draft. FWIW, I'm > discussing two > fragmentation > issues: > > > (1) Fragmentation that is > caused by > prepending an SFC header. > (2) Handling fragments at > the ingress of > an SFC-enabled domain. > > Increasing the MTU is for sure a > recommendation is to be > explicitly > > called out in the text (see my > first message). > > > There are other issues that > need to be > discussed, e.g., how to > deal with > > fragments in SFFs/Classifiers? > > > It is also "prudent" to > check that no > issues will be experienced > in SFF > > to handle fragments. If an SFC > header is > prepended for all > fragments, I'm not sure there > > is any particular issue at > the SFF > level, except if > stripping/adding > > context TLVs depends on the full > packet (not > just fragment). It > is warranted to consider a > little bit this > point before declaring > there is no issue. > > > For point (1), declaring > fragmentation > out of scope would be > meant that > > an implementation must be > prepared to > receive fragments with or > without NSH header as this is a > decision > that is left to the > transport encapsulation. This is a > requirement per se! > > > I won't reiterate all the > comments I > have about the current > wording of > > this section. > > > Cheers, Med > > -----Message > d'origine----- De : > Elzur, Uri > > [mailto:uri.elzur@intel.com > > >] > Envoyé > : lundi 25 avril 2016 > 08:30 À : BOUCADAIR > Mohamed IMT/OLN; > Thomas Narten; > sfc@ietf.org > > > Objet : RE: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > Hi Med > > My point is that > Fragmentation is > yet another transport > related > issue > > that > > is beyond the scope of > NSH and > beyond the charter of > the WG, so > it > > doesn't > > really belong in the > draft. We are > providing an advice as > extending the size of > the packet may > lead to fragmentation, but > as you check RFC 7348 > VxLAN, which > my create the same issue, > you'll find it doesn't even > > relate > > to it. > > Thx > > Uri ("Oo-Ree") C: > 949-378-7568 > > > > > -----Original > Message----- From: sfc > > [mailto:sfc-bounces@ietf.org > > >] On > Behalf Of > > mohamed.boucadair@orange.com > > > > Sent: > Sunday, April 24, 2016 > 10:32 PM To: Elzur, Uri > > > >>; > Thomas Narten > > >>; > > sfc@ietf.org > > > Subject: Re: [sfc] WG > last call for > draft-ietf-sfc-nsh-04.txt > > Hi Uri, > > That's another option > that needs to > be discussed/investigated. > I'm > > afraid > > this is not the > rationale adopted in > -04 since it includes some > text > > that > > is far to be sufficient > to ensure > interoperable > implementations. > > BTW, saying that nsh > does not need > to deal with fragmentation > because > > it > > is transport-independent > is not IMHO > a good strategy to adopt > here > > because > > it opens the door for > interoperable > issues, it may lead to > sub-optimal > implementations if the > sfc information is present > only in one > > fragments, > > etc. > > My comments are related > to the > current text in the -04. > This text needs > > to > > be fixed somehow. > > Cheers, Med > > -----Message > d'origine----- De : > Elzur, Uri > > [mailto:uri.elzur@intel.com > > >] > Envoyé : dimanche 24 > avril > 2016 17:36 À : > BOUCADAIR Mohamed > IMT/OLN; Thomas Narten; > sfc@ietf.org > > > Objet : > RE: [sfc] WG last > call for > > draft-ietf-sfc-nsh-04.txt > > Hi Med > > I see no need to > specify the > exact behavior as NSH is > transport > independent i.e. like > NSH interaction with > any other > Transport eh issue of > Fragmentation is to > be dealt in > a way > that matches the > mechanisms > supported by the > Transport used > and do not belong in > the NSH draft > > Thx > > Uri ("Oo-Ree") C: > 949-378-7568 > > > > > -----Original > Message----- From: sfc > > [mailto:sfc-bounces@ietf.org > > >] > On Behalf Of > > mohamed.boucadair@orange.com > > > > > Sent: Thursday, > April 14, > 2016 12:43 AM To: > Thomas Narten > > > >>; > sfc@ietf.org > > > Subject: > Re: [sfc] WG last > call for > > draft-ietf-sfc-nsh-04.txt > > R-, > > In addition to other > pending > issues raised for > this draft, I > would like to raise this > additional one about > Section 6. > > == 6. Fragmentation > Considerations > > NSH and the > associated transport > header are "added" > to the > encapsulated > packet/frame. This > additional information > increases > > the > > size of the packet. > In order > the ensure proper > forwarding of > NSH data, several > options for > handling > fragmentation and > re-assembly exist: > > 1. Jumbo Frames, when > supported, enable > the transport > of NSH > and associated > transport packets > without requiring > fragmentation. > > 2. Path MTU Discovery > [RFC1191]"describes > a technique for > dynamically > discovering the > maximum transmission > unit (MTU) of > > an > > arbitrary internet > path" and can > be utilized to > ensure the > > the > > required packet size > is used. > > 3. [RFC6830] > describes two > schemes for > fragmentation and > re- > > assembly > > in section 5.4. == > > * The text is weak for a > Standard track > document that is > intended to solve > the problem in > > https://tools.ietf.org/html/rfc7498#section- > > 2.12. > > There should be a > clear behavior > to be followed by an > > implementation. > > Further, I would > avoid the use > of words such as "can". > > * The text covers only > fragmentation when > it is induced > by SFC > operations, it does > not discuss > the treatment of a > fragment > when received in an > SFC domain. > IMHO, the draft > should also > specify the behavior > of the > Classifier with > regards to > fragments for the > sake of proper > SFC operation. Applying > classification > policies may > require the > > full packet, not only a > fragment. > > In particular, dedicated > resources should > dedicated for > handling out of > order fragments. > Of course, it is out > of scope > of this document to > describe how > SFs handle fragments. > > * If an SFC header > is prepended > for all fragments, > I'm not > sure there is any > particular > issue at the SFF > level...except > if stripping/adding > context TLVs > depends on the full > packet > (not just fragment). > It is > warranted to > consider a little bit > this point before > declaring there > > is > > no issue. > > > * The text states > "several > options". This may > be interpreted > as if implementing > one of them > is > sufficient...which is not > true. The first two > points > contribute to > minimize the > fragmentation risk, but > fragmentation may > still be > experienced > (e.g., other shims > are prepended > by other nodes for > some other > purposes, nested > nsh, etc.) > > * The first two > points have > nothing to do with > reassembly. > > * The support of > jumbo frames by > a router/device does > not mean > that it can make use > of it. > Appropriate MTU > configuration > should be undertaken > in a > consistent manner > within an SFC > domain. The text > should be > updated to make it > is about > (consistent) MTU > > configuration. > > > * BTW, shouldn't the > text be > reworded to > recommended to > increase the MTU of > **all > nodes** of an > SFC-enabled domain by > at least the length > of SFC > header + transport > header? > > * Bullet 2, how PMTU > discovery > is actually used in this > context? Do you > assume that all > SFC-aware nodes will > issue > such messages > towards other > SFC-aware node, > arbitrary > destination, else? > > * Bullet 2, I would drop > "describes a > technique for > dynamically > discovering the > maximum transmission > unit > (MTU) of an > arbitrary internet > path". > > * Bullet 2, s/ the > the/the. > > * The reference to > the LISP > specification raises > two concerns > and one comment: > > (1) I don't think it > is a good > approach that > fragments induced > by the network are > passed to > their ultimate > destinations as > such > > (stateless). > > IMO, reassembly > should be done > within the SFC domain > (responsible for > fragmentation) > not passed away. (2) > Does the > stateful mode > require all SFC > data plane elements > maintain a > full list of MTU for > the any > SFF/SF instance of > the SFC > > domain? > > > The current text > suggests that > [RFC6830] should be > listed as > normative reference > (not an > informative one). I > would > personally favor > removing the > reference to LISP > (as it is an > Experimental RFC). > > * The security > section of the > draft may be > augmented with > informational > > fragmentation-related pointers to: > e.g., RFC1858 (Security > Considerations for > IP Fragment > Filtering), RFC3128 > (Protection > Against a Variant of > the Tiny > Fragment Attack), > and RFC 4963 > (IPv4 Reassembly > Errors at High > Data Rates). > > Cheers, Med > > -----Message > d'origine----- > De : sfc > > [mailto:sfc-bounces@ietf.org > > >] > De la part de > > mohamed.boucadair@orange.com > > > > > Envoyé : lundi > 11 avril > 2016 13:14 À : > Thomas > Narten; > sfc@ietf.org > > > Objet > : Re: > [sfc] WG last > call for > > draft-ietf-sfc-nsh-04.txt > > Dear Thomas, all, > > As I mentioned > during the > meeting, there > are several > issues > that are not > covered in the > last version of > the draft. I > already provided > examples of > the issues > offline as requested > by Martin. > > Cheers, Med > > -----Message > > d'origine----- De : sfc > > [mailto:sfc-bounces@ietf.org > > >] > De la part > de Thomas Narten > Envoyé : > jeudi 31 mars > 2016 04:48 À : > sfc@ietf.org > > > > > Objet : > [sfc] WG last > call for > > draft-ietf-sfc-nsh-04.txt > > Dear WG: > > This note > begins a WG > last call on > > draft-ietf-sfc-nsh-04.txt > > (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > > > > The editors of the NSH document have indicated > that they have > > addressed > all known > comments and > that there > are no open > issues with > the current > version of > the document. > > Substantive > comments to > the list please, > editorial > comments > can go > directly to the > document > editors. > > We'll also > get a brief > update from > the editors > at next > week's > meeting. If there > are any > remaining issues > with the > document, > raising them > before the > meeting would be > especially > helpful. > > For the > chairs, Thomas > > > _______________________________________________ > sfc mailing > list > sfc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing > list > sfc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing > list sfc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing > > > From nobody Thu Apr 28 10:11:24 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 C694D12B047 for ; Thu, 28 Apr 2016 10:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 M_BZm7-H4urY for ; Thu, 28 Apr 2016 10:11:19 -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 D75C112B031 for ; Thu, 28 Apr 2016 10:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63378; q=dns/txt; s=iport; t=1461863478; x=1463073078; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NIfDxkmdmp4ywgxxgh9+FCiDkr2k2+nQ37augSy08G8=; b=EH+FuMz7Sp9LLHSYBahLZ7yqYXocIBP1gtTs8drF95U+99i1ExJV/yzs A+QKmflGzgkRKgjCs0uS/SzHQYjQsX60LtffEFCetLn2IaoiOrN9maFKb gTs9cIiQ8eUfBtr/GLTBJmu0waoiI14QbQ3+vKhddqEPqV/X6JeUjuub7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgD1QiJX/4MNJK1bA4M4U30GrhSLX?= =?us-ascii?q?gENgXIEFwuFbQKBKTgUAQEBAQEBAWUnhEEBAQEDAQEBARcDSgcLDAQCAQgRAwE?= =?us-ascii?q?BAQEjBAchBgsUCQgCBAENBYgVAwoIDr51DYRLAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQSGIYRLgkGBfCEmhQ8Fh3SGGIUThEAxAYV7gneDLoF2gWeETYMphTSGJIE?= =?us-ascii?q?th14BHgEBQoI2gTVshml/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208";a="98825637" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 17:11:16 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3SHBGo6010705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 17:11:16 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 12:11:15 -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.1104.009; Thu, 28 Apr 2016 12:11:15 -0500 From: "Jim Guichard (jguichar)" To: Joel Halpern Direct , "Andrew G. Malis" Thread-Topic: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLy5gODJbPprtEyKsV065fH5RJ+elnwAgAAtrACAAAwigIAA0eUA///PIYCAAF7oAIAAAPWA///gC4A= Date: Thu, 28 Apr 2016 17:11:15 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> <888c5567-c459-f29f-6f20-02aad39f1f76@joelhalpern.com> In-Reply-To: <888c5567-c459-f29f-6f20-02aad39f1f76@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.77.177] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 17:11:23 -0000 That wording works for me. Paul/Uri, as editors of draft-ietf-sfc-nsh-04, unless there are any objections from the WG or yourselves, can you please make the suggested change to the text? Jim On 4/28/16, 11:05 AM, "Joel Halpern Direct" wrote: >Thanks Andy. That wording would indeed work for me. >Yours, >Joel > >On 4/28/16 11:02 AM, Andrew G. Malis wrote: >> Jim, >> >> The way option 3 is currently worded, there=B9s no indication that this = is >> just an example, and not a direction to use RFC 6830, section 5.4. I >> just had an offline discussion with Joel, and he and I agree that a >> better wording for option 3 would be "Use the fragmentation provided by >> the network overlay mechanics. One example can be found in RFC 6830, >> section 5.4.=B2 >> >> Thanks, >> Andy >> >> On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar) >> > wrote: >> >> Hi Andy, >> >> I think the key point is that NSH !=3D network overlay but rather >> utilizes a network overlay for packet transport between SFC network >> elements. The reference is just an example of how a network overlay >> might deal with fragmentation and is not a suggestion that NSH adopt >> that mechanism but rather makes the point that it can utilize the >> existing network overlay mechanics. >> >> Jim >> >> From: sfc > on >> behalf of "Andrew G. Malis" > > >> Date: Thursday, April 28, 2016 at 8:17 AM >> To: Joel Halpern Direct > > >> Cc: "Elzur, Uri" >, >> "mohamed.boucadair@orange.com " >> > >, "sfc@ietf.org >> " >, Linda >> Dunbar > >> Subject: Re: [sfc] Suggested wording addtion to the Section 6 >> (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt >> >> Joel, >> >> The diagrams in section 6 of RFC 6830 are control plane, not data >> plane. The data plane diagrams are in section 5. >> >> But the overriding question is - without any fields in the NSH >> header to sequence fragments, how can the fragments be correctly >> reassembled? >> >> Cheers, >> Andy >> >> On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct >> > >>wrote: >> >> The LISP header does not have a fragment flag or fragment >> offset. The diagrams in section 6 include the outer >> encapsulating header (the equivalent of the transport header in >> SFC.) Yes, the text is a little hard to follow in this regard. >> The LISP working group is going to be rewriting RFC 6830 as part >> of moving to standards track. >> >> So there is no difference in this regard between NSH and LISP. >> >> Yours, >> Joel >> >> On 4/27/16 7:02 PM, Andrew G. Malis wrote: >> >> Joel et al, >> >> All this talk about fragmentation prompted me to re-read >> section 6 of >> the draft, which recommends (as option 3) using the >> procedures in >> section 5.4 of RFC 6830 (presumably with the =B3NSH header= =B2 >> replacing the >> =B3LISP header=B2 in the description of the procedures in th= at >> section). >> >> So that led me to read that section (and the LISP header >> definition in >> section 5.1), and I see that LISP does fragmentation and >> reassembly >> identically to IPv4, using the Fragment Offset field so that >> fragments >> can be correctly reassembled in the proper order. >> >> However, the NSH Header doesn=B9t have a Fragment Offset fie= ld >> or any >> other way to order the fragments. >> >> So how can the procedures in Section 5.4 of 6830 be used? >> >> Thanks, >> Andy >> >> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> >> >> >> wrote: >> >> Both methods are valid, and both depend upon details of >>the >> underlying packet and the transport. As such, I don't >> see why this >> document benefits from describing them, much less why it >> should mark >> one method as a "should". Implementation details are >> likely to be >> more significant than any bit consumption difference >> between the two >> alternatives. >> >> Yours, >> Joel >> >> >> On 4/27/16 3:40 PM, Linda Dunbar wrote: >> >> I suggest adding the following paragraphs after the >> Bullet 3 of >> the Section 6 Fragmentation Consideration to make >> the process >> more clear and less controversial: >> >> >> -------------------------------- >> >> RFC6830 describes the fragmentation method of >> breaking the >> original packet into two equal sub-frames and >> encapsulating >> [LISP Header + Transport header] to each sub-frame. >> >> If LISP fragmentation [RFC6830 Section 5.4] is used, >> the [SFC >> Header + Transport Header] will be added to each >> half frame (or >> the original data frame). As the Transport Header is >> terminated >> by the next SFF node's tunnel transport layer, the >> combined two >> sub-frames will have two SFC Headers. >> >> Therefore, the fragmentation for NSH encapsulated >> data frame >> should be done completely by the node tunnel >> transport layer, >> which should break the [SFC + original packet] into >> two equal >> sub-frames and each sub-frame being encapsulated >> with its >> respective tunnel header. The next SFF node's >> tunnel transport >> layer should combine the two sub-frames before >> sending to the >> next node. >> >> =20 >>------------------------------------------------------ >> >> >> By the way, there are to typo in the Section 6: >> 3rd line: "In order the" =3D=3D> "In order to" >> Last line of Bullet 2: extra "the" in the "utilized >> to ensure >> the the required packet". >> >> >> Hope it helps. >> >> Linda >> >> >> >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> >> > > >> [mailto:mohamed.boucadair@orange.com >> >> > >] >> Sent: Wednesday, April 27, 2016 12:40 AM >> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; >> sfc@ietf.org >> > >> Subject: RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, all, >> >> Please see inline. >> >> Cheers, >> Med >> >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com >> >> > >] Envoy=E9 : mardi 26 >> avril 2016 19:18 =C0 : Linda Dunbar; BOUCADAIR >>Mohamed >> IMT/OLN; Elzur, >> Uri; sfc@ietf.org >> > Objet : Re: >>[sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> With regard to Transport tunnel fragementation, >> that seems >> an issue >> for the transport protocol. I don't actually >> object to a >> sentence, >> but it does not seem that it will accomplish >> anything. >> >> >> [Med] I would like to see some text added to the >>draft. >> >> >> With regard to packets fragmented by the >>source, I >> completely disagree >> with your assertion. If an SFF were to >> reassemble the >> packets, that >> would be a violation of its job. >> >> >> [Med] I agree with you. >> >> There is no reason for an SFF to >> >> reassemble a packet fragmented by the source. >>The >> classifier may have >> to do some interesting things in order to >> properly classify >> succeeding >> fragments, but that is an implementation issue >> (most commonly >> addressed with virtual reassembly, which doe >> snot delay the >> fragments.) We don't specity that. >> >> >> [Med] Still, the external behavior of the classifier >> needs to be >> clear in the document. I don't find any text in the >> draft saying >> for instance that an NSH header must be present in >>all >> fragments. (There some processing that might be >> needed at the >> SFF to "do its job" with regards to fragments >> (receive out of >> order fragments + forwarding policy on the full >> packet).) >> >> >> If an SF needs to reassemble fragments to do its >> job, that >> is up to >> the SF. Some will need to actually reassemble. >> Some will >> need to >> perform virtual reassembly, and some will >> happily process the >> fragments. I can not see what the NSH document >> could >> possibly mandate. >> >> >> [Med] Fully agree. >> >> >> Yours, >> Joel >> >> On 4/26/16 11:47 AM, Linda Dunbar wrote: >> >> Joel, >> >> I think the document should add the >> description on the >> following two >> fragmentation scenarios: >> >> - Transport tunnel generated fragmentation: >> When a packet >> fragmentation is caused by transport tunnel >> (i.e. various >> encapsulations), the termination point of >> the transport >> tunnel is >> responsible for re-assembling the fragmented >> pieces of >> the packet. >> Since there won't be any SFF nodes in >> between the >> Transport Tunnel, >> the tunnel generated fragmentation does not >> require any >> actions by >> SFF nodes or SF nodes. >> >> >> - Source node generated fragmentation (after >> adding on >> the NSH >> header): When fragmentation has to be >> performed for a >> packet being >> encapsulated with the NSH header, either the >> intermediate SFF nodes >> or the SF nodes have to be able to >> reassemble the >> fragmented pieces. >> >> >> >> >> Cheers, >> >> >> Linda >> >> -----Original Message----- From: Joel M. >>Halpern >> [mailto:jmh@joelhalpern.com >> >> > >] Sent: Tuesday, April 26, >> 2016 10:33 AM >> To: Linda Dunbar; >> mohamed.boucadair@orange.com >> >> > >; Elzur, Uri; >> sfc@ietf.org >> > Subject: Re: >> [sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> Re-reading your note, it is possible that >> you are >> referring only to >> the case of transport generated >> fragmentation of the >> outer packet. >> I had assumed you were not talking about >> that, since the >> resulting >> fragments will not all have NSH headers. As >> with any tunnel >> technology, if the tunnel chooses to >> fragment at its >> layer, then the >> tunnel is responsible for reassembly. That >> would be >> invisible to >> the SFF. >> >> Yours, Joel >> >> On 4/26/16 11:10 AM, Linda Dunbar wrote: >> >> Agree with Med. >> >> Even if each fragment piece of a packet >> with NSH >> header carries the >> NSH header, the intermediate SFF nodes >> still need to >> put together >> all the fragments together before >> passing the whole >> data frame to >> the SF. >> >> Linda >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> >> > >] >> On Behalf Of >> mohamed.boucadair@orange.com >> >> > > Sent: Monday, >> April 25, >> 2016 9:42 AM To: Elzur, Uri; Joel M. >> Halpern; >> sfc@ietf.org >> > Subject: >> Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Re-, >> >> How do you instruct the transport layer >> to ALWAYS >> prepend an NSH >> header even for fragments? Or you don't >> care about that? >> >> Thank you. >> >> Cheers, Med >> >> -----Message d'origine----- De : >> Elzur, Uri >> [mailto:uri.elzur@intel.com >> >> > >] Envoy=E9 : lundi 25 >> avril 2016 16:26 =C0 >> : BOUCADAIR Mohamed IMT/OLN; Joel M. >> Halpern; >> sfc@ietf.org >> > Objet >> : RE: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> Not to repeat my position, but I'll >> do it anyhow >> :-) As NSH is >> *NOT* a transport, dealing with >> fragmentation is >> left to the >> Transport used. >> >> The model I use for NSH, is >> basically similar to >> VXLAN . It is an >> overly. >> >> Thx >> >> Uri ("Oo-Ree") C: 949-378-7568 >> > >> >> >> -----Original Message----- From: sfc >> [mailto:sfc-bounces@ietf.org >> >> > >] >> On Behalf Of >> mohamed.boucadair@orange.com >> >> > > Sent: >> Monday, April 25, >> 2016 7:18 AM To: Joel M. Halpern >> > > >>; >> sfc@ietf.org >> > >> Subject: Re: [sfc] WG last call for >> draft-ietf-sfc-nsh-04.txt >> >> Hi Joel, >> >> Please see inline. >> >> Cheers, Med >> >> -----Message d'origine----- De : >> Joel M. Halpern >> [mailto:jmh@joelhalpern.com >> >> > >] Envoy=E9 : lundi >> 25 avril 2016 15:48 =C0 >> : BOUCADAIR Mohamed IMT/OLN; >> sfc@ietf.org >> > > Objet : Re: [sfc] WG >> last call for >> draft-ietf-sfc-nsh-04.txt >> >> If I am understanding you >> correctly Med, you >> are asking that the >> NSH draft specify how service >> chaining >> should cope with packets >> that have been fragmented? >> >> >> [Med] To be accurate, I'm asking to >> assess >> whether there are >> implications. If there are, then the >> draft >> should be updated >> accordingly. >> >> NSH, and the SFF functionality, >> does not care. >> >> >> [Med] I'm not that sure. Some >>typical >> implications are listed >> below: >> >> * SFF: If the NSH header is present >> only in the >> a fragment but SFF >> didn't maintained a state, >> subsequent fragments >> won't be >> appropriately processed. * SFC-aware >> function: >> if prepending a >> context information depends on the >> full packet, >> not only a >> fragment. >> >> It just does its job. >> >> [Med] which may be disturbed in some >> situations >> as listed in the >> examples above. >> >> Ingress and intermediate >> classifiers may >> cope with fragments in >> any number of ways. >> >> Specifying such is clearly out of >> scope for this >> draft. >> >> [Med] The purpose is not to specify >> the internal >> implementation >> details but the external behavior >>of the >> classifier function when >> it comes to handle fragments. That >> behavior may >> have an incidence >> on SFF, in particular. The purpose >> is not to >> recommend the maximum >> resources to be dedicated to out of >> order >> fragments nor the >> timeout to cache those; these >> considerations are >> of course out of >> scope. Nevertheless, an >> implementation should >> offer a configurable >> parameter so that an operator tweak >> those >> according to its >> context. >> >> I suppose one could write an >> informational >> draft on possible ways >> of coping. The IETF has not >>usually >> published such. >> Service functions have to cope >>with >> fragmented packets just as >> they had to before the advent of >> NSH, so >> describing that is >> clearly not needed here. >> >> >> [Med] The advent of NSH has the >> following >> implications: * it >> exacerbates fragmentation. Handing >> over this >> issue to the >> transport layer may lead to >> interoperability >> issues. * the >> chaining may not be efficient if >> fragments are >> inappropriately >> handled. >> >> Introducing NSH should not degrade >> the overall >> service compared to >> legacy service deployment schemes. >> >> >> Yours, Joel >> >> On 4/25/16 3:00 AM, >> mohamed.boucadair@orange.com >> >> >> > > wrote: >> >> Re-, >> >> I hear you, but my comment >> is that we >> need, as a WG, to decide >> what to >> >> put in the draft. FWIW, I'm >> discussing two >> fragmentation >> issues: >> >> >> (1) Fragmentation that is >> caused by >> prepending an SFC header. >> (2) Handling fragments at >> the ingress of >> an SFC-enabled domain. >> >> Increasing the MTU is for >>sure a >> recommendation is to be >> explicitly >> >> called out in the text (see my >> first message). >> >> >> There are other issues that >> need to be >> discussed, e.g., how to >> deal with >> >> fragments in SFFs/Classifiers? >> >> >> It is also "prudent" to >> check that no >> issues will be experienced >> in SFF >> >> to handle fragments. If an SFC >> header is >> prepended for all >> fragments, I'm not sure there >> >> is any particular issue at >> the SFF >> level, except if >> stripping/adding >> >> context TLVs depends on the full >> packet (not >> just fragment). It >> is warranted to consider a >> little bit this >> point before declaring >> there is no issue. >> >> >> For point (1), declaring >> fragmentation >> out of scope would be >> meant that >> >> an implementation must be >> prepared to >> receive fragments with or >> without NSH header as this is a >> decision >> that is left to the >> transport encapsulation. This >>is a >> requirement per se! >> >> >> I won't reiterate all the >> comments I >> have about the current >> wording of >> >> this section. >> >> >> Cheers, Med >> >> -----Message >> d'origine----- De : >> Elzur, Uri >> >> [mailto:uri.elzur@intel.com >> >> >] >> Envoy=E9 >> : lundi 25 avril 2016 >> 08:30 =C0 : BOUCADAIR >> Mohamed IMT/OLN; >> Thomas Narten; >> sfc@ietf.org >> > > >> Objet : RE: [sfc] WG >> last call for >> =20 >>draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> My point is that >> Fragmentation is >> yet another transport >> related >> issue >> >> that >> >> is beyond the scope of >> NSH and >> beyond the charter of >> the WG, so >> it >> >> doesn't >> >> really belong in the >> draft. We are >> providing an advice as >> extending the size of >> the packet may >> lead to fragmentation, >>but >> as you check RFC 7348 >> VxLAN, which >> my create the same >>issue, >> you'll find it doesn't >>even >> >> relate >> >> to it. >> >> Thx >> >> Uri ("Oo-Ree") C: >> 949-378-7568 >> > > >> >> >> -----Original >> Message----- From: sfc >> >> [mailto:sfc-bounces@ietf.org >> >> >>] On >> Behalf Of >> >> mohamed.boucadair@orange.com >> >> >> > > Sent: >> Sunday, April 24, 2016 >> 10:32 PM To: Elzur, Uri >> > >> >> >>; >> Thomas Narten >> >> > > >>; >> >> sfc@ietf.org >> > > >> Subject: Re: [sfc] WG >> last call for >> =20 >>draft-ietf-sfc-nsh-04.txt >> >> Hi Uri, >> >> That's another option >> that needs to >> be=20 >>discussed/investigated. >> I'm >> >> afraid >> >> this is not the >> rationale adopted in >> -04 since it includes=20 >>some >> text >> >> that >> >> is far to be sufficient >> to ensure >> interoperable >> implementations. >> >> BTW, saying that nsh >> does not need >> to deal with=20 >>fragmentation >> because >> >> it >> >> is transport-independent >> is not IMHO >> a good strategy to adopt >> here >> >> because >> >> it opens the door for >> interoperable >> issues, it may lead to >> sub-optimal >> implementations if the >> sfc information is=20 >>present >> only in one >> >> fragments, >> >> etc. >> >> My comments are related >> to the >> current text in the -04. >> This text needs >> >> to >> >> be fixed somehow. >> >> Cheers, Med >> >> -----Message >> d'origine----- De : >> Elzur, Uri >> >> [mailto:uri.elzur@intel.com >> >> >] >> Envoy=E9 : dimanche = 24 >> avril >> 2016 17:36 =C0 : >> BOUCADAIR Mohamed >> IMT/OLN; Thomas=20 >>Narten; >> sfc@ietf.org >> >> > > Objet : >> RE: [sfc] WG last >> call for >> >> draft-ietf-sfc-nsh-04.txt >> >> Hi Med >> >> I see no need to >> specify the >> exact behavior as=20 >>NSH is >> transport >> independent i.e. like >> NSH interaction with >> any other >> Transport eh issue=20 >>of >> Fragmentation is to >> be dealt in >> a way >> that matches the >> mechanisms >> supported by the >> Transport used >> and do not belong in >> the NSH draft >> >> Thx >> >> Uri ("Oo-Ree") C: >> 949-378-7568 >> > > >> >> >> -----Original >> Message----- From: sfc >> >> [mailto:sfc-bounces@ietf.org >> >> >] >> On Behalf Of >> >> mohamed.boucadair@orange.com >> >> >> > > >> Sent: Thursday, >> April 14, >> 2016 12:43 AM To: >> Thomas Narten >> > >> >> >>; >> sfc@ietf.org >> >> > > Subject: >> Re: [sfc] WG last >> call for >> >> draft-ietf-sfc-nsh-04.txt >> >> R-, >> >> In addition to other >> pending >> issues raised for >> this draft, I >> would like to raise= =20 >>this >> additional one about >> Section 6. >> >> =3D=3D 6. Fragmenta= tion >> Considerations >> >> NSH and the >> associated transport >> header are "added" >> to the >> encapsulated >> packet/frame. This >> additional=20 >>information >> increases >> >> the >> >> size of the packet. >> In order >> the ensure proper >> forwarding of >> NSH data, several >> options for >> handling >> fragmentation and >> re-assembly exist: >> >> 1. Jumbo Frames,=20 >>when >> supported, enable >> the transport >> of NSH >> and associated >> transport packets >> without requiring >> fragmentation. >> >> 2. Path MTU=20 >>Discovery >> [RFC1191]"describes >> a technique for >> dynamically >> discovering the >> maximum transmission >> unit (MTU) of >> >> an >> >> arbitrary internet >> path" and can >> be utilized to >> ensure the >> >> the >> >> required packet size >> is used. >> >> 3. [RFC6830] >> describes two >> schemes for >> fragmentation and >> re- >> >> assembly >> >> in section 5.4. =3D= =3D >> >> * The text is weak=20 >>for a >> Standard track >> document that is >> intended to solve >> the problem in >> >> https://tools.ietf.org/html/rfc7498#section- >> >> 2.12. >> >> There should be a >> clear behavior >> to be followed by an >> >> implementation. >> >> Further, I would >> avoid the use >> of words such as=20 >>"can". >> >> * The text covers=20 >>only >> fragmentation when >> it is induced >> by SFC >> operations, it does >> not discuss >> the treatment of a >> fragment >> when received in an >> SFC domain. >> IMHO, the draft >> should also >> specify the behavior >> of the >> Classifier with >> regards to >> fragments for the >> sake of proper >> SFC operation.=20 >>Applying >> classification >> policies may >> require the >> >> full packet, not only a >> fragment. >> >> In particular,=20 >>dedicated >> resources should >> dedicated for >> handling out of >> order fragments. >> Of course, it is out >> of scope >> of this document to >> describe how >> SFs handle=20 >>fragments. >> >> * If an SFC header >> is prepended >> for all fragments, >> I'm not >> sure there is any >> particular >> issue at the SFF >> level...except >> if stripping/adding >> context TLVs >> depends on the full >> packet >> (not just fragment). >> It is >> warranted to >> consider a little bit >> this point before >> declaring there >> >> is >> >> no issue. >> >> >> * The text states >> "several >> options". This may >> be interpreted >> as if implementing >> one of them >> is >> sufficient...which is not >> true. The first two >> points >> contribute to >> minimize the >> fragmentation risk,= =20 >>but >> fragmentation may >> still be >> experienced >> (e.g., other shims >> are prepended >> by other nodes for >> some other >> purposes, nested >> nsh, etc.) >> >> * The first two >> points have >> nothing to do with >> reassembly. >> >> * The support of >> jumbo frames by >> a router/device does >> not mean >> that it can make use >> of it. >> Appropriate MTU >> configuration >> should be undertaken >> in a >> consistent manner >> within an SFC >> domain. The text >> should be >> updated to make it >> is about >> (consistent) MTU >> >> configuration. >> >> >> * BTW, shouldn't the >> text be >> reworded to >> recommended to >> increase the MTU of >> **all >> nodes** of an >> SFC-enabled domain by >> at least the length >> of SFC >> header + transport >> header? >> >> * Bullet 2, how PMTU >> discovery >> is actually used in= =20 >>this >> context? Do you >> assume that all >> SFC-aware nodes will >> issue >> such messages >> towards other >> SFC-aware node, >> arbitrary >> destination, else? >> >> * Bullet 2, I would= =20 >>drop >> "describes a >> technique for >> dynamically >> discovering the >> maximum transmission >> unit >> (MTU) of an >> arbitrary internet >> path". >> >> * Bullet 2, s/ the >> the/the. >> >> * The reference to >> the LISP >> specification raises >> two concerns >> and one comment: >> >> (1) I don't think it >> is a good >> approach that >> fragments induced >> by the network are >> passed to >> their ultimate >> destinations as >> such >> >> (stateless). >> >> IMO, reassembly >> should be done >> within the SFC=20 >>domain >> (responsible for >> fragmentation) >> not passed away. (2) >> Does the >> stateful mode >> require all SFC >> data plane elements >> maintain a >> full list of MTU for >> the any >> SFF/SF instance of >> the SFC >> >> domain? >> >> >> The current text >> suggests that >> [RFC6830] should be >> listed as >> normative reference >> (not an >> informative one). I >> would >> personally favor >> removing the >> reference to LISP >> (as it is an >> Experimental RFC). >> >> * The security >> section of the >> draft may be >> augmented with >> informational >> >> fragmentation-related pointers to: >> e.g., RFC1858=20 >>(Security >> Considerations for >> IP Fragment >> Filtering), RFC3128 >> (Protection >> Against a Variant of >> the Tiny >> Fragment Attack), >> and RFC 4963 >> (IPv4 Reassembly >> Errors at High >> Data Rates). >> >> Cheers, Med >> >> -----Message >> d'origine----- >> De : sfc >> >> [mailto:sfc-bounces@ietf.org >> >> >] >> De la part de >> >> mohamed.boucadair@orange.com >> >> >> > > >> Envoy=E9 : lundi >> 11 avril >> 2016 13:14 =C0 : >> Thomas >> Narten; >> sfc@ietf.org >> >> > Objet >> : Re: >> [sfc] WG last >> call for >> >> draft-ietf-sfc-nsh-04.txt >> >> Dear Thomas,=20 >>all, >> >> As I mentioned >> during the >> meeting, there >> are several >> issues >> that are not >> covered in the >> last version of >> the draft. I >> already provided >> examples of >> the issues >> offline as requested >> by Martin. >> >> Cheers, Med >> >> -----Message >> >> d'origine----- De : sfc >> >> [mailto:sfc-bounces@ietf.org >> >> >] >> De la part >> de Thomas Narten >> Envoy=E9 : >> jeudi 31 mars >> 2016 04:48=20 >>=C0 : >> sfc@ietf.org >> >> >> > >> Objet : >> [sfc] WG last >> call for >> >> draft-ietf-sfc-nsh-04.txt >> >> Dear WG: >> >> This note >> begins a WG >> last call on >> >> draft-ietf-sfc-nsh-04.txt >> >> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >> >> >> >> The editors of the NSH document have indicated >> that they have >> >> addressed >> all known >> comments and >> that there >> are no open >> issues with >> the current >> version of >> the document. >> >> Substantive >> comments to >> the list=20 >>please, >> editorial >> comments >> can go >> directly to the >> document >> editors. >> >> We'll also >> get a brief >> update from >> the editors >> at next >> week's >> meeting. If there >> are any >> remaining issues >> with the >> document, >> raising them >> before the >> meeting would be >> especially >> helpful. >> >> For the >> chairs, Thomas >> >> >> _______________________________________________ >> sfc mailing >> list >> sfc@ietf.org >> >> > >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing >> list >> sfc@ietf.org >> >> > >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing >> list sfc@ietf.org >> >> > > >> >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> _______________________________________________ >> sfc mailing >> >> >> From nobody Thu Apr 28 10:56:06 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 C8C6D12D8D6 for ; Thu, 28 Apr 2016 10:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 xXRpBn0C9u9I for ; Thu, 28 Apr 2016 10:55:59 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42012D90F for ; Thu, 28 Apr 2016 10:55:59 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 28 Apr 2016 13:55:58 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C2 interface Thread-Index: AdGhdzeqsff0+F4JRSWm8k5GYfJj0Q== Date: Thu, 28 Apr 2016 17:55:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F44097wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] draft-ietf-sfc-control-plane -- C2 interface 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, 28 Apr 2016 17:56:04 -0000 --_000_E8355113905631478EFF04F5AA706E9830F44097wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-= 04#section-3.3.2 the section is: C2: Interface between SFC Control Plane & SFF - There is no mention of being able to instruct the SFF to load-balance an = SFP across multiple (functionally equivalent) SFs This is the service-function-group-name concept in OpenDaylight and in draf= t-penno-sfc-yang-14, as I understand it. Identifying members of a group and identifying a group as a next-hop would = be in the scope of the C2 interface, correct? - Regarding chain (path?) termination, there should be some mention of how = to forward packets per path after the NSH header is removed. For example, it may be that different paths terminate at different physical= interfaces or at different routing tables. This isn't always relevant, but I would expect it to be in the scope of C2,= no? E.g., for IP encapsulation, "if SPI=3D101 and SI=3D251 then terminate to r= outing table T1" Or, e.g., for Ethernet encapsulation "if SPI=3D200 and SI=3D252 then termin= ate to Ethernet interface eth1" David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F44097wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.2

the section is: C2: Interface between SFC Control Pl= ane & SFF

 

- There is no mention of being able to instruct the = SFF to load-balance an SFP across multiple (functionally equivalent) SFs

This is the service-function-group-name concept in O= penDaylight and in draft-penno-sfc-yang-14, as I understand it.<= /p>

Identifying members of a group and identifying a gro= up as a next-hop would be in the scope of the C2 interface, correct?

 

 

- Regarding chain (path?) termination, there should = be some mention of how to forward packets per path after the NSH header is = removed.

For example, it may be that different paths terminat= e at different physical interfaces or at different routing tables.

This isn’t always relevant, but I would expect= it to be in the scope of C2, no?

E.g., for IP encapsulation,  “if SPI=3D10= 1 and SI=3D251 then terminate to routing table T1”

Or, e.g., for Ethernet encapsulation “if SPI= =3D200 and SI=3D252 then terminate to Ethernet interface eth1”

 

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830F44097wtlexchp2sandvi_-- From nobody Thu Apr 28 10:57:33 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 F10B612D926 for ; Thu, 28 Apr 2016 10:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 YogGDkAlUInj for ; Thu, 28 Apr 2016 10:57:30 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7912D92D for ; Thu, 28 Apr 2016 10:57:28 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 28 Apr 2016 13:57:27 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGhd20GlIfr42rfQei+e06aOHat/g== Date: Thu, 28 Apr 2016 17:57:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F440D9wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] draft-ietf-sfc-control-plane -- C3 interface 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, 28 Apr 2016 17:57:32 -0000 --_000_E8355113905631478EFF04F5AA706E9830F440D9wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#secti= on-3.3.3 C3: Interface between SFC Control Plane & SFC-aware SFs Shouldn't information about bidirectional paths be in scope for C3 ? E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: "This interface informs the SFC-aware SF about the method for handling bidi= rectional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping." The alternative, in my opinion, is to standardize on an algorithmic method = for computing bidirectional paths. I'm uneasy about C3 carrying information specific to applications, such as "a threat-detecting SF can periodically send the threat characteristic= s via this interface, such as high probability of threat with packet of a given size." This seems like it should be out of scope of C3. Instead I think there woul= d be an application on top of the controller. Thoughts? In this paragraph, does "context information" mean metadata? If so, can tha= t be made clear that the SFC is being asked to add metadata to the packet? This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. (Because although the statement is that the SF doesn't have an SFF in the n= ode, it actually does have the SFF behavior. So call it what it is, an SFF.= ) Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic to the appropriate SF must be supported. Concretely, each SF must have a unique locator for unambiguous forwarding. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F440D9wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.3

C3: Interface between SFC Control Plane & SFC-aw= are SFs

 

Shouldn’t information about bidirectional path= s be in scope for C3 ?

E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt

Maybe add this paragraph:

“This interface informs the SFC-aware SF about= the method for handling bidirectional paths,

either by conveying the algorithmic method to use, o= r by providing forward/reverse path

mapping.”

The alternative, in my opinion, is to standardize on= an algorithmic method for computing bidirectional paths.

 

 

I’m uneasy about C3 carrying information speci= fic to applications, such as

    “a threat-detecting  SF= can periodically send the threat characteristics via this

      interface, such as high pro= bability of threat with packet of a

      given size.”

This seems like it should be out of scope of C3. Ins= tead I think there would be an application on top of the controller.

Thoughts?

 

 

In this paragraph, does “context information&#= 8221; mean metadata? If so, can that be made clear that the SFC is being as= ked to add metadata to the packet?

=    This interface is also used to instruct an SFC-aware SF about = any

=    context information it needs to supply in the context of a giv= en SFC.

 

 

Regarding this paragraph, I think it would be cleane= r if this behavior actually requires the C2 interface into the SF.

(Because although the statement is that the SF doesn= ’t have an SFF in the node, it actually does have the SFF behavior. S= o call it what it is, an SFF.)

  Multiple SFs may be located within the same ph= ysical node, and no SFF

   is enabled in that same node, means to unambi= guously forward the

   traffic to the appropriate SF must be support= ed.  Concretely, each SF

   must have a unique locator for unambiguous fo= rwarding.

 

 

 

 

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830F440D9wtlexchp2sandvi_-- From nobody Thu Apr 28 11:12: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 7013A12D510 for ; Thu, 28 Apr 2016 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 Mv7ptGzzD45W for ; Thu, 28 Apr 2016 11:12:52 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9F412B047 for ; Thu, 28 Apr 2016 11:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461867173; x=1493403173; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JpZ1KD+/oJW35NMqEoOzZRccnoY3PUEJ6wQSXIV1+3E=; b=xLV2aL8X4Re85JExD11a4CAp6PtfghVZ29zeFffAcqmi37vksRn15BG5 U7sBp1HKeQjQH9TOaQhPzSsJ8Jnvg4n9OCw/OqqlfhdjthgifaqaNvX6N tHDrqd8DHrUeaAbFG404JrMJx6PhDEjOfZPD/KB8ehlEbpOtgG1alOrDI 8=; X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208";a="216235468" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 28 Apr 2016 18:12:52 +0000 Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 28 Apr 2016 11:12:52 -0700 Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1156.000; Thu, 28 Apr 2016 11:12:52 -0700 From: Sunil Vallamkonda To: Linda Dunbar , "sfc@ietf.org" Thread-Topic: Questions to SFC-Metadata-model Thread-Index: AQHRn94+xc2w9iJn1EuQbXESQ+5+m5+frOug Date: Thu, 28 Apr 2016 18:12:52 +0000 Message-ID: <46b013de584a4a898ecb34d32cccd04e@SEAEXCHMBX06.olympus.F5Net.com> References: <1460042865963.25707@F5.com>, , <1460091126273.230@F5.com> <1D15709113D6B34BAE5E128F392059CA01268568BE@blr-exch-1.sandvine.com>, <1460738575691.54747@F5.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CEE6@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657E7CEE6@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Questions to SFC-Metadata-model 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, 28 Apr 2016 18:12:55 -0000 TGluZGEsDQoNCkl0IHdvdWxkIG5vdCBiZSBPT0IgdGhvdWdoIHRoZXJlIGlzIG5vIHJlc3RyaWN0 aW9uIHRvIGJlIHBhcnQgb2YgT09CIG1lc3NhZ2VzIGFsc28gYXMgbmVlZGVkLiANClRoZSBsb2Nh bCBwb2xpY3kgcnVsZXMgYW5kIGNhcGFiaWxpdGllcyB3b3VsZCBkaWN0YXRlIGF0IHJ1biB0aW1l IHdoZW4gYW5kIHdoaWNoIHRoZSBtZXRhZGF0YSBBdHRyaWJ1dGUtVmFsdWUtUGFpcnMgKEFWUHMp IGFuZC9vciBWZW5kb3ItQXR0cmlidXRlLVBhaXJzIChWQVBzKSBpbiBwYWNrZXQocykgZm9yIFBh dGhJRC4gVGhlIENsYXNzaWZpZXIncyBwb2xpY3kgY291bGQgaGF2ZSB0aGUgYWJpbGl0eSB0byBp bmNvcnBvcmF0ZSBhbmQvb3Igb3BlcmF0ZSB3aXRoIG1ldGFkYXRhIGluIGl0cyBydWxlcyB3aGlj aCBkZXBlbmRzIG9uIGltcGxlbWVudGF0aW9uLg0KV2hlbiBTRiBpbnN0YW50aWF0aW9uIGlzIGJ5 IGRpZmZlcmVudCB2ZW5kb3Igc2luY2UgdGhlIENvbnRyb2xsZXIgd291bGQgYmUgYXdhcmUsIHRo ZSBtZXRhZGF0YSBkaWN0aW9uYXJ5IHdvdWxkIHVwZGF0ZWQgYXMgcGFydCBwcm92aXNpb25pbmcg dGhlIFNGLg0KDQoNClRoYW5rIHlvdSwNClN1bmlsLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMaW5kYSBEdW5iYXINClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI2LCAyMDE2IDEwOjA2IEFNDQpU bzogU3VuaWwgVmFsbGFta29uZGEgPHN1bmlsdmtAZjUuY29tPjsgc2ZjQGlldGYub3JnDQpTdWJq ZWN0OiBbc2ZjXSBRdWVzdGlvbnMgdG8gU0ZDLU1ldGFkYXRhLW1vZGVsDQoNClN1bmlsLCANCg0K RG8geW91IHN1Z2dlc3QgdGhhdCB0aGUgbWV0YWRhdGEgY2FycmllZCBieSB0aGUgcGFja2V0cyBu ZWVkIHRvIGNhcnJ5IHRob3NlIE1ldGFkYXRhIGF0dHJpYnV0ZS1WYWx1ZSBwYWlycyAoU2VjdGlv biA0IG9mIHlvdXIgZHJhZnQpPyANCg0KT3IgYXJlIHRob3NlIG1ldGFkYXRhIGF0dHJpYnV0ZSB2 YWx1ZSBkaXN0cmlidXRlZCBieSBvdXQgb2YgYmFuZCBjb250cm9sIHBsYW5lIG1lc3NhZ2VzPyAN Cg0KRG8gYXNzdW1lIHRoYXQgQ2xhc3NpZmllciBpcyBpbmZvcm1lZCBvZiB0aG9zZSBNZXRhZGF0 YSBBdHRyaWJ1dGUgdmFsdWUgcGFpcnM/IFdoYXQgaWYgZGlmZmVyZW50IGluc3RhbnRpYXRpb24g b2YgdGhlIFNGIChieSBkaWZmZXJlbnQgdmVuZG9yKSB3aWxsIGJlIHRyYXZlcnNlZCBieSB0aGUg cGFja2V0PyANCg0KDQpMaW5kYQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VuaWwgVmFsbGFt a29uZGENClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyMSwgMjAxNiAxOjMxIFBNDQpUbzogc2ZjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10gQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0 aW9uIHNjaGVtZXMNCg0KDQpWZW5kb3JzIGFscmVhZHkgc2VlbSB0byBiZSB3b3JraW5nIG9uIHBy b3ByaWV0YXJ5IG1lY2hhbmlzbXMgdG8gc2hhcmUgdGhlIG1ldGFkYXRhIGluIGltcGxlbWVudGF0 aW9ucyB3aGljaCBzZWVtIHRvIGluZmVyIHRoZSBuZWVkIGZvciBhIHN0YW5kYXJkIGZyYW1ld29y ayBmb3IgaW50ZXJvcCBhbmQgc2NhbGUuDQpUaGUgZG9jdW1lbnQgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXZhbGxhbWtvbmRhLXNmYy1tZXRhZGF0YS1tb2RlbC0wMCBwcm9wb3Nl cyBtZXRob2QgdXNpbmcgSUFOQSByZWdpc3RyeSBmb3Igc3VwcG9ydGluZyBib3RoIHRoZSBnZW5l cmljIGFsbG9jYXRpb24gc2NoZW1lcyBhcyBtb2JpbGl0eSwgYnJvYWRiYW5kIGFuZCBvdGhlcnMs IGFuZCB0aGUgdmVuZG9yIHNwZWNpZmljIG9uZXMsIGFzIHRoZXkgZXZvbHZlLg0KDQoNClRoYW5r cywNClN1bmlsLg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBEb2xzb24NClNlbnQ6IEZy aWRheSwgQXByaWwgMTUsIDIwMTYgOTo1MCBBTQ0KVG86IFN1bWFuZHJhIE1hamVlIDxTLk1hamVl QEY1LmNvbT4NCkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBBIHJlcXVlc3Qg Zm9yIE1ldGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcw0KDQpTdW1hbmRyYSwNCg0KPiBJIGFtIGdl bmVyYWxseSBvcHBvc2VkIHRvIHN0YW5kYXJkaXppbmcgbWV0YWRhdGEgYWxsb2NhdGlvbiB0aGlz IGVhcmx5Lg0KDQpSZWZlcnJpbmcgYmFjayB0byBteSBvcmlnaW5hbCBlbWFpbCwgSSBtYWRlIHRo ZSByZXF1ZXN0IHRvIHRob3NlIHdobyBhcmUgcHJvcG9zaW5nIG1ldGFkYXRhIHNjaGVtZXMgaW4g ZHJhZnRzOyBJIGFtIG5vdCBhc2tpbmcgZm9yIGEgZGlyZWN0aW9uIGluZGljYXRpb24gaW4gdGhl IE5TSCBiYXNlIHByb3RvY29sLg0KDQpJbiBlYWNoIG9mIHRoZSBhbGxvY2F0aW9uIHNjaGVtZXMg dGhlcmUgYXJlICJyZXNlcnZlZCIgYml0cyB0aGF0IGNvdWxkIGJlIHVzZWQuDQoNCi1EYXZlDQoN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdW1hbmRyYSBNYWplZSBb bWFpbHRvOlMuTWFqZWVARjUuY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMTUsIDIwMTYgMTI6 NDMgUE0NClRvOiBCb3R0b3JmZiwgUGF1bDsgTmlsYW5qYW4gU2Fya2FyDQpDYzogRGF2ZSBEb2xz b247IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIEEgcmVxdWVzdCBmb3IgTWV0YWRh dGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNCkRhdmUsIFBhdWwgYW5kIE5pbGFuamFuLA0KDQpJIGFt IG5vdCBvcHBvc2VkIHRvIGhhdmluZyBhIGRpcmVjdGlvbiBiaXQgaW4gdGhlIG1ldGFkYXRhLCB5 ZXMgaXQgbWlnaHQgYmVjb21lIG5lY2Vzc2l0eSBpbiBjZXJ0YWluIHNpdHVhdGlvbi4gSSBhbSBu b3Qgc3VyZSBpZiB3ZSBuZWVkIHRoaXMgc2Vuc2Ugb2YgZGlyZWN0aW9uIGZvciBtYWpvcml0eSBv ZiB1c2UgY2FzZXMuDQoNCkkgYW0gZ2VuZXJhbGx5IG9wcG9zZWQgdG8gc3RhbmRhcmRpemluZyBt ZXRhZGF0YSBhbGxvY2F0aW9uIHRoaXMgZWFybHkuDQoNCldoYXQgSSB3b3VsZCByZWFsbHkgbGlr ZSB0byBoYXZlIGEgbWV0YWRhdGEgcmVnaXN0cnkgYW5kIGEgc2NoZW1lIGZvciB0aGF0LiAgDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBCb3R0b3JmZiwg UGF1bCA8cGF1bC5ib3R0b3JmZkBocGUuY29tPg0KU2VudDogRnJpZGF5LCBBcHJpbCA4LCAyMDE2 IDY6MTAgQU0NClRvOiBOaWxhbmphbiBTYXJrYXI7IFN1bWFuZHJhIE1hamVlDQpDYzogRGF2ZSBE b2xzb247IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzZmNdIEEgcmVxdWVzdCBmb3IgTWV0 YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNCkhpIE5pbGFuamFuLCBTdW1hbmRyYSwgRGF2ZToN Cg0KQWdyZWVkLCB0aGUgY2FzZSB3aGVyZSB0aGVyZSBhcmUgdHdvIHBvcnRzIChvciB0d28gdk5J Q3MpLCB0aGVuIHdlIGNhbiB1c2UgdGhlIFNBIChvciBTSVApIHRvIGRldGVybWluZSB0aGUgZGly ZWN0aW9uLg0KDQpUaG91Z2ggdGhpcyBkb2VzIG5vdCB3b3JrIGZvciBhIHNpbmdsZSBhcm1lZCBT RiBJIHN1c3BlY3QgdGhlIFNGcyB3aGljaCBuZWVkIHRvIGZvcm0gcmV2ZXJzZSBwYXRocyBhcmUg ZHVhbCBhcm1lZCB0b2RheS4gSWYgd2Ugc2ltcGx5IHNheSB0aGF0IFNGcyB3aGljaCBuZWVkIHRv IHJldmVyc2UgZGlyZWN0aW9ucyBhbHNvIG5lZWQgdG8gYmUgZHVhbCBhcm1lZCwgdGhlbiB0aGlz IGNvdWxkIGJlIGEgdW5pdmVyc2FsIHNvbHV0aW9uLiBUaGUgb3RoZXIgbmljZSB0aGluZyBhYm91 dCBpdCBpcyB0aGF0IGl0IHdvcmtzIGZvciBtdWx0aS1hcm1lZCBicmFuY2hpbmcgYWxzby4gU28g aWYgSSBoYXZlIGFuIFNGIHdpdGggTiBlZ3Jlc3MgcG9ydHMgKG9yIHZOSUNzKSB0aGVuIHRoZSBT RiBjYW4gYnJhbmNoIE4gd2F5cyBzaW1wbHkgYnkgc2VuZGluZyB0byB0aGUgY29ycmVjdCBlZ3Jl c3MgcG9ydC4gVGhpcyBzZWVtcyBuYXR1cmFsIGZyb20gYW4gU0YgY29kaW5nIHBvaW50IG9mIHZp ZXcuDQoNCkNoZWVycywNCg0KUGF1bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOaWxhbmph biBTYXJrYXINClNlbnQ6IEZyaWRheSwgQXByaWwgMDgsIDIwMTYgMjoxNiBBTQ0KVG86IFN1bWFu ZHJhIE1hamVlIDxTLk1hamVlQEY1LmNvbT4NCkNjOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5k dmluZS5jb20+OyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBBIHJlcXVlc3QgZm9y IE1ldGFkYXRhIGFsbG9jYXRpb24gc2NoZW1lcw0KDQpXaWxsIGEgU0YgZGV2aWNlIGhhdmUgMiBw b3J0cz8gUHJvYmxlbSB3YXMgdG8gZmluZCBhbiAgSVAgcGFja2V0IGRpcmVjdGlvbiBpbiBhIHNp bmdsZSBwb3J0IFNGIGRldmljZS4gSW4gY2FzZSB0aGVyZSBhcmUgMiBwb3J0cywgb25lIGlzIGNv bm5lY3RlZCB0byBzdWJzY3JpYmVycyBhbmQgYW5vdGhlciBpcyBjb25uZWN0ZWQgdG8gaW50ZXJu ZXQsIHRoZW4gdGhlcmUgaXMgbm8gaXNzdWUuDQoNClJlZ2FyZHMsDQpOaWxhbmphbg0KKHNlbnQg ZnJvbSBteSBtb2JpbGUgcGhvbmUpDQoNCk9uIDggQXByIDIwMTYgMTA6MjIsIFN1bWFuZHJhIE1h amVlIDxTLk1hamVlQEY1LmNvbT4gd3JvdGU6DQoNCuKAi0kgdGhpbmsgdGhlIHBhcnQgb2YgdGhl IHByb2JsZW0gbGllcyBpbiB0aGUgZGVmaW5pdGlvbiBvZiBVUCBhbmQgRE9XTi4gU28gbGV0cyB0 YWtlIHNvbWUgdXNlIGNhc2VzLg0KDQoNCmEpIEluIGNhc2Ugb2Ygc2VydmljZSBwcm92aWRlciBt YW55IGZ1bmN0aW9ucyBzaXRzIGF0IHRoZSBib3JkZXIgYmV0d2VlbiBuZXR3b3JrL2ludGVybmV0 ICBhbmQgc3Vic2NyaWJlci91c2VyLiBUeXBpY2FsbHkgdGhlIHR3byBzaWRlcyBvZiB0aGUgYm9y ZGVyIGlzIGRlZmluZWQgYnkgd2F5IG9mIGNvbmZpZ3VyYXRpb24sIHRoaXMgaW50ZXJmYWNlL3R1 bm5lbCBwb2ludCB0byBzdWJzY3JpYmVyIHNpZGUgYW5kIHRoYXQgcG9pbnRzIHRvIHRoZSBpbnRl cm5ldC4gQW55dGhpbmcgaW5ncmVzcyBvbiBzdWJzY3JpYmVyIHNpZGUgaXMgRlJPTSBzdWJzY3Jp YmVyIGFuZCB2aWNlIHZlcnNhLiBUaGUgVVAgb3IgRE9XTiBpcyBub3Qgc28gdXNlZnVsLg0KDQoN CmIpIENvbnNpZGVyIGEgdHlwaWNhbCBjbGllbnQgc2VydmVyLiAgQXNzdW1pbmcgeW91IG1lYW4g VVA6IGNsaWVudCAtPnNlcnZlci9maW5hbCBkZXN0aW5hdGlvbiBhbmQgRE9XTiB0aGUgb3RoZXIg d2F5LiBBIGZsb3cgYXdhcmUgc2VydmljZSB3b3VsZCBoYXZlIHN0YXRlIFNJUC0+RElQIGFzIFVQ IGFuZCBESVAtPlNJUCBhcyBET1dOLiBPdGhlcnMgbGlrZSByb3V0ZXIgZXRjLiBtYXkgbm90IGNh cmUgYXQgYWxsIGFuZCB0aGF0IGlzIGZpbmUuDQoNCg0KSW4gY2FzZSBvZiBzZWN1cml0eSBkZXZp Y2UgdGhlIGluYm91bmQgYW5kIG91dGJvdW5kIChvciB6b25lcykgYXJlIGRlZmluZWQgYnkgY29u ZmlndXJhdGlvbiB0aGF0IGlzIGxvY2FsIHRvIHRoYXQgZW50aXR5LiBTbyBoYXZpbmcgYSBjbGFz c2lmaWVyIHNheSBJTiBvciBPVVQgd291bGQgYmUgd3JvbmcgaW4gdGhhdCBjYXNlLg0KDQoNClN1 bWFuZHJhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBEYXZlIERv bHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgNywgMjAx NiA3OjExIFBNDQpUbzogU3VtYW5kcmEgTWFqZWU7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6 IEEgcmVxdWVzdCBmb3IgTWV0YWRhdGEgYWxsb2NhdGlvbiBzY2hlbWVzDQoNClN1bWFuZHJhIChh bmQgb3RoZXJzIHdobyBoYXZlIHF1ZXN0aW9uZWQgdGhpcyksIFdoYXQgZG8geW91IG1lYW4gYnkg ZGV0ZWN0aW5nIGRpcmVjdGlvbiBmcm9tIHRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0Pw0KSeKAmW0g aGF2aW5nIHRyb3VibGUgdW5kZXJzdGFuZGluZyBob3cgb25lIGNvdWxkIHRlbGwgZnJvbSBhbiBh cmJpdHJhcnkgSVAgcGFja2V0IHdoaWNoIGRpcmVjdGlvbiBpdCBpcyBnb2luZy4NCihVbmxlc3Mg a25vd2luZyB0aGUgSVAgYWRkcmVzcyBhbGxvY2F0aW9uIHNjaGVtZSBpbiB0aGUgaW5uZXIgbmV0 d29ya+KApj8gIFRoYXQgd291bGQgYmUgYXJkdW91cy4pDQoNCkFuZCBwb3NzaWJseSBpbi1ib3Vu ZCwgb3V0LWJvdW5kIGFyZSBiZXR0ZXIgbmFtZXM/DQpJIGRvbuKAmXQgbGlrZSBmb3J3YXJkL3Jl dmVyc2UgYmVjYXVzZSBJIGNhbuKAmXQgZ3Vlc3Mgd2hpY2ggaXMgd2hpY2guDQoNCi1EYXZlDQoN CkZyb206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21dDQpTZW50OiBUaHVy c2RheSwgQXByaWwgMDcsIDIwMTYgMTI6MjcgUE0NClRvOiBEYXZlIERvbHNvbjsgc2ZjQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogQSByZXF1ZXN0IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVt ZXMNCg0KDQrigItEYXZlLA0KDQoNCg0KVGhlIHVzZSBjYXNlIHlvdSBoYXZlIGRlZmluZWQgaXMg c3VwcG9ydGVkIGJ5IG1vc3QgZGV2aWNlcyBieSBiaW5kaW5nIHBvbGljaWVzIGV4cGxpY2l0bHkg b24sDQoNCiAgIGEpIGludGVyZmFjZSBvciBlcXVpdmFsZW50DQoNCiAgIGIpIGZsb3cgZGlyZWN0 aW9uLiBNb3N0IGZsb3cgYXdhcmUgZGV2aWNlcyBoYXMgdG8gZGV0ZWN0IHRvIGFuZCBmcm9tIGNv cnJlY3RseSB0byBkbyBsb3Qgb2YgdGhuZ3MgY29ycmVjdGx5Lg0KDQoNCg0KU28gdGhlIHF1ZXN0 aW9uIGlzIHdoYXQgZG8gd2UgZ2V0IGJ5IGFkZGluZyB0aGlzIGJpdD8gSSBhbSBvcHBvc2VkIHRv IHRoZSB0ZXJtIFVQIGFuZCBET1dOIChmcm9tIHNob3cgcG9pbnQgb2Ygdmlldz8pLCByYXRoZXIg Zm9yd2FyZCBhbmQgcmV2ZXJzZSAoZXZlbiB0aGF0IGlzIGNvbmZ1c2luZykuDQoNCg0KDQpTdW1h bmRyYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2ZjIDxzZmMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9sc29uQHNhbmR2 aW5lLmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDYsIDIwMTYgNzoxMyBBTQ0KVG86IHNm Y0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogW3NmY10gQSByZXF1ZXN0 IGZvciBNZXRhZGF0YSBhbGxvY2F0aW9uIHNjaGVtZXMNCg0KVG8gdGhvc2UgYXV0aG9ycyBvZiBt ZXRhZGF0YSBhbGxvY2F0aW9ucywgSSBoYXZlIGEgcmVxdWVzdC4NCkkgYmVsaWV2ZSBtYW55IHR5 cGVzIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBnb2luZyB0byB3YW50IHRvIGRpc3Rpbmd1aXNo IHVwLWxpbmsgdHJhZmZpYyBmcm9tIGRvd24tbGluayB0cmFmZmljLg0KRS5nLiwgYSBzZWN1cml0 eSBkZXZpY2UgdHJlYXRzIGluLWJvdW5kIHRvIHRoZSBwcm90ZWN0ZWQgZGV2aWNlIGRpZmZlcmVu dGx5IGZyb20gb3V0LWJvdW5kLg0KRS5nLiwgYW4gYWNjb3VudGluZyBzeXN0ZW0gbmVlZHMgdG8g a25vdyB3aGV0aGVyIHRvIGNoYXJnZSB0aGUgc291cmNlIG9yIGRlc3RpbmF0aW9uIG5vZGUuDQoN ClNvIG15IHJlcXVlc3QgaXMgdG8gYWxsb2NhdGUgYSBiaXQgZm9yIHVwLWxpbmsvZG93bi1saW5r IGRpc2NyaW1pbmF0aW9uLg0KSSB0aGluayB0aGUgYWx0ZXJuYXRpdmUgaXMgdG8gY29uZmlndXJl IGVhY2ggU0YgYWJvdXQgZWFjaCBwYXRoIHdoZXRoZXIgaXQgaXMgdXAgb3IgZG93biwgb3IgdG8g dXNlIHNvbWV0aGluZyBsaWtlIGFuIGV2ZW4vb2RkIHBhdGggSUQgc2NoZW1lLg0KDQpEb2VzIGFu eW9uZSBlbHNlIHNlZSB0aGlzIGFzIHVzZWZ1bD8NCg0KSSBiZWxpZXZlIGFsbCBvZiB0aGUgYWxs b2NhdGlvbiBkcmFmdHMgaGF2ZSByZXNlcnZlZCBiaXRzLg0KDQoNCkRhdmlkIERvbHNvbg0KU2Vu aW9yIFNvZnR3YXJlIEFyY2hpdGVjdA0KU2FuZHZpbmUNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpz ZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxp bmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMNCg== From nobody Thu Apr 28 11:43:06 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 685E112D0DD for ; Thu, 28 Apr 2016 11:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 xj1OHVTQIPMF for ; Thu, 28 Apr 2016 11:43:03 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0EC12D17B for ; Thu, 28 Apr 2016 11:43:02 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 28 Apr 2016 14:43:01 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1fSI1yPp+UQ0KhY1xrwASm1p+eIaqAgAGXhUA= Date: Thu, 28 Apr 2016 18:43:01 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F44359wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 18:43:05 -0000 --_000_E8355113905631478EFF04F5AA706E9830F44359wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Further to Jim's points about section 4.10.5, do I read it correctly that t= he SFF can be configured to steer traffic on the basis of these? o Destination MAC address o Source MAC address o VLAN-ID, o Destination IP address o Source IP address o Source port number o Destination port number o DSCP o Packet size, etc., or any combination thereof. This comes totally unexpected to me, thinking that the SFF steers traffic b= ased exclusively on Service Path Identifier and Service Index (SPI/SI), whi= ch oddly aren't in the above list. I can guess that maybe this is about reclassification, but "classification"= isn't mentioned in 4.10.5. Can someone explain? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 10:18 AM To: Martin Stiemerling; sfc@ietf.org Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_E8355113905631478EFF04F5AA706E9830F44359wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Further to Jim’s po= ints about section 4.10.5, do I read it correctly that the SFF can be confi= gured to steer traffic on the basis of these?

   o  Dest= ination MAC address

   o  Sour= ce MAC address

   o  VLAN= -ID,

   o  Dest= ination IP address

   o  Sour= ce IP address

   o  Sour= ce port number

   o  Dest= ination port number

   o  DSCP=

   o  Pack= et size, etc., or any combination thereof.

 <= /p>

This comes totally unexpe= cted to me, thinking that the SFF steers traffic based exclusively on Servi= ce Path Identifier and Service Index (SPI/SI), which oddly aren’t in the above list.

 <= /p>

I can guess that maybe th= is is about reclassification, but “classification” isn’t = mentioned in 4.10.5.

Can someone explain?=

 <= /p>

-Dave

 <= /p>

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; sfc@ietf.org
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Hi Martin & WG:

 

A few comments that I would= like to see addressed in the document before it can move forward to the ne= xt step.

  • Section 2.2 SFC Control Plane Bootstrapping.=

This section is too wishy w= ashy. It makes the statement “this document assumes the SFC control p= lane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

Minor point -> typo in b= ullet point 6 – SFP proxy should read SFC proxy

  • Section 2.3 Coherent Setup of an SFC-enabled Domain=

What does the sentence R= 20;various transport encapsulation schemes and/or variations of SFC header = implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or som= ething else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

  • Section 3.1 Reference Architecture

Second bullet point “= mapping between service function chains and SFPs” - this is a general= comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned only o= nce in the entire document. The architecture is explicit in that the SFP wh= en rendered into the network is an RSP and therefore the SFC control plane = element needs to have information on currently deployed RSPs.

 

Additionally there is no in= terface specified for communication between the SFC Control Plane Element a= nd SF management systems. This is an important aspect as many SF’s may require that SFC information be communicated to their = management systems that will be responsible for communicating directly with= their respective SF’s. 

  • Section 3.1.1. C1: Interface between SFC Control Plane & S= FC Classifier

The sentence “The con= trol plane may instruct the classifier about the initial values of the Serv= ice Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. 

  • Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Pac= kets

This section does not actua= lly provide any meaning or indication of relationship with the SFC Control = Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire= section should be removed from the document.

  • Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP

Figure 2 lists 3 different = SFP-id’s whereas the text mentions only SFP-id #1. Is this simply a t= ypo or are you trying to convey something else ?

 

Further you state that R= 20;the steering policies to a SFF node for service function chain depends o= n if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= ” -  this is an inaccurate statement as the combination of the S= FP-id and service-index determines the forwarding behavior (as specified in= section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

 

Jim

 

 

 

On 4/27/16, 12:29 AM, "= ;sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,=

 

This is the start of the Wo= rking Group Last Call (WGLC) for

 

draft-ietf-sfc-control-plan= e-04.txt

 

The WGLC lasts for 2 weeks = and will end May 11th at 10 pm PDT.

 

Please send your comments a= nd reviews to the sfc@ietf.org list.

 

Regards,<= /p>

 

   Martin (SFC co= -chair)

 

___________________________= ____________________

sfc mailing list=

 

--_000_E8355113905631478EFF04F5AA706E9830F44359wtlexchp2sandvi_-- From nobody Thu Apr 28 11:47: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 9E78112D76A for ; Thu, 28 Apr 2016 11:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.017 X-Spam-Level: X-Spam-Status: No, score=-8.017 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=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 gd-do_nCprBf for ; Thu, 28 Apr 2016 11:47:47 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7872312D7FE for ; Thu, 28 Apr 2016 11:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461869267; x=1493405267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JvfkOMlOw3aMJiU38l4jQlerVW6FUtZ3jj47eRcQ3K4=; b=C+8qEqaQ3kE6cIS2rEUSA6Q2ZvyqFL8SmQmu3Bkr8AHnT7IqeCrx/1uc pm0XqG9tbJcusf5BEC1SxbPB24EoZsQChHrdfS2O3NJbib0kn24iMdZPU u2XRrF5/3e5DTYpLaL6dwPaUbUKsxIUJRj7xwxm8zkiEb2iCKJCzp5ZuU U=; X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208";a="216243145" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 28 Apr 2016 18:47:47 +0000 Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 28 Apr 2016 11:47:46 -0700 Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1156.000; Thu, 28 Apr 2016 11:47:46 -0700 From: Sunil Vallamkonda To: "Paul Quinn (paulq)" , Ron Parker Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfiCTJ8b8qeo0249+QoeHMadZ+HQqWAgAADV4CAAFnsgIAYQhKA Date: Thu, 28 Apr 2016 18:47:46 +0000 Message-ID: <2f48dd8a8c8141b394cef2ff70473b08@SEAEXCHMBX06.olympus.F5Net.com> References: <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@cisco.com> In-Reply-To: <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , Dave Dolson , "sfc@ietf.org" Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 28 Apr 2016 18:47:49 -0000 Paul, Ron, As we see the below exposes the requirement of a specification framework to= address interoperability and scale across domains both for MDType 1 and 2 = metadata. The use case scenarios can be challenging without this making it hard for m= assive deployments and NSH as a pure traffic steering solution while other = solutions used in production today. The semantics document proposal: draft-vallamkonda-sfc-metadata-model-00 pr= ecisely addresses this requirement and eliminates ambiguity with IANA regis= try. It also aligns well with draft-ietf-sfc-control-plane-04.txt, with draft-ie= tf-sfc-nsh-04 and RFC7665. Thank you, Sunil. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, April 12, 2016 6:03 PM To: Ron Parker Cc: Thomas Narten ; sfc@ietf.org; Dave Dolson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Ron, Dave, The draft describes the metadata as opaque, and really NSH is just the enve= lop for it. The same can be said for the TLV as well -- there's no spec in= NSH, not should there be. In both cases, the metadata can/should/(must?) = be define in auxiliary drafts. There are several drafts re: metadata that = can be discussed and eventually standardized. It also bears mentioning tha= t the control plane, today in opensource, defines the type 1 semantics. Th= at schemes works well, and mixed implementations can play together. So, perhaps the best way forward: 1. Agree on the envelop and the use of that envelop 2. As a WG, adopt -->= standardize the opaque data, and the TLVs 3. As a WG, work on more detail= ed of use of the control plane to, when needed, define semantics Thoughts? Thanks, Paul > On Apr 12, 2016, at 3:41 PM, Ron Parker = wrote: >=20 > Dave, >=20 > I, too, have raised this issue on the thread. I think you hit the nail = on the head regarding interoperability, which is the primary reason for hav= ing a specification, at all. My mental model for the type-1 mandatory co= ntext headers is that of a composite 16-byte locally defined scratchpad. = I struggle with having its definition completely undefined in the document = and still making it mandatory. =20 >=20 > Much of the justification offered has been to be friendly to hardware. = Surely hardware needs to know the exact format and meaning of these 16 byte= s. >=20 > Ron >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > Sent: Tuesday, April 12, 2016 3:29 PM > To: Thomas Narten ; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 >=20 > The NSH draft indicates that MD-Type 1 MUST be supported, yet the Mandato= ry Context Header fields are not defined in the document. >=20 > Issues with metadata semantics have been raised various times on this lis= t and in drafts, and never satisfactorily addressed. > Examples: > https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-00.tx > t https://www.ietf.org/archive/id/draft-wang-sfc-md-type-issues-00.txt > https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt > https://mailarchive.ietf.org/arch/msg/sfc/2YvBakDgJ_hjY-BGvgWdcTTUDIs >=20 >=20 > So I don't feel this draft sufficiently explains the MD-Type 1 metadata w= ell enough to explain how one can make an interoperable implementation. >=20 > The draft references metadata allocation drafts, but they have not been a= dopted yet, so (as I understand it) these "works in progress" cannot suppor= t draft-ietf-sfc-nsh. >=20 >=20 > I think it might be acceptable to say that the metadata must be undirecti= onally clonable (or better phrase). > In other words, >=20 > Metadata used in NSH headers must been the condition that > a transport-layer-stateful Service Function can save away > metadata values that it has witnessed. An injected packet can > therefore be assigned a clone of metadata taken from an earlier > packet going in the same direction. For example, a Service Function > can send a TCP packet using metadata cloned from another TCP packet > of the same connection and direction. >=20 > Note that the Service Function need not know the meaning of the > metadata; it just needs to know it is safe to clone in this manner. >=20 >=20 >=20 > Another alternative would be to import one of the metadata allocation sch= emes into this draft as MD-Type 1, and allow IANA to allocate MD-types for = other schemes. >=20 >=20 >=20 > -Dave >=20 >=20 >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten > Sent: Wednesday, March 30, 2016 10:48 PM > To: sfc@ietf.org > Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Dear WG: >=20 > This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://dat= atracker.ietf.org/doc/draft-ietf-sfc-nsh/). >=20 > The editors of the NSH document have indicated that they have addressed a= ll known comments and that there are no open issues with the current versio= n of the document. >=20 > Substantive comments to the list please, editorial comments can go direct= ly to the document editors. >=20 > We'll also get a brief update from the editors at next week's meeting. If= there are any remaining issues with the document, raising them before the = meeting would be especially helpful. >=20 > For the chairs, > Thomas >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Apr 28 11:51:12 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 2A19112D54B for ; Thu, 28 Apr 2016 11:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 4Wej4fbuqijE for ; Thu, 28 Apr 2016 11:51:09 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF8212D53E for ; Thu, 28 Apr 2016 11:51:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F233125096B; Thu, 28 Apr 2016 11:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461869467; bh=oUWkA4dProo90HpYC67lL+P2fKU+H+NUd6RRSfrhPFs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=dUBZqiBUq43VwdR9CZYhPrfe5OnWMgTzoVZlVWWtt3jVxzXINialDJ8kWhUW2Zr86 5PsTx8Q7iglgSc8HFl1jyZIUyJx84/l89CxSw5zuof1FgQdeweGzwugTVIt5vBHTzk gO/ogCRCRPcPImCQDNfDlMW4n+VGJSN+BhFkGyRU= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 0964B2409DB; Thu, 28 Apr 2016 11:51:06 -0700 (PDT) To: Sunil Vallamkonda , "Paul Quinn (paulq)" , Ron Parker References: <14F8542B-9EE1-40DF-8DA2-E6E5048A16A3@cisco.com> <2f48dd8a8c8141b394cef2ff70473b08@SEAEXCHMBX06.olympus.F5Net.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 28 Apr 2016 14:50:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2f48dd8a8c8141b394cef2ff70473b08@SEAEXCHMBX06.olympus.F5Net.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Thomas Narten , "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.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, 28 Apr 2016 18:51:11 -0000 As has been discussed in several contexts, we need (and will have) a registry for MD-2 Type values (as called for in the draft.) I am still unable to see what this framework adds beyond that registry, or where the YANG model would be used. Yours, Joel On 4/28/16 2:47 PM, Sunil Vallamkonda wrote: > Paul, Ron, > > As we see the below exposes the requirement of a specification framework to address interoperability and scale across domains both for MDType 1 and 2 metadata. > The use case scenarios can be challenging without this making it hard for massive deployments and NSH as a pure traffic steering solution while other solutions used in production today. > The semantics document proposal: draft-vallamkonda-sfc-metadata-model-00 precisely addresses this requirement and eliminates ambiguity with IANA registry. > It also aligns well with draft-ietf-sfc-control-plane-04.txt, with draft-ietf-sfc-nsh-04 and RFC7665. > > > Thank you, > Sunil. > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) > Sent: Tuesday, April 12, 2016 6:03 PM > To: Ron Parker > Cc: Thomas Narten ; sfc@ietf.org; Dave Dolson > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > > Ron, Dave, > > The draft describes the metadata as opaque, and really NSH is just the envelop for it. The same can be said for the TLV as well -- there's no spec in NSH, not should there be. In both cases, the metadata can/should/(must?) be define in auxiliary drafts. There are several drafts re: metadata that can be discussed and eventually standardized. It also bears mentioning that the control plane, today in opensource, defines the type 1 semantics. That schemes works well, and mixed implementations can play together. > > So, perhaps the best way forward: > > 1. Agree on the envelop and the use of that envelop 2. As a WG, adopt --> standardize the opaque data, and the TLVs 3. As a WG, work on more detailed of use of the control plane to, when needed, define semantics > > Thoughts? > > Thanks, > Paul > > >> On Apr 12, 2016, at 3:41 PM, Ron Parker wrote: >> >> Dave, >> >> I, too, have raised this issue on the thread. I think you hit the nail on the head regarding interoperability, which is the primary reason for having a specification, at all. My mental model for the type-1 mandatory context headers is that of a composite 16-byte locally defined scratchpad. I struggle with having its definition completely undefined in the document and still making it mandatory. >> >> Much of the justification offered has been to be friendly to hardware. Surely hardware needs to know the exact format and meaning of these 16 bytes. >> >> Ron >> >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >> Sent: Tuesday, April 12, 2016 3:29 PM >> To: Thomas Narten ; sfc@ietf.org >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> >> The NSH draft indicates that MD-Type 1 MUST be supported, yet the Mandatory Context Header fields are not defined in the document. >> >> Issues with metadata semantics have been raised various times on this list and in drafts, and never satisfactorily addressed. >> Examples: >> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-00.tx >> t https://www.ietf.org/archive/id/draft-wang-sfc-md-type-issues-00.txt >> https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt >> https://mailarchive.ietf.org/arch/msg/sfc/2YvBakDgJ_hjY-BGvgWdcTTUDIs >> >> >> So I don't feel this draft sufficiently explains the MD-Type 1 metadata well enough to explain how one can make an interoperable implementation. >> >> The draft references metadata allocation drafts, but they have not been adopted yet, so (as I understand it) these "works in progress" cannot support draft-ietf-sfc-nsh. >> >> >> I think it might be acceptable to say that the metadata must be undirectionally clonable (or better phrase). >> In other words, >> >> Metadata used in NSH headers must been the condition that >> a transport-layer-stateful Service Function can save away >> metadata values that it has witnessed. An injected packet can >> therefore be assigned a clone of metadata taken from an earlier >> packet going in the same direction. For example, a Service Function >> can send a TCP packet using metadata cloned from another TCP packet >> of the same connection and direction. >> >> Note that the Service Function need not know the meaning of the >> metadata; it just needs to know it is safe to clone in this manner. >> >> >> >> Another alternative would be to import one of the metadata allocation schemes into this draft as MD-Type 1, and allow IANA to allocate MD-types for other schemes. >> >> >> >> -Dave >> >> >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten >> Sent: Wednesday, March 30, 2016 10:48 PM >> To: sfc@ietf.org >> Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >> >> Dear WG: >> >> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >> >> The editors of the NSH document have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. >> >> Substantive comments to the list please, editorial comments can go directly to the document editors. >> >> We'll also get a brief update from the editors at next week's meeting. If there are any remaining issues with the document, raising them before the meeting would be especially helpful. >> >> For the chairs, >> Thomas >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Apr 28 11:54: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 36EFA12D51E for ; Thu, 28 Apr 2016 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.016 X-Spam-Level: X-Spam-Status: No, score=-8.016 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 yJNPYCn_pzZN for ; Thu, 28 Apr 2016 11:54:34 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1945212D0DD for ; Thu, 28 Apr 2016 11:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461869675; x=1493405675; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fxh49aUhT4IZKtY70Q1Pyec32HIURkdsg24rvqwKdKA=; b=OmzQOpNLwGxb86GRh/D+c6jtnaB9piQ0nh8GJVhilzI4ZzhVRIGYr/WE 7RiRUpRTY5w9WyvfltVhaXSmifYmBVoScRdCKtz7OeA7NoR0d6BIZuNIY DJmU8+yn7MoMiKxJLP2ntUzih+3xtxKr4GPwrMu8L9JACzEtV44E1ELlN g=; X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208,217";a="215415533" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 28 Apr 2016 18:54:33 +0000 Received: from SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 28 Apr 2016 11:54:32 -0700 Received: from SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a]) by SEAEXCHMBX06.olympus.F5Net.com ([fe80::b921:c8e9:b9b2:3e8a%12]) with mapi id 15.00.1156.000; Thu, 28 Apr 2016 11:54:32 -0700 From: Sunil Vallamkonda To: "Jim Guichard (jguichar)" , "Andrew G. Malis" , Joel Halpern Direct Thread-Topic: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLy1NwdBMc0D4UalW6unQUylS5+euAMAgAAtrACAAAwigIAA0eUAgAASMoD//+WxMA== Date: Thu, 28 Apr 2016 18:54:32 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_a320cf42a7c64ca2a7b5438043174908SEAEXCHMBX06olympusF5Ne_" MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 18:54:39 -0000 --_000_a320cf42a7c64ca2a7b5438043174908SEAEXCHMBX06olympusF5Ne_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim, I agree, the confusion being NSH treated as a network overlay. Would it be possible for the document to have wording on this ? This could also clarify interpretations how NSH to be used with ARP, DHCP a= nd encapsulations. Thank you, Sunil From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, April 28, 2016 6:23 AM To: Andrew G. Malis ; Joel Halpern Direct Cc: Elzur, Uri ; mohamed.boucadair@orange.com; sfc@iet= f.org; Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentatio= n Consideration) of the draft-ietf-sfc-nsh-04.txt Hi Andy, I think the key point is that NSH !=3D network overlay but rather utilizes = a network overlay for packet transport between SFC network elements. The re= ference is just an example of how a network overlay might deal with fragmen= tation and is not a suggestion that NSH adopt that mechanism but rather mak= es the point that it can utilize the existing network overlay mechanics. Jim From: sfc > on behalf of = "Andrew G. Malis" > Date: Thursday, April 28, 2016 at 8:17 AM To: Joel Halpern Direct > Cc: "Elzur, Uri" >, "mohame= d.boucadair@orange.com" >, "sfc@ietf.org" >, Linda Dunbar > Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentatio= n Consideration) of the draft-ietf-sfc-nsh-04.txt Joel, The diagrams in section 6 of RFC 6830 are control plane, not data plane. Th= e data plane diagrams are in section 5. But the overriding question is - without any fields in the NSH header to se= quence fragments, how can the fragments be correctly reassembled? Cheers, Andy On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct > wrote: The LISP header does not have a fragment flag or fragment offset. The diag= rams in section 6 include the outer encapsulating header (the equivalent of= the transport header in SFC.) Yes, the text is a little hard to follow in= this regard. The LISP working group is going to be rewriting RFC 6830 as = part of moving to standards track. So there is no difference in this regard between NSH and LISP. Yours, Joel On 4/27/16 7:02 PM, Andrew G. Malis wrote: Joel et al, All this talk about fragmentation prompted me to re-read section 6 of the draft, which recommends (as option 3) using the procedures in section 5.4 of RFC 6830 (presumably with the "NSH header" replacing the "LISP header" in the description of the procedures in that section). So that led me to read that section (and the LISP header definition in section 5.1), and I see that LISP does fragmentation and reassembly identically to IPv4, using the Fragment Offset field so that fragments can be correctly reassembled in the proper order. However, the NSH Header doesn't have a Fragment Offset field or any other way to order the fragments. So how can the procedures in Section 5.4 of 6830 be used? Thanks, Andy On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> wrote: Both methods are valid, and both depend upon details of the underlying packet and the transport. As such, I don't see why this document benefits from describing them, much less why it should mark one method as a "should". Implementation details are likely to be more significant than any bit consumption difference between the two alternatives. Yours, Joel On 4/27/16 3:40 PM, Linda Dunbar wrote: I suggest adding the following paragraphs after the Bullet 3 of the Section 6 Fragmentation Consideration to make the process more clear and less controversial: -------------------------------- RFC6830 describes the fragmentation method of breaking the original packet into two equal sub-frames and encapsulating [LISP Header + Transport header] to each sub-frame. If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Transport Header] will be added to each half frame (or the original data frame). As the Transport Header is terminated by the next SFF node's tunnel transport layer, the combined two sub-frames will have two SFC Headers. Therefore, the fragmentation for NSH encapsulated data frame should be done completely by the node tunnel transport layer, which should break the [SFC + original packet] into two equal sub-frames and each sub-frame being encapsulated with its respective tunnel header. The next SFF node's tunnel transport layer should combine the two sub-frames before sending to the next node. ------------------------------------------------------ By the way, there are to typo in the Section 6: 3rd line: "In order the" =3D=3D> "In order to" Last line of Bullet 2: extra "the" in the "utilized to ensure the the required packet". Hope it helps. Linda -----Original Message----- From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com >] Sent: Wednesday, April 27, 2016 12:40 AM To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, all, Please see inline. Cheers, Med -----Message d'origine----- De : Joel M. Halpern [mailto:jmh@joelhalpern.com >] Envoy= =E9 : mardi 26 avril 2016 19:18 =C0 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur, Uri; sfc@ietf.org > Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt With regard to Transport tunnel fragementation, that seems an issue for the transport protocol. I don't actually object to a sentence, but it does not seem that it will accomplish anything. [Med] I would like to see some text added to the draft. With regard to packets fragmented by the source, I completely disagree with your assertion. If an SFF were to reassemble the packets, that would be a violation of its job. [Med] I agree with you. There is no reason for an SFF to reassemble a packet fragmented by the source. The classifier may have to do some interesting things in order to properly classify succeeding fragments, but that is an implementation issue (most commonly addressed with virtual reassembly, which doe snot delay the fragments.) We don't specity that. [Med] Still, the external behavior of the classifier needs to be clear in the document. I don't find any text in the draft saying for instance that an NSH header must be present in all fragments. (There some processing that might be needed at the SFF to "do its job" with regards to fragments (receive out of order fragments + forwarding policy on the full packet).) If an SF needs to reassemble fragments to do its job, that is up to the SF. Some will need to actually reassemble. Some will need to perform virtual reassembly, and some will happily process the fragments. I can not see what the NSH document could possibly mandate. [Med] Fully agree. Yours, Joel On 4/26/16 11:47 AM, Linda Dunbar wrote: Joel, I think the document should add the description on the following two fragmentation scenarios: - Transport tunnel generated fragmentation: When a packet fragmentation is caused by transport tunnel (i.e. various encapsulations), the termination point of the transport tunnel is responsible for re-assembling the fragmented pieces of the packet. Since there won't be any SFF nodes in between the Transport Tunnel, the tunnel generated fragmentation does not require any actions by SFF nodes or SF nodes. - Source node generated fragmentation (after adding on the NSH header): When fragmentation has to be performed for a packet being encapsulated with the NSH header, either the intermediate SFF nodes or the SF nodes have to be able to reassemble the fragmented pieces. Cheers, Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com >] S= ent: Tuesday, April 26, 2016 10:33 AM To: Linda Dunbar; mohamed.boucadair@orange.com >; Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-reading your note, it is possible that you are referring only to the case of transport generated fragmentation of the outer packet. I had assumed you were not talking about that, since the resulting fragments will not all have NSH headers. As with any tunne= l technology, if the tunnel chooses to fragment at its layer, then the tunnel is responsible for reassembly. That would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: Agree with Med. Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-, How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that= ? Thank you. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a transport, dealing with fragmentation is left to the Transport used. The model I use for NSH, is basically similar to VXLAN . It is an overly. Thx Uri ("Oo-Ree") C: 949-378-7568 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 7:18 AM To: Joel M. Halpern >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, Please see inline. Cheers, Med -----Message d'origine----- De : Joel M. Halper= n [mailto:jmh@joelhalpern.com >] Envoy=E9 : lundi 25 avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Obje= t : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt If I am understanding you correctly Med, you are asking that the NSH draft specify how service chaining should cope with packets that have been fragmented? [Med] To be accurate, I'm asking to assess whether there are implications. If there are, then the draft should be updated accordingly. NSH, and the SFF functionality, does not care. [Med] I'm not that sure. Some typical implications are listed below: * SFF: If the NSH header is present only in the a fragment but SFF didn't maintained a state, subsequent fragments won't be appropriately processed. * SFC-aware function: if prepending a context information depends on the full packet, not only a fragment. It just does its job. [Med] which may be disturbed in some situations as listed in the examples above. Ingress and intermediate classifiers may cope with fragments in any number of ways. Specifying such is clearly out of scope for this draft. [Med] The purpose is not to specify the internal implementation details but the external behavior of the classifier function when it comes to handle fragments. That behavior may have an incidence on SFF, in particular. The purpose is not to recommend the maximum resources to be dedicated to out of order fragments nor the timeout to cache those; these considerations are of course out of scope. Nevertheless, an implementation should offer a configurable parameter so that an operator tweak those according to its context. I suppose one could write an informational draft on possible ways of coping. The IETF has not usually published such. Service functions have to cope with fragmented packets just as they had to before the advent of NSH, so describing that is clearly not needed here. [Med] The advent of NSH has the following implications: * it exacerbates fragmentation. Handing over this issue to the transport layer may lead to interoperability issues. * the chaining may not be efficient if fragments are inappropriately handled. Introducing NSH should not degrade the overall service compared to legacy service deployment schemes. Yours, Joel On 4/25/16 3:00 AM, mohamed.boucadair@orange.com > wrote: Re-, I hear you, but my comment is that we need, as a WG, to decide what to put in the draft. FWIW, I'm discussing two fragmentation issues: (1) Fragmentation that is caused by prepending an SFC header. (2) Handling fragments at the ingress of an SFC-enabled domain. Increasing the MTU is for sure a recommendation is to be explicitly called out in the text (see my first message). There are other issues that need to be discussed, e.g., how to deal with fragments in SFFs/Classifiers? It is also "prudent" to check that no issues will be experienced in SFF to handle fragments. If an SFC header is prepended for all fragments, I'm not sure there is any particular issue at the SFF level, except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. For point (1), declaring fragmentation out of scope would be meant that an implementation must be prepared to receive fragments with or without NSH header as this is a decision that is left to the transport encapsulation. This is a requirement per se! I won't reiterate all the comments I have about the current wording of this section. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : lundi 25 avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med My point is that Fragmentation is yet another transport related issue that is beyond the scope of NSH and beyond the charter of the WG, so it doesn't really belong in the draft. We are providing an advice as extending the size of the packet may lead to fragmentation, but as you check RFC 7348 VxLAN, which my create the same issue, you'll find it doesn't even relate to it. Thx Uri ("Oo-Ree") C: 949-378-7568 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Sunday, April 24, 2016 10:32 PM To: Elzur, Uri >>; Thomas Narten >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Uri, That's another option that needs to be discussed/investigated. I'm afraid this is not the rationale adopted in -04 since it includes some text that is far to be sufficient to ensure interoperable implementations. BTW, saying that nsh does not need to deal with fragmentation because it is transport-independent is not IMHO a good strategy to adopt here because it opens the door for interoperable issues, it may lead to sub-optimal implementations if the sfc information is present only in one fragments, etc. My comments are related to the current text in the -04. This text needs to be fixed somehow. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : dimanche 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med I see no need to specify the exact behavior as NSH is transport independent i.e. like NSH interaction with any other Transport eh issue of Fragmentation is to be dealt in a way that matches the mechanisms supported by the Transport used and do not belong in the NSH draft Thx Uri ("Oo-Ree") C: 949-378-7568 = > -----Original Message----- From: sf= c [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Thursday, April 14, 2016 12:43 AM To: Thomas Narten >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt R-, In addition to other pending issues raised for this draft, I would like to raise this additional one about Section 6. =3D=3D 6. Fragmentation Considerat= ions NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. In order the ensure proper forwarding of NSH data, several options for handling fragmentation and re-assembly exist: 1. Jumbo Frames, when supported, enable the transport of NSH and associated transport packets without requiring fragmentation. 2. Path MTU Discovery [RFC1191]"describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path" and can be utilized to ensure the the required packet size is used. 3. [RFC6830] describes two schemes for fragmentation and re- assembly in section 5.4. =3D=3D * The text is weak for a Standard track document that is intended to solve the problem in https://tools.ietf.org/html/rfc7498= #section- 2.12. There should be a clear behavior to be followed by an implementation. Further, I would avoid the use of words such as "can". * The text covers only fragmentation when it is induced by SFC operations, it does not discuss the treatment of a fragment when received in an SFC domain. IMHO, the draft should also specify the behavior of the Classifier with regards to fragments for the sake of proper SFC operation. Applying classification policies may require the full packet, not only a fragment. In particular, dedicated resources should dedicated for handling out of order fragments. Of course, it is out of scope of this document to describe how SFs handle fragments. * If an SFC header is prepended for all fragments, I'm not sure there is any particular issue at the SFF level...except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. * The text states "several options". This may be interpreted as if implementing one of them is sufficient...which is not true. The first two points contribute to minimize the fragmentation risk, but fragmentation may still be experienced (e.g., other shims are prepended by other nodes for some other purposes, nested nsh, etc.) * The first two points have nothing to do with reassembly. * The support of jumbo frames by a router/device does not mean that it can make use of it. Appropriate MTU configuration should be undertaken in a consistent manner within an SFC domain. The text should be updated to make it is about (consistent) MTU configuration. * BTW, shouldn't the text be reworded to recommended to increase the MTU of **all nodes** of an SFC-enabled domain by at least the length of SFC header + transport header? * Bullet 2, how PMTU discovery is actually used in this context? Do you assume that all SFC-aware nodes will issue such messages towards other SFC-aware node, arbitrary destination, else? * Bullet 2, I would drop "describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path". * Bullet 2, s/ the the/the. * The reference to the LISP specification raises two concerns and one comment: (1) I don't think it is a good approach that fragments induced by the network are passed to their ultimate destinations as such (stateless). IMO, reassembly should be done within the SFC domain (responsible for fragmentation) not passed away. (2) Does the stateful mode require all SFC data plane elements maintain a full list of MTU for the any SFF/SF instance of the SFC domain? The current text suggests that [RFC6830] should be listed as normative reference (not an informative one). I would personally favor removing the reference to LISP (as it is an Experimental RFC). * The security section of the draft may be augmented with informational fragmentation-related pointers to: e.g., RFC1858 (Security Considerations for IP Fragment Filtering), RFC3128 (Protection Against a Variant of the Tiny Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High Data Rates). Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org >] De la part de mohamed.boucadair@orange.com > Envoy=E9 : lundi 11 avril 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org > Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear Thomas, all, As I mentioned during the meeting, there are several issues that are not covered in the last version of the draft. I already provided examples of the issues offline as requested by Martin. Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.or= g >] De la part de Thomas Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org > Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear WG: This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datatracker.ietf.o= rg/doc/draft-ietf-sfc-nsh/). The editors of the NSH document have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. Substantive comments to the list please, editorial comments can go directly to the document editors. We'll also get a brief update from the editors at next week's meeting. If there are any remaining issues with the document, raising them before the meeting would be especially helpful. For the chairs, Thomas ___________________________= ____________________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailma= n/listinfo/sfc _______________________________= ________________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailman/li= stinfo/sfc ___________________________________= ____________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailman/listin= fo/sfc _______________________________________= ________ sfc mailing --_000_a320cf42a7c64ca2a7b5438043174908SEAEXCHMBX06olympusF5Ne_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jim,

 

I agree, the confusion being NSH trea= ted as a network overlay.

Would it be possible for the document= to have wording on this ?

This could also clarify interpretatio= ns how NSH to be used with ARP, DHCP and encapsulations.<= /p>

 

 

Thank you,

Sunil

 

From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, April 28, 2016 6:23 AM
To: Andrew G. Malis <agmalis@gmail.com>; Joel Halpern Direct &= lt;jmh.direct@joelhalpern.com>
Cc: Elzur, Uri <uri.elzur@intel.com>; mohamed.boucadair@orange= .com; sfc@ietf.org; Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragm= entation Consideration) of the draft-ietf-sfc-nsh-04.txt<= /p>

 

Hi Andy,

 

I think the key point is that NSH !=3D = network overlay but rather utilizes a network overlay for packe= t transport between SFC network elements. The reference is just an example of how a network overlay might deal with fragmentation = and is not a suggestion that NSH adopt that mechanism but rather makes the = point that it can utilize the existing network overlay mechanics. 

 

Jim

 

From: sfc <sfc= -bounces@ietf.org> on behalf of "Andrew G. Malis" <agmalis@gmail.com>
Date: Thursday, April 28, 2016 at 8:17 AM
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: "Elzur, Uri" <uri.elzur@intel.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "sfc@ietf.org" <sfc@ietf.org>, Linda Dunbar <= ;linda.dunbar@huawei.com>=
Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragm= entation Consideration) of the draft-ietf-sfc-nsh-04.txt<= /p>

 

Joel,

 

The diagrams in section 6 of RFC 6830 a= re control plane, not data plane. The data plane diagrams are in section 5.=

 

But the overriding question is - withou= t any fields in the NSH header to sequence fragments, how can the fragments= be correctly reassembled?

 

Cheers,

Andy

 

On Wed, Apr 27, 2016 at 7:46 PM, Joel H= alpern Direct <jmh.direct@joelhalpern.com> wrote:

The LISP header does not have a fragmen= t flag or fragment offset.  The diagrams in section 6 include the oute= r encapsulating header (the equivalent of the transport header in SFC.)  Yes, the text is a little hard to follow in this reg= ard.  The LISP working group is going to be rewriting RFC 6830 as part= of moving to standards track.

So there is no difference in this regard between NSH and LISP.

Yours,
Joel

On 4/27/16 7:02 PM, Andrew G. Malis wrote:

Joel et al,

All this talk about fragmentation prompted me to re-read section 6 of
the draft, which recommends (as option 3) using the procedures in
section 5.4 of RFC 6830 (presumably with the “NSH header” repla= cing the
“LISP header” in the description of the procedures in that sect= ion).

So that led me to read that section (and the LISP header definition in
section 5.1), and I see that LISP does fragmentation and reassembly
identically to IPv4, using the Fragment Offset field so that fragments
can be correctly reassembled in the proper order.

However, the NSH Header doesn’t have a Fragment Offset field or any other way to order the fragments.

So how can the procedures in Section 5.4 of 6830 be used?

Thanks,
Andy

On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

    Both methods are valid, and both depend upon details of the     underlying packet and the transport.  As such, I don't s= ee why this
    document benefits from describing them, much less why it shou= ld mark
    one method as a "should".  Implementation deta= ils are likely to be
    more significant than any bit consumption difference between = the two
    alternatives.

    Yours,
    Joel


    On 4/27/16 3:40 PM, Linda Dunbar wrote:

        I suggest adding the following paragraphs after= the Bullet 3 of
        the Section 6 Fragmentation Consideration to ma= ke the process
        more clear and less controversial:


        --------------------------------

        RFC6830 describes the fragmentation method of b= reaking the
        original packet into two equal sub-frames and e= ncapsulating
        [LISP Header + Transport header] to each su= b-frame.

        If LISP fragmentation [RFC6830 Section 5.4] is = used, the [SFC
        Header + Transport Header] will be added to= each half frame (or
        the original data frame). As the Transport Head= er is terminated
        by the next SFF node's tunnel transport layer, = the combined two
        sub-frames will have two SFC Headers.

        Therefore, the fragmentation for NSH encapsulat= ed data frame
        should be done completely by the node tunnel tr= ansport layer,
        which should break the [SFC + original pack= et] into two equal
        sub-frames and each sub-frame being encapsulate= d with its
        respective tunnel header.  The next SFF no= de's tunnel transport
        layer should combine the two sub-frames before = sending to the
        next node.

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


        By the way, there are to typo in the Section 6:=
        3rd line: "In order the" =3D=3D> &= quot;In order to"
        Last line of Bullet 2: extra "the" in= the "utilized to ensure
        the the required packet".


        Hope it helps.

        Linda



        -----Original Message-----
        From: mohamed.boucadair@orange.com
        <mailto:mohamed.boucadair@orange.com>
        [mailto:mohamed.boucadair@orange.com
        <mailto:mohamed.boucadair@orange.com>]
        Sent: Wednesday, April 27, 2016 12:40 AM
        To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; = sfc@ietf.org
        <mailto:sfc@ietf.org>
        Subject: RE: [sfc] WG last call for draft-ietf-= sfc-nsh-04.txt

        Hi Joel, all,

        Please see inline.

        Cheers,
        Med

            -----Message d'origine-----
            De : Joel M. Halpern [mailto:jmh@joelhalpern.com
            <mailto:jmh@joelhalpern.com>] Envoy=E9 : = mardi 26
            avril 2016 19:18 =C0 : Linda Dunb= ar; BOUCADAIR Mohamed
            IMT/OLN; Elzur,
            Uri; sfc@ietf.org <mailto:sfc@ietf.org> Objet : Re: [sfc] WG
            last call for
            draft-ietf-sfc-nsh-04.txt

            With regard to Transport tunnel f= ragementation, that seems
            an issue
            for the transport protocol. = I don't actually object to a
            sentence,
            but it does not seem that it will= accomplish anything.


        [Med] I would like to see some text added to th= e draft.


            With regard to packets fragmented= by the source, I
            completely disagree
            with your assertion.  If an = SFF were to reassemble the
            packets, that
            would be a violation of its job.<= br>

        [Med] I agree with you.

          There is no reason for an SFF to

            reassemble a packet fragmented by= the source.  The
            classifier may have
            to do some interesting things in = order to properly classify
            succeeding
            fragments, but that is an impleme= ntation issue (most commonly
            addressed with virtual reassembly= , which doe snot delay the
            fragments.)  We don't specit= y that.


        [Med] Still, the external behavior of the class= ifier needs to be
        clear in the document. I don't find any text in= the draft saying
        for instance that an NSH header must be present= in all
        fragments. (There some processing that might be= needed at the
        SFF to "do its job" with regards to f= ragments (receive out of
        order fragments + forwarding policy on the = full packet).)


            If an SF needs to reassemble frag= ments to do its job, that
            is up to
            the SF.  Some will need to a= ctually reassemble.  Some will
            need to
            perform virtual reassembly, and s= ome will happily process the
            fragments.  I can not see wh= at the NSH document could
            possibly mandate.


        [Med] Fully agree.


            Yours,
            Joel

            On 4/26/16 11:47 AM, Linda Dunbar= wrote:

                Joel,

                I think the documen= t should add the description on the
                following two
                fragmentation scena= rios:

                - Transport tunnel = generated fragmentation: When a packet
                fragmentation is ca= used by transport tunnel (i.e. various
                encapsulations), th= e termination point of the transport
                tunnel is
                responsible for re-= assembling the fragmented pieces of
                the packet.
                Since there won't b= e any SFF nodes in between the
                Transport Tunnel,                 the tunnel generate= d fragmentation does not require any
                actions by
                SFF nodes or SF nod= es.


                - Source node gener= ated fragmentation (after adding on
                the NSH
                header): When fragm= entation has to be performed for a
                packet being
                encapsulated with t= he NSH header, either the
                intermediate SFF no= des
                or the SF nodes hav= e to be able to reassemble the
                fragmented pieces.<= br>



                Cheers,


                Linda

                -----Original Messa= ge----- From: Joel M. Halpern
                [mailto:jmh@joelhalpern.com
                <mailto:jmh@joelhalpern.com&g= t;] Sent: Tuesday, April 26,
                2016 10:33 AM
                To: Linda Dunbar; <= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com
                <mailto:mohamed.boucadai= r@orange.com>; Elzur, Uri;
                sfc@ietf.org <mailto:sfc@ietf.org> Subject: Re: [sfc] W= G
                last call for
                draft-ietf-sfc-nsh-= 04.txt

                Re-reading your not= e, it is possible that you are
                referring only to                 the case of transpo= rt generated fragmentation of the
                outer packet.
                I had assumed you w= ere not talking about that, since the
                resulting
                fragments will not = all have NSH headers.  As with any tunnel
                technology, if the = tunnel chooses to fragment at its
                layer, then the
                tunnel is responsib= le for reassembly.  That would be
                invisible to
                the SFF.

                Yours, Joel

                On 4/26/16 11:10 AM= , Linda Dunbar wrote:

                    Agree= with Med.

                    Even = if each fragment piece of a packet with NSH
                    heade= r carries the
                    NSH h= eader, the intermediate SFF nodes still need to
                    put t= ogether
                    all t= he fragments together before passing the whole
                    data = frame to
                    the S= F.

                    Linda=

                    -----= Original Message----- From: sfc
                    [mail= to:sfc-bounces@ie= tf.org
                    <m= ailto:sfc-bounces= @ietf.org>]
                    On Be= half Of mohamed.boucadair@orange.com
                    <m= ailto:moh= amed.boucadair@orange.com> Sent: Monday,
                    April= 25,
                    2016 = 9:42 AM To: Elzur, Uri; Joel M. Halpern;
                    sfc@ietf.org <mailto:sfc@ietf.org> Subjec= t:
                    Re: [= sfc] WG last call for draft-ietf-sfc-nsh-04.txt

                    Re-,<= br>
                    How d= o you instruct the transport layer to ALWAYS
                    prepe= nd an NSH
                    heade= r even for fragments? Or you don't care about that?

                    Thank= you.

                    Cheer= s, Med

                     = ;   -----Message d'origine----- De : Elzur, Uri
                     = ;   [mailto:u= ri.elzur@intel.com
                     = ;   <mailto:uri.elzur@intel.com>] Envoy=E9 : lundi 25
                     = ;   avril 2016 16:26 =C0
                     = ;   : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;
                     = ;   sfc@ietf.org= <mailto:sfc@ietf.org<= /a>> Objet
                     = ;   : RE: [sfc] WG last call for
                     = ;   draft-ietf-sfc-nsh-04.txt

                     = ;   Hi Med

                     = ;   Not to repeat my position, but I'll do it anyhow
                     = ;   :-) As NSH is
                     = ;   *NOT* a transport, dealing with fragmentation is
                     = ;   left to the
                     = ;   Transport used.

                     = ;   The model I use for NSH, is basically similar to
                     = ;   VXLAN . It is an
                     = ;   overly.

                     = ;   Thx

                     = ;   Uri ("Oo-Ree") C: 949-378-7568 <tel:949= -378-7568>


                     = ;   -----Original Message----- From: sfc
                     = ;   [mailto:= sfc-bounces@ietf.org
                     = ;   <mailto:sfc-bounces@ietf.org>]
                     = ;   On Behalf Of mohamed.boucadair@orange.com
                     = ;   <mailto:mohamed.boucadair@orange.com> Sent:
                     = ;   Monday, April 25,
                     = ;   2016 7:18 AM To: Joel M. Halpern
                     = ;   <jmh@j= oelhalpern.com <mailto:jmh@joelhalpern.com>>;
                     = ;   sfc@ietf.org= <mailto:sfc@ietf.org<= /a>>
                     = ;   Subject: Re: [sfc] WG last call for
                     = ;   draft-ietf-sfc-nsh-04.txt

                     = ;   Hi Joel,

                     = ;   Please see inline.

                     = ;   Cheers, Med

                     = ;       -----Message d'origine----- De : Joel M. Halpern
                     = ;       [mailto:jmh@joelhalpern.com
                     = ;       <mailto:jmh@joelhalpern.com>] Envoy=E9 : lundi
                     = ;       25 avril 2016 15:48 =C0
                     = ;       : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
                     = ;       <mailto:sfc@ietf.org> Objet : Re: [sfc] WG
                     = ;       last call for draft-ietf-sfc-nsh-04.txt

                     = ;       If I am understanding you correctly Med, you
                     = ;       are asking that the
                     = ;       NSH draft specify how service chaining
                     = ;       should cope with packets
                     = ;       that have been fragmented?


                     = ;   [Med] To be accurate, I'm asking to assess
                     = ;   whether there are
                     = ;   implications. If there are, then the draft
                     = ;   should be updated
                     = ;   accordingly.

                     = ;       NSH, and the SFF functionality, does not care.


                     = ;   [Med] I'm not that sure. Some typical
                     = ;   implications are listed
                     = ;   below:

                     = ;   * SFF: If the NSH header is present only in the
                     = ;   a fragment but SFF
                     = ;   didn't maintained a state, subsequent fragments
                     = ;   won't be
                     = ;   appropriately processed. * SFC-aware function:
                     = ;   if prepending a
                     = ;   context information depends on the full packet,
                     = ;   not only a
                     = ;   fragment.

                     = ;   It just does its job.

                     = ;   [Med] which may be disturbed in some situations
                     = ;   as listed in the
                     = ;   examples above.

                     = ;       Ingress and intermediate classifiers may
                     = ;       cope with fragments in
                     = ;       any number of ways.

                     = ;   Specifying such is clearly out of scope for this
                     = ;   draft.

                     = ;   [Med] The purpose is not to specify the internal
                     = ;   implementation
                     = ;   details but the external behavior of the
                     = ;   classifier function when
                     = ;   it comes to handle fragments. That behavior may
                     = ;   have an incidence
                     = ;   on SFF, in particular. The purpose is not to
                     = ;   recommend the maximum
                     = ;   resources to be dedicated to out of order
                     = ;   fragments nor the
                     = ;   timeout to cache those; these considerations are
                     = ;   of course out of
                     = ;   scope. Nevertheless, an implementation should
                     = ;   offer a configurable
                     = ;   parameter so that an operator tweak those
                     = ;   according to its
                     = ;   context.

                     = ;       I suppose one could write an informational
                     = ;       draft on possible ways
                     = ;       of coping.  The IETF has not usually
                     = ;       published such.
                     = ;       Service functions have to cope with
                     = ;       fragmented packets just as
                     = ;       they had to before the advent of NSH, so
                     = ;       describing that is
                     = ;       clearly not needed here.


                     = ;   [Med] The advent of NSH has the following
                     = ;   implications: * it
                     = ;   exacerbates fragmentation. Handing over this
                     = ;   issue to the
                     = ;   transport layer may lead to interoperability
                     = ;   issues. * the
                     = ;   chaining may not be efficient if fragments are
                     = ;   inappropriately
                     = ;   handled.

                     = ;   Introducing NSH should not degrade the overall
                     = ;   service compared to
                     = ;   legacy service deployment schemes.


                     = ;       Yours, Joel

                     = ;       On 4/25/16 3:00 AM,
                     = ;       mohamed.boucadair@orange.com
                     = ;       <mailto:mohamed.boucadair@orange.com> wrote:

                     = ;           Re-,

                     = ;           I hear you, but my comment is that we<= br>                      = ;           need, as a WG, to decide
                     = ;           what to

                     = ;       put in the draft. FWIW, I'm discussing two
                     = ;       fragmentation
                     = ;       issues:


                     = ;           (1) Fragmentation that is caused by                      = ;           prepending an SFC header.
                     = ;           (2) Handling fragments at the ingress = of
                     = ;           an SFC-enabled domain.

                     = ;           Increasing the MTU is for sure a
                     = ;           recommendation is to be
                     = ;           explicitly

                     = ;       called out in the text (see my first message).


                     = ;           There are other issues that need to be=
                     = ;           discussed, e.g., how to
                     = ;           deal with

                     = ;       fragments in SFFs/Classifiers?


                     = ;           It is also "prudent" to chec= k that no
                     = ;           issues will be experienced
                     = ;           in SFF

                     = ;       to handle fragments. If an SFC header is
                     = ;       prepended for all
                     = ;       fragments, I'm not sure there

                     = ;           is any particular issue at the SFF
                     = ;           level, except if
                     = ;           stripping/adding

                     = ;       context TLVs depends on the full packet (not
                     = ;       just fragment). It
                     = ;       is warranted to consider a little bit this
                     = ;       point before declaring
                     = ;       there is no issue.


                     = ;           For point (1), declaring fragmentation=
                     = ;           out of scope would be
                     = ;           meant that

                     = ;       an implementation must be prepared to
                     = ;       receive fragments with or
                     = ;       without NSH header as this is a decision
                     = ;       that is left to the
                     = ;       transport encapsulation. This is a
                     = ;       requirement per se!


                     = ;           I won't reiterate all the comments I                      = ;           have about the current
                     = ;           wording of

                     = ;       this section.


                     = ;           Cheers, Med

                     = ;               -----Message d'origine--= --- De :
                     = ;               Elzur, Uri
                     = ;               [mailto:uri.elzur@intel.com
                     = ;               <mailto:uri.elzur@intel.com>] En= voy=E9
                     = ;               : lundi 25 avril 2016                      = ;               08:30 =C0 : BOUCADAIR Mo= hamed IMT/OLN;
                     = ;               Thomas Narten;
                     = ;               sfc@ietf.org <mailto:sfc@ietf.org>
                     = ;               Objet : RE: [sfc] WG las= t call for
                     = ;               draft-ietf-sfc-nsh-04.tx= t

                     = ;               Hi Med

                     = ;               My point is that Fragmen= tation is
                     = ;               yet another transport re= lated
                     = ;               issue

                     = ;       that

                     = ;               is beyond the scope of N= SH and
                     = ;               beyond the charter of th= e WG, so
                     = ;               it

                     = ;       doesn't

                     = ;               really belong in the dra= ft. We are
                     = ;               providing an advice as                      = ;               extending the size of th= e packet may
                     = ;               lead to fragmentation, b= ut
                     = ;               as you check RFC 7348 Vx= LAN, which
                     = ;               my create the same issue= ,
                     = ;               you'll find it doesn't e= ven

                     = ;       relate

                     = ;               to it.

                     = ;               Thx

                     = ;               Uri ("Oo-Ree")= C: 949-378-7568
                     = ;               <tel:949-378-7568>


                     = ;               -----Original Message---= -- From: sfc
                     = ;               [mailto:sfc-bounces@ietf.org
                     = ;               <mailto:sfc-bounces@ietf.org>] = On
                     = ;               Behalf Of
                     = ;               mohamed.boucadair@orange.com
                     = ;               <mailto:mohamed.boucadair@oran= ge.com> Sent:
                     = ;               Sunday, April 24, 2016                      = ;               10:32 PM To: Elzur, Uri<= br>                      = ;               <uri.elzur@intel.com
                     = ;               <mailto:uri.elzur@intel.com>>= ;
                     = ;               Thomas Narten

                     = ;       <narten@us.ibm.com <mailto:narten@us.ibm.com>>;

                     = ;               sfc@ietf.org <mailto:sfc@ietf.org>
                     = ;               Subject: Re: [sfc] WG la= st call for
                     = ;               draft-ietf-sfc-nsh-04.tx= t

                     = ;               Hi Uri,

                     = ;               That's another option th= at needs to
                     = ;               be discussed/investigate= d.
                     = ;               I'm

                     = ;       afraid

                     = ;               this is not the rational= e adopted in
                     = ;               -04 since it includes so= me
                     = ;               text

                     = ;       that

                     = ;               is far to be sufficient = to ensure
                     = ;               interoperable
                     = ;               implementations.

                     = ;               BTW, saying that nsh doe= s not need
                     = ;               to deal with fragmentati= on
                     = ;               because

                     = ;       it

                     = ;               is transport-independent= is not IMHO
                     = ;               a good strategy to adopt=
                     = ;               here

                     = ;       because

                     = ;               it opens the door for in= teroperable
                     = ;               issues, it may lead to                      = ;               sub-optimal implementati= ons if the
                     = ;               sfc information is prese= nt
                     = ;               only in one

                     = ;       fragments,

                     = ;               etc.

                     = ;               My comments are related = to the
                     = ;               current text in the -04.=
                     = ;               This text needs

                     = ;       to

                     = ;               be fixed somehow.

                     = ;               Cheers, Med

                     = ;                   -----Messa= ge d'origine----- De :
                     = ;                   Elzur, Uri=
                     = ;                   [mailto:uri.elzur@intel.com<= /a>
                     = ;                   <mailto= :uri.elzur@intel.c= om>]
                     = ;                   Envoy=E9 := dimanche 24 avril
                     = ;                   2016 17:36= =C0 : BOUCADAIR Mohamed
                     = ;                   IMT/OLN; T= homas Narten;
                     = ;                   sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org> Obj= et :
                     = ;                   RE: [sfc] = WG last call for
                     = ;                   draft-ietf= -sfc-nsh-04.txt

                     = ;                   Hi Med

                     = ;                   I see no n= eed to specify the
                     = ;                   exact beha= vior as NSH is
                     = ;                   transport = independent i.e. like
                     = ;                   NSH intera= ction with any other
                     = ;                   Transport = eh issue of
                     = ;                   Fragmentat= ion is to be dealt in
                     = ;                   a way
                     = ;                   that match= es the mechanisms
                     = ;                   supported = by the Transport used
                     = ;                   and do not= belong in the NSH draft

                     = ;                   Thx

                     = ;                   Uri ("= ;Oo-Ree") C: 949-378-7568
                     = ;                   <tel:949-378-7568>


                     = ;                   -----Origi= nal Message----- From: sfc
                     = ;                   [mailto:sfc-bounces@ietf.or= g
                     = ;                   <mailto= :sfc-bounces@ietf= .org>]
                     = ;                   On Behalf = Of
                     = ;                   mohamed.boucadair@orange.com
                     = ;                   <mailto= :mohamed.= boucadair@orange.com>
                     = ;                   Sent: Thur= sday, April 14,
                     = ;                   2016 12:43= AM To: Thomas Narten
                     = ;                   <narten@us.ibm.com
                     = ;                   <mailto= :narten@us.ibm.com>>;
                     = ;                   sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org> Sub= ject:
                     = ;                   Re: [sfc] = WG last call for
                     = ;                   draft-ietf= -sfc-nsh-04.txt

                     = ;                   R-,

                     = ;                   In additio= n to other pending
                     = ;                   issues rai= sed for this draft, I
                     = ;                   would like= to raise this
                     = ;                   additional= one about Section 6.

                     = ;                   =3D=3D 6.&= nbsp; Fragmentation Considerations

                     = ;                   NSH and th= e associated transport
                     = ;                   header are= "added" to the
                     = ;                   encapsulat= ed packet/frame.  This
                     = ;                   additional= information
                     = ;                   increases<= br>
                     = ;       the

                     = ;                   size of th= e packet.  In order
                     = ;                   the ensure= proper forwarding of
                     = ;                   NSH data, = several options for
                     = ;                   handling f= ragmentation and
                     = ;                   re-assembl= y exist:

                     = ;                   1.  J= umbo Frames, when
                     = ;                   supported,= enable the transport
                     = ;                   of NSH
                     = ;                   and associ= ated transport packets
                     = ;                   without re= quiring
                     = ;                   fragmentat= ion.

                     = ;                   2.  P= ath MTU Discovery
                     = ;                   [RFC1191]&= quot;describes a technique for
                     = ;                   dynamicall= y discovering the
                     = ;                   maximum tr= ansmission unit (MTU) of

                     = ;       an

                     = ;                   arbitrary = internet path" and can
                     = ;                   be utilize= d to ensure the

                     = ;   the

                     = ;                   required p= acket size is used.

                     = ;                   3.  [= RFC6830] describes two
                     = ;                   schemes fo= r fragmentation and
                     = ;                   re-

                     = ;       assembly

                     = ;                   in section= 5.4. =3D=3D

                     = ;                   * The text= is weak for a
                     = ;                   Standard t= rack document that is
                     = ;                   intended t= o solve the problem in
                     = ;                   https://tools.ietf.org/html/rfc7498#section-

                     = ;   2.12.

                     = ;                   There shou= ld be a clear behavior
                     = ;                   to be foll= owed by an

                     = ;   implementation.

                     = ;                   Further, I= would avoid the use
                     = ;                   of words s= uch as "can".

                     = ;                   * The text= covers only
                     = ;                   fragmentat= ion when it is induced
                     = ;                   by SFC
                     = ;                   operations= , it does not discuss
                     = ;                   the treatm= ent of a fragment
                     = ;                   when recei= ved in an SFC domain.
                     = ;                   IMHO, the = draft should also
                     = ;                   specify th= e behavior of the
                     = ;                   Classifier= with regards to
                     = ;                   fragments = for the sake of proper
                     = ;                   SFC operat= ion. Applying
                     = ;                   classifica= tion policies may
                     = ;                   require th= e

                     = ;               full packet, not only a = fragment.

                     = ;                   In particu= lar, dedicated
                     = ;                   resources = should dedicated for
                     = ;                   handling o= ut of order fragments.
                     = ;                   Of course,= it is out of scope
                     = ;                   of this do= cument to describe how
                     = ;                   SFs handle= fragments.

                     = ;                   * If an SF= C header is prepended
                     = ;                   for all fr= agments, I'm not
                     = ;                   sure there= is any particular
                     = ;                   issue at t= he SFF level...except
                     = ;                   if strippi= ng/adding context TLVs
                     = ;                   depends on= the full packet
                     = ;                   (not just = fragment). It is
                     = ;                   warranted = to consider a little bit
                     = ;                   this point= before declaring there

                     = ;       is

                     = ;               no issue.


                     = ;                   * The text= states "several
                     = ;                   options&qu= ot;. This may be interpreted
                     = ;                   as if impl= ementing one of them
                     = ;                   is suffici= ent...which is not
                     = ;                   true. The = first two points
                     = ;                   contribute= to minimize the
                     = ;                   fragmentat= ion risk, but
                     = ;                   fragmentat= ion may still be
                     = ;                   experience= d
                     = ;                   (e.g., oth= er shims are prepended
                     = ;                   by other n= odes for some other
                     = ;                   purposes, = nested nsh, etc.)

                     = ;                   * The firs= t two points have
                     = ;                   nothing to= do with reassembly.

                     = ;                   * The supp= ort of jumbo frames by
                     = ;                   a router/d= evice does not mean
                     = ;                   that it ca= n make use of it.
                     = ;                   Appropriat= e MTU configuration
                     = ;                   should be = undertaken in a
                     = ;                   consistent= manner within an SFC
                     = ;                   domain. Th= e text should be
                     = ;                   updated to= make it is about
                     = ;                   (consisten= t) MTU

                     = ;   configuration.


                     = ;                   * BTW, sho= uldn't the text be
                     = ;                   reworded t= o recommended to
                     = ;                   increase t= he MTU of **all
                     = ;                   nodes** of= an SFC-enabled domain by
                     = ;                   at least t= he length of SFC
                     = ;                   header = 3; transport header?

                     = ;                   * Bullet 2= , how PMTU discovery
                     = ;                   is actuall= y used in this
                     = ;                   context? D= o you assume that all
                     = ;                   SFC-aware = nodes will issue
                     = ;                   such messa= ges towards other
                     = ;                   SFC-aware = node, arbitrary
                     = ;                   destinatio= n, else?

                     = ;                   * Bullet 2= , I would drop
                     = ;                   "desc= ribes a technique for
                     = ;                   dynamicall= y discovering the
                     = ;                   maximum tr= ansmission unit
                     = ;                   (MTU) of a= n arbitrary internet
                     = ;                   path"= .

                     = ;                   * Bullet 2= , s/ the the/the.

                     = ;                   * The refe= rence to the LISP
                     = ;                   specificat= ion raises two concerns
                     = ;                   and one co= mment:

                     = ;                   (1) I don'= t think it is a good
                     = ;                   approach t= hat fragments induced
                     = ;                   by the net= work are passed to
                     = ;                   their ulti= mate destinations as
                     = ;                   such

                     = ;   (stateless).

                     = ;                   IMO, reass= embly should be done
                     = ;                   within the= SFC domain
                     = ;                   (responsib= le for fragmentation)
                     = ;                   not passed= away. (2) Does the
                     = ;                   stateful m= ode require all SFC
                     = ;                   data plane= elements maintain a
                     = ;                   full list = of MTU for the any
                     = ;                   SFF/SF ins= tance of the SFC

                     = ;               domain?


                     = ;                   The curren= t text suggests that
                     = ;                   [RFC6830] = should be listed as
                     = ;                   normative = reference (not an
                     = ;                   informativ= e one). I would
                     = ;                   personally= favor removing the
                     = ;                   reference = to LISP (as it is an
                     = ;                   Experiment= al RFC).

                     = ;                   * The secu= rity section of the
                     = ;                   draft may = be augmented with
                     = ;                   informatio= nal
                     = ;                   fragmentat= ion-related pointers to:
                     = ;                   e.g., RFC1= 858 (Security
                     = ;                   Considerat= ions for IP Fragment
                     = ;                   Filtering)= , RFC3128 (Protection
                     = ;                   Against a = Variant of the Tiny
                     = ;                   Fragment A= ttack), and RFC 4963
                     = ;                   (IPv4 Reas= sembly Errors at High
                     = ;                   Data Rates= ).

                     = ;                   Cheers, Me= d

                     = ;                     &nb= sp; -----Message d'origine-----
                     = ;                     &nb= sp; De : sfc
                     = ;                     &nb= sp; [mailto:sfc-b= ounces@ietf.org
                     = ;                     &nb= sp; <mailto:sf= c-bounces@ietf.org>]
                     = ;                     &nb= sp; De la part de
                     = ;                     &nb= sp; mohamed.boucadair@orange.com
                     = ;                     &nb= sp; <mailto:mohamed.boucadair@orange.com>
                     = ;                     &nb= sp; Envoy=E9 : lundi 11 avril
                     = ;                     &nb= sp; 2016 13:14 =C0 : Thomas
                     = ;                     &nb= sp; Narten; sfc@ietf.org
                     = ;                     &nb= sp; <mailto:sfc@ietf.o= rg> Objet
                     = ;                     &nb= sp; : Re:
                     = ;                     &nb= sp; [sfc] WG last call for
                     = ;                     &nb= sp; draft-ietf-sfc-nsh-04.txt

                     = ;                     &nb= sp; Dear Thomas, all,

                     = ;                     &nb= sp; As I mentioned during the
                     = ;                     &nb= sp; meeting, there are several
                     = ;                     &nb= sp; issues
                     = ;                     &nb= sp; that are not covered in the
                     = ;                     &nb= sp; last version of the draft. I
                     = ;                     &nb= sp; already provided examples of
                     = ;                     &nb= sp; the issues offline as requested
                     = ;                     &nb= sp; by Martin.

                     = ;                     &nb= sp; Cheers, Med

                     = ;                     &nb= sp;     -----Message
                     = ;                     &nb= sp;     d'origine----- De : sfc
                     = ;                     &nb= sp;     [mailto:sfc-bounces@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc-bounces@ietf.org>]
                     = ;                     &nb= sp;     De la part de Thomas Narten
                     = ;                     &nb= sp;     Envoy=E9 : jeudi 31 mars
                     = ;                     &nb= sp;     2016 04:48 =C0 :
                     = ;                     &nb= sp;     sfc@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc@ietf.org>
                     = ;                     &nb= sp;     Objet : [sfc] WG last
                     = ;                     &nb= sp;     call for
                     = ;                     &nb= sp;     draft-ietf-sfc-nsh-04.txt

                     = ;                     &nb= sp;     Dear WG:

                     = ;                     &nb= sp;     This note begins a WG
                     = ;                     &nb= sp;     last call on
                     = ;                     &nb= sp;     draft-ietf-sfc-nsh-04.txt
                     = ;                     &nb= sp;     (https://datatracker.ietf.org/doc/draft-ietf-sfc-= nsh/).



            The editors of the NSH document h= ave indicated that they have

                     = ;                     &nb= sp;     addressed all known
                     = ;                     &nb= sp;     comments and that there
                     = ;                     &nb= sp;     are no open
                     = ;                     &nb= sp;     issues with the current
                     = ;                     &nb= sp;     version of the document.

                     = ;                     &nb= sp;     Substantive comments to
                     = ;                     &nb= sp;     the list please,
                     = ;                     &nb= sp;     editorial comments
                     = ;                     &nb= sp;     can go directly to the
                     = ;                     &nb= sp;     document editors.

                     = ;                     &nb= sp;     We'll also get a brief
                     = ;                     &nb= sp;     update from the editors
                     = ;                     &nb= sp;     at next
                     = ;                     &nb= sp;     week's meeting. If there
                     = ;                     &nb= sp;     are any remaining issues
                     = ;                     &nb= sp;     with the
                     = ;                     &nb= sp;     document, raising them
                     = ;                     &nb= sp;     before the meeting would be
                     = ;                     &nb= sp;     especially helpful.

                     = ;                     &nb= sp;     For the chairs, Thomas

                     = ;                     &nb= sp;     _______________________________________________
                     = ;                     &nb= sp;     sfc mailing
                     = ;                     &nb= sp;     list sfc@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc@ietf.org>
                     = ;                     &nb= sp;     https://www.ietf.org/mailman/listinfo/sfc


                     = ;                     &nb= sp; _______________________________________________
                     = ;                     &nb= sp; sfc mailing
                     = ;                     &nb= sp; list sfc@ietf.org
                     = ;                     &nb= sp; <mailto:sfc@ietf.o= rg>
                     = ;                     &nb= sp; https://www.ietf.org/mailman/listinfo/sfc


                     = ;                   __________= _____________________________________
                     = ;                   sfc mailin= g
                     = ;                   list sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org>
                     = ;                   https://www.ietf.org/mailman/listinfo/sfc


                     = ;               ________________________= _______________________
                     = ;               sfc mailing

 

--_000_a320cf42a7c64ca2a7b5438043174908SEAEXCHMBX06olympusF5Ne_-- From nobody Thu Apr 28 12:02: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 877F012D54B for ; Thu, 28 Apr 2016 12:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.016 X-Spam-Level: X-Spam-Status: No, score=-8.016 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.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 jrHUp1V6nYvZ for ; Thu, 28 Apr 2016 12:02:36 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE8C12D53D for ; Thu, 28 Apr 2016 12:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1461870157; x=1493406157; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JDgNYwz3YgzmsOHffNslKghwxNiNb4ukMOBRNLDpiB4=; b=iFuxgkZaVuZjMBN6kufEnPe3IQeANCZZzCoeQfggpVNuQ/CZCkKsg32D bgqlEGZV0fYw+T7Byx3OcN+Hg9pvunaGY/nMd9R4bvwDGoBdWVfi+qsbt h4YAFGw3bgKu/zsWPNBw/ReVTqyXyQcrxnk3ojuRHSI+OINqTrm3jwga2 I=; X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208,217";a="216246180" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 28 Apr 2016 19:02:35 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 28 Apr 2016 12:02:34 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1156.000; Thu, 28 Apr 2016 12:02:34 -0700 From: Sumandra Majee To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1dsXOC5ZyntEeCrVg5LtZQUZ+eU/SAgAHcfoD//5AdgA== Date: Thu, 28 Apr 2016 19:02:34 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.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.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_D347AB3A50CC9smajeef5com_" MIME-Version: 1.0 Archived-At: Cc: "Jim Guichard \(jguichar\)" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 19:02:40 -0000 --_000_D347AB3A50CC9smajeef5com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dave, I would also concur that SFF is a forwarding entity that uses pathID/SI to = find the next-hop/next-sf/next-sff. This is how our SFF works. It is absolutely possible that co resident classifier to further classify b= ased on l3/l4/l7/python_code and change the path. But logically that is an= other classification and list below is certainly not exhaustive. From: sfc > on behalf of = Dave Dolson > Date: Thursday, April 28, 2016 at 11:43 AM To: "sfc@ietf.org" > Cc: "Jim Guichard (jguichar)" > Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Further to Jim=92s points about section 4.10.5, do I read it correctly that= the SFF can be configured to steer traffic on the basis of these? o Destination MAC address o Source MAC address o VLAN-ID, o Destination IP address o Source IP address o Source port number o Destination port number o DSCP o Packet size, etc., or any combination thereof. This comes totally unexpected to me, thinking that the SFF steers traffic b= ased exclusively on Service Path Identifier and Service Index (SPI/SI), whi= ch oddly aren=92t in the above list. I can guess that maybe this is about reclassification, but =93classificatio= n=94 isn=92t mentioned in 4.10.5. Can someone explain? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 10:18 AM To: Martin Stiemerling; sfc@ietf.org Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement =93this document as= sumes the SFC control plane is provided with a set of information that is r= equired for proper SFC operation=94 but then goes on to list bullets that a= re likely to be provided or may be provided. It does not actually provide a= ny information on what is required for proper SFC operation. In the list of= likely information there is no indication of whether this information must= exist in the network prior to bootstrapping the SFC control plane element;= this is true also for the list of may information. Surely we should provid= e guidelines on what must be available before the SFC control plane element= can actually function although it is reasonable to assume that it can boot= strap without any information (albeit it can=92t actually do anything). On = this point I would argue that several of the may elements are actually requ= ired such as SFF, SF, SFC-proxy locators and may exist prior to bootstrappi= ng the SFC control plane element, or may be added later through some contro= l interface. Minor point -> typo in bullet point 6 =96 SFP proxy should read SFC proxy * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence =93various transport encapsulation schemes and/or va= riations of SFC header implementations may be supported=94 actually mean ? = Are we referring to the fact that the SFC header may carry type-1 or type-2= metadata or something else ? Note that there is only one SFC header implem= entation based on the WG charter so if we are referring to different SFC fo= rmats (meaning metadata) then please make this clear in the text, and if no= t, please remove this sentence. * Section 3.1 Reference Architecture Second bullet point =93mapping between service function chains and SFPs=94 = - this is a general comment for the entire document but applies here also. = There is no mention of mapping SFPs -> RSPs =96 in fact RSP is mentioned on= ly once in the entire document. The architecture is explicit in that the SF= P when rendered into the network is an RSP and therefore the SFC control pl= ane element needs to have information on currently deployed RSPs. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF=92s may require that SFC information be communicated to th= eir management systems that will be responsible for communicating directly = with their respective SF=92s. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence =93The control plane may instruct the classifier about the ini= tial values of the Service Index (SI)=94 should be changed to say MUST as o= therwise if a classifier chooses whatever value it wants then that may not = align with what is programmed into the SFFs by the SFC Control Plane elemen= t. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id=92s whereas the text mentions only SFP-id= #1. Is this simply a typo or are you trying to convey something else ? Further you state that =93the steering policies to a SFF node for service f= unction chain depends on if the packet comes from previous SFF or comes fro= m a specific SF i.e., the SFP Forwarding Table entries have to be ingress p= ort specific=94 - this is an inaccurate statement as the combination of th= e SFP-id and service-index determines the forwarding behavior (as specified= in section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence shoul= d be removed from the text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_D347AB3A50CC9smajeef5com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4CF4526416BDD54981CEC9383134DB73@F5.com> Content-Transfer-Encoding: quoted-printable
Dave,
I would also concur that SFF is a forwarding entity that uses pathID/S= I to find the next-hop/next-sf/next-sff. This is how our SFF works.

It is absolutely possible that co resident classifier to further class= ify based on  l3/l4/l7/python_code and change the path. But logically = that is another classification and list below is certainly not exhaustive. =  

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson &l= t;ddolson@sandvine.com>
Date: Thursday, April 28, 2016 at 1= 1:43 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Cc: "Jim Guichard (jguichar)&q= uot; <jguichar@cisco.com> Subject: Re: [sfc] WGLC for draft-i= etf-sfc-control-plane-04.txt

Further to Jim=92s points about sec= tion 4.10.5, do I read it correctly that the SFF can be configured to steer= traffic on the basis of these?

   o  Destination MA= C address

   o  Source MAC add= ress

   o  VLAN-ID,<= /o:p>

   o  Destination IP= address

   o  Source IP addr= ess

   o  Source port nu= mber

   o  Destination po= rt number

   o  DSCP

   o  Packet size, e= tc., or any combination thereof.

 

This comes totally unexpected to me= , thinking that the SFF steers traffic based exclusively on Service Path Id= entifier and Service Index (SPI/SI), which oddly aren=92t in the above list.

 

I can guess that maybe this is abou= t reclassification, but =93classification=94 isn=92t mentioned in 4.10.5.

Can someone explain?

 

-Dave

 

 

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; sfc@ietf.org=
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Hi Martin & WG:

 

A few comments that I would like to see addr= essed in the document before it can move forward to the next step.

  • Sectio= n 2.2 SFC Control Plane Bootstrapping.

This section is too wishy washy. It makes th= e statement =93this document assumes the SFC control plane is provided with= a set of information that is required for proper SFC operation=94 but then goes on to list bullet= s that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can=92t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

Minor point -> typo in bullet point 6 =96= SFP proxy should read SFC proxy

  • Sectio= n 2.3 Coherent Setup of an SFC-enabled Domain

What does the sentence =93various transport = encapsulation schemes and/or variations of SFC header implementations may b= e supported=94 actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or som= ething else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

  • Sectio= n 3.1 Reference Architecture

Second bullet point =93mapping between servi= ce function chains and SFPs=94 - this is a general comment for the entire d= ocument but applies here also. There is no mention of mapping SFPs -> RSPs =96 in fact RSP is mentioned only on= ce in the entire document. The architecture is explicit in that the SFP whe= n rendered into the network is an RSP and therefore the SFC control plane e= lement needs to have information on currently deployed RSPs.

 

Additionally there is no interface specified= for communication between the SFC Control Plane Element and SF management = systems. This is an important aspect as many SF=92s may require that SFC information be communicated to their m= anagement systems that will be responsible for communicating directly with = their respective SF=92s. 

  • Sectio= n 3.1.1. C1: Interface between SFC Control Plane & SFC Classifier<= /o:p>

The sentence =93The control plane may instru= ct the classifier about the initial values of the Service Index (SI)=94 sho= uld be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. =

  • Sectio= n 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets

This section does not actually provide any m= eaning or indication of relationship with the SFC Control Plane element. Fu= rthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire= section should be removed from the document.

  • Sectio= n 4.10.5. Fully Controlled SFF/SF Sequence for a SFP
    • =

Figure 2 lists 3 different SFP-id=92s wherea= s the text mentions only SFP-id #1. Is this simply a typo or are you trying= to convey something else ?

 

Further you state that =93the steering polic= ies to a SFF node for service function chain depends on if the packet comes= from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= =94 -  this is an inaccurate statement as the combination of the SFP-i= d and service-index determines the forwarding behavior (as specified in sec= tion 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

 

Jim

 

 

 

On 4/27/16, 12:29 AM, "sfc on behalf of= Martin Stiemerling" <sfc-b= ounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,

 

This is the start of the Working Group Last = Call (WGLC) for

 

draft-ietf-sfc-control-plane-04.txt

 

The WGLC lasts for 2 weeks and will end May = 11th at 10 pm PDT.

 

Please send your comments and reviews to the sfc@ietf.org list.

 

Regards,

 

   Martin (SFC co-chair)

 

____________________________________________= ___

sfc mailing list

 

 --_000_D347AB3A50CC9smajeef5com_-- From nobody Thu Apr 28 13:29:13 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 3C96712D9E6 for ; Thu, 28 Apr 2016 13:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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=-0.996, 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 glSm-BrQZDgW for ; Thu, 28 Apr 2016 13:28:59 -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 5E20112D9DF for ; Thu, 28 Apr 2016 13:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64935; q=dns/txt; s=iport; t=1461875339; x=1463084939; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VHAHZOV0PCPBg0ZsGoVYkSKgDAaCEk/0T1yZ7NNi/8k=; b=DNKbN/mm+HKOjUJmkU7LdMl6WyQQIf+31s0qOfy3STqHhbni6LmYoVIW qu2pOxA35p80zT2dHQzpUNy146N/JJEmtlZvIi1kNpjr5RFcukdvTBFXy Mf3I/xNlc9s0C3mYXOZe0/wTnHDmS4C+5lzOLIgcm8T2P2aqXOPSg7ia4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgAKciJX/4YNJK1bA4M4U24PBq19i?= =?us-ascii?q?14BDYFyBBcLhW0CgSw4FAEBAQEBAQFlJ4RBAQEBAwEBAQEXAQJKBwsFBwQCAQg?= =?us-ascii?q?RAwEBAQEjBAchBgsUCQgCBA4FiBUDCggOvyINhEsBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQERBIYhgXUIgk6CQYF8ISaCZIIrBYd0hhiJUzEBhXuCd4MugXaBZ4RNgym?= =?us-ascii?q?FNIYkgS2HXgEeAQFCgjaBNWyGaX8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,548,1454976000"; d="scan'208";a="267282151" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 20:28:57 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3SKSvPt012669 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 20:28:57 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.1104.5; Thu, 28 Apr 2016 15:28:56 -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.1104.009; Thu, 28 Apr 2016 15:28:56 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLy5ZShX9BUcs0qvgiEBlqhYSJ+elnwAgAAtrACAAAwigIAA0eUAgAASMoCAABvXAIAAAPWAgAAjHICAADcvAA== Date: Thu, 28 Apr 2016 20:28:56 +0000 Message-ID: <45761271-F03F-479E-978A-53545964F455@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> <888c5567-c459-f29f-6f20-02aad39f1f76@joelhalpern.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.90.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F91286BF94BE84A8652626FFD014F71@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , Joel Halpern Direct , "Andrew G. Malis" , "sfc@ietf.org" Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 28 Apr 2016 20:29:11 -0000 Jim, Andy, That works for me. We'll mark it for inclusion in the next revision. Paul > On Apr 28, 2016, at 10:11 AM, Jim Guichard (jguichar) wrote: >=20 > That wording works for me. >=20 > Paul/Uri, as editors of draft-ietf-sfc-nsh-04, unless there are any > objections from the WG or yourselves, can you please make the suggested > change to the text? >=20 > Jim >=20 > On 4/28/16, 11:05 AM, "Joel Halpern Direct" > wrote: >=20 >> Thanks Andy. That wording would indeed work for me. >> Yours, >> Joel >>=20 >> On 4/28/16 11:02 AM, Andrew G. Malis wrote: >>> Jim, >>>=20 >>> The way option 3 is currently worded, there=B9s no indication that this= is >>> just an example, and not a direction to use RFC 6830, section 5.4. I >>> just had an offline discussion with Joel, and he and I agree that a >>> better wording for option 3 would be "Use the fragmentation provided by >>> the network overlay mechanics. One example can be found in RFC 6830, >>> section 5.4.=B2 >>>=20 >>> Thanks, >>> Andy >>>=20 >>> On Thu, Apr 28, 2016 at 9:22 AM, Jim Guichard (jguichar) >>> > wrote: >>>=20 >>> Hi Andy, >>>=20 >>> I think the key point is that NSH !=3D network overlay but rather >>> utilizes a network overlay for packet transport between SFC network >>> elements. The reference is just an example of how a network overlay >>> might deal with fragmentation and is not a suggestion that NSH adopt >>> that mechanism but rather makes the point that it can utilize the >>> existing network overlay mechanics. >>>=20 >>> Jim >>>=20 >>> From: sfc > on >>> behalf of "Andrew G. Malis" >> > >>> Date: Thursday, April 28, 2016 at 8:17 AM >>> To: Joel Halpern Direct >> > >>> Cc: "Elzur, Uri" >, >>> "mohamed.boucadair@orange.com " >>> >> >, "sfc@ietf.org >>> " >, Linda >>> Dunbar > >>> Subject: Re: [sfc] Suggested wording addtion to the Section 6 >>> (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt >>>=20 >>> Joel, >>>=20 >>> The diagrams in section 6 of RFC 6830 are control plane, not data >>> plane. The data plane diagrams are in section 5. >>>=20 >>> But the overriding question is - without any fields in the NSH >>> header to sequence fragments, how can the fragments be correctly >>> reassembled? >>>=20 >>> Cheers, >>> Andy >>>=20 >>> On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct >>> > >>> wrote: >>>=20 >>> The LISP header does not have a fragment flag or fragment >>> offset. The diagrams in section 6 include the outer >>> encapsulating header (the equivalent of the transport header in >>> SFC.) Yes, the text is a little hard to follow in this regard. >>> The LISP working group is going to be rewriting RFC 6830 as part >>> of moving to standards track. >>>=20 >>> So there is no difference in this regard between NSH and LISP. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 4/27/16 7:02 PM, Andrew G. Malis wrote: >>>=20 >>> Joel et al, >>>=20 >>> All this talk about fragmentation prompted me to re-read >>> section 6 of >>> the draft, which recommends (as option 3) using the >>> procedures in >>> section 5.4 of RFC 6830 (presumably with the =B3NSH header= =B2 >>> replacing the >>> =B3LISP header=B2 in the description of the procedures in th= at >>> section). >>>=20 >>> So that led me to read that section (and the LISP header >>> definition in >>> section 5.1), and I see that LISP does fragmentation and >>> reassembly >>> identically to IPv4, using the Fragment Offset field so that >>> fragments >>> can be correctly reassembled in the proper order. >>>=20 >>> However, the NSH Header doesn=B9t have a Fragment Offset fie= ld >>> or any >>> other way to order the fragments. >>>=20 >>> So how can the procedures in Section 5.4 of 6830 be used? >>>=20 >>> Thanks, >>> Andy >>>=20 >>> On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >>> >>> >> >>> wrote: >>>=20 >>> Both methods are valid, and both depend upon details of >>> the >>> underlying packet and the transport. As such, I don't >>> see why this >>> document benefits from describing them, much less why it >>> should mark >>> one method as a "should". Implementation details are >>> likely to be >>> more significant than any bit consumption difference >>> between the two >>> alternatives. >>>=20 >>> Yours, >>> Joel >>>=20 >>>=20 >>> On 4/27/16 3:40 PM, Linda Dunbar wrote: >>>=20 >>> I suggest adding the following paragraphs after the >>> Bullet 3 of >>> the Section 6 Fragmentation Consideration to make >>> the process >>> more clear and less controversial: >>>=20 >>>=20 >>> -------------------------------- >>>=20 >>> RFC6830 describes the fragmentation method of >>> breaking the >>> original packet into two equal sub-frames and >>> encapsulating >>> [LISP Header + Transport header] to each sub-frame. >>>=20 >>> If LISP fragmentation [RFC6830 Section 5.4] is used, >>> the [SFC >>> Header + Transport Header] will be added to each >>> half frame (or >>> the original data frame). As the Transport Header is >>> terminated >>> by the next SFF node's tunnel transport layer, the >>> combined two >>> sub-frames will have two SFC Headers. >>>=20 >>> Therefore, the fragmentation for NSH encapsulated >>> data frame >>> should be done completely by the node tunnel >>> transport layer, >>> which should break the [SFC + original packet] into >>> two equal >>> sub-frames and each sub-frame being encapsulated >>> with its >>> respective tunnel header. The next SFF node's >>> tunnel transport >>> layer should combine the two sub-frames before >>> sending to the >>> next node. >>>=20 >>>=20 >>> ------------------------------------------------------ >>>=20 >>>=20 >>> By the way, there are to typo in the Section 6: >>> 3rd line: "In order the" =3D=3D> "In order to" >>> Last line of Bullet 2: extra "the" in the "utilized >>> to ensure >>> the the required packet". >>>=20 >>>=20 >>> Hope it helps. >>>=20 >>> Linda >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: mohamed.boucadair@orange.com >>> >>> >> > >>> [mailto:mohamed.boucadair@orange.com >>> >>> >> >] >>> Sent: Wednesday, April 27, 2016 12:40 AM >>> To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; >>> sfc@ietf.org >>> > >>> Subject: RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Hi Joel, all, >>>=20 >>> Please see inline. >>>=20 >>> Cheers, >>> Med >>>=20 >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com >>> >>> >> >] Envoy=E9 : mardi 26 >>> avril 2016 19:18 =C0 : Linda Dunbar; BOUCADAIR >>> Mohamed >>> IMT/OLN; Elzur, >>> Uri; sfc@ietf.org >>> > Objet : Re: >>> [sfc] WG >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> With regard to Transport tunnel fragementation, >>> that seems >>> an issue >>> for the transport protocol. I don't actually >>> object to a >>> sentence, >>> but it does not seem that it will accomplish >>> anything. >>>=20 >>>=20 >>> [Med] I would like to see some text added to the >>> draft. >>>=20 >>>=20 >>> With regard to packets fragmented by the >>> source, I >>> completely disagree >>> with your assertion. If an SFF were to >>> reassemble the >>> packets, that >>> would be a violation of its job. >>>=20 >>>=20 >>> [Med] I agree with you. >>>=20 >>> There is no reason for an SFF to >>>=20 >>> reassemble a packet fragmented by the source. >>> The >>> classifier may have >>> to do some interesting things in order to >>> properly classify >>> succeeding >>> fragments, but that is an implementation issue >>> (most commonly >>> addressed with virtual reassembly, which doe >>> snot delay the >>> fragments.) We don't specity that. >>>=20 >>>=20 >>> [Med] Still, the external behavior of the classifier >>> needs to be >>> clear in the document. I don't find any text in the >>> draft saying >>> for instance that an NSH header must be present in >>> all >>> fragments. (There some processing that might be >>> needed at the >>> SFF to "do its job" with regards to fragments >>> (receive out of >>> order fragments + forwarding policy on the full >>> packet).) >>>=20 >>>=20 >>> If an SF needs to reassemble fragments to do its >>> job, that >>> is up to >>> the SF. Some will need to actually reassemble. >>> Some will >>> need to >>> perform virtual reassembly, and some will >>> happily process the >>> fragments. I can not see what the NSH document >>> could >>> possibly mandate. >>>=20 >>>=20 >>> [Med] Fully agree. >>>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 4/26/16 11:47 AM, Linda Dunbar wrote: >>>=20 >>> Joel, >>>=20 >>> I think the document should add the >>> description on the >>> following two >>> fragmentation scenarios: >>>=20 >>> - Transport tunnel generated fragmentation: >>> When a packet >>> fragmentation is caused by transport tunnel >>> (i.e. various >>> encapsulations), the termination point of >>> the transport >>> tunnel is >>> responsible for re-assembling the fragmented >>> pieces of >>> the packet. >>> Since there won't be any SFF nodes in >>> between the >>> Transport Tunnel, >>> the tunnel generated fragmentation does not >>> require any >>> actions by >>> SFF nodes or SF nodes. >>>=20 >>>=20 >>> - Source node generated fragmentation (after >>> adding on >>> the NSH >>> header): When fragmentation has to be >>> performed for a >>> packet being >>> encapsulated with the NSH header, either the >>> intermediate SFF nodes >>> or the SF nodes have to be able to >>> reassemble the >>> fragmented pieces. >>>=20 >>>=20 >>>=20 >>>=20 >>> Cheers, >>>=20 >>>=20 >>> Linda >>>=20 >>> -----Original Message----- From: Joel M. >>> Halpern >>> [mailto:jmh@joelhalpern.com >>> >>> >> >] Sent: Tuesday, April 26, >>> 2016 10:33 AM >>> To: Linda Dunbar; >>> mohamed.boucadair@orange.com >>> >>> >> >; Elzur, Uri; >>> sfc@ietf.org >>> > Subject: Re: >>> [sfc] WG >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Re-reading your note, it is possible that >>> you are >>> referring only to >>> the case of transport generated >>> fragmentation of the >>> outer packet. >>> I had assumed you were not talking about >>> that, since the >>> resulting >>> fragments will not all have NSH headers. As >>> with any tunnel >>> technology, if the tunnel chooses to >>> fragment at its >>> layer, then the >>> tunnel is responsible for reassembly. That >>> would be >>> invisible to >>> the SFF. >>>=20 >>> Yours, Joel >>>=20 >>> On 4/26/16 11:10 AM, Linda Dunbar wrote: >>>=20 >>> Agree with Med. >>>=20 >>> Even if each fragment piece of a packet >>> with NSH >>> header carries the >>> NSH header, the intermediate SFF nodes >>> still need to >>> put together >>> all the fragments together before >>> passing the whole >>> data frame to >>> the SF. >>>=20 >>> Linda >>>=20 >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> >>> >> >] >>> On Behalf Of >>> mohamed.boucadair@orange.com >>> >>> >> > Sent: Monday, >>> April 25, >>> 2016 9:42 AM To: Elzur, Uri; Joel M. >>> Halpern; >>> sfc@ietf.org >>> > Subject: >>> Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Re-, >>>=20 >>> How do you instruct the transport layer >>> to ALWAYS >>> prepend an NSH >>> header even for fragments? Or you don't >>> care about that? >>>=20 >>> Thank you. >>>=20 >>> Cheers, Med >>>=20 >>> -----Message d'origine----- De : >>> Elzur, Uri >>> [mailto:uri.elzur@intel.com >>> >>> >> >] Envoy=E9 : lundi 25 >>> avril 2016 16:26 =C0 >>> : BOUCADAIR Mohamed IMT/OLN; Joel M. >>> Halpern; >>> sfc@ietf.org >>> > Objet >>> : RE: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Hi Med >>>=20 >>> Not to repeat my position, but I'll >>> do it anyhow >>> :-) As NSH is >>> *NOT* a transport, dealing with >>> fragmentation is >>> left to the >>> Transport used. >>>=20 >>> The model I use for NSH, is >>> basically similar to >>> VXLAN . It is an >>> overly. >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") C: 949-378-7568 >>> > >>>=20 >>>=20 >>> -----Original Message----- From: sfc >>> [mailto:sfc-bounces@ietf.org >>> >>> >> >] >>> On Behalf Of >>> mohamed.boucadair@orange.com >>> >>> >> > Sent: >>> Monday, April 25, >>> 2016 7:18 AM To: Joel M. Halpern >>> >> >> >>; >>> sfc@ietf.org >>> > >>> Subject: Re: [sfc] WG last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Hi Joel, >>>=20 >>> Please see inline. >>>=20 >>> Cheers, Med >>>=20 >>> -----Message d'origine----- De : >>> Joel M. Halpern >>> [mailto:jmh@joelhalpern.com >>> >>> >> >] Envoy=E9 : lundi >>> 25 avril 2016 15:48 =C0 >>> : BOUCADAIR Mohamed IMT/OLN; >>> sfc@ietf.org >>> >> > Objet : Re: [sfc] WG >>> last call for >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> If I am understanding you >>> correctly Med, you >>> are asking that the >>> NSH draft specify how service >>> chaining >>> should cope with packets >>> that have been fragmented? >>>=20 >>>=20 >>> [Med] To be accurate, I'm asking to >>> assess >>> whether there are >>> implications. If there are, then the >>> draft >>> should be updated >>> accordingly. >>>=20 >>> NSH, and the SFF functionality, >>> does not care. >>>=20 >>>=20 >>> [Med] I'm not that sure. Some >>> typical >>> implications are listed >>> below: >>>=20 >>> * SFF: If the NSH header is present >>> only in the >>> a fragment but SFF >>> didn't maintained a state, >>> subsequent fragments >>> won't be >>> appropriately processed. * SFC-aware >>> function: >>> if prepending a >>> context information depends on the >>> full packet, >>> not only a >>> fragment. >>>=20 >>> It just does its job. >>>=20 >>> [Med] which may be disturbed in some >>> situations >>> as listed in the >>> examples above. >>>=20 >>> Ingress and intermediate >>> classifiers may >>> cope with fragments in >>> any number of ways. >>>=20 >>> Specifying such is clearly out of >>> scope for this >>> draft. >>>=20 >>> [Med] The purpose is not to specify >>> the internal >>> implementation >>> details but the external behavior >>> of the >>> classifier function when >>> it comes to handle fragments. That >>> behavior may >>> have an incidence >>> on SFF, in particular. The purpose >>> is not to >>> recommend the maximum >>> resources to be dedicated to out of >>> order >>> fragments nor the >>> timeout to cache those; these >>> considerations are >>> of course out of >>> scope. Nevertheless, an >>> implementation should >>> offer a configurable >>> parameter so that an operator tweak >>> those >>> according to its >>> context. >>>=20 >>> I suppose one could write an >>> informational >>> draft on possible ways >>> of coping. The IETF has not >>> usually >>> published such. >>> Service functions have to cope >>> with >>> fragmented packets just as >>> they had to before the advent of >>> NSH, so >>> describing that is >>> clearly not needed here. >>>=20 >>>=20 >>> [Med] The advent of NSH has the >>> following >>> implications: * it >>> exacerbates fragmentation. Handing >>> over this >>> issue to the >>> transport layer may lead to >>> interoperability >>> issues. * the >>> chaining may not be efficient if >>> fragments are >>> inappropriately >>> handled. >>>=20 >>> Introducing NSH should not degrade >>> the overall >>> service compared to >>> legacy service deployment schemes. >>>=20 >>>=20 >>> Yours, Joel >>>=20 >>> On 4/25/16 3:00 AM, >>> mohamed.boucadair@orange.com >>> >>>=20 >>> >> > wrote: >>>=20 >>> Re-, >>>=20 >>> I hear you, but my comment >>> is that we >>> need, as a WG, to decide >>> what to >>>=20 >>> put in the draft. FWIW, I'm >>> discussing two >>> fragmentation >>> issues: >>>=20 >>>=20 >>> (1) Fragmentation that is >>> caused by >>> prepending an SFC header. >>> (2) Handling fragments at >>> the ingress of >>> an SFC-enabled domain. >>>=20 >>> Increasing the MTU is for >>> sure a >>> recommendation is to be >>> explicitly >>>=20 >>> called out in the text (see my >>> first message). >>>=20 >>>=20 >>> There are other issues that >>> need to be >>> discussed, e.g., how to >>> deal with >>>=20 >>> fragments in SFFs/Classifiers? >>>=20 >>>=20 >>> It is also "prudent" to >>> check that no >>> issues will be experienced >>> in SFF >>>=20 >>> to handle fragments. If an SFC >>> header is >>> prepended for all >>> fragments, I'm not sure there >>>=20 >>> is any particular issue at >>> the SFF >>> level, except if >>> stripping/adding >>>=20 >>> context TLVs depends on the full >>> packet (not >>> just fragment). It >>> is warranted to consider a >>> little bit this >>> point before declaring >>> there is no issue. >>>=20 >>>=20 >>> For point (1), declaring >>> fragmentation >>> out of scope would be >>> meant that >>>=20 >>> an implementation must be >>> prepared to >>> receive fragments with or >>> without NSH header as this is a >>> decision >>> that is left to the >>> transport encapsulation. This >>> is a >>> requirement per se! >>>=20 >>>=20 >>> I won't reiterate all the >>> comments I >>> have about the current >>> wording of >>>=20 >>> this section. >>>=20 >>>=20 >>> Cheers, Med >>>=20 >>> -----Message >>> d'origine----- De : >>> Elzur, Uri >>>=20 >>> [mailto:uri.elzur@intel.com >>>=20 >>> >] >>> Envoy=E9 >>> : lundi 25 avril 2016 >>> 08:30 =C0 : BOUCADAIR >>> Mohamed IMT/OLN; >>> Thomas Narten; >>> sfc@ietf.org >>> >> > >>> Objet : RE: [sfc] WG >>> last call for >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Hi Med >>>=20 >>> My point is that >>> Fragmentation is >>> yet another transport >>> related >>> issue >>>=20 >>> that >>>=20 >>> is beyond the scope of >>> NSH and >>> beyond the charter of >>> the WG, so >>> it >>>=20 >>> doesn't >>>=20 >>> really belong in the >>> draft. We are >>> providing an advice as >>> extending the size of >>> the packet may >>> lead to fragmentation, >>> but >>> as you check RFC 7348 >>> VxLAN, which >>> my create the same >>> issue, >>> you'll find it doesn't >>> even >>>=20 >>> relate >>>=20 >>> to it. >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") C: >>> 949-378-7568 >>> >> > >>>=20 >>>=20 >>> -----Original >>> Message----- From: sfc >>>=20 >>> [mailto:sfc-bounces@ietf.org >>>=20 >>> >> >] On >>> Behalf Of >>>=20 >>> mohamed.boucadair@orange.com >>> >>>=20 >>> >> > Sent: >>> Sunday, April 24, 2016 >>> 10:32 PM To: Elzur, Uri >>> >> >>>=20 >>> >>; >>> Thomas Narten >>>=20 >>> >> >> >>; >>>=20 >>> sfc@ietf.org >>> >> > >>> Subject: Re: [sfc] WG >>> last call for >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Hi Uri, >>>=20 >>> That's another option >>> that needs to >>> be=20 >>> discussed/investigated. >>> I'm >>>=20 >>> afraid >>>=20 >>> this is not the >>> rationale adopted in >>> -04 since it includes=20 >>> some >>> text >>>=20 >>> that >>>=20 >>> is far to be sufficient >>> to ensure >>> interoperable >>> implementations. >>>=20 >>> BTW, saying that nsh >>> does not need >>> to deal with=20 >>> fragmentation >>> because >>>=20 >>> it >>>=20 >>> is transport-independent >>> is not IMHO >>> a good strategy to adopt >>> here >>>=20 >>> because >>>=20 >>> it opens the door for >>> interoperable >>> issues, it may lead to >>> sub-optimal >>> implementations if the >>> sfc information is=20 >>> present >>> only in one >>>=20 >>> fragments, >>>=20 >>> etc. >>>=20 >>> My comments are related >>> to the >>> current text in the -04. >>> This text needs >>>=20 >>> to >>>=20 >>> be fixed somehow. >>>=20 >>> Cheers, Med >>>=20 >>> -----Message >>> d'origine----- De : >>> Elzur, Uri >>>=20 >>> [mailto:uri.elzur@intel.com >>>=20 >>> >] >>> Envoy=E9 : dimanche = 24 >>> avril >>> 2016 17:36 =C0 : >>> BOUCADAIR Mohamed >>> IMT/OLN; Thomas=20 >>> Narten; >>> sfc@ietf.org >>> >>> >> > Objet : >>> RE: [sfc] WG last >>> call for >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Hi Med >>>=20 >>> I see no need to >>> specify the >>> exact behavior as=20 >>> NSH is >>> transport >>> independent i.e. like >>> NSH interaction with >>> any other >>> Transport eh issue=20 >>> of >>> Fragmentation is to >>> be dealt in >>> a way >>> that matches the >>> mechanisms >>> supported by the >>> Transport used >>> and do not belong in >>> the NSH draft >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") C: >>> 949-378-7568 >>> >> > >>>=20 >>>=20 >>> -----Original >>> Message----- From: sfc >>>=20 >>> [mailto:sfc-bounces@ietf.org >>>=20 >>> >] >>> On Behalf Of >>>=20 >>> mohamed.boucadair@orange.com >>> >>>=20 >>> >> > >>> Sent: Thursday, >>> April 14, >>> 2016 12:43 AM To: >>> Thomas Narten >>> >> >>>=20 >>> >>; >>> sfc@ietf.org >>> >>> >> > Subject: >>> Re: [sfc] WG last >>> call for >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> R-, >>>=20 >>> In addition to other >>> pending >>> issues raised for >>> this draft, I >>> would like to raise= =20 >>> this >>> additional one about >>> Section 6. >>>=20 >>> =3D=3D 6. Fragmenta= tion >>> Considerations >>>=20 >>> NSH and the >>> associated transport >>> header are "added" >>> to the >>> encapsulated >>> packet/frame. This >>> additional=20 >>> information >>> increases >>>=20 >>> the >>>=20 >>> size of the packet. >>> In order >>> the ensure proper >>> forwarding of >>> NSH data, several >>> options for >>> handling >>> fragmentation and >>> re-assembly exist: >>>=20 >>> 1. Jumbo Frames,=20 >>> when >>> supported, enable >>> the transport >>> of NSH >>> and associated >>> transport packets >>> without requiring >>> fragmentation. >>>=20 >>> 2. Path MTU=20 >>> Discovery >>> [RFC1191]"describes >>> a technique for >>> dynamically >>> discovering the >>> maximum transmission >>> unit (MTU) of >>>=20 >>> an >>>=20 >>> arbitrary internet >>> path" and can >>> be utilized to >>> ensure the >>>=20 >>> the >>>=20 >>> required packet size >>> is used. >>>=20 >>> 3. [RFC6830] >>> describes two >>> schemes for >>> fragmentation and >>> re- >>>=20 >>> assembly >>>=20 >>> in section 5.4. =3D= =3D >>>=20 >>> * The text is weak=20 >>> for a >>> Standard track >>> document that is >>> intended to solve >>> the problem in >>>=20 >>> https://tools.ietf.org/html/rfc7498#section- >>>=20 >>> 2.12. >>>=20 >>> There should be a >>> clear behavior >>> to be followed by an >>>=20 >>> implementation. >>>=20 >>> Further, I would >>> avoid the use >>> of words such as=20 >>> "can". >>>=20 >>> * The text covers=20 >>> only >>> fragmentation when >>> it is induced >>> by SFC >>> operations, it does >>> not discuss >>> the treatment of a >>> fragment >>> when received in an >>> SFC domain. >>> IMHO, the draft >>> should also >>> specify the behavior >>> of the >>> Classifier with >>> regards to >>> fragments for the >>> sake of proper >>> SFC operation.=20 >>> Applying >>> classification >>> policies may >>> require the >>>=20 >>> full packet, not only a >>> fragment. >>>=20 >>> In particular,=20 >>> dedicated >>> resources should >>> dedicated for >>> handling out of >>> order fragments. >>> Of course, it is out >>> of scope >>> of this document to >>> describe how >>> SFs handle=20 >>> fragments. >>>=20 >>> * If an SFC header >>> is prepended >>> for all fragments, >>> I'm not >>> sure there is any >>> particular >>> issue at the SFF >>> level...except >>> if stripping/adding >>> context TLVs >>> depends on the full >>> packet >>> (not just fragment). >>> It is >>> warranted to >>> consider a little bit >>> this point before >>> declaring there >>>=20 >>> is >>>=20 >>> no issue. >>>=20 >>>=20 >>> * The text states >>> "several >>> options". This may >>> be interpreted >>> as if implementing >>> one of them >>> is >>> sufficient...which is not >>> true. The first two >>> points >>> contribute to >>> minimize the >>> fragmentation risk,= =20 >>> but >>> fragmentation may >>> still be >>> experienced >>> (e.g., other shims >>> are prepended >>> by other nodes for >>> some other >>> purposes, nested >>> nsh, etc.) >>>=20 >>> * The first two >>> points have >>> nothing to do with >>> reassembly. >>>=20 >>> * The support of >>> jumbo frames by >>> a router/device does >>> not mean >>> that it can make use >>> of it. >>> Appropriate MTU >>> configuration >>> should be undertaken >>> in a >>> consistent manner >>> within an SFC >>> domain. The text >>> should be >>> updated to make it >>> is about >>> (consistent) MTU >>>=20 >>> configuration. >>>=20 >>>=20 >>> * BTW, shouldn't the >>> text be >>> reworded to >>> recommended to >>> increase the MTU of >>> **all >>> nodes** of an >>> SFC-enabled domain by >>> at least the length >>> of SFC >>> header + transport >>> header? >>>=20 >>> * Bullet 2, how PMTU >>> discovery >>> is actually used in= =20 >>> this >>> context? Do you >>> assume that all >>> SFC-aware nodes will >>> issue >>> such messages >>> towards other >>> SFC-aware node, >>> arbitrary >>> destination, else? >>>=20 >>> * Bullet 2, I would= =20 >>> drop >>> "describes a >>> technique for >>> dynamically >>> discovering the >>> maximum transmission >>> unit >>> (MTU) of an >>> arbitrary internet >>> path". >>>=20 >>> * Bullet 2, s/ the >>> the/the. >>>=20 >>> * The reference to >>> the LISP >>> specification raises >>> two concerns >>> and one comment: >>>=20 >>> (1) I don't think it >>> is a good >>> approach that >>> fragments induced >>> by the network are >>> passed to >>> their ultimate >>> destinations as >>> such >>>=20 >>> (stateless). >>>=20 >>> IMO, reassembly >>> should be done >>> within the SFC=20 >>> domain >>> (responsible for >>> fragmentation) >>> not passed away. (2) >>> Does the >>> stateful mode >>> require all SFC >>> data plane elements >>> maintain a >>> full list of MTU for >>> the any >>> SFF/SF instance of >>> the SFC >>>=20 >>> domain? >>>=20 >>>=20 >>> The current text >>> suggests that >>> [RFC6830] should be >>> listed as >>> normative reference >>> (not an >>> informative one). I >>> would >>> personally favor >>> removing the >>> reference to LISP >>> (as it is an >>> Experimental RFC). >>>=20 >>> * The security >>> section of the >>> draft may be >>> augmented with >>> informational >>>=20 >>> fragmentation-related pointers to: >>> e.g., RFC1858=20 >>> (Security >>> Considerations for >>> IP Fragment >>> Filtering), RFC3128 >>> (Protection >>> Against a Variant of >>> the Tiny >>> Fragment Attack), >>> and RFC 4963 >>> (IPv4 Reassembly >>> Errors at High >>> Data Rates). >>>=20 >>> Cheers, Med >>>=20 >>> -----Message >>> d'origine----- >>> De : sfc >>>=20 >>> [mailto:sfc-bounces@ietf.org >>>=20 >>> >] >>> De la part de >>>=20 >>> mohamed.boucadair@orange.com >>> >>>=20 >>> >> > >>> Envoy=E9 : lundi >>> 11 avril >>> 2016 13:14 =C0 : >>> Thomas >>> Narten; >>> sfc@ietf.org >>>=20 >>> > Objet >>> : Re: >>> [sfc] WG last >>> call for >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Dear Thomas,=20 >>> all, >>>=20 >>> As I mentioned >>> during the >>> meeting, there >>> are several >>> issues >>> that are not >>> covered in the >>> last version of >>> the draft. I >>> already provided >>> examples of >>> the issues >>> offline as requested >>> by Martin. >>>=20 >>> Cheers, Med >>>=20 >>> -----Message >>>=20 >>> d'origine----- De : sfc >>>=20 >>> [mailto:sfc-bounces@ietf.org >>>=20 >>> >] >>> De la part >>> de Thomas Narten >>> Envoy=E9 : >>> jeudi 31 mars >>> 2016 04:48=20 >>> =C0 : >>> sfc@ietf.org >>> >>>=20 >>> > >>> Objet : >>> [sfc] WG last >>> call for >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> Dear WG: >>>=20 >>> This note >>> begins a WG >>> last call on >>>=20 >>> draft-ietf-sfc-nsh-04.txt >>>=20 >>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). >>>=20 >>>=20 >>>=20 >>> The editors of the NSH document have indicated >>> that they have >>>=20 >>> addressed >>> all known >>> comments and >>> that there >>> are no open >>> issues with >>> the current >>> version of >>> the document. >>>=20 >>> Substantive >>> comments to >>> the list=20 >>> please, >>> editorial >>> comments >>> can go >>> directly to the >>> document >>> editors. >>>=20 >>> We'll also >>> get a brief >>> update from >>> the editors >>> at next >>> week's >>> meeting. If there >>> are any >>> remaining issues >>> with the >>> document, >>> raising them >>> before the >>> meeting would be >>> especially >>> helpful. >>>=20 >>> For the >>> chairs, Thomas >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing >>> list >>> sfc@ietf.org >>>=20 >>> > >>>=20 >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing >>> list >>> sfc@ietf.org >>>=20 >>> > >>>=20 >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing >>> list sfc@ietf.org >>> >>> >> > >>>=20 >>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Apr 28 14:28:34 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 DD25112D9CD for ; Thu, 28 Apr 2016 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 fQTCzfihp5o6 for ; Thu, 28 Apr 2016 14:28:27 -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 389E112D891 for ; Thu, 28 Apr 2016 14:28:26 -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 CIS89939; Thu, 28 Apr 2016 21:28:23 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 28 Apr 2016 22:28:19 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.126]) by SJCEML702-CHM.china.huawei.com ([169.254.4.137]) with mapi id 14.03.0235.001; Thu, 28 Apr 2016 14:28:14 -0700 From: Henry Fourie To: Sumandra Majee , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1xptygDpbcqk2x0cunxea82p+eU/SAgAHcfoCAAAV3AP//oNsQ Date: Thu, 28 Apr 2016 21:28:13 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559A09569109@SJCEML701-CHM.china.huawei.com> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.202.57] Content-Type: multipart/alternative; boundary="_000_0F8583BBE82FA449A8B78417CC07559A09569109SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57228078.0035, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.126, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9efd71f21c046270d01650c0fb1175f6 Archived-At: Cc: "Jim Guichard \(jguichar\)" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 28 Apr 2016 21:28:33 -0000 --_000_0F8583BBE82FA449A8B78417CC07559A09569109SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Comments: 1. There is one sentence on OAM in 3.1. This probably deserves a sub-s= ection in section 4 that covers fault management, alarms, error reporting, = switchovers... Note, the SFC control plane must be able to invoke SFC OAM mechanisms, and = to determine the results of OAM operations. 2. There is no mention of metadata in the document. Use of the term 'm= etadata' may make some text clearer. For example, there should be a sentence in the 3.3.x sections for SFC contr= oller to request a particular component to insert/remove/report packet meta= data. 3. Last para of 3.3.2: change 'An SFF can be instructed...' to 'An SFF= must be instructed...' 4. 3.3.3: This paragraph does not read well: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. Suggest: This interface may also be used to instruct an SFC-aware SF to insert, remo= ve or report metadata information for a given SFC. 5. 3.3.3: In several paragraphs the term 'contexts' is used. It may be= clearer if 'metadata' is used instead. 6. Suggest moving this paragraph from 4.10.5 to 3.4.4 as it relates sp= ecifically to SFC Proxy functionality. Reworded, this can replace the last sentence in 3.= 3.4: The C4 interface may also include information to map the SFP Identifier carried in the packet header to a locally significant link identifier, e.g., VLAN-ID, and a method to construct and encapsulate the SFC header back to the packets when they come back from the attached SF= s. 7. Last para of 4.10.5 typo: classier -> classifier 8. Last para of 4.10.5: This could be clearer on what the problem is. = Not sure what SFF A and SFF B are? Would it not be better to recommend a pr= ocedure in which the SFC Controller updates downstream SFFs before upstream= SFFs when constructing a new SFP. Insertion of a SF into a SFP should have= only local impact on the SFF it is connected to. - Louis From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee Sent: Thursday, April 28, 2016 12:03 PM To: Dave Dolson; sfc@ietf.org Cc: Jim Guichard (jguichar) Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Dave, I would also concur that SFF is a forwarding entity that uses pathID/SI to = find the next-hop/next-sf/next-sff. This is how our SFF works. It is absolutely possible that co resident classifier to further classify b= ased on l3/l4/l7/python_code and change the path. But logically that is an= other classification and list below is certainly not exhaustive. From: sfc > on behalf of = Dave Dolson > Date: Thursday, April 28, 2016 at 11:43 AM To: "sfc@ietf.org" > Cc: "Jim Guichard (jguichar)" > Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Further to Jim's points about section 4.10.5, do I read it correctly that t= he SFF can be configured to steer traffic on the basis of these? o Destination MAC address o Source MAC address o VLAN-ID, o Destination IP address o Source IP address o Source port number o Destination port number o DSCP o Packet size, etc., or any combination thereof. This comes totally unexpected to me, thinking that the SFF steers traffic b= ased exclusively on Service Path Identifier and Service Index (SPI/SI), whi= ch oddly aren't in the above list. I can guess that maybe this is about reclassification, but "classification"= isn't mentioned in 4.10.5. Can someone explain? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 10:18 AM To: Martin Stiemerling; sfc@ietf.org Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_0F8583BBE82FA449A8B78417CC07559A09569109SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

    Commen= ts:

 <= /p>

1.  &= nbsp;   There is one sent= ence on OAM in 3.1. This probably deserves a sub-section in section 4 that = covers fault management, alarms, error reporting, switchovers…

 

Note, the SFC control plane must be a= ble to invoke SFC OAM mechanisms, and to determine the results of OAM opera= tions.

 

2.  &= nbsp;   There is no menti= on of metadata in the document. Use of the term ‘metadata’ may = make some text clearer.

For example, there should be a sentence in the 3.3.x= sections for SFC controller to request a particular component to insert/remove/report packet metadata.

 

3.  &= nbsp;   Last para of 3.3.= 2: change ‘An SFF can be instructed…’ to ‘An SFF mu= st be instructed…’

 

4.  &= nbsp;   3.3.3: This parag= raph does not read well:

 

This interface is also used to instruct an S= FC-aware SF about any

context information it needs to supply in th= e context of a given SFC.

Suggest:

This interface may also be used to instruct = an SFC-aware SF to insert, remove or

report metadata information for a given SFC.=

 

5.  &= nbsp;   3.3.3: In several= paragraphs the term ‘contexts’ is used. It may be clearer if &= #8216;metadata’ is used instead.

 

6.  &= nbsp;   Suggest moving th= is paragraph from 4.10.5 to 3.4.4 as it relates specifically to

SFC Proxy functionality. Reworded, this can replace the last se= ntence in 3.3.4:

The C4 interface may also include inf= ormation to map the SFP

Identifier carried in the packet header to a= locally significant link

identifier, e.g., VLAN-ID, and a method to c= onstruct and encapsulate

the SFC header back to the packets when they= come back from the attached SFs.

 <= /p>

7. = ;     Last para of 4.10= .5 typo: classier -> classifier

8. = ;     Last para of 4.10= .5: This could be clearer on what the problem is. Not sure what SFF A and S= FF B are? Would it not be better to recommend a procedure in which the SFC Controller updates downstream SFFs before upstream SFFs w= hen constructing a new SFP. Insertion of a SF into a SFP should have only l= ocal impact on the SFF it is connected to.

 <= /p>

-  &n= bsp;     Louis<= /span>

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee
Sent: Thursday, April 28, 2016 12:03 PM
To: Dave Dolson; sfc@ietf.org
Cc: Jim Guichard (jguichar)
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Dave,

I would also concur that SFF= is a forwarding entity that uses pathID/SI to find the next-hop/next-sf/ne= xt-sff. This is how our SFF works.

 

It is absolutely possible th= at co resident classifier to further classify based on  l3/l4/l7/pytho= n_code and change the path. But logically that is another classification and list below is certainly not exhaustive.  

 

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson <ddolson@sandvine.com>
Date: Thursday, April 28, 2016 at 11:43 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Cc: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Further to Jim’s po= ints about section 4.10.5, do I read it correctly that the SFF can be confi= gured to steer traffic on the basis of these?

   o  Dest= ination MAC address

   o  Sour= ce MAC address

   o  VLAN= -ID,

   o  Dest= ination IP address

   o  Sour= ce IP address

   o  Sour= ce port number

   o  Dest= ination port number

   o  DSCP=

   o  Pack= et size, etc., or any combination thereof.

 

This comes totally unexpe= cted to me, thinking that the SFF steers traffic based exclusively on Servi= ce Path Identifier and Service Index (SPI/SI), which oddly aren’t in the above list.

 

I can guess that maybe th= is is about reclassification, but “classification” isn’t = mentioned in 4.10.5.

Can someone explain?

 

-Dave

 

 

 

From: sfc [mailto:sfc-bou= nces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; sfc@ietf.org=
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

 =

Hi Martin & WG:<= span style=3D"color:black">

 

A few comments that I would= like to see addressed in the document before it can move forward to the ne= xt step.

  • Section 2.2 SFC Control Plane Bootstrapping.=

This section is too wishy w= ashy. It makes the statement “this document assumes the SFC control p= lane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

Minor point -> typo in b= ullet point 6 – SFP proxy should read SFC proxy<= /p>

  • Section 2.3 Coherent Setup of an SFC-enabled Domain

What does the sentence R= 20;various transport encapsulation schemes and/or variations of SFC header = implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or som= ething else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

  • Section 3.1 Reference Architecture

Second bullet point “= mapping between service function chains and SFPs” - this is a general= comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned only o= nce in the entire document. The architecture is explicit in that the SFP wh= en rendered into the network is an RSP and therefore the SFC control plane = element needs to have information on currently deployed RSPs.

 

Additionally there is no in= terface specified for communication between the SFC Control Plane Element a= nd SF management systems. This is an important aspect as many SF’s may require that SFC information be communicated to their = management systems that will be responsible for communicating directly with= their respective SF’s. =

  • Section 3.1.1. C1: Interface between SFC Control Plane & S= FC Classifier

The sentence “The con= trol plane may instruct the classifier about the initial values of the Serv= ice Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. 

  • Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Pac= kets

This section does not actua= lly provide any meaning or indication of relationship with the SFC Control = Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire= section should be removed from the document.

  • Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP

Figure 2 lists 3 different = SFP-id’s whereas the text mentions only SFP-id #1. Is this simply a t= ypo or are you trying to convey something else ?

 

Further you state that R= 20;the steering policies to a SFF node for service function chain depends o= n if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific= ” -  this is an inaccurate statement as the combination of the S= FP-id and service-index determines the forwarding behavior (as specified in= section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

 

Jim

 

 

 

On 4/27/16, 12:29 AM, "= ;sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,

 

This is the start of the Wo= rking Group Last Call (WGLC) for

 

draft-ietf-sfc-control-plan= e-04.txt

 

The WGLC lasts for 2 weeks = and will end May 11th at 10 pm PDT.=

 

Please send your comments a= nd reviews to the sfc@ietf.org list.

 

Regards,

 

   Martin (SFC co= -chair)

 

___________________________= ____________________

sfc mailing list

sfc@ietf.org<= /p>

 

--_000_0F8583BBE82FA449A8B78417CC07559A09569109SJCEML701CHMchi_-- From nobody Thu Apr 28 23:05: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 3C7F612B05A for ; Thu, 28 Apr 2016 23:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 TUPm38a-g6vm for ; Thu, 28 Apr 2016 23:05:52 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEB812B008 for ; Thu, 28 Apr 2016 23:05:52 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id DEBC840D02; Fri, 29 Apr 2016 08:05:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id B30D21A005D; Fri, 29 Apr 2016 08:05:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 08:05:50 +0200 From: To: Dave Dolson , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C2 interface Thread-Index: AdGhdzeqsff0+F4JRSWm8k5GYfJj0QAYB0bQ Date: Fri, 29 Apr 2016 06:05:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D61B4F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D61B4FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C2 interface 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, 29 Apr 2016 06:05:55 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D61B4FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dave, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 28 avril 2016 19:56 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : draft-ietf-sfc-control-plane -- C2 interface In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-= 04#section-3.3.2 the section is: C2: Interface between SFC Control Plane & SFF - There is no mention of being able to instruct the SFF to load-balance an = SFP across multiple (functionally equivalent) SFs This is the service-function-group-name concept in OpenDaylight and in draf= t-penno-sfc-yang-14, as I understand it. Identifying members of a group and identifying a group as a next-hop would = be in the scope of the C2 interface, correct? [Med] This is in scope of C2, that is responsible for populating the SFC Fo= rwarding Policy Table. The current text cites examples of additional to be = used for lookup purposes (excerpt from Section 1.2): Additional information such as a flow identifier, Service Index (SI), and/or other characteristics (e.g., the 5-tuple transport coordinates of the original packet) may be used for lookup purposes. The set of information to use for lookup purposes may be instructed by the control plane. Load balancing is discussed in "Additional Considerations" section. Indeed,= Section 4.10.1 includes the following: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. I suggest to make this change: OLD: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. NEW: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces (C2 interface, typically). Please let me know if further changes are required. - Regarding chain (path?) termination, there should be some mention of how = to forward packets per path after the NSH header is removed. For example, it may be that different paths terminate at different physical= interfaces or at different routing tables. This isn't always relevant, but I would expect it to be in the scope of C2,= no? E.g., for IP encapsulation, "if SPI=3D101 and SI=3D251 then terminate to r= outing table T1" Or, e.g., for Ethernet encapsulation "if SPI=3D200 and SI=3D252 then termin= ate to Ethernet interface eth1" [Med] What about making this change? OLD: An SFF can be instructed to strip the SFC information for the chains it terminates. NEW: An SFF can be instructed to strip the SFC information for the chains it terminates. Forwarding policies for handling packets bound to chains that are terminated by an SFF may be communicated via this interf= ace. That text may be completed with the following sentence to further highlight= that these forwarding instructions are not mandatory: By default, an SFF relies on legacy processing for forwarding these pack= ets. David Dolson Senior Software Architect, Sandvine Inc. --_000_787AE7BB302AE849A7480A190F8B933008D61B4FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Please see inline.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : jeudi 28 avril 2016 19:56
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : draft-ietf-sfc-control-plane -- C2 interface=

 

In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.2

the section is: C2: Interface b= etween SFC Control Plane & SFF

 

- There is no mention of being = able to instruct the SFF to load-balance an SFP across multiple (functional= ly equivalent) SFs

This is the service-function-gr= oup-name concept in OpenDaylight and in draft-penno-sfc-yang-14, as I under= stand it.

Identifying members of a group = and identifying a group as a next-hop would be in the scope of the C2 inter= face, correct?

 

[Med] This is in scope of C2, t= hat is responsible for populating the SFC Forwarding Policy Table. The curr= ent text cites examples of additional to be used for lookup purposes (excerpt from Section 1.2):

 

      Additional informa=
tion such as a flow identifier, Service Index
      (SI), and/or other=
 characteristics (e.g., the 5-tuple transport
      coordinates of the=
 original packet) may be used for lookup
      purposes.  Th=
e set of information to use for lookup purposes may
      be instructed by t=
he control plane.

 

Load balancing is discussed in = “Additional Considerations” section. Indeed, Section 4.10.1 inc= ludes the following:

 

   SF/SFP Load-balancing: &n= bsp; re-construct SFPs to distribute the workload

      among variou= s SF instances.  Particularly, load distribution

      policies can= be taken into account by the Control Element to re-

      compute an S= FP or be provisioned as attributes to SFPs that will

      be ins= talled using the control interfaces.

 

I suggest to make this change:

 

OLD:

   SF/SFP Load-balancing:   r=
e-construct SFPs to distribute the workload
      among various SF i=
nstances.  Particularly, load distribution
      policies can be ta=
ken into account by the Control Element to re-
      compute an SFP or =
be provisioned as attributes to SFPs that will
      be installed using=
 the control interfaces.

 

NEW:

   SF/SFP Load-balancing:   r=
e-construct SFPs to distribute the workload
      among various SF i=
nstances.  Particularly, load distribution
      policies can be ta=
ken into account by the Control Element to re-
      compute an SFP or =
be provisioned as attributes to SFPs that will
      be installed using=
 the control interfaces (C2 interface, typically).

 

Please let me know if further c= hanges are required.

 

- Regarding chain (path?) termi= nation, there should be some mention of how to forward packets per path aft= er the NSH header is removed.

For example, it may be that dif= ferent paths terminate at different physical interfaces or at different rou= ting tables.

This isn’t always relevan= t, but I would expect it to be in the scope of C2, no?

E.g., for IP encapsulation, &nb= sp;“if SPI=3D101 and SI=3D251 then terminate to routing table T1̶= 1;

Or, e.g., for Ethernet encapsul= ation “if SPI=3D200 and SI=3D252 then terminate to Ethernet interface= eth1”

&nbs= p;

[Med] What about making this ch= ange?

OLD:

   An SFF can be instructed to strip th=
e SFC information for the chains
   it terminates.

 


NEW:


   An SFF can be instructed to strip th=
e SFC information for the chains


   it terminates. Forwarding policies f=
or handling packets bound to 


   chains that are terminated by a=
n SFF may be communicated via this interface.


 


That text may be completed with the following sen=
tence to further highlight that these forwarding instructions are not manda=
tory:


 


   By default, an SFF relies on legacy =
processing for forwarding these packets.


      =



&nbs=
p;


David Dolson<=
/p>

Senior Software Architect, Sand=
vine Inc.


 
--_000_787AE7BB302AE849A7480A190F8B933008D61B4FOPEXCLILMA3corp_-- From nobody Thu Apr 28 23:51:13 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 92DD012D535 for ; Thu, 28 Apr 2016 23:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oGQUH-IEjav7 for ; Thu, 28 Apr 2016 23:51:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F8412D4FF for ; Thu, 28 Apr 2016 23:51:08 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 69F8818CB0A; Fri, 29 Apr 2016 08:51:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 46A6927C064; Fri, 29 Apr 2016 08:51:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 08:51:06 +0200 From: To: Dave Dolson , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGhd20GlIfr42rfQei+e06aOHat/gAZcYog Date: Fri, 29 Apr 2016 06:51:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D61B8B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D61B8BOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.29.61516 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface 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, 29 Apr 2016 06:51:11 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D61B8BOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 28 avril 2016 19:57 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : draft-ietf-sfc-control-plane -- C3 interface Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#secti= on-3.3.3 C3: Interface between SFC Control Plane & SFC-aware SFs Shouldn't information about bidirectional paths be in scope for C3 ? [Med] Yes. This is actually covered in https://tools.ietf.org/html/draft-ie= tf-sfc-control-plane-04#section-4.2. The current wording does not recommend= how this bidir will be ensured because this is likely to be SF-specific an= d deployment-specific. E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: "This interface informs the SFC-aware SF about the method for handling bidi= rectional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping." [Med] I'm hesitating to add text about the "algorithmic method" as I don't = have a document to cite. Note that some stateful SFs (e.g., NAT) will natur= ally add a reverse mapping to handle incoming packets without requiring inp= uts from the CP. What do you mean by "providing forward/reverse path mappin= g"? Is it SF-specific mapping? What about adding this NEW text at the end of Section 4.2? NEW: Typically, C2 interface is used to ensure that the same SF instance is involved in both directions of a flow (including, to ensure full chain symmetry). The alternative, in my opinion, is to standardize on an algorithmic method = for computing bidirectional paths. I'm uneasy about C3 carrying information specific to applications, such as "a threat-detecting SF can periodically send the threat characteristic= s via this interface, such as high probability of threat with packet of a given size." This seems like it should be out of scope of C3. Instead I think there woul= d be an application on top of the controller. [Med] The text you quoted is an example to illustrate how a feedback loop m= ay be useful to adjust SFPs. I do see value in having such information avai= lable to the chaining decision engine. Obviously, this text does not exclud= e that this information can be acquired by another dedicated application on= top of a control element. Thoughts? In this paragraph, does "context information" mean metadata? If so, can tha= t be made clear that the SFC is being asked to add metadata to the packet? This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. [Med] FWIW, context information is mentioned in the WG charter "communicate= s context information between nodes that implement". What about this change= to avoid confusion: OLD: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. NEW: This interface is also used to instruct an SFC-aware SF about any context information (a.k.a., metadata) it needs to supply for a given SFC. Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. [Med] I do think the current wording is correct. Having an SFF co-located w= ith a set of SFs is deployment-specific according to the SFC architecture R= FC. (Because although the statement is that the SF doesn't have an SFF in the n= ode, it actually does have the SFF behavior. So call it what it is, an SFF.= ) Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic to the appropriate SF must be supported. Concretely, each SF must have a unique locator for unambiguous forwarding. David Dolson Senior Software Architect, Sandvine Inc. --_000_787AE7BB302AE849A7480A190F8B933008D61B8BOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : jeudi 28 avril 2016 19:57
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : draft-ietf-sfc-control-plane -- C3 interface=

 

Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.3

C3: Interface between SFC Contr= ol Plane & SFC-aware SFs

 

Shouldn’t information abo= ut bidirectional paths be in scope for C3 ?

 

[Med] Yes. This is actually cov= ered in https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-4.2= . The current wording does not recommend how this bidir will be ensured bec= ause this is likely to be SF-specific and deployment-specific.

 

E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt

Maybe add this paragraph:<= /o:p>

“This interface informs t= he SFC-aware SF about the method for handling bidirectional paths,

either by conveying the algorit= hmic method to use, or by providing forward/reverse path

mapping.”

 

[Med] I’m hesitating to a= dd text about the “algorithmic method” as I don’t have a = document to cite. Note that some stateful SFs (e.g., NAT) will naturally add a reverse mapping to handle incoming packets without requiring inputs = from the CP. What do you mean by “providing forward/reverse path mapp= ing”? Is it SF-specific mapping?

 

What about adding this NEW text= at the end of Section 4.2?

 

NEW:

   Typically, C2 inte= rface is used to ensure that the same SF instance

   is involved i= n both directions of a flow (including, to ensure full

   chain symmetr= y). 

   

The alternative, in my opinion,= is to standardize on an algorithmic method for computing bidirectional pat= hs.

 

 

I’m uneasy about C3 carry= ing information specific to applications, such as

    “= a threat-detecting  SF can periodically send the threa= t characteristics via this

      interface, s= uch as high probability of threat with packet of a

      given size.&= #8221;

This seems like it should be ou= t of scope of C3. Instead I think there would be an application on top of t= he controller.

 

[Med] The text you quoted is an= example to illustrate how a feedback loop may be useful to adjust SFPs. I = do see value in having such information available to the chaining decision engine. Obviously, this text does not exclude tha= t this information can be acquired by another dedicated application on top = of a control element.  

 

Thoughts?

 

 

In this paragraph, does “= context information” mean metadata? If so, can that be made clear tha= t the SFC is being asked to add metadata to the packet?

   This interface is also used to instruct an SFC-= aware SF about any

   context information it needs to supply in the c= ontext of a given SFC.

 

[Med] FWIW, context information= is mentioned in the WG charter “communicates context information bet= ween nodes that implement”. What about this change to avoid confusion:

 

OLD:

   This interface is also used to instruct an SFC-= aware SF about any

   context information it needs to supply in the c= ontext of a given SFC.

 

NEW:

   This interface is also used to instruct an SFC-= aware SF about any

   context information (a.k.a., metadata) it needs= to supply

   for a given SFC.

 

 

Regarding this paragraph, I thi= nk it would be cleaner if this behavior actually requires the C2 interface = into the SF.

 

[Med] I do think the current wo= rding is correct. Having an SFF co-located with a set of SFs is deployment-= specific according to the SFC architecture RFC.

 

(Because although the statement= is that the SF doesn’t have an SFF in the node, it actually does hav= e the SFF behavior. So call it what it is, an SFF.)

  Multiple SFs may be located wit= hin the same physical node, and no SFF

   is enabled in that same node, = means to unambiguously forward the

   traffic to the appropriate SF = must be supported.  Concretely, each SF

   must have a unique locator for= unambiguous forwarding.

&nbs= p;

 

David Dolson<= /p>

Senior Software Architect, Sand= vine Inc.

 

--_000_787AE7BB302AE849A7480A190F8B933008D61B8BOPEXCLILMA3corp_-- From nobody Fri Apr 29 00:53: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 5B5AA12D557 for ; Fri, 29 Apr 2016 00:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 jWNzeU50-Mp4 for ; Fri, 29 Apr 2016 00:53:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157BC12D565 for ; Fri, 29 Apr 2016 00:47:02 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 50A2A3B4D9A; Fri, 29 Apr 2016 09:47:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B628F35C060; Fri, 29 Apr 2016 09:46:42 +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.0279.002; Fri, 29 Apr 2016 09:46:42 +0200 From: To: Henry Fourie , Sumandra Majee , Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoD1fSI1yPp+UQ0KhY1xrwASm1p+eIaqAgAGXhUD//+XaAIAAKLKAgAC/UcA= Date: Fri, 29 Apr 2016 07:46:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D61BF4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <0F8583BBE82FA449A8B78417CC07559A09569109@SJCEML701-CHM.china.huawei.com> In-Reply-To: <0F8583BBE82FA449A8B78417CC07559A09569109@SJCEML701-CHM.china.huawei.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.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D61BF4OPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Cc: "Jim Guichard \(jguichar\)" Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 29 Apr 2016 07:53:13 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D61BF4OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Louis, Thank you for the review. Please see inline. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Henry Fourie Envoy=E9 : jeudi 28 avril 2016 23:28 =C0 : Sumandra Majee; Dave Dolson; sfc@ietf.org Cc : Jim Guichard (jguichar) Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt All, Comments: 1. There is one sentence on OAM in 3.1. This probably deserves a sub-= section in section 4 that covers fault management, alarms, error reporting,= switchovers... Note, the SFC control plane must be able to invoke SFC OAM mechanisms, and = to determine the results of OAM operations. [Med] We used to have a dedicated OAM section but the WG decided to move th= at text from the draft (see https://trac.tools.ietf.org/wg/sfc/trac/ticket/= 12). The points you mentioned are good ones but they should be handled in t= he OAM document. 2. There is no mention of metadata in the document. Use of the term '= metadata' may make some text clearer. For example, there should be a sentence in the 3.3.x sections for SFC contr= oller to request a particular component to insert/remove/report packet meta= data. [Med] The document uses "context information" (that is called out in https:= //datatracker.ietf.org/wg/sfc/charter/). I made a change to indicate that "= context information" is also known as "metadata". 3. Last para of 3.3.2: change 'An SFF can be instructed...' to 'An SF= F must be instructed...' [Med] Looks reasonable to me. 4. 3.3.3: This paragraph does not read well: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. Suggest: This interface may also be used to instruct an SFC-aware SF to insert, remo= ve or report metadata information for a given SFC. [Med] The modification mixes several aspects that are covered in other part= s of this section. I made this change: This interface is also used to instruct an SFC-aware SF about any context information (a.k.a., metadata) it needs to supply for a given SF= C. 5. 3.3.3: In several paragraphs the term 'contexts' is used. It may b= e clearer if 'metadata' is used instead. [Med] See above. 6. Suggest moving this paragraph from 4.10.5 to 3.4.4 as it relates s= pecifically to SFC Proxy functionality. Reworded, this can replace the last sentence in 3.= 3.4: The C4 interface may also include information to map the SFP Identifier carried in the packet header to a locally significant link identifier, e.g., VLAN-ID, and a method to construct and encapsulate the SFC header back to the packets when they come back from the attached SF= s. [Med] There is already this text in Section 3.4.4: This interface may also be used to instruct the SFC proxy about the state and information to maintain for proper handling of packets received back from an SFC-unaware SF. 7. Last para of 4.10.5 typo: classier -> classifier [Med] Thank you for catching this. Fixed. 8. Last para of 4.10.5: This could be clearer on what the problem is. [Med] The problem is detailed in the example: "For example, if the SFF "A" = and SFF "C" get flow steering policies at slightly different times, some packets might not be directed to some service functions on a chain." Can you please indicate what is not clear in that text? Thank you. Not sure what SFF A and SFF B are? [Med] These are SFF examples to illustrate the problem. Would it not be better to recommend a procedure in which the SFC Controller= updates downstream SFFs before upstream SFFs when constructing a new SFP. = Insertion of a SF into a SFP should have only local impact on the SFF it is= connected to. [Med] The notion of upstream and downstream SFF depends the chain under con= sideration. So following the recommendation you propose may not be possible= if SFF provisioning/control is achieved for all chains at once, not per ea= ch chain. This decision is deployment-specific. - Louis From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Sumandra Majee Sent: Thursday, April 28, 2016 12:03 PM To: Dave Dolson; sfc@ietf.org Cc: Jim Guichard (jguichar) Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Dave, I would also concur that SFF is a forwarding entity that uses pathID/SI to = find the next-hop/next-sf/next-sff. This is how our SFF works. It is absolutely possible that co resident classifier to further classify b= ased on l3/l4/l7/python_code and change the path. But logically that is an= other classification and list below is certainly not exhaustive. From: sfc > on behalf of = Dave Dolson > Date: Thursday, April 28, 2016 at 11:43 AM To: "sfc@ietf.org" > Cc: "Jim Guichard (jguichar)" > Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Further to Jim's points about section 4.10.5, do I read it correctly that t= he SFF can be configured to steer traffic on the basis of these? o Destination MAC address o Source MAC address o VLAN-ID, o Destination IP address o Source IP address o Source port number o Destination port number o DSCP o Packet size, etc., or any combination thereof. This comes totally unexpected to me, thinking that the SFF steers traffic b= ased exclusively on Service Path Identifier and Service Index (SPI/SI), whi= ch oddly aren't in the above list. I can guess that maybe this is about reclassification, but "classification"= isn't mentioned in 4.10.5. Can someone explain? -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 10:18 AM To: Martin Stiemerling; sfc@ietf.org Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt Hi Martin & WG: A few comments that I would like to see addressed in the document before it= can move forward to the next step. * Section 2.2 SFC Control Plane Bootstrapping. This section is too wishy washy. It makes the statement "this document assu= mes the SFC control plane is provided with a set of information that is req= uired for proper SFC operation" but then goes on to list bullets that are l= ikely to be provided or may be provided. It does not actually provide any i= nformation on what is required for proper SFC operation. In the list of lik= ely information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide gu= idelines on what must be available before the SFC control plane element can= actually function although it is reasonable to assume that it can bootstra= p without any information (albeit it can't actually do anything). On this p= oint I would argue that several of the may elements are actually required s= uch as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the= SFC control plane element, or may be added later through some control inte= rface. Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy * Section 2.3 Coherent Setup of an SFC-enabled Domain What does the sentence "various transport encapsulation schemes and/or vari= ations of SFC header implementations may be supported" actually mean ? Are = we referring to the fact that the SFC header may carry type-1 or type-2 met= adata or something else ? Note that there is only one SFC header implementa= tion based on the WG charter so if we are referring to different SFC format= s (meaning metadata) then please make this clear in the text, and if not, p= lease remove this sentence. * Section 3.1 Reference Architecture Second bullet point "mapping between service function chains and SFPs" - th= is is a general comment for the entire document but applies here also. Ther= e is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only onc= e in the entire document. The architecture is explicit in that the SFP when= rendered into the network is an RSP and therefore the SFC control plane el= ement needs to have information on currently deployed RSPs. Additionally there is no interface specified for communication between the = SFC Control Plane Element and SF management systems. This is an important a= spect as many SF's may require that SFC information be communicated to thei= r management systems that will be responsible for communicating directly wi= th their respective SF's. * Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifi= er The sentence "The control plane may instruct the classifier about the initi= al values of the Service Index (SI)" should be changed to say MUST as other= wise if a classifier chooses whatever value it wants then that may not alig= n with what is programmed into the SFFs by the SFC Control Plane element. * Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets This section does not actually provide any meaning or indication of relatio= nship with the SFC Control Plane element. Furthermore, there has been no W= G consensus to carry source routes within the SFC encapsulation. Therefore = this entire section should be removed from the document. * Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #= 1. Is this simply a typo or are you trying to convey something else ? Further you state that "the steering policies to a SFF node for service fun= ction chain depends on if the packet comes from previous SFF or comes from = a specific SF i.e., the SFP Forwarding Table entries have to be ingress por= t specific" - this is an inaccurate statement as the combination of the SF= P-id and service-index determines the forwarding behavior (as specified in = section 3.3 & section 7 of draft-ietf-sfc-nsh-04). This sentence should be= removed from the text. Jim On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" on behalf of mls.ietf@gmail.com> wrote: Dear all, This is the start of the Working Group Last Call (WGLC) for draft-ietf-sfc-control-plane-04.txt The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT. Please send your comments and reviews to the sfc@ietf.org list. Regards, Martin (SFC co-chair) _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_787AE7BB302AE849A7480A190F8B933008D61BF4OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Louis,

 

Thank you for the review.<= /o:p>

 

Please see inline.

 

Cheers,

Med

 

De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Henry Fourie
Envoy=E9 : jeudi 28 avril 2016 23:28
=C0 : Sumandra Majee; Dave Dolson; sfc@ietf.org
Cc : Jim Guichard (jguichar)
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt<= o:p>

 

All,<= /o:p>

 &nbs= p;  Comments:

 = ;

1.       Th= ere is one sentence on OAM in 3.1. This probably deserves a sub-section in = section 4 that covers fault management, alarms, error reporting, switchovers…

 

Note, the SFC control = plane must be able to invoke SFC OAM mechanisms, and to determine the resul= ts of OAM operations.

 

[Med] We used to have a dedicated OAM section but the= WG decided to move that text from the draft (see https://trac.= tools.ietf.org/wg/sfc/trac/ticket/12). The points you mentioned are goo= d ones but they should be handled in the OAM

document.

 

2.       Th= ere is no mention of metadata in the document. Use of the term ‘metad= ata’ may make some text clearer.

For example, there should be a sente= nce in the 3.3.x sections for SFC controller to request a particular component to insert/remove/report packet metadata.

 

[= Med] The document uses “context information” (that is called ou= t in https://datatracke= r.ietf.org/wg/sfc/charter/). I made a change to indicate that “co= ntext information” is also known as “metadata”.  

<= o:p> 

3.       La= st para of 3.3.2: change ‘An SFF can be instructed…’ to &= #8216;An SFF must be instructed…’

[= Med] Looks reasonable to me.

 

4.       3.= 3.3: This paragraph does not read well:

 

This interface is also used t= o instruct an SFC-aware SF about any

context information it needs = to supply in the context of a given SFC.

Suggest:

This interface may also be us= ed to instruct an SFC-aware SF to insert, remove or

report metadata information f= or a given SFC.

<= o:p> 

[= Med] The modification mixes several aspects that are covered in other parts= of this section. I made this change:

<= o:p> 

   This interface is also used to= instruct an SFC-aware SF about any

   context information (a.k.a., m= etadata) it needs to supply for a given SFC.

 

5.       3.= 3.3: In several paragraphs the term ‘contexts’ is used. It may = be clearer if ‘metadata’ is used instead.

[= Med] See above.

 

6.       Su= ggest moving this paragraph from 4.10.5 to 3.4.4 as it relates specifically= to

SFC Proxy functionality. Reworded, this can repl= ace the last sentence in 3.3.4:

The C4 interface may a= lso include information to map the SFP

Identifier carried in the pac= ket header to a locally significant link

identifier, e.g., VLAN-ID, an= d a method to construct and encapsulate

the SFC header back to the pa= ckets when they come back from the attached SFs.

 <= /o:p>

[Med] There is already this tex= t in Section 3.4.4:

 

   This interface may also be used to i=
nstruct the SFC proxy about the
   state and information to maintain fo=
r proper handling of packets
   received back from an SFC-unaware SF=
.

 

7.       La= st para of 4.10.5 typo: classier -> classifier

[Med] Thank you for catching th= is. Fixed.

 

 

8.       La= st para of 4.10.5: This could be clearer on what the problem is.= 

[Med] The problem is detail=
ed in the example: “For example, if the S=
FF "A" and SFF "C" get flow
   steering policies at slightly differ=
ent times, some packets might not
   be directed to some service function=
s on a chain.”

 

Can you please indicate what is= not clear in that text? Thank you.

 

Not sure what SFF A and SFF B are?

[Med] These are SFF examples to= illustrate the problem.

 

Would it not be better to recommend a procedure in which= the SFC Controller updates downstream SFFs before upstream SFFs when constructing a new SFP. Insertion of a SF into a SFP should have= only local impact on the SFF it is connected to.

[Med] The notion of upstream an= d downstream SFF depends the chain under consideration. So following the re= commendation you propose may not be possible if SFF provisioning/control is achieved for all chains at once, not per each = chain. This decision is deployment-specific.

 = ;

-Lo= uis

 

From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Sumandra Majee
Sent: Thursday, April 28, 2016 12:03 PM
To: Dave Dolson; sfc@ietf.org Cc: Jim Guichard (jguichar)
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Dave,

I would also = concur that SFF is a forwarding entity that uses pathID/SI to find the next= -hop/next-sf/next-sff. This is how our SFF works.

 

It is absolut= ely possible that co resident classifier to further classify based on  = ;l3/l4/l7/python_code and change the path. But logically that is another classification and list below is certainly not exhaustive.  <= o:p>

 

From: sfc <sfc-bounces@ietf.org> on behalf of Dave Dols= on <ddolson@sandvine.com>=
Date: Thursday, April 28, 2016 at 11:43 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Cc: "Jim Guichard (jguichar)" <jguichar@cisco.com>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt=

 

Further to= Jim’s points about section 4.10.5, do I read it correctly that the S= FF can be configured to steer traffic on the basis of these?

 &nbs= p; o  Destination MAC address

 &nbs= p; o  Source MAC address

 &nbs= p; o  VLAN-ID,<= /o:p>

 &nbs= p; o  Destination IP address

 &nbs= p; o  Source IP address

 &nbs= p; o  Source port number

 &nbs= p; o  Destination port number

 &nbs= p; o  DSCP

 &nbs= p; o  Packet size, etc., or any combination thereof.

 

This comes= totally unexpected to me, thinking that the SFF steers traffic based exclu= sively on Service Path Identifier and Service Index (SPI/SI), which oddly aren’t in the above list.

 

I can gues= s that maybe this is about reclassification, but “classification̶= 1; isn’t mentioned in 4.10.5.

Can someon= e explain?

 

-Dave

 

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; sfc@ietf.org=
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

 

Hi Martin &a= mp; WG:=

 

A few commen= ts that I would like to see addressed in the document before it can move fo= rward to the next step.

  • Section 2.2 SFC Control Plane Bootstrapping.

This section= is too wishy washy. It makes the statement “this document assumes th= e SFC control plane is provided with a set of information that is required for proper SFC operation” but then goes on to list bu= llets that are likely to be provided or may be provided. It does n= ot actually provide any information on what is required for proper SFC operation. In the list of likely&n= bsp;information there is no indication of whether this information must exi= st in the network prior to bootstrapping the SFC control plane element; thi= s is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actual= ly function although it is reasonable to assume that it can bootstrap witho= ut any information (albeit it can’t actually do anything). On this point I would argue that several of the may&n= bsp;elements are actually required such as SFF, SF, SFC-proxy locators and = may exist prior to bootstrapping the SFC control plane element, or may be a= dded later through some control interface. 

 

Minor point = -> typo in bullet point 6 – SFP proxy should read SFC proxy

  • Section 2.3 Coherent Setup of an SFC-enabled Do= main

What does th= e sentence “various transport encapsulation schemes and/or variations= of SFC header implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-= 2 metadata or something else ? Note that there is only one SFC header implementation based on the WG charter so if we are r= eferring to different SFC formats (meaning metadata) then please make this = clear in the text, and if not, please remove this sentence. 

  • Section 3.1 Reference Architecture

Second bulle= t point “mapping between service function chains and SFPs” - th= is is a general comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is ment= ioned only once in the entire document. The architecture is explicit in tha= t the SFP when rendered into the network is an RSP and therefore the SFC co= ntrol plane element needs to have information on currently deployed RSPs.

 

Additionally= there is no interface specified for communication between the SFC Control = Plane Element and SF management systems. This is an important aspect as many SF’s may require that SFC information be communicated= to their management systems that will be responsible for communicating dir= ectly with their respective SF’s. 

  • Section 3.1.1. C1: Interface between SFC Contro= l Plane & SFC Classifier<= /li>

The sentence= “The control plane may instruct the classifier about the initial val= ues of the Service Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wan= ts then that may not align with what is programmed into the SFFs by the SFC= Control Plane element. = ;

  • Section 4.10.4. Encoding the Exact SFF/SF Seque= nce in Data Packets

This section= does not actually provide any meaning or indication of relationship with t= he SFC Control Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. There= fore this entire section should be removed from the document.

  • Section 4.10.5. Fully Controlled SFF/SF Sequenc= e for a SFP

Figure 2 lis= ts 3 different SFP-id’s whereas the text mentions only SFP-id #1. Is = this simply a typo or are you trying to convey something else ?

 

Further you = state that “the steering policies to a SFF node for service function = chain depends on if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingre= ss port specific” -  this is an inaccurate statement as the comb= ination of the SFP-id and service-index determines the forwarding behavior = (as specified in section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the tex= t.

 

Jim

 

 

 

On 4/27/16, = 12:29 AM, "sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org on behalf of mls.ietf@gmail.com> wrote:

 

Dear all,

 

This is the = start of the Working Group Last Call (WGLC) for

 

draft-ietf-s= fc-control-plane-04.txt

 

The WGLC las= ts for 2 weeks and will end May 11th at 10 pm PDT.

 

Please send = your comments and reviews to the sfc@ietf.org list.

 

Regards,

 

  = Martin (SFC co-chair)

 

____________= ___________________________________

sfc mailing = list

 

--_000_787AE7BB302AE849A7480A190F8B933008D61BF4OPEXCLILMA3corp_-- From nobody Fri Apr 29 00:55:21 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 5FFAD12D59C for ; Fri, 29 Apr 2016 00:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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=-0.996, 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 ow8lAxaopPp6 for ; Fri, 29 Apr 2016 00:55:17 -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 BD22012D6E7 for ; Fri, 29 Apr 2016 00:53:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNN80342; Fri, 29 Apr 2016 07:53:57 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 29 Apr 2016 08:53:56 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 29 Apr 2016 15:53:45 +0800 From: Qin Wu To: "Huangyong (Oliver)" , Martin Stiemerling , "sfc@ietf.org" Thread-Topic: [sfc] RE: WGLC for draft-ietf-sfc-control-plane-04.txt Thread-Index: AQHRoexABGAcurNnsku+qCdV5uGkeQ== Date: Fri, 29 Apr 2016 07:53:44 +0000 Message-ID: References: <65e5a067-8d94-2632-506f-9f2d60dabeaf@gmail.com> <8172B566C79A4A4C8EB6C7B1F6529EFC8B7435C1@szxema506-mbx.china.huawei.com> In-Reply-To: <8172B566C79A4A4C8EB6C7B1F6529EFC8B7435C1@szxema506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.183] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57231315.00E4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ce719da7d1a4693c6ea2fcec8d81a96d Archived-At: Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.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, 29 Apr 2016 07:55:19 -0000 KzEuDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gSHVhbmd5b25nIChPbGl2ZXIpDQq3osvNyrG85DogMjAxNsTqNNTCMjjI 1SA5OjA2DQrK1bz+yMs6IE1hcnRpbiBTdGllbWVybGluZzsgc2ZjQGlldGYub3JnDQrW98ziOiBb c2ZjXSC08Li0OiBXR0xDIGZvciBkcmFmdC1pZXRmLXNmYy1jb250cm9sLXBsYW5lLTA0LnR4dA0K DQpEZWFyIE1hcnRpbiwNCg0KICAgIEFzIHRoZSBlYXJseSB2ZXJzaW9uIGF1dGhvciBvZiB0aGUg ZHJhZnQuICBJIHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhpcyBkcmFmdC4NCg0KQlINCk9saXZl cg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gTWFydGluIFN0aWVtZXJsaW5nDQq3osvNyrG85DogMjAxNsTqNNTCMjfI 1SAxMjoyOQ0KytW8/sjLOiBzZmNAaWV0Zi5vcmcNCtb3zOI6IFtzZmNdIFdHTEMgZm9yIGRyYWZ0 LWlldGYtc2ZjLWNvbnRyb2wtcGxhbmUtMDQudHh0DQoNCkRlYXIgYWxsLA0KDQpUaGlzIGlzIHRo ZSBzdGFydCBvZiB0aGUgV29ya2luZyBHcm91cCBMYXN0IENhbGwgKFdHTEMpIGZvcg0KDQpkcmFm dC1pZXRmLXNmYy1jb250cm9sLXBsYW5lLTA0LnR4dA0KDQpUaGUgV0dMQyBsYXN0cyBmb3IgMiB3 ZWVrcyBhbmQgd2lsbCBlbmQgTWF5IDExdGggYXQgMTAgcG0gUERULg0KDQpQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIGFuZCByZXZpZXdzIHRvIHRoZSBzZmNAaWV0Zi5vcmcgbGlzdC4NCg0KUmVn YXJkcywNCg0KICAgTWFydGluIChTRkMgY28tY2hhaXIpDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Fri Apr 29 05:56: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 6ABA312D12B for ; Fri, 29 Apr 2016 05:56:06 -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 hE54q-_uVZZW for ; Fri, 29 Apr 2016 05:56:04 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D911A12B01A for ; Fri, 29 Apr 2016 05:56:03 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a17so34987707wme.0 for ; Fri, 29 Apr 2016 05:56:03 -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=OWsfTryStnjH7gjnlZadEukJ7uiYuZ/ah1uE4rnhOus=; b=CDvRDyj1aXwJn7/5bEt08ZxyNtms2LBDrmNdCJ5SFeX1d4QDziNrfE+C246qCuhWl0 HDKCgYqseyk5OY+pmUsnTomtvAtefKZwKGYXx6ZPkQuE37IGiXuMlCBqbdk2k7npBTxY zFR1VQ658yYs0B8xBqxzHRMVx1/qheA06+Kvjw+eHlBpolSWp28bh+7HYc0gkLoOEfc5 SlBGXTlVJsYfcW4+toccF3Mkn6Y4/j/526I37ZSz+PAYO9m/NYooUdPU4KUOHV2Grne8 fE2o6eVqvXx8fts/7m9puCQd5NKHW+3Buu3ZUwZWamueG3XwUN6vw2984mh+xbVCLPeb 6mvA== 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=OWsfTryStnjH7gjnlZadEukJ7uiYuZ/ah1uE4rnhOus=; b=jp7Q/d4TsSVuhG2uaiZ7gF73IfSO8bf+ZfTYzrXu63Ga8xVM+7UJYwfugH9KAOy6en Npk8drwACWE10OfghRvmfwVXjGZHBqL0wc9pb7x3rRex4+E4X/yHRjMUNqlG8WZ9JN0Y d3g010GTBeaFDh2+z2pMR5pmF3F/5wcf5u95/peevq70jKHo4DD8oOkT+iT8kM2cSIyL 14oKQ+md99f9AIoYO5bkQi2Pq1d/JaGQO8KlHbOukhpxhT4k2QX/7xA8hdz8AHoiLwOL cf3wC0xO3mHmatwiZka0C8k7cumBMpoym7+8HEth2ygG7zV+yUtqCcmWjFZYJxOReLoL PiPg== X-Gm-Message-State: AOPr4FWTpp63UvJ8/zLvj32dTJhCSdApwHlpFO0p6j5f1V9+gEkhm9ut27Iq6VR5oKx/Ig== X-Received: by 10.28.5.85 with SMTP id 82mr4058283wmf.26.1461934562508; Fri, 29 Apr 2016 05:56:02 -0700 (PDT) Received: from mn-mn0F.local (tmo-099-74.customers.d1-online.com. [80.187.99.74]) by smtp.googlemail.com with ESMTPSA id jr8sm14711664wjb.15.2016.04.29.05.56.00 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 05:56:01 -0700 (PDT) To: sfc@ietf.org From: Martin Stiemerling Message-ID: Date: Fri, 29 Apr 2016 14:55:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Draft minutes SFC session @ IETF-95 in Buenos Airs 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, 29 Apr 2016 12:56:06 -0000 Dear all, Please find the draft minutes of the SFC session @ IETF-95 in Buenos Aires online: https://www.ietf.org/proceedings/95/minutes/minutes-95-sfc Let us know if something is missing, etc. Thanks to Dhruv Dhody for taking the notes! Regards, Martin From nobody Fri Apr 29 06:57:53 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 4FA6D12D69C for ; Fri, 29 Apr 2016 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 bUZTerLWNbwC for ; Fri, 29 Apr 2016 06:57:48 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0171712D6A1 for ; Fri, 29 Apr 2016 06:57:30 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Fri, 29 Apr 2016 09:57:30 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C2 interface Thread-Index: AdGhdzeqsff0+F4JRSWm8k5GYfJj0QAYB0bQABE7GWA= Date: Fri, 29 Apr 2016 13:57:30 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D61B4F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D61B4F@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F45AADwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C2 interface 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, 29 Apr 2016 13:57:51 -0000 --_000_E8355113905631478EFF04F5AA706E9830F45AADwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Med, Please see inline [DD] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, April 29, 2016 2:06 AM To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C2 interface Hi Dave, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 28 avril 2016 19:56 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : draft-ietf-sfc-control-plane -- C2 interface In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-= 04#section-3.3.2 the section is: C2: Interface between SFC Control Plane & SFF - There is no mention of being able to instruct the SFF to load-balance an = SFP across multiple (functionally equivalent) SFs This is the service-function-group-name concept in OpenDaylight and in draf= t-penno-sfc-yang-14, as I understand it. Identifying members of a group and identifying a group as a next-hop would = be in the scope of the C2 interface, correct? [Med] This is in scope of C2, that is responsible for populating the SFC Fo= rwarding Policy Table. The current text cites examples of additional to be = used for lookup purposes (excerpt from Section 1.2): Additional information such as a flow identifier, Service Index (SI), and/or other characteristics (e.g., the 5-tuple transport coordinates of the original packet) may be used for lookup purposes. The set of information to use for lookup purposes may be instructed by the control plane. Load balancing is discussed in "Additional Considerations" section. Indeed,= Section 4.10.1 includes the following: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. [DD] This is in a section that seems to be about the controller making adju= stments to move work-load to different paths. I'm concerned with the case w= hen traffic of a single path is load-balanced across multiple workers in a = dynamic manner that doesn't require controller micro-management. [DD] To help clarify, it might be useful to think of the SFF having multipl= e next-hop entries for the same SPI/SI pair; as with ECMP routing or LAG, a= local decision selects which to use. I suggest to make this change: OLD: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. NEW: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces (C2 interface, typically). Please let me know if further changes are required. [DD] Although this change is correct, it doesn't address my concern. I woul= d like to see language in section 3.3.2. [DD] Perhaps, "The C2 interface may be used to configure groups of function= ally equivalent SFs that may service a path." - Regarding chain (path?) termination, there should be some mention of how = to forward packets per path after the NSH header is removed. For example, it may be that different paths terminate at different physical= interfaces or at different routing tables. This isn't always relevant, but I would expect it to be in the scope of C2,= no? E.g., for IP encapsulation, "if SPI=3D101 and SI=3D251 then terminate to r= outing table T1" Or, e.g., for Ethernet encapsulation "if SPI=3D200 and SI=3D252 then termin= ate to Ethernet interface eth1" [Med] What about making this change? OLD: An SFF can be instructed to strip the SFC information for the chains it terminates. NEW: An SFF can be instructed to strip the SFC information for the chains it terminates. Forwarding policies for handling packets bound to chains that are terminated by an SFF may be communicated via this interf= ace. That text may be completed with the following sentence to further highlight= that these forwarding instructions are not mandatory: By default, an SFF relies on legacy processing for forwarding these pack= ets. [DD] OK, looks good. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F45AADwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Med,=

Please see inline [DD]=

 

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, April 29, 2016 2:06 AM
To: Dave Dolson; sfc@ietf.org
Subject: RE: draft-ietf-sfc-control-plane -- C2 interface=

 

Hi Dave,

 

Please see inline.

 

Cheers,

Med

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : jeudi 28 avril 2016 19:56
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : draft-ietf-sfc-control-plane -- C2 interface=

 

In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.2

the section is: C2: Interface between SFC Control Pl= ane & SFF

 

- There is no mention of being able to instruct the = SFF to load-balance an SFP across multiple (functionally equivalent) SFs

This is the service-function-group-name concept in O= penDaylight and in draft-penno-sfc-yang-14, as I understand it.<= /p>

Identifying members of a group and identifying a gro= up as a next-hop would be in the scope of the C2 interface, correct?

 

[Med] This is in scope of C2, that is responsi= ble for populating the SFC Forwarding Policy Table. The current text cites = examples of additional to be used for lookup purposes (excerpt from Section 1.2):

 

      Additional information such as a flow i=
dentifier, Service Index
      (SI), and/or other characteristics (e.g=
., the 5-tuple transport
      coordinates of the original packet) may=
 be used for lookup
      purposes.  The set of information =
to use for lookup purposes may
      be instructed by the control plane.

 

Load balancing is discussed in “Addition= al Considerations” section. Indeed, Section 4.10.1 includes the follo= wing:

 

   SF/SFP Load-balancing:   re-constru= ct SFPs to distribute the workload

      among various SF instances.=   Particularly, load distribution

      policies can be taken into = account by the Control Element to re-

      compute an SFP or be provisioned as attributes to SFPs that will

      be installed using th= e control interfaces.

[DD] This is in a sect= ion that seems to be about the controller making adjustments to move work-l= oad to different paths. I’m concerned with the case when traffic of a= single path is load-balanced across multiple workers in a dynamic manner that doesn’t require controller micro-ma= nagement.

[DD] To help clarify, = it might be useful to think of the SFF having multiple next-hop entries for= the same SPI/SI pair; as with ECMP routing or LAG, a local decision select= s which to use.

 

I suggest to make this change:

 

OLD:

   SF/SFP Load-balancing:   re-construct SFPs to d=
istribute the workload
      among various SF instances.  Parti=
cularly, load distribution
      policies can be taken into account by t=
he Control Element to re-
      compute an SFP or be provisioned as att=
ributes to SFPs that will
      be installed using the control interfac=
es.

 

NEW:

   SF/SFP Load-balancing:   re-construct SFPs to d=
istribute the workload
      among various SF instances.  Parti=
cularly, load distribution
      policies can be taken into account by t=
he Control Element to re-
      compute an SFP or be provisioned as att=
ributes to SFPs that will
      be installed using the control interfac=
es (C2 interface, typically).

 

Please let me know if further changes are requ= ired.

[DD] Although this cha= nge is correct, it doesn’t address my concern. I would like to see la= nguage in section 3.3.2.

[DD] Perhaps, “T= he C2 interface may be used to configure groups of functionally equivalent = SFs that may service a path.”

 

- Regarding chain (path?) termination, there should = be some mention of how to forward packets per path after the NSH header is = removed.

For example, it may be that different paths terminat= e at different physical interfaces or at different routing tables.

This isn’t always relevant, but I would expect= it to be in the scope of C2, no?

E.g., for IP encapsulation,  “if SPI=3D10= 1 and SI=3D251 then terminate to routing table T1”

Or, e.g., for Ethernet encapsulation “if SPI= =3D200 and SI=3D252 then terminate to Ethernet interface eth1”

 =

[Med] What about making this change?

OLD:

   An SFF can be instructed to strip the SFC information for=
 the chains
   it terminates.

 

NEW:

   An SFF can be instructed to strip the SFC information for=
 the chains
   it terminates. Forwarding policies for handling packets b=
ound to 
   chains that are terminated by an SFF may be communic=
ated via this interface.
 
That text may be completed with the following sentence to further high=
light that these forwarding instructions are not mandatory:

 


   By default, an SFF relies on legacy processing for forwar=
ding these packets.


[DD] OK, looks good.   =
   


 =



David Dolson


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

 
--_000_E8355113905631478EFF04F5AA706E9830F45AADwtlexchp2sandvi_-- From nobody Fri Apr 29 07:24:22 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 2CD0B12D64E for ; Fri, 29 Apr 2016 07:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 fFKJYR2U29jG for ; Fri, 29 Apr 2016 07:24:17 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1016B12D0EF for ; Fri, 29 Apr 2016 07:24:17 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Fri, 29 Apr 2016 10:24:16 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGhd20GlIfr42rfQei+e06aOHat/gAZcYogABCNidA= Date: Fri, 29 Apr 2016 14:24:15 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D61B8B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D61B8B@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F45BFEwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface 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, 29 Apr 2016 14:24:20 -0000 --_000_E8355113905631478EFF04F5AA706E9830F45BFEwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [DD] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, April 29, 2016 2:51 AM To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C3 interface Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 28 avril 2016 19:57 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : draft-ietf-sfc-control-plane -- C3 interface Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#secti= on-3.3.3 C3: Interface between SFC Control Plane & SFC-aware SFs Shouldn't information about bidirectional paths be in scope for C3 ? [Med] Yes. This is actually covered in https://tools.ietf.org/html/draft-ie= tf-sfc-control-plane-04#section-4.2. The current wording does not recommend= how this bidir will be ensured because this is likely to be SF-specific an= d deployment-specific. E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: "This interface informs the SFC-aware SF about the method for handling bidi= rectional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping." [Med] I'm hesitating to add text about the "algorithmic method" as I don't = have a document to cite. Note that some stateful SFs (e.g., NAT) will natur= ally add a reverse mapping to handle incoming packets without requiring inp= uts from the CP. What do you mean by "providing forward/reverse path mappin= g"? Is it SF-specific mapping? [DD] I agree there is a lack of material to cite... [DD] What I mean is informing the SF that "path X is the complementary path= of path Y". E.g., "Paths 100 (upstream) and 101 (downstream) are pairs. Re= spond to a path-100 packet on path 101." What about adding this NEW text at the end of Section 4.2? NEW: Typically, C2 interface is used to ensure that the same SF instance is involved in both directions of a flow (including, to ensure full chain symmetry). [DD] I disagree that C2 has anything to do with this. Instead, C1 must be u= sed to provide consistent classification. [DD] How about adding the generic statement to section 3.3.3, "Some SFs may= need to be configured regarding the rules for packet reversal on a path. T= he controller may use the C3 interface to specify how packets on a path may= be placed on the reverse path." The alternative, in my opinion, is to standardize on an algorithmic method = for computing bidirectional paths. I'm uneasy about C3 carrying information specific to applications, such as "a threat-detecting SF can periodically send the threat characteristic= s via this interface, such as high probability of threat with packet of a given size." This seems like it should be out of scope of C3. Instead I think there woul= d be an application on top of the controller. [Med] The text you quoted is an example to illustrate how a feedback loop m= ay be useful to adjust SFPs. I do see value in having such information avai= lable to the chaining decision engine. Obviously, this text does not exclud= e that this information can be acquired by another dedicated application on= top of a control element. Thoughts? In this paragraph, does "context information" mean metadata? If so, can tha= t be made clear that the SFC is being asked to add metadata to the packet? This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. [Med] FWIW, context information is mentioned in the WG charter "communicate= s context information between nodes that implement". What about this change= to avoid confusion: OLD: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. NEW: This interface is also used to instruct an SFC-aware SF about any context information (a.k.a., metadata) it needs to supply for a given SFC. [DD] Again, is this intended to mean adding information to a packet? Or is = "supply" intentionally vague about the delivery mechanism? Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. [Med] I do think the current wording is correct. Having an SFF co-located w= ith a set of SFs is deployment-specific according to the SFC architecture R= FC. [DD] I agree with that statement. However, I think the case being described= is when there *is* a co-located SFF, but the text is pretending there isn'= t. If the following text remains, C3 will need to include all the functiona= lity of C2. (Because although the statement is that the SF doesn't have an SFF in the n= ode, it actually does have the SFF behavior. So call it what it is, an SFF.= ) Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic to the appropriate SF must be supported. Concretely, each SF must have a unique locator for unambiguous forwarding. David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830F45BFEwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please see inline [DD]=

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, April 29, 2016 2:51 AM
To: Dave Dolson; sfc@ietf.org
Subject: RE: draft-ietf-sfc-control-plane -- C3 interface=

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : jeudi 28 avril 2016 19:57
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : draft-ietf-sfc-control-plane -- C3 interface=

 

Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.3

C3: Interface between SFC Control Plane & SFC-aw= are SFs

 

Shouldn’t information about bidirectional path= s be in scope for C3 ?

 

[Med] Yes. This is actually covered in https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-4.2= . The current wording does not recommend how this bidir will be ensured bec= ause this is likely to be SF-specific and deployment-specific.

 

E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt

Maybe add this paragraph:

“This interface informs the SFC-aware SF about= the method for handling bidirectional paths,

either by conveying the algorithmic method to use, o= r by providing forward/reverse path

mapping.”

 

[Med] I’m hesitating to add text about t= he “algorithmic method” as I don’t have a document to cit= e. Note that some stateful SFs (e.g., NAT) will naturally add a reverse mapping to handle incoming packets without requiring inputs from the CP. W= hat do you mean by “providing forward/reverse path mapping”? Is= it SF-specific mapping?

 

[DD] I agree there is = a lack of material to cite…

[DD] What I mean is in= forming the SF that “path X is the complementary path of path Y”= ;. E.g., “Paths 100 (upstream) and 101 (downstream) are pairs. Respon= d to a path-100 packet on path 101.”

 

What about adding this NEW text at the end of = Section 4.2?

 

NEW:

   Typically, C2 interface is used t= o ensure that the same SF instance

   is involved in both directio= ns of a flow (including, to ensure full

   chain symmetry).

[DD] I disagree that C= 2 has anything to do with this. Instead, C1 must be used to provide consist= ent classification.

[DD] How about adding = the generic statement to section 3.3.3, “Some SFs may need to be conf= igured regarding the rules for packet reversal on a path. The controller ma= y use the C3 interface to specify how packets on a path may be placed on the reverse path.”

   

The alternative, in my opinion, is to standardize on= an algorithmic method for computing bidirectional paths.

 

 

I’m uneasy about C3 carrying information speci= fic to applications, such as

    “a threat-detecting  SF= can periodically send the threat characteristics via this

      interface, such as high pro= bability of threat with packet of a

      given size.”

This seems like it should be out of scope of C3. Ins= tead I think there would be an application on top of the controller.

 

[Med] The text you quoted is an example to ill= ustrate how a feedback loop may be useful to adjust SFPs. I do see value in= having such information available to the chaining decision engine. Obviously, this text does not exclude that this informati= on can be acquired by another dedicated application on top of a control ele= ment.  

 

Thoughts?

 

 

In this paragraph, does “context information&#= 8221; mean metadata? If so, can that be made clear that the SFC is being as= ked to add metadata to the packet?

=    This interface is also used to instruct an SFC-aware SF about = any

=    context information it needs to supply in the context of a giv= en SFC.

 

[Med] FWIW, context information is mentioned i= n the WG charter “communicates context information between nodes that= implement”. What about this change to avoid confusion:

 

OLD:

=    This interface is also used to instruct an SFC-aware SF about = any

=    context information it needs to supply in the context of a giv= en SFC.

 

NEW:

=    This interface is also used to instruct an SFC-aware SF about = any

=    context information (a.k.a., metadata) it needs to supply

=    for a given SFC.

[DD] Again, is this in= tended to mean adding information to a packet? Or is “supply” i= ntentionally vague about the delivery mechanism?

 

 

Regarding this paragraph, I think it would be cleane= r if this behavior actually requires the C2 interface into the SF.

 

[Med] I do think the current wording is correc= t. Having an SFF co-located with a set of SFs is deployment-specific accord= ing to the SFC architecture RFC.

[DD] I agree with that= statement. However, I think the case being described is when there *is<= /b>* a co-located SFF, but the text is pretending there isn’t. If the= following text remains, C3 will need to include all the functionality of C2.=

(Because although the statement is that the SF doesn= ’t have an SFF in the node, it actually does have the SFF behavior. S= o call it what it is, an SFF.)

  Multiple SFs may be located within the same ph= ysical node, and no SFF

   is enabled in that same node, means to unambi= guously forward the

   traffic to the appropriate SF must be support= ed.  Concretely, each SF

   must have a unique locator for unambiguous fo= rwarding.

 =

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830F45BFEwtlexchp2sandvi_-- From nobody Fri Apr 29 07:32: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 1F0D512D178 for ; Fri, 29 Apr 2016 07:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 GxXNxjCNFbX7 for ; Fri, 29 Apr 2016 07:32:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C12712D14D for ; Fri, 29 Apr 2016 07:32:15 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 7D1D120F2B; Fri, 29 Apr 2016 16:32:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49DAF120059; Fri, 29 Apr 2016 16:32:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 16:32:13 +0200 From: To: Dave Dolson , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C2 interface Thread-Index: AdGhdzeqsff0+F4JRSWm8k5GYfJj0QAYB0bQABE7GWAAAcgu4A== Date: Fri, 29 Apr 2016 14:32:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D61FA2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933008D61B4F@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D61FA2OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C2 interface 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, 29 Apr 2016 14:32:18 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D61FA2OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 15:57 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C2 interface Med, Please see inline [DD] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, April 29, 2016 2:06 AM To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C2 interface Hi Dave, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 28 avril 2016 19:56 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : draft-ietf-sfc-control-plane -- C2 interface In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-= 04#section-3.3.2 the section is: C2: Interface between SFC Control Plane & SFF - There is no mention of being able to instruct the SFF to load-balance an = SFP across multiple (functionally equivalent) SFs This is the service-function-group-name concept in OpenDaylight and in draf= t-penno-sfc-yang-14, as I understand it. Identifying members of a group and identifying a group as a next-hop would = be in the scope of the C2 interface, correct? [Med] This is in scope of C2, that is responsible for populating the SFC Fo= rwarding Policy Table. The current text cites examples of additional to be = used for lookup purposes (excerpt from Section 1.2): Additional information such as a flow identifier, Service Index (SI), and/or other characteristics (e.g., the 5-tuple transport coordinates of the original packet) may be used for lookup purposes. The set of information to use for lookup purposes may be instructed by the control plane. Load balancing is discussed in "Additional Considerations" section. Indeed,= Section 4.10.1 includes the following: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. [DD] This is in a section that seems to be about the controller making adju= stments to move work-load to different paths. I'm concerned with the case w= hen traffic of a single path is load-balanced across multiple workers in a = dynamic manner that doesn't require controller micro-management. [DD] To help clarify, it might be useful to think of the SFF having multipl= e next-hop entries for the same SPI/SI pair; as with ECMP routing or LAG, a= local decision selects which to use. I suggest to make this change: OLD: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. NEW: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces (C2 interface, typically). Please let me know if further changes are required. [DD] Although this change is correct, it doesn't address my concern. I woul= d like to see language in section 3.3.2. [DD] Perhaps, "The C2 interface may be used to configure groups of function= ally equivalent SFs that may service a path." [Med] Ok, what about this NEW text? The C2 interface may be used to configure groups of functionally equivalent SFs. In particular, this group may be used for load- balancing purposes. --_000_787AE7BB302AE849A7480A190F8B933008D61FA2OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 15:57
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C2 interface

 

Med,

Please = see inline [DD]

&n= bsp;

&n= bsp;

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, April 29, 2016 2:06 AM
To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C2 interface=

 

Hi Dave,

 

Please see inline.

 

Cheers,

Med

 

De : Dave= Dolson [mailto:ddolson@sandvine.co= m]
Envoy=E9 : jeudi 28 avril 2016 19:56
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : draft-ietf-sfc-control-plane -- C2 interface=

 

In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.2

the section is: C2: Interface b= etween SFC Control Plane & SFF

 

- There is no mention of being = able to instruct the SFF to load-balance an SFP across multiple (functional= ly equivalent) SFs

This is the service-function-gr= oup-name concept in OpenDaylight and in draft-penno-sfc-yang-14, as I under= stand it.

Identifying members of a group = and identifying a group as a next-hop would be in the scope of the C2 inter= face, correct?

 

[Med] This is in scope of C2, t= hat is responsible for populating the SFC Forwarding Policy Table. The curr= ent text cites examples of additional to be used for lookup purposes (excerpt from Section 1.2):

 

      Additional information such as=
 a flow identifier, Service Index
      (SI), and/or other characteris=
tics (e.g., the 5-tuple transport
      coordinates of the original pa=
cket) may be used for lookup
      purposes.  The set of inf=
ormation to use for lookup purposes may
      be instructed by the control p=
lane.

 

Load balancing is discussed in = “Additional Considerations” section. Indeed, Section 4.10.1 inc= ludes the following:

 

   SF/SFP Load-balancing: &n= bsp; re-construct SFPs to distribute the workload

      among variou= s SF instances.  Particularly, load distribution

      policies can= be taken into account by the Control Element to re-

      compute an S= FP or be provisioned as attributes to SFPs that will

      be ins= talled using the control interfaces.

[DD] Th= is is in a section that seems to be about the controller making adjustments= to move work-load to different paths. I’m concerned with the case wh= en traffic of a single path is load-balanced across multiple workers in a dynamic manner that doesn’t require con= troller micro-management.

[DD] To= help clarify, it might be useful to think of the SFF having multiple next-= hop entries for the same SPI/SI pair; as with ECMP routing or LAG, a local = decision selects which to use.

&n= bsp;

I suggest to make this change:

 

OLD:

   SF/SFP Load-balancing:   re-construct =
SFPs to distribute the workload
      among various SF instances.&nb=
sp; Particularly, load distribution
      policies can be taken into acc=
ount by the Control Element to re-
      compute an SFP or be provision=
ed as attributes to SFPs that will
      be installed using the control=
 interfaces.

 

NEW:

   SF/SFP Load-balancing:   re-construct =
SFPs to distribute the workload
      among various SF instances.&nb=
sp; Particularly, load distribution
      policies can be taken into acc=
ount by the Control Element to re-
      compute an SFP or be provision=
ed as attributes to SFPs that will
      be installed using the control=
 interfaces (C2 interface, typically).

 

Please let me know if further c= hanges are required.

[DD] Al= though this change is correct, it doesn’t address my concern. I would= like to see language in section 3.3.2.

[DD] Pe= rhaps, “The C2 interface may be used to configure groups of functiona= lly equivalent SFs that may service a path.”

 

[Med] Ok, what about this NEW t= ext?

 

   The C2 interface may be used t= o configure groups of functionally

   equivalent SFs.  In parti= cular, this group may be used for load-

   balancing purposes.

 

 

--_000_787AE7BB302AE849A7480A190F8B933008D61FA2OPEXCLILMA3corp_-- From nobody Fri Apr 29 08:06: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 9ECE112D173 for ; Fri, 29 Apr 2016 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 ABcxmb709tDf for ; Fri, 29 Apr 2016 08:06:42 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id B2D3E12D0A5 for ; Fri, 29 Apr 2016 08:06:41 -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.0195.001; Fri, 29 Apr 2016 11:06:40 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C2 interface Thread-Index: AdGhdzeqsff0+F4JRSWm8k5GYfJj0QAYB0bQABE7GWAAAcgu4AABUcsQ Date: Fri, 29 Apr 2016 15:06:39 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D61B4F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933008D61FA2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D61FA2@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F45F0Ewtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C2 interface 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, 29 Apr 2016 15:06:44 -0000 --_000_E8355113905631478EFF04F5AA706E9830F45F0Ewtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks good, thank you. From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, April 29, 2016 10:32 AM To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C2 interface Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 15:57 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C2 interface Med, Please see inline [DD] From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Friday, April 29, 2016 2:06 AM To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C2 interface Hi Dave, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 28 avril 2016 19:56 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : draft-ietf-sfc-control-plane -- C2 interface In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-= 04#section-3.3.2 the section is: C2: Interface between SFC Control Plane & SFF - There is no mention of being able to instruct the SFF to load-balance an = SFP across multiple (functionally equivalent) SFs This is the service-function-group-name concept in OpenDaylight and in draf= t-penno-sfc-yang-14, as I understand it. Identifying members of a group and identifying a group as a next-hop would = be in the scope of the C2 interface, correct? [Med] This is in scope of C2, that is responsible for populating the SFC Fo= rwarding Policy Table. The current text cites examples of additional to be = used for lookup purposes (excerpt from Section 1.2): Additional information such as a flow identifier, Service Index (SI), and/or other characteristics (e.g., the 5-tuple transport coordinates of the original packet) may be used for lookup purposes. The set of information to use for lookup purposes may be instructed by the control plane. Load balancing is discussed in "Additional Considerations" section. Indeed,= Section 4.10.1 includes the following: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. [DD] This is in a section that seems to be about the controller making adju= stments to move work-load to different paths. I'm concerned with the case w= hen traffic of a single path is load-balanced across multiple workers in a = dynamic manner that doesn't require controller micro-management. [DD] To help clarify, it might be useful to think of the SFF having multipl= e next-hop entries for the same SPI/SI pair; as with ECMP routing or LAG, a= local decision selects which to use. I suggest to make this change: OLD: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces. NEW: SF/SFP Load-balancing: re-construct SFPs to distribute the workload among various SF instances. Particularly, load distribution policies can be taken into account by the Control Element to re- compute an SFP or be provisioned as attributes to SFPs that will be installed using the control interfaces (C2 interface, typically). Please let me know if further changes are required. [DD] Although this change is correct, it doesn't address my concern. I woul= d like to see language in section 3.3.2. [DD] Perhaps, "The C2 interface may be used to configure groups of function= ally equivalent SFs that may service a path." [Med] Ok, what about this NEW text? The C2 interface may be used to configure groups of functionally equivalent SFs. In particular, this group may be used for load- balancing purposes. --_000_E8355113905631478EFF04F5AA706E9830F45F0Ewtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Looks good, thank you.=

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, April 29, 2016 10:32 AM
To: Dave Dolson; sfc@ietf.org
Subject: RE: draft-ietf-sfc-control-plane -- C2 interface=

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 15:57
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C2 interface

 

Med,=

Please see inline [DD]=

 

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Friday, April 29, 2016 2:06 AM
To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C2 interface=

 

Hi Dave,

 

Please see inline.

 

Cheers,

Med

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : jeudi 28 avril 2016 19:56
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : draft-ietf-sfc-control-plane -- C2 interface=

 

In section 3.3.2, https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.2

the section is: C2: Interface between SFC Control Pl= ane & SFF

 

- There is no mention of being able to instruct the = SFF to load-balance an SFP across multiple (functionally equivalent) SFs

This is the service-function-group-name concept in O= penDaylight and in draft-penno-sfc-yang-14, as I understand it.<= /p>

Identifying members of a group and identifying a gro= up as a next-hop would be in the scope of the C2 interface, correct?

 

[Med] This is in scope of C2, that is responsi= ble for populating the SFC Forwarding Policy Table. The current text cites = examples of additional to be used for lookup purposes (excerpt from Section 1.2):

 

&=
nbsp;     Additional information such as a flow identif=
ier, Service Index
&=
nbsp;     (SI), and/or other characteristics (e.g., the=
 5-tuple transport
&=
nbsp;     coordinates of the original packet) may be us=
ed for lookup
&=
nbsp;     purposes.  The set of information to use=
 for lookup purposes may
&=
nbsp;     be instructed by the control plane.

 

Load balancing is discussed in “Addition= al Considerations” section. Indeed, Section 4.10.1 includes the follo= wing:

 

   SF/SFP Load-balancing:   re-constru= ct SFPs to distribute the workload

      among various SF instances.=   Particularly, load distribution

      policies can be taken into = account by the Control Element to re-

      compute an SFP or be provisioned as attributes to SFPs that will

      be installed using th= e control interfaces.

[DD] This is in a sect= ion that seems to be about the controller making adjustments to move work-l= oad to different paths. I’m concerned with the case when traffic of a= single path is load-balanced across multiple workers in a dynamic manner that doesn’t require controller micro-ma= nagement.

[DD] To help clarify, = it might be useful to think of the SFF having multiple next-hop entries for= the same SPI/SI pair; as with ECMP routing or LAG, a local decision select= s which to use.

 

I suggest to make this change:

 

OLD:

&=
nbsp;  SF/SFP Load-balancing:   re-construct SFPs to distrib=
ute the workload
&=
nbsp;     among various SF instances.  Particularl=
y, load distribution
&=
nbsp;     policies can be taken into account by the Con=
trol Element to re-
&=
nbsp;     compute an SFP or be provisioned as attribute=
s to SFPs that will
&=
nbsp;     be installed using the control interfaces.

 

NEW:

&=
nbsp;  SF/SFP Load-balancing:   re-construct SFPs to distrib=
ute the workload
&=
nbsp;     among various SF instances.  Particularl=
y, load distribution
&=
nbsp;     policies can be taken into account by the Con=
trol Element to re-
&=
nbsp;     compute an SFP or be provisioned as attribute=
s to SFPs that will
&=
nbsp;     be installed using the control interfaces (C2=
 interface, typically).

 

Please let me know if further changes are requ= ired.

[DD] Although this cha= nge is correct, it doesn’t address my concern. I would like to see la= nguage in section 3.3.2.

[DD] Perhaps, “T= he C2 interface may be used to configure groups of functionally equivalent = SFs that may service a path.”

 

[Med] Ok, what about this NEW text?=

 

   The C2 interface may be used to configure gro= ups of functionally

   equivalent SFs.  In particular, this gro= up may be used for load-

   balancing purposes.

 

 

--_000_E8355113905631478EFF04F5AA706E9830F45F0Ewtlexchp2sandvi_-- From nobody Fri Apr 29 08:18:19 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 7174612B062 for ; Fri, 29 Apr 2016 08:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kkwEmBxiM7pV for ; Fri, 29 Apr 2016 08:18:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D2F12B03A for ; Fri, 29 Apr 2016 08:18:10 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 78EA5264BE3; Fri, 29 Apr 2016 17:18:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 55BDA35C045; Fri, 29 Apr 2016 17:18:08 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 17:18:08 +0200 From: To: Dave Dolson , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPyCGamlj3aSpeV/2k+/ATTtw== Date: Fri, 29 Apr 2016 15:18:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D6201COPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.29.145415 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface 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, 29 Apr 2016 15:18:18 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D6201COPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 16:24 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface [..] E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: "This interface informs the SFC-aware SF about the method for handling bidi= rectional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping." [Med] I'm hesitating to add text about the "algorithmic method" as I don't = have a document to cite. Note that some stateful SFs (e.g., NAT) will natur= ally add a reverse mapping to handle incoming packets without requiring inp= uts from the CP. What do you mean by "providing forward/reverse path mappin= g"? Is it SF-specific mapping? [DD] I agree there is a lack of material to cite... [DD] What I mean is informing the SF that "path X is the complementary path= of path Y". E.g., "Paths 100 (upstream) and 101 (downstream) are pairs. Re= spond to a path-100 packet on path 101." [Med] Thank you for the clarification. What would be the added value of pro= viding that information (X complementary of Y) if we assume that two classi= fication rules are installed to handle both directions? What about adding this NEW text at the end of Section 4.2? NEW: Typically, C2 interface is used to ensure that the same SF instance is involved in both directions of a flow (including, to ensure full chain symmetry). [DD] I disagree that C2 has anything to do with this. Instead, C1 must be u= sed to provide consistent classification. [Med] The example I have in mind is an a statefull NAT that is attached to = a given SFF while the Classifier hasn't the visibility on the full forwardi= ng path. The classifier in such case has no means to force that the same SF= instance will be invoked for both direction. Wouldn't C2 be involved in su= ch case? [DD] How about adding the generic statement to section 3.3.3, "Some SFs may= need to be configured regarding the rules for packet reversal on a path. T= he controller may use the C3 interface to specify how packets on a path may= be placed on the reverse path." [Med] What is specific in this case compared to configuring two classificat= ion rules; one for each direction? Is there something the classifier is sup= posed to do? ... [Med] FWIW, context information is mentioned in the WG charter "communicate= s context information between nodes that implement". What about this change= to avoid confusion: OLD: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. NEW: This interface is also used to instruct an SFC-aware SF about any context information (a.k.a., metadata) it needs to supply for a given SFC. [DD] Again, is this intended to mean adding information to a packet? Or is = "supply" intentionally vague about the delivery mechanism? [Med] "Supply" is intentional here as this covers both cases: (1) add a new= information to a packer (e.g., a new TLV), (2) update the context of an ex= isting TLV. Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. [Med] I do think the current wording is correct. Having an SFF co-located w= ith a set of SFs is deployment-specific according to the SFC architecture R= FC. [DD] I agree with that statement. However, I think the case being described= is when there *is* a co-located SFF, but the text is pretending there isn'= t. If the following text remains, C3 will need to include all the functiona= lity of C2. [Med] I re-confirm that the initial case we wanted to cover by this text is= an SFF servicing a group of SFs that are embedded in a distinct physical n= ode. This scenario suppose that once an SF is consumed it sends back the pa= cket to the SFF that may undertake another hook to another SF in that node = and so on. The packet is not handed from an SF to another one without solic= iting the external SFF. That's sub-optimal, I agree. The text is currently = silent whether the distinct locators are configured using the C2 interface = (assuming that a distinct management interface is used between the control = element and an SFC-aware SF). --_000_787AE7BB302AE849A7480A190F8B933008D6201COPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 16:24
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

 

[..]

 

E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-pack= et-02.txt

Maybe add this paragraph:<= /o:p>

“This interface informs t= he SFC-aware SF about the method for handling bidirectional paths,

either by conveying the algorit= hmic method to use, or by providing forward/reverse path

mapping.”

 

[Med] I’m hesitating to a= dd text about the “algorithmic method” as I don’t have a = document to cite. Note that some stateful SFs (e.g., NAT) will naturally add a reverse mapping to handle incoming packets without requiring inputs = from the CP. What do you mean by “providing forward/reverse path mapp= ing”? Is it SF-specific mapping?

&n= bsp;

[DD] I = agree there is a lack of material to cite…

[DD] Wh= at I mean is informing the SF that “path X is the complementary path = of path Y”. E.g., “Paths 100 (upstream) and 101 (downstream) ar= e pairs. Respond to a path-100 packet on path 101.”=

[Med] Thank you for the clarifica= tion. What would be the added value of providing that information (X comple= mentary of Y) if we assume that two classification rules are installed to handle both directions?  

 

What about adding this NEW text= at the end of Section 4.2?

 

NEW:

   Typically, C2 inte= rface is used to ensure that the same SF instance

   is involved i= n both directions of a flow (including, to ensure full

   chain symmetr= y).

[DD] I = disagree that C2 has anything to do with this. Instead, C1 must be used to = provide consistent classification.

[Med] The example I have in mind = is an a statefull NAT that is attached to a given SFF while the Classifier = hasn’t the visibility on the full forwarding path. The classifier in such case has no means to force that the same SF instanc= e will be invoked for both direction. Wouldn’t C2 be involved in such= case?  

 

[DD] Ho= w about adding the generic statement to section 3.3.3, “Some SFs may = need to be configured regarding the rules for packet reversal on a path. Th= e controller may use the C3 interface to specify how packets on a path may be placed on the reverse path.”=

[Med] What is specific in this ca= se compared to configuring two classification rules; one for each direction= ? Is there something the classifier is supposed to do?  

   

…

 

[Med] FWIW, context information= is mentioned in the WG charter “communicates context information bet= ween nodes that implement”. What about this change to avoid confusion:

 

OLD:

   This interface is also used to instruct an SFC-= aware SF about any

   context information it needs to supply in the c= ontext of a given SFC.

 

NEW:

   This interface is also used to instruct an SFC-= aware SF about any

   context information (a.k.a., metadata) it needs= to supply

   for a given SFC.

[DD] Ag= ain, is this intended to mean adding information to a packet? Or is “= supply” intentionally vague about the delivery mechanism?<= /span>

[Med] “Supply” is int= entional here as this covers both cases: (1) add a new information to a pac= ker (e.g., a new TLV), (2) update the context of an existing TLV.

&n= bsp;

 

Regarding this paragraph, I thi= nk it would be cleaner if this behavior actually requires the C2 interface = into the SF.

 

[Med] I do think the current wo= rding is correct. Having an SFF co-located with a set of SFs is deployment-= specific according to the SFC architecture RFC.

[DD] I = agree with that statement. However, I think the case being described is whe= n there *is* a co-located SFF, but the text is pretending there isn&= #8217;t. If the following text remains, C3 will need to include all the functionality of C2.

[Med] I re-confirm that the initi= al case we wanted to cover by this text is an SFF servicing a group of SFs = that are embedded in a distinct physical node. This scenario suppose that once an SF is consumed it sends back the packet to t= he SFF that may undertake another hook to another SF in that node and so on= . The packet is not handed from an SF to another one without soliciting the= external SFF. That’s sub-optimal, I agree. The text is currently silent whether the distinct locators are co= nfigured using the C2 interface (assuming that a distinct management interf= ace is used between the control element and an SFC-aware SF).   &= nbsp; 

 

--_000_787AE7BB302AE849A7480A190F8B933008D6201COPEXCLILMA3corp_-- From nobody Fri Apr 29 08:48: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 9159E12B03A for ; Fri, 29 Apr 2016 08:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 9EdaWi6mXYfR for ; Fri, 29 Apr 2016 08:48:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01B212D187 for ; Fri, 29 Apr 2016 08:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=168770; q=dns/txt; s=iport; t=1461944857; x=1463154457; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m56Bqyb1+45IhDDO7lVl13ank2Ht/eQV+mxFARON0xQ=; b=kJUtQleLqtmubwsBc3hBCKp0l+5q0rIP2bsPJI6OZpNoYMwiR6Q4gd8L z6u/Wel5ub0SsXx3vn6QZOxCcQglw97NjT/VQgkv7GFIFXhvy7RC340xY hLxpE3XbRdvzULGUkuETq06BcHNddPkTOuPga+vx/5OlwsAIX0NRCzYTH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgAAgSNX/4ENJK1aA4JsTFN9Bq4Li?= =?us-ascii?q?2ABDYFyBBcBCoVuAoEqOBQBAQEBAQEBZSeEQQEBAQQBAQEXAQIQOgcLDAQCAQg?= =?us-ascii?q?RAwEBASEBAgQHIQYLFAkIAgQBDQWIFQMSDr9/DYROAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBEQSGIYRMgkGCHAEVEYUPBYd2iyyEQDEBhXuCd4MugXaBZ4RNgymFNIY?= =?us-ascii?q?kgS2HXgEeAQFCgjaBNWyIAn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208,217";a="266245842" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 15:47:35 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3TFlZ0V015480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 15:47:35 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.1104.5; Fri, 29 Apr 2016 10:47: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.1104.009; Fri, 29 Apr 2016 10:47:34 -0500 From: "Jim Guichard (jguichar)" To: Sunil Vallamkonda , "Andrew G. Malis" , Joel Halpern Direct Thread-Topic: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRoLy5gODJbPprtEyKsV065fH5RJ+elnwAgAAtrACAAAwigIAA0eUA///PIYCAAJ/UAIABGwgA Date: Fri, 29 Apr 2016 15:47:34 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B899585893723B9@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F037@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <783b2703-5371-7e9c-0718-27c5722d7f8f@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933008D5F52C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7E05C330D7FD6D4FAD0728C46B89958589372CCE@ORSMSX114.amr.corp.intel.com> <787AE7BB302AE849A7480A190F8B933008D5F5A1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7CD2F@dfweml501-mbb> <098dd557-bb0a-c499-6bf6-3faa707b89c7@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657E7CDB7@dfweml501-mbb> <787AE7BB302AE849A7480A190F8B933008D604E1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A95BA014132FF49AE685FAB4B9F17F657E7D943@dfweml501-mbb> <552c87c0-81b6-7f14-09a3-f68abc25a581@joelhalpern.com> <4d65232a-d4a6-a11b-c765-635cb909edbd@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D348FA2D4C885jguicharciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-sfc-nsh-04.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, 29 Apr 2016 15:48:12 -0000 --_000_D348FA2D4C885jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Sunil, I think the suggested text to add is "Use the fragmentation provided by the= network overlay mechanics. One example can be found in RFC 6830, section 5= .4.=94 - hope this clarifies. Jim From: Sunil Vallamkonda > Date: Thursday, April 28, 2016 at 2:54 PM To: Jim Guichard >, "Andrew G= . Malis" >, Joel Halpern Direct= > Cc: "Elzur, Uri" >, "mohame= d.boucadair@orange.com" >, "sfc@ietf.org" >, Linda Dunbar > Subject: RE: [sfc] Suggested wording addtion to the Section 6 (Fragmentatio= n Consideration) of the draft-ietf-sfc-nsh-04.txt Jim, I agree, the confusion being NSH treated as a network overlay. Would it be possible for the document to have wording on this ? This could also clarify interpretations how NSH to be used with ARP, DHCP a= nd encapsulations. Thank you, Sunil From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, April 28, 2016 6:23 AM To: Andrew G. Malis >; Joel Hal= pern Direct > Cc: Elzur, Uri >; mohamed.b= oucadair@orange.com; sfc@ietf.org; Linda Dunbar > Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentatio= n Consideration) of the draft-ietf-sfc-nsh-04.txt Hi Andy, I think the key point is that NSH !=3D network overlay but rather utilizes = a network overlay for packet transport between SFC network elements. The re= ference is just an example of how a network overlay might deal with fragmen= tation and is not a suggestion that NSH adopt that mechanism but rather mak= es the point that it can utilize the existing network overlay mechanics. Jim From: sfc > on behalf of = "Andrew G. Malis" > Date: Thursday, April 28, 2016 at 8:17 AM To: Joel Halpern Direct > Cc: "Elzur, Uri" >, "mohame= d.boucadair@orange.com" >, "sfc@ietf.org" >, Linda Dunbar > Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragmentatio= n Consideration) of the draft-ietf-sfc-nsh-04.txt Joel, The diagrams in section 6 of RFC 6830 are control plane, not data plane. Th= e data plane diagrams are in section 5. But the overriding question is - without any fields in the NSH header to se= quence fragments, how can the fragments be correctly reassembled? Cheers, Andy On Wed, Apr 27, 2016 at 7:46 PM, Joel Halpern Direct > wrote: The LISP header does not have a fragment flag or fragment offset. The diag= rams in section 6 include the outer encapsulating header (the equivalent of= the transport header in SFC.) Yes, the text is a little hard to follow in= this regard. The LISP working group is going to be rewriting RFC 6830 as = part of moving to standards track. So there is no difference in this regard between NSH and LISP. Yours, Joel On 4/27/16 7:02 PM, Andrew G. Malis wrote: Joel et al, All this talk about fragmentation prompted me to re-read section 6 of the draft, which recommends (as option 3) using the procedures in section 5.4 of RFC 6830 (presumably with the =93NSH header=94 replacing the =93LISP header=94 in the description of the procedures in that section). So that led me to read that section (and the LISP header definition in section 5.1), and I see that LISP does fragmentation and reassembly identically to IPv4, using the Fragment Offset field so that fragments can be correctly reassembled in the proper order. However, the NSH Header doesn=92t have a Fragment Offset field or any other way to order the fragments. So how can the procedures in Section 5.4 of 6830 be used? Thanks, Andy On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern >> wrote: Both methods are valid, and both depend upon details of the underlying packet and the transport. As such, I don't see why this document benefits from describing them, much less why it should mark one method as a "should". Implementation details are likely to be more significant than any bit consumption difference between the two alternatives. Yours, Joel On 4/27/16 3:40 PM, Linda Dunbar wrote: I suggest adding the following paragraphs after the Bullet 3 of the Section 6 Fragmentation Consideration to make the process more clear and less controversial: -------------------------------- RFC6830 describes the fragmentation method of breaking the original packet into two equal sub-frames and encapsulating [LISP Header + Transport header] to each sub-frame. If LISP fragmentation [RFC6830 Section 5.4] is used, the [SFC Header + Transport Header] will be added to each half frame (or the original data frame). As the Transport Header is terminated by the next SFF node's tunnel transport layer, the combined two sub-frames will have two SFC Headers. Therefore, the fragmentation for NSH encapsulated data frame should be done completely by the node tunnel transport layer, which should break the [SFC + original packet] into two equal sub-frames and each sub-frame being encapsulated with its respective tunnel header. The next SFF node's tunnel transport layer should combine the two sub-frames before sending to the next node. ------------------------------------------------------ By the way, there are to typo in the Section 6: 3rd line: "In order the" =3D=3D> "In order to" Last line of Bullet 2: extra "the" in the "utilized to ensure the the required packet". Hope it helps. Linda -----Original Message----- From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com >] Sent: Wednesday, April 27, 2016 12:40 AM To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; sfc@ietf.org > Subject: RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, all, Please see inline. Cheers, Med -----Message d'origine----- De : Joel M. Halpern [mailto:jmh@joelhalpern.com >] Envoy= =E9 : mardi 26 avril 2016 19:18 =C0 : Linda Dunbar; BOUCADAIR Mohamed IMT/OLN; Elzur, Uri; sfc@ietf.org > Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt With regard to Transport tunnel fragementation, that seems an issue for the transport protocol. I don't actually object to a sentence, but it does not seem that it will accomplish anything. [Med] I would like to see some text added to the draft. With regard to packets fragmented by the source, I completely disagree with your assertion. If an SFF were to reassemble the packets, that would be a violation of its job. [Med] I agree with you. There is no reason for an SFF to reassemble a packet fragmented by the source. The classifier may have to do some interesting things in order to properly classify succeeding fragments, but that is an implementation issue (most commonly addressed with virtual reassembly, which doe snot delay the fragments.) We don't specity that. [Med] Still, the external behavior of the classifier needs to be clear in the document. I don't find any text in the draft saying for instance that an NSH header must be present in all fragments. (There some processing that might be needed at the SFF to "do its job" with regards to fragments (receive out of order fragments + forwarding policy on the full packet).) If an SF needs to reassemble fragments to do its job, that is up to the SF. Some will need to actually reassemble. Some will need to perform virtual reassembly, and some will happily process the fragments. I can not see what the NSH document could possibly mandate. [Med] Fully agree. Yours, Joel On 4/26/16 11:47 AM, Linda Dunbar wrote: Joel, I think the document should add the description on the following two fragmentation scenarios: - Transport tunnel generated fragmentation: When a packet fragmentation is caused by transport tunnel (i.e. various encapsulations), the termination point of the transport tunnel is responsible for re-assembling the fragmented pieces of the packet. Since there won't be any SFF nodes in between the Transport Tunnel, the tunnel generated fragmentation does not require any actions by SFF nodes or SF nodes. - Source node generated fragmentation (after adding on the NSH header): When fragmentation has to be performed for a packet being encapsulated with the NSH header, either the intermediate SFF nodes or the SF nodes have to be able to reassemble the fragmented pieces. Cheers, Linda -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com >] S= ent: Tuesday, April 26, 2016 10:33 AM To: Linda Dunbar; mohamed.boucadair@orange.com >; Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-reading your note, it is possible that you are referring only to the case of transport generated fragmentation of the outer packet. I had assumed you were not talking about that, since the resulting fragments will not all have NSH headers. As with any tunne= l technology, if the tunnel chooses to fragment at its layer, then the tunnel is responsible for reassembly. That would be invisible to the SFF. Yours, Joel On 4/26/16 11:10 AM, Linda Dunbar wrote: Agree with Med. Even if each fragment piece of a packet with NSH header carries the NSH header, the intermediate SFF nodes still need to put together all the fragments together before passing the whole data frame to the SF. Linda -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 9:42 AM To: Elzur, Uri; Joel M. Halpern; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Re-, How do you instruct the transport layer to ALWAYS prepend an NSH header even for fragments? Or you don't care about that= ? Thank you. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : lundi 25 avril 2016 16:26 =C0 : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med Not to repeat my position, but I'll do it anyhow :-) As NSH is *NOT* a transport, dealing with fragmentation is left to the Transport used. The model I use for NSH, is basically similar to VXLAN . It is an overly. Thx Uri ("Oo-Ree") C: 949-378-7568 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Monday, April 25, 2016 7:18 AM To: Joel M. Halpern >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Joel, Please see inline. Cheers, Med -----Message d'origine----- De : Joel M. Halper= n [mailto:jmh@joelhalpern.com >] Envoy=E9 : lundi 25 avril 2016 15:48 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Obje= t : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt If I am understanding you correctly Med, you are asking that the NSH draft specify how service chaining should cope with packets that have been fragmented? [Med] To be accurate, I'm asking to assess whether there are implications. If there are, then the draft should be updated accordingly. NSH, and the SFF functionality, does not care. [Med] I'm not that sure. Some typical implications are listed below: * SFF: If the NSH header is present only in the a fragment but SFF didn't maintained a state, subsequent fragments won't be appropriately processed. * SFC-aware function: if prepending a context information depends on the full packet, not only a fragment. It just does its job. [Med] which may be disturbed in some situations as listed in the examples above. Ingress and intermediate classifiers may cope with fragments in any number of ways. Specifying such is clearly out of scope for this draft. [Med] The purpose is not to specify the internal implementation details but the external behavior of the classifier function when it comes to handle fragments. That behavior may have an incidence on SFF, in particular. The purpose is not to recommend the maximum resources to be dedicated to out of order fragments nor the timeout to cache those; these considerations are of course out of scope. Nevertheless, an implementation should offer a configurable parameter so that an operator tweak those according to its context. I suppose one could write an informational draft on possible ways of coping. The IETF has not usually published such. Service functions have to cope with fragmented packets just as they had to before the advent of NSH, so describing that is clearly not needed here. [Med] The advent of NSH has the following implications: * it exacerbates fragmentation. Handing over this issue to the transport layer may lead to interoperability issues. * the chaining may not be efficient if fragments are inappropriately handled. Introducing NSH should not degrade the overall service compared to legacy service deployment schemes. Yours, Joel On 4/25/16 3:00 AM, mohamed.boucadair@orange.com > wrote: Re-, I hear you, but my comment is that we need, as a WG, to decide what to put in the draft. FWIW, I'm discussing two fragmentation issues: (1) Fragmentation that is caused by prepending an SFC header. (2) Handling fragments at the ingress of an SFC-enabled domain. Increasing the MTU is for sure a recommendation is to be explicitly called out in the text (see my first message). There are other issues that need to be discussed, e.g., how to deal with fragments in SFFs/Classifiers? It is also "prudent" to check that no issues will be experienced in SFF to handle fragments. If an SFC header is prepended for all fragments, I'm not sure there is any particular issue at the SFF level, except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. For point (1), declaring fragmentation out of scope would be meant that an implementation must be prepared to receive fragments with or without NSH header as this is a decision that is left to the transport encapsulation. This is a requirement per se! I won't reiterate all the comments I have about the current wording of this section. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : lundi 25 avril 2016 08:30 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med My point is that Fragmentation is yet another transport related issue that is beyond the scope of NSH and beyond the charter of the WG, so it doesn't really belong in the draft. We are providing an advice as extending the size of the packet may lead to fragmentation, but as you check RFC 7348 VxLAN, which my create the same issue, you'll find it doesn't even relate to it. Thx Uri ("Oo-Ree") C: 949-378-7568 > -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Sunday, April 24, 2016 10:32 PM To: Elzur, Uri >>; Thomas Narten >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Uri, That's another option that needs to be discussed/investigated. I'm afraid this is not the rationale adopted in -04 since it includes some text that is far to be sufficient to ensure interoperable implementations. BTW, saying that nsh does not need to deal with fragmentation because it is transport-independent is not IMHO a good strategy to adopt here because it opens the door for interoperable issues, it may lead to sub-optimal implementations if the sfc information is present only in one fragments, etc. My comments are related to the current text in the -04. This text needs to be fixed somehow. Cheers, Med -----Message d'origine----- De : Elzur, Uri [mailto:uri.elzur@intel.com >] Envoy=E9 : dimanche 24 avril 2016 17:36 =C0 : BOUCADAIR Mohamed IMT/OLN; Thomas Narten; sfc@ietf.org > Objet : RE: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Hi Med I see no need to specify the exact behavior as NSH is transport independent i.e. like NSH interaction with any other Transport eh issue of Fragmentation is to be dealt in a way that matches the mechanisms supported by the Transport used and do not belong in the NSH draft Thx Uri ("Oo-Ree") C: 949-378-7568 = > -----Original Message----- From: sf= c [mailto:sfc-bounces@ietf.org >] On Behalf Of mohamed.boucadair@orange.com > Sent: Thursday, April 14, 2016 12:43 AM To: Thomas Narten >>; sfc@ietf.org > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt R-, In addition to other pending issues raised for this draft, I would like to raise this additional one about Section 6. =3D=3D 6. Fragmentation Considerat= ions NSH and the associated transport header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet. In order the ensure proper forwarding of NSH data, several options for handling fragmentation and re-assembly exist: 1. Jumbo Frames, when supported, enable the transport of NSH and associated transport packets without requiring fragmentation. 2. Path MTU Discovery [RFC1191]"describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path" and can be utilized to ensure the the required packet size is used. 3. [RFC6830] describes two schemes for fragmentation and re- assembly in section 5.4. =3D=3D * The text is weak for a Standard track document that is intended to solve the problem in https://tools.ietf.org/html/rfc7498= #section- 2.12. There should be a clear behavior to be followed by an implementation. Further, I would avoid the use of words such as "can". * The text covers only fragmentation when it is induced by SFC operations, it does not discuss the treatment of a fragment when received in an SFC domain. IMHO, the draft should also specify the behavior of the Classifier with regards to fragments for the sake of proper SFC operation. Applying classification policies may require the full packet, not only a fragment. In particular, dedicated resources should dedicated for handling out of order fragments. Of course, it is out of scope of this document to describe how SFs handle fragments. * If an SFC header is prepended for all fragments, I'm not sure there is any particular issue at the SFF level...except if stripping/adding context TLVs depends on the full packet (not just fragment). It is warranted to consider a little bit this point before declaring there is no issue. * The text states "several options". This may be interpreted as if implementing one of them is sufficient...which is not true. The first two points contribute to minimize the fragmentation risk, but fragmentation may still be experienced (e.g., other shims are prepended by other nodes for some other purposes, nested nsh, etc.) * The first two points have nothing to do with reassembly. * The support of jumbo frames by a router/device does not mean that it can make use of it. Appropriate MTU configuration should be undertaken in a consistent manner within an SFC domain. The text should be updated to make it is about (consistent) MTU configuration. * BTW, shouldn't the text be reworded to recommended to increase the MTU of **all nodes** of an SFC-enabled domain by at least the length of SFC header + transport header? * Bullet 2, how PMTU discovery is actually used in this context? Do you assume that all SFC-aware nodes will issue such messages towards other SFC-aware node, arbitrary destination, else? * Bullet 2, I would drop "describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path". * Bullet 2, s/ the the/the. * The reference to the LISP specification raises two concerns and one comment: (1) I don't think it is a good approach that fragments induced by the network are passed to their ultimate destinations as such (stateless). IMO, reassembly should be done within the SFC domain (responsible for fragmentation) not passed away. (2) Does the stateful mode require all SFC data plane elements maintain a full list of MTU for the any SFF/SF instance of the SFC domain? The current text suggests that [RFC6830] should be listed as normative reference (not an informative one). I would personally favor removing the reference to LISP (as it is an Experimental RFC). * The security section of the draft may be augmented with informational fragmentation-related pointers to: e.g., RFC1858 (Security Considerations for IP Fragment Filtering), RFC3128 (Protection Against a Variant of the Tiny Fragment Attack), and RFC 4963 (IPv4 Reassembly Errors at High Data Rates). Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.org >] De la part de mohamed.boucadair@orange.com > Envoy=E9 : lundi 11 avril 2016 13:14 =C0 : Thomas Narten; sfc@ietf.org > Objet : Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear Thomas, all, As I mentioned during the meeting, there are several issues that are not covered in the last version of the draft. I already provided examples of the issues offline as requested by Martin. Cheers, Med -----Message d'origine----- De : sfc [mailto:sfc-bounces@ietf.or= g >] De la part de Thomas Narten Envoy=E9 : jeudi 31 mars 2016 04:48 =C0 : sfc@ietf.org > Objet : [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Dear WG: This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datatracker.ietf.o= rg/doc/draft-ietf-sfc-nsh/). The editors of the NSH document have indicated that they have addressed all known comments and that there are no open issues with the current version of the document. Substantive comments to the list please, editorial comments can go directly to the document editors. We'll also get a brief update from the editors at next week's meeting. If there are any remaining issues with the document, raising them before the meeting would be especially helpful. For the chairs, Thomas ___________________________= ____________________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailma= n/listinfo/sfc _______________________________= ________________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailman/li= stinfo/sfc ___________________________________= ____________ sfc mailing list sfc@ietf.org > https://www.ietf.org/mailman/listin= fo/sfc _______________________________________= ________ sfc mailing --_000_D348FA2D4C885jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <51D060B29752E94887DA825BDD7843AF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Sunil,

I think the suggested text to add is "Use the fragmentation provided = by the network overlay mechanics. One example can be found in RFC 6830, sec= tion 5.4.=94 - hope this clarifies.

Jim<= /span>

From: Sunil Vallamkonda <sunilvk@f5.com>
Date: Thursday, April 28, 2016 at 2= :54 PM
To: Jim Guichard <jguichar@cisco.com>, "Andrew G. Malis&q= uot; <agmalis@gmail.com>, Jo= el Halpern Direct <jmh.dir= ect@joelhalpern.com>
Cc: "Elzur, Uri" <uri.elzur@intel.com>, "mohamed.boucadair@orange.com= " <mohamed.boucadai= r@orange.com>, "sfc@ietf.org" <sfc@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: RE: [sfc] Suggested wordin= g addtion to the Section 6 (Fragmentation Consideration) of the draft-ietf-= sfc-nsh-04.txt

Jim,

 

I agree, the confusion being NSH trea= ted as a network overlay.

Would it be possible for the document= to have wording on this ?

This could also clarify interpretatio= ns how NSH to be used with ARP, DHCP and encapsulations.<= /p>

 

 

Thank you,

Sunil

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, April 28, 2016 6:23 AM
To: Andrew G. Malis <agmalis= @gmail.com>; Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: Elzur, Uri <uri.elzur@= intel.com>; mohamed.boucadair@orange.co= m; sfc@ietf.org; Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragm= entation Consideration) of the draft-ietf-sfc-nsh-04.txt<= /p>

 

Hi Andy,

 

I think the key point is that NSH !=3D = network overlay but rather utilizes a network overlay for packe= t transport between SFC network elements. The reference is just an example of how a network overlay might deal with fragmentation = and is not a suggestion that NSH adopt that mechanism but rather makes the = point that it can utilize the existing network overlay mechanics. 

 

Jim

 

From: sfc <sfc= -bounces@ietf.org> on behalf of "Andrew G. Malis" <agmalis@gmail.com>
Date: Thursday, April 28, 2016 at 8:17 AM
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Cc: "Elzur, Uri" <uri.elzur@intel.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "sfc@ietf.org" <sfc@ietf.org>, Linda Dunbar <= ;linda.dunbar@huawei.com>=
Subject: Re: [sfc] Suggested wording addtion to the Section 6 (Fragm= entation Consideration) of the draft-ietf-sfc-nsh-04.txt<= /p>

 

Joel,

 

The diagrams in section 6 of RFC 6830 a= re control plane, not data plane. The data plane diagrams are in section 5.=

 

But the overriding question is - withou= t any fields in the NSH header to sequence fragments, how can the fragments= be correctly reassembled?

 

Cheers,

Andy

 

On Wed, Apr 27, 2016 at 7:46 PM, Joel H= alpern Direct <jmh.direct@joelhalpern.com> wrote:

The LISP header does not have a fragmen= t flag or fragment offset.  The diagrams in section 6 include the oute= r encapsulating header (the equivalent of the transport header in SFC.)  Yes, the text is a little hard to follow in this reg= ard.  The LISP working group is going to be rewriting RFC 6830 as part= of moving to standards track.

So there is no difference in this regard between NSH and LISP.

Yours,
Joel

On 4/27/16 7:02 PM, Andrew G. Malis wrote:

Joel et al,

All this talk about fragmentation prompted me to re-read section 6 of
the draft, which recommends (as option 3) using the procedures in
section 5.4 of RFC 6830 (presumably with the =93NSH header=94 replacing the=
=93LISP header=94 in the description of the procedures in that section).
So that led me to read that section (and the LISP header definition in
section 5.1), and I see that LISP does fragmentation and reassembly
identically to IPv4, using the Fragment Offset field so that fragments
can be correctly reassembled in the proper order.

However, the NSH Header doesn=92t have a Fragment Offset field or any
other way to order the fragments.

So how can the procedures in Section 5.4 of 6830 be used?

Thanks,
Andy

On Wed, Apr 27, 2016 at 4:19 PM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

    Both methods are valid, and both depend upon details of the     underlying packet and the transport.  As such, I don't s= ee why this
    document benefits from describing them, much less why it shou= ld mark
    one method as a "should".  Implementation deta= ils are likely to be
    more significant than any bit consumption difference between = the two
    alternatives.

    Yours,
    Joel


    On 4/27/16 3:40 PM, Linda Dunbar wrote:

        I suggest adding the following paragraphs after= the Bullet 3 of
        the Section 6 Fragmentation Consideration to ma= ke the process
        more clear and less controversial:


        --------------------------------

        RFC6830 describes the fragmentation method of b= reaking the
        original packet into two equal sub-frames and e= ncapsulating
        [LISP Header + Transport header] to each su= b-frame.

        If LISP fragmentation [RFC6830 Section 5.4] is = used, the [SFC
        Header + Transport Header] will be added to= each half frame (or
        the original data frame). As the Transport Head= er is terminated
        by the next SFF node's tunnel transport layer, = the combined two
        sub-frames will have two SFC Headers.

        Therefore, the fragmentation for NSH encapsulat= ed data frame
        should be done completely by the node tunnel tr= ansport layer,
        which should break the [SFC + original pack= et] into two equal
        sub-frames and each sub-frame being encapsulate= d with its
        respective tunnel header.  The next SFF no= de's tunnel transport
        layer should combine the two sub-frames before = sending to the
        next node.

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


        By the way, there are to typo in the Section 6:=
        3rd line: "In order the" =3D=3D> &= quot;In order to"
        Last line of Bullet 2: extra "the" in= the "utilized to ensure
        the the required packet".


        Hope it helps.

        Linda



        -----Original Message-----
        From: mohamed.boucadair@orange.com
        <mailto:mohamed.boucadair@orange.com>
        [mailto:mohamed.boucadair@orange.com
        <mailto:mohamed.boucadair@orange.com>]
        Sent: Wednesday, April 27, 2016 12:40 AM
        To: Joel M. Halpern; Linda Dunbar; Elzur, Uri; = sfc@ietf.org
        <mailto:sfc@ietf.org>
        Subject: RE: [sfc] WG last call for draft-ietf-= sfc-nsh-04.txt

        Hi Joel, all,

        Please see inline.

        Cheers,
        Med

            -----Message d'origine-----
            De : Joel M. Halpern [mailto:jmh@joelhalpern.com
            <mailto:jmh@joelhalpern.com>] Envoy=E9 : = mardi 26
            avril 2016 19:18 =C0 : Linda Dunb= ar; BOUCADAIR Mohamed
            IMT/OLN; Elzur,
            Uri; sfc@ietf.org <mailto:sfc@ietf.org> Objet : Re: [sfc] WG
            last call for
            draft-ietf-sfc-nsh-04.txt

            With regard to Transport tunnel f= ragementation, that seems
            an issue
            for the transport protocol. = I don't actually object to a
            sentence,
            but it does not seem that it will= accomplish anything.


        [Med] I would like to see some text added to th= e draft.


            With regard to packets fragmented= by the source, I
            completely disagree
            with your assertion.  If an = SFF were to reassemble the
            packets, that
            would be a violation of its job.<= br>

        [Med] I agree with you.

          There is no reason for an SFF to

            reassemble a packet fragmented by= the source.  The
            classifier may have
            to do some interesting things in = order to properly classify
            succeeding
            fragments, but that is an impleme= ntation issue (most commonly
            addressed with virtual reassembly= , which doe snot delay the
            fragments.)  We don't specit= y that.


        [Med] Still, the external behavior of the class= ifier needs to be
        clear in the document. I don't find any text in= the draft saying
        for instance that an NSH header must be present= in all
        fragments. (There some processing that might be= needed at the
        SFF to "do its job" with regards to f= ragments (receive out of
        order fragments + forwarding policy on the = full packet).)


            If an SF needs to reassemble frag= ments to do its job, that
            is up to
            the SF.  Some will need to a= ctually reassemble.  Some will
            need to
            perform virtual reassembly, and s= ome will happily process the
            fragments.  I can not see wh= at the NSH document could
            possibly mandate.


        [Med] Fully agree.


            Yours,
            Joel

            On 4/26/16 11:47 AM, Linda Dunbar= wrote:

                Joel,

                I think the documen= t should add the description on the
                following two
                fragmentation scena= rios:

                - Transport tunnel = generated fragmentation: When a packet
                fragmentation is ca= used by transport tunnel (i.e. various
                encapsulations), th= e termination point of the transport
                tunnel is
                responsible for re-= assembling the fragmented pieces of
                the packet.
                Since there won't b= e any SFF nodes in between the
                Transport Tunnel,                 the tunnel generate= d fragmentation does not require any
                actions by
                SFF nodes or SF nod= es.


                - Source node gener= ated fragmentation (after adding on
                the NSH
                header): When fragm= entation has to be performed for a
                packet being
                encapsulated with t= he NSH header, either the
                intermediate SFF no= des
                or the SF nodes hav= e to be able to reassemble the
                fragmented pieces.<= br>



                Cheers,


                Linda

                -----Original Messa= ge----- From: Joel M. Halpern
                [mailto:jmh@joelhalpern.com
                <mailto:jmh@joelhalpern.com&g= t;] Sent: Tuesday, April 26,
                2016 10:33 AM
                To: Linda Dunbar; <= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank"> mohamed.boucadair@orange.com
                <mailto:mohamed.boucadai= r@orange.com>; Elzur, Uri;
                sfc@ietf.org <mailto:sfc@ietf.org> Subject: Re: [sfc] W= G
                last call for
                draft-ietf-sfc-nsh-= 04.txt

                Re-reading your not= e, it is possible that you are
                referring only to                 the case of transpo= rt generated fragmentation of the
                outer packet.
                I had assumed you w= ere not talking about that, since the
                resulting
                fragments will not = all have NSH headers.  As with any tunnel
                technology, if the = tunnel chooses to fragment at its
                layer, then the
                tunnel is responsib= le for reassembly.  That would be
                invisible to
                the SFF.

                Yours, Joel

                On 4/26/16 11:10 AM= , Linda Dunbar wrote:

                    Agree= with Med.

                    Even = if each fragment piece of a packet with NSH
                    heade= r carries the
                    NSH h= eader, the intermediate SFF nodes still need to
                    put t= ogether
                    all t= he fragments together before passing the whole
                    data = frame to
                    the S= F.

                    Linda=

                    -----= Original Message----- From: sfc
                    [mail= to:sfc-bounces@ie= tf.org
                    <m= ailto:sfc-bounces= @ietf.org>]
                    On Be= half Of mohamed.boucadair@orange.com
                    <m= ailto:moh= amed.boucadair@orange.com> Sent: Monday,
                    April= 25,
                    2016 = 9:42 AM To: Elzur, Uri; Joel M. Halpern;
                    sfc@ietf.org <mailto:sfc@ietf.org> Subjec= t:
                    Re: [= sfc] WG last call for draft-ietf-sfc-nsh-04.txt

                    Re-,<= br>
                    How d= o you instruct the transport layer to ALWAYS
                    prepe= nd an NSH
                    heade= r even for fragments? Or you don't care about that?

                    Thank= you.

                    Cheer= s, Med

                     = ;   -----Message d'origine----- De : Elzur, Uri
                     = ;   [mailto:u= ri.elzur@intel.com
                     = ;   <mailto:uri.elzur@intel.com>] Envoy=E9 : lundi 25
                     = ;   avril 2016 16:26 =C0
                     = ;   : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;
                     = ;   sfc@ietf.org= <mailto:sfc@ietf.org<= /a>> Objet
                     = ;   : RE: [sfc] WG last call for
                     = ;   draft-ietf-sfc-nsh-04.txt

                     = ;   Hi Med

                     = ;   Not to repeat my position, but I'll do it anyhow
                     = ;   :-) As NSH is
                     = ;   *NOT* a transport, dealing with fragmentation is
                     = ;   left to the
                     = ;   Transport used.

                     = ;   The model I use for NSH, is basically similar to
                     = ;   VXLAN . It is an
                     = ;   overly.

                     = ;   Thx

                     = ;   Uri ("Oo-Ree") C: 949-378-7568 <tel:949= -378-7568>


                     = ;   -----Original Message----- From: sfc
                     = ;   [mailto:= sfc-bounces@ietf.org
                     = ;   <mailto:sfc-bounces@ietf.org>]
                     = ;   On Behalf Of mohamed.boucadair@orange.com
                     = ;   <mailto:mohamed.boucadair@orange.com> Sent:
                     = ;   Monday, April 25,
                     = ;   2016 7:18 AM To: Joel M. Halpern
                     = ;   <jmh@j= oelhalpern.com <mailto:jmh@joelhalpern.com>>;
                     = ;   sfc@ietf.org= <mailto:sfc@ietf.org<= /a>>
                     = ;   Subject: Re: [sfc] WG last call for
                     = ;   draft-ietf-sfc-nsh-04.txt

                     = ;   Hi Joel,

                     = ;   Please see inline.

                     = ;   Cheers, Med

                     = ;       -----Message d'origine----- De : Joel M. Halpern
                     = ;       [mailto:jmh@joelhalpern.com
                     = ;       <mailto:jmh@joelhalpern.com>] Envoy=E9 : lundi
                     = ;       25 avril 2016 15:48 =C0
                     = ;       : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
                     = ;       <mailto:sfc@ietf.org> Objet : Re: [sfc] WG
                     = ;       last call for draft-ietf-sfc-nsh-04.txt

                     = ;       If I am understanding you correctly Med, you
                     = ;       are asking that the
                     = ;       NSH draft specify how service chaining
                     = ;       should cope with packets
                     = ;       that have been fragmented?


                     = ;   [Med] To be accurate, I'm asking to assess
                     = ;   whether there are
                     = ;   implications. If there are, then the draft
                     = ;   should be updated
                     = ;   accordingly.

                     = ;       NSH, and the SFF functionality, does not care.


                     = ;   [Med] I'm not that sure. Some typical
                     = ;   implications are listed
                     = ;   below:

                     = ;   * SFF: If the NSH header is present only in the
                     = ;   a fragment but SFF
                     = ;   didn't maintained a state, subsequent fragments
                     = ;   won't be
                     = ;   appropriately processed. * SFC-aware function:
                     = ;   if prepending a
                     = ;   context information depends on the full packet,
                     = ;   not only a
                     = ;   fragment.

                     = ;   It just does its job.

                     = ;   [Med] which may be disturbed in some situations
                     = ;   as listed in the
                     = ;   examples above.

                     = ;       Ingress and intermediate classifiers may
                     = ;       cope with fragments in
                     = ;       any number of ways.

                     = ;   Specifying such is clearly out of scope for this
                     = ;   draft.

                     = ;   [Med] The purpose is not to specify the internal
                     = ;   implementation
                     = ;   details but the external behavior of the
                     = ;   classifier function when
                     = ;   it comes to handle fragments. That behavior may
                     = ;   have an incidence
                     = ;   on SFF, in particular. The purpose is not to
                     = ;   recommend the maximum
                     = ;   resources to be dedicated to out of order
                     = ;   fragments nor the
                     = ;   timeout to cache those; these considerations are
                     = ;   of course out of
                     = ;   scope. Nevertheless, an implementation should
                     = ;   offer a configurable
                     = ;   parameter so that an operator tweak those
                     = ;   according to its
                     = ;   context.

                     = ;       I suppose one could write an informational
                     = ;       draft on possible ways
                     = ;       of coping.  The IETF has not usually
                     = ;       published such.
                     = ;       Service functions have to cope with
                     = ;       fragmented packets just as
                     = ;       they had to before the advent of NSH, so
                     = ;       describing that is
                     = ;       clearly not needed here.


                     = ;   [Med] The advent of NSH has the following
                     = ;   implications: * it
                     = ;   exacerbates fragmentation. Handing over this
                     = ;   issue to the
                     = ;   transport layer may lead to interoperability
                     = ;   issues. * the
                     = ;   chaining may not be efficient if fragments are
                     = ;   inappropriately
                     = ;   handled.

                     = ;   Introducing NSH should not degrade the overall
                     = ;   service compared to
                     = ;   legacy service deployment schemes.


                     = ;       Yours, Joel

                     = ;       On 4/25/16 3:00 AM,
                     = ;       mohamed.boucadair@orange.com
                     = ;       <mailto:mohamed.boucadair@orange.com> wrote:

                     = ;           Re-,

                     = ;           I hear you, but my comment is that we<= br>                      = ;           need, as a WG, to decide
                     = ;           what to

                     = ;       put in the draft. FWIW, I'm discussing two
                     = ;       fragmentation
                     = ;       issues:


                     = ;           (1) Fragmentation that is caused by                      = ;           prepending an SFC header.
                     = ;           (2) Handling fragments at the ingress = of
                     = ;           an SFC-enabled domain.

                     = ;           Increasing the MTU is for sure a
                     = ;           recommendation is to be
                     = ;           explicitly

                     = ;       called out in the text (see my first message).


                     = ;           There are other issues that need to be=
                     = ;           discussed, e.g., how to
                     = ;           deal with

                     = ;       fragments in SFFs/Classifiers?


                     = ;           It is also "prudent" to chec= k that no
                     = ;           issues will be experienced
                     = ;           in SFF

                     = ;       to handle fragments. If an SFC header is
                     = ;       prepended for all
                     = ;       fragments, I'm not sure there

                     = ;           is any particular issue at the SFF
                     = ;           level, except if
                     = ;           stripping/adding

                     = ;       context TLVs depends on the full packet (not
                     = ;       just fragment). It
                     = ;       is warranted to consider a little bit this
                     = ;       point before declaring
                     = ;       there is no issue.


                     = ;           For point (1), declaring fragmentation=
                     = ;           out of scope would be
                     = ;           meant that

                     = ;       an implementation must be prepared to
                     = ;       receive fragments with or
                     = ;       without NSH header as this is a decision
                     = ;       that is left to the
                     = ;       transport encapsulation. This is a
                     = ;       requirement per se!


                     = ;           I won't reiterate all the comments I                      = ;           have about the current
                     = ;           wording of

                     = ;       this section.


                     = ;           Cheers, Med

                     = ;               -----Message d'origine--= --- De :
                     = ;               Elzur, Uri
                     = ;               [mailto:uri.elzur@intel.com
                     = ;               <mailto:uri.elzur@intel.com>] En= voy=E9
                     = ;               : lundi 25 avril 2016                      = ;               08:30 =C0 : BOUCADAIR Mo= hamed IMT/OLN;
                     = ;               Thomas Narten;
                     = ;               sfc@ietf.org <mailto:sfc@ietf.org>
                     = ;               Objet : RE: [sfc] WG las= t call for
                     = ;               draft-ietf-sfc-nsh-04.tx= t

                     = ;               Hi Med

                     = ;               My point is that Fragmen= tation is
                     = ;               yet another transport re= lated
                     = ;               issue

                     = ;       that

                     = ;               is beyond the scope of N= SH and
                     = ;               beyond the charter of th= e WG, so
                     = ;               it

                     = ;       doesn't

                     = ;               really belong in the dra= ft. We are
                     = ;               providing an advice as                      = ;               extending the size of th= e packet may
                     = ;               lead to fragmentation, b= ut
                     = ;               as you check RFC 7348 Vx= LAN, which
                     = ;               my create the same issue= ,
                     = ;               you'll find it doesn't e= ven

                     = ;       relate

                     = ;               to it.

                     = ;               Thx

                     = ;               Uri ("Oo-Ree")= C: 949-378-7568
                     = ;               <tel:949-378-7568>


                     = ;               -----Original Message---= -- From: sfc
                     = ;               [mailto:sfc-bounces@ietf.org
                     = ;               <mailto:sfc-bounces@ietf.org>] = On
                     = ;               Behalf Of
                     = ;               mohamed.boucadair@orange.com
                     = ;               <mailto:mohamed.boucadair@oran= ge.com> Sent:
                     = ;               Sunday, April 24, 2016                      = ;               10:32 PM To: Elzur, Uri<= br>                      = ;               <uri.elzur@intel.com
                     = ;               <mailto:uri.elzur@intel.com>>= ;
                     = ;               Thomas Narten

                     = ;       <narten@us.ibm.com <mailto:narten@us.ibm.com>>;

                     = ;               sfc@ietf.org <mailto:sfc@ietf.org>
                     = ;               Subject: Re: [sfc] WG la= st call for
                     = ;               draft-ietf-sfc-nsh-04.tx= t

                     = ;               Hi Uri,

                     = ;               That's another option th= at needs to
                     = ;               be discussed/investigate= d.
                     = ;               I'm

                     = ;       afraid

                     = ;               this is not the rational= e adopted in
                     = ;               -04 since it includes so= me
                     = ;               text

                     = ;       that

                     = ;               is far to be sufficient = to ensure
                     = ;               interoperable
                     = ;               implementations.

                     = ;               BTW, saying that nsh doe= s not need
                     = ;               to deal with fragmentati= on
                     = ;               because

                     = ;       it

                     = ;               is transport-independent= is not IMHO
                     = ;               a good strategy to adopt=
                     = ;               here

                     = ;       because

                     = ;               it opens the door for in= teroperable
                     = ;               issues, it may lead to                      = ;               sub-optimal implementati= ons if the
                     = ;               sfc information is prese= nt
                     = ;               only in one

                     = ;       fragments,

                     = ;               etc.

                     = ;               My comments are related = to the
                     = ;               current text in the -04.=
                     = ;               This text needs

                     = ;       to

                     = ;               be fixed somehow.

                     = ;               Cheers, Med

                     = ;                   -----Messa= ge d'origine----- De :
                     = ;                   Elzur, Uri=
                     = ;                   [mailto:uri.elzur@intel.com<= /a>
                     = ;                   <mailto= :uri.elzur@intel.c= om>]
                     = ;                   Envoy=E9 := dimanche 24 avril
                     = ;                   2016 17:36= =C0 : BOUCADAIR Mohamed
                     = ;                   IMT/OLN; T= homas Narten;
                     = ;                   sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org> Obj= et :
                     = ;                   RE: [sfc] = WG last call for
                     = ;                   draft-ietf= -sfc-nsh-04.txt

                     = ;                   Hi Med

                     = ;                   I see no n= eed to specify the
                     = ;                   exact beha= vior as NSH is
                     = ;                   transport = independent i.e. like
                     = ;                   NSH intera= ction with any other
                     = ;                   Transport = eh issue of
                     = ;                   Fragmentat= ion is to be dealt in
                     = ;                   a way
                     = ;                   that match= es the mechanisms
                     = ;                   supported = by the Transport used
                     = ;                   and do not= belong in the NSH draft

                     = ;                   Thx

                     = ;                   Uri ("= ;Oo-Ree") C: 949-378-7568
                     = ;                   <tel:949-378-7568>


                     = ;                   -----Origi= nal Message----- From: sfc
                     = ;                   [mailto:sfc-bounces@ietf.or= g
                     = ;                   <mailto= :sfc-bounces@ietf= .org>]
                     = ;                   On Behalf = Of
                     = ;                   mohamed.boucadair@orange.com
                     = ;                   <mailto= :mohamed.= boucadair@orange.com>
                     = ;                   Sent: Thur= sday, April 14,
                     = ;                   2016 12:43= AM To: Thomas Narten
                     = ;                   <narten@us.ibm.com
                     = ;                   <mailto= :narten@us.ibm.com>>;
                     = ;                   sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org> Sub= ject:
                     = ;                   Re: [sfc] = WG last call for
                     = ;                   draft-ietf= -sfc-nsh-04.txt

                     = ;                   R-,

                     = ;                   In additio= n to other pending
                     = ;                   issues rai= sed for this draft, I
                     = ;                   would like= to raise this
                     = ;                   additional= one about Section 6.

                     = ;                   =3D=3D 6.&= nbsp; Fragmentation Considerations

                     = ;                   NSH and th= e associated transport
                     = ;                   header are= "added" to the
                     = ;                   encapsulat= ed packet/frame.  This
                     = ;                   additional= information
                     = ;                   increases<= br>
                     = ;       the

                     = ;                   size of th= e packet.  In order
                     = ;                   the ensure= proper forwarding of
                     = ;                   NSH data, = several options for
                     = ;                   handling f= ragmentation and
                     = ;                   re-assembl= y exist:

                     = ;                   1.  J= umbo Frames, when
                     = ;                   supported,= enable the transport
                     = ;                   of NSH
                     = ;                   and associ= ated transport packets
                     = ;                   without re= quiring
                     = ;                   fragmentat= ion.

                     = ;                   2.  P= ath MTU Discovery
                     = ;                   [RFC1191]&= quot;describes a technique for
                     = ;                   dynamicall= y discovering the
                     = ;                   maximum tr= ansmission unit (MTU) of

                     = ;       an

                     = ;                   arbitrary = internet path" and can
                     = ;                   be utilize= d to ensure the

                     = ;   the

                     = ;                   required p= acket size is used.

                     = ;                   3.  [= RFC6830] describes two
                     = ;                   schemes fo= r fragmentation and
                     = ;                   re-

                     = ;       assembly

                     = ;                   in section= 5.4. =3D=3D

                     = ;                   * The text= is weak for a
                     = ;                   Standard t= rack document that is
                     = ;                   intended t= o solve the problem in
                     = ;                   https://tools.ietf.org/html/rfc7498#section-

                     = ;   2.12.

                     = ;                   There shou= ld be a clear behavior
                     = ;                   to be foll= owed by an

                     = ;   implementation.

                     = ;                   Further, I= would avoid the use
                     = ;                   of words s= uch as "can".

                     = ;                   * The text= covers only
                     = ;                   fragmentat= ion when it is induced
                     = ;                   by SFC
                     = ;                   operations= , it does not discuss
                     = ;                   the treatm= ent of a fragment
                     = ;                   when recei= ved in an SFC domain.
                     = ;                   IMHO, the = draft should also
                     = ;                   specify th= e behavior of the
                     = ;                   Classifier= with regards to
                     = ;                   fragments = for the sake of proper
                     = ;                   SFC operat= ion. Applying
                     = ;                   classifica= tion policies may
                     = ;                   require th= e

                     = ;               full packet, not only a = fragment.

                     = ;                   In particu= lar, dedicated
                     = ;                   resources = should dedicated for
                     = ;                   handling o= ut of order fragments.
                     = ;                   Of course,= it is out of scope
                     = ;                   of this do= cument to describe how
                     = ;                   SFs handle= fragments.

                     = ;                   * If an SF= C header is prepended
                     = ;                   for all fr= agments, I'm not
                     = ;                   sure there= is any particular
                     = ;                   issue at t= he SFF level...except
                     = ;                   if strippi= ng/adding context TLVs
                     = ;                   depends on= the full packet
                     = ;                   (not just = fragment). It is
                     = ;                   warranted = to consider a little bit
                     = ;                   this point= before declaring there

                     = ;       is

                     = ;               no issue.


                     = ;                   * The text= states "several
                     = ;                   options&qu= ot;. This may be interpreted
                     = ;                   as if impl= ementing one of them
                     = ;                   is suffici= ent...which is not
                     = ;                   true. The = first two points
                     = ;                   contribute= to minimize the
                     = ;                   fragmentat= ion risk, but
                     = ;                   fragmentat= ion may still be
                     = ;                   experience= d
                     = ;                   (e.g., oth= er shims are prepended
                     = ;                   by other n= odes for some other
                     = ;                   purposes, = nested nsh, etc.)

                     = ;                   * The firs= t two points have
                     = ;                   nothing to= do with reassembly.

                     = ;                   * The supp= ort of jumbo frames by
                     = ;                   a router/d= evice does not mean
                     = ;                   that it ca= n make use of it.
                     = ;                   Appropriat= e MTU configuration
                     = ;                   should be = undertaken in a
                     = ;                   consistent= manner within an SFC
                     = ;                   domain. Th= e text should be
                     = ;                   updated to= make it is about
                     = ;                   (consisten= t) MTU

                     = ;   configuration.


                     = ;                   * BTW, sho= uldn't the text be
                     = ;                   reworded t= o recommended to
                     = ;                   increase t= he MTU of **all
                     = ;                   nodes** of= an SFC-enabled domain by
                     = ;                   at least t= he length of SFC
                     = ;                   header = 3; transport header?

                     = ;                   * Bullet 2= , how PMTU discovery
                     = ;                   is actuall= y used in this
                     = ;                   context? D= o you assume that all
                     = ;                   SFC-aware = nodes will issue
                     = ;                   such messa= ges towards other
                     = ;                   SFC-aware = node, arbitrary
                     = ;                   destinatio= n, else?

                     = ;                   * Bullet 2= , I would drop
                     = ;                   "desc= ribes a technique for
                     = ;                   dynamicall= y discovering the
                     = ;                   maximum tr= ansmission unit
                     = ;                   (MTU) of a= n arbitrary internet
                     = ;                   path"= .

                     = ;                   * Bullet 2= , s/ the the/the.

                     = ;                   * The refe= rence to the LISP
                     = ;                   specificat= ion raises two concerns
                     = ;                   and one co= mment:

                     = ;                   (1) I don'= t think it is a good
                     = ;                   approach t= hat fragments induced
                     = ;                   by the net= work are passed to
                     = ;                   their ulti= mate destinations as
                     = ;                   such

                     = ;   (stateless).

                     = ;                   IMO, reass= embly should be done
                     = ;                   within the= SFC domain
                     = ;                   (responsib= le for fragmentation)
                     = ;                   not passed= away. (2) Does the
                     = ;                   stateful m= ode require all SFC
                     = ;                   data plane= elements maintain a
                     = ;                   full list = of MTU for the any
                     = ;                   SFF/SF ins= tance of the SFC

                     = ;               domain?


                     = ;                   The curren= t text suggests that
                     = ;                   [RFC6830] = should be listed as
                     = ;                   normative = reference (not an
                     = ;                   informativ= e one). I would
                     = ;                   personally= favor removing the
                     = ;                   reference = to LISP (as it is an
                     = ;                   Experiment= al RFC).

                     = ;                   * The secu= rity section of the
                     = ;                   draft may = be augmented with
                     = ;                   informatio= nal
                     = ;                   fragmentat= ion-related pointers to:
                     = ;                   e.g., RFC1= 858 (Security
                     = ;                   Considerat= ions for IP Fragment
                     = ;                   Filtering)= , RFC3128 (Protection
                     = ;                   Against a = Variant of the Tiny
                     = ;                   Fragment A= ttack), and RFC 4963
                     = ;                   (IPv4 Reas= sembly Errors at High
                     = ;                   Data Rates= ).

                     = ;                   Cheers, Me= d

                     = ;                     &nb= sp; -----Message d'origine-----
                     = ;                     &nb= sp; De : sfc
                     = ;                     &nb= sp; [mailto:sfc-b= ounces@ietf.org
                     = ;                     &nb= sp; <mailto:sf= c-bounces@ietf.org>]
                     = ;                     &nb= sp; De la part de
                     = ;                     &nb= sp; mohamed.boucadair@orange.com
                     = ;                     &nb= sp; <mailto:mohamed.boucadair@orange.com>
                     = ;                     &nb= sp; Envoy=E9 : lundi 11 avril
                     = ;                     &nb= sp; 2016 13:14 =C0 : Thomas
                     = ;                     &nb= sp; Narten; sfc@ietf.org
                     = ;                     &nb= sp; <mailto:sfc@ietf.o= rg> Objet
                     = ;                     &nb= sp; : Re:
                     = ;                     &nb= sp; [sfc] WG last call for
                     = ;                     &nb= sp; draft-ietf-sfc-nsh-04.txt

                     = ;                     &nb= sp; Dear Thomas, all,

                     = ;                     &nb= sp; As I mentioned during the
                     = ;                     &nb= sp; meeting, there are several
                     = ;                     &nb= sp; issues
                     = ;                     &nb= sp; that are not covered in the
                     = ;                     &nb= sp; last version of the draft. I
                     = ;                     &nb= sp; already provided examples of
                     = ;                     &nb= sp; the issues offline as requested
                     = ;                     &nb= sp; by Martin.

                     = ;                     &nb= sp; Cheers, Med

                     = ;                     &nb= sp;     -----Message
                     = ;                     &nb= sp;     d'origine----- De : sfc
                     = ;                     &nb= sp;     [mailto:sfc-bounces@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc-bounces@ietf.org>]
                     = ;                     &nb= sp;     De la part de Thomas Narten
                     = ;                     &nb= sp;     Envoy=E9 : jeudi 31 mars
                     = ;                     &nb= sp;     2016 04:48 =C0 :
                     = ;                     &nb= sp;     sfc@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc@ietf.org>
                     = ;                     &nb= sp;     Objet : [sfc] WG last
                     = ;                     &nb= sp;     call for
                     = ;                     &nb= sp;     draft-ietf-sfc-nsh-04.txt

                     = ;                     &nb= sp;     Dear WG:

                     = ;                     &nb= sp;     This note begins a WG
                     = ;                     &nb= sp;     last call on
                     = ;                     &nb= sp;     draft-ietf-sfc-nsh-04.txt
                     = ;                     &nb= sp;     (https://datatracker.ietf.org/doc/draft-ietf-sfc-= nsh/).



            The editors of the NSH document h= ave indicated that they have

                     = ;                     &nb= sp;     addressed all known
                     = ;                     &nb= sp;     comments and that there
                     = ;                     &nb= sp;     are no open
                     = ;                     &nb= sp;     issues with the current
                     = ;                     &nb= sp;     version of the document.

                     = ;                     &nb= sp;     Substantive comments to
                     = ;                     &nb= sp;     the list please,
                     = ;                     &nb= sp;     editorial comments
                     = ;                     &nb= sp;     can go directly to the
                     = ;                     &nb= sp;     document editors.

                     = ;                     &nb= sp;     We'll also get a brief
                     = ;                     &nb= sp;     update from the editors
                     = ;                     &nb= sp;     at next
                     = ;                     &nb= sp;     week's meeting. If there
                     = ;                     &nb= sp;     are any remaining issues
                     = ;                     &nb= sp;     with the
                     = ;                     &nb= sp;     document, raising them
                     = ;                     &nb= sp;     before the meeting would be
                     = ;                     &nb= sp;     especially helpful.

                     = ;                     &nb= sp;     For the chairs, Thomas

                     = ;                     &nb= sp;     _______________________________________________
                     = ;                     &nb= sp;     sfc mailing
                     = ;                     &nb= sp;     list sfc@ietf.org
                     = ;                     &nb= sp;     <mailto:sfc@ietf.org>
                     = ;                     &nb= sp;     https://www.ietf.org/mailman/listinfo/sfc


                     = ;                     &nb= sp; _______________________________________________
                     = ;                     &nb= sp; sfc mailing
                     = ;                     &nb= sp; list sfc@ietf.org
                     = ;                     &nb= sp; <mailto:sfc@ietf.o= rg>
                     = ;                     &nb= sp; https://www.ietf.org/mailman/listinfo/sfc


                     = ;                   __________= _____________________________________
                     = ;                   sfc mailin= g
                     = ;                   list sfc@ietf.org
                     = ;                   <mailto= :sfc@ietf.org>
                     = ;                   https://www.ietf.org/mailman/listinfo/sfc


                     = ;               ________________________= _______________________
                     = ;               sfc mailing

 

 --_000_D348FA2D4C885jguicharciscocom_-- From nobody Fri Apr 29 09:23:17 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 3C69A12D1D8 for ; Fri, 29 Apr 2016 09:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 pNAluwD2q9Wq for ; Fri, 29 Apr 2016 09:23:06 -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 5B7BA12D1D2 for ; Fri, 29 Apr 2016 09:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7156; q=dns/txt; s=iport; t=1461946986; x=1463156586; h=from:to:subject:date:message-id:mime-version; bh=dNaqSCZgfwCYE0+zgX7tP/HOLHvjcFkhQulI+CbQGkk=; b=JXwO8zJ9wkbcPwoHyOal/0pmPWC6ii9e6ZC1MtauXvYTLgCcW5js4J6c yJa6HwVHKEJPvyEmtojmvSGyFEJe5e5kWaVrH/LnnUxLJ3dQpDWDLAqc9 qa5ty2Z7/XJc1FZREPhcBvtXGNluf3ZalH3NNDVXnxiBri38EdjAQIkup 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAgAkiiNX/4UNJK1dgmxMgUIOBrR3h?= =?us-ascii?q?HMBDYF2hhCBLTgUAQEBAQEBAWUnhEEBAQUdbgEIEQMBAig5FAkKBAESiCrEYQE?= =?us-ascii?q?BAQEBBQEBAQEBARqGIYRMhA8RATyFNgWODoUUhHEBjhaBZ4RNiF2PLwEeAQFCg?= =?us-ascii?q?2tsh0w2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208,217";a="266953571" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 16:23:05 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3TGN5jN007902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Apr 2016 16:23:05 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 11:23:04 -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.1104.009; Fri, 29 Apr 2016 11:23:03 -0500 From: "Jim Guichard (jguichar)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Thread-Index: AQHRojNnrFMuf4oP40+/x3o+g9IIvg== Date: Fri, 29 Apr 2016 16:23:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D34901FD4C89Bjguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 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, 29 Apr 2016 16:23:10 -0000 --_000_D34901FD4C89Bjguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: Thank you for your feedback on draft-penno-sfc-trace-03 as a WG document. W= e have received good support for adoption of the draft and therefore author= s, please post a new version as draft-ietf-sfc-trace-00. Thank You! Jim From: sfc > on behalf of = Jim Guichard > Date: Thursday, February 11, 2016 at 3:18 PM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-penno-sfc-trace-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-trace-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_D34901FD4C89Bjguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <856885671EEE634EAAB92BAFD6CE63F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Dear WG:

Thank you for your feedback on draft-penno-sfc-trace-03 as a WG docume= nt. We have received good support for adoption of the draft and therefore a= uthors, please post a new version as draft-ietf-sfc-trace-00.

Thank You!

Jim

From: sfc <sfc-bounces@ietf.org> on behalf of Jim Guichard &= lt;jguichar@cisco.com>
Date: Thursday, February 11, 2016 a= t 3:18 PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for WG adoption= of draft-penno-sfc-trace-03

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-trace-03 as a WG document. The = call for adoption will run for 2 weeks ending 2/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG’s = decisions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is als= o a good time to poll for knowledge of any IPR that applies to this draft, = in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).= If you are listed as a document author please respond to this email (to th= e chairs) whether or not you are aware of any relevant IPR.


Thanks!


SFC Chairs

--_000_D34901FD4C89Bjguicharciscocom_-- From nobody Fri Apr 29 09:31:19 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 960D012D199 for ; Fri, 29 Apr 2016 09:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 I-sc0Xwg1icC for ; Fri, 29 Apr 2016 09:31:16 -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 8004212D1B3 for ; Fri, 29 Apr 2016 09:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7071; q=dns/txt; s=iport; t=1461947476; x=1463157076; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NgTm5Ad2ZjcNojGUoJqZ6+22KHwz4+f0mTLDF0/7M74=; b=mIW+sVQ9OWT8dkxmSywH1gBK1ucV0yRXj27alahCU3R/VI1UKq1xhl8A mnFgoyhkN7Y3hfYj2bGitEvweWzBP3P9yWc9msg3LTF23MK6q4PDCFjmj wR227M9/xaXqLScgTXrqAXoGC4FGmLFaxaurP7i/6ENv2gv/lq4tms7SU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAgChiyNX/5FdJa1dgmxMgVAGtHmEc?= =?us-ascii?q?wENgXaGEAKBKzgUAQEBAQEBAWUcC4RBAQEBBB1sAgEZAwECKAcyFAkIAgQTiCr?= =?us-ascii?q?EZAEBAQEBAQEBAQEBAQEBAQEBAQEXhiGIWxEBPIU2BY4OhRSEcQGBLYxpgWeET?= =?us-ascii?q?Yhdjy8BHgEBQoIFG4FLbIdMNn8BAQE?= X-IronPort-AV: E=Sophos; i="5.24,552,1454976000"; d="scan'208,217"; a="99363046" 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; 29 Apr 2016 16:31:15 +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 u3TGVFcR006077 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Apr 2016 16:31:15 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.1104.5; Fri, 29 Apr 2016 11:31:14 -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.1104.009; Fri, 29 Apr 2016 11:31:14 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRZQHOvGZf31kz6UifjJTvmDJQAZ+hr9aA Date: Fri, 29 Apr 2016 16:31:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D34904044C8A3jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 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, 29 Apr 2016 16:31:18 -0000 --_000_D34904044C8A3jguicharciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: We did not receive many responses for this call for adoption and therefore = would like to re-invite people to post their thoughts on adopting this docu= ment into the SFC WG. The call for adoption will run for a further 2 weeks = ending 6/13/2016. Thanks! SFC Chairs From: Jim Guichard > Date: Thursday, February 11, 2016 at 3:24 PM To: "sfc@ietf.org" > Subject: Call for WG adoption of draft-penno-sfc-appid-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-appid-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_D34904044C8A3jguicharciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <72C4D93262357A4298A4E1C926F828AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Dear WG:

We did not receive many responses for this call for adoption and there= fore would like to re-invite people to post their thoughts on adopting this= document into the SFC WG. The call for adoption will run for a further 2 w= eeks ending 6/13/2016. 

Thanks!

SFC Chairs

From: Jim Guichard <jguichar@cisco.com>
Date: Thursday, February 11, 2016 a= t 3:24 PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Call for WG adoption of dr= aft-penno-sfc-appid-03

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-appid-03 as a WG document. The = call for adoption will run for 2 weeks ending 2/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG’s = decisions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is als= o a good time to poll for knowledge of any IPR that applies to this draft, = in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).= If you are listed as a document author please respond to this email (to th= e chairs) whether or not you are aware of any relevant IPR.


Thanks!


SFC Chairs

--_000_D34904044C8A3jguicharciscocom_-- From nobody Fri Apr 29 10:41: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 EFADB12D167 for ; Fri, 29 Apr 2016 10:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 gwnusDN3DW_n for ; Fri, 29 Apr 2016 10:41:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D5012D11F for ; Fri, 29 Apr 2016 10:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8735; q=dns/txt; s=iport; t=1461951692; x=1463161292; h=from:to:subject:date:message-id:mime-version; bh=F7Vo5fTw4PAd1NeUeXALBUO5XVnb0Aw9vWrV0yYU3T0=; b=DV4IOP+bM7DUcFi8pkYXI5t6i2wI57er/T5xmVwg/6kjSQK+Y2brjsTp GfoD98H7C4klM3WwDOvYiSYUmfZskTdSaZe/KzMAlxXLlzSdcLILnIF8x VwKaBMB2mgAIuzP7mT7AcEyXmRCR3BUhVzYalTbfAbZ6y39Y6k+jlU3V6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAgAHnCNX/4wNJK1dgmxMgVAGtHmEc?= =?us-ascii?q?wENgXaGEIEuOBQBAQEBAQEBZSeEQQEBBR1uAQgRAwECKDkUCQoEARKIKsR8AQE?= =?us-ascii?q?BAQEFAQEBAQEBGopthA8RATyFNgWODoUUhHEBjhaBZ4RNiF2PLwEeAQFCggUbg?= =?us-ascii?q?Utsh0w2fwEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,552,1454976000"; d="scan'208,217"; a="99220111" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 17:41:31 +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 u3THfVvJ013528 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 29 Apr 2016 17:41:31 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 12:41:30 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 12:41:30 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Thread-Index: AQHRoj5dGTJSUC0nfUiLJR/vcLXzfw== Date: Fri, 29 Apr 2016 17:41:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.234.13] Content-Type: multipart/alternative; boundary="_000_D34914FE14560Bnaikumarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 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, 29 Apr 2016 17:41:34 -0000 --_000_D34914FE14560Bnaikumarciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Support. Regards, Nagendra From: sfc > on behalf of = "Jim Guichard (jguichar)" > Date: Friday, April 29, 2016 at 12:31 PM To: "sfc@ietf.org" > Subject: [sfc] Call for WG adoption of draft-penno-sfc-appid-03 Dear WG: We did not receive many responses for this call for adoption and therefore = would like to re-invite people to post their thoughts on adopting this docu= ment into the SFC WG. The call for adoption will run for a further 2 weeks = ending 6/13/2016. Thanks! SFC Chairs From: Jim Guichard > Date: Thursday, February 11, 2016 at 3:24 PM To: "sfc@ietf.org" > Subject: Call for WG adoption of draft-penno-sfc-appid-03 Dear WG: This email serves as a call for WG adoption of draft-penno-sfc-appid-03 as = a WG document. The call for adoption will run for 2 weeks ending 2/25/2016. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Thanks! SFC Chairs --_000_D34914FE14560Bnaikumarciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <23544AD3C6030A46B1908822F2EEDFF1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support.

Regards,
Nagendra

From: sfc <sfc-bounces@ietf.org> on behalf of "Jim Guic= hard (jguichar)" <jguichar@ci= sco.com>
Date: Friday, April 29, 2016 at 12:= 31 PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] Call for WG adoption= of draft-penno-sfc-appid-03

Dear WG:

We did not receive many responses for this call for adoption and there= fore would like to re-invite people to post their thoughts on adopting this= document into the SFC WG. The call for adoption will run for a further 2 w= eeks ending 6/13/2016. 

Thanks!

SFC Chairs

From: Jim Guichard <jguichar@cisco.com>
Date: Thursday, February 11, 2016 a= t 3:24 PM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: Call for WG adoption of dr= aft-penno-sfc-appid-03

Dear WG:


This email serves a= s a call for WG adoption of draft-penno-sfc-appid-03 as a WG document. The = call for adoption will run for 2 weeks ending 2/25/2016.

 

Please note that th= is is a call for adoption, and not a last call for content of the document.= Adopting a WG document simply means that the WG will focus its efforts on that particular draft going forward, and = use that document for resolving open issues and documenting the WG’s = decisions.

 

Please indicate whe= ther you support adoption for not, and if not why. Issues you have with the= current document itself can also be raised, but they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. 

 

Finally, now is als= o a good time to poll for knowledge of any IPR that applies to this draft, = in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details).= If you are listed as a document author please respond to this email (to th= e chairs) whether or not you are aware of any relevant IPR.


Thanks!


SFC Chairs

--_000_D34914FE14560Bnaikumarciscocom_-- From nobody Fri Apr 29 14:33:42 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 E923812D1DD for ; Fri, 29 Apr 2016 14:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 GwBgB2yQUrYz for ; Fri, 29 Apr 2016 14:33:38 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C912D742 for ; Fri, 29 Apr 2016 14:33:38 -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.0195.001; Fri, 29 Apr 2016 17:33:37 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: draft-ietf-sfc-control-plane -- C3 interface Thread-Index: AdGiKlPylIfr42rfQei+e06aOHat/gALj+Bg Date: Fri, 29 Apr 2016 21:33:37 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D6201C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D6201C@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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830F46E8Dwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-control-plane -- C3 interface 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, 29 Apr 2016 21:33:41 -0000 --_000_E8355113905631478EFF04F5AA706E9830F46E8Dwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Med, Please see inline [DD2] From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Friday, April 29, 2016 11:18 AM To: Dave Dolson; sfc@ietf.org Subject: RE: draft-ietf-sfc-control-plane -- C3 interface Re-, Please see inline. Cheers, Med De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : vendredi 29 avril 2016 16:24 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Objet : RE: draft-ietf-sfc-control-plane -- C3 interface [..] E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-= packet-02.txt Maybe add this paragraph: "This interface informs the SFC-aware SF about the method for handling bidi= rectional paths, either by conveying the algorithmic method to use, or by providing forward/= reverse path mapping." [Med] I'm hesitating to add text about the "algorithmic method" as I don't = have a document to cite. Note that some stateful SFs (e.g., NAT) will natur= ally add a reverse mapping to handle incoming packets without requiring inp= uts from the CP. What do you mean by "providing forward/reverse path mappin= g"? Is it SF-specific mapping? [DD] I agree there is a lack of material to cite... [DD] What I mean is informing the SF that "path X is the complementary path= of path Y". E.g., "Paths 100 (upstream) and 101 (downstream) are pairs. Re= spond to a path-100 packet on path 101." [Med] Thank you for the clarification. What would be the added value of pro= viding that information (X complementary of Y) if we assume that two classi= fication rules are installed to handle both directions? [DD2] Please see the new https://tools.ietf.org/html/draft-penno-sfc-packet= -03, which discusses the need for symmetric path information. Section 5.1 = talks about using the control plane to provide this information. If this ap= proach is taken, the C3 interface would provide the information. What about adding this NEW text at the end of Section 4.2? NEW: Typically, C2 interface is used to ensure that the same SF instance is involved in both directions of a flow (including, to ensure full chain symmetry). [DD] I disagree that C2 has anything to do with this. Instead, C1 must be u= sed to provide consistent classification. [Med] The example I have in mind is an a statefull NAT that is attached to = a given SFF while the Classifier hasn't the visibility on the full forwardi= ng path. The classifier in such case has no means to force that the same SF= instance will be invoked for both direction. Wouldn't C2 be involved in su= ch case? [DD2] OK, I see your point, but this is different than my concern, which is= that if the SF needs to know about related forward/reverse paths, then the= C3 interface has this responsibility. [DD] How about adding the generic statement to section 3.3.3, "Some SFs may= need to be configured regarding the rules for packet reversal on a path. T= he controller may use the C3 interface to specify how packets on a path may= be placed on the reverse path." [Med] What is specific in this case compared to configuring two classificat= ion rules; one for each direction? Is there something the classifier is sup= posed to do? [DD2] I hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains= why SFs need to know this. ... [Med] FWIW, context information is mentioned in the WG charter "communicate= s context information between nodes that implement". What about this change= to avoid confusion: OLD: This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC. NEW: This interface is also used to instruct an SFC-aware SF about any context information (a.k.a., metadata) it needs to supply for a given SFC. [DD] Again, is this intended to mean adding information to a packet? Or is = "supply" intentionally vague about the delivery mechanism? [Med] "Supply" is intentional here as this covers both cases: (1) add a new= information to a packer (e.g., a new TLV), (2) update the context of an ex= isting TLV. [DD2] I think we agree on the purpose. But if it is configuration about how= to modify packets, I think you should say so; otherwise one might think it= is about supplying information out-of-band in the control-plane. Would you= change "... it needs to supply for a given SFC." to "... it needs to attac= h to packets for a given SFC." ? Regarding this paragraph, I think it would be cleaner if this behavior actu= ally requires the C2 interface into the SF. [Med] I do think the current wording is correct. Having an SFF co-located w= ith a set of SFs is deployment-specific according to the SFC architecture R= FC. [DD] I agree with that statement. However, I think the case being described= is when there *is* a co-located SFF, but the text is pretending there isn'= t. If the following text remains, C3 will need to include all the functiona= lity of C2. [Med] I re-confirm that the initial case we wanted to cover by this text is= an SFF servicing a group of SFs that are embedded in a distinct physical n= ode. This scenario suppose that once an SF is consumed it sends back the pa= cket to the SFF that may undertake another hook to another SF in that node = and so on. The packet is not handed from an SF to another one without solic= iting the external SFF. That's sub-optimal, I agree. The text is currently = silent whether the distinct locators are configured using the C2 interface = (assuming that a distinct management interface is used between the control = element and an SFC-aware SF). [DD2] If you wish the text to be silent on which interface, then you should= move it out of section "3.3.3 C3: Interface between SFC Control Plane & SF= C-aware SFs". [DD2] But again, I think you should avoid discussing how an SF can be confi= gured to send traffic directly to another SF, which I don't think is archit= ecturally correct. There needs to be a (co-located) SFF to connect them. --_000_E8355113905631478EFF04F5AA706E9830F46E8Dwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Med,=

Please see inline [DD2= ]

 

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, April 29, 2016 11:18 AM
To: Dave Dolson; sfc@ietf.org
Subject: RE: draft-ietf-sfc-control-plane -- C3 interface=

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : vendredi 29 avril 2016 16:24
=C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

 

[..]=

 

E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt<= /span>

Maybe add this paragraph:

“This interface informs the SFC-aware SF about= the method for handling bidirectional paths,

either by conveying the algorithmic method to use, o= r by providing forward/reverse path

mapping.”

 

[Med] I’m hesitating to add text about t= he “algorithmic method” as I don’t have a document to cit= e. Note that some stateful SFs (e.g., NAT) will naturally add a reverse mapping to handle incoming packets without requiring inputs from the CP. W= hat do you mean by “providing forward/reverse path mapping”? Is= it SF-specific mapping?

 

[DD] I agree there is = a lack of material to cite…

[DD] What I mean is in= forming the SF that “path X is the complementary path of path Y”= ;. E.g., “Paths 100 (upstream) and 101 (downstream) are pairs. Respon= d to a path-100 packet on path 101.”

[Med] Thank you for the clarification. What woul= d be the added value of providing that information (X complementary of Y) i= f we assume that two classification rules are installed to handle both directions?  

[DD2] Please see the n= ew https://tools.ietf.org/html/draft-penno-sfc-packet-03, which discusses the need for symmetric= path information.  Section 5.1 talks about using the control plane t= o provide this information. If this approach is taken, the C3 interface would provide the information.

 

What about adding this NEW text at the end of = Section 4.2?

 

NEW:

   Typically, C2 interface is used t= o ensure that the same SF instance

   is involved in both directio= ns of a flow (including, to ensure full

   chain symmetry).

[DD] I disagree that C= 2 has anything to do with this. Instead, C1 must be used to provide consist= ent classification.

[Med] The example I have in mind is an a statefu= ll NAT that is attached to a given SFF while the Classifier hasn’t th= e visibility on the full forwarding path. The classifier in such case has no means to force that the same SF instance will be invok= ed for both direction. Wouldn’t C2 be involved in such case? &nb= sp;

[DD2] OK, I see your p= oint, but this is different than my concern, which is that if the SF needs = to know about related forward/reverse paths, then the C3 interface has this= responsibility.

 

[DD] How about adding = the generic statement to section 3.3.3, “Some SFs may need to be conf= igured regarding the rules for packet reversal on a path. The controller ma= y use the C3 interface to specify how packets on a path may be placed on the reverse path.”

[Med] What is specific in this case compared to = configuring two classification rules; one for each direction? Is there some= thing the classifier is supposed to do? 

[DD2] I hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains why SFs = need to know this.

&=
nbsp;  

…


 


[Med] FWIW, context information is mentioned i=
n the WG charter “communicates context information between nodes that=
 implement”. What about this change to avoid confusion:


 


OLD:


=
   This interface is also used to instruct an SFC-aware SF about =
any


=
   context information it needs to supply in the context of a giv=
en SFC.


 


NEW:


=
   This interface is also used to instruct an SFC-aware SF about =
any


=
   context information (a.k.a., metadata) it needs to supply



=
   for a given SFC.


[DD] Again, is this in=
tended to mean adding information to a packet? Or is “supply” i=
ntentionally vague about the delivery mechanism?


[Med] “Supply” is intentional here a=
s this covers both cases: (1) add a new information to a packer (e.g., a ne=
w TLV), (2) update the context of an existing TLV.



[DD2] I think we agree=
 on the purpose. But if it is configuration about how to modify packets, I =
think you should say so; otherwise one might think it is about supplying in=
formation out-of-band in the control-plane.
 Would you change “… it needs to supply for a given SFC.”=
 to “… it needs to attach to packets for a given SFC.” ?<=
o:p>


 


 


Regarding this paragraph, I think it would be cleane=
r if this behavior actually requires the C2 interface into the SF.


 


[Med] I do think the current wording is correc=
t. Having an SFF co-located with a set of SFs is deployment-specific accord=
ing to the SFC architecture RFC.


[DD] I agree with that=
 statement. However, I think the case being described is when there *is<=
/b>* a co-located SFF, but the text is pretending there isn’t. If the=
 following text remains, C3 will need to include
 all the functionality of C2.=



[Med] I re-confirm that the initial case we want=
ed to cover by this text is an SFF servicing a group of SFs that are embedd=
ed in a distinct physical node. This scenario
 suppose that once an SF is consumed it sends back the packet to the SFF th=
at may undertake another hook to another SF in that node and so on. The pac=
ket is not handed from an SF to another one without soliciting the external=
 SFF. That’s sub-optimal, I agree.
 The text is currently silent whether the distinct locators are configured =
using the C2 interface (assuming that a distinct management interface is us=
ed between the control element and an SFC-aware SF).



[DD2] If you wish the =
text to be silent on which interface, then you should move it out of sectio=
n “3.3.3 C3: Interface between SFC Control Plane & SFC-aware SFs&=
#8221;.


[DD2] But again, I thi=
nk you should avoid discussing how an SF can be configured to send traffic =
directly to another SF, which I don’t think is architecturally correc=
t. There needs to be a (co-located) SFF to
 connect them.


 


 


    


 
--_000_E8355113905631478EFF04F5AA706E9830F46E8Dwtlexchp2sandvi_--