From nobody Sun Sep 2 14:28:15 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93866130DF0; Sun, 2 Sep 2018 14:28:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <153592368953.16514.967420125387671097@ietfa.amsl.com> Date: Sun, 02 Sep 2018 14:28:09 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-15.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 21:28:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Segment Routing interworking with LDP Authors : Ahmed Bashandy Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-15.txt Pages : 23 Date : 2018-09-02 Abstract: A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-15 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-ldp-interop-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-15 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 Sun Sep 2 14:29:08 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995D3130DF1; Sun, 2 Sep 2018 14:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 aTJ6L6vzAiBz; Sun, 2 Sep 2018 14:29:00 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 72295130E11; Sun, 2 Sep 2018 14:29:00 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id 2-v6so7150964pgo.4; Sun, 02 Sep 2018 14:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=RltJJu9iW4bH0ZoYktiSC+evINgHsT8Vxx09myqRIbU=; b=cjxIFU0/mgCUkSsbtM+2C91w97Y3QulQ0DZFED1uAc5ELxpGzaq11oTiAzi4AGzT7F y3fMOW82lrosL6iFofT1Jv+mOPYLJMKh/noprig9UqwkQXfANnA6ySycYVwlcOMM7yMW ooUGupXw6Cz+BPdAYrZjbTx/jirGQ/HSVzWl0kpwDDRyLsvNsxK2kDu/Whx35MEIu2U+ D1/qzohNcdWi2n73VbVPGIc5UYu6mOhYb1llI8gaywb0nVBmvSwR+VJC+WKUlSlNAXnG tTnvLfvVg8S8FU++rnsar9arORVqYcVQTUUBWe/fRLsHeeIM4SNe2abu96QggrEXSPZa Sg5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RltJJu9iW4bH0ZoYktiSC+evINgHsT8Vxx09myqRIbU=; b=nd/roNr2TiJ2x9hs2RMlQmwsy3aoPT0Fz38KB38woReotnz7lnZymjt62uS7HltA3e K5tArsGnscoBp2pu0HnPD3lOpGHXLfbiax5LGYdIt4Q4TlAntNVPMi2DlbKyDNlb9VMm brXMX67f0IpPFhP6aqCjCsQ041RTH4y0qHHN4TBetPhs//aGAuucGvgLr3EfD4GaZSM0 RwPYKZ6I+N7xHuY19/J5RBMhdAhZVeeyf2Df4CbPj0YPfAknr6YPeFiAqnzCSTZrGaMG YnvbccDpnrxBNImaGqXM807gHH6Jqoa+XX7Fdt5utv2AWLti9A7hnj1qo/VRWBkXeAcf npkw== X-Gm-Message-State: APzg51Aas/CvfYwoKkEddofR5cp4ww7R/WKOrgB2uDJi9FC6JKRdb4UJ oAH2IT3PLNECJHAUxMNwt+Y= X-Google-Smtp-Source: ANB0VdbWRCA7zaGg05L2Z5A9i5eYSXhgEy39bsro1n6I33TlrvUZqyr4rLr/ncs92UfMDbgadhB1EA== X-Received: by 2002:a63:5815:: with SMTP id m21-v6mr23362338pgb.78.1535923739925; Sun, 02 Sep 2018 14:28:59 -0700 (PDT) Received: from [192.168.50.145] (c-73-158-246-48.hsd1.ca.comcast.net. [73.158.246.48]) by smtp.gmail.com with ESMTPSA id h12-v6sm22643730pfo.135.2018.09.02.14.28.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 14:28:59 -0700 (PDT) To: Benjamin Kaduk Cc: bruno.decraene@orange.com, "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" , Rob Shakir , "aretana.ietf@gmail.com" , "spring-chairs@ietf.org" , "spring@ietf.org" , The IESG References: <152951284387.28600.11874107921186798735.idtracker@ietfa.amsl.com> <22642_1531139781_5B4356C5_22642_217_1_53C29892C857584299CBF5D05346208A47AE54BA@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180709225252.GD59001@kduck.kaduk.org> <31682_1531226969_5B44AB59_31682_103_1_53C29892C857584299CBF5D05346208A47AE73C4@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180710141101.GP59001@kduck.kaduk.org> <20180726202715.GA91950@kduck.kaduk.org> From: Ahmed Bashandy Message-ID: Date: Sun, 2 Sep 2018 14:28:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180726202715.GA91950@kduck.kaduk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 21:29:06 -0000 It seems like it was some editing error I uploaded version 15 and oput back the parapgraph Ahmed On 7/26/18 1:27 PM, Benjamin Kaduk wrote: > Hi Ahmed, > > Thanks for posting the update (and sorry for only getting to it now). > > The two specific points I raised in my DISCUSS ballot are properly > addressed, but before I go clear that I was hoping you could help me > remember why the following text was removed when going from -13 to -14: > > [...] Because this document recognizes that > miscofiguration and/or programming may result in false or conflicting > label binding advertisements, thereby compromising traffic > forwarding, the document recommends strict configuration/ > programmability control as well as montoring the SID advertised and > log/error messages by the operator to avoid or at least significantly > minimize the possibility of such risk. > > I couldn't find anything in my email history that helped jog my memory. > > Thanks, > > Benjamin > > On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote: >> Hi, >> >> I just posted version 14 >> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt >> >> Thanks >> >> Ahmed >> >> >> >> On 7/10/18 7:11 AM, Benjamin Kaduk wrote: >>> Hi Bruno, >>> >>> Thanks for the additional clarifications in the suggested text -- it looks >>> good to me, so you and Ahmed should please go ahead with it (once >>> submissions open up again). >>> >>> -Benjamin >>> >>> On Tue, Jul 10, 2018 at 12:49:28PM +0000, bruno.decraene@orange.com wrote: >>>> Hi Benjamin, >>>> >>>> Thanks for the discussion. >>>> Please see inline [Bruno2] >>>> >>>>> From: Benjamin Kaduk [mailto:kaduk@mit.edu] >>>> > Sent: Tuesday, July 10, 2018 12:53 AM >>>> > On Mon, Jul 09, 2018 at 12:36:20PM +0000, bruno.decraene@orange.com wrote: >>>> > > Hi Benjamin, >>>> > > >>>> > > Thanks for your comments. >>>> > > Please see inline another addition to Ahmed's answer. [Bruno] >>>> > > >>>> > > > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] >>>> > > > Sent: Monday, July 09, 2018 2:30 AM >>>> > > > >>>> > > > Hi >>>> > > > Thanks for the review >>>> > > > >>>> > > > See reply to the comment at #Ahmed >>>> > > > >>>> > > > Ahmed >>>> > > > >>>> > > > >>>> > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote: >>>> > > > > Benjamin Kaduk has entered the following ballot position for >>>> > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss >>>> > > > > >>>> > > > > When responding, please keep the subject line intact and reply to all >>>> > > > > email addresses included in the To and CC lines. (Feel free to cut this >>>> > > > > introductory paragraph, however.) >>>> > > > > >>>> > > > > >>>> > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> > > > > for more information about IESG DISCUSS and COMMENT positions. >>>> > > > > >>>> > > > > >>>> > > > > The document, along with other ballot positions, can be found here: >>>> > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > DISCUSS: >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > >>>> > > > > I may be missing something, but I don't see anything that says whether the >>>> > > > > preference field introduced in Section 3.2.3 uses larger values or smaller >>>> > > > > values for more-preferred SRMSes. >>>> > > > #Ahmed: >>>> > > > If I understand this statement correctly, the concern is about which >>>> > > > label(s) get assigned to which prefix(es). This concern is addressed as >>>> > > > follows >>>> > > > >>>> > > > From the MPLS architecture point of view, there is nothing wrong in >>>> > > > having multiple labels for the same prefix. Segment routing in general >>>> > > > and this document in particular did not introduce this behavior nor did >>>> > > > they prohibit/restrict/relax it. For example, an implementation that >>>> > > > allows the operator to locally assign multiple local labels to the same >>>> > > > prefix may continue to apply this behavior whether the platform supports >>>> > > > segment routing or not, in which case it is up to the implementation >>>> > > > and/or the configuration affecting the MPLS forwarding plane to specify >>>> > > > how to behave when multiple labels are assigned to the same prefix. Such >>>> > > > behavior is a general MPLS behavior that outside the scope of and is not >>>> > > > modified by segment routing. >>>> > > > >>>> > > > However the opposite, where the same label gets assigned to multiple >>>> > > > prefixes resulting in label collision is problematic. This document >>>> > > > prohibits label collision resulting from the use of SRMS (which is >>>> > > > introduced by this document) in the first bullet starting at the 3rd >>>> > > > line of page 12: >>>> > > >   "-  If there is an incoming label collision as specified in >>>> > > >       [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified >>>> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve the >>>> > > >       collision."" >>>> > > > >>>> > > > > >>>> > > > > >>>> > > > > The introduction of the SRMS is also introducing a new way for a protocol >>>> > > > > participant to make claims about route prefixes directed at "third parties" >>>> > > > > (non-MS, non-MC routers). While routing protocols in general do require high >>>> > > > > levels of trust in all participants in order for proper routing to occur, this >>>> > > > > addition seems to create a "first among equals" situation that could be called >>>> > > > > out more clearly in the security considerations. (I do appreciate that the >>>> > > > > requirement for preferring SIDs advertised in prefix reachability >>>> > > > > advertisements over those advertised in mapping server advertisements does help >>>> > > > > alleviate some of the risk.) >>>> > > >>>> > > [Bruno] >>>> > > 1) As the SID attached to the prefix reachability is more preferred than the SID advertised by the >>>> > SRMS, I would kind of argue that the SRMS is more "last among equals" :-) >>>> > > 2) I agree that routing protocols, especially Link State Internal Routing Protocols, do require high >>>> > levels of trusts among participants. In particular, please note that any node can already advertise >>>> > any IP prefix (with any attached SID), and with any metric/cost, hence attracting the traffic. In this >>>> > regards, I don't really see an increased risk in IGP routing. >>>> > >>>> > I don't really see an increased risk per se, either (since all routers can >>>> > break routing in all sorts of ways), but I do see a new mechanism by which >>>> > certain routers can cause routing breakage. So I was thinking "first among >>>> > equals" in terms of "more ways to break things", not "can break things with >>>> > a larger magnitude of breakage". You are right that the preference order >>>> > that Ahmed described does mean that this new "mechanism for breakage" is >>>> > only applicable when there are no explicit prefix-SID advertisements >>>> > received via the IGP. So in that sense this new mechanism for breakage is >>>> > "last among equals", as you say, because it can only take effect if the IGP >>>> > leaves room for it. >>>> >>>> [Bruno2] Ack; I believe we are in sync. >>>> >>>> > > 3) I agree that SRMS allows for a "centralized" SID advertisement. I personally don't feel that this >>>> > is more risky than a "centralized" BGP Route Reflector. However, I'm not against raising this in the >>>> > security consideration section. >>>> > > Please see below a proposed text. Please comment/propose text as required. >>>> > > >>>> > > OLD: >>>> > > This document introduces another form of label binding >>>> > > advertisements. The security associated with these advertisement is >>>> > > part of the security applied to routing protocols such as IS-IS >>>> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of >>>> > > cryptographic authentication mechanisms. This document also >>>> > > specifies a mechanism by which the ill effects of advertising >>>> > > conflicting label bindings can be mitigated. >>>> > > >>>> > > NEW: >>>> > > This document introduces another form of label binding >>>> > > advertisements. The security associated with these advertisements is >>>> > > part of the security applied to routing protocols such as IS-IS >>>> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of >>>> > > cryptographic authentication mechanisms. >>>> > > This form of advertisement is more centralized, on behalf of the node advertising the IP >>>> > reachability. >>>> > > This document also >>>> > > specifies a mechanism by which the ill effects of advertising >>>> > > conflicting label bindings can be mitigated. In particular, advertisements from the node >>>> > advertsising the IP reachability is more preference than the centralized one. >>>> > >>>> > I think that's enough to resolve my DISCUSS point. I would prefer if there >>>> > was a little bit more text, such as "more centralized, on behalf of the >>>> > node advertising the IP reachability, which presents a different risk >>>> > profile than existing mechanisms for distributing label bindings", but your >>>> > version does cover the key point. >>>> >>>> [Bruno2] ok. Proposed NEW2: >>>> >>>> This document introduces another form of label binding >>>> advertisements. The security associated with these advertisements is >>>> part of the security applied to routing protocols such as IS-IS >>>> [RFC5304] and OSPF [RFC5709] which both optionally make use of >>>> cryptographic authentication mechanisms. >>>> This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile. >>>> This document also >>>> specifies a mechanism by which the ill effects of advertising >>>> conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one. >>>> >>>> >>>> >>>> In short, I used your proposed text but removed " than existing mechanisms for distributing label bindings" as this could be read as "LDP". We could add more text to distinguish, but IMO the current text seems fine. >>>> >>>> >>>> > (And to be clear, I am not trying to say >>>> > that the centralized risk is better or worse in all cases; it's just >>>> > different, so we should call that out to the reader and inform their decision >>>> > making.) >>>> >>>> [Bruno2] In sync. I agree with you that we should call that out to the reader and inform their decision making. Thanks for bringing the comment. >>>> I'll work with Ahmed, to have the draft reflect this, as he has the pen. >>>> >>>> Thanks, >>>> Bruno >>>> >>>> >>>> > Thanks, >>>> > >>>> > Benjamin >>>> > >>>> > > >>>> > > Thanks, >>>> > > --Bruno >>>> > > >>>> > > > #Ahmed: >>>> > > > If I understand your comment, the concern is about >>>> > > > "first-come-first-serve" behavior. I believe this concern is addressed >>>> > > > as follows >>>> > > > (1) The sentence starting at the fourth line of the second paragraph in >>>> > > > page 10 says: >>>> > > >    For a given prefix, if an MC receives an SR mapping advertisement >>>> > > >    from a mapping server and also has received a prefix-SID >>>> > > >    advertisement for that same prefix in a prefix reachability >>>> > > >    advertisement, then the MC MUST prefer the SID advertised in the >>>> > > >    prefix reachability advertisement over the mapping server >>>> > > >    advertisement i.e., the mapping server advertisment MUST be ignored >>>> > > >    for that prefix. >>>> > > > >>>> > > > (2) The last bullet at the bottom of page 11 says: >>>> > > >    -  For any prefix for which it did not receive a prefix-SID >>>> > > >       advertisement, the MCC applies the SRMS mapping advertisments with >>>> > > >       the highest preference. >>>> > > > >>>> > > > (3) The first bullet near the top pf page 12 says: >>>> > > >    -  If there is an incoming label collision as specified in >>>> > > >       [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified >>>> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve the >>>> > > >       collision. >>>> > > > >>>> > > > So for the same set of received advertisements (SRMS advertisements, >>>> > > > prefix-SID advertisements, or combination of both), the same set of >>>> > > > labels will be assigned to the same prefix. As mentioned in my previous >>>> > > > comments, if multiple labels get assigned to the same prefix, the >>>> > > > behavior is not related to segment routing >>>> > > > >>>> > > > Regarding placing a comment in the security section, IMO a specification >>>> > > > of which advertisement(s) to use when receiving multiple (conflicting or >>>> > > > non-conflicting) advertisements has nothing to do with security. It is >>>> > > > an externally visible protocol(s) behavior that should be specified in >>>> > > > the sections covering the protocol(s) themselves rather than security >>>> > > > consideration of the protocol(s). >>>> > > > >>>> > > > But if you still think there is a need to mention something in the >>>> > > > security section, a suggestion from your side will be greatly appreciated . >>>> > > > > >>>> > > > > >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > COMMENT: >>>> > > > > ---------------------------------------------------------------------- >>>> > > > > >>>> > > > > I support Alissa's suggestion about the text covering cryptographic authentication. >>>> > > > #Ahmed: I modified the statement as Alissa suggested in version 14 that >>>> > > > will be published in the next 1-2 days >>>> > > > > >>>> > > > > "[100,300]" and "(100,200)" are each used as an example SRGB. In >>>> > > > > some contexts the round versus square brackets indicate a >>>> > > > > distinction between "closed" (includes endpoints) and "open" (does >>>> > > > > not include endpoints) intervals. If there's no need to make such a >>>> > > > > distinction, I suggest standardizing one one format. >>>> > > > #Ahmed: I changed both of them to use [] in version because we mean >>>> > > > inclusive >>>> > > > > >>>> > > > > As was mentioned in the secdir review, it would be good to expand FEC and LFA on first >>>> > usage. >>>> > > > #Ahmed: Corrected in version 14 that will be published in the next 1-2 days >>>> > > > > >>>> > > > > Section 1 >>>> > > > > >>>> > > > > Section 2 describes the co-existence of SR with other MPLS Control >>>> > > > > Plane. [...] >>>> > > > > >>>> > > > > nit: "other MPLS Control Plane" seems to be an incomplete compound noun >>>> > > > > -- is it other control plane technologies that are being considered? >>>> > > > #Ahmed: I added "protocols" in version 14 to clarify that >>>> > > > > >>>> > > > > Section 2 >>>> > > > > >>>> > > > > Note that this static label allocation capability of the label >>>> > > > > manager exists for many years across several vendors and hence is not >>>> > > > > new. Furthermore, note that the label-manager ability to statically >>>> > > > > allocate a range of labels to a specific application is not new >>>> > > > > either. [...] >>>> > > > > >>>> > > > > nits: "has existed", "label-manager's ability". >>>> > > > #Ahmed: Corrected (thanks a lot) >>>> > > > > >>>> > > > > Section 2.1 >>>> > > > > >>>> > > > > MPLS2MPLS refers the forwarding behavior where a router receives an >>>> > > > > labeled packet and switches it out as a labeled packet. Several >>>> > > > > >>>> > > > > nit: "refers to", "a labeled packet" >>>> > > > #Ahmed: Corrected >>>> > > > > >>>> > > > > Section 3.2 >>>> > > > > >>>> > > > > This section defines the Segment Routing Mapping Server (SRMS). The >>>> > > > > SRMS is a IGP node advertising mapping between Segment Identifiers >>>> > > > > (SID) and prefixes advertised by other IGP nodes. The SRMS uses a >>>> > > > > dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol >>>> > > > > specific and defined in [I-D.ietf-isis-segment-routing-extensions], >>>> > > > > [I-D.ietf-ospf-segment-routing-extensions], and >>>> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. >>>> > > > > >>>> > > > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a >>>> > > > > better parenthetical? >>>> > > > #Ahmed: Corrected in the next version >>>> > > > > >>>> > > > > The example diagram depicted in Figure 3 assumes that the operator >>>> > > > > configures P5 to act as a Segment Routing Mapping Server (SRMS) and >>>> > > > > advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103) >>>> > > > > and (PE4, 104). >>>> > > > > >>>> > > > > nit: I think this is Figure 2. >>>> > > > #Ahmed: Corrected in the next version >>>> > > > > >>>> > > > > Section 3.2.1 >>>> > > > > >>>> > > > > [...] Examples >>>> > > > > of explicit prefix-SID advertisment are the prefix-SID sub-TLVs >>>> > > > > defined in ([I-D.ietf-isis-segment-routing-extensions], >>>> > > > > [I-D.ietf-ospf-segment-routing-extensions], and >>>> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). >>>> > > > > >>>> > > > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat) >>>> > > > > be appropriate for inclusion in this list? >>>> > > > > >>>> > > > > for that prefix. Hence assigning a prefix-SID to a prefix using the >>>> > > > > SRMS functionality does not preclude assigning the same or different >>>> > > > > prefix-SID(s) to the same prefix using explict prefix-SID >>>> > > > > advertisement such as the aforementioned prefix-SID sub-TLV. >>>> > > > #Ahmed: The SRMS functionality is specific to IGPs as mentioned in the >>>> > > > second sentence of the second paragraph in Section 3.2 >>>> > > > > >>>> > > > > nit: I think the aforementioned things were a list, so "sub-TLVs" plural >>>> > > > > would be appropriate. >>>> > > > > >>>> > > > > Including the name for IS-IS TLV 135 might be helpful for the >>>> > > > > reader. >>>> > > > > >>>> > > > #Ahmed: Corrected as suggested in the next version >>>> > > >>>> > > >>>> > > >>>> > ________________________________________________________________________________ >>>> > _________________________________________ >>>> > > >>>> > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou >>>> > privilegiees et ne doivent donc >>>> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par >>>> > erreur, veuillez le signaler >>>> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant >>>> > susceptibles d'alteration, >>>> > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> > > >>>> > > This message and its attachments may contain confidential or privileged information that may be >>>> > protected by law; >>>> > > they should not be distributed, used or copied without authorisation. >>>> > > If you have received this email in error, please notify the sender and delete this message and its >>>> > attachments. >>>> > > As emails may be altered, Orange is not liable for messages that have been modified, changed >>>> > or falsified. >>>> > > Thank you. >>>> > > >>>> >>>> _________________________________________________________________________________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> From nobody Sun Sep 2 14:29:57 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E647130DE6; Sun, 2 Sep 2018 14:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fqn6i2pLVxrr; Sun, 2 Sep 2018 14:29:44 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 01FFC130DD8; Sun, 2 Sep 2018 14:29:44 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id r1-v6so7664680pgp.11; Sun, 02 Sep 2018 14:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=7W1YnSlCSI5RaycpbDCf+gcG/OeZEuQWWQHjsYZvxNk=; b=UBIODtyWZLO0P3QzRcP6lalyS0w12alTkSQTsUBbzLHA4d+VxdhWamJHT2BJ/Ur6OM ZwL5JDS3DCfj9RvFq+aC5a8TJgca0NIl68RDGHwH1PuwDLmR66ySnk0STwQUfRyvW3fU 4SYbrzEOsBPlgKcrSdtpJNBEF8XbtdNeTOz6NwCA0+phevEZ9+CaiD7pm8hMBNjE8r46 4JBrDouBdJD2f7Isc1GRWUngg09xtGHxJStQDvwI8awhC3dFd5NWIv3wKJCkOxC9AUJC uEusrf+fRJOE7jHGgonxrsxpalabtzjTDnAk2Av5MlOU2pdpzZg29PwfguHUmh5F9mIW b/Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7W1YnSlCSI5RaycpbDCf+gcG/OeZEuQWWQHjsYZvxNk=; b=ubWXZJnyO3UPUi1jGzXIqiHKYynGxUgwVq0ul/CdcKRlkVQN3BUSNiONcnh4FDv9ey y0L2R+7zFlBg9/LT7gcR4DbM3kPSuzyeGvzE5OJwk2MFbmBkPtFTkUrlGm5UTIIOpLRV PzzE0szpsCNiaxCAozgz9jhCMHGaedMPoi9WGFAu1G782Jn6t9vhp6sxYwSNxra7dH5L noxzDQLrFSb/hz5RgorfAhxeEKtWnw8Qfl5xMCqSzfb1EDBWHhHWR9lBo4AnePFFoGyH hNj3XptMZpiSvLzaZpYf6tA5VGpH7+Mqs74tpbEf1bdyyW/8N4QeOnaLjoMq32NtyO14 AWAQ== X-Gm-Message-State: APzg51CSvsIhIBP1jXr14DBsjTHNRLz1O7up5Zi72zGec0c17EWDXKbL MojEbOLWzKaYmcIssupbE7Q= X-Google-Smtp-Source: ANB0VdYfDg0KeQM6ZJ5+WA87N02t5Ry4GGQaLRwYKo4yTzlYBxPiRUjHkF7LOXQbSOa055qhBbD+hg== X-Received: by 2002:a63:881:: with SMTP id 123-v6mr23260056pgi.244.1535923783432; Sun, 02 Sep 2018 14:29:43 -0700 (PDT) Received: from [192.168.50.145] (c-73-158-246-48.hsd1.ca.comcast.net. [73.158.246.48]) by smtp.gmail.com with ESMTPSA id d22-v6sm55822877pfm.48.2018.09.02.14.29.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 14:29:42 -0700 (PDT) To: Alvaro Retana , Benjamin Kaduk Cc: "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" , Rob Shakir , bruno.decraene@orange.com, "spring-chairs@ietf.org" , "spring@ietf.org" , The IESG References: <152951284387.28600.11874107921186798735.idtracker@ietfa.amsl.com> <22642_1531139781_5B4356C5_22642_217_1_53C29892C857584299CBF5D05346208A47AE54BA@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180709225252.GD59001@kduck.kaduk.org> <31682_1531226969_5B44AB59_31682_103_1_53C29892C857584299CBF5D05346208A47AE73C4@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180710141101.GP59001@kduck.kaduk.org> <20180726202715.GA91950@kduck.kaduk.org> From: Ahmed Bashandy Message-ID: <54308844-f714-c0cb-083a-3b7d233fb8fd@gmail.com> Date: Sun, 2 Sep 2018 14:29:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7F83E99B586046503EF17931" Content-Language: en-US Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 21:29:49 -0000 This is a multi-part message in MIME format. --------------7F83E99B586046503EF17931 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks a for the reminder I uploaded version 15 to address Benjamin's comments Ahmed On 8/29/18 9:09 AM, Alvaro Retana wrote: > Ahmed: Ping!! > > We’re really close… > > Alvaro. > > On July 26, 2018 at 4:27:25 PM, Benjamin Kaduk (kaduk@mit.edu > ) wrote: > >> Hi Ahmed, >> >> Thanks for posting the update (and sorry for only getting to it now). >> >> The two specific points I raised in my DISCUSS ballot are properly >> addressed, but before I go clear that I was hoping you could help me >> remember why the following text was removed when going from -13 to -14: >> >> [...] Because this document recognizes that >> miscofiguration and/or programming may result in false or conflicting >> label binding advertisements, thereby compromising traffic >> forwarding, the document recommends strict configuration/ >> programmability control as well as montoring the SID advertised and >> log/error messages by the operator to avoid or at least significantly >> minimize the possibility of such risk. >> >> I couldn't find anything in my email history that helped jog my memory. >> >> Thanks, >> >> Benjamin >> >> On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote: >> > Hi, >> > >> > I just posted version 14 >> > >> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt >> >> > >> > Thanks >> > >> > Ahmed >> > >> > >> > >> > On 7/10/18 7:11 AM, Benjamin Kaduk wrote: >> > > Hi Bruno, >> > > >> > > Thanks for the additional clarifications in the suggested text -- >> it looks >> > > good to me, so you and Ahmed should please go ahead with it (once >> > > submissions open up again). >> > > >> > > -Benjamin >> > > >> > > On Tue, Jul 10, 2018 at 12:49:28PM +0000, >> bruno.decraene@orange.com wrote: >> > >> Hi Benjamin, >> > >> >> > >> Thanks for the discussion. >> > >> Please see inline [Bruno2] >> > >> >> > >>> From: Benjamin Kaduk [mailto:kaduk@mit.edu ] >> > >> > Sent: Tuesday, July 10, 2018 12:53 AM >> > >> > On Mon, Jul 09, 2018 at 12:36:20PM +0000, >> bruno.decraene@orange.com wrote: >> > >> > > Hi Benjamin, >> > >> > > >> > >> > > Thanks for your comments. >> > >> > > Please see inline another addition to Ahmed's answer. [Bruno] >> > >> > > >> > >> > > > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com >> ] >> > >> > > > Sent: Monday, July 09, 2018 2:30 AM >> > >> > > > >> > >> > > > Hi >> > >> > > > Thanks for the review >> > >> > > > >> > >> > > > See reply to the comment at #Ahmed >> > >> > > > >> > >> > > > Ahmed >> > >> > > > >> > >> > > > >> > >> > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote: >> > >> > > > > Benjamin Kaduk has entered the following ballot position >> for >> > >> > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss >> > >> > > > > >> > >> > > > > When responding, please keep the subject line intact and >> reply to all >> > >> > > > > email addresses included in the To and CC lines. (Feel >> free to cut this >> > >> > > > > introductory paragraph, however.) >> > >> > > > > >> > >> > > > > >> > >> > > > > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > >> > > > > for more information about IESG DISCUSS and COMMENT >> positions. >> > >> > > > > >> > >> > > > > >> > >> > > > > The document, along with other ballot positions, can be >> found here: >> > >> > > > > >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ >> >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> ---------------------------------------------------------------------- >> > >> > > > > DISCUSS: >> > >> > > > > >> ---------------------------------------------------------------------- >> > >> > > > > >> > >> > > > > I may be missing something, but I don't see anything >> that says whether the >> > >> > > > > preference field introduced in Section 3.2.3 uses larger >> values or smaller >> > >> > > > > values for more-preferred SRMSes. >> > >> > > > #Ahmed: >> > >> > > > If I understand this statement correctly, the concern is >> about which >> > >> > > > label(s) get assigned to which prefix(es). This concern is >> addressed as >> > >> > > > follows >> > >> > > > >> > >> > > > From the MPLS architecture point of view, there is nothing >> wrong in >> > >> > > > having multiple labels for the same prefix. Segment >> routing in general >> > >> > > > and this document in particular did not introduce this >> behavior nor did >> > >> > > > they prohibit/restrict/relax it. For example, an >> implementation that >> > >> > > > allows the operator to locally assign multiple local >> labels to the same >> > >> > > > prefix may continue to apply this behavior whether the >> platform supports >> > >> > > > segment routing or not, in which case it is up to the >> implementation >> > >> > > > and/or the configuration affecting the MPLS forwarding >> plane to specify >> > >> > > > how to behave when multiple labels are assigned to the >> same prefix. Such >> > >> > > > behavior is a general MPLS behavior that outside the scope >> of and is not >> > >> > > > modified by segment routing. >> > >> > > > >> > >> > > > However the opposite, where the same label gets assigned >> to multiple >> > >> > > > prefixes resulting in label collision is problematic. This >> document >> > >> > > > prohibits label collision resulting from the use of SRMS >> (which is >> > >> > > > introduced by this document) in the first bullet starting >> at the 3rd >> > >> > > > line of page 12: >> > >> > > >   "-  If there is an incoming label collision as specified in >> > >> > > > [I-D.ietf-spring-segment-routing-mpls] , apply the steps >> specified >> > >> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve >> the >> > >> > > >       collision."" >> > >> > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > The introduction of the SRMS is also introducing a new >> way for a protocol >> > >> > > > > participant to make claims about route prefixes directed >> at "third parties" >> > >> > > > > (non-MS, non-MC routers). While routing protocols in >> general do require high >> > >> > > > > levels of trust in all participants in order for proper >> routing to occur, this >> > >> > > > > addition seems to create a "first among equals" >> situation that could be called >> > >> > > > > out more clearly in the security considerations. (I do >> appreciate that the >> > >> > > > > requirement for preferring SIDs advertised in prefix >> reachability >> > >> > > > > advertisements over those advertised in mapping server >> advertisements does help >> > >> > > > > alleviate some of the risk.) >> > >> > > >> > >> > > [Bruno] >> > >> > > 1) As the SID attached to the prefix reachability is more >> preferred than the SID advertised by the >> > >> > SRMS, I would kind of argue that the SRMS is more "last among >> equals" :-) >> > >> > > 2) I agree that routing protocols, especially Link State >> Internal Routing Protocols, do require high >> > >> > levels of trusts among participants. In particular, please >> note that any node can already advertise >> > >> > any IP prefix (with any attached SID), and with any >> metric/cost, hence attracting the traffic. In this >> > >> > regards, I don't really see an increased risk in IGP routing. >> > >> > >> > >> > I don't really see an increased risk per se, either (since all >> routers can >> > >> > break routing in all sorts of ways), but I do see a new >> mechanism by which >> > >> > certain routers can cause routing breakage. So I was thinking >> "first among >> > >> > equals" in terms of "more ways to break things", not "can >> break things with >> > >> > a larger magnitude of breakage". You are right that the >> preference order >> > >> > that Ahmed described does mean that this new "mechanism for >> breakage" is >> > >> > only applicable when there are no explicit prefix-SID >> advertisements >> > >> > received via the IGP. So in that sense this new mechanism for >> breakage is >> > >> > "last among equals", as you say, because it can only take >> effect if the IGP >> > >> > leaves room for it. >> > >> >> > >> [Bruno2] Ack; I believe we are in sync. >> > >> >> > >> > > 3) I agree that SRMS allows for a "centralized" SID >> advertisement. I personally don't feel that this >> > >> > is more risky than a "centralized" BGP Route Reflector. >> However, I'm not against raising this in the >> > >> > security consideration section. >> > >> > > Please see below a proposed text. Please comment/propose >> text as required. >> > >> > > >> > >> > > OLD: >> > >> > > This document introduces another form of label binding >> > >> > > advertisements. The security associated with these >> advertisement is >> > >> > > part of the security applied to routing protocols such as IS-IS >> > >> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of >> > >> > > cryptographic authentication mechanisms. This document also >> > >> > > specifies a mechanism by which the ill effects of advertising >> > >> > > conflicting label bindings can be mitigated. >> > >> > > >> > >> > > NEW: >> > >> > > This document introduces another form of label binding >> > >> > > advertisements. The security associated with these >> advertisements is >> > >> > > part of the security applied to routing protocols such as IS-IS >> > >> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of >> > >> > > cryptographic authentication mechanisms. >> > >> > > This form of advertisement is more centralized, on behalf of >> the node advertising the IP >> > >> > reachability. >> > >> > > This document also >> > >> > > specifies a mechanism by which the ill effects of advertising >> > >> > > conflicting label bindings can be mitigated. In particular, >> advertisements from the node >> > >> > advertsising the IP reachability is more preference than the >> centralized one. >> > >> > >> > >> > I think that's enough to resolve my DISCUSS point. I would >> prefer if there >> > >> > was a little bit more text, such as "more centralized, on >> behalf of the >> > >> > node advertising the IP reachability, which presents a >> different risk >> > >> > profile than existing mechanisms for distributing label >> bindings", but your >> > >> > version does cover the key point. >> > >> >> > >> [Bruno2] ok. Proposed NEW2: >> > >> >> > >> This document introduces another form of label binding >> > >> advertisements. The security associated with these >> advertisements is >> > >> part of the security applied to routing protocols such as IS-IS >> > >> [RFC5304] and OSPF [RFC5709] which both optionally make use of >> > >> cryptographic authentication mechanisms. >> > >> This form of advertisement is more centralized, on behalf of the >> node advertising the IP reachability, which presents a different risk >> profile. >> > >> This document also >> > >> specifies a mechanism by which the ill effects of advertising >> > >> conflicting label bindings can be mitigated. In particular, >> advertisements from the node advertising the IP reachability is more >> preferred than the centralized one. >> > >> >> > >> >> > >> >> > >> In short, I used your proposed text but removed " than existing >> mechanisms for distributing label bindings" as this could be read as >> "LDP". We could add more text to distinguish, but IMO the current >> text seems fine. >> > >> >> > >> >> > >> > (And to be clear, I am not trying to say >> > >> > that the centralized risk is better or worse in all cases; >> it's just >> > >> > different, so we should call that out to the reader and inform >> their decision >> > >> > making.) >> > >> >> > >> [Bruno2] In sync. I agree with you that we should call that out >> to the reader and inform their decision making. Thanks for bringing >> the comment. >> > >> I'll work with Ahmed, to have the draft reflect this, as he has >> the pen. >> > >> >> > >> Thanks, >> > >> Bruno >> > >> >> > >> >> > >> > Thanks, >> > >> > >> > >> > Benjamin >> > >> > >> > >> > > >> > >> > > Thanks, >> > >> > > --Bruno >> > >> > > >> > >> > > > #Ahmed: >> > >> > > > If I understand your comment, the concern is about >> > >> > > > "first-come-first-serve" behavior. I believe this concern >> is addressed >> > >> > > > as follows >> > >> > > > (1) The sentence starting at the fourth line of the second >> paragraph in >> > >> > > > page 10 says: >> > >> > > >    For a given prefix, if an MC receives an SR mapping >> advertisement >> > >> > > >    from a mapping server and also has received a prefix-SID >> > >> > > >    advertisement for that same prefix in a prefix >> reachability >> > >> > > >    advertisement, then the MC MUST prefer the SID >> advertised in the >> > >> > > >    prefix reachability advertisement over the mapping server >> > >> > > >    advertisement i.e., the mapping server advertisment >> MUST be ignored >> > >> > > >    for that prefix. >> > >> > > > >> > >> > > > (2) The last bullet at the bottom of page 11 says: >> > >> > > >    -  For any prefix for which it did not receive a >> prefix-SID >> > >> > > >       advertisement, the MCC applies the SRMS mapping >> advertisments with >> > >> > > >       the highest preference. >> > >> > > > >> > >> > > > (3) The first bullet near the top pf page 12 says: >> > >> > > >    -  If there is an incoming label collision as specified in >> > >> > > > [I-D.ietf-spring-segment-routing-mpls] , apply the steps >> specified >> > >> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve >> the >> > >> > > >       collision. >> > >> > > > >> > >> > > > So for the same set of received advertisements (SRMS >> advertisements, >> > >> > > > prefix-SID advertisements, or combination of both), the >> same set of >> > >> > > > labels will be assigned to the same prefix. As mentioned >> in my previous >> > >> > > > comments, if multiple labels get assigned to the same >> prefix, the >> > >> > > > behavior is not related to segment routing >> > >> > > > >> > >> > > > Regarding placing a comment in the security section, IMO a >> specification >> > >> > > > of which advertisement(s) to use when receiving multiple >> (conflicting or >> > >> > > > non-conflicting) advertisements has nothing to do with >> security. It is >> > >> > > > an externally visible protocol(s) behavior that should be >> specified in >> > >> > > > the sections covering the protocol(s) themselves rather >> than security >> > >> > > > consideration of the protocol(s). >> > >> > > > >> > >> > > > But if you still think there is a need to mention >> something in the >> > >> > > > security section, a suggestion from your side will be >> greatly appreciated . >> > >> > > > > >> > >> > > > > >> > >> > > > > >> ---------------------------------------------------------------------- >> > >> > > > > COMMENT: >> > >> > > > > >> ---------------------------------------------------------------------- >> > >> > > > > >> > >> > > > > I support Alissa's suggestion about the text covering >> cryptographic authentication. >> > >> > > > #Ahmed: I modified the statement as Alissa suggested in >> version 14 that >> > >> > > > will be published in the next 1-2 days >> > >> > > > > >> > >> > > > > "[100,300]" and "(100,200)" are each used as an example >> SRGB. In >> > >> > > > > some contexts the round versus square brackets indicate a >> > >> > > > > distinction between "closed" (includes endpoints) and >> "open" (does >> > >> > > > > not include endpoints) intervals. If there's no need to >> make such a >> > >> > > > > distinction, I suggest standardizing one one format. >> > >> > > > #Ahmed: I changed both of them to use [] in version >> because we mean >> > >> > > > inclusive >> > >> > > > > >> > >> > > > > As was mentioned in the secdir review, it would be good >> to expand FEC and LFA on first >> > >> > usage. >> > >> > > > #Ahmed: Corrected in version 14 that will be published in >> the next 1-2 days >> > >> > > > > >> > >> > > > > Section 1 >> > >> > > > > >> > >> > > > > Section 2 describes the co-existence of SR with other >> MPLS Control >> > >> > > > > Plane. [...] >> > >> > > > > >> > >> > > > > nit: "other MPLS Control Plane" seems to be an >> incomplete compound noun >> > >> > > > > -- is it other control plane technologies that are being >> considered? >> > >> > > > #Ahmed: I added "protocols" in version 14 to clarify that >> > >> > > > > >> > >> > > > > Section 2 >> > >> > > > > >> > >> > > > > Note that this static label allocation capability of the >> label >> > >> > > > > manager exists for many years across several vendors and >> hence is not >> > >> > > > > new. Furthermore, note that the label-manager ability to >> statically >> > >> > > > > allocate a range of labels to a specific application is >> not new >> > >> > > > > either. [...] >> > >> > > > > >> > >> > > > > nits: "has existed", "label-manager's ability". >> > >> > > > #Ahmed: Corrected (thanks a lot) >> > >> > > > > >> > >> > > > > Section 2.1 >> > >> > > > > >> > >> > > > > MPLS2MPLS refers the forwarding behavior where a router >> receives an >> > >> > > > > labeled packet and switches it out as a labeled packet. >> Several >> > >> > > > > >> > >> > > > > nit: "refers to", "a labeled packet" >> > >> > > > #Ahmed: Corrected >> > >> > > > > >> > >> > > > > Section 3.2 >> > >> > > > > >> > >> > > > > This section defines the Segment Routing Mapping Server >> (SRMS). The >> > >> > > > > SRMS is a IGP node advertising mapping between Segment >> Identifiers >> > >> > > > > (SID) and prefixes advertised by other IGP nodes. The >> SRMS uses a >> > >> > > > > dedicated IGP extension (IS-IS, OSPF and OSPFv3) which >> is protocol >> > >> > > > > specific and defined in >> [I-D.ietf-isis-segment-routing-extensions], >> > >> > > > > [I-D.ietf-ospf-segment-routing-extensions], and >> > >> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. >> > >> > > > > >> > >> > > > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently >> supported" is a >> > >> > > > > better parenthetical? >> > >> > > > #Ahmed: Corrected in the next version >> > >> > > > > >> > >> > > > > The example diagram depicted in Figure 3 assumes that >> the operator >> > >> > > > > configures P5 to act as a Segment Routing Mapping Server >> (SRMS) and >> > >> > > > > advertises the following mappings: (P7, 107), (P8, 108), >> (PE3, 103) >> > >> > > > > and (PE4, 104). >> > >> > > > > >> > >> > > > > nit: I think this is Figure 2. >> > >> > > > #Ahmed: Corrected in the next version >> > >> > > > > >> > >> > > > > Section 3.2.1 >> > >> > > > > >> > >> > > > > [...] Examples >> > >> > > > > of explicit prefix-SID advertisment are the prefix-SID >> sub-TLVs >> > >> > > > > defined in ([I-D.ietf-isis-segment-routing-extensions], >> > >> > > > > [I-D.ietf-ospf-segment-routing-extensions], and >> > >> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). >> > >> > > > > >> > >> > > > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's >> telechat) >> > >> > > > > be appropriate for inclusion in this list? >> > >> > > > > >> > >> > > > > for that prefix. Hence assigning a prefix-SID to a >> prefix using the >> > >> > > > > SRMS functionality does not preclude assigning the same >> or different >> > >> > > > > prefix-SID(s) to the same prefix using explict prefix-SID >> > >> > > > > advertisement such as the aforementioned prefix-SID >> sub-TLV. >> > >> > > > #Ahmed: The SRMS functionality is specific to IGPs as >> mentioned in the >> > >> > > > second sentence of the second paragraph in Section 3.2 >> > >> > > > > >> > >> > > > > nit: I think the aforementioned things were a list, so >> "sub-TLVs" plural >> > >> > > > > would be appropriate. >> > >> > > > > >> > >> > > > > Including the name for IS-IS TLV 135 might be helpful >> for the >> > >> > > > > reader. >> > >> > > > > >> > >> > > > #Ahmed: Corrected as suggested in the next version >> > >> > > >> > >> > > >> > >> > > >> > >> > >> ________________________________________________________________________________ >> > >> > _________________________________________ >> > >> > > >> > >> > > Ce message et ses pieces jointes peuvent contenir des >> informations confidentielles ou >> > >> > privilegiees et ne doivent donc >> > >> > > pas etre diffuses, exploites ou copies sans autorisation. Si >> vous avez recu ce message par >> > >> > erreur, veuillez le signaler >> > >> > > a l'expediteur et le detruire ainsi que les pieces jointes. >> Les messages electroniques etant >> > >> > susceptibles d'alteration, >> > >> > > Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> > >> > > >> > >> > > This message and its attachments may contain confidential or >> privileged information that may be >> > >> > protected by law; >> > >> > > they should not be distributed, used or copied without >> authorisation. >> > >> > > If you have received this email in error, please notify the >> sender and delete this message and its >> > >> > attachments. >> > >> > > As emails may be altered, Orange is not liable for messages >> that have been modified, changed >> > >> > or falsified. >> > >> > > Thank you. >> > >> > > >> > >> >> > >> >> _________________________________________________________________________________________________________________________ >> > >> >> > >> Ce message et ses pieces jointes peuvent contenir des >> informations confidentielles ou privilegiees et ne doivent donc >> > >> pas etre diffuses, exploites ou copies sans autorisation. Si >> vous avez recu ce message par erreur, veuillez le signaler >> > >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> > >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> > >> >> > >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> > >> they should not be distributed, used or copied without >> authorisation. >> > >> If you have received this email in error, please notify the >> sender and delete this message and its attachments. >> > >> As emails may be altered, Orange is not liable for messages that >> have been modified, changed or falsified. >> > >> Thank you. >> > >> >> > --------------7F83E99B586046503EF17931 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks a for the reminder

I uploaded version 15 to address Benjamin's comments


Ahmed




On 8/29/18 9:09 AM, Alvaro Retana wrote:
Ahmed: Ping!!

We’re really close…

Alvaro.

On July 26, 2018 at 4:27:25 PM, Benjamin Kaduk (kaduk@mit.edu) wrote:

Hi Ahmed,

Thanks for posting the update (and sorry for only getting to it now).

The two specific points I raised in my DISCUSS ballot are properly
addressed, but before I go clear that I was hoping you could help me
remember why the following text was removed when going from -13 to -14:

[...] Because this document recognizes that
miscofiguration and/or programming may result in false or conflicting
label binding advertisements, thereby compromising traffic
forwarding, the document recommends strict configuration/
programmability control as well as montoring the SID advertised and
log/error messages by the operator to avoid or at least significantly
minimize the possibility of such risk.

I couldn't find anything in my email history that helped jog my memory.

Thanks,

Benjamin

On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote:
> Hi,
>
> I just posted version 14
> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt
>
> Thanks
>
> Ahmed
>
>
>
> On 7/10/18 7:11 AM, Benjamin Kaduk wrote:
> > Hi Bruno,
> >
> > Thanks for the additional clarifications in the suggested text -- it looks
> > good to me, so you and Ahmed should please go ahead with it (once
> > submissions open up again).
> >
> > -Benjamin
> >
> > On Tue, Jul 10, 2018 at 12:49:28PM +0000, bruno.decraene@orange.com wrote:
> >> Hi Benjamin,
> >>
> >> Thanks for the discussion.
> >> Please see inline [Bruno2]
> >>
> >>> From: Benjamin Kaduk [mailto:kaduk@mit.edu]
> >> > Sent: Tuesday, July 10, 2018 12:53 AM
> >> > On Mon, Jul 09, 2018 at 12:36:20PM +0000, bruno.decraene@orange.com wrote:
> >> > > Hi Benjamin,
> >> > >
> >> > > Thanks for your comments.
> >> > > Please see inline another addition to Ahmed's answer. [Bruno]
> >> > >
> >> > > > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
> >> > > > Sent: Monday, July 09, 2018 2:30 AM
> >> > > >
> >> > > > Hi
> >> > > > Thanks for the review
> >> > > >
> >> > > > See reply to the comment at #Ahmed
> >> > > >
> >> > > > Ahmed
> >> > > >
> >> > > >
> >> > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote:
> >> > > > > Benjamin Kaduk has entered the following ballot position for
> >> > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss
> >> > > > >
> >> > > > > When responding, please keep the subject line intact and reply to all
> >> > > > > email addresses included in the To and CC lines. (Feel free to cut this
> >> > > > > introductory paragraph, however.)
> >> > > > >
> >> > > > >
> >> > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> > > > > for more information about IESG DISCUSS and COMMENT positions.
> >> > > > >
> >> > > > >
> >> > > > > The document, along with other ballot positions, can be found here:
> >> > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > ----------------------------------------------------------------------
> >> > > > > DISCUSS:
> >> > > > > ----------------------------------------------------------------------
> >> > > > >
> >> > > > > I may be missing something, but I don't see anything that says whether the
> >> > > > > preference field introduced in Section 3.2.3 uses larger values or smaller
> >> > > > > values for more-preferred SRMSes.
> >> > > > #Ahmed:
> >> > > > If I understand this statement correctly, the concern is about which
> >> > > > label(s) get assigned to which prefix(es). This concern is addressed as
> >> > > > follows
> >> > > >
> >> > > > From the MPLS architecture point of view, there is nothing wrong in
> >> > > > having multiple labels for the same prefix. Segment routing in general
> >> > > > and this document in particular did not introduce this behavior nor did
> >> > > > they prohibit/restrict/relax it. For example, an implementation that
> >> > > > allows the operator to locally assign multiple local labels to the same
> >> > > > prefix may continue to apply this behavior whether the platform supports
> >> > > > segment routing or not, in which case it is up to the implementation
> >> > > > and/or the configuration affecting the MPLS forwarding plane to specify
> >> > > > how to behave when multiple labels are assigned to the same prefix. Such
> >> > > > behavior is a general MPLS behavior that outside the scope of and is not
> >> > > > modified by segment routing.
> >> > > >
> >> > > > However the opposite, where the same label gets assigned to multiple
> >> > > > prefixes resulting in label collision is problematic. This document
> >> > > > prohibits label collision resulting from the use of SRMS (which is
> >> > > > introduced by this document) in the first bullet starting at the 3rd
> >> > > > line of page 12:
> >> > > >   "-  If there is an incoming label collision as specified in
> >> > > >       [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified
> >> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve the
> >> > > >       collision.""
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > > The introduction of the SRMS is also introducing a new way for a protocol
> >> > > > > participant to make claims about route prefixes directed at "third parties"
> >> > > > > (non-MS, non-MC routers). While routing protocols in general do require high
> >> > > > > levels of trust in all participants in order for proper routing to occur, this
> >> > > > > addition seems to create a "first among equals" situation that could be called
> >> > > > > out more clearly in the security considerations. (I do appreciate that the
> >> > > > > requirement for preferring SIDs advertised in prefix reachability
> >> > > > > advertisements over those advertised in mapping server advertisements does help
> >> > > > > alleviate some of the risk.)
> >> > >
> >> > > [Bruno]
> >> > > 1) As the SID attached to the prefix reachability is more preferred than the SID advertised by the
> >> > SRMS, I would kind of argue that the SRMS is more "last among equals" :-)
> >> > > 2) I agree that routing protocols, especially Link State Internal Routing Protocols, do require high
> >> > levels of trusts among participants. In particular, please note that any node can already advertise
> >> > any IP prefix (with any attached SID), and with any metric/cost, hence attracting the traffic. In this
> >> > regards, I don't really see an increased risk in IGP routing.
> >> >
> >> > I don't really see an increased risk per se, either (since all routers can
> >> > break routing in all sorts of ways), but I do see a new mechanism by which
> >> > certain routers can cause routing breakage. So I was thinking "first among
> >> > equals" in terms of "more ways to break things", not "can break things with
> >> > a larger magnitude of breakage". You are right that the preference order
> >> > that Ahmed described does mean that this new "mechanism for breakage" is
> >> > only applicable when there are no explicit prefix-SID advertisements
> >> > received via the IGP. So in that sense this new mechanism for breakage is
> >> > "last among equals", as you say, because it can only take effect if the IGP
> >> > leaves room for it.
> >>
> >> [Bruno2] Ack; I believe we are in sync.
> >>
> >> > > 3) I agree that SRMS allows for a "centralized" SID advertisement. I personally don't feel that this
> >> > is more risky than a "centralized" BGP Route Reflector. However, I'm not against raising this in the
> >> > security consideration section.
> >> > > Please see below a proposed text. Please comment/propose text as required.
> >> > >
> >> > > OLD:
> >> > > This document introduces another form of label binding
> >> > > advertisements. The security associated with these advertisement is
> >> > > part of the security applied to routing protocols such as IS-IS
> >> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of
> >> > > cryptographic authentication mechanisms. This document also
> >> > > specifies a mechanism by which the ill effects of advertising
> >> > > conflicting label bindings can be mitigated.
> >> > >
> >> > > NEW:
> >> > > This document introduces another form of label binding
> >> > > advertisements. The security associated with these advertisements is
> >> > > part of the security applied to routing protocols such as IS-IS
> >> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of
> >> > > cryptographic authentication mechanisms.
> >> > > This form of advertisement is more centralized, on behalf of the node advertising the IP
> >> > reachability.
> >> > > This document also
> >> > > specifies a mechanism by which the ill effects of advertising
> >> > > conflicting label bindings can be mitigated. In particular, advertisements from the node
> >> > advertsising the IP reachability is more preference than the centralized one.
> >> >
> >> > I think that's enough to resolve my DISCUSS point. I would prefer if there
> >> > was a little bit more text, such as "more centralized, on behalf of the
> >> > node advertising the IP reachability, which presents a different risk
> >> > profile than existing mechanisms for distributing label bindings", but your
> >> > version does cover the key point.
> >>
> >> [Bruno2] ok. Proposed NEW2:
> >>
> >> This document introduces another form of label binding
> >> advertisements. The security associated with these advertisements is
> >> part of the security applied to routing protocols such as IS-IS
> >> [RFC5304] and OSPF [RFC5709] which both optionally make use of
> >> cryptographic authentication mechanisms.
> >> This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile.
> >> This document also
> >> specifies a mechanism by which the ill effects of advertising
> >> conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one.
> >>
> >>
> >>
> >> In short, I used your proposed text but removed " than existing mechanisms for distributing label bindings" as this could be read as "LDP". We could add more text to distinguish, but IMO the current text seems fine.
> >>
> >>
> >> > (And to be clear, I am not trying to say
> >> > that the centralized risk is better or worse in all cases; it's just
> >> > different, so we should call that out to the reader and inform their decision
> >> > making.)
> >>
> >> [Bruno2] In sync. I agree with you that we should call that out to the reader and inform their decision making. Thanks for bringing the comment.
> >> I'll work with Ahmed, to have the draft reflect this, as he has the pen.
> >>
> >> Thanks,
> >> Bruno
> >>
> >>
> >> > Thanks,
> >> >
> >> > Benjamin
> >> >
> >> > >
> >> > > Thanks,
> >> > > --Bruno
> >> > >
> >> > > > #Ahmed:
> >> > > > If I understand your comment, the concern is about
> >> > > > "first-come-first-serve" behavior. I believe this concern is addressed
> >> > > > as follows
> >> > > > (1) The sentence starting at the fourth line of the second paragraph in
> >> > > > page 10 says:
> >> > > >    For a given prefix, if an MC receives an SR mapping advertisement
> >> > > >    from a mapping server and also has received a prefix-SID
> >> > > >    advertisement for that same prefix in a prefix reachability
> >> > > >    advertisement, then the MC MUST prefer the SID advertised in the
> >> > > >    prefix reachability advertisement over the mapping server
> >> > > >    advertisement i.e., the mapping server advertisment MUST be ignored
> >> > > >    for that prefix.
> >> > > >
> >> > > > (2) The last bullet at the bottom of page 11 says:
> >> > > >    -  For any prefix for which it did not receive a prefix-SID
> >> > > >       advertisement, the MCC applies the SRMS mapping advertisments with
> >> > > >       the highest preference.
> >> > > >
> >> > > > (3) The first bullet near the top pf page 12 says:
> >> > > >    -  If there is an incoming label collision as specified in
> >> > > >       [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified
> >> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve the
> >> > > >       collision.
> >> > > >
> >> > > > So for the same set of received advertisements (SRMS advertisements,
> >> > > > prefix-SID advertisements, or combination of both), the same set of
> >> > > > labels will be assigned to the same prefix. As mentioned in my previous
> >> > > > comments, if multiple labels get assigned to the same prefix, the
> >> > > > behavior is not related to segment routing
> >> > > >
> >> > > > Regarding placing a comment in the security section, IMO a specification
> >> > > > of which advertisement(s) to use when receiving multiple (conflicting or
> >> > > > non-conflicting) advertisements has nothing to do with security. It is
> >> > > > an externally visible protocol(s) behavior that should be specified in
> >> > > > the sections covering the protocol(s) themselves rather than security
> >> > > > consideration of the protocol(s).
> >> > > >
> >> > > > But if you still think there is a need to mention something in the
> >> > > > security section, a suggestion from your side will be greatly appreciated .
> >> > > > >
> >> > > > >
> >> > > > > ----------------------------------------------------------------------
> >> > > > > COMMENT:
> >> > > > > ----------------------------------------------------------------------
> >> > > > >
> >> > > > > I support Alissa's suggestion about the text covering cryptographic authentication.
> >> > > > #Ahmed: I modified the statement as Alissa suggested in version 14 that
> >> > > > will be published in the next 1-2 days
> >> > > > >
> >> > > > > "[100,300]" and "(100,200)" are each used as an example SRGB. In
> >> > > > > some contexts the round versus square brackets indicate a
> >> > > > > distinction between "closed" (includes endpoints) and "open" (does
> >> > > > > not include endpoints) intervals. If there's no need to make such a
> >> > > > > distinction, I suggest standardizing one one format.
> >> > > > #Ahmed: I changed both of them to use [] in version because we mean
> >> > > > inclusive
> >> > > > >
> >> > > > > As was mentioned in the secdir review, it would be good to expand FEC and LFA on first
> >> > usage.
> >> > > > #Ahmed: Corrected in version 14 that will be published in the next 1-2 days
> >> > > > >
> >> > > > > Section 1
> >> > > > >
> >> > > > > Section 2 describes the co-existence of SR with other MPLS Control
> >> > > > > Plane. [...]
> >> > > > >
> >> > > > > nit: "other MPLS Control Plane" seems to be an incomplete compound noun
> >> > > > > -- is it other control plane technologies that are being considered?
> >> > > > #Ahmed: I added "protocols" in version 14 to clarify that
> >> > > > >
> >> > > > > Section 2
> >> > > > >
> >> > > > > Note that this static label allocation capability of the label
> >> > > > > manager exists for many years across several vendors and hence is not
> >> > > > > new. Furthermore, note that the label-manager ability to statically
> >> > > > > allocate a range of labels to a specific application is not new
> >> > > > > either. [...]
> >> > > > >
> >> > > > > nits: "has existed", "label-manager's ability".
> >> > > > #Ahmed: Corrected (thanks a lot)
> >> > > > >
> >> > > > > Section 2.1
> >> > > > >
> >> > > > > MPLS2MPLS refers the forwarding behavior where a router receives an
> >> > > > > labeled packet and switches it out as a labeled packet. Several
> >> > > > >
> >> > > > > nit: "refers to", "a labeled packet"
> >> > > > #Ahmed: Corrected
> >> > > > >
> >> > > > > Section 3.2
> >> > > > >
> >> > > > > This section defines the Segment Routing Mapping Server (SRMS). The
> >> > > > > SRMS is a IGP node advertising mapping between Segment Identifiers
> >> > > > > (SID) and prefixes advertised by other IGP nodes. The SRMS uses a
> >> > > > > dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol
> >> > > > > specific and defined in [I-D.ietf-isis-segment-routing-extensions],
> >> > > > > [I-D.ietf-ospf-segment-routing-extensions], and
> >> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
> >> > > > >
> >> > > > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a
> >> > > > > better parenthetical?
> >> > > > #Ahmed: Corrected in the next version
> >> > > > >
> >> > > > > The example diagram depicted in Figure 3 assumes that the operator
> >> > > > > configures P5 to act as a Segment Routing Mapping Server (SRMS) and
> >> > > > > advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103)
> >> > > > > and (PE4, 104).
> >> > > > >
> >> > > > > nit: I think this is Figure 2.
> >> > > > #Ahmed: Corrected in the next version
> >> > > > >
> >> > > > > Section 3.2.1
> >> > > > >
> >> > > > > [...] Examples
> >> > > > > of explicit prefix-SID advertisment are the prefix-SID sub-TLVs
> >> > > > > defined in ([I-D.ietf-isis-segment-routing-extensions],
> >> > > > > [I-D.ietf-ospf-segment-routing-extensions], and
> >> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
> >> > > > >
> >> > > > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat)
> >> > > > > be appropriate for inclusion in this list?
> >> > > > >
> >> > > > > for that prefix. Hence assigning a prefix-SID to a prefix using the
> >> > > > > SRMS functionality does not preclude assigning the same or different
> >> > > > > prefix-SID(s) to the same prefix using explict prefix-SID
> >> > > > > advertisement such as the aforementioned prefix-SID sub-TLV.
> >> > > > #Ahmed: The SRMS functionality is specific to IGPs as mentioned in the
> >> > > > second sentence of the second paragraph in Section 3.2
> >> > > > >
> >> > > > > nit: I think the aforementioned things were a list, so "sub-TLVs" plural
> >> > > > > would be appropriate.
> >> > > > >
> >> > > > > Including the name for IS-IS TLV 135 might be helpful for the
> >> > > > > reader.
> >> > > > >
> >> > > > #Ahmed: Corrected as suggested in the next version
> >> > >
> >> > >
> >> > >
> >> > ________________________________________________________________________________
> >> > _________________________________________
> >> > >
> >> > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou
> >> > privilegiees et ne doivent donc
> >> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par
> >> > erreur, veuillez le signaler
> >> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant
> >> > susceptibles d'alteration,
> >> > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >> > >
> >> > > This message and its attachments may contain confidential or privileged information that may be
> >> > protected by law;
> >> > > they should not be distributed, used or copied without authorisation.
> >> > > If you have received this email in error, please notify the sender and delete this message and its
> >> > attachments.
> >> > > As emails may be altered, Orange is not liable for messages that have been modified, changed
> >> > or falsified.
> >> > > Thank you.
> >> > >
> >>
> >> _________________________________________________________________________________________________________________________
> >>
> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> This message and its attachments may contain confidential or privileged information that may be protected by law;
> >> they should not be distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender and delete this message and its attachments.
> >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> >> Thank you.
> >>
>

--------------7F83E99B586046503EF17931-- From nobody Sun Sep 2 14:32:01 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB187130DD0; Sun, 2 Sep 2018 14:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 CrGxfhhIQH-1; Sun, 2 Sep 2018 14:31:56 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 4E624130DD8; Sun, 2 Sep 2018 14:31:56 -0700 (PDT) X-AuditID: 1209190d-ee5ff70000002c0d-4d-5b8c56c99d38 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B4.CB.11277.AC65C8B5; Sun, 2 Sep 2018 17:31:54 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w82LVmue030366; Sun, 2 Sep 2018 17:31:49 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w82LVhWu020308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Sep 2018 17:31:45 -0400 Date: Sun, 2 Sep 2018 16:31:43 -0500 From: Benjamin Kaduk To: Ahmed Bashandy Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , "aretana.ietf@gmail.com" , Rob Shakir , bruno.decraene@orange.com, The IESG , "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Message-ID: <20180902213142.GD91593@kduck.kaduk.org> References: <152951284387.28600.11874107921186798735.idtracker@ietfa.amsl.com> <22642_1531139781_5B4356C5_22642_217_1_53C29892C857584299CBF5D05346208A47AE54BA@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180709225252.GD59001@kduck.kaduk.org> <31682_1531226969_5B44AB59_31682_103_1_53C29892C857584299CBF5D05346208A47AE73C4@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20180710141101.GP59001@kduck.kaduk.org> <20180726202715.GA91950@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsUixG6nrnsqrCfaoHeblcXiNRIWNw5tYLL4 sWMOs8WmvVdZLGb8mchscWTyOhaL06t62S2OX/jN6MDhsXPWXXaPBZtKPZYs+cnk0fLsJFsA SxSXTUpqTmZZapG+XQJXRs/uC2wFq7YzVjQcesrYwNjVwdjFyMkhIWAicf3pdJYuRi4OIYHF TBKHr81ghHA2MEpc3vmWBaRKSOAKk8TCo8EgNouAisTENc1gcTYgu6H7MjOILSKgK3Hp5Smw ZmaBRmaJ2d2HwYqEBcolVh2exw5i8wKte3h7NRPEhicsEneur2eESAhKnJz5BKyBWUBHYufW O2xdjBxAtrTE8n8cEGF5ieats8GWcQrYSjzfc5UNxBYVUJbY23eIfQKj4Cwkk2YhmTQLYdIs JJMWMLKsYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECIoUTkneHYz/7nodYhTg YFTi4dXQ6YkWYk0sK67MPcQoycGkJMrrV9YZLcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE90tq V7QQb0piZVVqUT5MSpqDRUmc1/Fca7SQQHpiSWp2ampBahFMVoaDQ0mCd0Uo0B7BotT01Iq0 zJwShDQTByfIcB6g4VUgNbzFBYm5xZnpEPlTjJYc845OncTM8ec9iNzXPW0SsxBLXn5eqpQ4 ryJIgwBIQ0ZpHtxMUOKTyN5f84pRHOhFYV4xYBoU4gEmTbipr4AWMgEtZLnaAbKwJBEhJdXA eO/R86xFxTtjU4wPdLr/qykV+3yuuCnNuN3c8ersDKGLceba1ax6Rs9ilvk6St4TWMaccyth U/2RK/cyHuZm3I2oNtq4Jd9Mx2zxvATnt+08Out0j76vt9i4W2HW1xUZ/1etqNrBnCAYOc80 rje++8Gj9V5mthm7dxX/c4n+3nnim2Alp6G3EktxRqKhFnNRcSIAjpRSH1cDAAA= Archived-At: Subject: Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-ldp-interop-13: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 21:32:00 -0000 On Sun, Sep 02, 2018 at 02:28:58PM -0700, Ahmed Bashandy wrote: > It seems like it was some editing error > > > I uploaded version 15 and oput back the parapgraph Thanks, but I think there is still an editing error, e.g., "Because this document recognizes that reachability, which presents a different risk profile." is not a complete sentence. (I assume this is an extra pasted line in the original source format, though the datatracker only shows .txt and .pdf so I can't check for myself.) -Benjamin > > Ahmed > > > > On 7/26/18 1:27 PM, Benjamin Kaduk wrote: > > Hi Ahmed, > > > > Thanks for posting the update (and sorry for only getting to it now). > > > > The two specific points I raised in my DISCUSS ballot are properly > > addressed, but before I go clear that I was hoping you could help me > > remember why the following text was removed when going from -13 to -14: > > > > [...] Because this document recognizes that > > miscofiguration and/or programming may result in false or conflicting > > label binding advertisements, thereby compromising traffic > > forwarding, the document recommends strict configuration/ > > programmability control as well as montoring the SID advertised and > > log/error messages by the operator to avoid or at least significantly > > minimize the possibility of such risk. > > > > I couldn't find anything in my email history that helped jog my memory. > > > > Thanks, > > > > Benjamin > > > > On Mon, Jul 16, 2018 at 02:10:37PM -0700, Ahmed Bashandy wrote: > >> Hi, > >> > >> I just posted version 14 > >> https://www.ietf.org/id/draft-ietf-spring-segment-routing-ldp-interop-14.txt > >> > >> Thanks > >> > >> Ahmed > >> > >> > >> > >> On 7/10/18 7:11 AM, Benjamin Kaduk wrote: > >>> Hi Bruno, > >>> > >>> Thanks for the additional clarifications in the suggested text -- it looks > >>> good to me, so you and Ahmed should please go ahead with it (once > >>> submissions open up again). > >>> > >>> -Benjamin > >>> > >>> On Tue, Jul 10, 2018 at 12:49:28PM +0000, bruno.decraene@orange.com wrote: > >>>> Hi Benjamin, > >>>> > >>>> Thanks for the discussion. > >>>> Please see inline [Bruno2] > >>>> > >>>>> From: Benjamin Kaduk [mailto:kaduk@mit.edu] > >>>> > Sent: Tuesday, July 10, 2018 12:53 AM > >>>> > On Mon, Jul 09, 2018 at 12:36:20PM +0000, bruno.decraene@orange.com wrote: > >>>> > > Hi Benjamin, > >>>> > > > >>>> > > Thanks for your comments. > >>>> > > Please see inline another addition to Ahmed's answer. [Bruno] > >>>> > > > >>>> > > > From: Ahmed Bashandy [mailto:abashandy.ietf@gmail.com] > >>>> > > > Sent: Monday, July 09, 2018 2:30 AM > >>>> > > > > >>>> > > > Hi > >>>> > > > Thanks for the review > >>>> > > > > >>>> > > > See reply to the comment at #Ahmed > >>>> > > > > >>>> > > > Ahmed > >>>> > > > > >>>> > > > > >>>> > > > On 6/20/18 9:40 AM, Benjamin Kaduk wrote: > >>>> > > > > Benjamin Kaduk has entered the following ballot position for > >>>> > > > > draft-ietf-spring-segment-routing-ldp-interop-13: Discuss > >>>> > > > > > >>>> > > > > When responding, please keep the subject line intact and reply to all > >>>> > > > > email addresses included in the To and CC lines. (Feel free to cut this > >>>> > > > > introductory paragraph, however.) > >>>> > > > > > >>>> > > > > > >>>> > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >>>> > > > > for more information about IESG DISCUSS and COMMENT positions. > >>>> > > > > > >>>> > > > > > >>>> > > > > The document, along with other ballot positions, can be found here: > >>>> > > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > ---------------------------------------------------------------------- > >>>> > > > > DISCUSS: > >>>> > > > > ---------------------------------------------------------------------- > >>>> > > > > > >>>> > > > > I may be missing something, but I don't see anything that says whether the > >>>> > > > > preference field introduced in Section 3.2.3 uses larger values or smaller > >>>> > > > > values for more-preferred SRMSes. > >>>> > > > #Ahmed: > >>>> > > > If I understand this statement correctly, the concern is about which > >>>> > > > label(s) get assigned to which prefix(es). This concern is addressed as > >>>> > > > follows > >>>> > > > > >>>> > > > From the MPLS architecture point of view, there is nothing wrong in > >>>> > > > having multiple labels for the same prefix. Segment routing in general > >>>> > > > and this document in particular did not introduce this behavior nor did > >>>> > > > they prohibit/restrict/relax it. For example, an implementation that > >>>> > > > allows the operator to locally assign multiple local labels to the same > >>>> > > > prefix may continue to apply this behavior whether the platform supports > >>>> > > > segment routing or not, in which case it is up to the implementation > >>>> > > > and/or the configuration affecting the MPLS forwarding plane to specify > >>>> > > > how to behave when multiple labels are assigned to the same prefix. Such > >>>> > > > behavior is a general MPLS behavior that outside the scope of and is not > >>>> > > > modified by segment routing. > >>>> > > > > >>>> > > > However the opposite, where the same label gets assigned to multiple > >>>> > > > prefixes resulting in label collision is problematic. This document > >>>> > > > prohibits label collision resulting from the use of SRMS (which is > >>>> > > > introduced by this document) in the first bullet starting at the 3rd > >>>> > > > line of page 12: > >>>> > > >   "-  If there is an incoming label collision as specified in > >>>> > > >       [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified > >>>> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve the > >>>> > > >       collision."" > >>>> > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > The introduction of the SRMS is also introducing a new way for a protocol > >>>> > > > > participant to make claims about route prefixes directed at "third parties" > >>>> > > > > (non-MS, non-MC routers). While routing protocols in general do require high > >>>> > > > > levels of trust in all participants in order for proper routing to occur, this > >>>> > > > > addition seems to create a "first among equals" situation that could be called > >>>> > > > > out more clearly in the security considerations. (I do appreciate that the > >>>> > > > > requirement for preferring SIDs advertised in prefix reachability > >>>> > > > > advertisements over those advertised in mapping server advertisements does help > >>>> > > > > alleviate some of the risk.) > >>>> > > > >>>> > > [Bruno] > >>>> > > 1) As the SID attached to the prefix reachability is more preferred than the SID advertised by the > >>>> > SRMS, I would kind of argue that the SRMS is more "last among equals" :-) > >>>> > > 2) I agree that routing protocols, especially Link State Internal Routing Protocols, do require high > >>>> > levels of trusts among participants. In particular, please note that any node can already advertise > >>>> > any IP prefix (with any attached SID), and with any metric/cost, hence attracting the traffic. In this > >>>> > regards, I don't really see an increased risk in IGP routing. > >>>> > > >>>> > I don't really see an increased risk per se, either (since all routers can > >>>> > break routing in all sorts of ways), but I do see a new mechanism by which > >>>> > certain routers can cause routing breakage. So I was thinking "first among > >>>> > equals" in terms of "more ways to break things", not "can break things with > >>>> > a larger magnitude of breakage". You are right that the preference order > >>>> > that Ahmed described does mean that this new "mechanism for breakage" is > >>>> > only applicable when there are no explicit prefix-SID advertisements > >>>> > received via the IGP. So in that sense this new mechanism for breakage is > >>>> > "last among equals", as you say, because it can only take effect if the IGP > >>>> > leaves room for it. > >>>> > >>>> [Bruno2] Ack; I believe we are in sync. > >>>> > >>>> > > 3) I agree that SRMS allows for a "centralized" SID advertisement. I personally don't feel that this > >>>> > is more risky than a "centralized" BGP Route Reflector. However, I'm not against raising this in the > >>>> > security consideration section. > >>>> > > Please see below a proposed text. Please comment/propose text as required. > >>>> > > > >>>> > > OLD: > >>>> > > This document introduces another form of label binding > >>>> > > advertisements. The security associated with these advertisement is > >>>> > > part of the security applied to routing protocols such as IS-IS > >>>> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of > >>>> > > cryptographic authentication mechanisms. This document also > >>>> > > specifies a mechanism by which the ill effects of advertising > >>>> > > conflicting label bindings can be mitigated. > >>>> > > > >>>> > > NEW: > >>>> > > This document introduces another form of label binding > >>>> > > advertisements. The security associated with these advertisements is > >>>> > > part of the security applied to routing protocols such as IS-IS > >>>> > > [RFC5304] and OSPF [RFC5709] which both optionally make use of > >>>> > > cryptographic authentication mechanisms. > >>>> > > This form of advertisement is more centralized, on behalf of the node advertising the IP > >>>> > reachability. > >>>> > > This document also > >>>> > > specifies a mechanism by which the ill effects of advertising > >>>> > > conflicting label bindings can be mitigated. In particular, advertisements from the node > >>>> > advertsising the IP reachability is more preference than the centralized one. > >>>> > > >>>> > I think that's enough to resolve my DISCUSS point. I would prefer if there > >>>> > was a little bit more text, such as "more centralized, on behalf of the > >>>> > node advertising the IP reachability, which presents a different risk > >>>> > profile than existing mechanisms for distributing label bindings", but your > >>>> > version does cover the key point. > >>>> > >>>> [Bruno2] ok. Proposed NEW2: > >>>> > >>>> This document introduces another form of label binding > >>>> advertisements. The security associated with these advertisements is > >>>> part of the security applied to routing protocols such as IS-IS > >>>> [RFC5304] and OSPF [RFC5709] which both optionally make use of > >>>> cryptographic authentication mechanisms. > >>>> This form of advertisement is more centralized, on behalf of the node advertising the IP reachability, which presents a different risk profile. > >>>> This document also > >>>> specifies a mechanism by which the ill effects of advertising > >>>> conflicting label bindings can be mitigated. In particular, advertisements from the node advertising the IP reachability is more preferred than the centralized one. > >>>> > >>>> > >>>> > >>>> In short, I used your proposed text but removed " than existing mechanisms for distributing label bindings" as this could be read as "LDP". We could add more text to distinguish, but IMO the current text seems fine. > >>>> > >>>> > >>>> > (And to be clear, I am not trying to say > >>>> > that the centralized risk is better or worse in all cases; it's just > >>>> > different, so we should call that out to the reader and inform their decision > >>>> > making.) > >>>> > >>>> [Bruno2] In sync. I agree with you that we should call that out to the reader and inform their decision making. Thanks for bringing the comment. > >>>> I'll work with Ahmed, to have the draft reflect this, as he has the pen. > >>>> > >>>> Thanks, > >>>> Bruno > >>>> > >>>> > >>>> > Thanks, > >>>> > > >>>> > Benjamin > >>>> > > >>>> > > > >>>> > > Thanks, > >>>> > > --Bruno > >>>> > > > >>>> > > > #Ahmed: > >>>> > > > If I understand your comment, the concern is about > >>>> > > > "first-come-first-serve" behavior. I believe this concern is addressed > >>>> > > > as follows > >>>> > > > (1) The sentence starting at the fourth line of the second paragraph in > >>>> > > > page 10 says: > >>>> > > >    For a given prefix, if an MC receives an SR mapping advertisement > >>>> > > >    from a mapping server and also has received a prefix-SID > >>>> > > >    advertisement for that same prefix in a prefix reachability > >>>> > > >    advertisement, then the MC MUST prefer the SID advertised in the > >>>> > > >    prefix reachability advertisement over the mapping server > >>>> > > >    advertisement i.e., the mapping server advertisment MUST be ignored > >>>> > > >    for that prefix. > >>>> > > > > >>>> > > > (2) The last bullet at the bottom of page 11 says: > >>>> > > >    -  For any prefix for which it did not receive a prefix-SID > >>>> > > >       advertisement, the MCC applies the SRMS mapping advertisments with > >>>> > > >       the highest preference. > >>>> > > > > >>>> > > > (3) The first bullet near the top pf page 12 says: > >>>> > > >    -  If there is an incoming label collision as specified in > >>>> > > >       [I-D.ietf-spring-segment-routing-mpls] , apply the steps specified > >>>> > > >       in [I-D.ietf-spring-segment-routing-mpls] to resolve the > >>>> > > >       collision. > >>>> > > > > >>>> > > > So for the same set of received advertisements (SRMS advertisements, > >>>> > > > prefix-SID advertisements, or combination of both), the same set of > >>>> > > > labels will be assigned to the same prefix. As mentioned in my previous > >>>> > > > comments, if multiple labels get assigned to the same prefix, the > >>>> > > > behavior is not related to segment routing > >>>> > > > > >>>> > > > Regarding placing a comment in the security section, IMO a specification > >>>> > > > of which advertisement(s) to use when receiving multiple (conflicting or > >>>> > > > non-conflicting) advertisements has nothing to do with security. It is > >>>> > > > an externally visible protocol(s) behavior that should be specified in > >>>> > > > the sections covering the protocol(s) themselves rather than security > >>>> > > > consideration of the protocol(s). > >>>> > > > > >>>> > > > But if you still think there is a need to mention something in the > >>>> > > > security section, a suggestion from your side will be greatly appreciated . > >>>> > > > > > >>>> > > > > > >>>> > > > > ---------------------------------------------------------------------- > >>>> > > > > COMMENT: > >>>> > > > > ---------------------------------------------------------------------- > >>>> > > > > > >>>> > > > > I support Alissa's suggestion about the text covering cryptographic authentication. > >>>> > > > #Ahmed: I modified the statement as Alissa suggested in version 14 that > >>>> > > > will be published in the next 1-2 days > >>>> > > > > > >>>> > > > > "[100,300]" and "(100,200)" are each used as an example SRGB. In > >>>> > > > > some contexts the round versus square brackets indicate a > >>>> > > > > distinction between "closed" (includes endpoints) and "open" (does > >>>> > > > > not include endpoints) intervals. If there's no need to make such a > >>>> > > > > distinction, I suggest standardizing one one format. > >>>> > > > #Ahmed: I changed both of them to use [] in version because we mean > >>>> > > > inclusive > >>>> > > > > > >>>> > > > > As was mentioned in the secdir review, it would be good to expand FEC and LFA on first > >>>> > usage. > >>>> > > > #Ahmed: Corrected in version 14 that will be published in the next 1-2 days > >>>> > > > > > >>>> > > > > Section 1 > >>>> > > > > > >>>> > > > > Section 2 describes the co-existence of SR with other MPLS Control > >>>> > > > > Plane. [...] > >>>> > > > > > >>>> > > > > nit: "other MPLS Control Plane" seems to be an incomplete compound noun > >>>> > > > > -- is it other control plane technologies that are being considered? > >>>> > > > #Ahmed: I added "protocols" in version 14 to clarify that > >>>> > > > > > >>>> > > > > Section 2 > >>>> > > > > > >>>> > > > > Note that this static label allocation capability of the label > >>>> > > > > manager exists for many years across several vendors and hence is not > >>>> > > > > new. Furthermore, note that the label-manager ability to statically > >>>> > > > > allocate a range of labels to a specific application is not new > >>>> > > > > either. [...] > >>>> > > > > > >>>> > > > > nits: "has existed", "label-manager's ability". > >>>> > > > #Ahmed: Corrected (thanks a lot) > >>>> > > > > > >>>> > > > > Section 2.1 > >>>> > > > > > >>>> > > > > MPLS2MPLS refers the forwarding behavior where a router receives an > >>>> > > > > labeled packet and switches it out as a labeled packet. Several > >>>> > > > > > >>>> > > > > nit: "refers to", "a labeled packet" > >>>> > > > #Ahmed: Corrected > >>>> > > > > > >>>> > > > > Section 3.2 > >>>> > > > > > >>>> > > > > This section defines the Segment Routing Mapping Server (SRMS). The > >>>> > > > > SRMS is a IGP node advertising mapping between Segment Identifiers > >>>> > > > > (SID) and prefixes advertised by other IGP nodes. The SRMS uses a > >>>> > > > > dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol > >>>> > > > > specific and defined in [I-D.ietf-isis-segment-routing-extensions], > >>>> > > > > [I-D.ietf-ospf-segment-routing-extensions], and > >>>> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. > >>>> > > > > > >>>> > > > > nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a > >>>> > > > > better parenthetical? > >>>> > > > #Ahmed: Corrected in the next version > >>>> > > > > > >>>> > > > > The example diagram depicted in Figure 3 assumes that the operator > >>>> > > > > configures P5 to act as a Segment Routing Mapping Server (SRMS) and > >>>> > > > > advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103) > >>>> > > > > and (PE4, 104). > >>>> > > > > > >>>> > > > > nit: I think this is Figure 2. > >>>> > > > #Ahmed: Corrected in the next version > >>>> > > > > > >>>> > > > > Section 3.2.1 > >>>> > > > > > >>>> > > > > [...] Examples > >>>> > > > > of explicit prefix-SID advertisment are the prefix-SID sub-TLVs > >>>> > > > > defined in ([I-D.ietf-isis-segment-routing-extensions], > >>>> > > > > [I-D.ietf-ospf-segment-routing-extensions], and > >>>> > > > > [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). > >>>> > > > > > >>>> > > > > Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat) > >>>> > > > > be appropriate for inclusion in this list? > >>>> > > > > > >>>> > > > > for that prefix. Hence assigning a prefix-SID to a prefix using the > >>>> > > > > SRMS functionality does not preclude assigning the same or different > >>>> > > > > prefix-SID(s) to the same prefix using explict prefix-SID > >>>> > > > > advertisement such as the aforementioned prefix-SID sub-TLV. > >>>> > > > #Ahmed: The SRMS functionality is specific to IGPs as mentioned in the > >>>> > > > second sentence of the second paragraph in Section 3.2 > >>>> > > > > > >>>> > > > > nit: I think the aforementioned things were a list, so "sub-TLVs" plural > >>>> > > > > would be appropriate. > >>>> > > > > > >>>> > > > > Including the name for IS-IS TLV 135 might be helpful for the > >>>> > > > > reader. > >>>> > > > > > >>>> > > > #Ahmed: Corrected as suggested in the next version > >>>> > > > >>>> > > > >>>> > > > >>>> > ________________________________________________________________________________ > >>>> > _________________________________________ > >>>> > > > >>>> > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou > >>>> > privilegiees et ne doivent donc > >>>> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par > >>>> > erreur, veuillez le signaler > >>>> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant > >>>> > susceptibles d'alteration, > >>>> > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > >>>> > > > >>>> > > This message and its attachments may contain confidential or privileged information that may be > >>>> > protected by law; > >>>> > > they should not be distributed, used or copied without authorisation. > >>>> > > If you have received this email in error, please notify the sender and delete this message and its > >>>> > attachments. > >>>> > > As emails may be altered, Orange is not liable for messages that have been modified, changed > >>>> > or falsified. > >>>> > > Thank you. > >>>> > > > >>>> > >>>> _________________________________________________________________________________________________________________________ > >>>> > >>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > >>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > >>>> > >>>> This message and its attachments may contain confidential or privileged information that may be protected by law; > >>>> they should not be distributed, used or copied without authorisation. > >>>> If you have received this email in error, please notify the sender and delete this message and its attachments. > >>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > >>>> Thank you. > >>>> > From nobody Mon Sep 3 04:29:42 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80860130E34; Mon, 3 Sep 2018 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 TtpQM51Qa0xx; Mon, 3 Sep 2018 04:29:37 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 44D4A130E32; Mon, 3 Sep 2018 04:29:36 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id x26-v6so193598lfi.7; Mon, 03 Sep 2018 04:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x0fgL4vXQI+Gpww2Wase4yM/ShSS1PhPGT06YQM6ceo=; b=iDEHH37UnAUJRVNji3i2cJrFrMkvErm2iiLim7ujwFrmasvGiIcOMKoKcJkkOqg6K4 J7QH2CXhRI8a/sGyPatANGVN33I8eMy4QywI1jh6kbNPvfCzqEA6UZc6M2X5lB7MKAoF RX2M3Ggv4HztNhhlq32FTCd4Qon4OhnkWHRgggXNK2L47NKUONtbGRidFJWZf5rsmdIE oV2hKhIh4ov4JJDUcrZG+7XGidI22ktVPGqRgc3DK3WxAofnYrBCpNouuz952DOcS358 QcNVIvZ5bQ5Dq4qT7lcjGh3JFdIMLVuJ6DOoR171ctHhYn11/JVURSIcYEdg4GjiO/14 jJzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x0fgL4vXQI+Gpww2Wase4yM/ShSS1PhPGT06YQM6ceo=; b=LKLXVDHj2TaZT1d1RVrNxh/qAMSdt8nes1AekYEk6yzR0+YoUcyDmONL2ueLz3LdOP 5j+x+KhJ3IYWhztvWA63A/zQYabLw9gm500+hD3EXFSzJvBC7dYItObdhJSKpZaNhHFl h0i4axi7tsUnmRYKUnvUxr2tnh1998An62j4VSiOHHae3A5wWiVF8v0GH1KeGa2QEevT ixvsnO8SSH5bfG5061o4yi7mUk1M+HqwAKi6jkpsBoB8gPIUp8G2OJxBiHaMWoEZHuFk FhfxCECAG2XTQmUSnS80m8SmuLSa/zyqomoRJAw9BUIDk69pkLczcI70bvHmouvkhpWC 8RRA== X-Gm-Message-State: APzg51ARxxlGgSODund1t0ykVWvrsDJx5NgEFsYXzMr8eD1IyLuEJa1j bgVwq7cWNrXQKKQ41ath3hXvG83o1CRaEa2nDVA= X-Google-Smtp-Source: ANB0VdZrxDeccs/l1Oqlvcpabj6ASxd/hhRB80Ru4J8TDyWkKwN+wGMvbc53aOdxptOqXNq7k+mobsiEb9lbQR1MJ7g= X-Received: by 2002:a19:500f:: with SMTP id e15-v6mr16913240lfb.71.1535974174421; Mon, 03 Sep 2018 04:29:34 -0700 (PDT) MIME-Version: 1.0 References: <40ED2C86-3403-4D89-8CA8-FBB9651BF2AB@gmail.com> <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> In-Reply-To: <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net> From: Gaurav Dawra Date: Mon, 3 Sep 2018 04:29:22 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Alvaro Retana , Martin Stiemerling , SPRING WG , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="0000000000000cfa830574f5db7f" Archived-At: Subject: Re: [spring] [Tsv-art] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 11:29:40 -0000 --0000000000000cfa830574f5db7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Please see inline...[Gaurav2] On Thu, Aug 9, 2018 at 8:30 AM Mirja K=C3=BChlewind w= rote: > Hi Gaurav, > > please see inline. > > On 03.08.2018 07:20, Gaurav Dawra wrote: > > Hey Mirja, > > Sorry for the long delay. I was traveling constantly since IETF and bit > lost in my mailbox and discussion with Authors. Please see my response > inline[Gaurav] > > > I think with your changes you addressed explicit problems Martin called > out, however, I still have high level concerns about these sections as th= ey > are mostly giving speculative recommendation which are not clear to me to > work in practice. > > Regarding section 7.1, you say > "A flowlet is defined as a burst of packets from the same flow followed b= y > an idle interval." > but then you say > "...then the application can break the elephant flow F into flowlets F1, > F2, F3, F4..." > > This sounds like you would just divide an elephant flow mostly randomly > into flowlets which can interact badly with the congestion control. If yo= u > actually have chunks of data that are transmitted with large enough idle > interval in between (as you define flowlets in the first sentence), that = is > not an elephant flow anymore and it will not help you to "spread the load > of the elephant flow through all the ECMP paths". In summary I actually > don't see how the concept of flowlets can be helpful to address the probl= em > you have at all, and I still advise you to remove section 7.1 entirely. > > [Gaurav] Hi Mirja, Thanks for the review. The proposal here is no > different that current ECMP hashing at flowlet level. The only difference > which is being pointed out here is that if we use SR, we could leverage o= n > the ability of be aware of multiple disjoint paths rather than the hashin= g. > It=E2=80=99s pins the flowlets to particular paths which is basic SR oper= ations. > > > Yes the problem is that we usually don't recommend ECMP hashing on flowle= t > level because it can interact badly with the end-end mechanisms of that > flow. As I said, I don't see how the notion of flowlets help you problem > and therefore I still recommend to remove that paragraph. > [Gaurav2] OK. It took sometime to get to consensus with authors. Will > update the text to use 5-tuple flows instead of flowlets. Would that > suffice? I will update the text shortly. > > > Regarding section 7.2, I also still skeptical about any benefits that can > be achieved. Given you are in a data center, the controller should alread= y > know about static parameters such as the maximum bandwidth per link. > > For dynamic parameters, e.g. like loss rate, measuring them on a per-flow > bases is the wrong thing to do. What I mean is you can ask a router about > the average loss rate that it observes and that might give you some > valuable, however, if you ask a TCP flow about the average loss rate the > answer will mainly depend on the congestion controller used and the > currently available bandwidth, which is a very dynamic property and not a > link characteristic. So this information is not usable for performance > aware routing. A flow could give you information about the observed RTT > (min/max) on a certain path, or the maximum available bandwidth on a path= , > but as I said, given you are in a data center environment these are > information that the controller already should have anyway. > > [Gaurav] They are two separate mechanisms. Most DCs have some sort of > data-plane/ECMP aware tracing mechanism to detect the loss/delays and can > be combined with Application back-off to detect issue. All this section i= s > suggesting is that SR can be used to pin the path to particular set of EC= MP > paths instead of relying on ECMP hashing. > > > This is not quite what the text says. If that is the statement you want t= o > make, that is fine but then you don't need to talk about performance awar= e > routing at all. > [Gaurav2] I will update the text here with statement i mentioned above. IMHO, it's performance aware routing wrt to end-host traffic. > > > Your example with detecting a faulty path due to losses does not work wit= h > TCP as you never know if these loses are due to a problem on the path, > self-induced or by a competing flow. And even if you don't use TCP and e.= g. > send constant bit rate traffic, there may be a large number of competing > TCP flows that can induce the loses. Try to steer traffic "away" on a > time-scale that is slower than TCP dynamics or even your flow dynamic (wh= en > flows start or end) in case you have a lot of very short flow, in the bes= t > case doesn't work and in the worst case leads to oscillation. > > [Gaurav] As I said above, there are other mechanisms to detect loss and > trace the path on which loss is seen. This is a common mechanism used in > MSDCs. > > I think this is beyond the scope of the document. > [Gaurav2] Will update the text. > > > > I am happy to discuss further over the phone to try to explain the though= t > process. I will also do check again with Authors to update the text or > something else based on our conversation. > > > Maybe see if some update can be made to the text first and then we can > have another discussion if needed. > [Gaurav2] Sounds good. Will update the text shortly and then we can > discuss if needed. > Cheers, Gaurav > > > Cheers, > > > > Gaurav > > If you want to make TCP use for handover situation where one path might g= o > away or become unusable, it's best to use Multipath TCP (with coupled > congestion control) instead because that works on the right time scale. > Again, I don't think this is a use case for SR and I would recommend to > remove the section entirely. > > Mirja > > > > > On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra > wrote: > >> Hi Mirja, >> >> Ack. Let me work with authors to close ASAP. >> >> Cheers, >> >> Gaurav >> >> Sent from my iPhone >> >> On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind = wrote: >> >> Hi Gaurav, >> >> sorry for my very long delay but this got somehow a bit lost in my >> mailbox. >> >> I think with your changes you addressed explicit problems Martin called >> out, however, I still have high level concerns about these sections as t= hey >> are mostly giving speculative recommendation which are not clear to me t= o >> work in practice. >> >> Regarding section 7.1, you say >> "A flowlet is defined as a burst of packets from the same flow followed >> by an idle interval." >> but then you say >> "...then the application can break the elephant flow F into flowlets F1, >> F2, F3, F4..." >> >> This sounds like you would just divide an elephant flow mostly randomly >> into flowlets which can interact badly with the congestion control. If y= ou >> actually have chunks of data that are transmitted with large enough idle >> interval in between (as you define flowlets in the first sentence), that= is >> not an elephant flow anymore and it will not help you to "spread the loa= d >> of the elephant flow through all the ECMP paths". In summary I actually >> don't see how the concept of flowlets can be helpful to address the prob= lem >> you have at all, and I still advise you to remove section 7.1 entirely. >> >> Regarding section 7.2, I also still skeptical about any benefits that ca= n >> be achieved. Given you are in a data center, the controller should alrea= dy >> know about static parameters such as the maximum bandwidth per link. For >> dynamic parameters, e.g. like loss rate, measuring them on a per-flow ba= ses >> is the wrong thing to do. What I mean is you can ask a router about the >> average loss rate that it observes and that might give you some valuable= , >> however, if you ask a TCP flow about the average loss rate the answer wi= ll >> mainly depend on the congestion controller used and the currently availa= ble >> bandwidth, which is a very dynamic property and not a link characteristi= c. >> So this information is not usable for performance aware routing. A flow >> could give you information about the observed RTT (min/max) on a certain >> path, or the maximum available bandwidth on a path, but as I said, given >> you are in a data center environment these are information that the >> controller already should have anyway. >> >> Your example with detecting a faulty path due to losses does not work >> with TCP as you never know if these loses are due to a problem on the pa= th, >> self-induced or by a competing flow. And even if you don't use TCP and e= .g. >> send constant bit rate traffic, there may be a large number of competing >> TCP flows that can induce the loses. Try to steer traffic "away" on a >> time-scale that is slower than TCP dynamics or even your flow dynamic (w= hen >> flows start or end) in case you have a lot of very short flow, in the be= st >> case doesn't work and in the worst case leads to oscillation. >> >> If you want to make TCP use for handover situation where one path might >> go away or become unusable, it's best to use Multipath TCP (with coupled >> congestion control) instead because that works on the right time scale. >> Again, I don't think this is a use case for SR and I would recommend to >> remove the section entirely. >> >> Mirja >> >> >> On 05.07.2018 04:08, Gaurav Dawra wrote: >> >> Hey Alvaro, Mirja, >> >> Friendly reminder to further progress this document. >> >> Cheers, >> >> Gaurav >> >> On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra >> wrote: >> >>> Hi Alvaro, Mirja >>> >>> Any feedback or next steps to close this? >>> >>> Cheers, >>> >>> Gaurav >>> >>> Sent from my iPhone >>> >>> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra wrote= : >>> >>> Hi Mirja, >>> >>> Friendly Reminder...Could you please also advice if there is anything >>> further to DISCUSS on this document which was also related to TCP updat= es >>> below? >>> >>> Cheers, >>> >>> Gaurav >>> >>> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana >>> wrote: >>> >>>> Thanks Martin! >>>> >>>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gmail.com) >>>> wrote: >>>> >>>> Hi Alvaro, all, >>>> >>>> Thanks for addressing my concerns. >>>> >>>> This version is good to go from my side. >>>> >>>> Kind regards, >>>> >>>> ;Martin >>>> >>>> Am 30.05.18 um 21:55 schrieb Alvaro Retana: >>>> > Martin: >>>> > br/>> Hi!! How are you? >>>> > br/>> Gaurav just posted a revision. Please takke a look and let us >>>> know if br/>> the changes address your concerrns or not. >>>> > br/>> >>>> https://www.ietf.org/rfcdiff??url2=3Ddraft-ietf-spring-segment-routing= -msdc-09 >>>> > br/>> Thanks!!! >>>> > br/>> Alvaro. < >>>> > br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (( >>>> gdawra.ietf@gmail.com br/>> ) wrote: >>>> > br/>>> Hi Martin, < >>>> >> >>>> >> Thanks for review. I will post the new version. Hopefully, it will >>>> br/>>> address all your comments and we can close thhis review. >>>> >> >>>> >> Any updates on below response? >>>> >> >>>> >> Cheers, >>>> >> >>>> >> Gaurav >>>> >> >>>> >> Sent from my iPhone >>>> >> >>>> >> On May 23, 2018, at 4:17 AM, Gaurav Dawra >>> br/>>> > wrote: >>>> >> >>>> >>> Hi Martin, >>>> >>> >>>> >>> Thanks for the review. Any further comments here ? I will post the >>>> br/>>>> new version soon. < >>>> >>> >>>> >>> Cheers, >>>> >>> >>>> >>> Gaurav >>>> >>> >>>> >>> Sent from my iPhone >>>> >>> >>>> >>> On May 16, 2018, at 7:44 PM, Gaurav Dawra >>> br/>>>> >> wrote: >>>> >>> >>>> >>>> Hi Martin, >>>> >>>> >>>> >>>> Apologies from my end we had few internal authors conversations o= n >>>> br/>>>>> the points you have raised. < >>>> >>>> >>>> >>>> Please find below my response. I will be happy to discuss further= , >>>> br/>>>>> if needed. < >>>> >>>> >>>> >>>> inline... >>>> >>>> >>>> >>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling < >>>> mls.ietf@gmail.com br/>>>>>> > wrote: >>>> >>>>> >>>> >>>>> Hi Gaurav, >>>> >>>>> >>>> >>>>> This got lost on my end, sorry for this. The filter just moved >>>> br/>>>>>> these messages out of my sight... :-/ >>>> >>>>> >>>> >>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra: >>>> >>>>>> Hey Martin, >>>> >>>>>> Sorry for late reply. Please see some comments inline[Gaurav] >>>> >>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>> >>>> br/>>>>>>>>; >>> mls.ietf@gmail.com>> wrote: >>>> >>>>>>> >>>> >>>>>>> Hi all, >>>> >>>>>>> >>>> >>>>>>> I've reviewed this document as part of the transport area >>>> review br/>>>>>>>> team's ongoing effort to review key IETF documents. >>>> These br/>>>>t;>>>> comments were written primarily for the transpor= t >>>> area directors, br/>>>>>>>> but are copied to the doocument's authors = for >>>> their information br/>>>>>>>&> and to allow them to address any issues >>>> raised. When done at the >>>> >>>>>>> time of IETF Last Call, the authors should consider this revie= w >>>> br/>>>>>>>> together with any other last-call comments they receive. P= lease >>>> br/>>>&>>>>> always CC tsv-art@=E2=80=A6 if you reply to or forward th= is >>>> review. >>>> >>>>>>> >>>> >>>>>>> Summary: >>>> >>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one >>>> part br/>>>>>>>> of Secction3, described in the review, and needs to b= e >>>> rethought. br/>>&>>>>>> The other sections are good AFAIK. >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Technicals: >>>> >>>>>>> The overall draft looks ok, but the three points below look >>>> br/>>>>>>>> strange and need a fix before publication IMHO: >>>> >>>>>>> >>>> >>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not >>>> well br/>>>>>>>> proven funcationality and not even safe to use >>>> functionality. br/>>>&>>>>> Both are some sort discussing that differe= nt >>>> paths in the network br/>>>>>>>> could be used by the eend host traffi= c. >>>> This sounds pretty much br/>>>>>>>t;> like the Path Aware Networking >>>> Proposed Research Group br/>>t;>>>>>> (https://irtf.org/panrg) and >>>> hints to the fact that there is no br/>>>>>>>> commonly understannd an= d >>>> accepted engineering solution in this space. >>>> >>>>>>> >>>> >>>>>>> Section 7.1: >>>> >>>>>>> [KANDULA04] is a really old reference that hasn't been followe= d >>>> br/>>>>>>>> up iin recent times and even worse there is no evidence th= at >>>> this br/>>t;>>>>>> is going to work good enough or stable enough und= er >>>> real Internet br/>>>>>>>> traffic. Additioonally, it is more than uncl= ear >>>> how any modern TCP br/>>>>&ggt;>>> implementation will react to this >>>> >>>>>> [Gaurav] Will get back on this. >>>> >>>>> >>>> >>>>> I will reply to the other email dicussing this. >>>> >>>> I have replied to other thread. >>>> >>>>> >>>> >>>>>>> >>>> >>>>>>> Section 7.2: >>>> >>>>>>> This section describes an idea without detailing too much abou= t >>>> br/>>>>>>>> any furtther aspects. Further it changes the commonly acce= pted >>>> br/>>>;>>>>> notion of what an end host can do with the network. At be= st >>>> this br/>>>>>>>> would require a good ddefinition of what an end host = in >>>> your br/>>>>>>>&ggt; setting is, e.g., a highly modified piece of (at >>>> least) software >>>> >>>>>>> that usually not found in OS availble on the market (yet?) >>>> >>>>>>> Further communicating instantaneous path characteristics to a >>>> br/>>>>>>>> central point is potentially a bad idea, as the data is al= ready >>>> br/>>>;>>>>> outdated when reported by any node. >>>> >>>>>> [Gaurav] I believe Authors are trying to highlight that Host >>>> which br/>>>>>>> is defineed in br/>>>>>>> ( >>>> https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15) >>>> br/>>>>>>> can innfluence the traffic based on the Calculations locall= y or >>>> br/>>>t;>>>> jointly with the controller. Implementations can decide= how >>>> much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Host >>>> based on br/>>>>>>> perfoormance data collection. >>>> >>>>> >>>> >>>>> Performance data collection (monitoring?) isn't crucial when it >>>> br/>>>>>> comes to timely (actuaally real-time) reaction. However, thi= s >>>> br/>>>>>> secttion isn't just about performance data collection as it = is >>>> about br/>>>>>>> "Performance-aware routing" this seems to try to inte= ract >>>> in br/>>>>>> real-time with the network behhavior of TCP. This isn't e= ven >>>> close br/>>>>>> to acceeptable. >>>> >>>>> >>>> >>>>> I would be ok to say that it is useful to collect performance >>>> data br/>>>>>> for offline analysis and improvement of the data networ= k. >>>> However, br/>>>>>&ggt; this is at completely different magnitues of ti= me >>>> scales. >>>> >>>>> >>>> >>>>> I would recommend to remove the TCP part from this section >>>> entirely. >>>> >>>> Ack, will update in next rev: >>>> >>>> >>>> >>>> Section will read like this: >>>> >>>> >>>> >>>> ; >>>> >>>> /Knowing the path associated with flows/packets, the end host may= / >>>> >>>> /deduce certain characteristics of the path on its own, and/ >>>> >>>> /additionally use the information supplied with path information/ >>>> >>>> /pushed from the controller or received via pull request. The >>>> host/ >>>> >>>> /may further share its path observations with the centralized >>>> agent,/ >>>> >>>> /so that the latter may keep up-to-date network health map to >>>> assist/ >>>> >>>> /other hosts with this information./ >>>> >>>> // >>>> >>>> /For example, an application A.1 at HostA may pin a flow destined= / >>>> >>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. >>>> The/ >>>> >>>> /application A.1 may collect information on packet loss, deduced >>>> from/ >>>> >>>> /Other offline mechanisms. [There are some pingMesh mechanisms >>>> which / >>>> >>>> /Can be used here]/ >>>> >>>> /Through these mechanisms information to a centralized agent, >>>> e.g./ >>>> >>>> /after a flow completes, or periodically for longer lived flows./ >>>> >>>> /Next, using both local and/or global performance data, >>>> application/ >>>> >>>> /A.1 as well as other applications sharing the same resources in >>>> the/ >>>> >>>> /DC fabric may pick up the best path for the new flow, or update >>>> an/ >>>> >>>> /existing path (e.g.: when informed of congestion on an existing/ >>>> >>>> /path)./ >>>> >>>> ; >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>>> >>>> >>>>>>> Section 3, 3rd bullet point: >>>> >>>>>>> It is the foundation of TCP that the network is regarded as a >>>> br/>>>>>>>> black box and that you infer from the transmission of pack= ets >>>> br/>>>>;>>>> what the current state of the network path is. Inferring >>>> network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a b= ad >>>> idea, as br/>>>>>>>>; this would required that all paths exhibit this = and >>>> if not what br//>>>>>>>> is going to happen? >>>> >>>>>>> It could be an interesting research field to change many point= s >>>> br/>>>>>>>> in TCP'ss behavior, but this once again points to the fact= that >>>> br/>>>&>>>>> this not the IETF works but IRTF or elsewhere. >>>> >>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is >>>> rightly br/>>>>>>> treating Network as Black Box. Authors are implying= per >>>> path br/>>>>;>>> performance metrics as not cached. Is there some chan= ge in >>>> text br/>>>>>>> you are suggesting?? >>>> >>>>> >>>> >>>>> >>>> >>>>> I would recommend to remove the 3rd bullet point completey. TCP >>>> br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is >>>> br/>>>>>> something the network could decide, e.g., rerouting TCP flow= s >>>> br/>&ggt;>>>> within the network or changing the forwarding path in th= e >>>> network br/>>>>>> for particular flows (if it is not routed). >>>> >>>> >>>> >>>> Ack, after discussion, we will remove the Section 3 - 3r= d >>>> br/>>>>> bullet point. Willl update in next rev - coming shortly. >>>> >>>> >>>> >>>>> >>>> >>>>> Kind regards, >>>> >>>>> >>>> >>>>> Martin >>>> >>>>> >>>> >>>> >>>> >>>> >>> >> >> >> _______________________________________________ >> Tsv-art mailing listTsv-art@ietf.orghttps://www.ietf.org/mailman/listinf= o/tsv-art >> >> >> > > --0000000000000cfa830574f5db7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Please see inline...[Gaurav2]=

On Thu, Aug 9, 2018 a= t 8:30 AM Mirja K=C3=BChlewind <i= etf@kuehlewind.net> wrote:
=20 =20 =20
Hi Gaurav,

please see inline.

On 03.08.2018 07:20= , Gaurav Dawra wrote:
=20
Hey Mirja,

Sorry for the long delay. I was traveling constantly since IETF and bit lost in my mailbox and discussion with Authors. Please see my response inline[Gaurav]


I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the applicat= ion can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow through all the ECMP paths". In summar= y I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.<= /span>

[Gaurav] Hi Mirja, Thanks for the review. The proposal here is no different that current ECMP hashing at flowlet level. The only difference which is being pointed out here is that if we use SR, we could leverage on the ability of be aware of multiple disjoint paths rather than the hashing. It=E2=80=99s pins the flowlets to particular paths which is basic SR operations.


Yes the problem is that we usually don't recommend ECMP hashing on flowlet level because it can interact badly with the end-end mechanisms of that flow. As I said, I don't see how the notion of flowlets help you problem and therefore I still recommend to remove that paragraph.
[Gaurav2] OK. It took sometime to get to consensus with authors. Will u= pdate the text to use 5-tuple flows instead of flowlets. Would that suffice= ? I will update the text shortly.


Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link.

For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

[Gaurav] They are two separate mechanisms. Most DCs have some sort of data-plane/ECMP aware tracing mechanism to detect the loss/delays and can be combined with Application back-off to detect issue. All this section is suggesting is that SR can be used to pin the path to particular set of ECMP paths instead of relying on ECMP hashing.


This is not quite what the text says. If that is the statement you want to make, that is fine but then you don't need to talk about performance aware routing at all.
= [Gaurav2] I will update the text here with statement i mentioned above. IMH= O, it's performance aware routing wrt to end-host traffic.=C2=A0 =C2=A0=


Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away" on a time-scale that is= slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

[Gaurav] As I said above, there are other mechanisms to detect loss and trace the path on which loss is seen. This is a common mechanism used in MSDCs.

I think this is beyond the scope of the document.=C2=A0
[Gaurav2] Will update the text.

=C2=A0

I am happy to discuss further over the phone to try to explain the thought process. I will also do check again with Authors to update the text or something else based on our conversation.


Maybe see if some update can be made to the text first and then we can have another discussion if needed.
[Gaurav2] Sounds good. Will update the text shortly and then we can dis= cuss if needed.

Cheers,

Gaurav=C2=A0

=C2=A0

Cheers,

=C2=A0

Gaurav

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for SR and I would recommend to remove the section entirely.

Mirja<= sub><= /span>

=C2=A0



On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:
Hi Mirja,

Ack. Let me work with authors to close ASAP.

Cheers,

Gaurav

Sent from my iPhone

On Jul 5, 2018, at 10:06 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:

Hi Gaurav,

sorry for my very long delay but this got somehow a bit lost in my mailbox.

I think with your changes you addressed explicit problems Martin called out, however, I still have high level concerns about these sections as they are mostly giving speculative recommendation which are not clear to me to work in practice.

Regarding section 7.1, you say
"A flowlet is defined as a burst of packets from the same flow followed by an idle interval."
but then you say
"...then the application can break the elephant flow F into flowlets F1, F2, F3, F4..."

This sounds like you would just divide an elephant flow mostly randomly into flowlets which can interact badly with the congestion control. If you actually have chunks of data that are transmitted with large enough idle interval in between (as you define flowlets in the first sentence), that is not an elephant flow anymore and it will not help you to "spread the load of the elephant flow throug= h all the ECMP paths". In summary I actually don't see how the concept of flowlets can be helpful to address the problem you have at all, and I still advise you to remove section 7.1 entirely.

Regarding section 7.2, I also still skeptical about any benefits that can be achieved. Given you are in a data center, the controller should already know about static parameters such as the maximum bandwidth per link. For dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases is the wrong thing to do. What I mean is you can ask a router about the average loss rate that it observes and that might give you some valuable, however, if you ask a TCP flow about the average loss rate the answer will mainly depend on the congestion controller used and the currently available bandwidth, which is a very dynamic property and not a link characteristic. So this information is not usable for performance aware routing. A flow could give you information about the observed RTT (min/max) on a certain path, or the maximum available bandwidth on a path, but as I said, given you are in a data center environment these are information that the controller already should have anyway.

Your example with detecting a faulty path due to losses does not work with TCP as you never know if these loses are due to a problem on the path, self-induced or by a competing flow. And even if you don't use TCP and e.g. send constant bit rate traffic, there may be a large number of competing TCP flows that can induce the loses. Try to steer traffic "away= " on a time-scale that is slower than TCP dynamics or even your flow dynamic (when flows start or end) in case you have a lot of very short flow, in the best case doesn't work and in the worst case leads to oscillation.

If you want to make TCP use for handover situation where one path might go away or become unusable, it's best to use Multipath TCP (with coupled congestion control) instead because that works on the right time scale. Again, I don't think this is a use case for S= R and I would recommend to remove the section entirely.

Mirja


On 05.07.2018 04:08, Gaurav Dawra wrote:
Hey Alvaro, Mirja,=C2=A0

Friendly reminder to further progress this document.

Cheers,

Gaurav

On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <gdawra.= ietf@gmail.com> wrote:
Hi Alvaro, Mirja=C2=A0

Any feedback or next steps to close this?

Cheers,

Gaurav

Sent from my iPhone

On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:

Hi Mirja,

Friendly Reminder...Could you please also advice if there is anything further to DISCUSS on this document which was also related to TCP updates below?

Cheers,

Gaurav
=
On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <aretana.i= etf@gmail.com> wrote:

Thanks Martin!

On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@gmail.com) wrote:

Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!=C2=A0 How ar= e you?
> br/>> Gaurav just posted a revision.=C2=A0 Please takke a look and let us know if br/>> the changes address your concerrns or not.
> br/>> https://www.ietf.org/rfcdiff??url2=3Ddraft-iet= f-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra ((gdawra.ietf@gmail.com br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
>>
>> Thanks for review. I will post the new version. Hopefully, it will br/>>> address all your comments and we can close thhis review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>= > On May 23, 2018, at 4:17 AM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>> <mailto:gdawra.ietf@@gmail.com>> wrote:
>>
>>> Hi Martin,
>>>
>>&g= t; Thanks for the review. Any further comments here ? I will post the br/>>>&g= t; new version soon. <
>>>= ;
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>= >> On May 16, 2018, at 7:44 PM, Gaurav Dawra <gdawra.ietf@gmail.com br/>>>&g= t; <mailto:gdawra.ietf@@gmail..com>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>&g= t;> Apologies from my end we had few internal authors conversations on br/>>>&g= t;> the points you have raised. <
>>>>
>>>> Please find below my response. I will be happy to discuss further, br/>>>&g= t;> if needed. <
>>>>
>>>> <Gaurav> inline...
>>>= ;>
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <mls.ietf@gmail.com br/>>>>>> <mailto:mls.iietf@gmail.com>> wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>&g= t;>> This got lost on my end, sorry for this. The filter just moved br/>>>&g= t;>> these messages out of my sight... :-/
>>>= ;>>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>= >>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>&g= t;>>>> <mls.ietf@@gmail.com <mailto:mls.ietf@gmail.com>= ; br/>>>>>>>>; <mailto:mls.ietf@gmail.com>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>&g= t;>>>> I've reviewed this document as part of the transport area review br/>>>&g= t;>>>> team's ongoin= g effort to review key IETF documents. These br/>>>&a= mp;gtt;>>>> comments were written primarily for the transport area directors, br/>>>&g= t;>>>> but are copied to the doocument's authors for their information br/>>>&g= t;>>>&> and to allow them to address any issues raised. When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review br/>>>&g= t;>>>> together with any other last-call comments they receive. Please br/>>>&a= mp;>>>>> always CC tsv-art@=E2=80=A6= if you reply to or forward this review.
>>>>>>>
>>>>>>> Summary:
>>>>>>> This draft has serious issues in Section 7..1, 7.2 and in one part br/>>>&g= t;>>>> of Secction3, described in the review, and needs to be rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look br/>>>&g= t;>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well br/>>>&g= t;>>>> proven funcationality and not even safe to use functionality. br/>>>&>>>>> Both are some sort discussing that different paths in the network br/>>>&g= t;>>>> could be used by the eend host traffic. This sounds pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the fact that there is no br/>>>&g= t;>>>> commonly understannd and accepted engineering solution in this space.
>>>>>>>
>>>>>>> Section 7.1:
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed br/>>>&g= t;>>>> up iin recent times and even worse there is no evidence that this br/>&gtt;&= gt;>>>>> is going to work good enough or stable enough under real Internet br/>>>&g= t;>>>> traffic. Additioonally, it is more than unclear how any modern TCP br/>>>&g= t;&ggt;>>> implementation will react to this
>>>= ;>>> [Gaurav] Will get back on this.
>>>>>
>>>>> I will reply to the other email dicussing this.
>>>> <Gaurav> I have replied to other thread.
>>>>>
>>>>>>>
>>>>>>> Section 7.2:
>>&g= t;>>>> This section describes an idea without detailing too much about br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted br/>>>;&= gt;>>>> notion of what an end host can do with the network. At best this br/>>>&g= t;>>>> would require a good ddefinition of what an end host in your br/>>>&g= t;>>>&ggt; setting is, e.g., a highly modified piece of (at least) software
>>>= ;>>>> that usually not found in OS availble on the market (yet?)
>>&g= t;>>>> Further communicating instantaneous path characteristics to a br/>>>&g= t;>>>> central point is potentially a bad idea, as the data is already br/>>>;>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which br/>>>&g= t;>>> is defineed in br/>>>>>>> (https://tools.ietf.or= g/html/draftt-ietf-spring-segment-routing-15) br/>>>>>>> can innfluence the traffic based on the Calculations locally or br/>>&g= tt;>>>> jointly with the controller. Implementations can decide how much br/>>>&g= t;>>> Centralized -vs- localized coontrol is allowed at Host based on br/>>>>>>> perfoormance data collection.
>>>>>
>>>>> Performance data collection (monitoring?) isn't crucial when it br/>>>&g= t;>> comes to timely (actuaally real-time) reaction. However, this br/>>>>>> secttion isn't just about performance data collection as it is about br/>>>&g= t;>>> "Performance-aware routing" this seems to try to interact in br/>>>&g= t;>> real-time with the network behhavior of TCP. This isn't even close br/>>>&g= t;>> to acceeptable.
>>>>>
>>>>> I would be ok to say that it is useful to collect performance data br/>>>&g= t;>> for offline analysis and improvement of the data network. However, br/>>>&g= t;>&ggt; this is at completely different magnitues of time scales.
>>>= ;>>
>>>>> I would recommend to remove the TCP part from this section entirely.
>>>> <Gaurav>Ack, will update in next rev:
>>>>
>>>> Section will read like this:
>>>>
>>>> ;
>>>> /Knowing the path associated with flows/packets, the end host may/
>>>> /deduce certain characteristics of the path on its own, and/
>>>> /additionally use the information supplied with path information/
>>>> /pushed from the controller or received via pull request. The host/
>>>> /may further share its path observations with the centralized agent,/
>>>> /so that the latter may keep up-to-date network health map to assist/
>>>> /other hosts with this information./
>>>> //
>>>> /For example, an application A.1 at HostA may pin a flow destined/
>>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/
>>>> /application A.1 may collect information on packet loss, deduced from/
>>>> /Other offline mechanisms. [There are some pingMesh mechanisms which /
>>>> /Can be used here]/
>>>> /Through these mechanisms information to a centralized agent, e.g./
>>>> /after a flow completes, or periodically for longer lived flows./
>>>> /Next, using both local and/or global performance data, application/
>>>> /A.1 as well as other applications sharing the same resources in the/
>>>> /DC fabric may pick up the best path for the new flow, or update an/
>>>> /existing path (e.g.: when informed of congestion on an existing/
>>>> /path)./
>>>> ;
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> Section 3, 3rd bullet point:
>>&g= t;>>>> It is the foundation of TCP that the network is regarded as a br/>>>>>>>> black box and that you infer from the transmission of packets br/>>>>;>>>> what the current state of the network path is. Inferring network br/>>>&g= t;>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as br/>>>&g= t;>>>>; this would required that all paths exhibit this and if not what br//>>>&= gt;>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points br/>>>&g= t;>>>> in TCP'ss behavior, but this once again points to the fact that br/>>>&a= mp;>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly br/>>>&g= t;>>> treating Network as Black Box. Authors are implying per path br/>>>&g= t;;>>> performance metrics as not cached. Is there some change in text br/>>>>>>> you are suggesting??
>>>>>
>>>>>
>>>>> I would recommend to remove the 3rd bullet point completey. TCP br/>>>>>> isn't the place to rememmber "good&quo= t; or "bad" paths. This is br/>>>>>> something the network could decide, e.g., rerouting TCP flows br/>&ggt;&= gt;>>> within the network or changing the forwarding path in the network br/>>>&g= t;>> for particular flows (if it is not routed).
>>>>
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd br/>>>&g= t;> bullet point.=C2=A0Willl update in next rev - coming shortly.
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> =C2=A0Martin
>>>>>
>>>> 




__________________________________________=
_____
Tsv-art mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art



--0000000000000cfa830574f5db7f-- From nobody Mon Sep 3 05:07:00 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3303A130E0C; Mon, 3 Sep 2018 05:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HD3IWTOq0jqV; Mon, 3 Sep 2018 05:06:53 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DE412F1A2; Mon, 3 Sep 2018 05:06:53 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 423pbv31ypz2ykx; Mon, 3 Sep 2018 14:06:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 423pbv1yfWz3wbB; Mon, 3 Sep 2018 14:06:51 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0408.000; Mon, 3 Sep 2018 14:06:50 +0200 From: To: "spring@ietf.org" CC: "draft-ietf-isis-mpls-elc@ietf.org" , "lsr@ietf.org" Thread-Topic: Entropy label for SR-MPLS Thread-Index: AdRDfmJEvDXqHVCdQUmNMYMho3GQxA== Date: Mon, 3 Sep 2018 12:06:50 +0000 Message-ID: <15634_1535976411_5B8D23DB_15634_337_1_53C29892C857584299CBF5D05346208A47B2DCFC@OPEXCLILM21.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.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47B2DCFCOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] Entropy label for SR-MPLS X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 12:06:55 -0000 --_000_53C29892C857584299CBF5D05346208A47B2DCFCOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SPRING WG, draft-ietf-isis-mpls-elc defines an IS-IS extension to allow the use of MPL= S entropy labels in SR-MPLS networks. https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05 As a reminder, entropy label has been defined in RFC 6790 by the MPLS WG. I= t improves load-balancing / allows the effective use of parallel paths. It = requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As s= egment routing does not uses LDP nor RSVP-TE, an IGP extension is indeed re= quired. https://tools.ietf.org/html/rfc6790 As of today (-05) the IGP encoding chosen by draft-ietf-isis-mpls-elc: - may support inter-area/level deployments, albeit with additional complexi= ty (currently not specified) - does not support inter-AS and inter-protocol deployments. (Inter-protocol= being the redistribution of prefixes/segments from a protocol (instance) t= o another IGP protocol (instance)) Following some discussions, this restriction is not an IGP technical issue = as it would be easy to allow for this feature by using a different IGP enco= ding. It's a question of requirements so it would be better discussed in th= e SPRING WG. I'd like to see a discussion on whether this restriction is a good or a bad= thing from a SPRING requirement standpoint. In other words, do we want to allow (or not) the use of entropy label in in= ter-AS and inter-protocol deployments or do we accept this regression compa= red to LDP and RSVP-TE? Thanks, Regards, --Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A47B2DCFCOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi SPRING WG,

 

draft-ietf-isis-mpls-elc d= efines an IS-IS extension to allow the use of MPLS entropy labels in SR-MPL= S networks.

https://tools.ietf.org/html/draft= -ietf-isis-mpls-elc-05

 

As a reminder, entropy lab= el has been defined in RFC 6790 by the MPLS WG. It improves load-balancing = / allows the effective use of parallel paths. It requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As segment r= outing does not uses LDP nor RSVP-TE, an IGP extension is indeed required. https://tools.ietf.org/html= /rfc6790

 

As of today (-05) the IGP = encoding chosen by draft-ietf-isis-mpls-elc:

- may support inter-area/l= evel deployments, albeit with additional complexity (currently not specifie= d)

- does not support inter-A= S and inter-protocol deployments. (Inter-protocol being the redistribution = of prefixes/segments from a protocol (instance) to another IGP protocol (instance))

 

Following some discussions= , this restriction is not an IGP technical issue as it would be easy to all= ow for this feature by using a different IGP encoding. It’s a question of requirements so it would be better discussed in the SPRING W= G.

 

I’d like to see a di= scussion on whether this restriction is a good or a bad thing from a SPRING= requirement standpoint.

In other words, do we want= to allow (or not) the use of entropy label in inter-AS and inter-protocol = deployments or do we accept this regression compared to LDP and RSVP-TE?

 

Thanks,<= /p>

Regards,=

--Bruno<= /p> 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A47B2DCFCOPEXCLILM21corp_-- From nobody Mon Sep 3 05:37:38 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED510130E2F; Mon, 3 Sep 2018 05:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EdmhWqLa8ncC; Mon, 3 Sep 2018 05:37:34 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.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 47E6F126CC7; Mon, 3 Sep 2018 05:37:34 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 423qHJ5HRZz5vlc; Mon, 3 Sep 2018 14:37:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 423qHJ4J3ZzDq7S; Mon, 3 Sep 2018 14:37:32 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0408.000; Mon, 3 Sep 2018 14:37:32 +0200 From: To: "spring@ietf.org" CC: "lsr@ietf.org" , "draft-ietf-isis-mpls-elc@ietf.org" Thread-Topic: Entropy label for SR-MPLS Thread-Index: AdRDfmJEvDXqHVCdQUmNMYMho3GQxAAAE49g Date: Mon, 3 Sep 2018 12:37:32 +0000 Message-ID: <3479_1535978252_5B8D2B0C_3479_321_1_53C29892C857584299CBF5D05346208A47B2DE61@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <15634_1535976411_5B8D23DB_15634_337_1_53C29892C857584299CBF5D05346208A47B2DCFC@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15634_1535976411_5B8D23DB_15634_337_1_53C29892C857584299CBF5D05346208A47B2DCFC@OPEXCLILM21.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.4] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47B2DE61OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Entropy label for SR-MPLS X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 12:37:37 -0000 --_000_53C29892C857584299CBF5D05346208A47B2DE61OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Speaking as an individual contributor and a service provider, 1) ELC (Entropy Label Capability) I support the ability to use entropy label and hence advertise ELC (Entropy= Label Capability) inter-AS and inter-protocol deployments - In Orange we do have both inter-area/level and inter-AS w/ inter-protocol= deployments, in particular for the support of MPLS VPNs across ASes. - I don't see a reason to introduce such limitation to segment routing (com= pared to LDP & RSVP-TE) especially as this feature could easily be supporte= d by the IGP extension. 2) ERLD (Entropy Readable Label Depth) On a side note, as the draft also defines the IGP extension to advertise ER= LD (Entropy Readable Label Depth) I don't think that we (equally) need to p= ropagate ELRD advertisement between areas/levels/ASes/protocols as: - ELC advertisement is a MUST while ERLD is both only nice to have and only= required for SR-policies with "many" labels, which should be the minority = in most deployments - ELC only requires the advertisement of a flag per segment/prefix which ca= n easily be propagated between IGP topologies. While the use of ERLD requir= es the knowledge of the IGP topology, which by definition is not available = in inter-area/level/AS/protocol scenarios. I see two main cases of the use of ERLD in inter AS scenario: - along the shortest path: in this case, only one or two labels= /SIDs is required hence ERLD is not a concern. (Note that this applies to a= ny type of metric and to Flex Algo) - along a TE/specific path: in this case, the computation of th= e path requires the knowledge of the topology along the path, hence the LSD= B of both ASes. It would typically be performed by a PCE rather than the in= gress node (although the ingress could also learn the remote topology, e.g.= with BGP-LS) In summary, in both cases there is no need to propagate the ERLC between LS= DB Thanks, Regards, --Bruno From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.= com Sent: Monday, September 03, 2018 2:07 PM To: spring@ietf.org Cc: lsr@ietf.org; draft-ietf-isis-mpls-elc@ietf.org Subject: [Lsr] Entropy label for SR-MPLS Hi SPRING WG, draft-ietf-isis-mpls-elc defines an IS-IS extension to allow the use of MPL= S entropy labels in SR-MPLS networks. https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05 As a reminder, entropy label has been defined in RFC 6790 by the MPLS WG. I= t improves load-balancing / allows the effective use of parallel paths. It = requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As s= egment routing does not uses LDP nor RSVP-TE, an IGP extension is indeed re= quired. https://tools.ietf.org/html/rfc6790 As of today (-05) the IGP encoding chosen by draft-ietf-isis-mpls-elc: - may support inter-area/level deployments, albeit with additional complexi= ty (currently not specified) - does not support inter-AS and inter-protocol deployments. (Inter-protocol= being the redistribution of prefixes/segments from a protocol (instance) t= o another IGP protocol (instance)) Following some discussions, this restriction is not an IGP technical issue = as it would be easy to allow for this feature by using a different IGP enco= ding. It's a question of requirements so it would be better discussed in th= e SPRING WG. I'd like to see a discussion on whether this restriction is a good or a bad= thing from a SPRING requirement standpoint. In other words, do we want to allow (or not) the use of entropy label in in= ter-AS and inter-protocol deployments or do we accept this regression compa= red to LDP and RSVP-TE? Thanks, Regards, --Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A47B2DE61OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Speaking as an= individual contributor and a service provider,

 

1) ELC (Entrop= y Label Capability)

I support the = ability to use entropy label and hence advertise ELC (Entropy Label Capabil= ity) inter-AS and inter-protocol deployments

- In Orange we= do have both inter-area/level and inter-AS w/ inter-protocol deployments, = in particular for the support of MPLS VPNs across ASes.

- I don’= t see a reason to introduce such limitation to segment routing (compared to= LDP & RSVP-TE) especially as this feature could easily be supported by the IGP extension.

 

2) ERLD (Entro= py Readable Label Depth)

On a side note= , as the draft also defines the IGP extension to advertise ERLD (Entropy Re= adable Label Depth) I don’t think that we (equally) need to propagate ELRD advertisement between areas/levels/ASes/protocols as:<= /o:p>

- ELC advertis= ement is a MUST while ERLD is both only nice to have and only required for = SR-policies with “many” labels, which should be the minority in most deployments

- ELC only req= uires the advertisement of a flag per segment/prefix which can easily be pr= opagated between IGP topologies. While the use of ERLD requires the knowledge of the IGP topology, which by definition is not available in= inter-area/level/AS/protocol scenarios.

  I see t= wo main cases of the use of ERLD in inter AS scenario:

  &n= bsp;         - along the shortest p= ath: in this case, only one or two labels/SIDs is required hence ERLD is no= t a concern. (Note that this applies to any type of metric and to Flex Algo)

  &n= bsp;         - along a TE/specific = path: in this case, the computation of the path requires the knowledge of t= he topology along the path, hence the LSDB of both ASes. It would typically be performed by a PCE rather than th= e ingress node (although the ingress could also learn the remote topology, = e.g. with BGP-LS)

In summary, in both cases there is no need to propagate the = ERLC between LSDB

 

Thanks,<= /p>

Regards,=

--Bruno<= /p>

 

 

 

From:<= /b> Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Monday, September 03, 2018 2:07 PM
To: spring@ietf.org
Cc: lsr@ietf.org; draft-ietf-isis-mpls-elc@ietf.org
Subject: [Lsr] Entropy label for SR-MPLS

 

Hi SPRING WG,

 

draft-ietf-isis-mpls-elc d= efines an IS-IS extension to allow the use of MPLS entropy labels in SR-MPL= S networks.

https://tools.ietf.org/html/draft= -ietf-isis-mpls-elc-05

 

As a reminder, entropy lab= el has been defined in RFC 6790 by the MPLS WG. It improves load-balancing = / allows the effective use of parallel paths. It requires a signaling and RFC 6790 defined it for LDP, RSVP-TE and BGP. As segment r= outing does not uses LDP nor RSVP-TE, an IGP extension is indeed required. https://tools.ietf.org/html= /rfc6790

 

As of today (-05) the IGP = encoding chosen by draft-ietf-isis-mpls-elc:

- may support inter-area/l= evel deployments, albeit with additional complexity (currently not specifie= d)

- does not support inter-A= S and inter-protocol deployments. (Inter-protocol being the redistribution = of prefixes/segments from a protocol (instance) to another IGP protocol (instance))

 

Following some discussions= , this restriction is not an IGP technical issue as it would be easy to all= ow for this feature by using a different IGP encoding. It’s a question of requirements so it would be better discussed in the SPRING W= G.

 

I’d like to see a di= scussion on whether this restriction is a good or a bad thing from a SPRING= requirement standpoint.

In other words, do we want= to allow (or not) the use of entropy label in inter-AS and inter-protocol = deployments or do we accept this regression compared to LDP and RSVP-TE?

 

Thanks,<= /p>

Regards,=

--Bruno<= /p> 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A47B2DE61OPEXCLILM21corp_-- From nobody Thu Sep 6 08:48:30 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1FC130EA7; Thu, 6 Sep 2018 08:48:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, robjs@google.com, draft-ietf-spring-segment-routing-ldp-interop@ietf.org, Rob Shakir , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153624889704.11633.13485233801237660858.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2018 08:48:17 -0700 Archived-At: Subject: [spring] Protocol Action: 'Segment Routing interworking with LDP' to Proposed Standard (draft-ietf-spring-segment-routing-ldp-interop-15.txt) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 15:48:17 -0000 The IESG has approved the following document: - 'Segment Routing interworking with LDP' (draft-ietf-spring-segment-routing-ldp-interop-15.txt) as Proposed Standard This document is the product of the Source Packet Routing in Networking Working Group. The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ Technical Summary This document describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. Working Group Summary The WG supports the progress of this Document towards its publication as a Proposed Standard RFC. Document Quality The Document is well written. There are known implementations. Personnel Rob Shakir is the Document Shepherd Alvaro Retana is the Responsible AD From nobody Fri Sep 7 01:53:32 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3714F12426A; Fri, 7 Sep 2018 01:53:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: martin.vigoureux@nokia.com, spring@ietf.org, spring-chairs@ietf.org, bruno.decraene@orange.com X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153631041118.28963.12258591598696442027.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2018 01:53:31 -0700 Archived-At: Subject: [spring] spring - New Meeting Session Request for IETF 103 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 08:53:31 -0000 A new meeting session request has just been submitted by Bruno Decraene, a Chair of the spring working group. --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Bruno Decraene Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 180 Conflicts to Avoid: First Priority: mpls 6man lsr teas Second Priority: idr rtgarea rtgwg pce sfc detnet People who must be present: Bruno Decraene Martin Vigoureux Rob Shakir Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Sep 10 05:36:37 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40026130EBD; Mon, 10 Sep 2018 05:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 LeRsTLPTNpDY; Mon, 10 Sep 2018 05:36:32 -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 83549127B92; Mon, 10 Sep 2018 05:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28742; q=dns/txt; s=iport; t=1536582992; x=1537792592; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BBe4xfy2+ktX/PUos+I3GKgWnte8md5nt0OurMVtoB4=; b=D2Lnn99drSeR+lbNpHWZqPGaOZtVygYm5Gv+WU4yiepLRcDoKJ122E4M 8neXSUu8GMMruZTceVyoMbiaVbOztHN073GZHJhlJ+hOQE7BJTGAAyTj5 G9tiJwWeb4vU5715IyIfLBWsK27c4MsmQwhz4aLhXsTYSnrpMSmXKPagg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AABxZJZb/5NdJa1SChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGCV0gvZX8oCoNoiBOMHoFoJZY0gXoLJ4EvAYMVAheDYiE?= =?us-ascii?q?0GAECAQECAQECbRwMhTgBAQEBAyNEEhACAQgRAwEBASEHAwICAjAUCQgCBA4?= =?us-ascii?q?FgyEBgR1kD6RQgS4fhA8BPYUJBYplF4FBP4ESJwwTgkyCdyQCAwGBMkIJFoJ?= =?us-ascii?q?LMYImAogmhQyFYYh1CQKGN4lJF45wizqILAIRFIElHTiBVXAVZQGCQYsVhT5?= =?us-ascii?q?vjHuBHQEB?= X-IronPort-AV: E=Sophos;i="5.53,355,1531785600"; d="scan'208,217";a="232185009" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2018 12:36:30 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w8ACaUiP031303 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Sep 2018 12:36:30 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Sep 2018 07:36:30 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1395.000; Mon, 10 Sep 2018 07:36:30 -0500 From: "Rakesh Gandhi (rgandhi)" To: Mach Chen CC: "ippm@ietf.org" , spring Thread-Topic: New Draft draft-gandhi-spring-udp-pm Thread-Index: AQHUHdYWIyzVjAdRVki/QCU1ZO1Y+aSdv1EAgEwbkYA= Date: Mon, 10 Sep 2018 12:36:30 +0000 Message-ID: References: <92ED16BE-ACDF-4901-91B5-BC39A744C2F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.181.86] Content-Type: multipart/alternative; boundary="_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] New Draft draft-gandhi-spring-udp-pm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 12:36:35 -0000 --_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1hY2ggZm9yIHRoZSBjb21tZW50cy4gV2Ugd2lsbCBhZGQgZm9sbG93aW5nIFRMViBp biB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuDQoNCg0KMy4xLjIuMS4gIEJsb2NrIE51 bWJlciBUTFYNCg0KICAgVGhlIExvc3MgTWVhc3VyZW1lbnQgdXNpbmcgQWx0ZXJuYXRlLU1hcmtp bmcgbWV0aG9kIGRlZmluZWQgaW4NCiAgIFtSRkM4MzIxXSByZXF1aXJlcyB0byBpZGVudGlmeSB0 aGUgQmxvY2sgTnVtYmVyIChjb2xvdXIpIG9mIHRoZQ0KICAgdHJhZmZpYyBjb3VudGVycyBjYXJy aWVkIGJ5IHRoZSBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMuDQogICBQcm9iZSBx dWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgc3BlY2lmaWVkIGluIFtSRkM2Mzc0XSBmb3IgTG9z cw0KICAgTWVhc3VyZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8gY2FycnkgdGhlIEJs b2NrIE51bWJlci4NCg0KICAgW1JGQzYzNzRdIGRlZmluZXMgcHJvYmUgcXVlcnkgYW5kIHJlc3Bv bnNlIG1lc3NhZ2VzIHRoYXQgY2FuIGluY2x1ZGUNCiAgIG9uZSBvciBtb3JlIG9wdGlvbmFsIFRM VnMuICBOZXcgVExWIFR5cGUgKHZhbHVlIFRCQTgpIGlzIGRlZmluZWQgaW4NCiAgIHRoaXMgZG9j dW1lbnQgdG8gY2FycnkgQmxvY2sgTnVtYmVyICgzMi1iaXQpIGZvciB0aGUgdHJhZmZpYyBjb3Vu dGVycw0KICAgaW4gdGhlIHByb2JlIHF1ZXJ5IGFuZCByZXNwb25zZSBtZXNzYWdlcyBmb3IgbG9z cyBtZWFzdXJlbWVudC4gIFRoZQ0KICAgZm9ybWF0IG9mIHRoZSBCbG9jayBOdW1iZXIgVExWIGlz IHNob3duIGluIEZpZ3VyZSAxMToNCg0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgIHwgICBUeXBlIFRCQTcgICB8ICAgIExlbmd0aCAgICAgfCAgICAgIFJlc2VydmVkICAg ICAgICAgICAgICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICBCbG9jayBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDExOiBCbG9jayBOdW1iZXIgVExWDQoNCiAg IFRoZSBCbG9jayBOdW1iZXIgVExWIGlzIG9wdGlvbmFsLiAgVGhlIFBNIHF1ZXJpZXIgbm9kZSBT SE9VTEQgb25seQ0KICAgaW5zZXJ0IG9uZSBCbG9jayBOdW1iZXIgVExWIGluIHRoZSBwcm9iZSBx dWVyeSBtZXNzYWdlIGFuZCB0aGUNCiAgIHJlc3BvbmRlciBub2RlIGluIHRoZSBwcm9iZSByZXNw b25zZSBtZXNzYWdlIFNIT1VMRCByZXR1cm4gdGhlIGZpcnN0DQogICBCbG9jayBOdW1iZXIgVExW IGZyb20gdGhlIHByb2JlIHF1ZXJ5IG1lc3NhZ2VzIGFuZCBpZ25vcmUgb3RoZXIgQmxvY2sNCiAg IE51bWJlciBUTFZzIGlmIHByZXNlbnQuICBJbiBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVz c2FnZXMsIHRoZQ0KICAgY291bnRlcnMgTVVTVCBiZWxvbmcgdG8gdGhlIHNhbWUgQmxvY2sgTnVt YmVyLg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0KRnJvbTogTWFjaCBDaGVuIDxtYWNoLmNo ZW5AaHVhd2VpLmNvbT4NCkRhdGU6IE1vbmRheSwgSnVseSAyMywgMjAxOCBhdCAxMTozMSBQTQ0K VG86ICI9U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20iIDxyZ2FuZGhpQGNpc2NvLmNvbT4NCkNjOiAi aXBwbUBpZXRmLm9yZyIgPGlwcG1AaWV0Zi5vcmc+LCBzcHJpbmcgPHNwcmluZ0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhpLXNwcmluZy11ZHAtcG0NCg0KSGkg QXV0aG9ycywNCg0KVGhlIGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtLTAxIGRlZmluZXMgYSBu ZXcgQyBmbGFnIGFzIGZvbGxvd2luZzoNCg0KMy4xLjIuMS4gIExvc3MgTWVhc3VyZW1lbnQgRmxh Z3MNCg0KICAgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERhdGEgRm9ybWF0IEZsYWdzIChERmxhZ3Mp IGFzIGRlZmluZWQgaW4NCiAgIFtSRkM2Mzc0XS4gIE5ldyBGbGFnIGlzIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudCBmb3IgQ29sb3IgKEMpIGluIHRoZQ0KICAgREZsYWdzIGZpZWxkIGFzIGZvbGxv d3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfFh8QnxDfDB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBEYXRhIEZvcm1hdCBG bGFncw0KDQogICBUaGUgRmxhZyBDIGluZGljYXRlcyB0aGUgQ29sb3Igb2YgdGhlIGNvdW50ZXJz IGluIHRoZSBMTSBwcm9iZQ0KICAgbWVzc2FnZSBbUkZDNjM3NF0gd2hlbiB1c2luZyBBbHRlcm5h dGUtTWFya2luZyBtZXRob2QgZGVmaW5lZCBpbg0KICAgW1JGQzgzMjFdLg0KLS0tLS0tLS0tLS0t LQ0KDQpBcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yIG9mIFtSRkM4MzIxXSwgY291bGQgeW91IGNv bnNpZGVyIHRvIGRlZmluZSBtb3JlIHRoYW4gb25lIGZsYWcgb3IgYSBUTFYgdG8gY2FycnkgQmxv Y2sgbnVtYmVyIGluc3RlYWQ/DQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KRnJvbTogaXBwbSBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJha2VzaCBHYW5kaGkg KHJnYW5kaGkpDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDk6NTcgUE0NClRvOiBpcHBt QGlldGYub3JnDQpTdWJqZWN0OiBbaXBwbV0gTmV3IERyYWZ0IGRyYWZ0LWdhbmRoaS1zcHJpbmct dWRwLXBtDQoNCkhpIFdHLA0KDQpXZSBsaWtlIHRvIGludHJvZHVjZSBmb2xsb3dpbmcgbmV3IGRy YWZ0IHRoYXQgd2FzIHByZXNlbnRlZCB0byBTUFJJTkcgV0cgeWVzdGVyZGF5Lg0KDQpUaGlzIGRy YWZ0IGRlZmluZXMgSVAvVURQIHBhdGggZm9yIHNlbmRpbmcgcHJvYmUgcXVlcnkgbWVzc2FnZXMg Zm9yIGRlbGF5IGFuZCBsb3NzIG1lYXN1cmVtZW50IHRoYXQgaXMgYWdub3N0aWNzIHRvIGRhdGEg cGxhbmUgKFNSLU1QTFMvU1J2Ni9JUCkgYW5kIGRvZXMgbm90IHJlcXVpcmUgdG8gYm9vdHN0cmFw IFBNIHNlc3Npb24uDQoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Z2FuZGhpLXNwcmluZy11ZHAtcG0vDQoNCllvdSBtYXkgZmluZCBwcmVzZW50YXRpb24gaW4gdGhl IGZvbGxvd2luZyBwYWNrYWdlIChpdCBpcyB0aGUgc2Vjb25kIGRyYWZ0KS4NCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlhbHMvc2xpZGVzLTEwMi1zcHJp bmctMTMtcGVyZm9ybWFuY2UtbWVhc3VyZW1lbnQtaW4tc3ItbmV0d29ya3MtMDANCg0KV2Ugd2Vs Y29tZSB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4NCg0KVGhhbmtzLA0KUmFrZXNoIChP biBiZWhhbGYgb2YgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzKQ0KDQo= --_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <354D19C367601E41B0C5F8B24FC3292D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1lOnAxOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjVwdDsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMwNDYzQzE7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uczENCgl7bXNvLXN0eWxlLW5hbWU6czE7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnAucDIsIGxpLnAyLCBkaXYucDIN Cgl7bXNvLXN0eWxlLW5hbWU6cDI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjcuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5w MywgbGkucDMsIGRpdi5wMw0KCXttc28tc3R5bGUtbmFtZTpwMzsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t c3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzIE1hY2ggZm9yIHRoZSBjb21tZW50cy4gV2Ug d2lsbCBhZGQgZm9sbG93aW5nIFRMViBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+My4xLjIuMS4m bmJzcDsgQmxvY2sgTnVtYmVyIFRMVjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBMb3NzIE1lYXN1cmVtZW50 IHVzaW5nIEFsdGVybmF0ZS1NYXJraW5nIG1ldGhvZCBkZWZpbmVkIGluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBbUkZD ODMyMV0gcmVxdWlyZXMgdG8gaWRlbnRpZnkgdGhlIEJsb2NrIE51bWJlciAoY29sb3VyKSBvZiB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHRyYWZmaWMgY291bnRlcnMgY2FycmllZCBieSB0aGUgcHJvYmUgcXVlcnkg YW5kIHJlc3BvbnNlIG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtQcm9iZSBxdWVyeSBhbmQgcmVz cG9uc2UgbWVzc2FnZXMgc3BlY2lmaWVkIGluIFtSRkM2Mzc0XSBmb3IgTG9zczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg TWVhc3VyZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8gY2FycnkgdGhlIEJsb2NrIE51 bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBbUkZDNjM3NF0gZGVmaW5lcyBwcm9iZSBxdWVyeSBhbmQgcmVz cG9uc2UgbWVzc2FnZXMgdGhhdCBjYW4gaW5jbHVkZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb25lIG9yIG1vcmUgb3B0 aW9uYWwgVExWcy4mbmJzcDsgTmV3IFRMViBUeXBlICh2YWx1ZSBUQkE4KSBpcyBkZWZpbmVkIGlu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyB0aGlzIGRvY3VtZW50IHRvIGNhcnJ5IEJsb2NrIE51bWJlciAoMzItYml0KSBm b3IgdGhlIHRyYWZmaWMgY291bnRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluIHRoZSBwcm9iZSBxdWVyeSBhbmQg cmVzcG9uc2UgbWVzc2FnZXMgZm9yIGxvc3MgbWVhc3VyZW1lbnQuJm5ic3A7IFRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgZm9ybWF0IG9mIHRoZSBCbG9jayBOdW1iZXIgVExWIGlzIHNob3duIGluIEZpZ3VyZSAxMTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IFR5cGUgVEJB NyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlbmd0aCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlc2VydmVkJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJs b2NrIE51bWJlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSAx MTogQmxvY2sgTnVtYmVyIFRMVjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBCbG9jayBOdW1iZXIgVExWIGlz IG9wdGlvbmFsLiZuYnNwOyBUaGUgUE0gcXVlcmllciBub2RlIFNIT1VMRCBvbmx5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBpbnNlcnQgb25lIEJsb2NrIE51bWJlciBUTFYgaW4gdGhlIHByb2JlIHF1ZXJ5IG1lc3NhZ2Ug YW5kIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgcmVzcG9uZGVyIG5vZGUgaW4gdGhlIHByb2JlIHJlc3BvbnNlIG1l c3NhZ2UgU0hPVUxEIHJldHVybiB0aGUgZmlyc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJsb2NrIE51bWJlciBUTFYg ZnJvbSB0aGUgcHJvYmUgcXVlcnkgbWVzc2FnZXMgYW5kIGlnbm9yZSBvdGhlciBCbG9jazxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgTnVtYmVyIFRMVnMgaWYgcHJlc2VudC4mbmJzcDsgSW4gcHJvYmUgcXVlcnkgYW5kIHJl c3BvbnNlIG1lc3NhZ2VzLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNvdW50ZXJzIE1VU1QgYmVsb25nIHRvIHRo ZSBzYW1lIEJsb2NrIE51bWJlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlJha2VzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1h Y2ggQ2hlbiAmbHQ7bWFjaC5jaGVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1v bmRheSwgSnVseSAyMywgMjAxOCBhdCAxMTozMSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PVNN VFA6cmdhbmRoaUBjaXNjby4gY29tJnF1b3Q7ICZsdDtyZ2FuZGhpQGNpc2NvLmNvbSZndDs8YnI+ DQo8Yj5DYzogPC9iPiZxdW90O2lwcG1AaWV0Zi5vcmcmcXVvdDsgJmx0O2lwcG1AaWV0Zi5vcmcm Z3Q7LCBzcHJpbmcgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UkU6IE5ldyBEcmFmdCBkcmFmdC1nYW5kaGktc3ByaW5nLXVkcC1wbTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgQXV0aG9ycyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5U aGUgZHJhZnQtZ2FuZGhpLXNwcmluZy11ZHAtcG0tMDEgZGVmaW5lcyBhIG5ldyBDIGZsYWcgYXMg Zm9sbG93aW5nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjMuMS4yLjEuJm5ic3A7IExvc3MgTWVhc3VyZW1lbnQg RmxhZ3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERh dGEgRm9ybWF0IEZsYWdzIChERmxhZ3MpIGFzIGRlZmluZWQgaW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgW1JGQzYzNzRdLiZuYnNwOyBOZXcgRmxhZyBpcyBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgZm9yIENvbG9yIChDKSBpbiB0aGU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgREZsYWdzIGZpZWxkIGFzIGZvbGxvd3Mu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxYfEJ8Q3wwfDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRhIEZvcm1hdCBGbGFn czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBUaGUgRmxhZyBDIGluZGljYXRlcyB0aGUgQ29s b3Igb2YgdGhlIGNvdW50ZXJzIGluIHRoZSBMTSBwcm9iZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtZXNzYWdlIFtSRkM2Mzc0XSB3aGVuIHVzaW5nIEFsdGVy bmF0ZS1NYXJraW5nIG1ldGhvZCBkZWZpbmVkIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IFtSRkM4MzIxXS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEIj4tLS0tLS0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+QXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQu MiBvZiBbUkZDODMyMV0sIGNvdWxkIHlvdSBjb25zaWRlciB0byBkZWZpbmUgbW9yZSB0aGFuIG9u ZSBmbGFnIG9yIGEgVExWIHRvIGNhcnJ5IEJsb2NrIG51bWJlciBpbnN0ZWFkPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5 N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5NYWNoPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gaXBwbSBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmFrZXNo IEdhbmRoaSAocmdhbmRoaSk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNywgMjAx OCA5OjU3IFBNPGJyPg0KPGI+VG86PC9iPiBpcHBtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtpcHBtXSBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhpLXNwcmluZy11ZHAtcG08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkhpIFdHLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5XZSBsaWtlIHRvIGlu dHJvZHVjZSBmb2xsb3dpbmcgbmV3IGRyYWZ0IHRoYXQgd2FzIHByZXNlbnRlZCB0byBTUFJJTkcg V0cgeWVzdGVyZGF5Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPlRoaXMgZHJhZnQgZGVmaW5lcyBJUC9VRFAgcGF0 aCBmb3Igc2VuZGluZyBwcm9iZSBxdWVyeSBtZXNzYWdlcyBmb3IgZGVsYXkgYW5kIGxvc3MgbWVh c3VyZW1lbnQgdGhhdCBpcyBhZ25vc3RpY3MgdG8gZGF0YSBwbGFuZSAoU1ItTVBMUy9TUnY2L0lQ KSBhbmQgZG9lcyBub3QgcmVxdWlyZSB0byBib290c3RyYXAgUE0gc2Vzc2lvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+ PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLXNw cmluZy11ZHAtcG0vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nYW5k aGktc3ByaW5nLXVkcC1wbS88L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Zb3UgbWF5IGZpbmQgcHJl c2VudGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgcGFja2FnZSAoaXQgaXMgdGhlIHNlY29uZCBkcmFm dCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy8xMDIvbWF0ZXJpYWxzL3NsaWRlcy0xMDItc3ByaW5nLTEzLXBlcmZvcm1hbmNlLW1lYXN1 cmVtZW50LWluLXNyLW5ldHdvcmtzLTAwIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTAyL21hdGVyaWFscy9zbGlkZXMtMTAyLXNwcmluZy0xMy1wZXJmb3JtYW5jZS1tZWFz dXJlbWVudC1pbi1zci1uZXR3b3Jrcy0wMDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+V2Ugd2VsY29tZSB5b3Vy IGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+VGhhbmtzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+UmFrZXNoIChPbiBiZWhhbGYgb2YgYXV0aG9ycyBhbmQgY29u dHJpYnV0b3JzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BB5CFE61A1824846B748FDBE7F10A3E7ciscocom_-- From nobody Mon Sep 10 06:04:56 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA566130E96; Mon, 10 Sep 2018 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rLl0jQOlgm9c; Mon, 10 Sep 2018 06:04:42 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 D45C5130E94; Mon, 10 Sep 2018 06:04:41 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id z11-v6so17345461lff.9; Mon, 10 Sep 2018 06:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wOI2AoC2u6mp/nMg/44rsyArmviGtBqYuthQDUQlto8=; b=R9Hg1DYkk+zZyfAHDqwjnJEVEfRNBgvosXp7mKuHk2TbIyrUAhdhlFpqaZFFIOOeDQ wQx6ZVxfXtXESAfhhVlm0FeAVHQ0h3AnVm/sWspZTP0G/2UNYOWJkT2vFC/gAmzoZQKN JBfc0Ul3oZTBh5+U39erggPN6mqCy+FTs45VnxwuJTPARlMtr04T0esEotMW7XDST9as Pe/iow9vEGxduq0ru7XUZ54H3ivoPG5FVffoB0UjRSyhFE8ESJMh1odYXi6U+i4YhmnN 4r1N1v6mCzHc5NSXB7rLOlsynChdnDy9Ykkif68sIjvq1/jqPQ+OW2NGQs9nA4IPR+hr +QnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wOI2AoC2u6mp/nMg/44rsyArmviGtBqYuthQDUQlto8=; b=gBCtekzX7VqfXNMbfLulDH/TZaTpHONWS2LJntqw7Q10KcnucwGoXxG/dPK63A5qoH z+76S1EdJ4BhCv+qVwBLRReuG+2pPv3hBI3d7z6ApSuDlXtQWA0a3r8Iy5yIuYqiC3mh bnuyrpX5N5nViX3UW/7+SE3mYuoz8mU0un4E+33rZPbg4V8IGd9hGqrOtAM2eAFNQmsl lgcFpbRhLMD6eR6XGPp5EAGaRRxw0obUUgWpfRIDzapx8TNJsNj8zjS1nrlEpT+E3YUE T29SAaJMPNWHotLWaRbXv6jT+DTwz7NWDL4cVG0+hEE3P5y0/Jwv39kGZuUHmWEOPeNY 6sFw== X-Gm-Message-State: APzg51CPDz2jCXVopq4YNzNkKue2zbUuegd7Ev67tr60nb/iw1jsujFy tFU2A7lhPE5jAemfB1fJXmHhWIN6frtiNf6OGA== X-Google-Smtp-Source: ANB0VdbBbLWP/yRC7GYpXR1JP5POQm0Ev0TyeAJ/8Ru1jZoqk4TD4n4RasMJ1rCWG8Dr3WZvZceyabRpaTrUZ6+1XaU= X-Received: by 2002:a19:4283:: with SMTP id p125-v6mr8293120lfa.104.1536584676903; Mon, 10 Sep 2018 06:04:36 -0700 (PDT) MIME-Version: 1.0 References: <92ED16BE-ACDF-4901-91B5-BC39A744C2F1@cisco.com> In-Reply-To: From: Rakesh Gandhi Date: Mon, 10 Sep 2018 09:04:25 -0400 Message-ID: To: Greg Mirsky Cc: rgandhi=40cisco.com@dmarc.ietf.org, spring@ietf.org, ippm@ietf.org Content-Type: multipart/alternative; boundary="000000000000d58fa3057583ff4e" Archived-At: Subject: Re: [spring] [ippm] New Draft draft-gandhi-spring-udp-pm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 13:04:46 -0000 --000000000000d58fa3057583ff4e Content-Type: text/plain; charset="UTF-8" Hi Greg, Thanks for your comments. We can add following summary in the draft for STAMP. Please advise if the text is correct. The Simple Two-way Active Measurement Protocol (STAMP) [I-D.ippm-stamp] extends TWAMP by alleviating control channel signaling to setup test channel and supports IEEE 1588 timestamp format. The STAMP defines mechanisms such as using the TCP port of control channel for test channel, using configuration data model to provision test channels and using responder node in reflector mode for two-way measurement. The TWAMP Light from broadband forum [BBF.TR-390] provides simplified mechanisms for active performance measurement in Customer Edge IP networks. Thanks, Rakesh On Tue, Jul 17, 2018 at 3:30 PM Greg Mirsky wrote: > Hi Rakesh, > thank you for bringing this draft up for discussion. There was not enough > time to ask questions at the SPRING WG meeting and this is a very good > opportunity. > I understand that you've proposed to use RFC 6374 to encode PM operations > and measurements.. Also, you've referenced work on OWAMP and TWAMP. But I > don't find any reference to STAMP > in the draft. How > would you position STAMP, its optional extensions > , and YANG > model in > comparison with your new draft? > > Regards, > Greg > > On Tue, Jul 17, 2018 at 6:57 AM, Rakesh Gandhi (rgandhi) < > rgandhi=40cisco.com@dmarc.ietf.org> wrote: > >> Hi WG, >> >> >> >> We like to introduce following new draft that was presented to SPRING WG >> yesterday. >> >> >> >> This draft defines IP/UDP path for sending probe query messages for delay >> and loss measurement that is agnostics to data plane (SR-MPLS/SRv6/IP) and >> does not require to bootstrap PM session. >> >> >> >> https://datatracker.ietf.org/doc/draft-gandhi-spring-udp-pm/ >> >> >> >> You may find presentation in the following package (it is the second >> draft). >> >> >> >> >> https://datatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-measurement-in-sr-networks-00 >> >> >> >> We welcome your comments and suggestions. >> >> >> >> Thanks, >> >> Rakesh (On behalf of authors and contributors) >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000d58fa3057583ff4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

Th= anks for your comments. We can add following summary in the draft for STAMP= . Please advise if the text is correct.

=C2=A0= The Simple Two-way Active Measurement Protocol (STAMP)
=C2=A0=C2=A0 [I-= D.ippm-stamp] extends TWAMP by alleviating control channel
=C2=A0=C2=A0 = signaling to setup test channel and supports IEEE 1588 timestamp
=C2=A0= =C2=A0 format.=C2=A0 The STAMP defines mechanisms such as using the TCP por= t of
=C2=A0=C2=A0 control channel for test channel, using configuration = data model to
=C2=A0=C2=A0 provision test channels and using responder n= ode in reflector mode
=C2=A0=C2=A0 for two-way measurement.=C2=A0 The TW= AMP Light from broadband forum
=C2=A0=C2=A0 [BBF.TR-390] provides simpli= fied mechanisms for active performance
=C2=A0=C2=A0 measurement in Custo= mer Edge IP networks.

Thanks,
Rakesh=


On Tue, Jul 17, 2018 at 3:30 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Rakesh,
thank you for bringin= g this draft up for discussion. There was not enough time to ask questions = at the SPRING WG meeting and this is a very good opportunity.=C2=A0
I understand that you've proposed to use RFC 6374 to encode PM opera= tions and measurements.. Also, you've referenced work on OWAMP and TWAM= P. But I don't find any reference to STAMP in the draft. Ho= w would you position STAMP, its optional extensions, and YANG model=C2=A0in comparison with your new draft?<= /div>

Regards,
Greg

On Tue, Jul 17, 2018 at 6:57 AM,= Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.i= etf.org> wrote:

Hi W= G,

<= /u>=C2=A0

We l= ike to introduce following new draft that was presented to SPRING WG yester= day.

<= /u>=C2=A0

This= draft defines IP/UDP path for sending probe query messages for delay and l= oss measurement that is agnostics to data plane (SR-MPLS/SRv6/IP) and does = not require to bootstrap PM session.

<= /u>=C2=A0

https://datatracker.ietf.org/doc/draft-gandhi-spring-= udp-pm/

<= /u>=C2=A0

You = may find presentation in the following package (it is the second draft).=

<= /u>=C2=A0

https://da= tatracker.ietf.org/meeting/102/materials/slides-102-spring-13-performance-m= easurement-in-sr-networks-00

<= /u>=C2=A0

We w= elcome your comments and suggestions.

<= /u>=C2=A0

Than= ks,

Rake= sh (On behalf of authors and contributors)

<= /u>=C2=A0


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


_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000d58fa3057583ff4e-- From nobody Mon Sep 10 09:25:18 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA2130F30; Mon, 10 Sep 2018 09:25:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: spring@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153659670001.26517.861627310390777605.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 09:25:00 -0700 Archived-At: Subject: [spring] WG Review: Source Packet Routing in Networking (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 16:25:10 -0000 The Source Packet Routing in Networking (spring) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-09-20. Source Packet Routing in Networking (spring) ----------------------------------------------------------------------- Current status: Active WG Chairs: Rob Shakir Bruno Decraene Assigned Area Director: Martin Vigoureux Routing Area Directors: Alvaro Retana Deborah Brungard Martin Vigoureux Mailing list: Address: spring@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spring Archive: https://mailarchive.ietf.org/arch/browse/spring/ Group page: https://datatracker.ietf.org/group/spring/ Charter: https://datatracker.ietf.org/doc/charter-ietf-spring/ The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). SPRING WG serves as a forum to discuss SPRING networks operations, define new applications of, and specify extensions of Segment Routing technologies. SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING WG defines procedures that allow a node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING nodes must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for other network applications. The scope of the SPRING WG work includes both single Autonomous System (AS) and multi-AS environments. Segment Routing typically operates within a single trust domain which requires the enforcement of a strict boundary and preventing Segment Routing packets from entering the trusted domain from the untrusted exterior. Certain deployments may however involve multiple trust domains which in turn may imply the use of cross/inter domain segments. Risk models associated with these various scenarios may necessitate the use of a cryptographic integrity checks to validate that the segment list is provided by an authorised entity. As is customary in the Routing Area, the SPRING WG will also identify and address any other security considerations introduced by the technologies it defines; addressing such considerations may require the introduction of new functionality in protocols leveraged for Source Routing, in which case the SPRING WG will formulate requirements to be considered by the appropriate WG for that work. SPRING technologies may be deployed in environments spanning a range of risk and threat models, which may impact both the security considerations and the requirements place on other protocols in order to support Source Routing protocols. The technologies SPRING WG defines may be applicable to both centralised and distributed path computation. The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director. The work-items of the SPRING WG include functional specifications for: o Segment Routing policies and the associated steering, signalling and traffic engineering mechanisms. o Source-routed stateless service chaining using SR-MPLS and SRv6 dataplanes. o SRv6 network programming for the underlay networks and overlay services, and including data plane behavior and functions associated with SIDs o Operation, Administration and Management (OAM), and traffic accounting in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Performance Management (PM) and monitoring in networks with SR-MPLS and SRv6 data planes in the case where SR introduces specificities compared to MPLS or IPv6 technologies. o Inter-working between SRv6 and SR-MPLS and between SR and existing routing solutions to allow for seamless deployment and co-existence. o New types of segments mapping to forwarding behaviour (e.g., local ingress replication, local forwarding resources, a pre-existing replication structure) if needed for new usages. Any of the above may require architectural extensions. The work-items of SPRING WG also include: o Specification of management models (YANG) for Segment Routing applications, services and networks with SR-MPLS and SRv6 dataplanes. The SPRING WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include (but may not be limited to): * mpls on the MPLS dataplane and OAM extensions, * 6man on the IPv6 dataplane for SR and associated OAM extensions * lsr on OSPF and IS-IS extensions to flood SPRING-related information * idr for BGP extensions * bess for VPN control plane * pce on extensions to communicate with an external entity to compute and program SPRING paths * teas on generic traffic engineering architecture * sfc on service chaining applications * rtgwg on fast-reroute technologies ----------------------------------------------------------------------- Milestones: SR-MPLS sent to IESG by October 2018 SR-MPLS configuration YANG model sent to IESG by December 2018 MPLS anycast sent to IESG by October 2018 SR-TE policy sent to IESG by SR policies YANG model sent to IESG by December 2019 SR-MPLS OAM sent to IESG by SR-MPLS Performance Measurement to IESG by SR-IPv6 OAM sent to IESG by Stateless service chaining with SR sent to IESG by SRv6 Network Programming to IESG by From nobody Mon Sep 10 18:12:35 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05A4130FF2; Mon, 10 Sep 2018 18:12:27 -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, 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 5mOVL6vL1MOe; Mon, 10 Sep 2018 18:12:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 83473130F34; Mon, 10 Sep 2018 18:12:26 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 00A62F0A362C3; Tue, 11 Sep 2018 02:12:24 +0100 (IST) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 11 Sep 2018 02:12:24 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0382.000; Tue, 11 Sep 2018 09:12:19 +0800 From: Mach Chen To: spring CC: "ippm@ietf.org" Thread-Topic: Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm Thread-Index: AdRJbGlD0dKzTMmeRKC4ZAeuWsJEag== Date: Tue, 11 Sep 2018 01:12:19 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 01:12:28 -0000 Hi Authors, =20 The draft-li-pce-sr-path-segment and draft-cheng-spring-mpls-path-segment d= efine the notion of path segment identifier. Could you please consider addi= ng some text in draft-gandhi-spring-udp-pm and draft-gandhi-spring-sr-mpls-= pm and how it is applicable to performance measurement in segment routing? =20 Best regards Mach From nobody Mon Sep 10 18:25:58 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F3113101C; Mon, 10 Sep 2018 18:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pa9DeQ4zNOFE; Mon, 10 Sep 2018 18:25:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 640E9131008; Mon, 10 Sep 2018 18:25:47 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E2BD8CACA80E7; Tue, 11 Sep 2018 02:09:33 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 11 Sep 2018 02:09:33 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0399.000; Tue, 11 Sep 2018 09:09:28 +0800 From: Mach Chen To: "Rakesh Gandhi (rgandhi)" CC: "ippm@ietf.org" , spring Thread-Topic: New Draft draft-gandhi-spring-udp-pm Thread-Index: AQHUHdYWIyzVjAdRVki/QCU1ZO1Y+aSdv1EAgEwbkYCAAMFW0A== Date: Tue, 11 Sep 2018 01:09:28 +0000 Message-ID: References: <92ED16BE-ACDF-4901-91B5-BC39A744C2F1@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] New Draft draft-gandhi-spring-udp-pm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 01:25:50 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFrZXNoLA0KDQpJdCBsb29rcyBnb29kIHRvIG1lLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNo DQoNCkZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIFttYWlsdG86cmdhbmRoaUBjaXNjby5j b21dDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxOCA4OjM3IFBNDQpUbzogTWFjaCBD aGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbT4NCkNjOiBpcHBtQGlldGYub3JnOyBzcHJpbmcgPHNw cmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhpLXNwcmlu Zy11ZHAtcG0NCg0KVGhhbmtzIE1hY2ggZm9yIHRoZSBjb21tZW50cy4gV2Ugd2lsbCBhZGQgZm9s bG93aW5nIFRMViBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuDQoNCg0KMy4xLjIu MS4gIEJsb2NrIE51bWJlciBUTFYNCg0KICAgVGhlIExvc3MgTWVhc3VyZW1lbnQgdXNpbmcgQWx0 ZXJuYXRlLU1hcmtpbmcgbWV0aG9kIGRlZmluZWQgaW4NCiAgIFtSRkM4MzIxXSByZXF1aXJlcyB0 byBpZGVudGlmeSB0aGUgQmxvY2sgTnVtYmVyIChjb2xvdXIpIG9mIHRoZQ0KICAgdHJhZmZpYyBj b3VudGVycyBjYXJyaWVkIGJ5IHRoZSBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMu DQogICBQcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMgc3BlY2lmaWVkIGluIFtSRkM2 Mzc0XSBmb3IgTG9zcw0KICAgTWVhc3VyZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8g Y2FycnkgdGhlIEJsb2NrIE51bWJlci4NCg0KICAgW1JGQzYzNzRdIGRlZmluZXMgcHJvYmUgcXVl cnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIHRoYXQgY2FuIGluY2x1ZGUNCiAgIG9uZSBvciBtb3Jl IG9wdGlvbmFsIFRMVnMuICBOZXcgVExWIFR5cGUgKHZhbHVlIFRCQTgpIGlzIGRlZmluZWQgaW4N CiAgIHRoaXMgZG9jdW1lbnQgdG8gY2FycnkgQmxvY2sgTnVtYmVyICgzMi1iaXQpIGZvciB0aGUg dHJhZmZpYyBjb3VudGVycw0KICAgaW4gdGhlIHByb2JlIHF1ZXJ5IGFuZCByZXNwb25zZSBtZXNz YWdlcyBmb3IgbG9zcyBtZWFzdXJlbWVudC4gIFRoZQ0KICAgZm9ybWF0IG9mIHRoZSBCbG9jayBO dW1iZXIgVExWIGlzIHNob3duIGluIEZpZ3VyZSAxMToNCg0KICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgIHwgICBUeXBlIFRCQTcgICB8ICAgIExlbmd0aCAgICAgfCAgICAg IFJlc2VydmVkICAgICAgICAgICAgICAgICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICBCbG9jayBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNCiAgICAgICAgICAgICAgICAgICAgRmlndXJlIDExOiBCbG9jayBOdW1i ZXIgVExWDQoNCiAgIFRoZSBCbG9jayBOdW1iZXIgVExWIGlzIG9wdGlvbmFsLiAgVGhlIFBNIHF1 ZXJpZXIgbm9kZSBTSE9VTEQgb25seQ0KICAgaW5zZXJ0IG9uZSBCbG9jayBOdW1iZXIgVExWIGlu IHRoZSBwcm9iZSBxdWVyeSBtZXNzYWdlIGFuZCB0aGUNCiAgIHJlc3BvbmRlciBub2RlIGluIHRo ZSBwcm9iZSByZXNwb25zZSBtZXNzYWdlIFNIT1VMRCByZXR1cm4gdGhlIGZpcnN0DQogICBCbG9j ayBOdW1iZXIgVExWIGZyb20gdGhlIHByb2JlIHF1ZXJ5IG1lc3NhZ2VzIGFuZCBpZ25vcmUgb3Ro ZXIgQmxvY2sNCiAgIE51bWJlciBUTFZzIGlmIHByZXNlbnQuICBJbiBwcm9iZSBxdWVyeSBhbmQg cmVzcG9uc2UgbWVzc2FnZXMsIHRoZQ0KICAgY291bnRlcnMgTVVTVCBiZWxvbmcgdG8gdGhlIHNh bWUgQmxvY2sgTnVtYmVyLg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0KRnJvbTogTWFjaCBD aGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+Pg0K RGF0ZTogTW9uZGF5LCBKdWx5IDIzLCAyMDE4IGF0IDExOjMxIFBNDQpUbzogIj1TTVRQOnJnYW5k aGlAY2lzY28uIGNvbSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNv bT4+DQpDYzogImlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+IiA8aXBwbUBpZXRm Lm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+LCBzcHJpbmcgPHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBOZXcgRHJhZnQgZHJhZnQtZ2FuZGhp LXNwcmluZy11ZHAtcG0NCg0KSGkgQXV0aG9ycywNCg0KVGhlIGRyYWZ0LWdhbmRoaS1zcHJpbmct dWRwLXBtLTAxIGRlZmluZXMgYSBuZXcgQyBmbGFnIGFzIGZvbGxvd2luZzoNCg0KMy4xLjIuMS4g IExvc3MgTWVhc3VyZW1lbnQgRmxhZ3MNCg0KICAgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERhdGEg Rm9ybWF0IEZsYWdzIChERmxhZ3MpIGFzIGRlZmluZWQgaW4NCiAgIFtSRkM2Mzc0XS4gIE5ldyBG bGFnIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBmb3IgQ29sb3IgKEMpIGluIHRoZQ0KICAg REZsYWdzIGZpZWxkIGFzIGZvbGxvd3MuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstKy0rLSstKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfFh8QnxDfDB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICBEYXRhIEZvcm1hdCBGbGFncw0KDQogICBUaGUgRmxhZyBDIGluZGljYXRlcyB0aGUg Q29sb3Igb2YgdGhlIGNvdW50ZXJzIGluIHRoZSBMTSBwcm9iZQ0KICAgbWVzc2FnZSBbUkZDNjM3 NF0gd2hlbiB1c2luZyBBbHRlcm5hdGUtTWFya2luZyBtZXRob2QgZGVmaW5lZCBpbg0KICAgW1JG QzgzMjFdLg0KLS0tLS0tLS0tLS0tLQ0KDQpBcyBkZWZpbmVkIGluIFNlY3Rpb24gNC4yIG9mIFtS RkM4MzIxXSwgY291bGQgeW91IGNvbnNpZGVyIHRvIGRlZmluZSBtb3JlIHRoYW4gb25lIGZsYWcg b3IgYSBUTFYgdG8gY2FycnkgQmxvY2sgbnVtYmVyIGluc3RlYWQ/DQoNCkJlc3QgcmVnYXJkcywN Ck1hY2gNCg0KRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE3LCAy MDE4IDk6NTcgUE0NClRvOiBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KU3Vi amVjdDogW2lwcG1dIE5ldyBEcmFmdCBkcmFmdC1nYW5kaGktc3ByaW5nLXVkcC1wbQ0KDQpIaSBX RywNCg0KV2UgbGlrZSB0byBpbnRyb2R1Y2UgZm9sbG93aW5nIG5ldyBkcmFmdCB0aGF0IHdhcyBw cmVzZW50ZWQgdG8gU1BSSU5HIFdHIHllc3RlcmRheS4NCg0KVGhpcyBkcmFmdCBkZWZpbmVzIElQ L1VEUCBwYXRoIGZvciBzZW5kaW5nIHByb2JlIHF1ZXJ5IG1lc3NhZ2VzIGZvciBkZWxheSBhbmQg bG9zcyBtZWFzdXJlbWVudCB0aGF0IGlzIGFnbm9zdGljcyB0byBkYXRhIHBsYW5lIChTUi1NUExT L1NSdjYvSVApIGFuZCBkb2VzIG5vdCByZXF1aXJlIHRvIGJvb3RzdHJhcCBQTSBzZXNzaW9uLg0K DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdhbmRoaS1zcHJpbmct dWRwLXBtLw0KDQpZb3UgbWF5IGZpbmQgcHJlc2VudGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgcGFj a2FnZSAoaXQgaXMgdGhlIHNlY29uZCBkcmFmdCkuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL3NsaWRlcy0xMDItc3ByaW5nLTEzLXBlcmZvcm1h bmNlLW1lYXN1cmVtZW50LWluLXNyLW5ldHdvcmtzLTAwDQoNCldlIHdlbGNvbWUgeW91ciBjb21t ZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNClRoYW5rcywNClJha2VzaCAoT24gYmVoYWxmIG9mIGF1 dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycykNCg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLnAxLCBsaS5wMSwgZGl2LnAxDQoJe21zby1zdHlsZS1uYW1lOnAxOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjVwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDQ2M0MxO30NCnAucDIsIGxp LnAyLCBkaXYucDINCgl7bXNvLXN0eWxlLW5hbWU6cDI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjcuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KcC5wMywgbGkucDMsIGRpdi5wMw0KCXttc28tc3R5bGUtbmFtZTpwMzsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLnMxDQoJe21zby1zdHlsZS1uYW1lOnMxOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj5IaSBSYWtlc2gsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkl0IGxvb2tzIGdvb2QgdG8gbWUuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkJl c3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPk1hY2g8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwv Zm9udD48L2I+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBS YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSBbbWFpbHRvOnJnYW5kaGlAY2lzY28uY29tXQ0KPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gTW9uZGF5 LCBTZXB0ZW1iZXIgMTAsIDIwMTggODozNyBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBNYWNoIENoZW4gJmx0O21hY2guY2hlbkBodWF3ZWku Y29tJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L3NwYW4+ PC9iPiBpcHBtQGlldGYub3JnOyBzcHJpbmcgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTog TmV3IERyYWZ0IGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U aGFua3MgTWFjaCBmb3IgdGhlIGNvbW1lbnRzLiBXZSB3aWxsIGFkZCBmb2xsb3dpbmcgVExWIGlu IHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+My4xLjIuMS4mbmJzcDsgQmxvY2sgTnVtYmVyIFRMVjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGUgTG9zcyBNZWFzdXJlbWVu dCB1c2luZyBBbHRlcm5hdGUtTWFya2luZyBtZXRob2QgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBbUkZDODMyMV0gcmVxdWlyZXMg dG8gaWRlbnRpZnkgdGhlIEJsb2NrIE51bWJlciAoY29sb3VyKSBvZiB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdHJhZmZpYyBjb3VudGVycyBj YXJyaWVkIGJ5IHRoZSBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7UHJvYmUgcXVl cnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIHNwZWNpZmllZCBpbiBbUkZDNjM3NF0gZm9yIExvc3M8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTWVhc3Vy ZW1lbnQgZG8gbm90IGRlZmluZSBhbnkgbWVhbnMgdG8gY2FycnkgdGhlIEJsb2NrIE51bWJlci48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgW1JGQzYzNzRdIGRlZmluZXMg cHJvYmUgcXVlcnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIHRoYXQgY2FuIGluY2x1ZGU8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb25lIG9yIG1vcmUg b3B0aW9uYWwgVExWcy4mbmJzcDsgTmV3IFRMViBUeXBlICh2YWx1ZSBUQkE4KSBpcyBkZWZpbmVk IGluPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRo aXMgZG9jdW1lbnQgdG8gY2FycnkgQmxvY2sgTnVtYmVyICgzMi1iaXQpIGZvciB0aGUgdHJhZmZp YyBjb3VudGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBpbiB0aGUgcHJvYmUgcXVlcnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIGZvciBsb3NzIG1l YXN1cmVtZW50LiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgZm9ybWF0IG9mIHRoZSBCbG9jayBOdW1iZXIgVExWIGlzIHNob3duIGlu IEZpZ3VyZSAxMTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsg MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBUeXBlIFRCQTcmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBMZW5ndGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNlcnZlZCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQmxvY2sgTnVtYmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO3w8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRmlndXJlIDExOiBCbG9jayBOdW1iZXIgVExWPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBCbG9jayBOdW1iZXIgVExWIGlzIG9wdGlvbmFs LiZuYnNwOyBUaGUgUE0gcXVlcmllciBub2RlIFNIT1VMRCBvbmx5PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluc2VydCBvbmUgQmxvY2sgTnVtYmVy IFRMViBpbiB0aGUgcHJvYmUgcXVlcnkgbWVzc2FnZSBhbmQgdGhlPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlc3BvbmRlciBub2RlIGluIHRoZSBw cm9iZSByZXNwb25zZSBtZXNzYWdlIFNIT1VMRCByZXR1cm4gdGhlIGZpcnN0PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEJsb2NrIE51bWJlciBUTFYg ZnJvbSB0aGUgcHJvYmUgcXVlcnkgbWVzc2FnZXMgYW5kIGlnbm9yZSBvdGhlciBCbG9jazxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBOdW1iZXIgVExW cyBpZiBwcmVzZW50LiZuYnNwOyBJbiBwcm9iZSBxdWVyeSBhbmQgcmVzcG9uc2UgbWVzc2FnZXMs IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBj b3VudGVycyBNVVNUIGJlbG9uZyB0byB0aGUgc2FtZSBCbG9jayBOdW1iZXIuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UmFrZXNoPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNp emU9IjMiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2s7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250IGNvbG9yPSJibGFjayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NYWNo IENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbSI+bWFjaC5jaGVu QGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5EYXRlOiA8L3NwYW4+PC9iPk1vbmRheSwgSnVseSAyMywgMjAxOCBhdCAxMTozMSBQTTxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPjwvYj4mcXVvdDs9 U01UUDpyZ2FuZGhpQGNpc2NvLiBjb20mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyZ2FuZGhp QGNpc2NvLmNvbSI+cmdhbmRoaUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPjwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPiZndDssIHNwcmluZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPjwvYj5SRTog TmV3IERyYWZ0IGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgQXV0aG9ycyw8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhlIGRy YWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtLTAxIGRlZmluZXMgYSBuZXcgQyBmbGFnIGFzIGZvbGxv d2luZzo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+My4xLjIuMS4mbmJzcDsgTG9zcyBNZWFzdXJlbWVudCBGbGFnczwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsgQW4gTE0gbWVzc2FnZSBjYXJyaWVzIERhdGEgRm9ybWF0IEZsYWdzIChERmxh Z3MpIGFzIGRlZmluZWQgaW48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyBbUkZDNjM3NF0uJm5ic3A7IE5ldyBGbGFnIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBm b3IgQ29sb3IgKEMpIGluIHRoZTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IERGbGFncyBmaWVsZCBhcyBmb2xsb3dzLjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0Mzs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8WHxCfEN8MHw8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Ozwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0YSBGb3JtYXQg RmxhZ3M8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFRoZSBGbGFnIEMgaW5kaWNhdGVzIHRoZSBDb2xvciBv ZiB0aGUgY291bnRlcnMgaW4gdGhlIExNIHByb2JlPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgbWVzc2FnZSBbUkZDNjM3NF0gd2hlbiB1c2luZyBBbHRlcm5hdGUtTWFy a2luZyBtZXRob2QgZGVmaW5lZCBpbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IFtSRkM4MzIxXS48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPi0tLS0tLS0tLS0t LS08L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RCI+QXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMiBvZiBbUkZDODMyMV0sIGNvdWxkIHlv dSBjb25zaWRlciB0byBkZWZpbmUgbW9yZSB0aGFuIG9uZSBmbGFnIG9yIGEgVExWIHRvIGNhcnJ5 IEJsb2NrIG51bWJlciBpbnN0ZWFkPzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEIj5NYWNoPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gaXBwbSBbPGEgaHJlZj0ibWFpbHRvOmlwcG0t Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mIDwvc3Bhbj48L2I+UmFr ZXNoIEdhbmRoaSAocmdhbmRoaSk8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U2VudDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKdWx5IDE3LCAyMDE4IDk6NTcgUE08YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gPGEgaHJlZj0i bWFpbHRvOmlwcG1AaWV0Zi5vcmciPmlwcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gW2lwcG1dIE5ldyBEcmFm dCBkcmFmdC1nYW5kaGktc3ByaW5nLXVkcC1wbTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSI0 IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPkhpIFdHLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldlIGxpa2UgdG8gaW50cm9k dWNlIGZvbGxvd2luZyBuZXcgZHJhZnQgdGhhdCB3YXMgcHJlc2VudGVkIHRvIFNQUklORyBXRyB5 ZXN0ZXJkYXkuDQo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5UaGlzIGRyYWZ0IGRlZmlu ZXMgSVAvVURQIHBhdGggZm9yIHNlbmRpbmcgcHJvYmUgcXVlcnkgbWVzc2FnZXMgZm9yIGRlbGF5 IGFuZCBsb3NzIG1lYXN1cmVtZW50IHRoYXQgaXMgYWdub3N0aWNzIHRvIGRhdGEgcGxhbmUgKFNS LU1QTFMvU1J2Ni9JUCkgYW5kIGRvZXMgbm90IHJlcXVpcmUNCiB0byBib290c3RyYXAgUE0gc2Vz c2lvbi48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9InAxIj48c3BhbiBjbGFzcz0iczEiPjx1Pjxmb250IHNpemU9IjQiIGNvbG9yPSIjMDQ2 M2MxIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2FuZGhpLXNwcmluZy11 ZHAtcG0vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1nYW5kaGktc3By aW5nLXVkcC1wbS88L2E+PC9zcGFuPjwvZm9udD48L3U+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iNCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Z b3UgbWF5IGZpbmQgcHJlc2VudGF0aW9uIGluIHRoZSBmb2xsb3dpbmcgcGFja2FnZSAoaXQgaXMg dGhlIHNlY29uZCBkcmFmdCkuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlhbHMvc2xpZGVz LTEwMi1zcHJpbmctMTMtcGVyZm9ybWFuY2UtbWVhc3VyZW1lbnQtaW4tc3ItbmV0d29ya3MtMDAi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL3NsaWRl cy0xMDItc3ByaW5nLTEzLXBlcmZvcm1hbmNlLW1lYXN1cmVtZW50LWluLXNyLW5ldHdvcmtzLTAw PC9hPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldlIHdlbGNvbWUgeW91ciBjb21tZW50 cyBhbmQgc3VnZ2VzdGlvbnMuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjQiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+VGhhbmtzLDwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSI0IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxNC4wcHQiPlJha2VzaCAoT24gYmVoYWxmIG9mIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyk8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iNCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE29263AB7Cdggeml510mbxchi_-- From nobody Mon Sep 10 23:48:17 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D720131106 for ; Mon, 10 Sep 2018 23:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=NmUvZ/N4; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=qBkn16V1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky7S7HpFxK9T for ; Mon, 10 Sep 2018 23:48:05 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 991951310D4 for ; Mon, 10 Sep 2018 23:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1536648482; x=1568184482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SC9db/sMs3yAaH2uwtHemZjYdGqk17YK1Y95z4vhays=; b=NmUvZ/N44LUYTSH9Rf8WhZ0yWcvJyZ011ntufc5SYgraIB/vGj3Y5xCm l6bJ2Rp+qMYYaeKxwdaQtzVVgis6XK58lgm1EFVnjzpDIDGDfsIjNjVjK /hlDsDOVmfeISMkLJ/N8ms3NB/wvgvFeqQPHuTTvziXLM1fnPArvTe+b5 n3BMwuojGjwJmmXJp/TGvZY4iu4zrNLvuKcd8BkLd/4/8hqbCko5LEjv7 5eM98g05HGE9T/5I94mJeGssdcRxWyEsX+E1x3h5WJG3GU0NDbrkJ6AlV BECdMqVLriry/+GjBJALhoc8vxUk2R41cCdoIN/o6S1zbDJG788Gku9Ws w==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 08:47:52 +0200 X-IronPort-AV: E=Sophos;i="5.53,359,1531778400"; d="scan'208";a="883576877" Received: from he106140.emea1.cds.t-internal.com ([10.169.119.73]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Sep 2018 08:47:48 +0200 Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE106140.emea1.cds.t-internal.com (10.169.119.73) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Sep 2018 08:47:48 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE105660.EMEA1.cds.t-internal.com (10.169.119.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 11 Sep 2018 08:47:48 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.20) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Sep 2018 08:45:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SC9db/sMs3yAaH2uwtHemZjYdGqk17YK1Y95z4vhays=; b=qBkn16V1tEFUkBfper3np74NyxJ7ea6QuI4ezHCH7gmvmg8mpaPJqXDF7NqU+0/3UWlFkg9w3fYi/fTSNKc5Fc2cdT2XsFKEF86yudBqbLhruZ+ux3RNVRI7AHDYN9UkcSRoF3Y1rBzk82qjQC/kuk2ssp6QnaAYRDDtKtdk9io= Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.143) by FRAPR01MB0114.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.15; Tue, 11 Sep 2018 06:47:47 +0000 Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::c146:c5c0:b4b6:6d72]) by FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::c146:c5c0:b4b6:6d72%7]) with mapi id 15.20.1122.020; Tue, 11 Sep 2018 06:47:47 +0000 From: To: CC: Thread-Topic: [spring] WG Review: Source Packet Routing in Networking (spring) Thread-Index: AQHUSSMkIBdL7o/lFkCwOb+NkKutBKTqnfKQ Date: Tue, 11 Sep 2018 06:47:47 +0000 Message-ID: References: <153659670001.26517.861627310390777605.idtracker@ietfa.amsl.com> In-Reply-To: <153659670001.26517.861627310390777605.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.22] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0114; 6:hmBWc1yJxqQ84fGmRl4XCpzlMAknAUsooelidKiI/EnYjcadEjt8QsBtlGnWUMTB8iVU07iDz48wvJDwZ0fU3MU3fjL5ioMig+GDRIR0WWrBLQvKpx/DiWqyd26UzUn6hzvE2aH5HCeSmX3K6/il3+1ocZRDQX919Ghp7d+QrNom4tASNx9HqnQcbEJGccEvnbv9CLYZgEfF3BIW03C87VBHgPe5bd1SsvXvxRBjWtvcW+1+m2RzLsnK3/uwvK+1T2JMa5C8A+ed9wclLQnaw/Kz0gpkBZajPYOE0MSXp3XSIQSTILwUnwZ9TgcsC7vJjd8n2aN5Ne04PBD5eFkTqJsgJgoOeKPgqOGemHoc4TSw7Ac3L5auyLFytS/6Twk2ctameJIj2ZsGKbqyRmtFMZHPw93rXpiys2rpiL88P8h8yNBz/bBOgtNMm9P/WYLsIm5yD/MKAfTndeTRYE6//w==; 5:tjnl7aIhFEPSB6vBPJOofmThyknupIoIIFyDqQ6p6Fd/SlVClDQBUnqngMFLOtnS0R2tK5L275cE/UZDdlK4UbiCPjqVzyAJUyNmGY19+UYzjAXcWcXiH2fR0w23weod68GhNHKMjG831g1HoicU/KHxdyxHMLdbYuHXq7Um8EI=; 7:mVRmVjsoUt+DUdQamSuyMV5vXlJjL9sXd/IpvACPGi5kp07Cd5N4iSZqEiZf1ShtNAb4y1hCYdyF5zuBqqYnQ8GyehXSbqH3hzmC4W7bzJ0qzyld1FSNeBhIHRP1XrkPyuFinetJ8PrffnUgWHP5vKIDQ1PBc8b6pavxQckhaG7IcAoYcnUyuJPKV08Lbt93NUXk4gSrCX9HIZJq71TB0NN5bgOYUvU9Rm4Phk+kjVrtzFvWzgeMquV6kUT+s89U x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 928bf914-b460-42af-0cb0-08d617b27c39 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0114; x-ms-traffictypediagnostic: FRAPR01MB0114: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(269456686620040); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699050); SRVR:FRAPR01MB0114; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0114; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(396003)(376002)(136003)(189003)(199004)(68736007)(478600001)(9686003)(316002)(305945005)(2906002)(106356001)(14454004)(7736002)(3846002)(6116002)(53936002)(26005)(102836004)(97736004)(256004)(66066001)(186003)(8936002)(11346002)(14444005)(55016002)(476003)(33656002)(486006)(446003)(52396003)(86362001)(2900100001)(81156014)(5660300001)(76176011)(5250100002)(81166006)(8676002)(7696005)(75402003)(74482002)(72206003)(105586002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0114; H:FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: 43l1uY69YGv7FIMf+AJsLOMx3QOiGoD8F3KbjyCJ2rMui4OsuVPw3/pOJkxo9GQh7eKvA7CWP+BU8DzqB+DCXsn/nSjkDLBFC6+RGYjCJp5YbkObTm7t0a1xp6um8v/d8j8OZ5nRw1cW6zyVpZ0Q+UfS4VBdEjE0DsmytYKFGUDYm9e7bHHPH9VB3ecqc4tkYACacXapUm+0FOVn2ntLq2/RXMuGAYLakg6V6kPFIa7vMqPapD7952FCxA3Dq4gUU0XMOQcpafgM9w5lCX3wrkvFKckXLrH0QJP3p6RrP0D9iCIY/xq4Yxi1o64NPN3+EF+shn6NkjNEe8nNMAZ3W0YytmwikWuNKzrH/OKBMBA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 928bf914-b460-42af-0cb0-08d617b27c39 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 06:47:47.4804 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0114 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [spring] WG Review: Source Packet Routing in Networking (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 06:48:16 -0000 Hi Bruno, one comment on the proposed agenda, o New types of segments mapping to forwarding behaviour (e.g., local ingres= s replication, local forwarding resources, a pre-existing replication struc= ture) if needed for new usages. [RG] The multicast part has been agreed. I personally am not interested in = work on "new types of segments mapping to local forwarding resources". This= solution likely requires maintaining state in core nodes. Such a solution = makes sense, if resources are scarce and different products compete for ban= dwidth in a range similar as the core network to be sliced itself. This isn= 't the case in most networks today. If this work is to be scheduled, I'd pr= efer to wait until there are use cases requiring it. I've asked for those, = but didn't yet receive a response.=20 Should "new types of segments mapping to local forwarding resources" be a m= ulticast requirement only, my question is, whether this is a new requiremen= t and needs to be maintained. I'm not a multicast expert but think to recal= l, that providing separate forwarding resources to replicated packets withi= n router hardware is state of the art. If that's the case, what's new here= ? If "new types of segments mapping to local forwarding resources" is limited= to user access interfaces of SR domain edge nodes, the text should say so.= =20 Regards, Ruediger From nobody Tue Sep 11 00:44:33 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B437130E41 for ; Tue, 11 Sep 2018 00:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 bj8x6OL1Errk for ; Tue, 11 Sep 2018 00:44:29 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C55130E3D for ; Tue, 11 Sep 2018 00:44:29 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 428cPQ5jBbz2yGc; Tue, 11 Sep 2018 09:44:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 428cPQ4gWlz1xpC; Tue, 11 Sep 2018 09:44:26 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0415.000; Tue, 11 Sep 2018 09:44:26 +0200 From: To: "Ruediger.Geib@telekom.de" CC: "spring@ietf.org" Thread-Topic: [spring] WG Review: Source Packet Routing in Networking (spring) Thread-Index: AQHUSSMkIBdL7o/lFkCwOb+NkKutBKTqnfKQgAAPgLA= Date: Tue, 11 Sep 2018 07:44:25 +0000 Message-ID: <20240_1536651866_5B97725A_20240_307_10_53C29892C857584299CBF5D05346208A47B49554@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <153659670001.26517.861627310390777605.idtracker@ietfa.amsl.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.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Review: Source Packet Routing in Networking (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 07:44:31 -0000 Hi Ruediger, Thanks for the feedback and comments. On a process standpoint, note that the charter has already been sent to the= IESG for review https://datatracker.ietf.org/doc/charter-ietf-spring/histo= ry/ > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Tuesday, September 11, 2018 8:48 AM >=20 > Hi Bruno, >=20 > one comment on the proposed agenda, >=20 > >=20 > o New types of segments mapping to forwarding behaviour (e.g., local ing= ress replication, local > forwarding resources, a pre-existing replication structure) if needed fo= r new usages. >=20 > [RG] The multicast part has been agreed. I personally am not interested = in work on "new types > of segments mapping to local forwarding resources". This solution likely= requires maintaining > state in core nodes. Such a solution makes sense, if resources are scarc= e and different > products compete for bandwidth in a range similar as the core network to= be sliced itself. This > isn't the case in most networks today. If this work is to be scheduled, = I'd prefer to wait until there > are use cases requiring it. I've asked for those, but didn't yet receive= a response. >=20 > Should "new types of segments mapping to local forwarding resources" be = a multicast > requirement only, my question is, whether this is a new requirement and = needs to be > maintained. I'm not a multicast expert but think to recall, that providi= ng separate forwarding > resources to replicated packets within router hardware is state of the = art. If that's the case, > what's new here? >=20 > If "new types of segments mapping to local forwarding resources" is limi= ted to user access > interfaces of SR domain edge nodes, the text should say so. The work item is: "o New types of segments mapping to forwarding behaviour = if needed for new usages." " (e.g., local ingress replication, local forwarding resources, a pre-exist= ing replication structure)" are possible examples. Their purpose is to give= a better practical idea of what "forwarding behavior" could represent. It'= s not a statement that the WG must deliver on "local forwarding ressources"= . As a side note, regarding specifically "new types of segments mapping to lo= cal forwarding resources", I think one could argue that https://tools.ietf.= org/html/draft-ietf-isis-l2bundles-07 could fall into this. But the discuss= ion is moot as this work item has already been carried out by the IS-IS WG,= independently of this SPRING charter. Regards, --Bruno =20 > Regards, >=20 > Ruediger >=20 >=20 >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 11 05:20:14 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50C9130E71; Tue, 11 Sep 2018 05:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 zbvWJPv-d-nH; Tue, 11 Sep 2018 05:20:05 -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 C1213130E46; Tue, 11 Sep 2018 05:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1536668405; x=1537878005; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=97Up8qdZsfCBjX4ioBY7qF60531cC4MkrWTI4C7/tJs=; b=MYU3FRyK9ugzuKAGXk83LeuBDvfIYoCUs2I1i55hhoQrLauinAp60lkJ weB6cY98IrLtyt/kvcNLonKpIZCVcc3AHyEbzJpa8IAd9iAVn4+TqYXW3 P7BVMw/CUSXo8KXi7wJWDo1qyxenKbWHnhNXQpdvwySxNCA2iythwpxC5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAwCLsZdb/5BdJa1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfL2V/KAqDaIgTjB6BaINikneBegsYC4RJGYNzITQYAQIBAQI?= =?us-ascii?q?BAQJtHAyFOQIBAwEBIRE6CxIBCBoCJgIEJQsVEgQBDQWDIQGCAQ+lEYEuhGy?= =?us-ascii?q?FFAWBC4laF4FBP4E5DBOCTIMbAQGBYReCajGCJgKcCAkCkAAXgUCEP4hxk2Y?= =?us-ascii?q?CERSBJR04gVVwFTsqAYJBgk2ISIU+b4x9gR0BAQ?= X-IronPort-AV: E=Sophos;i="5.53,360,1531785600"; d="scan'208";a="170116239" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 12:20:04 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w8BCK3ng027639 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2018 12:20:04 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Sep 2018 07:20:01 -0500 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1395.000; Tue, 11 Sep 2018 07:20:01 -0500 From: "Rakesh Gandhi (rgandhi)" To: Mach Chen , spring CC: "ippm@ietf.org" Thread-Topic: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm Thread-Index: AQHUScnDT6yM7jL8dky5UDpY/GMOVA== Date: Tue, 11 Sep 2018 12:20:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.181.86] Content-Type: text/plain; charset="utf-8" Content-ID: <5F60945E5857484190B313A1E673841B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [spring] [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 12:20:08 -0000 VGhhbmtzIE1hY2ggZm9yIHRoZSByZXZpZXcgY29tbWVudHMuIFdlIHdpbGwgYWRkIGZvbGxvd2lu ZyB0ZXh0IGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudHMuDQoNCjEuICBMb3Nz IE1lYXN1cmVtZW50DQogDQogIFRoZSBwYXRoIHNlZ21lbnQgaWRlbnRpZmllciBbSS1ELnNwcmlu Zy1tcGxzLXBhdGgtc2VnbWVudF0NCiAgIFtJLUQucGNlLXNyLXBhdGgtc2VnbWVudF0gb2YgdGhl IFNSIFBvbGljeSBpcyByZXF1aXJlZCBmb3IgYWNjb3VudGluZw0KICAgcmVjZWl2ZWQgdHJhZmZp YyBvbiB0aGUgZWdyZXNzIG5vZGUgZm9yIGxvc3MgbWVhc3VyZW1lbnQuDQogDQoyLiBUd28td2F5 IEVuZC10by1lbmQgTWVhc3VyZW1lbnQgb2YgU1IgUG9saWN5DQogDQogICBUaGUgcGF0aCBzZWdt ZW50IGlkZW50aWZpZXIgW0ktRC5zcHJpbmctbXBscy1wYXRoLXNlZ21lbnRdDQogICBbSS1ELnBj ZS1zci1wYXRoLXNlZ21lbnRdIG9mIHRoZSBmb3J3YXJkIFNSIFBvbGljeSBjYW4gYmUgdXNlZCB0 bw0KICAgZmluZCB0aGUgcmV2ZXJzZSBTUiBQb2xpY3kgdG8gc2VuZCB0aGUgcHJvYmUgcmVzcG9u c2UgbWVzc2FnZS4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KT24gMjAxOC0wOS0xMCwgOToxMiBQ TSwgImlwcG0gb24gYmVoYWxmIG9mIE1hY2ggQ2hlbiIgPGlwcG0tYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgbWFjaC5jaGVuQGh1YXdlaS5jb20+IHdyb3RlOg0KDQogICAgSGkgQXV0aG9y cywNCiAgICAgDQogICAgVGhlIGRyYWZ0LWxpLXBjZS1zci1wYXRoLXNlZ21lbnQgYW5kIGRyYWZ0 LWNoZW5nLXNwcmluZy1tcGxzLXBhdGgtc2VnbWVudCBkZWZpbmUgdGhlIG5vdGlvbiBvZiBwYXRo IHNlZ21lbnQgaWRlbnRpZmllci4gQ291bGQgeW91IHBsZWFzZSBjb25zaWRlciBhZGRpbmcgc29t ZSB0ZXh0IGluIGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtIGFuZCBkcmFmdC1nYW5kaGktc3By aW5nLXNyLW1wbHMtcG0gYW5kIGhvdyBpdCBpcyBhcHBsaWNhYmxlIHRvIHBlcmZvcm1hbmNlIG1l YXN1cmVtZW50IGluIHNlZ21lbnQgcm91dGluZz8NCiAgICAgDQogICAgQmVzdCByZWdhcmRzDQog ICAgTWFjaA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgaXBwbSBtYWlsaW5nIGxpc3QNCiAgICBpcHBtQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQogICAgDQoNCg== From nobody Tue Sep 11 07:03:19 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCE9130DC4 for ; Tue, 11 Sep 2018 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=GGNMJ0Jl; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=TprVGkad Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXjZeU9i0Zu3 for ; Tue, 11 Sep 2018 07:03:14 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 2396F12F1A2 for ; Tue, 11 Sep 2018 07:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1536674594; x=1568210594; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hyb+rfoIS9yta1c/kz7n6gdXHvB4PbGRpIUIYZV4q+M=; b=GGNMJ0JlENYWJVy6HIHIURovFhf8s7KH9OcpO5cbtS4w6Xg7iRM4wgUn 7cAh7UUiPSBSusbvVn3aKXCFFpp8q2nal6R1dDEk033/8HVidPfR40SL9 1j8xk6mbgDd8aJEkpyp9wna5q5fQ+l0tOQ9yIKwzNcP2bpC/AEfWS8dum +V+vK1a4mklCbRuXGwPwlZC0wGiQuSspj0le6RK/mar62xcfvNT/7kNz3 8w97iA1GO+eGD+8VXgKf7jNNtrO7Iw7S6XdDQRMBiD8RCFmMKmPrpc3fl KXPSX/Mq03lY5/QGfhU1WY+QFnlzqKxr5PeGfgQXobupyVC/eEizGw11a Q==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 16:03:12 +0200 X-IronPort-AV: E=Sophos;i="5.53,360,1531778400"; d="scan'208";a="120916081" Received: from he106142.emea1.cds.t-internal.com ([10.169.119.76]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 11 Sep 2018 16:02:58 +0200 Received: from HE106139.EMEA1.cds.t-internal.com (10.169.119.72) by HE106142.emea1.cds.t-internal.com (10.169.119.76) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Sep 2018 16:02:53 +0200 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE106139.EMEA1.cds.t-internal.com (10.169.119.72) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 11 Sep 2018 16:02:53 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Sep 2018 16:03:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hyb+rfoIS9yta1c/kz7n6gdXHvB4PbGRpIUIYZV4q+M=; b=TprVGkadkLKY2cxo3JzO2TdzDao4kC7xG3+hWB/ypdFGq2gYf7jltW3ocC9NrCWOtsmOAtqC3JXWBH5By7dgDlyLIOLnG4cttiEUVLomQFEu/Dq40Mne/8Z8wDE8Y6LmfIAdqCl/kWIElNBIQm7IX6BeONlsyZ3KD6ebMQoN/9I= Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.143) by FRAPR01MB0115.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.15; Tue, 11 Sep 2018 14:02:52 +0000 Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::c146:c5c0:b4b6:6d72]) by FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::c146:c5c0:b4b6:6d72%7]) with mapi id 15.20.1122.020; Tue, 11 Sep 2018 14:02:52 +0000 From: To: CC: Thread-Topic: [spring] WG Review: Source Packet Routing in Networking (spring) Thread-Index: AQHUSSMkIBdL7o/lFkCwOb+NkKutBKTqnfKQgAAPgLCAAG7jgA== Date: Tue, 11 Sep 2018 14:02:52 +0000 Message-ID: References: <153659670001.26517.861627310390777605.idtracker@ietfa.amsl.com> <20240_1536651866_5B97725A_20240_307_10_53C29892C857584299CBF5D05346208A47B49554@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <20240_1536651866_5B97725A_20240_307_10_53C29892C857584299CBF5D05346208A47B49554@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.156] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0115; 6:R6XNjvF/he1AJpeU8rN9SETmFvGWWjZpLdK8V+vYgP+MN989FosvVz0FEVdmobAly/RhKILPMHRbUoP6R5QRJnuYlvN6I4JXzdNnscJSmk36XxzRfAgHWrqeUrwA3t5WjnszcBOh4UrZjLUqLCk9j4pdM0pI/uwqKtQ6NeL5H6ytosJ85pcF0U1/8tUJha/3hBEW3dg64Ezq4WbykJEXd0JY8+Og9BYuK3iordoUPR6gmCgF4+TlGuCv98WSuTUFzM26eFM1jZ/HXIenexkOD66IHm+mx0eX+arHcCW2n8wjAAcrcWaKgGucNFo3N6m8W9j2ODyHV09O6VPcW6b+WIfZvJjQKOI/F/oA5ktT4so4T31vwUOM90oSIB/3jn+zsvAmTheiiSv1Zbw2ziFziqUcmmctrCEFE2MfuNJV0dICDAMlEGHpc+GTzJMvp1/ADjAe3AKHnOMqOcOp+4PzoQ==; 5:o48KNdKYj8JqNhNHnZ90jjLp2yRLG7WsaKrrdq1DoHHy6GVKXj/MM82unCsh01rzM96p9D+D70u+KxxxPKNnWvGroST581/HjkJbiDEArBQmzqGwztKOu4nhoXZYqVywpWWs/9/Yp98Zu/AB+PO/HkzklG27Gn5NJGeQ85olqjc=; 7:wBWZdKYSWNErOLTk5TJT1lQN552I+HlB857jd901JKL/bXZIQ6WEXVQ1jGvRvb8TyMjy6DI1ZjcBP4cfdc/0GtNPlEFtlz3xM6zjvOaewaLyLzO6dkmKm8ArDuqXOH+bMF4OPOtN0kPcVGroqaJARWEjnBn4Pjd0Ql3Wa6GXmLeS5THhwvVqs/3J4oJMQC6m+l3rs+uZDOuXB8CJ7wJQFVi3c3G0UyhQ/azissFDi7BaD3GIYgejRZqBTVY2feAH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7921c828-b7c0-40b6-4469-08d617ef4421 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0115; x-ms-traffictypediagnostic: FRAPR01MB0115: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(103651359005742)(260130700054247)(161740460382875)(269456686620040)(18271650672692); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:FRAPR01MB0115; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0115; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(366004)(136003)(199004)(189003)(51914003)(6116002)(305945005)(7736002)(476003)(5640700003)(55016002)(97736004)(14454004)(486006)(9686003)(6306002)(2351001)(14444005)(256004)(5024004)(26005)(53936002)(6916009)(186003)(478600001)(11346002)(102836004)(446003)(86362001)(66066001)(105586002)(106356001)(72206003)(33656002)(2501003)(75402003)(74482002)(316002)(68736007)(52396003)(76176011)(5660300001)(3846002)(8676002)(7696005)(81166006)(8936002)(5250100002)(2906002)(81156014)(2900100001)(966005)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0115; H:FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: KYlfpPTMnCrAJ8GdHzgutzMVbOLnIg2fOvgLhU4lvLaRCWgThq7vUU5S3g4309ZkK0aAzJU+AkAmOHz96ymEls4fUGnCtPb5LotpbhutpQF87dr552BfgWtfjDQ6vT6PM8WbPZh4IgLVEjAK1IkAkhOIUaGAYRMicKCuyFgjZk1v2gQlq3Tc/gWRLatpOzx2K+aGGwKt7bLQMuEvrvNbDnsYRlv3dTckwaiWcH1hR3rxxR44LMEFczn/N7344kzrC/2wIUyCVoLPXy62DtYrQdKUoE45K6SXin/WKVnCvW/X+0mYw/cuO1Ns+a5KhyqYmGvF0bGrn/rNmGYJnibCnP1tpIOohtnbZ8aDuYNk2RA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7921c828-b7c0-40b6-4469-08d617ef4421 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 14:02:52.6246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0115 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [spring] WG Review: Source Packet Routing in Networking (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 14:03:18 -0000 Hi Bruno, I admit that I had ample opportunity to earlier comment on the proposed cha= rter statement and didn't. So I don't re-open discussion now. I trust you and Rob to interpret the charter item "New types of segments ma= pping to forwarding behaviour if needed for new usages" not as a statement = allowing to get WG status for drafts offering solutions without prior descr= ibing the problems to be solved.=20 Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]=20 Gesendet: Dienstag, 11. September 2018 09:44 An: Geib, R=FCdiger Cc: spring@ietf.org Betreff: RE: [spring] WG Review: Source Packet Routing in Networking (sprin= g) Hi Ruediger, Thanks for the feedback and comments. On a process standpoint, note that the charter has already been sent to the= IESG for review https://datatracker.ietf.org/doc/charter-ietf-spring/histo= ry/ > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Tuesday, September 11, 2018 8:48 AM >=20 > Hi Bruno, > > one comment on the proposed agenda, > > > > o New types of segments mapping to forwarding behaviour (e.g., local ing= ress replication, local > forwarding resources, a pre-existing replication= structure) if needed for new usages. > > [RG] The multicast part has been agreed. I personally am not interested = in work on "new types > of segments mapping to local forwarding resources"= . This solution likely requires maintaining > state in core nodes. Such a = solution makes sense, if resources are scarce and different > products com= pete for bandwidth in a range similar as the core network to be sliced itse= lf. This > isn't the case in most networks today. If this work is to be sc= heduled, I'd prefer to wait until there > are use cases requiring it. I've= asked for those, but didn't yet receive a response. > > Should "new types of segments mapping to local forwarding resources" be = a multicast > requirement only, my question is, whether this is a new requ= irement and needs to be > maintained. I'm not a multicast expert but think= to recall, that providing separate forwarding > resources to replicated p= ackets within router hardware is state of the art. If that's the case, > = what's new here? > > If "new types of segments mapping to local forwarding resources" is limi= ted to user access > interfaces of SR domain edge nodes, the text should s= ay so. The work item is: "o New types of segments mapping to forwarding behaviour = if needed for new usages." " (e.g., local ingress replication, local forwarding resources, a pre-exist= ing replication structure)" are possible examples. Their purpose is to give= a better practical idea of what "forwarding behavior" could represent. It'= s not a statement that the WG must deliver on "local forwarding ressources"= . As a side note, regarding specifically "new types of segments mapping to lo= cal forwarding resources", I think one could argue that https://tools.ietf.= org/html/draft-ietf-isis-l2bundles-07 could fall into this. But the discuss= ion is moot as this work item has already been carried out by the IS-IS WG,= independently of this SPRING charter. Regards, --Bruno =20 > Regards, > > Ruediger > > >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 11 19:33:04 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB9130DC1; Tue, 11 Sep 2018 19:32:56 -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, 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 9vz93aTvNm13; Tue, 11 Sep 2018 19:32:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6C998130DCD; Tue, 11 Sep 2018 19:32:54 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7FAAE36782477; Wed, 12 Sep 2018 03:32:49 +0100 (IST) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 12 Sep 2018 03:32:50 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.7]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0399.000; Wed, 12 Sep 2018 10:32:43 +0800 From: Mach Chen To: "Rakesh Gandhi (rgandhi)" , spring CC: "ippm@ietf.org" Thread-Topic: [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm Thread-Index: AQHUScnDT6yM7jL8dky5UDpY/GMOVKTr7eww Date: Wed, 12 Sep 2018 02:32:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] [ippm] Comments on draft-gandhi-spring-sr-mpls-pm and draft-gandhi-spring-udp-pm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 02:32:56 -0000 SGkgUmFrZXNoLA0KDQpUaGFua3MgZm9yIGNvbnNpZGVyaW5nIG15IGNvbW1lbnRzIQ0KDQpCZXN0 IHJlZ2FyZHMsDQpNYWNoIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIFttYWlsdG86cmdhbmRoaUBjaXNjby5jb21dDQo+IFNl bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMSwgMjAxOCA4OjIwIFBNDQo+IFRvOiBNYWNoIENoZW4g PG1hY2guY2hlbkBodWF3ZWkuY29tPjsgc3ByaW5nIDxzcHJpbmdAaWV0Zi5vcmc+DQo+IENjOiBp cHBtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaXBwbV0gQ29tbWVudHMgb24gZHJhZnQtZ2Fu ZGhpLXNwcmluZy1zci1tcGxzLXBtIGFuZCBkcmFmdC0NCj4gZ2FuZGhpLXNwcmluZy11ZHAtcG0N Cj4gDQo+IFRoYW5rcyBNYWNoIGZvciB0aGUgcmV2aWV3IGNvbW1lbnRzLiBXZSB3aWxsIGFkZCBm b2xsb3dpbmcgdGV4dCBpbiB0aGUNCj4gbmV4dCByZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnRzLg0K PiANCj4gMS4gIExvc3MgTWVhc3VyZW1lbnQNCj4gDQo+ICAgVGhlIHBhdGggc2VnbWVudCBpZGVu dGlmaWVyIFtJLUQuc3ByaW5nLW1wbHMtcGF0aC1zZWdtZW50XQ0KPiAgICBbSS1ELnBjZS1zci1w YXRoLXNlZ21lbnRdIG9mIHRoZSBTUiBQb2xpY3kgaXMgcmVxdWlyZWQgZm9yIGFjY291bnRpbmcN Cj4gICAgcmVjZWl2ZWQgdHJhZmZpYyBvbiB0aGUgZWdyZXNzIG5vZGUgZm9yIGxvc3MgbWVhc3Vy ZW1lbnQuDQo+IA0KPiAyLiBUd28td2F5IEVuZC10by1lbmQgTWVhc3VyZW1lbnQgb2YgU1IgUG9s aWN5DQo+IA0KPiAgICBUaGUgcGF0aCBzZWdtZW50IGlkZW50aWZpZXIgW0ktRC5zcHJpbmctbXBs cy1wYXRoLXNlZ21lbnRdDQo+ICAgIFtJLUQucGNlLXNyLXBhdGgtc2VnbWVudF0gb2YgdGhlIGZv cndhcmQgU1IgUG9saWN5IGNhbiBiZSB1c2VkIHRvDQo+ICAgIGZpbmQgdGhlIHJldmVyc2UgU1Ig UG9saWN5IHRvIHNlbmQgdGhlIHByb2JlIHJlc3BvbnNlIG1lc3NhZ2UuDQo+IA0KPiBUaGFua3Ms DQo+IFJha2VzaA0KPiANCj4gDQo+IE9uIDIwMTgtMDktMTAsIDk6MTIgUE0sICJpcHBtIG9uIGJl aGFsZiBvZiBNYWNoIENoZW4iIDxpcHBtLQ0KPiBib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBtYWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgSGkgQXV0aG9ycywNCj4g DQo+ICAgICBUaGUgZHJhZnQtbGktcGNlLXNyLXBhdGgtc2VnbWVudCBhbmQgZHJhZnQtY2hlbmct c3ByaW5nLW1wbHMtcGF0aC0NCj4gc2VnbWVudCBkZWZpbmUgdGhlIG5vdGlvbiBvZiBwYXRoIHNl Z21lbnQgaWRlbnRpZmllci4gQ291bGQgeW91IHBsZWFzZQ0KPiBjb25zaWRlciBhZGRpbmcgc29t ZSB0ZXh0IGluIGRyYWZ0LWdhbmRoaS1zcHJpbmctdWRwLXBtIGFuZCBkcmFmdC1nYW5kaGktDQo+ IHNwcmluZy1zci1tcGxzLXBtIGFuZCBob3cgaXQgaXMgYXBwbGljYWJsZSB0byBwZXJmb3JtYW5j ZSBtZWFzdXJlbWVudCBpbg0KPiBzZWdtZW50IHJvdXRpbmc/DQo+IA0KPiAgICAgQmVzdCByZWdh cmRzDQo+ICAgICBNYWNoDQo+IA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gICAgIGlwcG0gbWFpbGluZyBsaXN0DQo+ICAgICBpcHBtQGll dGYub3JnDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0N Cj4gDQoNCg== From nobody Mon Sep 24 06:48:01 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D03DC130DC2; Mon, 24 Sep 2018 06:47:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: spring-chairs@ietf.org, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153779687876.28048.15339137396549087902.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2018 06:47:58 -0700 Archived-At: Subject: [spring] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_char?= =?utf-8?q?ter-ietf-spring-01-02=3A_=28with_COMMENT=29?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 13:47:59 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-spring-01-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-spring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This sentence is probably unnecessary as always true for all wgs: "The SPRING WG will manage its specific work items by milestones agreed with the responsible Area Director." From nobody Wed Sep 26 16:49:39 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E71F130DCE; Wed, 26 Sep 2018 16:49:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: spring-chairs@ietf.org, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153800577202.21617.12298849906709295342.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2018 16:49:32 -0700 Archived-At: Subject: [spring] Alissa Cooper's No Objection on charter-ietf-spring-01-02: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 23:49:32 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-spring-01-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-spring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not clear on the implications of the text about security considerations. If it turns out that people want to use this cross-domain, will integrity protection be specified as a requirement? Will other security properties be specified as required in that scenario? If it turns out that the threat models require enhancements to the security properties of the underlying protocols, will the segment routing specs still be progressed even as those requirements are pitched over to other WGs, or will they not? From nobody Thu Sep 27 06:15:48 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9997130E89; Thu, 27 Sep 2018 06:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 9vNHkGGhim-w; Thu, 27 Sep 2018 06:15:44 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50134.outbound.protection.outlook.com [40.107.5.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F072B130E86; Thu, 27 Sep 2018 06:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sv0Uc0OrFe7jYVJ2OPjtYsQ5LUkKJjWgStSIrMOM4X4=; b=ghkxBigAfz4pFd1fWUI32Wda+Va1zpaF06HEyOklT1P2hx09JQKQI4U+ZH1MEDPzivz8RwLZQNEYbpgoZBW8BzuGWZX5AE1XPDMQZb+t87H14AUEbdXhMSEHB41qF6ph6rTE0HRIkb50DhbYH+mOB3RFYYRGEVuxmp5pQsQR+zI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [135.244.225.245] (135.245.212.245) by VI1PR0701MB2509.eurprd07.prod.outlook.com (2603:10a6:800:6e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.10; Thu, 27 Sep 2018 13:15:40 +0000 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , The IESG Cc: spring@ietf.org, spring-chairs@ietf.org References: <153779687876.28048.15339137396549087902.idtracker@ietfa.amsl.com> From: Martin Vigoureux Message-ID: Date: Thu, 27 Sep 2018 15:15:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <153779687876.28048.15339137396549087902.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Originating-IP: [135.245.212.245] X-ClientProxiedBy: LNXP265CA0082.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::22) To VI1PR0701MB2509.eurprd07.prod.outlook.com (2603:10a6:800:6e::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 37a49741-173a-4e1b-49e5-08d6247b529e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:VI1PR0701MB2509; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2509; 3:GcRIAKucp2S4BfJKQ3yxbA6e23W1MuDuIv+ca8zxXUJSsrcwLNTy1nuBi9vVJdtioYJP7tfWPyKNCxUWyTPjuCrdKedBsWT4Xf0SUxRLCXrejJImMnHFs9Cv6Zjq5YK8bzFfg2NYHgLdXp9HKN8lAHusxW/CTtsqvq1M1InGHTMzvu87wdZEhpkIFCX7l/q4ar/nYbgwwhUu15hHh/IDGBpmOCVkoK+qhugGKqFuhJqZz3RzDSPcJeO2iLQxdhDr; 25:J1CQamo++luzFhJNCcSN+4sk84Ewzl+Je6cPb4O3LTv/B+hK0p1PovEmu067eQjrZzVCkmJUk8SD6Sm+lqnZHvKHp93xdADlNL8MVEZeHO7tMsjfCmGneQSPVkZGv2CQCTzs1QjXb6rX29f9P/7QZ7uGxHaAQyVzjhioqMczbNE2pfOs7dt4SUtjwnzodVGbDQEZLxg2eztbkFNwFN5bwHJyxtfET9sHipKyi0Q7uBdlxC0zponPh7zUcA1A1SSwTnxaDM6IyuJATlo784cQNsx3dpONrec1KLvHFSLuvIa2qQUmj7/X0jgz7KxSMDnT4ASf6w5IlG0ImcCj5793Gg==; 31:2Hb53ic/WlJQ9ftKqVXjva68g7cu2qzpcp1HQt+V2cvJk0FGk8+NMabEwu0CnT+ABCIAa4XTrCX4IY3DKeshIAR69yWUxt5/VvisLk+7FIPRI13SCfpkluW8Nyuayl4ME86yoCsNa5myDJW+DjLDDzhVxRgtPZA3JnrjaliHJF4skMskWFkTpNrYtKvjLG2ikIuqZpHkkSriR2p+YKvpj08GlurV9ZQSt2WAPoVSGjk= X-MS-TrafficTypeDiagnostic: VI1PR0701MB2509: X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2509; 20:Opwo2ZWA/gLktliICi2BD96p8Z7U/3sXKKJ4TBZqYWGh0BM/qe0ayN9zs1+3y+M4YjghPiB7DWX2XiguKRvYjKcMfVUlzhyqkxAdR157x3jdx2OVwgQU+ZxdF9KkUhK/aAz6VRungeRLz1OiTWtOsfLyZbJHNgvyJbZhio+NLcXyJdElRKEHiEl3C7KLaEnwPn0rutWOZ8Fllke8T14EQr8YhGiaXgecnC0qv7W4zibbeoY+Rnzu7wNlqqJWCFbBFylXHUX5BlTMRA+jEWV5yCfl76XRzzM1PmkvUxG0OMQ6d0FzQuI8dHDv1WsbxbAEaJRaY7L7mqvyl8hnxd2B8N/WDXhZAAAYtZEGOqmnKVMXPEXZtk5HZy9Hty/6/KvJURXRDyctF5U0WI94Gdf8oU3fj8MnjGl7197qcw+IMct7Cxdqmq7KiAmXfYumZsgduNtE0vSj3oltDQ7CVh3CAv9dygwwDX3jN2gMPq7W+YQszEdHTDYZswmIcqKtU8Qd; 4:5poZblbcpXa0Bo8pIGZ4MW7TSuVg6A8kx+mCeq8/6aAeD8z/8DdKHNphzacATVRLeqaK3KEB2MWKtf9z4nA1kubX1hVu/2t61xGqA5LdafBgM0V0aia2/OCQ3OkZHUvORu3vjzcywPHhyA86dGRoic/6RC6LVmpteBgV8WQMw7p1IzxJ27JclGC27pSj9GqjCr2o4aQ7wIePTcvfihbma6Etuay4mELIKKntlacgZp/Tm2TZo+U9VCAyAFZmYWgm0BsyOjTwKhNMGguhPg4Q8vWMMPhd0HNuOvctgj3Wq9vphbMg5DoQAyj4UMqBloBf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231355)(11241501184)(806099)(944501410)(52105095)(10201501046)(93006095)(93001095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051); SRVR:VI1PR0701MB2509; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2509; X-Forefront-PRVS: 0808323E97 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(376002)(396003)(39860400002)(366004)(346002)(136003)(189003)(199004)(5660300001)(305945005)(31686004)(8936002)(65826007)(64126003)(229853002)(3846002)(2906002)(50466002)(2870700001)(6116002)(58126008)(316002)(110136005)(6666003)(36756003)(97736004)(26005)(186003)(16526019)(65806001)(6486002)(66066001)(65956001)(386003)(16576012)(2486003)(52146003)(23676004)(81156014)(68736007)(81166006)(52116002)(47776003)(76176011)(6246003)(476003)(478600001)(53936002)(34290500001)(2616005)(446003)(11346002)(966005)(6306002)(4326008)(44832011)(486006)(106356001)(49976009)(86362001)(224313004)(31696002)(3260700006)(67846002)(105586002)(7736002)(25786009)(956004)(224303003)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2509; H:[135.244.225.245]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjI1MDk7MjM6d1B5dXZjb1QzSEx1dzdWR3VkdUZKR0hy?= =?utf-8?B?cDloWERVL3pSckhEYkwyeFFuUnBPNlJVV2tyODVyVitKMEIxUUxpU0kwM0ZD?= =?utf-8?B?Y3E5TTNrZml1ZHNzVi9DcTN2K1BmZUZOampDVjJ2aHYwTllOODNFdSs4THUr?= =?utf-8?B?VStLeEJMT1U0TjBENTdDT0JsSHpCM3VsRXh3V1hoL3prZE5uUU80bHZ3WnNK?= =?utf-8?B?RTRDMDNRUC93eXBzZjgwVVRQL2xDbURmbGd4YVNrb0QwN1c0TzV6QWJvN0ZB?= =?utf-8?B?SnNkUzZUNEZTbFJXL2JVQ3djamRlYW1mdENQbTdWOGx0TjJINjVXMW1vWmZ1?= =?utf-8?B?UWdwcGQybVpudWI0MHFyRGNsZmI3VjNvNkV6eFZxT0tlT3Q5ZGZrdUNsSmlo?= =?utf-8?B?Z3hxK2pIelpYbVU5RTYxeHVyd0paNG1FRjV1dndtbzhJNURWT2ZvNzhCaXpQ?= =?utf-8?B?VE0vQkg2alBYQWt6VDd6MDlpY1Q3QXgzSGpTdisxRHJ1ZitvWkJEVkJRaTRL?= =?utf-8?B?V1UrbkVEemErRXhPTHZ2cEY0UE1tTzNTUkZURWNia0MzQ3hxbWhUNitkRldD?= =?utf-8?B?d1A4VUpZYlllV0VXNEZZZlNjaGw2eVVieXErejhSK3B6dGRYTHlCMDVHeTll?= =?utf-8?B?S0NzK2dCVlFjcDBrd2IwczdCYkFQNmFkVTVXV0szRkdKQmNFTlZOZUFkRUZy?= =?utf-8?B?VmF2L01sVTQ3VGxQYllrKzJLSlA5YVgvUzMzV2tndjFPWElHUXpzM2JZSW9Q?= =?utf-8?B?K2QrcTluQUxqRk9PU2toRmtFVjluVnpZMUtiUzdiNHE2TkEvN3l3L2JxV29M?= =?utf-8?B?c1JlcUkxaE9mQlRnd3FWRjJ2YXFPbW9wWEdnOW10MjVsYWFrKytoKzNTZ2VS?= =?utf-8?B?VEJ1VHBQZkJnVk9JTUI5M2wrZ0dnYkRqSGx5Z09FcmJLVmE4bkV4bWtKdTRY?= =?utf-8?B?SXI2OUJIRXFmK3h1TFQyT2VnUEZTa3ZjNUJ2M1FPRi93TW1MUy9xbEpPZHhl?= =?utf-8?B?NHVYa3BzMU40MzJjQnkvZzY4ZUQxeWNFQ0dZMDU3S2N6dlAzVUhCeUNpa2tq?= =?utf-8?B?ckRDMkNMQU5rb1FRMGRmSklsamx2T3dHVzJBczExajU5b3M3blVyanBuNVRZ?= =?utf-8?B?bnVFTlFoT1ozb05sSkd2ODlRVVRYTmU1dGFwNndGYllvRVBJcWlMSEcxZnQw?= =?utf-8?B?NGpWdmtYeWFkNzY1N2ZuRnd5eWU1YVVHVkxvQ2dTTHBBTjZxVGl5ZVFoY3BU?= =?utf-8?B?NjNOUm9tV29aeEpkcXpSOFVvT1Q2bTQrRDNPTC93WndkVXZPaXJ6bDMzUjJD?= =?utf-8?B?VW5XWEJ1dGtwTVJIc2F4N2VidUd3aXQxQkk3dHpDVlRzeWJQSHhBWUtaazRw?= =?utf-8?B?RDNQZE5SNnBhY3laaEt5RXVDcldXdVplZ3V4MUNIenhaWktNZnVsUlpwY0Iz?= =?utf-8?B?UmlraElGRU8zNlo1ZURzN3hQdDgzKzhaeUhuTUxLTkthalAzb2YwdmlteU9U?= =?utf-8?B?bEV0VHZ5OXR3OUIrMzhGZFFJbzQ3UGgxQTNHUWlzTU95a3Z3cXFQVEZsU0tI?= =?utf-8?B?cElxRERxeWh2Z2JJNDhvZHJQWWQ4RHhVOFgxU2gzcjhvR1gwK0hMWFNMbkpk?= =?utf-8?B?RURzSm0xUmNhRzEzQUp6ODZHZzU1V0ZONVJJODJ5RUhabXZiMnJndVFJZHdy?= =?utf-8?B?WDNRKzBOOHFTZ25TKzlGOWlhQytoTzRTSEhDNDFva3JoWUIyNzBNR3RMZG9R?= =?utf-8?B?amFVMkUvR3ltdXpRRFhmUG9QVFRmSFpPRHdrMVdvamVlcXBnYW5GZGp6dCtP?= =?utf-8?B?aXA5VEpwT2UyTWpkTUpyUnJZODBlWWJiRGZ0YkJyemJIOEpPcFl4MUxRaFd1?= =?utf-8?B?ZDF1UDV4UEpscTJGTzFXQlM4L0pXaStZQ244aEVHaEVJS1BhR1k2c3o4MHdT?= =?utf-8?B?TTFwSjFYdVcvV3ZxL29DbDRPVkV5SUZ5bmZMWm1Ta2RXUStTSy9JMmFVYnlo?= =?utf-8?B?dGFqV0tweUsrWm5PZnBtZUx6WHpvRVF1L2QvMkhycVNSUWFWL1FSeXZ0SVEx?= =?utf-8?B?cGZxdzZrVy9LT0l3cXNyTTkzOWNpSktLZ1pWN1V0dm9PNEZudnIvZ1JoODZB?= =?utf-8?Q?osHPN6/VUcEPQBkGkZfm0xhrc=3D?= X-Microsoft-Antispam-Message-Info: 2MoSM806TxNLl4YGXpHf/BmCmN9Rv06HLZ/j8nOOX9Z09snH0JaHOFZRAeuDUNLW9wzA2oEyfz34+LrbQP4YtU9LGQCFlGPyUQ1jKO36dQrT3ktsjWY/Q5kCwtihnziy1k1GSO1aSho8p40TqNEUo137YDt9524bIhmN2v6Ywe+uwE53+PHWCWObMYIr1lmzOFBAKAzxVtqcW3Q7cF+YVQVYezys5Z0EEIjzkhe79wZgfQPtqMj9sxuPPA7dZfXbB6fkiwVleyqSuLex2XNVq6QTcYahl7ImZ/hD2zY4CmirJR5Wf2OLZ+0mKfZrQr8m8NQiac0Fkinc079f3bTpPdsMjiq6s/gXau+B/WeAv4ztk7DyhItSoKn7pVakpxWhmjxttYLcAv17NmMHGEfSzQ== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2509; 6:uFymdY6tkW4vgfLtWAZTzNbCv3OTsuESdVWBxVx2LnbJ7UxnyAeelANnAlaZwac12PtwgUC6Y6BkXA1u6w2DdIUURhdz3Iyuy8VuuzgisUBnuBsoEHWTcV1/ZkM8Flh2Z+ddXKZQ2XCFSeB5dPhMZNEebQBv7Oi23GwnLwFu8zke63WsyEAI016jkgxcxZVzvNHTtJ+8UaYLIWUfelUvjmxkZRDEk3JRv7wBe9q1p48arWdpPEBkSfdfYklUIY8lhbcMTl5peJSCEVfQPeBkb2K9maw2P6J47xfwbpewjUUHZOXPF0LMsSzuLQsapI/028fv8UXuSIY0jMbx0lCgpoiUeMySsXqY+e3CIXCgucqGON5iuX3dd5chb073YhST1w06yMa+PpMF9YBzPxSDZrq1tv3R28+HlPtcEvjq2hcxXmqMjswlpqyyJhFs1ejR3jQW35dKGUTxCqHAkkw2lA==; 5:ATL9e6K3KgKl8hvzq4VQ8v3wQIiBMksR3ioKkIsLpNKnCKMHnwC2MZ2cJ4px0/Pxuvf+cfIztd1fH33/jSPyINKlDnb8wwagQCglrN6LwwcBOrsiXNl9I8rjl531pvo2Lsii1LlMnVZueur07+S+Rlk6X/CGs9/SLHeCcC6Vgno=; 7:mIZcrwvEilAIlRkVIGjYU4vTdPwuBoGIluoJVSnlIcC9vHvQByJk1DVR/8IyF0fcQDUJX8/VoUpMMN+xW+3jv1auqiy/iJF1/5GTcB3+nieplQItI9Oxp4Q98W3vdYZ/Du2HppBB117JjeHdW2PRbHDlZx7dbZ4nn+9od3KLHZsmDazSzhrRs45Au1fnEiYlBmrDT6xDpgCdy8Sohdnt2mDTgCytr/fxM8kUVsiIoHSSXwa2EPRAOUGQh9GXjthc SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2018 13:15:40.1293 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 37a49741-173a-4e1b-49e5-08d6247b529e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2509 Archived-At: Subject: Re: [spring] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_char?= =?utf-8?q?ter-ietf-spring-01-02=3A_=28with_COMMENT=29?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 13:15:47 -0000 Hello Mirja, yes, but since it is true there is no harm in keeping it either. -m Le 2018-09-24 à 15:47, Mirja Kühlewind a écrit : > Mirja Kühlewind has entered the following ballot position for > charter-ietf-spring-01-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This sentence is probably unnecessary as always true for all wgs: > > "The SPRING WG will manage its specific work items by milestones agreed > with the responsible Area Director." > > > From nobody Thu Sep 27 06:17:55 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474E5130E93; Thu, 27 Sep 2018 06:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 vfmHs0YrY_rr; Thu, 27 Sep 2018 06:17:44 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4CA130E86; Thu, 27 Sep 2018 06:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fS10/VXPQ1c2D6dOv5kFTa3hj5P1X+9Syl1vaoLkUUQ=; b=sZ5HVwXQcWcxoX6xIfzc5mg6d+TXU+2Ofs+mcPIlMApE5DAp9VkAzb4AzoQPHdMImAANip4SW/N2F/8bDvV9zT9Y50IkcnwdB+QjTdJ85JEcmImxNNrEhZaadXmqWR5LowI/6F97sohsqH4YVtyKX0AbWDXrGEZGLqphMf5qzMQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [135.244.225.245] (135.245.212.245) by VI1PR0701MB2512.eurprd07.prod.outlook.com (2603:10a6:800:6f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.12; Thu, 27 Sep 2018 13:17:41 +0000 To: Alissa Cooper , The IESG Cc: spring@ietf.org, spring-chairs@ietf.org References: <153800577202.21617.12298849906709295342.idtracker@ietfa.amsl.com> From: Martin Vigoureux Message-ID: Date: Thu, 27 Sep 2018 15:17:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <153800577202.21617.12298849906709295342.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [135.245.212.245] X-ClientProxiedBy: AM6PR06CA0016.eurprd06.prod.outlook.com (2603:10a6:20b:14::29) To VI1PR0701MB2512.eurprd07.prod.outlook.com (2603:10a6:800:6f::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 93a94a3a-df46-4b88-0661-08d6247b9ad1 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:VI1PR0701MB2512; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2512; 3:H141Ezz8mbveaqWd78mWL0o4hCxJLcb6x1JP/IBElaWHusGEX7EfNGCbMzNuTZ3/TU8hSHRn10Vl4TksS5LLQ2NBPeheDBy2ajoJO/y7L+1szq8EE+HlNYkVAtxYuqwiZzh7xJjNZUenoRr1Zi8S6a2laI2BUq2itdfAlvYSxWuvyjWTbeYV+zDvBAwr5yKZMu1WZIumvNfbycEbxrwMa2aYWg855CeU/44iclGf11LLPNq6mfk1yl/HoRYFoNLn; 25:q8EuLwI9rS1xwntUceyvqpdtP2wLsqH26FFuzDtDVHns0qO4gtq9LLwh+Cf0gsqce5ZsYxhXtE4LaKyc6i4BUcME0tuTn9tBMYf8omWPl6wNaPSjhKRN+PSqiw32m6RG6rn4GJvCuH3htI9H9PqOGuO7aEAOVOee9x0oxZ6O/ox0gkP6UXebgjWX6bv5W/mBStMJdBBz4uMpWa1KRlDvAydILjnvhqDUMx+mj1DZWS0clTMypL0NlaDOaQOd7Aylj78LmttzfVI8SrvTpQr8RXkEc9upGfs7I2J6JpIukPZg0tcs868/G+MrsSKE5bg8nnqAxGez+eWMmblH+gzLFw==; 31:0O+TY6DsB9FSD8hLmn/nwgIXnAaKzJ3uf4w/yN2dyiP5wjbACIjD1qZTdj61xn14lDWxfq0uUkvyvPfGDwewHEs0NJpjAqiH8qzzwkFODxcBy0PNlD9VsmvwxkgZ4SzMwecSYpUmf5GBIp2cA88fMcMxVeM66MOkboZ8khVrveDSaj8azYxazCJHWNeAjRlCVStJBCiGFnB1RTu3406Za3CxzBbwd4HuNbPwTAEvRyg= X-MS-TrafficTypeDiagnostic: VI1PR0701MB2512: X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2512; 20:SlIcmFuzwHm/jkhTodjz8p7KULO8K7CNKneSHv3qvnA+B1Y4hNfLJewTtfngvoykbAkO5CU3Hzh4ZFI4EWdlifa/D+wFZ/jI5+dTX4QPHTx5FyRYrpXwJ4pt33JDrD/A9P9y6Rem8zf5Rux8XIQ4Y0aw15nhJ4Sz9rCBEufarvwNoXdRv+QoTPF/uMXAp+VQie6pE6djzBZTeeFa9Ki/A0Et0TBzj2jpWjgbeH/HtGYtRSqLONmhj2nE6gffSdgYkNi+5x/tKrFwmpA9GG7BNTicNT7YKVJKBI3/PTyxirkn5N4rh4N2T0SmIf1I+Go4thNmEEKmXIAuQrfx/mH/kyeVEdkM8afTOTw/5LBHuIAOEE3SGukqk6HtHrjjb3NSQjVfhK+uwJ/Toiu1CUiAMcHslRPPSexE45tsR42o5lqZh4xoQMtJ8fbF/kCqUpNHifHJzEdRxBqmtblmRszGlQqPO+2Ky8jM9oOciLkneJ499EtH6G0XBHvyNifqXnQa; 4:wDb0DyoSzkWP2sr+JVVxvKXyln4j4EiH+LTLXHI8l4uA0+UaBxJ1IGAgXkLTgoY82EykR+orOtnPYjxPMM/pAwMKjU7ApERPmLA1Qwk9dAmn/Vf4ak1gURxsVp8700/9XqfAMwmJ8PqVphZrbYzm2DxOBUZI+4Stf0Aw6jGX1N0IQhM9KA7PDTeSQyFbR3hyyHi1EHrlkj3vRgrMX1m3MYEMlm0K/6Vxwz/GXSGMFKZOvad7UahcIxj47bHYOSEDWGq+NgExYnu0pcLCTlKgKv4EmhUQGjWWQ424Lo8XERfEwJgz9F8FLtt+IpZW+jjJLknrLE20a9p77QmcSbY7tOnORRJUhWLM1tgMWo3AcAw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(120809045254105); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231355)(11241501184)(806099)(944501410)(52105095)(10201501046)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:VI1PR0701MB2512; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2512; X-Forefront-PRVS: 0808323E97 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(136003)(39860400002)(366004)(346002)(376002)(396003)(189003)(199004)(26005)(305945005)(49976009)(7736002)(186003)(86362001)(65806001)(3846002)(6116002)(65956001)(106356001)(66066001)(47776003)(58126008)(110136005)(6666003)(34290500001)(31696002)(229853002)(16526019)(50466002)(105586002)(2870700001)(6486002)(31686004)(486006)(446003)(53936002)(2616005)(65826007)(11346002)(44832011)(6306002)(956004)(476003)(81156014)(3260700006)(2906002)(5660300001)(8676002)(81166006)(97736004)(6246003)(16576012)(966005)(316002)(4326008)(478600001)(64126003)(8936002)(68736007)(386003)(76176011)(52116002)(23676004)(2486003)(52146003)(25786009)(14444005)(67846002)(36756003)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2512; H:[135.244.225.245]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjI1MTI7MjM6VnVNY09zTVNKQlI2enpubnc5RE1KeHB6?= =?utf-8?B?ZkJmN3BXbCtKd2VwOUpQcGs4ek1wUHpiRmI0a2JwK3JoMWxHcEI0VWIvOXly?= =?utf-8?B?VHE1bVhld2VJQWJRMWsyOGpxSmJmbnpRK3ZURmRLTlN5c2M2cDVpSmUxbDFi?= =?utf-8?B?cy9wWmRSbzZSL2RxRlA4cWhXZE1wM2IyQ3pzQnZub3cxRnNOQy9NWGhuNmJm?= =?utf-8?B?d3JsdlFLYkxQWG0wcmRaK2ZtL1RkNlRwSkwwUER2ODVhQkcrVzJkcU0wQktW?= =?utf-8?B?U2U4M2gyWGM2aTNGMzNjcGpBd1NkQlZ4MjZ1NkRWRkQ5Njg2RkMwRDIySWd2?= =?utf-8?B?b3J6UzN2d05PUWZnajQ4NSsyZHVMN1NubHkyWDBLSFJpVUJlNlJZVnBuMXFN?= =?utf-8?B?OFdNbmM3UnM2K3dMN0VUMWNLZURoV2dlbkhPZCtib1ZQV3V0U3RvOUwzc3ho?= =?utf-8?B?TXNOU2wySnFoTzU3OEpoR1J5NFlEZkxGekF6N0UwcHhjQXc4U0w4UlplWENh?= =?utf-8?B?ZDVqeXRMMGdzOHhwRGZIc3BxNzNHRm1OeWkvZ3VKUVJQRmZVNVpSNGdqMi9a?= =?utf-8?B?S25tSTJhbHlJOWsrakRtUURKbnhlOVZvNzBWRllLRDQ3T1ZHT01uRUNjdHM3?= =?utf-8?B?Zm50MzdreGJsWnVFMU0zOU0wbHRRUUtEWnlMaHVvWWxXYktoR09qeXBZaDF3?= =?utf-8?B?YittTWE0Rnd4UkZPRGF6VXVzV2ltaW8vZkNhRHMveGREeSt2SHd4SFhyYnBW?= =?utf-8?B?V2hvaDZDSFZKTm12THFlUU54M00vcDVsU1RwZmF4KzlNaWVXM3U2VWVueHlQ?= =?utf-8?B?TERjOVMvOC81eFRoK2Z2R0cvekVwSE9vUnlxRFNRU2dsQTZoM0hLREw5Wmpi?= =?utf-8?B?ZklPUzA1ZUlHNFdwN0NweEhiaytwUE5FMVB1MGZxbFRmUC9hek5JU0hvYW9j?= =?utf-8?B?bm5vODJvaldlZ2NYNDV6ZzRBSExuV3dtbkRxVHE5V1hzeHd6Lzk0YkFJWWdj?= =?utf-8?B?RktvZnNDQlErTmc5ZGp0L2E3eTJRb1lmTElQZjRySGg4aDNlckZJRGN3amQy?= =?utf-8?B?dTRhRTZsQWVSbkMvQ21VQ2tnSGdlVG52L3NHMkJGZmo0bTdVcjNGd25MeGxS?= =?utf-8?B?a0JNYXNQUTNCOTBZam15NGpha0o0QTd0NllYNjdGeWlZRVpNOER6T1hXeU5T?= =?utf-8?B?bkRQV2trTEI5NTFIWGFYT0R3QUNlQmlDanJ1TVd6MTYvMUF4R0tMWFFLMnND?= =?utf-8?B?MWFINFFDWm9rRnp4R3NZV0lTREVyNFVEMm1GOWZpeDFSWWxFa2xWVlE0M1Mw?= =?utf-8?B?cGJQbCtybVFtOVNtc0UzbkVodTdqUTJZWi9ZNTJvR1RTbXBaanZmR09IRWVv?= =?utf-8?B?NTBsOGtKd0phcUN4OWhGR2ROS2hXWExiRTlJT2dHS2xTOXBLNVVvMExPS1N2?= =?utf-8?B?NWhjYVFYVUFQcEdVbnlqYVdKdy96Q2tvcG84TkRTSndoQ21ySGFvb3FUbzdT?= =?utf-8?B?SlB5TEk4UnNuTUkxNEprMXVYdWZXVWJyNUZtWHdRam9ZY3dERVk5VVFYcUdI?= =?utf-8?B?ZFJpQytydjZ3VDRVQzNUN0Z0N2VOVnJUR0NpdEtWemNCRWhDQ2RBZllHYnVh?= =?utf-8?B?VkpxelkzdTMzMDN1aFpYVC9Gb0pQRmJ6WUtkTWtOV3hsNWk5Z1QrZGFNZm1k?= =?utf-8?B?cnAyQjU5blE5WUpLRGQyaitmMlY0SjUwejJETVRkNElvWGVWSjZtNFhFM2ZR?= =?utf-8?B?cGJJTldubHp2RnNxaHBEWGxjMkdOenVUMng4U1l6bytHM2FEZ0h5VmN2aElS?= =?utf-8?B?L0dyVG4vZnhaVlNEb3hVaVZPMnBtMnR0NlcxK00xQ1lUMjRmSnUrWkx5WUxY?= =?utf-8?B?blc3Ukp3eVI2ckU1cVpiZmNpWU9BemZmaUZPYUxXQ1NzSjBhcEtFSkhvZ1lk?= =?utf-8?B?ODFvSGs5R0N1clRiZExkZkUzb3NGclE4RVpLVnFWU2FsbU5TSVZ6STdFZVgw?= =?utf-8?B?aE5CQkNMSlE4RVFuY3dTY0JvMGdVWmFiUGdSWkRXdUZxOU5PaFExZWxHcnNQ?= =?utf-8?B?SHlkVDFzMHdIT3ozdlk2enQvcXRMTE5sMG91dlFOaHhPM2hnWjFpVjM4UXda?= =?utf-8?B?L1ppQT09?= X-Microsoft-Antispam-Message-Info: XHfGXr5QXKOOPPhUAJPuuW6CWC4NMJgQyI2/Mv9umg2cncNfscLe1i+cmw0XZDaCqyMsirZc1LCBgK9bzBrI/ES3KxgKSDEu5EBiV3PlouKx68mVGAyMQQJeeJ2HTjzIf2X0zEcoXSeVqMym/cO+S1ouCVIR6MbVM58vJQ84ItI1FJ62XQqtQ+H5JEt1x8Op2U0XLBWr4vqdSoydbPFplC2tBi2tycU/E5dmc4BJztcKmfqw2reVevToo+39MEEHzDT9JaZVDLH+ekDHOe10ETNLlwUGf/3MaRf9Lhu2TJBmsJfjNCSaVrjgUDQaV90mqoaEpT53o4YS2jM9bCcxihBcBSum7B9eVms3tQJWozLnNLveG3vECQ2nff+KpsvVLsINk1/6c7P7yxAXtZhaLQ== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2512; 6:M+dXRa4ZYzREUFQds0t34UIUZghZ5fCz1i3YOgOEiNCrsYQYJJlkq4Aamb6PZhPsmvrloQCQN313Fo8rlZkEyT1bmU2MTj3IOH12rmaKUCTwTIrFUaa6AB0sXYCf/Z91qzH58Lo1rny/eeSf0bc8tZabtFaPB6V7v20qaXtjEExVH1U7yDgyVa68OUQfS777VPetiiBwArEfa/z+MiVvQXUwMIw5ywO2amQ+yyTVgC7uL+OG+HrAHzrOZxreuElQ0WR1I6FOQOufbKdlNRMKK8e95XRwLyxihjQmr+/IeiOxNu8lhyocfQTdZ5MpsXu/SNynyBmMLXNbL5m/+wzVJZlMCpPm8xpaWfqrdO8W7p6GiErFrSOXsoNrwK0YWLc4eehdF56JsRO0Ll1JlYSFqMBIlO9xSVnJTTSFLtGTU0omCLUr/k0c8LNGhPEyOSMt7ooHLnU2C3NdwiD5j2mASg==; 5:j36v0PRKcM+SJi9Ce8CdMFzf/PX0qBByN+xDuVRxHfniWMdN/C7mH1n1HXW8ytgH1G+pglSgh2UkiLkCZnTBpxht+B9pBw17Xofp4hhjhT/iwDTpbNEJLoQ1Sw77V/qjEAL0K/ZMriMR1meZTcypVnT6yuP4h+pRYQr9bbawnBI=; 7:vKEyef2qtInibWTRJfO1lY2+6amV7cs16WJ0NsSo2xMfoKR9oZMVVTsL05G522ih/b+3p79JZhhwRwv4gP2B8q6F32wkq53M8u3izv2RMy/5t9uqCNQMRTeqVXYap6R9AoAn5zhy4d9IwjDsuLCPLzXJqgKPX+2FqtP9tdVBSrcVLuGClWXfh/nD5rdYL1oDHF6t86OqqpGemVqMnkEDrF2g2DW0FQMV1GiiT/JgqtZhRb4LpPhSIcWTmMsduo3Z SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2018 13:17:41.2737 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 93a94a3a-df46-4b88-0661-08d6247b9ad1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2512 Archived-At: Subject: Re: [spring] Alissa Cooper's No Objection on charter-ietf-spring-01-02: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 13:17:46 -0000 Hello Alissa, If the WG identifies security aspects arising from certain deployment scenarios, yes it shall formulate requirements for addressing these. SPRING is upstream to the protocol WGs so its documents should not depend on the protocol extensions, and, in my view, are thus likely to progress ahead of time compared to those. -m Le 2018-09-27 à 1:49, Alissa Cooper a écrit : > Alissa Cooper has entered the following ballot position for > charter-ietf-spring-01-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm not clear on the implications of the text about security considerations. If > it turns out that people want to use this cross-domain, will integrity > protection be specified as a requirement? Will other security properties be > specified as required in that scenario? If it turns out that the threat models > require enhancements to the security properties of the underlying protocols, > will the segment routing specs still be progressed even as those requirements > are pitched over to other WGs, or will they not? > > >