From nobody Wed Feb 1 07:49:30 2017 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 EA3E3129E56; Wed, 1 Feb 2017 07:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 O6CWYeDIM1dk; Wed, 1 Feb 2017 07:49:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5201294B9; Wed, 1 Feb 2017 07:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1279; q=dns/txt; s=iport; t=1485964167; x=1487173767; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KlJrX9rW+HEgUSbnNrLkJdS99JKqXfJZvggEINs9Zrg=; b=EVKZ0t8EscaP9JRvbpbKNkhJF/ju30nSL5ONmJgXK6GjIVeivWh+lGBD wx6/yRWagGFoxPU9zNh2AlzHMJoRZqktrD9YYvQD/oFDHIb7HPi7Yw4bp 3nIWpkN0Ckt8P5KDRnanshCGXyuWsa503SRK6B0HIHl5dvyDwNzbms8jJ k=; X-IronPort-AV: E=Sophos;i="5.33,320,1477958400"; d="scan'208";a="206906525" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2017 15:49:26 +0000 Received: from [10.65.84.236] ([10.65.84.236]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v11FnMH7017932; Wed, 1 Feb 2017 15:49:24 GMT Message-ID: <5892037D.3000609@cisco.com> Date: Wed, 01 Feb 2017 07:49:17 -0800 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Horneffer , Martin Vigoureux , spring@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-spring-segment-routing-mpls@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 15:49:29 -0000 Hi Also support as a co-author Ahmed On 1/30/2017 12:58 AM, Martin Horneffer wrote: > Hello, > > support from me as co-author and operator. > > Bets regards, Martin > > > Am 27.01.17 um 12:05 schrieb Martin Vigoureux: >> >> Hello Working Group, >> >> This email starts a 2-week Working Group Last Call on >> draft-ietf-spring-segment-routing-mpls-06 [1]. >> >> ¤ Please read the document if you haven't read the most recent >> version yet, and send your comments to the list, no later than the >> *12th of February*. >> Note that this is *not only* a call for comments on the document; it >> is also a call for support (or not) to publish this document as a >> Proposed Standard RFC. >> >> ¤ We have already polled for IPR knowledge on this document and all >> Authors have replied. >> IPR exists against this document and has been disclosed [2]. >> >> Thank you >> >> M&B >> >> --- >> [1] >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >> [2] >> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-mpls >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > From nobody Thu Feb 2 04:16:13 2017 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 D6D0C12896F; Thu, 2 Feb 2017 04:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6lSB4VTopYr; Thu, 2 Feb 2017 04:16:05 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 86E4A129410; Thu, 2 Feb 2017 04:16:03 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id v77so3736474wmv.0; Thu, 02 Feb 2017 04:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZF+4mH/C7Df7WPCEEoa8n3wG6pFIOsDu67jgpWnUS4s=; b=oDmCe4ropYQlpM7Mf6xDduN4D20ustajpvLcuLoW5wpqGcsi8u9xMC0vCqa7bJmAUf HsVVvlh8ytSZgMvxf1A0cejwiqM+DdtFYIWP93uU+oJM/pS1iqiw1+rXXg0qx1U2gElY x7EjNX9WGQZYMyQLuyHRIUU1ObcmRB0Uqlh1y8sgijXLD36TgAVZqdfMHqF0VdEUJ9Mx QGmKC31fW5RisCH5/pBZ0SX/jv9no7gr6oqYg1oDo/Omg/NhsMo07w5ObWmWdujWh+P6 CF7kWJO25dNIbXAmMfiFBCHZGZFwBNtK8k11o0KHdb3NvPjR5YINBCQPPdq5mkluYusI +r7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZF+4mH/C7Df7WPCEEoa8n3wG6pFIOsDu67jgpWnUS4s=; b=WlSB1BdDagQ8YE/dsoDu0a7Tzj0ZY2gFtbOZUgMBxktfqxqt4WJLaV3nUNX2YPSftP +AE6wLOh+YilzTP7Z9UKumFQ55IZuH2faljoZhULP4RBBCzeyeBdW4Vh+XXTOS12at0K BiPk7Pj5FjxqUkGqFjM2COVY06lsqzJiFZLXaf612J40nMu5A1CkyeRNTWcxw4+Ry/92 0LfzpmQRZ/LV6f5BgXlbUAtbzMAxlsW44zET03KtkYzvywhpa25OTELd7LetgCLa5dXG gS9WEd72wEUO5CbDmDJ5jZYPuyVcILQaAwDuU64pTsOBuFPsnkTNpDpYaIQgSNdCGrCU TMxQ== X-Gm-Message-State: AIkVDXL+8n1koZtNFpD6eD2rauXYQV24MnzwdJMQJJ1sHuPldjtE0QQx+Xyck+Mc7LthuQ== X-Received: by 10.28.23.70 with SMTP id 67mr25891411wmx.23.1486037759805; Thu, 02 Feb 2017 04:15:59 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id r24sm3154230wrr.34.2017.02.02.04.15.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 04:15:59 -0800 (PST) References: From: Stewart Bryant To: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" Message-ID: <55fdb032-20d7-bfa2-c3cb-bcea3dd2b553@gmail.com> Date: Thu, 2 Feb 2017 12:15:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" , "spring-chairs@tools.ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:16:07 -0000 Here are a number of WGLC comments on this document. - Stewart Segment Routing with MPLS data plane draft-ietf-spring-segment-routing-mpls-06 Abstract Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. SB> This is SR MPLS. The above text implies a special header. Surely SB> it appends a stack of MPLS label stack entries that encode the instructions SB> as label values. A segment can represent any instruction, topological or service-based. SB> and more! SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. SB> The above does not read well. SB> Surely something like: SB> SR allows an ingress node to steer a packet through a SB> topological path specifying which service actions or other SB> operations need to executed on arrival as a each specified node. Segment Routing can be directly applied to the MPLS architecture with no change in the forwarding plane. This drafts describes how Segment Routing operates on top of the MPLS data plane. =========================== 2. Illustration Segment Routing, applied to the MPLS data plane, offers the ability to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress PE, without any other protocol than ISIS or OSPF ([I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE signaling protocols are not required. SB> Strictly no protocol is required as we did in MPLS-TP. SB> What you are saying is that by embedding additional SB> information in the the link state igp in use, you remove the SB> dependence on LDP, and RSVP-TE, although of course RSVP-TE SB> does run-time bandwidth accounting which you have to move to SB> a central place. SB> I suspect that the reader would be better served by putting the SB> rest of this after explaining how the protocol mapping works. ================== Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following benefits: Simple operation: one single intra-domain protocol to operate: the IGP. No need to support IGP synchronization extensions as described in [RFC5443] and [RFC6138]. Excellent scaling: one Node-SID per PE. SB> Is this all it seems. If you are going to steer the packet SB> I think you need more than one node-SID to get the packet there. SB> I presume the point is (and it should be brought out) that with SB> liberal label retention you have a label per adjacency that maps SB> to the remote PE (in the RP), although only one is in the FIB. If you have SB> an RSVP-TE path you have more than one label per PE, you have SB> one per constructed path, but in the FIB you only need to specify SB> a single label imposition, whilst in SR, you need to specify a SB> multi-label imposition. SB> As I understand it different vendors have different approaches SB> to label aggregation which may further complicate the issue, but SB> this text needs to be neutral on that point. 3. MPLS Instantiation of Segment Routing MPLS instantiation of Segment Routing fits in the MPLS architecture as defined in [RFC3031] both from a control plane and forwarding plane perspective: o From a control plane perspective [RFC3031] does not mandate a single signaling protocol. Segment Routing proposes to use the Link State IGP as its use of information flooding fits very well with label stacking on ingress. SB> Surely you propose to be protocol agnostic? For example SR will work just as SB> well with for example a pub-sub approach. o From a forwarding plane perspective, Segment Routing does not require any change to the forwarding plane. When applied to MPLS, a Segment is a LSP and the 20 right-most bits of the segment are encoded as a label. This implies that, in the MPLS instantiation, the SID values are allocated within a reduced 20-bit space out of the 32-bit SID space. SB> That is a very strange way of saying that in MPLS SIDs are 20 SB> bits, although of course they are often less than 20 bits SB> as other MPLS applications need to use the same label table. SB> If SIDs were 32 bits, then you would need to encode them across SB> multiple labels, which I have not seen proposed. The notion of indexed global segment fits the MPLS architecture [RFC3031] as the absolute value allocated to any segment (global or local) can be managed by a local allocation process (similarly to other MPLS signaling protocols). SB> You need some text to introduce the above rather than pull it out SB> of a hat. If present, SR can coexist and interworks with LDP and RSVP [I-D.ietf-spring-segment-routing-ldp-interop]. The source routing model described in [I-D.ietf-spring-segment-routing] is inherited from the ones proposed by [RFC1940] and [RFC2460]. The source routing model offers the support for explicit routing capability. SB> SR goes back prior to RFC791, which also included source routing. Contrary to RSVP-based explicit routes where tunnel midpoints maintain states, SR-based explicit routes only require per-flow states at the ingress edge router where the traffic engineer policy is applied. SB> What about bandwidth management? Contrary to RSVP-based explicit routes which consist in non-ECMP circuits (similar to ATM/FR), SR-based explicit routes can be built as list of ECMP-aware node segments and hence ECMP-aware traffic engineering is natively supported by SR. SB> You mean loose source routing, which is again an old concept. When Segment Routing is instantiated over the MPLS data plane the following applies: o A list of segments is represented as a stack of labels. SB> The items in the stack are technically LSEs. o The active segment is the top label. o The CONTINUE operation is implemented as an MPLS swap operation. The outgoing label value is computed as follows: SB> CONTINUE need a reference * When the same Segment Routing Global Block (SRGB, defined in [I-D.ietf-spring-segment-routing] is used throughout the SR domain, the outgoing label value is equal to the incoming label value. * When different SRGBs are used, the outgoing label value is set as: [SRGB(next_hop)+index]. SB> This is a continue, so isn't it label = label + SRGB_base_next - SRGB_base_this? SB> The order can be the other way around by this never gives negative numbers. If the index can't be applied to the SRGB (i.e.: if the index points outside the SRGB of the next-hop or the next-hop has not advertised a valid SRGB), then no outgoing label value can be computed and the next-hop MUST be considered as not supporting the MPLS operations for that particular SID. SB> Presumably you also need to take a management action since the SB> control plane should no allow the situation to occur. * The index and the SRGB may be learned through different means. Obviously, the SRGB MUST be the one the index is related to. SB> The above is a little opaque. o The NEXT operation is implemented as an MPLS pop operation. The NEXT operation does not require any mapping to an outgoing label hence the SRGB is irrelevant for this operation. SB> NEXT needs a reference o The PUSH operation is implemented as an MPLS push of a label stack. SB> POP needs a reference, and don't you actually push one or more LSE? o The Segment Routing Global Block (SRGB) values MUST be greater than 15 in order to preserve values 0-15 as defined in [RFC3032]. SB> What you are saying is that the SRGB base value must have a number SB> greater than the top of the special purpose label space (0..15), although SB> as it was expressed it looked like you wanted to have room for them SB> in the SR label space. SB> Indeed I think the document set conflates SGRB with SRGB_base and SB> ought to define both terms. SB> I think it might be worth noting that the obvious implementation of SB> RFC7474 would be to move the ceiling of the SPLs rather than SB> creating a new table in h/w and thus it would be sensible leave SB> some space between 15 and SRGB-base. ====================== 4.1. Example 1 ... In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- awareness ensures that the traffic be load-shared between any ECMP path, in this case the two north and south links between R2 and R3. SB> Ah now how is that ECMP being calculated? If it is based on the SB> labels in a stack without an EL, isn't there a tendency to reduce SB> the entropy given the guideline to allocate the same SRGB everywhere? ===================== 5.1. LDP LSP segment combined with IGP segments The example illustrates a segment-routing policy including IGP segments and LDP LSP segments. SL1---S2---SL3---L4---SL5---S6 | | +---------------+ Figure 4: LDP LSP segment combined with IGP segments SB> This and the text that follows is very confusing. It would be helpful to define your SB> SL, S, L notation up front. ================== 5.2. RSVP-TE LSP segment combined with IGP segments The example illustrates a segment-routing policy including IGP segments and RSVP-TE LSP segments. S1---S2---RS3---R4---RS5---S6 | | +---------------+ Figure 5: RSVP-TE LSP segment combined with IGP segments SB> Again starting with the notation would be helpful to the reader. ============= In the MPLS instantiation, as the packet travels through the SR domain, the stack is depleted and the segment list history is gradually lost. SB> Strictly the history is not gradually lost, it is never there. SB> When you see a label stack, you know the future of the packet SB> but never the past. ============== 8. Manageability Considerations This document describes the applicability of Segment Routing over the MPLS data plane. Segment Routing does not introduce any change in the MPLS data plane. Manageability considerations described in [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when used with Segment Routing. SB> Maybe I missed it, but I could not see any discussion on the implications SB> for LSP-ping. Does that just work out of the box or does it need changes? 9. Security Considerations This document does not introduce additional security requirements and mechanisms other than the ones described in [I-D.ietf-spring-segment-routing]. SB> I think that the MPLS element of the security considerations might be SB> better placed here with the rest of the MPLS text. SB> By minimising the range of the labels used, isn't path guessing more SB> of a concern, and isn't there a greater chance that a misforwarded packet SB> will get to a destination rather than be dropped? SB> SB> Doesn't SR make it a tad easier for the pervasive monitoring people SB> to figure out where a packet is going than in an LSP or RSVP-TE controlled SB> network? From nobody Mon Feb 6 05:20:55 2017 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 93B57129D71; Mon, 6 Feb 2017 05:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 kx9F6rKPtGsn; Mon, 6 Feb 2017 05:20:53 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0124.outbound.protection.outlook.com [104.47.0.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96848129D70; Mon, 6 Feb 2017 05:20:49 -0800 (PST) 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; bh=NwkqgM1eWJoA1YuHk+wAKfqiKs2iHvczqzv04JChwIY=; b=V+N5xuq1+VH/CQ2VjNjTmueJ/74BKOit6g9B5uyMc5yffMY0+eDP8O/Q8IPV3Lbz2DSyA5RBCy4qFTDxrFjsmfzVJ4Z00OosE/kUIGSnWDyHOPxtscbv8vhIlvUDHeTv2S6Jc0VCmyNOKR6LFO4XCroiZaXY5oZX1odQxJ9J8S4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [192.168.1.5] (86.247.3.219) by AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 6 Feb 2017 13:20:46 +0000 From: Martin Vigoureux To: Message-ID: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> Date: Mon, 6 Feb 2017 14:20:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.247.3.219] X-ClientProxiedBy: VI1PR0602CA0016.eurprd06.prod.outlook.com (10.175.26.154) To AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) X-MS-Office365-Filtering-Correlation-Id: 590b1161-333c-406c-8276-08d44e92f627 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2465; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 3:Iq9LRRINN7f6dgvrRTbvQYivD4pTyh2aD9c9R0QpKZgotDQYm7lp5N2jZTliJFyVMihxCgAWJpBHG43D1iBpQv4Ao6x16BtAyO1CYCX1GJCe9ypjdKnJpwDUWf1MIcdg7h0yPOUJtmmi45CUU+9sVX/i4JWqllArLMgHELAK/iZ35nA0dCajO9NzCp06vFiJ6o61pMYrnEtXohiXNQ5/ufCU3PvHZq/UdCGwKquXi6p3266sJJPi7CDyXAZ35F4JxlZj6YaoghHs2hX5DWZHEmrDteOL/1o8pbvW8dMVhCY=; 25:EWAQrbEZCDlX2G4b3s2ac9hK/22BWHWlObkYrJtkVwoyaB0+yWOSnq3XwbtSS1OHPdVK0zhD0TXAT9AAlhMlPrwO2iN/jXzWWNdDd3O0O0CXdYB1qEQAz9BOwnQT+kEltohL1O787oDfctsU/LnewkKgLwVdeFne8bssZmKJIjWOO+yFWMD80UZdHlBshLjpzVQ/+rsr0+C0zulV/rBAuNpmlAmM5Ww7H8DjWMJguOczKHazwy9jzR8lA9mfWR5vtN9ctHBPtUq100KDQdOTHMwxVytGo/nWB1RC3UqlayBxybznBijxoZnCICDaoOj8WGcjsC91Ze876BbuzIpAmiDN+Ts3NR6z9bUChPdMGMPHEW1eJo5kDD0thtTfbgeAZunFQqYamT0Wv/8EWv90a2QnFnhfwbLrEDZdMzi11pBH2LkUNOJfZPiatF92j4NAueyL1TiAYlO/Jt1ZB3pSYg== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 31:p95sUFeIkxb375/z4GHoTs7RNuEZcsjxHXH7umAbUR7deKyYEfqkPDPuI8lGfxU+mkg0Z5HGWwNv28gf/hQ6/w+I5SkM6ZytcaLc0Zc9W2iMkBCqJyqtTOAflLmcamOPoCwFQku6IZVAr5OQ3EYL4zecffcoBXwtySRxjaRly6A32Nz/cfJulXIY1cQgxz/cjuLzS9v/VK1yBSVAq5MFcjsI1n1YhTOmvTxeIJA7uzwnN0g2EVeiE8zT6JQk6ZwEjAPYdQqf9aT5rrHot5HRow==; 20:1Q9Vnxz6BuEO8sstaMRSIlFblJEjbnY3v1KNq+cok3xWYQ7iqeoCffvVfXJnQTXZCdrXgH/wR4j8Bz95Kzlo0bBeJ2Ybvo6UjoM7Ak4ZUcOJ6r81pXwwUAOJZZkoBizx/MqmQBGl/9Jhic94MEkZL6Ebv9oLSiOpm2crWUKv/gTxhDXsdUd6jC97AyiF6ZuVuPzvJh2yVsbnDxLGstXNbbT3gOQvuiRJ31gh3MMKizL3WDiESKDK761qADcpGDvybnkggg00aH2otCEGQKsUAF5LCiLX1K/h56f6GNnVFbjeaTUZ/N8RofldToMl3wv3zPU1dSMVwZ8sSNfaUqD96oU/TP6HM1YXsJnMjmfV3yS7o6zKTB+OGqeuanFySu6xo7Mane9pRYzI1Wv6U7Edodx9wQL1t9rILrDUJ7IY/Ds6FW8z94wr6B+lByEUjtcLTK4SP66yT2zJYXi2aGjygaN66AphHf8evMK96eCy8MmAJ8d7IyrKzyd1FoQ/H8PA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM5PR0701MB2465; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2465; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 4:en6r6dxpA5gtBFH/3E/KclELYi/asvtcEs8HQsualr2zQB8ymtHeuT3KsS9YSDGuBX2LcRyYYdLUTbt5s3+O+AKhCOVD+DSCMA8748xpXgpw8KDkGzDo1dV5Vna/A9p1D86TaG5RosCNhhm3dXmJy8fqd+kdr6aElpvDDA/YBzQPvicSX8X5RC7mX3bhakM5Y6fwb+UQOwj+/Pp64/LHRPIslLn8/tWc4AgbBEmeAB8FirIj4w8sM9RoYiQO9uZTGEvZ+a7iBitMod7PyPTrBJ8oDMH2DFrUOS88st1fG9mgOle+Gy0YsEBT2X15O/BZ2GgBEB60q8LdtJmmxEaRWmUn4uRfU8I2pjeQ85vsLZ4JWhUKuwMz7+1VDIr/KnhcqmB+hyfopoy1aO99UrHv3C1hX6brvda7H1YngFABm3nKw+26ZsXnDLcP4Z7TFVacj36V8nBO4o5nrCUDQQUxl4s6+MZmKaM7PK1EtsaW7j/tWo9yNoF2KMBRWJifp635c2YARKaVji8nkXT78zsOO+OP8LEk44GX9Xb008UiSq51p4//C1Uyyt3MfY92nWShxN3UnPKljqWo/WGM7FUPeOWUlfgI2kqI4epTAOhK93IJ7mQ+HV7AkDrzYQI3w0Mh7psxwpG1xVjtnNWPOTFx/21JEjMF4g8A3ppGB/Hp+iWuAntP6fgBcHIhIYYTrLr+RfUfSep0A3kbjlwoMWrq9A== X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(189002)(199003)(38730400001)(54356999)(50986999)(83506001)(31686004)(97736004)(42186005)(25786008)(86362001)(106356001)(90366009)(105586002)(36756003)(189998001)(33646002)(77096006)(6486002)(6306002)(7736002)(305945005)(2351001)(65956001)(450100001)(101416001)(66066001)(4001350100001)(65806001)(50466002)(6916009)(68736007)(6666003)(5660300001)(110136003)(65826007)(31696002)(81166006)(92566002)(53936002)(230783001)(47776003)(3846002)(6116002)(117156001)(8676002)(4326007)(23746002)(64126003)(2906002)(2870700001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2465; H:[192.168.1.5]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2465; 23:z1bFJI81VhoRuHLO/G8cVyrv0YsY7CjqbDo?= =?Windows-1252?Q?Ga/zsXre5vb+K0hzSduJlarVgq6roTHNjMkTKFEdkQeKk27f9lsUPqNP?= =?Windows-1252?Q?XOLwrw09knmx8wWmK2kqnwChN2yZhpPCJ5M2JZBp/2GdXqhM9fVL/DcX?= =?Windows-1252?Q?yP6z0NuOte1tsatc2Gho0zMr0jwXEX+jRA6I909gipA96XnCm7WhnkBu?= =?Windows-1252?Q?HhOlNbnB1dWgFIr/eHABydwKlUW+TgAg2pinW5gprl88RqSd8uHFusvl?= =?Windows-1252?Q?6S4dxqrfcGoP9D3i0i6LaADb/tQiIsvZWBtGs6ryhkal+pnTo4thcexI?= =?Windows-1252?Q?5M4SpZ35n0CDG+DeF103YOVhciJzoj7GYYC6vzpISTJO6VrA35Mifl7a?= =?Windows-1252?Q?4T8oZYiL57lf8H9qMsRN/ZDb9UoxUmRueTWKLf6FObUerl899sEz0uOo?= =?Windows-1252?Q?Vc0Jxvu0rZIYIordjy4wPmhK856p0vcCSAa1+TRABiCrgzqIRmNhhTkY?= =?Windows-1252?Q?61jFzHOZfrI0Ai2vXIWBdi3IiGAlThFDWu6AM6v4F7hPH1awtDNEvwx5?= =?Windows-1252?Q?/kiJOVO81hkbbL0bQG/PwoeMj3wQL/RS7WugNP2UpKCgXAwTuCW4T1IJ?= =?Windows-1252?Q?UCDLDYqWlxWGSSuP86pnnYJuCYm8gmZaXam1FtU5L3ue7Trc5kY/CUk7?= =?Windows-1252?Q?vucoNa0Gi9ExZRULoGhjxelk3NRxKkmlJYL3x/+MA1zKtJSPrkNRUqm6?= =?Windows-1252?Q?1XBirUdSMv9R/ehQNFpMDwRNjufD4jLbXz4PkrpvfdG2vr0oOd3K30oc?= =?Windows-1252?Q?Z1rCWbCuMHeCCEH7B2zID7xtEpDz3XdH6wZjqO4Q84J7nzjNK8oHap16?= =?Windows-1252?Q?YEBuvPQTM5d3xJJ41DHKy9gNMUpLJW5j3L5Qi0/lBMurM4G+uq/SbHbV?= =?Windows-1252?Q?BGlUwxabOE0eyylBVYkCrKROD1jcCG0W0hGzX+HWJ9OBZIckPqWZ48Tl?= =?Windows-1252?Q?77ZE3EczgKI0XChbcysAMYtampL+92VzkrmKKQbeUK99G8dzv3jN9LUe?= =?Windows-1252?Q?VyJoSpEoBbU1/xlM4lNAdBdm/ykTUp2UWmRG7h5eBTcJX68IueA+1wmt?= =?Windows-1252?Q?C1M0I0SurGp97cErl/J+6uDATV1/eGioHWNkeT5Ol5lE5cE//+o+B7Xb?= =?Windows-1252?Q?/yibtM8Nu2JvBVG3cL2ReyUB85UyhbNbYf8IoyWh2z2SHOcOeUGQ6+sf?= =?Windows-1252?Q?KL3gMEGS2b9EF5quyAhEfFJB5V19gPQbQzdfaB8sqNap+wi9rZkUDB7z?= =?Windows-1252?Q?jEOqqHGGhQDjg6ZPSHA489mI4fOeGJ3OV3R8JJubEe372wj7PG8TxAU2?= =?Windows-1252?Q?vo7yP3Hw9pjis7KweM6qSjpkLMG+nYLjaANW0PwtGXn6K/KRR6UuqDZ/?= =?Windows-1252?Q?FZWkVskpJovkyNDRGoI1qyp3jVPnYoJcIRJ5vv/KGYpvS45wATlpFa3f?= =?Windows-1252?Q?/4Oif+nRAZtusaMMwvbDB9YAb4qo7aUNBKjxQEVFBW9xfp8Z7HGW0FqK?= =?Windows-1252?Q?NbmNkFu2Pu5fn2T8O/2UfXi01Hl5TIkdRa4DV?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 6:Db0x2lHVxPNdAVswjvRCn5WFtjb8HFdcePpniau1TJFtmvzc834+a0dvc2tYGZ+peMTArNyE064UHF+RmykL+CuX5vTKDFaMnotZ70JNhz2lYMD6Oo/SAA850Yx2zLpWIcwoggM85rB2DQTOwTq3Iz1rO6IJshT2QmKN5XcGZCCDsmz1mx1hIK6T+x2w2GK3kIqupKTeaUyWzhfUVV9UBbe23uc7NtDYlOOJ8sbN31oiYoWCvfATWfTHvLMfE+DuNfT18yiavhh87vdz+ZTV6ENZfNAXrDHuC6WuG/leyJ+cyKnGoVyyz1k9f6dZ5mGTiSBeX1unDve1LNjlbolF6e05pBwdw9pPDoJJj++cTb0l2K4aru4TnhPT4gagtmy3FxRPzxcjCHYcwYzK24HSrtlHdIn3tMDJB9ArYUoOrp0=; 5:LtI+zwTyRTGQP973i3xGfgvgYOcSKhpzamdQSOGDh7tCFz1NqHuGG4SuPHsPoRBAqec2J965LluynrTE0wgPWfG9gJF9urromUUxfMvZT1VqyIo6GX7ZEtvQ1oO4PHQQRIAQT68zAuVOV1rVrBa5mRtE8c+fYeJjttr9tHoxMr8=; 24:t666QAtA7pXe3O1UfQnH8opiG+vQ9p1QnNmPZkkVRLeGrzaAOaNkFbk1eYMpUl8FN5EyNmxV02dhgMTwcQXAn4Q7O0SsWTYteDspYN4piJc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 7:DsjQ/eXH65aA+DERRZw18Nk5s3i1plCUg3cshuUI1TFWNSgwOLzg1IaZV3VH3MffBPHTL8kPfWDV2GJgdFgNxpGplEttcJPygrmbNTFLixiGmT+wYJMEFmPKZ0b34VXOTxgaUtYjcRwoPSaTtuBPiBuTApIKwTq/9FOydAYOQKi7XkqMQzO3p+NV/mdSQ6IXiXTNAnGDbmeyPbE0iOHPAG3Bz8JZLPN8hkDYyQZlA5JFABf5nWbdAo+jI0hs9fGCPhLdREWrVTWPlzh7u6Ah/NkH+ZYML/PAkPGNOOnArJEqO5Ed/2+6iXlJVSfHApKDMxHsaA0GK9mIaIeuC+TKUy+p0ZP78atYPINoga0UMg26pK7ottrAr+Qq+8OTiC6JNFJcbvsYw7ipPa5ronh995HAw+0WT5t6EeJkCO7rlNqSqviSImuM8D4MMdhNqOSWFEjNA4cxMm/K1nJOKM3Zlw3RJnIG1gr3BmBmD1Tznw0mNouH3lRoDjerF8F76YQj7svmyKoV/nkQMLDaVlJ8OA== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 13:20:46.6177 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2465 Archived-At: Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:20:54 -0000 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-ldp-interop-05 [1]. ¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *19th of February*. Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as a Proposed Standard RFC. ¤ We have already polled for IPR knowledge on this document and all Authors have replied. IPR exists against this document and has been disclosed [2]. Thank you M&B --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-ldp-interop From nobody Mon Feb 6 07:19:57 2017 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 9B275129E2F; Mon, 6 Feb 2017 07:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c5uL_9S29mQ; Mon, 6 Feb 2017 07:19:54 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12980127601; Mon, 6 Feb 2017 07:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1836; q=dns/txt; s=iport; t=1486394394; x=1487603994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fm7hzi6uyTWopp5Q685sWqwLwJ9ikLx7rDPOxAy+Fvg=; b=fbnYXp6CXU4klX42VGa/cgDN3YVqSc26AdUZnzu09brDjANCIhx49lBM m7WloTkCyGLOGzRaFOXd+XLKpDNAadVzfujj876SGtavtV7L5Ud5Koz/3 z50Wn57fUVqg06M3ludDP6XNBI0UWCd5kWdG9Hw8ZVRDGOeQLDUTmokd5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAQBGk5hY/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHg1GKCKdDggwfDYUsSgIagi4/GAECAQEBAQEBAWIohGo?= =?us-ascii?q?CBAEBGxc6CxACAQgcKAICJQslAgQBDQWJcw6RLp1ICIIjizsBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYEHijSDF4EPEQGDHoJjAQSbZgGGZ4shgXuFF4NNhiOTCwE?= =?us-ascii?q?fOHYITxU8hkJ1hmiBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208";a="382063343" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2017 15:19:53 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v16FJqnJ017970 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Feb 2017 15:19:53 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 6 Feb 2017 10:19:52 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 6 Feb 2017 10:19:52 -0500 From: "Acee Lindem (acee)" To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 Thread-Index: AQHSgIx21WBnDL5/g0uWzHhqqHGjLg== Date: Mon, 6 Feb 2017 15:19:52 +0000 Message-ID: References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> In-Reply-To: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:19:55 -0000 SSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50LiBJ dCBpcyBlc3NlbnRpYWwNCmZvciBjby1leGlzdGVuY2UgYW5kIG1pZ3JhdGlvbiB3aXRoL2Zyb20g TERQIGJhc2VkIE1QTFMgY29udHJvbCBwbGFuZXMgYW5kDQpTUiBiYXNlZCBNUExTIGNvbnRyb2wg cGxhbmVzLg0KDQpUaGFua3MsDQpBY2VlIA0KDQpPbiAyLzYvMTcsIDg6MjAgQU0sICJzcHJpbmcg b24gYmVoYWxmIG9mIE1hcnRpbiBWaWdvdXJldXgiDQo8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIG1hcnRpbi52aWdvdXJldXhAbm9raWEuY29tPiB3cm90ZToNCg0KPkhlbGxv IFdvcmtpbmcgR3JvdXAsDQo+DQo+VGhpcyBlbWFpbCBzdGFydHMgYSAyLXdlZWsgV29ya2luZyBH cm91cCBMYXN0IENhbGwgb24NCj5kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRw LWludGVyb3AtMDUgWzFdLg0KPg0KPqHoIFBsZWFzZSByZWFkIHRoZSBkb2N1bWVudCBpZiB5b3Ug aGF2ZW4ndCByZWFkIHRoZSBtb3N0IHJlY2VudA0KPnZlcnNpb24geWV0LCBhbmQgc2VuZCB5b3Vy IGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuIHRoZQ0KPioxOXRoIG9mIEZlYnJ1 YXJ5Ki4NCj5Ob3RlIHRoYXQgdGhpcyBpcyAqbm90IG9ubHkqIGEgY2FsbCBmb3IgY29tbWVudHMg b24gdGhlIGRvY3VtZW50OyBpdCBpcw0KPmFsc28gYSBjYWxsIGZvciBzdXBwb3J0IChvciBub3Qp IHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhIFByb3Bvc2VkDQo+U3RhbmRhcmQgUkZDLg0K Pg0KPqHoIFdlIGhhdmUgYWxyZWFkeSBwb2xsZWQgZm9yIElQUiBrbm93bGVkZ2Ugb24gdGhpcyBk b2N1bWVudCBhbmQgYWxsDQo+QXV0aG9ycyBoYXZlIHJlcGxpZWQuDQo+SVBSIGV4aXN0cyBhZ2Fp bnN0IHRoaXMgZG9jdW1lbnQgYW5kIGhhcyBiZWVuIGRpc2Nsb3NlZCBbMl0uDQo+DQo+VGhhbmsg eW91DQo+DQo+TSZCDQo+DQo+LS0tDQo+WzFdIA0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50DQo+ZXJvcC8N Cj5bMl0gDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJtaXQ9 ZHJhZnQmaWQ9ZHJhZnQtaWV0Zi1zcHJpbmcNCj4tc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9w DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5z cHJpbmcgbWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Mon Feb 6 07:20:52 2017 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 E0705129E2F; Mon, 6 Feb 2017 07:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy0w4Nz4lGoW; Mon, 6 Feb 2017 07:20:49 -0800 (PST) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 14292129E53; Mon, 6 Feb 2017 07:20:49 -0800 (PST) Received: by mail-qt0-x243.google.com with SMTP id n13so15303961qtc.0; Mon, 06 Feb 2017 07:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=01B4xwKEeIL/ncJvj6joE2Wu0171f1N1HUDDl6zL3Ig=; b=OUvJDa0lO1ju1+7gMmQmtt22klDvURVOXR6krMOlW8PxniNPoA+IdCEP41fSIZTYQW hqjQn7E2nrnaW2usMC7WpiN+Lq0DvM1/XbEFV+e3GhQKGdjHxjI8n3Uco6DXvk4J9EAI vKkdnKxthAfgocE4ClspzGrMqFnhvylG08pME2JlmGY0TnBwSKYkuAlIIwVmmveuCS8H ShiTCsXw8/uTKL6VxoCVpjmctfO3JtyOyAMELuTG2WBt4xGB5wy97uGyiuWC0iRi4cCl 1VzwLRvrqpeesylQSlJj0wuUea+fvuozea+U3794c72Gkrrul6Pgw/fE8FWu5TrJTkmg 3BdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=01B4xwKEeIL/ncJvj6joE2Wu0171f1N1HUDDl6zL3Ig=; b=fM5RFX+mw++T3WEs58R7w1guq3vXuEqTDIzDG8/ObfVt7/nwZq38cATi7w63OIlpQF lasfRESUVwOXuDDI8By7yZ6fB0Wj0VAq8gS8HADu0or8RN/AGv7kawfg9vnJ4hffM4r0 /TWjsh3lrPtdnwymQGIOv0rCj9+LHA3e1vJH/TU9jx1E3S6ymfvzhdzLiufECG41IMoT ahTXOwUd6BU2L2lSNGcjzTR3Qfm9zlzBCGpu6yAdAWJU0FzeqoxJJJ3tWarBPDaxmCIq GPoQVJn1EkJcrksy66NPMaghDya79zUMB0kpvF8hPddVahEt6wZbjlKSkQsJAWBYq3u3 tULA== X-Gm-Message-State: AMke39lJsLNh/JZq3TCC04j6sK+MwBdTefR36SCYBut9PjSfUH7yc807s65LYDGTrMTeGCKmT6GaAcU/hC5ydA== X-Received: by 10.200.45.247 with SMTP id q52mr10562442qta.197.1486394448193; Mon, 06 Feb 2017 07:20:48 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.28.69 with HTTP; Mon, 6 Feb 2017 07:20:47 -0800 (PST) In-Reply-To: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> From: Robert Raszuk Date: Mon, 6 Feb 2017 16:20:47 +0100 X-Google-Sender-Auth: gpI-XZxVC1hHD8ILdKPTdEHevLo Message-ID: To: Martin Vigoureux Content-Type: multipart/alternative; boundary=001a1139cdf014b2dd0547de2df2 Archived-At: Cc: "spring@ietf.org" , draft-ietf-spring-segment-routing-ldp-interop@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:20:51 -0000 --001a1139cdf014b2dd0547de2df2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support. Thx, Robert On Mon, Feb 6, 2017 at 2:20 PM, Martin Vigoureux wrote: > Hello Working Group, > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-ldp-interop-05 [1]. > > =C2=A4 Please read the document if you haven't read the most recent > version yet, and send your comments to the list, no later than the > *19th of February*. > Note that this is *not only* a call for comments on the document; it is > also a call for support (or not) to publish this document as a Proposed > Standard RFC. > > =C2=A4 We have already polled for IPR knowledge on this document and all > Authors have replied. > IPR exists against this document and has been disclosed [2]. > > Thank you > > M&B > > --- > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-r > outing-ldp-interop/ > [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddra > ft-ietf-spring-segment-routing-ldp-interop > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a1139cdf014b2dd0547de2df2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.=C2=A0
=
Thx,
Robert

On Mon, Feb 6,= 2017 at 2:20 PM, Martin Vigoureux <martin.vigoureux@nokia.com> wrote:
Hello Working Group,<= br>
This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-ldp-interop-05 [1].

=C2=A4 Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than the
*19th of February*.
Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC.

=C2=A4 We have already polled for IPR knowledge on this document and all Au= thors have replied.
IPR exists against this document and has been disclosed [2].

Thank you

M&B

---
[1] https://datatrack= er.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
[2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&= amp;id=3Ddraft-ietf-spring-segment-routing-ldp-interop

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

--001a1139cdf014b2dd0547de2df2-- From nobody Mon Feb 6 07:22:57 2017 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 92D1C129E63; Mon, 6 Feb 2017 07:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4a9tQ48cZJv; Mon, 6 Feb 2017 07:22:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28518129E53; Mon, 6 Feb 2017 07:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1026; q=dns/txt; s=iport; t=1486394572; x=1487604172; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a1noQENztElv7qT/RxccG6XzRpapxb8AZ/vPFOtDjlo=; b=Ol3KHijNl9OwRm0kSClytqtrz0rbIVQco4t5KT6ebAyj5UJQJTa+DwcU JQsfTvRanLS4/szIwvuRdxYfZMFys3sm4hXv9xZ0foNI57psJxM/T1Jb2 P08iSCnA4xaH/o3jmGTJowRQbDTXUtU0w/cqun+uEM+ncTAuJFHaje6Cr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQBGk5hY/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHjVmSDJU3ggwshXYCgkg/GAECAQEBAQEBAWIohGkBAQE?= =?us-ascii?q?DAR1cBQsCAQgYLjIlAgQOBYlrCA6xIYs7AQEBAQEBAQEBAQEBAQEBAQEBAQEBG?= =?us-ascii?q?AWGTIIFgmqDF4EPEQEcgzSCMQEEm2YBhmeLIYF7hReDTYYjkwsBHzh2CE8VPBE?= =?us-ascii?q?BhjB1hmiBIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208";a="203446448" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Feb 2017 15:22:51 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v16FMoVa029580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Feb 2017 15:22:51 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 6 Feb 2017 10:22:50 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 6 Feb 2017 10:22:50 -0500 From: "Stefano Previdi (sprevidi)" To: Martin Vigoureux Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 Thread-Index: AQHSgHvachxfO/Qhd0+FipvYm2XrFqFcbJqA Date: Mon, 6 Feb 2017 15:22:49 +0000 Message-ID: <5AA8B4C4-1BA5-42E0-8D43-33E6B0F67CF3@cisco.com> References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> In-Reply-To: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.80.236] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:22:53 -0000 I support as co-author. s. > On Feb 6, 2017, at 2:20 PM, Martin Vigoureux = wrote: >=20 > Hello Working Group, >=20 > This email starts a 2-week Working Group Last Call on draft-ietf-spring-s= egment-routing-ldp-interop-05 [1]. >=20 > =A4 Please read the document if you haven't read the most recent > version yet, and send your comments to the list, no later than the > *19th of February*. > Note that this is *not only* a call for comments on the document; it is a= lso a call for support (or not) to publish this document as a Proposed Stan= dard RFC. >=20 > =A4 We have already polled for IPR knowledge on this document and all Aut= hors have replied. > IPR exists against this document and has been disclosed [2]. >=20 > Thank you >=20 > M&B >=20 > --- > [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ld= p-interop/ > [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ie= tf-spring-segment-routing-ldp-interop From nobody Mon Feb 6 07:42:00 2017 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 332EF129E84; Mon, 6 Feb 2017 07:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HCv67lWrfCW; Mon, 6 Feb 2017 07:41:57 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CE6129E7C; Mon, 6 Feb 2017 07:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1132; q=dns/txt; s=iport; t=1486395717; x=1487605317; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=HD/cIqFFQDUIkDTHS6VDPnoOubJikTHdq8KpQTbdKJ0=; b=KrXYRhXrZkC+LKAkfKQjxW9BSGplpXMGd72wE0KQVoTWFB6dAhgzj2b6 pZMprxcpRX9aokQlzBpGc0hXXy9KrciY59i5M7GIB6iVlcx1DRn+doM+K wkObYnBZw+5rx93DcmYQPfqxbZpWmt4c6uB+W0jdu1nkyIK2B3e40ht/U o=; X-IronPort-AV: E=Sophos;i="5.33,342,1477958400"; d="scan'208";a="691993479" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2017 15:41:55 +0000 Received: from [10.61.211.152] ([10.61.211.152]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v16FftuV000898; Mon, 6 Feb 2017 15:41:55 GMT To: "Stefano Previdi (sprevidi)" , Martin Vigoureux References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> <5AA8B4C4-1BA5-42E0-8D43-33E6B0F67CF3@cisco.com> From: Clarence Filsfils Message-ID: <58989943.3080906@cisco.com> Date: Mon, 6 Feb 2017 16:41:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5AA8B4C4-1BA5-42E0-8D43-33E6B0F67CF3@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:41:59 -0000 I support this document as co-author. Cheers, Clarence On 06-Feb-17 16:22, Stefano Previdi (sprevidi) wrote: > I support as co-author. > > s. > > >> On Feb 6, 2017, at 2:20 PM, Martin Vigoureux wrote: >> >> Hello Working Group, >> >> This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-ldp-interop-05 [1]. >> >> ¤ Please read the document if you haven't read the most recent >> version yet, and send your comments to the list, no later than the >> *19th of February*. >> Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as a Proposed Standard RFC. >> >> ¤ We have already polled for IPR knowledge on this document and all Authors have replied. >> IPR exists against this document and has been disclosed [2]. >> >> Thank you >> >> M&B >> >> --- >> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ >> [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-ldp-interop > > . > From nobody Mon Feb 6 07:58:52 2017 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 C127D129EC5; Mon, 6 Feb 2017 07:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.788 X-Spam-Level: X-Spam-Status: No, score=-8.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, 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 NRgQrrc5q3hf; Mon, 6 Feb 2017 07:58:49 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA91129E94; Mon, 6 Feb 2017 07:58:48 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5704D8A203DC9; Mon, 6 Feb 2017 15:58:44 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v16FwkA0030799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2017 16:58:46 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v16FwiGe028158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Feb 2017 15:58:45 GMT Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.153]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 6 Feb 2017 16:58:44 +0100 From: "Henderickx, Wim (Nokia - BE)" To: "Stefano Previdi (sprevidi)" , "Vigoureux, Martin (Nokia - FR)" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 Thread-Index: AQHSgJHk4SnDvVOQBEueCJ4DAkW6lA== Date: Mon, 6 Feb 2017 15:58:44 +0000 Message-ID: <1DB4DFE5-0DC6-41E9-84A6-7EBD373D278B@nokia.com> References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> <5AA8B4C4-1BA5-42E0-8D43-33E6B0F67CF3@cisco.com> In-Reply-To: <5AA8B4C4-1BA5-42E0-8D43-33E6B0F67CF3@cisco.com> Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <2F6CE79D5EFF5D498A432F5CD62570B8@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:58:51 -0000 c3VwcG9ydA0KDQpPbiAwNi8wMi8yMDE3LCAxMDoyMiwgInNwcmluZyBvbiBiZWhhbGYgb2YgU3Rl ZmFubyBQcmV2aWRpIChzcHJldmlkaSkiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2Ygc3ByZXZpZGlAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEkgc3VwcG9ydCBhcyBjby1h dXRob3IuDQogICAgDQogICAgcy4NCiAgICANCiAgICANCiAgICA+IE9uIEZlYiA2LCAyMDE3LCBh dCAyOjIwIFBNLCBNYXJ0aW4gVmlnb3VyZXV4IDxtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4g d3JvdGU6DQogICAgPiANCiAgICA+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQogICAgPiANCiAgICA+ IFRoaXMgZW1haWwgc3RhcnRzIGEgMi13ZWVrIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGRy YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcC0wNSBbMV0uDQogICAg PiANCiAgICA+IMKkIFBsZWFzZSByZWFkIHRoZSBkb2N1bWVudCBpZiB5b3UgaGF2ZW4ndCByZWFk IHRoZSBtb3N0IHJlY2VudA0KICAgID4gdmVyc2lvbiB5ZXQsIGFuZCBzZW5kIHlvdXIgY29tbWVu dHMgdG8gdGhlIGxpc3QsIG5vIGxhdGVyIHRoYW4gdGhlDQogICAgPiAqMTl0aCBvZiBGZWJydWFy eSouDQogICAgPiBOb3RlIHRoYXQgdGhpcyBpcyAqbm90IG9ubHkqIGEgY2FsbCBmb3IgY29tbWVu dHMgb24gdGhlIGRvY3VtZW50OyBpdCBpcyBhbHNvIGEgY2FsbCBmb3Igc3VwcG9ydCAob3Igbm90 KSB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMuDQog ICAgPiANCiAgICA+IMKkIFdlIGhhdmUgYWxyZWFkeSBwb2xsZWQgZm9yIElQUiBrbm93bGVkZ2Ug b24gdGhpcyBkb2N1bWVudCBhbmQgYWxsIEF1dGhvcnMgaGF2ZSByZXBsaWVkLg0KICAgID4gSVBS IGV4aXN0cyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgYW5kIGhhcyBiZWVuIGRpc2Nsb3NlZCBbMl0u DQogICAgPiANCiAgICA+IFRoYW5rIHlvdQ0KICAgID4gDQogICAgPiBNJkINCiAgICA+IA0KICAg ID4gLS0tDQogICAgPiBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wLw0KICAgID4gWzJdIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRyYWZ0JmlkPWRyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcA0KICAgIA0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc3ByaW5nIG1h aWxpbmcgbGlzdA0KICAgIHNwcmluZ0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQogICAgDQoNCg== From nobody Tue Feb 7 00:40:13 2017 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 F2CB6129494; Tue, 7 Feb 2017 00:40:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148645681198.16324.3258303658175911919.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 00:40:11 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 08:40:12 -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 of the IETF. Title : A Scalable and Topology-Aware MPLS Dataplane Monitoring System Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-05.txt Pages : 16 Date : 2017-02-07 Abstract: This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and LSP path trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 7 00:55:22 2017 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 98453128E18; Tue, 7 Feb 2017 00:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ1q7Ml2-ZJ8; Tue, 7 Feb 2017 00:55:17 -0800 (PST) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D47129565; Tue, 7 Feb 2017 00:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1486457710; x=1517993710; h=from:to:cc:subject:date:message-id:mime-version; bh=5b6M4XUa+f6D0zzn1G1lsJGtg1ZQSjNrIkCDEBhoCNw=; b=kQtYkbRe2nXd3OEKxuztqONYKBO0DhgRdv/XMfenD9pkhk40ZZ9hC6yE QjUm7uC+e7pTUB59x4SO//xB0CJhIqtKV6dQ8HeFM/DxvoAJvjqjEw9Zc rX2MZu/H1lRSNMF8QeMmG4CRM1qHKGcVYfD2k7r9amGLSGVXFG9ZxPplv +DCCiUjpWagdWY1WrHhbdYWj94EmwzvRQFovgcK/BD//pCoYGCAXN2K2p v7q9/Y0kPIwGZL2yeOUo7MBexSAJyhH5h1Y891z8q6uc2tHZ9v+dZ1Udb F87F1WooeeuijR+SimHf10P87roaWlWVOzABXLqnjenCPxnY/qhX/f+Oy A==; Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 07 Feb 2017 09:55:04 +0100 X-IronPort-AV: E=Sophos;i="5.33,345,1477954800"; d="scan'208,217";a="1076900262" Received: from he101653.emea1.cds.t-internal.com ([10.134.226.13]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2017 09:54:58 +0100 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101653.emea1.cds.t-internal.com (10.134.226.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Feb 2017 09:54:53 +0100 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Tue, 7 Feb 2017 09:54:53 +0100 From: To: Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbgNDdW3AAKavA0A= Date: Tue, 7 Feb 2017 08:54:53 +0000 Message-ID: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.166.43] Content-Type: multipart/alternative; boundary="_000_21e86564238c4f1d8cb225372b809f1dHE101653emea1cdstintern_" MIME-Version: 1.0 Archived-At: Cc: spring@ietf.org, spring-chairs@ietf.org, draft-ietf-spring-oam-usecase@ietf.org Subject: [spring] WG: draft-ietf-spring-oam-usecase - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 08:55:21 -0000 --_000_21e86564238c4f1d8cb225372b809f1dHE101653emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, thanks for your thorough review. Your comments help to clarify how to use S= R to improve monitoring of an MPLS domain. We've adapted text, there's some= mostly minor discussion on a few issues. Comments are marked [RG] in your = text below. Version -05 has just been submitted. Regards, Ruediger Von: bruno.decraene@orange.com [mailto:br= uno.decraene@orange.com] Gesendet: Dienstag, 17. Januar 2017 17:35 An: draft-ietf-spring-oam-usecase@ietf.org Cc: spring@ietf.org; spring-chairs@ietf.org Betreff: draft-ietf-spring-oam-usecase - shepherd review Hi authors, As the document shepherd, I have reviewed draft-ietf-spring-oam-usecase-04. Please find some comments below. Best regards, Bruno --- =3D=3D=3D=3D=3D Major comment Multiple sections or text of the document seems to mix continuity check and= connectivity verification. I think the document would be clearer if both p= oints were more structured. e.g. introducing each, then explaining their in= teractions, then detailing each one independently, possibly in independent = sub-section. [RG] Good point, done (added section "Terminology"). =3D=3D=3D=3D=3D Minor comments =A72 "enabling MPLS topology detection based on IGP signaled segments as specifi= ed at [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]." You could probably add draft-ietf-idr-bgp-ls-segment-routing-ext, as an e= xternal server is less likely to be part of the IGP. [RG] Done. ---- "As compared to LDP, Segment Routing is expected to simplify the system by = enabling MPLS topology detection based on IGP signaled segments" I find the term "MPLS topology" loosely defined. As I read it, it could enc= ompass: - the network topology, which can be learnt by listening to the IGP, regard= less of the use of LDP or Segment Routing - MPLS signaling topology. With segment routing, it can be learnt by listen= ing to IGP. For LDP, it would require looking at the LDP configuration or L= DP status. - MPLS signaled labels. With segment routing, it can be learnt by listening= to IGP. For LDP, it would require one T-LDP session per node. Could you please elaborate on what is exactly meant with "MPLS topology"? [RG] Again, good point, done (at least tried to..). --- One paragraph is about the use of SRMS in LDP network. "The system applies = to monitoring of LDP LSP's ...." Another paragraph is about the use of SRMS in pre-segment routing networks.= "The MPLS path monitoring system described by this document can be realise= d with pre-Segment Routing (SR) based technology." It's not crystal clear to mean what you mean by "pre-Segment Routing (SR) b= ased technology." I could read "LDP", in which case, both paragraph are abo= ut the same subject. In which case, an editorial update would be useful to = merge those two paragraphs, as they are related to the same case. (or at le= ast very related) [RG] Clarified sentence, moved text, added a reference to the section textt= was moved to. --- "The system offers several benefits for network monitoring." I would expect those benefits to be spelled out in the document. The senten= ce is indeed followed by a set of sentences, but it's not clear to me wheth= er those sentences details those benefits or not. The first two sentences l= ooks like benefits. The third one ["MPLS path trace function (whose specifi= cation and features are not part of this use case) is required, if the actu= al data plane of a router should be checked against its control plane.]", d= oes not looks like a benefit to me. Could you please highlight which are the specific benefits? [RG] Good point, changed paragraph to bullet point list, focus is on "benef= its". --- "MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane." That sentence is 2 years old. Since then, has the MPLS WG progressed on thi= s? If so, could you please indicate the related draft. If not, why? [RG] Done. And is this related to a further paragraph: " Documents discussing SR OAM requirements and possible solutions to allow SR usage as described by this document have been submitted already, see [I-D.ietf-spring-sr-oam-requirement] and [I-D.ietf-mpls-spring-lsp-ping]." If so, both could probably be merged. Any may be "already" is not appropriate for an RFC. [RG] The statement has been changed. AFAIK the requirements cover more than the features added by I-D.ietf-mpls-spring-lsp-ping. I think it's fair= to keep them separate. And I don't think it's up to the authors of the use cases to decide about a merge. --- >From an editorial standpoint, I feel that the text mixes: - the monitoring part, which is expected to be forwarded in the dataplane j= ust like users packets. - the trace/OAM features, which requires specific features on transit nodes= , hence are not forwarded in the dataplane like users packets. May be those 2 functions could be better distinguished in the text. [RG] Done. --- "By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379],= a segment based routing LSP monitoring system may: o easily detect ECMP functionality and properties of paths at data leve= l." It's not clear to me what is meant by "properties" nor "at data level". Regarding detecting ECMP functionality, it could be detected with SR IGP ex= tensions, both for layer 3 ECMP (adj_SID) and layer 2 ECMP (draft-ietf-isi= s-l2bundles). Or may be you mean load-balancing behavior over ECMP links/path. But this i= s not what is written. --- "limit the MPLS label stack of an OAM packet to a minmum of 3 labels." Do you mean :s/minmum/maximum Why is this important? - If this is a hard limitation on the SRMS, then the probing packets would = also need to have a max of 3 labels. Which is typically not achievable. - Why would the SRMS have such a limitation for a pure software based featu= re? [RG] Changed text and still like to maintain the idea of using no more than= 3 labels as an alternative to specify a path by labels only. MPLS trace is a fair option i= n the case of multiple physical interfaces & ECMP between two nodes. --- "It doesn't have to support any specialised protocol stack," What do you mean by this? It does need to support the MPLS protocol stack, probably the IP protocol s= tack, the IGP protocol stack in order to learn the topology/labels, the LSP= Ping protocol stack if OAM test are required.... [RG] Changed the sentence. IP/MPLS packet formats need to be understood, pa= ckets must be built, sent and received, RFC4379 must be supported and IGP/M= PLS topology should be maintained (i.e., IGP listening, SPF and optional co= rrelation with MPLS traceroute). Static MPLS and IP routes do. Nothing else= . --- "The MPLS monitoring servers are the single entities pushing monitoring pac= ket label stacks." may be :s/single/only :s/pushing/sending and receiving [RG] Changed the section and the sentence, added receiving. --- "If the depth of label stacks to be pushed by a path monitoring system (PMS) are of concern for a domain, a dedicated server based path monitoring architecture allows limiting monitoring related label stack pushes to these servers." If the limitation is on the PMS, as already expressed I don't see why a pur= e software packet sender would be limited in term of the number of labels (= which are just bytes) sent. If the limitation is elsewhere, could you pleas= e elaborate. The second part of the sentence could be rephrased for an easier understand= ing. (it took me 3 readings to guess that the important part is running the= PMS on dedicated server. Although I'm even sure why using a software on a = server solves the problem compared to using a software on the routing engin= e of a router (which may also be x86). [RG] Changed the sentence, saying a server has no label stack depth limitat= ions. --- =A73 "It can send pure monitoring packets" What do you mean by "pure"? >From the next sentence, I'd guess that you mean "monitoring packets with an= y payload" --- "Segment Routing here is used as a means of adding label stacks and hence transport to standard MPLS OAM packets, which then detect correspondence of control and data plane of this (or any other addressed) path." Could probably be better rephrased. e.g. Segment Routing here is used as a mean of transporting probes or standard M= PLS OAM packets, along any path. When MPLS OAM packets are used, consist= ency between control and data plane may be checked. [RG] Good point, should be better phrased now. --- "if the PMS is an IP host not connected to the MPLS domain, the PMS can send its probe with the list of SIDs/Labels onto a suitable tunnel providing an MPLS access to a router which is part of the monitored MPLS domain." Probably some text should be added to cover this point. (e.g. the tunnel MU= ST be secured and provide authentication of the sender and cryptographic si= gnature. Also this has security implication as MPLS VPNs are based on the inability = of the sender to send MPLS packet, while this option open this door. This s= hould be discussed in the security consideration section. [RG] Fair observation, I've added some text. ---- =A74.1 "To be able to work with the smallest possible SR label stack, first a suit= able MPLS OAM method is used to detect the ECMP routed path between LER i t= o LER j which is to be monitored " This is not very clear to me. Could this be rephrased? e.g. What to do mean= by "MPLS OAM method?" Is this MPLS OAM API (e.g. LSP ping)? Is this an alg= orithm to define the path? (but the end of the sentence seems to indicate t= hat the path is given as input "which is to be monitored") is "detect" the = best term? Also, this really the first sentence of the section. Could you first introd= uce the global picture and the goal, rather than starting with an optimisat= ion "To be able to work with the smallest possible SR label stack" [RG] Rephrased the paragraph. --- "The packet will only reliably use the monitored path, if the label and address information used in combination with the MPLS OAM method of choice is identical to that of the monitoring packet." Could this be rephrased to improve clarity? [RG] Rephrased the paragraph. ---- "The path PMS to LER i must be available." "The path LER j to PMS must be a= vailable." Given that the goal is to monitor paths which are assumed to be available, = if you detect a packet loss, how do you know which segment has an error? In= deed, packet loss could happen on this PMS to LERi path, while you think th= at you are measuring the path LER i to LER j. --- "This path must be detectable" What does this mean? [RG] Rephrased the paragraph. --- "If ECMP is deployed, it may be desired to measure along both possible path= s which a packet may use between LER i and LER j." - ECMP may be more than both. - If you don't want to follow an ECMP path, why are you sending packet alon= g an ECMP path? SR allows enforcing a single path among multiple ECMPs. [RG] Rephrased the sentence. ---- "Further changes in ECMP functionality at LER i will impact results." Can you elaborate on this? Some LSR dynamically change their load-balancing= behavior in order to try to equally spread the load on all ECMP paths. Is = this behavior an issue? (i.e. are PMS and dynamic load-balancing adaptation= mutually incompatible?) Also if you want to monitor the (customer) ECMP path, would it be good to d= etect any change in this path, including a change trigger by such dynamic l= oad-balancing adaptation? And if you don't want to monitor the ECMP path, may be you should only moni= tor individual path. [RG] Rephrased the sentence. ---- " Determining a path to be executed prior to a measurement may also be done by setting up a label stack including all Node SIDs along that path (if LSR1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities." Adding all node SID do not remove ECMP functionnality. e.g. there could = be multiple links between LSR1 and LER i. [RG] You are right, added text. --- "Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with little effort and very excellent scalability." Why is the scalability excellent? It looks to me that some links near the P= MS will be "heavily" used to test all paths. "little effort" is not very specific. IMHO a key benefit is the ability to = monitor all network paths by deploying a single PMS, while some others tech= niques requires the deployment of many probes. [RG] Added text to clarify properties of the solution. --- "The PMS does not require access to LSR/LER management interfaces " The choice of the term "interfaces" seems debatble to me as it could be mis= read as physical interface being monitored. As the goal of this document is= to monitor path and interfaces, I'd rather use "interface" only to refer t= o physical interface. [RG] Replaced "interfaces" by "plane information". --- =A74.2 Same comment: if the PMS detects loss of probe packets, it does not know wh= ether the loss happens on the monitored bundle, or the path from the PMS to= R2 or the path from R1 to the PMS. So how do you compute/measure the characteristics of the sub-path (here the= bundle) that you want to monitor? [RG] You are right, added text. --- =A74.3 "In the previous example, a uni-directional fault on the middle link in direction of R2 to R1 would be localized by sending the following two probes with respective segment lists: o 72, 662, 992, 664 o 72, 663, 992, 664" "The first probe would fail while the second would succeed." I would have said the opposite as 663 maps to the middle link which is assu= med to be faulty. The formulation of the text is debatable as you are using the a priori know= nledge of the failure in order to define the probes which needs to be sent. More generally, as you are sending packets over a path longer than the one = to be tested, what you need is to also monitor those extra sub-path in orde= r to be able to check whether the failure is indeed on the sub-path that yo= u want to test, rather than the paths from the PMS to the first node on the= tested path, or the path from the last node on the tested path to the PMS. [RG] Thanks, added text and a generic statement addressing your second poi= nt. I don't want to describe a complete solution as part of a use case, I h= ope that's acceptable. --- =A76 "Next: LDP or RSVP-TE label identifying the path to LER j at LER i. if LER j is the ingress of the RSVP-TE LSP, LER j does not have a label ide= ntifying this LSP. Eventually, SR may allocate a binding SID to this RSVP-T= E LSP. if LER j is a transit LSR of the RSVP-TE LSP, how does the PMS learn this l= abels, which a priori is only know from LER j and its upstream LSR. [RG] I'm not an RSVP-TE expert. Next:... says path from LER i to LER j (a= t LER i), in case of RSVP TE a tunnel would start in LER I and terminate in= j. Changed text. If that can't be settled, I don't care about RSVP-TE and I'd rather remove = text than work on it. --- =A77 " MPLS SR topology awareness should allow the SID to monitor liveliness of most types of SIDs (this may not be recommendable if a SID identifies an inter domain interface)" Why would it not be recommendable to monitor an inter domain SID/interface? [RG] I'm sure that the principle works on interfaces within an IGP domain = (and that what the use case offers). As with RSVP-TE, it may also work on i= nter domain SIDs, however I prefer not to have to discuss that in detail, a= s I didn't think it through. Hence, if someone (not me) provides text on i= nter domain SID/interface or RSVP-TE. which is acceptable to the chairs/IE= TF, I'm happy to add it. If this must be a scetch of workable solution, and= I'm supposed to work it out, I'm not interested. I don't say, any of this = is impossible or a bad idea. I don't have time to work on it. --- "To match control plane information with data plane information, MPLS OAM functions as defined for example by RFC 4379 [RFC4379] should be enhanced to allow collection of data relevant to check all relevant types of Segment IDs." Is there a document working on this? (e.g. draft-ietf-mpls-spring-lsp-ping = ?) If so, it could be referenced. inter domain SID/interface [RG] Done. --- =A78 "While the PMS based use cases explained in Section 3 " I think uses-cases are explained in section 4. [RG] Done. --- =A76 "An implementation report on a PMS operating in an LDP domain is given in [= I-D.leipnitz-spring-pms-implementation-report]" This document is more than an implementation. IMHO it would deserve a short= text introducing its scope and result. e.g. "[I-D.leipnitz-spring-pms-implementation-report] present a PMS implementati= on report and compare delays measured with one PMS to the results of three = IPPM standard conformant Measurement Agents, using the IPPM methodology as = defined in [RFC6576]. The results show that the PMS measurements equal those captured by an IPPM conformant measurement system. The ADK test is successful by comparing the measurement values of the round-trip delays for packets with a size of 64 bytes." (but I'm not an IPPM expert, so authors should be able to provide a better = text) [RG] Thanks for the positive feedback, done. =3D=3D=3D=3D=3D Nits "IGP LSA" LSA is not defined nor expanded on first use. Plus it is protocol specific (OSPF). Could you cover both OSPF and IS-IS or= use a term which is not protocol specific? Especially since a priori you m= ean LSDB analysis, rather than LSA. --- :s/minmum/minimum --- OLD: used as a means of adding label stacks and hence transport to standard= MPLS OAM packets NEW: used as a mean of adding label stacks and hence transport standard MPL= S OAM packets to any node [RG] Text has been removed or changed.. ___________________________________________________________________________= ______________________________________________ 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_21e86564238c4f1d8cb225372b809f1dHE101653emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brun= o,

&n= bsp;

thanks = for your thorough review. Your comments help to clarify how to use SR to im= prove monitoring of an MPLS domain. We’ve adapted text, there’s= some mostly minor discussion on a few issues. Comments are marked [RG] in your text below.

&n= bsp;

Version= -05 has just been submitted.

&n= bsp;

Regards, Ruediger=

 

Von: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Gesendet: Dienstag, 17. Januar 201= 7 17:35
An: draft-ietf-spring-oam-usecase@ietf.org
Cc: spring@ietf.org; spring-chairs@ietf.org
Betreff: draft-ietf-spring-oam-usecase - shepherd review<= /span>

 

Hi authors,

 

As the document shepherd, I hav= e reviewed draft-ietf-spring-oam-usecase-04.

Please find some comments below= .

 

Best regards,=

Bruno

---

 

=3D=3D=3D=3D=3D Major comment

Multiple sections or text of th= e document seems to mix continuity check and connectivity verification. I t= hink the document would be clearer if both points were more structured. e.g= . introducing each, then explaining their interactions, then detailing each one independently, possibly in ind= ependent sub-section.

&n= bsp;

[RG] Go= od point, done (added section “Terminology”).=

 

=3D=3D=3D=3D=3D Minor comments<= o:p>

=A72

"enabling MPLS topology de= tection based on IGP signaled segments as specified at [I-D.ietf-isis-segme= nt-routing-extensions] and

   [I-D.ietf-ospf-seg= ment-routing-extensions]."

You could probably add &nb= sp; draft-ietf-idr-bgp-ls-segment-routing-ext, as an external server is les= s likely to be part of the IGP.

&n= bsp;

[RG] Do= ne.

 

----

"As compared to LDP, Segme= nt Routing is expected to simplify the system by enabling MPLS topology det= ection based on IGP signaled segments"

I find the term "MPLS topo= logy" loosely defined. As I read it, it could encompass:

- the network topology, which c= an be learnt by listening to the IGP, regardless of the use of LDP or Segme= nt Routing

- MPLS signaling topology. With= segment routing, it can be learnt by listening to IGP. For LDP, it would r= equire looking at the LDP configuration or LDP status.

- MPLS signaled labels. With se= gment routing, it can be learnt by listening to IGP. For LDP, it would requ= ire one T-LDP session per node.

 

Could you please elaborate on w= hat is exactly meant with "MPLS topology"?

&n= bsp;

[RG] Ag= ain, good point, done (at least tried to..).

&n= bsp;

---

One paragraph is about the use = of SRMS in LDP network. "The system applies to monitoring of LDP LSP's= ...."

Another paragraph is about the = use of SRMS in pre-segment routing networks. "The MPLS path monitoring= system described by this document can be realised with pre-Segment Routing= (SR) based technology."

 

It's not crystal clear to mean = what you mean by "pre-Segment Routing (SR) based technology." I c= ould read "LDP", in which case, both paragraph are about the same= subject. In which case, an editorial update would be useful to merge those two paragraphs, as they are related to the same case. (or a= t least very related)

&n= bsp;

[RG] Cl= arified sentence, moved text, added a reference to the section textt was mo= ved to.

 

---

"The system offers several= benefits for network monitoring."

I would expect those benefits t= o be spelled out in the document. The sentence is indeed followed by a set = of sentences, but it's not clear to me whether those sentences details thos= e benefits or not. The first two sentences looks like benefits. The third one ["MPLS path trace function (whose = specification and features are not part of this use case) is required, if t= he actual data plane of a router should be checked against its control plan= e.]", does not looks like a benefit to me.

Could you please highlight whic= h are the specific benefits?

&n= bsp;

[RG] Go= od point, changed paragraph to bullet point list, focus is on “benefi= ts”.

---

"MPLS path trace function = (whose specification and features

   are not part of th= is use case) is required, if the actual data plane

   of a router should= be checked against its control plane."

 

That sentence is 2 years old. S= ince then, has the MPLS WG progressed on this? If so, could you please indi= cate the related draft. If not, why?

&n= bsp;

[RG] Do= ne.

 

And is this related to a furthe= r paragraph:

"   Documents di= scussing SR OAM requirements and possible solutions to

   allow SR usage as = described by this document have been submitted

   already, see [I-D.= ietf-spring-sr-oam-requirement] and

   [I-D.ietf-mpls-spr= ing-lsp-ping]."

   =

If so, both could probably be m= erged.

Any may be "already" = is not appropriate for an RFC.

&n= bsp;

[RG] Th= e statement has been changed. AFAIK the requir= ements cover more

than th= e features added by I-D.ietf-mpls-spring-lsp-ping. I think it’s fair = to

keep th= em separate. And I don’t think it’s up to the authors of the us= e

cases t= o decide about a merge.

 

---

From an editorial standpoint, I= feel that the text mixes:

- the monitoring part, which is= expected to be forwarded in the dataplane just like users packets.

- the trace/OAM features, which= requires specific features on transit nodes, hence are not forwarded in th= e dataplane like users packets.

 

May be those 2 functions could = be better distinguished in the text.

&n= bsp;

[RG] Do= ne.

 

---

"By utilising the ECMP rel= ated tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing L= SP monitoring system may:

   o  easily det= ect ECMP functionality and properties of paths at data level."

It's not clear to me what is me= ant by "properties"  nor "at data level".

Regarding detecting ECMP functi= onality, it could be detected with SR IGP extensions, both for layer 3 ECMP= (adj_SID)  and layer 2 ECMP (draft-ietf-isis-l2bundles).

Or may be you mean load-balanci= ng behavior over ECMP links/path. But this is not what is written.

 

---

"limit the MPLS label stac= k of an OAM packet to a minmum of 3 labels."

Do you mean :s/minmum/maximum <= o:p>

 

Why is this important?

- If this is a hard limitation = on the SRMS, then the probing packets would also need to have a max of 3 la= bels. Which is typically not achievable.

- Why would the SRMS have such = a limitation for a pure software based feature?

&n= bsp;

[RG] Ch= anged text and still like to maintain the idea of using no more than 3 labe= ls as an

alterna= tive to specify a path by labels only. MPLS trace is a fair option in the c= ase

of mult= iple physical interfaces & ECMP between two nodes.

 

---

"It doesn't have to suppor= t any specialised protocol stack,"

What do you mean by this? =

It does need to support the MPL= S protocol stack, probably the IP protocol stack, the IGP protocol stack in= order to learn the topology/labels, the LSP Ping protocol stack if OAM tes= t are required....

&n= bsp;

[RG] Ch= anged the sentence. IP/MPLS packet formats need to be understood, packets m= ust be built, sent and received, RFC4379 must be supported and IGP/MPLS top= ology should be maintained (i.e., IGP listening, SPF and optional correlation with MPLS traceroute). Static MPLS= and IP routes do. Nothing else.

&n= bsp;

---

"The MPLS monitoring serve= rs are the single entities pushing monitoring packet label stacks."

may be

:s/single/only

:s/pushing/sending and receivin= g

&n= bsp;

[RG] Ch= anged the section and the sentence, added receiving.

 

---

"If the depth

   of label stacks to= be pushed by a path monitoring system (PMS) are of

   concern for a doma= in, a dedicated server based path monitoring

   architecture allow= s limiting monitoring related label stack pushes to

   these servers.&quo= t;

   =

If the limitation is on the PMS= , as already expressed I don't see why a pure software packet sender would = be limited in term of the number of labels (which are just bytes) sent. If = the limitation is elsewhere, could you please elaborate.

The second part of the sentence= could be rephrased for an easier understanding. (it took me 3 readings to = guess that the important part is running the PMS on dedicated server. Altho= ugh I'm even sure why using a software on a server solves the problem compared to using a software on the routing= engine of a router (which may also be x86).

&n= bsp;

[RG] Ch= anged the sentence, saying a server has no label stack depth limitations.

&n= bsp;

---

=A73

"It can send pure monitori= ng packets"

What do you mean by "pure&= quot;?

From the next sentence, I'd gue= ss that you mean "monitoring packets with any payload"=

---

"Segment=

   Routing here is us= ed as a means of adding label stacks and hence

   transport to stand= ard MPLS OAM packets, which then detect

   correspondence of = control and data plane of this (or any other

   addressed) path.&q= uot;

   =

Could probably be better rephra= sed. e.g.   

 

Segment Routing here is used as= a mean of transporting probes or standard MPLS OAM packets, along any path= . When MPLS OAM packets are used,    consistency between con= trol and data plane may be checked.

&n= bsp;

[RG] Go= od point, should be better phrased now.

 

---

"if the PMS is an IP host = not connected to the MPLS domain,

   the PMS can send i= ts probe with the list of SIDs/Labels onto a

   suitable tunnel pr= oviding an MPLS access to a router which is part of

   the monitored MPLS= domain."

 

Probably some text should be ad= ded to cover this point. (e.g. the tunnel MUST be secured and provide authe= ntication of the sender and cryptographic signature.

Also this has security implicat= ion as MPLS VPNs are based on the inability of the sender to send MPLS pack= et, while this option open this door. This should be discussed in the secur= ity consideration section.

&n= bsp;

[RG] Fa= ir observation, I’ve added some text.

&n= bsp;

----

=A74.1

 

"To be able to work with t= he smallest possible SR label stack, first a suitable MPLS OAM method is us= ed to detect the ECMP routed path between LER i to LER j which is to be mon= itored "

This is not very clear to me. C= ould this be rephrased? e.g. What to do mean by "MPLS OAM method?"= ; Is this MPLS OAM API (e.g. LSP ping)? Is this an algorithm to define the = path? (but the end of the sentence seems to indicate that the path is given as input "which is to be monitored") is &= quot;detect" the best term?

 

Also, this really the first sen= tence of the section. Could you first introduce the global picture and the = goal, rather than starting with an optimisation "To be able to work wi= th the smallest possible SR label stack"

&n= bsp;

[RG] Re= phrased the paragraph.

&n= bsp;

---

"The packet will

   only reliably use = the monitored path, if the label and address

   information used i= n combination with the MPLS OAM method of choice is

   identical to that = of the monitoring packet."

 

   Could this be reph= rased to improve clarity?  

&n= bsp;

[RG] Re= phrased the paragraph.

----  

"The path PMS to LER i mus= t be available." "The path LER j to PMS must be available."

Given that the goal is to monit= or paths which are assumed to be available, if you detect a packet loss, ho= w do you know which segment has an error? Indeed, packet loss could happen = on this PMS to LERi path, while you think that you are measuring the path LER i to LER j.

---

"This path must be detecta= ble"

What does this mean?=

&n= bsp;

[RG] &n= bsp;Rephrased the paragraph.

 

---

"If ECMP is deployed, it m= ay be desired to measure along both possible paths which a packet may use b= etween LER i and LER j."

- ECMP may be more than both.

- If you don't want to follow a= n ECMP path, why are you sending packet along an ECMP path? SR allows enfor= cing a single path among multiple ECMPs.

&n= bsp;

[RG] &n= bsp;Rephrased the sentence.

 

----

"Further changes in ECMP f= unctionality at LER i will impact results."

Can you elaborate on this? Some= LSR dynamically change their load-balancing behavior in order to try to eq= ually spread the load on all ECMP paths. Is this behavior an issue? (i.e. a= re PMS and dynamic load-balancing adaptation mutually incompatible?)

Also if you want to monitor the= (customer) ECMP path, would it be good to detect any change in this path, = including a change trigger by such dynamic load-balancing adaptation?<= /o:p>

And if you don't want to monito= r the ECMP path, may be you should only monitor individual path.=

&n= bsp;

[RG] &n= bsp;Rephrased the sentence.

&n= bsp;

----

"   Determining = a path to be executed prior to a measurement may also be<= /p>

   done by setting up= a label stack including all Node SIDs along that

   path (if LSR1 has = Node SID 40 in the example and it should be passed

   between LER i and = LER j, the label stack is 20 - 40 - 30 - 10).  The

   advantage of this = method is, that it does not involve MPLS OAM

   functionality and = it is independent of ECMP functionalities."

 

   Adding all node SI= D do not remove ECMP functionnality. e.g. there could be multiple links bet= ween LSR1 and LER i.

&n= bsp;

[RG] &n= bsp;You are right, added text.

&n= bsp;

   ---

  "Monitoring an MPLS= domain by a PMS based on SR offers the option of

   monitoring complet= e MPLS domains with little effort and very

   excellent scalabil= ity."

Why is the scalability excellen= t? It looks to me that some links near the PMS will be "heavily" = used to test all paths.

"little effort" is no= t very specific. IMHO a key benefit is the ability to monitor all network p= aths by deploying a single PMS, while some others techniques requires the d= eployment of many probes.

&n= bsp;

[RG] &n= bsp;Added text to clarify properties of the solution.

&n= bsp;

---

"The PMS does not require = access to LSR/LER management interfaces "

The choice of the term "in= terfaces" seems debatble to me as it could be misread as physical inte= rface being monitored. As the goal of this document is to monitor path and = interfaces, I'd rather use "interface" only to refer to physical interface.

&n= bsp;

[RG] &n= bsp;Replaced “interfaces” by “plane information”.

---

=A74.2

Same comment: if the PMS detect= s loss of probe packets, it does not know whether the loss happens on the m= onitored bundle, or the path from the PMS to R2 or the path from R1 to the = PMS.

So how do you compute/measure t= he characteristics of the sub-path (here the bundle) that you want to monit= or?

&n= bsp;

[RG] &n= bsp;You are right, added text.

 

---

=A74.3

   "In the = previous example, a uni-directional fault on the middle link

   in direction of R2= to R1 would be localized by sending the following

   two probes with re= spective segment lists:

   o  72, 662, 9= 92, 664

   o  72, 663, 9= 92, 664"

   =

 

"The first probe would fai= l while the second would succeed."

I would have said the opposite = as 663 maps to the middle link which is assumed to be faulty.

 

The formulation of the text is = debatable as you are using the a priori knownledge of the failure in order = to define the probes which needs to be sent.

More generally, as you are send= ing packets over a path longer than the one to be tested, what you need is = to also monitor those extra sub-path in order to be able to check whether t= he failure is indeed on the sub-path that you want to test, rather than the paths from the PMS to the first nod= e on the tested path, or the path from the last node on the tested path to = the PMS.

&n= bsp;

[RG] &n= bsp;Thanks, added text and a generic statement addressing your second point= . I don’t want to describe a complete solution as part of a use case,= I hope that’s acceptable.

 

---

=A76

"Next: LDP or RSVP-TE labe= l identifying the path to LER j at LER i.

 

if LER j is the ingress of the = RSVP-TE LSP, LER j does not have a label identifying this LSP. Eventually, = SR may allocate a binding SID to this RSVP-TE LSP.

if LER j is a transit LSR of th= e RSVP-TE LSP, how does the PMS learn this labels, which a priori is only k= now from LER j and its upstream LSR.

&n= bsp;

[RG] &n= bsp;I’m not an RSVP-TE expert.  Next:… says path from LER = i to LER j (at LER i), in case of RSVP TE a tunnel would start in LER I and= terminate in j. Changed text.

If that= can’t be settled, I don’t care about RSVP-TE and I’d rat= her remove text than work on it.

---

=A77

"   MPLS SR topo= logy awareness should allow the SID to monitor liveliness=

   of most types of S= IDs (this may not be recommendable if a SID

   identifies an inte= r domain interface)"

   =

Why would it not be recommendab= le to monitor an inter domain SID/interface?

&n= bsp;

[RG] &n= bsp;I’m sure that the principle works on interfaces within an IGP dom= ain (and that what the use case offers). As with RSVP-TE, it may also work = on inter domain SIDs, however I prefer not to have to discuss that in detail, as I didn’t think it through. Hence, if s= omeone (not me) provides  text on inter domain SID/interface or RSVP-T= E. which is  acceptable to the chairs/IETF, I’= m happy to add it. If this must be a scetch of workable solution, and IR= 17;m supposed to work it out, I’m not interested. I don’t say, = any of this is impossible or a bad idea. I don’t have time to work on it.

&n= bsp;

---

      = "To match control plane information with data plane information, MPLS<= o:p>

   OAM functions as d= efined for example by RFC 4379 [RFC4379] should be

   enhanced to allow = collection of data relevant to check all relevant

   types of Segment I= Ds."

Is there a document working on = this? (e.g. draft-ietf-mpls-spring-lsp-ping ?) If so, it could be reference= d.

 

inter domain SID/interface

&n= bsp;

[RG] Do= ne.

---

=A78

"While the PMS based use c= ases explained in Section 3 "

I think uses-cases are explaine= d in section 4.

&n= bsp;

[RG] Do= ne.

---

=A76

"An implementation report = on a PMS operating in an LDP domain is given in [I-D.leipnitz-spring-pms-im= plementation-report]"

This document is more than an i= mplementation. IMHO it would deserve a short text introducing its scope and= result. e.g.

"[I-D.leipnitz-spring-pms-= implementation-report] present a PMS implementation report and compare dela= ys measured with one PMS to the results of three IPPM standard conformant M= easurement Agents, using the IPPM methodology as defined in [RFC6576].

The results show that the PMS m= easurements equal those captured by

   an IPPM conformant= measurement system.  The ADK test is successful by<= /p>

   comparing the meas= urement values of the round-trip delays for packets

   with a size of 64 = bytes."

   =

(but I'm not an IPPM expert, so= authors should be able to provide a better text) 

&n= bsp;

[RG] Th= anks for the positive feedback, done.

 

 

=3D=3D=3D=3D=3D Nits=

"IGP LSA"<= /span>

LSA is not defined nor expanded= on first use.

Plus it is protocol specific (O= SPF). Could you cover both OSPF and IS-IS or use a term which is not protoc= ol specific? Especially since a priori you mean LSDB analysis, rather than = LSA.

---

:s/minmum/minimum

---

OLD: used as a means of adding = label stacks and hence transport to standard MPLS OAM packets

NEW: used as a mean of adding l= abel stacks and hence transport standard MPLS OAM packets to any node<= /o:p>

&n= bsp;

[RG] Te= xt has been removed or changed..

&n= bsp;

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_21e86564238c4f1d8cb225372b809f1dHE101653emea1cdstintern_-- From nobody Tue Feb 7 05:51:01 2017 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 773B2129C07; Tue, 7 Feb 2017 05:50:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148647545948.16284.8360784393021155625.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 05:50:59 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-07.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:50:59 -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 of the IETF. Title : Segment Routing with MPLS data plane Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Martin Horneffer Rob Shakir Jeff Tantsura Edward Crabbe Filename : draft-ietf-spring-segment-routing-mpls-07.txt Pages : 16 Date : 2017-02-07 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS dataplane, the SR header is instantiated through a label stack. A segment can represent any instruction, topological or service-based. Additional segments can be defined in the future. SR allows to enforce a flow through any topological path and/or service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change in the forwarding plane. This drafts describes how Segment Routing operates on top of the MPLS data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 7 05:51:36 2017 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 375A9129C04; Tue, 7 Feb 2017 05:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P588cQmhbCzi; Tue, 7 Feb 2017 05:51:30 -0800 (PST) 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 D33E6129C11; Tue, 7 Feb 2017 05:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15156; q=dns/txt; s=iport; t=1486475487; x=1487685087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D90H3DOUXlFVih/clJucBckdpNE3VIlv2VEf64Nvv4g=; b=Gjwb5LNzNSD0yvJDpFka8ObxuuA6TelDik7dJHd6U6OVJxAIF+ixKdJe PIXr/4GNZSbkOvImm29P7zYCjwAyA/pPClIVOC1CssmLqeUu6gSAGoLzq ihBt8t/6DE4FCFz68vB4D0DY+yopry3C9CniqWE9aWUVxLHrc6EtC9bCP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCd0JlY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBageNWZIPiAyNKoIMhiICgk4/GAECAQEBAQEBAWIohGkBAQE?= =?us-ascii?q?DAR1cBQsCAQgSBi4hERcOAgQOBYlbAw0Ish2HPg2ECgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEfhkyCBYJqglGCA4M0gjEFiQqSKTgBigiDbIQZgXuFF4NOhiOKMIheAR8?= =?us-ascii?q?4fk8VPBEBhDIFGIFhdYgSgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="382532604" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2017 13:51:27 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v17DpQRB028987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Feb 2017 13:51:26 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 08:51:25 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 08:51:25 -0500 From: "Stefano Previdi (sprevidi)" To: Stewart Bryant Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 Thread-Index: AQHSeI1Ayr4HY2RVbEy4KOIyTWUgNKFV/u0AgAf2VYA= Date: Tue, 7 Feb 2017 13:51:25 +0000 Message-ID: <366F7F32-85AD-40C4-A6BC-F46E3F17BA65@cisco.com> References: <55fdb032-20d7-bfa2-c3cb-bcea3dd2b553@gmail.com> In-Reply-To: <55fdb032-20d7-bfa2-c3cb-bcea3dd2b553@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.213.28] Content-Type: text/plain; charset="Windows-1252" Content-ID: <12BD270D7BB0B24EB9CB5108B877D0BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" , "spring@ietf.org" , "spring-chairs@tools.ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-06 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:51:35 -0000 Stewart, I applied some of your comments in the new submitted version of the draft. = Some other comments below. > On Feb 2, 2017, at 1:15 PM, Stewart Bryant wro= te: >=20 > Here are a number of WGLC comments on this document. >=20 > - Stewart >=20 > Segment Routing with MPLS data plane > draft-ietf-spring-segment-routing-mpls-06 >=20 > Abstract >=20 > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through a controlled set of instructions, called > segments, by prepending the packet with an SR header. >=20 > SB> This is SR MPLS. The above text implies a special header. Surely > SB> it appends a stack of MPLS label stack entries that encode the instru= ctions > SB> as label values. the first statement is the generic description of SR as an architecture. Th= en, I will add a statement regarding the incarnation of the SR header in th= e mpls dataplane (i.e.: a label stack). >=20 > A segment can > represent any instruction, topological or service-based. > SB> and more! > SR allows > to enforce a flow through any topological path and service chain > while maintaining per-flow state only at the ingress node to the SR > domain. >=20 > SB> The above does not read well. > SB> Surely something like: > SB> SR allows an ingress node to steer a packet through a > SB> topological path specifying which service actions or other > SB> operations need to executed on arrival as a each specified node. the above is confusing because it implies the two are merged. paths can be topological, service-based or both. > Segment Routing can be directly applied to the MPLS architecture with > no change in the forwarding plane. This drafts describes how Segment > Routing operates on top of the MPLS data plane. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 >=20 > 2. Illustration >=20 > Segment Routing, applied to the MPLS data plane, offers the ability > to tunnel services (VPN, VPLS, VPWS) from an ingress PE to an egress > PE, without any other protocol than ISIS or OSPF > ([I-D.ietf-isis-segment-routing-extensions] and > [I-D.ietf-ospf-segment-routing-extensions]). LDP and RSVP-TE > signaling protocols are not required. >=20 > SB> Strictly no protocol is required as we did in MPLS-TP. > SB> What you are saying is that by embedding additional > SB> information in the the link state igp in use, you remove the > SB> dependence on LDP, and RSVP-TE, although of course RSVP-TE > SB> does run-time bandwidth accounting which you have to move to > SB> a central place. the text has been already reviewed and commented multiple time and reflects= the agreement of the WG. We specify that SR doesn=92t need rsvp-te or ldp.= =20 In the context of SR, we just don=92t need them. On other context they cert= ainly have their value. >=20 > SB> I suspect that the reader would be better served by putting the > SB> rest of this after explaining how the protocol mapping works. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > Supporting MPLS services (VPN, VPLS, VPWS) with SR has the following > benefits: >=20 > Simple operation: one single intra-domain protocol to operate: the > IGP. No need to support IGP synchronization extensions as > described in [RFC5443] and [RFC6138]. >=20 > Excellent scaling: one Node-SID per PE. >=20 > SB> Is this all it seems. If you are going to steer the packet > SB> I think you need more than one node-SID to get the packet there. not really. Please have a look at the architecture and illustrations. > SB> I presume the point is (and it should be brought out) that with > SB> liberal label retention you have a label per adjacency that maps > SB> to the remote PE (in the RP), although only one is in the FIB. If you= have > SB> an RSVP-TE path you have more than one label per PE, you have > SB> one per constructed path, but in the FIB you only need to specify > SB> a single label imposition, whilst in SR, you need to specify a > SB> multi-label imposition. this would trigger the neverending debate on whether we should start compar= ing all aspects pros/cons of control planes (SR vs. ldp/rsvp).=20 We=92re just interested into how SR works: one sid per pe. > SB> As I understand it different vendors have different approaches > SB> to label aggregation which may further complicate the issue, but > SB> this text needs to be neutral on that point. >=20 >=20 > 3. MPLS Instantiation of Segment Routing >=20 > MPLS instantiation of Segment Routing fits in the MPLS architecture > as defined in [RFC3031] both from a control plane and forwarding > plane perspective: >=20 > o From a control plane perspective [RFC3031] does not mandate a > single signaling protocol. Segment Routing proposes to use the > Link State IGP as its use of information flooding fits very well > with label stacking on ingress. >=20 > SB> Surely you propose to be protocol agnostic? For example SR will work = just as > SB> well with for example a pub-sub approach. >=20 > o From a forwarding plane perspective, Segment Routing does not > require any change to the forwarding plane. >=20 > When applied to MPLS, a Segment is a LSP and the 20 right-most bits > of the segment are encoded as a label. This implies that, in the > MPLS instantiation, the SID values are allocated within a reduced > 20-bit space out of the 32-bit SID space. >=20 > SB> That is a very strange way of saying that in MPLS SIDs are 20 > SB> bits, although of course they are often less than 20 bits > SB> as other MPLS applications need to use the same label table. > SB> If SIDs were 32 bits, then you would need to encode them across > SB> multiple labels, which I have not seen proposed. what exactly you don=92t find clear ? a label value is 20 bits as per mpls architecture so we map a segment ident= ifier into these bits. > The notion of indexed global segment fits the MPLS architecture > [RFC3031] as the absolute value allocated to any segment (global or > local) can be managed by a local allocation process (similarly to > other MPLS signaling protocols). >=20 > SB> You need some text to introduce the above rather than pull it out > SB> of a hat. yes. Added reference to the architecture draft where indexes are introduced= and defined. > If present, SR can coexist and interworks with LDP and RSVP > [I-D.ietf-spring-segment-routing-ldp-interop]. >=20 > The source routing model described in > [I-D.ietf-spring-segment-routing] is inherited from the ones proposed > by [RFC1940] and [RFC2460]. The source routing model offers the > support for explicit routing capability. >=20 > SB> SR goes back prior to RFC791, which also included source routing. >=20 >=20 > Contrary to RSVP-based explicit routes where tunnel midpoints > maintain states, SR-based explicit routes only require per-flow > states at the ingress edge router where the traffic engineer policy > is applied. >=20 > SB> What about bandwidth management? clearly this is in the scope of RSVP. With SR we assume controller based SR TE networks where resources (used/ava= ilable) are reported to the management/controller system and programming of= paths done accordingly. Again, it=92s out of scope of this draft. >=20 > Contrary to RSVP-based explicit routes which consist in non-ECMP > circuits (similar to ATM/FR), SR-based explicit routes can be built > as list of ECMP-aware node segments and hence ECMP-aware traffic > engineering is natively supported by SR. >=20 > SB> You mean loose source routing, which is again an old concept. we don=92t claim the invention of it. We just illustrate the benefit of it. > When Segment Routing is instantiated over the MPLS data plane the > following applies: >=20 > o A list of segments is represented as a stack of labels. >=20 > SB> The items in the stack are technically LSEs. >=20 > o The active segment is the top label. >=20 > o The CONTINUE operation is implemented as an MPLS swap operation. > The outgoing label value is computed as follows: >=20 > SB> CONTINUE need a reference yes, added. >=20 > * When the same Segment Routing Global Block (SRGB, defined in > [I-D.ietf-spring-segment-routing] is used throughout the SR > domain, the outgoing label value is equal to the incoming label > value. >=20 > * When different SRGBs are used, the outgoing label value is set > as: [SRGB(next_hop)+index]. >=20 > SB> This is a continue, so isn't it label =3D label + SRGB_base_next - SR= GB_base_this? > SB> The order can be the other way around by this never gives negative nu= mbers. and so ? > If the index can't be applied to > the SRGB (i.e.: if the index points outside the SRGB of the > next-hop or the next-hop has not advertised a valid SRGB), then > no outgoing label value can be computed and the next-hop MUST > be considered as not supporting the MPLS operations for that > particular SID. >=20 > SB> Presumably you also need to take a management action since the > SB> control plane should no allow the situation to occur. >=20 > * The index and the SRGB may be learned through different means. > Obviously, the SRGB MUST be the one the index is related to. >=20 > SB> The above is a little opaque. I think it=92s clear but I can add a few words if it helps you: the SRGB ca= n be learned through different means. However, it is obvious that the SRGB = the index is applied to MUST be the one belonging to the neighbor intended = to receive the packet. > o The NEXT operation is implemented as an MPLS pop operation. The > NEXT operation does not require any mapping to an outgoing label > hence the SRGB is irrelevant for this operation. >=20 > SB> NEXT needs a reference >=20 > o The PUSH operation is implemented as an MPLS push of a label > stack. >=20 > SB> POP needs a reference, and don't you actually push one or more LSE? >=20 > o The Segment Routing Global Block (SRGB) values MUST be greater > than 15 in order to preserve values 0-15 as defined in [RFC3032]. >=20 > SB> What you are saying is that the SRGB base value must have a number > SB> greater than the top of the special purpose label space (0..15), alth= ough > SB> as it was expressed it looked like you wanted to have room for them > SB> in the SR label space. I think the text is clear, no ? it=92s not SR but rather the MPLS architect= ure that requires to use label 16 upwards. SR complies to this. > SB> Indeed I think the document set conflates SGRB with SRGB_base and > SB> ought to define both terms. >=20 > SB> I think it might be worth noting that the obvious implementation of > SB> RFC7474 would be to move the ceiling of the SPLs rather than > SB> creating a new table in h/w and thus it would be sensible leave > SB> some space between 15 and SRGB-base. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 4.1. Example 1 > ... >=20 > In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- > awareness ensures that the traffic be load-shared between any ECMP > path, in this case the two north and south links between R2 and R3. >=20 >=20 >=20 > SB> Ah now how is that ECMP being calculated? igp. > If it is based on the > SB> labels in a stack without an EL, isn't there a tendency to reduce > SB> the entropy given the guideline to allocate the same SRGB everywhere? >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 5.1. LDP LSP segment combined with IGP segments >=20 > The example illustrates a segment-routing policy including IGP > segments and LDP LSP segments. >=20 > SL1---S2---SL3---L4---SL5---S6 > | | > +---------------+ >=20 > Figure 4: LDP LSP segment combined with IGP segments >=20 > SB> This and the text that follows is very confusing. It would be helpful= to define your > SB> SL, S, L notation up front. please precise what is confusing to you. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 5.2. RSVP-TE LSP segment combined with IGP segments >=20 > The example illustrates a segment-routing policy including IGP > segments and RSVP-TE LSP segments. >=20 > S1---S2---RS3---R4---RS5---S6 > | | > +---------------+ >=20 > Figure 5: RSVP-TE LSP segment combined with IGP segments >=20 > SB> Again starting with the notation would be helpful to the reader. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > In the MPLS instantiation, as the packet travels through the SR > domain, the stack is depleted and the segment list history is > gradually lost. >=20 > SB> Strictly the history is not gradually lost, it is never there. > SB> When you see a label stack, you know the future of the packet > SB> but never the past. removed =93history=94. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > 8. Manageability Considerations >=20 > This document describes the applicability of Segment Routing over the > MPLS data plane. Segment Routing does not introduce any change in > the MPLS data plane. Manageability considerations described in > [I-D.ietf-spring-segment-routing] applies to the MPLS data plane when > used with Segment Routing. >=20 > SB> Maybe I missed it, but I could not see any discussion on the implicat= ions > SB> for LSP-ping. Does that just work out of the box or does it need chan= ges? LSP-ping is in the oam draft. >=20 > 9. Security Considerations >=20 > This document does not introduce additional security requirements and > mechanisms other than the ones described in > [I-D.ietf-spring-segment-routing]. >=20 > SB> I think that the MPLS element of the security considerations might be > SB> better placed here with the rest of the MPLS text. > SB> By minimising the range of the labels used, isn't path guessing more > SB> of a concern, and isn't there a greater chance that a misforwarded pa= cket > SB> will get to a destination rather than be dropped? > SB> > SB> Doesn't SR make it a tad easier for the pervasive monitoring people > SB> to figure out where a packet is going than in an LSP or RSVP-TE contr= olled > SB> network? please read the arch draft and its security section. thanks. s. >=20 >=20 >=20 From nobody Tue Feb 7 05:52:46 2017 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 DE089129C23 for ; Tue, 7 Feb 2017 05:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 10Mibis0NvyH for ; Tue, 7 Feb 2017 05:52:44 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBE9129C24 for ; Tue, 7 Feb 2017 05:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2566; q=dns/txt; s=iport; t=1486475535; x=1487685135; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ms/drDRTSGgjpf8Nu23f6XiNqb5YMtH3TMHitzzZNIk=; b=PryF1BkkA/XM/uR5BdoYY/PiRsk4xcvcivLF/2nLmX+wvQHcU3IVFw9I n+qtjt+EZXtAW9sfCiZD08bjjS7gvCRREHQIXTmRBkp6qIdL5d3nHigT0 yJ7YTsrlbTZMv8khMFwZkCJOEhjLECpASZBbsxRrto2VkbjRbK5qkd2Er I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDpz5lY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVmSD5U2ggwfDYUsSgKCTj8YAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQMBAQE4NBALAgEIEgYeECcLFw4CBBOJawgOsguLVQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GTIIFgmqDF4E9gzSCMQWbawGGaYskgXtThESJcZMOAR84fk8VGCQ?= =?us-ascii?q?RAYYwdYgSgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="380984875" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Feb 2017 13:52:14 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v17DqERC013157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Feb 2017 13:52:14 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 7 Feb 2017 08:52:13 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 7 Feb 2017 08:52:13 -0500 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-07.txt Thread-Index: AQHSgUk6r/++7U/1Sk6pHVXs6WjioKFd5AOA Date: Tue, 7 Feb 2017 13:52:13 +0000 Message-ID: <879DE4A5-E494-41A0-A6C4-335CA1A622FB@cisco.com> References: <148647545948.16284.8360784393021155625.idtracker@ietfa.amsl.com> In-Reply-To: <148647545948.16284.8360784393021155625.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.213.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <22AF0CF2F2C5774F813AD34248277EC8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-07.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 13:52:46 -0000 this is the updated version after all received comments. Thanks. s. > On Feb 7, 2017, at 2:50 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Source Packet Routing in Networking of t= he IETF. >=20 > Title : Segment Routing with MPLS data plane > Authors : Clarence Filsfils > Stefano Previdi > Ahmed Bashandy > Bruno Decraene > Stephane Litkowski > Martin Horneffer > Rob Shakir > Jeff Tantsura > Edward Crabbe > Filename : draft-ietf-spring-segment-routing-mpls-07.txt > Pages : 16 > Date : 2017-02-07 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through a controlled set of instructions, called > segments, by prepending the packet with an SR header. In the MPLS > dataplane, the SR header is instantiated through a label stack. A > segment can represent any instruction, topological or service-based. > Additional segments can be defined in the future. SR allows to > enforce a flow through any topological path and/or service chain > while maintaining per-flow state only at the ingress node to the SR > domain. >=20 > Segment Routing can be directly applied to the MPLS architecture with > no change in the forwarding plane. This drafts describes how Segment > Routing operates on top of the MPLS data plane. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-mpl= s-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue Feb 7 06:03:22 2017 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 48E3F129C34; Tue, 7 Feb 2017 06:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 NZRlXaNbAu1Y; Tue, 7 Feb 2017 06:03:17 -0800 (PST) Received: from relais-inet.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 91371129C3B; Tue, 7 Feb 2017 06:03:17 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 231C7120665; Tue, 7 Feb 2017 15:03:16 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id CF151C0063; Tue, 7 Feb 2017 15:03:15 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 7 Feb 2017 15:03:15 +0100 From: To: "Roberta Maglione (robmgl)" , "draft-ietf-spring-ipv6-use-cases@ietf.org" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-ipv6-use-cases - shepherd review Thread-Index: AdJXqlEYjoPjwSyiQZm/+o0EBVlxZgFUu9GACRGCViA= Date: Tue, 7 Feb 2017 14:03:14 +0000 Message-ID: <14149_1486476195_5899D3A3_14149_4497_1_53C29892C857584299CBF5D05346208A1ED3C9D9@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <17317_1481899619_5853FE63_17317_744_1_53C29892C857584299CBF5D05346208A1ECC6721@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Christian Martin \(martincj\)" , "spring-chairs@ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] draft-ietf-spring-ipv6-use-cases - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:03:20 -0000 Hi Roberta, Thanks for the update and for addressing my comments. I'll write the write'up ASAP (ETA end of this week) FYI some typo: OLD: and the achieve larger scale NEW: and to achieve larger scale OLD: a solution relaying on IPv6 NEW: a solution relying on IPv6 No need to refresh the draft for this. Thanks --Bruno > -----Original Message----- > From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com] > Sent: Friday, December 23, 2016 10:37 AM > To: DECRAENE Bruno IMT/OLN; draft-ietf-spring-ipv6-use-cases@ietf.org; s= pring@ietf.org > Cc: spring-chairs@ietf.org; Stefano Previdi (sprevidi); Christian Martin= (martincj) > Subject: RE: draft-ietf-spring-ipv6-use-cases - shepherd review >=20 > Hello Bruno, > Thanks for your comments, we are going to address them and post an updat= ed version of > the document after the Holidays. > Please see initial answers inline. > Regards > Roberta >=20 > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Friday, December 16, 2016 3:47 PM > To: draft-ietf-spring-ipv6-use-cases@ietf.org; spring@ietf.org > Cc: spring-chairs@ietf.org > Subject: draft-ietf-spring-ipv6-use-cases - shepherd review >=20 > Hi authors, >=20 > As the document shepherd, I have reviewed draft-ietf-spring-ipv6-use-cas= es. > I'm generally fine with the document, but do have some comments. Please = find them below. >=20 > Best regards, > Bruno >=20 > =3D=3D=3D=3D=3D Major comments > Section 2.3.0 (intro of 2.3) and 2.3.1 are related to Service Function C= haining and Data > Center Network Overlay use cases. > Hence they have an adherence with the SFC and NVO3 WG. > Have those WG been presented this document, kept up to date, and are ali= gned with the > requirements as written? > Besides, those texts are unchanged since early 2014, while the situation= may have change > since then, especially since both SFC and NVO3 WG are "recent". Especial= ly SFC which has > been formed at the same period (23/12/2013). A priori, their work is lik= ely to have > progressed since then, which does not seem reflected in this draft. >=20 > [RM] we are going the re-work theses sections to update the text in ther= e. >=20 > =3D=3D=3D=3D=3D Minor comments >=20 > =A72 IPv6 SPRING use cases > There are a few paragraphs ("In addition....in the above use case.") whi= ch describes that the > lack of MPLS support for IPv6 only networks is a use case for the IPv6 S= R dataplane. > However it seems to me that MPLS SR support IPv6 FEC/segment hence would= have been a > solution for such use case. So it does not seem to me a use case mandati= ng a new dataplane > (IPv6 SR). >=20 > [RM] Agree with you that when MPLS is present MPLS SR with IPv6 FEC/seg= ment is a viable > solution. However it was pointed out in the mailing list by Wes George > (https://www.ietf.org/mail-archive/web/spring/current/msg00832.html ) th= at MPLS in IPv6 > only environment still has some gaps as described in RFC 7439. Specific = text was added to > address that comment. > We can definitely re-word the text in this section, to clarify the meani= ng. >=20 > On a related point, the term "IPv6-only" does not seem well defined as i= t could sometime > means "non-IPv4" and sometimes "non-MPLS", which is different. > [RM] will clarify this point thanks >=20 > --- > "In addition it is worth to note that in today's MPLS dual-stack > networks IPv4 traffic is labeled while IPv6 traffic is usually > natively routed, not label-switched. Therefore in order to be able > to provide Traffic Engineering "like" capabilities for IPv6 traffic > additional/alternative encapsulation mechanisms would be required." >=20 > The first observation does not seem enough to require the new of a new d= ata-plane. As > discussed above, this may be caused by a lack of support for IPv6 in exi= sting MPLS signaling > protocols. MPLS SR seems to be a valid option. So it does not seem to be= a use case > mandating a new dataplane (IPv6 SR). >=20 >=20 > [RM] agree with you, the intention here was to capture current common de= ployments for > dual-stack networks where most of the times IPv4 is labeled switched whi= le IPv6 is natively > routed, given the current gaps for MPLS on IPv6 only networks. >=20 >=20 > --- > " 2. There is a strict lack of an MPLS dataplane" > May be adding "in a portion of the end to end path". (as some may have M= PLS in the core, > yet not in the access/DC/home network...) >=20 > [RM] okay >=20 > --- > "This section will describe some scenarios where MPLS may not be > present and it will highlight how the SPRING architecture could be > used to address such use cases, particularly, when an MPLS data plane > is neither present nor desired." >=20 > May be rephrasing to avoid saying twice in the same sentence that MPLS i= s not present. >=20 > [RM] will do >=20 > --- > " In any environment with requirements such as those listed above, an > IPv6 data plane provides a powerful combination of capabilities for a > network operator to realize benefits in explicit routing, protection > and restoration, high routing scalability, traffic engineering, > service chaining, service differentiation and application flexibility > via programmability." >=20 > [...] >=20 > " In addition to the use cases described in this document the SPRING > architecture can be applied to all the use cases described in > [RFC7855] for the SPRING MPLS data plane, when an IPv6 data plane is > present. Here there is a summary of those use cases: >=20 > 1. Traffic Engineering >=20 > 2. Disjoint paths in dual-plane networks >=20 > 3. Fast Reroute: Protecting node and adjacency segments >=20 > 4. OAM/monitoring >=20 > 5. Egress Peering Engineering" >=20 >=20 > I feel that there is redundancy with those 2 paragraphs. In particular t= he catalog of > usages/benefits is duplicated. >=20 > [RM] will simplify the text and remove redundant text >=20 > --- > =A72.2 > It's not clear to me what "egress vectoring" is. (May be because this Ac= cess Network section > seems to refer to a specific access techno (DOCSIS) which I'm not famili= ar with.) Could you > add a reference? >=20 > [RM] will add a reference >=20 > --- > =A72.3 >=20 > "A service provider may choose to have these service functions > performed external to the routing infrastructure, specifically on > either dedicated physical servers or within VMs running on a > virtualization platform." >=20 > It's not clear to me what is meant by "routing infrastructure", especial= ly when opposed to > servers/VM. Indeed, routers can now run in servers/VM. So may be rephras= ing the whole > point would help. >=20 > [RM] will re-phrase the sentence >=20 > --- > Introduction part (2.3.0) is mostly related to service chaining, althoug= h this is not reflected > by the title. It is referencing two WG documents from the SFC WG. Does t= his mean that the > SFC WG is presenting those requirements in the SPRING WG? This may requ= ire involving > the SFC WG in this last call. And some elaboration why the SFC WG soluti= ons are not > adequate/enough. (e.g. is this a need to combine both routing instructio= ns and service > instruction in order to both choose the route and the sequence of servic= es function? In > particular when NHS meta data is not needed?) >=20 > This service chaining text seems to originate from draft-martin-spring-s= egment-routing-ipv6- > use-cases-00 i.e .from march 2014. And the text is unchanged since draft= -martin-spring- > segment-routing-ipv6-use-cases-01 i.e from April 4, 2014.This seems like= a long time in this > domain: mostly the whole duration of the SFC WG. Is this still aligned w= ith the work that the > SFC WG has done in that 2.5 years period? >=20 > [RM] will re-work the section and update the text >=20 > --- > 2.3.1 is mostly related to VPN overlay. In the IETF, this seem in scope = to the NVO3 WG. Does > this mean that the NVO3 WG is presenting those requirements in the SPRIN= G WG? This may > require involving the NVO3 WG in this last call. Especially since NVO3 s= eems to have enough > encapsulation techniques to deal with, and it's not clear to me that NVO= 3 needs one more. >=20 > Besides, this section seems to come from 2014 and draft-baker-openstack-= ipv6-model > which has expired 18 month ago. 2014 may be a long time ago in the DC en= vironment. Is > this approach still up to date/relevant? >=20 > [RM] will re-work the section and update the text >=20 > ---- > "The 128-bit PE Ingress ID in the Segment Router Header (SRH) policy lis= t" > Name of the field and structure seems to have changed in the 6MAN draft.= possibly: > :s/PE Ingress ID/Ingress Node TLV > :s/policy list/Optional TLV objects >=20 > [RM] will fix this >=20 > =3D=3D=3D=3D=3D Nits: >=20 > Reference: > Some references are outdated (cf idnits), in particular [I-D.previdi-6ma= n-segment-routing- > header]. >=20 > =A72.3 > "The term "Service Function Chain", as defined in [RFC7498], it is used" > :s/it is/is >=20 > [RM] ok will fix both of them >=20 > Thanks again for the comments. > Regards > Roberta > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou > privilegiees et ne doivent donc pas etre diffuses, exploites ou copies s= ans autorisation. Si > vous avez recu ce message par erreur, veuillez le signaler a l'expediteu= r 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 fals= ifie. Merci. >=20 > 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 d= elete this message > and its attachments. > As emails may be altered, Orange is not liable for messages that have be= en 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. From nobody Wed Feb 8 06:30:52 2017 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 E1FF3129B14; Wed, 8 Feb 2017 06:30:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148656425092.3885.15689064242548535048.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2017 06:30:50 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-06.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:30:51 -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 of the IETF. Title : Segment Routing interworking with LDP Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-06.txt Pages : 20 Date : 2017-02-08 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 and service chain 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 drafts 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 8 06:32:13 2017 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 83240129B3E for ; Wed, 8 Feb 2017 06:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIkeGNuZneFO for ; Wed, 8 Feb 2017 06:32:11 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468FB129B3B for ; Wed, 8 Feb 2017 06:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2340; q=dns/txt; s=iport; t=1486564331; x=1487773931; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RstMlSTjXUJpLHcOE5c8Y3Sj48SY5BfHHPkNZuri4do=; b=dxuVD/70x2TLZRYc3eeNjN72Cyp4wdke2sA+ZGHnNxZF01LgdFe3jTfw Nt09bw8Ech4GOnEo7sjjyn3nXnyfVN9tophbP6iOCiGcJy2mE0Up+WrZW OHh7G5esFLvFwVQqrtfOb87LF/hgF8gBeyRLsxHfP2siUrGM0ZifAL7Pa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQCKK5tY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqSCZU2ggwfDYUsSgKCaT8YAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQMBAQE4NBALAgEIEgYeECcLFw4CBBOJbAgOsiGLUwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GTIIFgmqDF4E9gzSCMQWbcAGGbIslgXtThESJc5MSAR84fk8VGCQ?= =?us-ascii?q?RAYYwdYdygQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="382126822" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2017 14:32:10 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v18EWA5u003656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Feb 2017 14:32:10 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 09:32:09 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 09:32:09 -0500 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-06.txt Thread-Index: AQHSghf2ykZPn52qUESmYuxhkRKiW6Fff+IA Date: Wed, 8 Feb 2017 14:32:09 +0000 Message-ID: <61C5F952-19B0-4E9C-BFCA-E642F6969845@cisco.com> References: <148656425092.3885.15689064242548535048.idtracker@ietfa.amsl.com> In-Reply-To: <148656425092.3885.15689064242548535048.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.226.239] Content-Type: text/plain; charset="us-ascii" Content-ID: <2E1E0908DB50604CB087D58DB52E067E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-06.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:32:12 -0000 integrated various comments from various contributors. Thanks. s. > On Feb 8, 2017, at 3:30 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Source Packet Routing in Networking of t= he IETF. >=20 > Title : Segment Routing interworking with LDP > Authors : Clarence Filsfils > Stefano Previdi > Ahmed Bashandy > Bruno Decraene > Stephane Litkowski > Filename : draft-ietf-spring-segment-routing-ldp-interop-06.txt > Pages : 20 > Date : 2017-02-08 >=20 > 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 and service chain while maintaining per-flow state only at the > ingress node to the SR domain. >=20 > The Segment Routing architecture can be directly applied to the MPLS > data plane with no change in the forwarding plane. This drafts > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-in= terop/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop= -06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-ldp= -interop-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Feb 8 18:56:04 2017 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 15B1D12957B; Wed, 8 Feb 2017 18:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 I2M2irmJsWXH; Wed, 8 Feb 2017 18:56:01 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 56CEC129546; Wed, 8 Feb 2017 18:56:01 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id CA6FBA817FD19; Thu, 9 Feb 2017 02:55:59 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id v192u0K7005191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2017 02:56:00 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id v192tx0A011505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Feb 2017 02:56:00 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.132]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Wed, 8 Feb 2017 21:55:59 -0500 From: "Dolganow, Andrew (Nokia - SG)" To: "Vigoureux, Martin (Nokia - FR)" , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 Thread-Index: AQHSgoAKf7Ruir6n7kWI3H9mrgcISw== Date: Thu, 9 Feb 2017 02:55:59 +0000 Message-ID: <69AC5812-7DF8-4781-938C-F79F5DDEC336@nokia.com> References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> In-Reply-To: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 02:56:03 -0000 c3VwcG9ydA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc3ByaW5nIDxzcHJp bmctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1BUlRJTiBWSUdPVVJFVVggPG1hcnRp bi52aWdvdXJldXhAbm9raWEuY29tPg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSA2LCAyMDE3IGF0 IDk6MjAgUE0NClRvOiAic3ByaW5nQGlldGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KQ2M6ICJk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3BAaWV0Zi5vcmciIDxk cmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3BAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbc3ByaW5nXSBXRyBMYXN0IENhbGwgZm9yCWRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1sZHAtaW50ZXJvcC0wNQ0KDQogICAgSGVsbG8gV29ya2luZyBHcm91cCwNCiAg ICANCiAgICBUaGlzIGVtYWlsIHN0YXJ0cyBhIDItd2VlayBXb3JraW5nIEdyb3VwIExhc3QgQ2Fs bCBvbiANCiAgICBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3At MDUgWzFdLg0KICAgIA0KICAgIMKkIFBsZWFzZSByZWFkIHRoZSBkb2N1bWVudCBpZiB5b3UgaGF2 ZW4ndCByZWFkIHRoZSBtb3N0IHJlY2VudA0KICAgIHZlcnNpb24geWV0LCBhbmQgc2VuZCB5b3Vy IGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuIHRoZQ0KICAgICoxOXRoIG9mIEZl YnJ1YXJ5Ki4NCiAgICBOb3RlIHRoYXQgdGhpcyBpcyAqbm90IG9ubHkqIGEgY2FsbCBmb3IgY29t bWVudHMgb24gdGhlIGRvY3VtZW50OyBpdCBpcyANCiAgICBhbHNvIGEgY2FsbCBmb3Igc3VwcG9y dCAob3Igbm90KSB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgYSBQcm9wb3NlZCANCiAgICBT dGFuZGFyZCBSRkMuDQogICAgDQogICAgwqQgV2UgaGF2ZSBhbHJlYWR5IHBvbGxlZCBmb3IgSVBS IGtub3dsZWRnZSBvbiB0aGlzIGRvY3VtZW50IGFuZCBhbGwgDQogICAgQXV0aG9ycyBoYXZlIHJl cGxpZWQuDQogICAgSVBSIGV4aXN0cyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgYW5kIGhhcyBiZWVu IGRpc2Nsb3NlZCBbMl0uDQogICAgDQogICAgVGhhbmsgeW91DQogICAgDQogICAgTSZCDQogICAg DQogICAgLS0tDQogICAgWzFdIA0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcC8NCiAgICBbMl0g DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJtaXQ9ZHJh ZnQmaWQ9ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wDQogICAg DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBzcHJpbmcgbWFpbGluZyBsaXN0DQogICAgc3ByaW5nQGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCiAgICANCg0K From nobody Wed Feb 8 20:27:06 2017 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 898F012946F; Wed, 8 Feb 2017 20:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 1SioXSWQcYqs; Wed, 8 Feb 2017 20:27:04 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C801293DF; Wed, 8 Feb 2017 20:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1418; q=dns/txt; s=iport; t=1486614423; x=1487824023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wSE7Y28OBvjpC0nPX4WBGCodd7fK7u+firvsAI1RW+w=; b=FvPSZSJgT5g1GQkadLIL3lNa7gth3ty10Cjs74ReSys36eDtEGVAFOgf +sMfPkdQZopUndQFdJ8sDhWplAEdhnyNIiXDXFegosC4qEq0DxQP5+H8J UhTvA4a/gKQDh6fG6bLDhXESvXNsJdz3845unDzijScWs8oVwF0UhXvXJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAu75tY/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqSCZU2ggwfDYUsSgKCbz8YAQIBAQEBAQEBYiiEaQE?= =?us-ascii?q?BAQQBARtRCwwEAgEIEQQBASgHJwsUCQgCBAENBQiJbA6yNotOAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWGTIRvgxeBDxEBhgEFkAOFUYYcAYZsixyCBIUXg1CGI5M?= =?us-ascii?q?SAR84dghPFTyGQnWGUYEhgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,349,1484006400"; d="scan'208";a="382560288" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Feb 2017 04:27:03 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v194R2vu013358 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Feb 2017 04:27:03 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Feb 2017 22:27:02 -0600 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 8 Feb 2017 22:27:02 -0600 From: "Les Ginsberg (ginsberg)" To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 Thread-Index: AQHSgHvc+iwKvRIUvEykWmyw/RIiXaFgGH/Q Date: Thu, 9 Feb 2017 04:27:02 +0000 Message-ID: References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> In-Reply-To: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.53.141] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 04:27:05 -0000 Support. Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin > Vigoureux > Sent: Monday, February 06, 2017 5:21 AM > To: spring@ietf.org > Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org > Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp- > interop-05 >=20 > Hello Working Group, >=20 > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-ldp-interop-05 [1]. >=20 > =A4 Please read the document if you haven't read the most recent version = yet, > and send your comments to the list, no later than the *19th of February*. > Note that this is *not only* a call for comments on the document; it is a= lso a > call for support (or not) to publish this document as a Proposed Standard > RFC. >=20 > =A4 We have already polled for IPR knowledge on this document and all > Authors have replied. > IPR exists against this document and has been disclosed [2]. >=20 > Thank you >=20 > M&B >=20 > --- > [1] > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp- > interop/ > [2] > https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-s= pring- > segment-routing-ldp-interop >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Feb 9 11:01:36 2017 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 EBB5E129442; Thu, 9 Feb 2017 11:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 cD6mthvgxhVW; Thu, 9 Feb 2017 11:01:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E3C12942F; Thu, 9 Feb 2017 11:01:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAH76146; Thu, 09 Feb 2017 19:01:29 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 19:01:28 +0000 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Thu, 9 Feb 2017 11:01:25 -0800 From: Yingzhen Qu To: Martin Vigoureux , "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 Thread-Index: AQHSgHvktKcgBhwfl0qgT5oq3LSQG6FhDMjw Date: Thu, 9 Feb 2017 19:01:24 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B3C3E3E@dfweml501-mbx> References: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> In-Reply-To: <4878b720-582c-313c-af2e-44dcc11629ec@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.128] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.589CBC89.029E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c879900d9273b018e32202f5f9a459a3 Archived-At: Cc: "draft-ietf-spring-segment-routing-ldp-interop@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-interop-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:01:35 -0000 Support. Thanks, Yingzhen -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: Monday, February 06, 2017 5:21 AM To: spring@ietf.org Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-ldp-in= terop-05 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-ldp-interop-05 [1]. =A4 Please read the document if you haven't read the most recent version ye= t, and send your comments to the list, no later than the *19th of February*= . Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as a Proposed Standa= rd RFC. =A4 We have already polled for IPR knowledge on this document and all Autho= rs have replied. IPR exists against this document and has been disclosed [2]. Thank you M&B --- [1] https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-inte= rop/ [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-spr= ing-segment-routing-ldp-interop _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Fri Feb 10 06:13:58 2017 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 CA741129979; Fri, 10 Feb 2017 06:13:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148673603282.29317.17522709252166613216.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 06:13:52 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-09.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:13:53 -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 of the IETF. Title : IPv6 SPRING Use Cases Authors : John Brzozowski John Leddy Clarence Filsfils Roberta Maglione Mark Townsley Filename : draft-ietf-spring-ipv6-use-cases-09.txt Pages : 12 Date : 2017-02-10 Abstract: Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-ipv6-use-cases-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 10 09:45:30 2017 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 BB8A7124281; Fri, 10 Feb 2017 09:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 DJmX_gZfq5b1; Fri, 10 Feb 2017 09:45:25 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC5F1293EC; Fri, 10 Feb 2017 09:45:24 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id A9D52C04E1; Fri, 10 Feb 2017 18:45:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 7FA85180063; Fri, 10 Feb 2017 18:45:22 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 18:45:22 +0100 From: To: "Ruediger.Geib@telekom.de" Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbgNDdW3AAKavA0AAzyNMcA== Date: Fri, 10 Feb 2017 17:45:21 +0000 Message-ID: <25080_1486748722_589DFC32_25080_2438_1_53C29892C857584299CBF5D05346208A1ED56C59@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com> In-Reply-To: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED56C59OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Subject: Re: [spring] draft-ietf-spring-oam-usecase - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 17:45:30 -0000 --_000_53C29892C857584299CBF5D05346208A1ED56C59OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ruediger, Thanks for the answer and the updated draft which is indeed improved. Reading the new version, I have additional comments below: --- Idnits report 1 issue: "=3D=3D It seems as if not all pages are separated b= y form feeds - found 0 form feeds but 16 pages" https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-oam-usecase-05.txt --- =A72 "This document describes illustrates a system" syntax error. -- " o A single centralized MPLS monitoring system which is able to perform a continuity check (ping) along all Label Switched Paths of the SR domain. Monitoring packets never leave data plane. o The MPLS ping (or continuity check) packets never leave the MPLS data plane." Two latest sentences seems redundant. -- "Monitoring packets never leave data plane." May be :s/data plane/user data plane On my side, I'd see one addition advantage which does not seem to be mentio= ned: since this is the same system sending and receiving the monitoring packet, = the monitoring system may freely choose the payload of the packet. This all= ows sending probing packets representing real customer traffic, possibly fr= om multiple service (e.g. small VoIP packet, larger HTTP packets), embeddin= g useful monitoring data (e.g. accurate time stamps since both sender and r= eceiver have the same clock, sequence numbers to ease the measurement...) -- " o An MPLS monitoring system, maybe several ones if redundancy is desired, which apply SR for OAM purposes as described, offer the possibilty to scale and design a flexible MPLS OAM platform as suitable for a provider." I feel that the sentence could be rephrased to enhance its readability. e.g. "Such MPLS monitoring system offer flexibility in term of deployment: = from one single centralized one to a set of distributed systems (e.g. on a = per region or service base), and in term of redundancy from 1+1 to N+1" -- "construct ping packets respectively, which can be precisely steered to pat= hs whose connectivity is to be checked, also if ECMP is present" - I'm not sure what "respectively" refers to. - may be :s/also if ECMP is present/including when ECMP is present But feel free to disregard the comment as English is not my first language. --- " If the depth of label stacks to be pushed for the purpose of path monitoring is of concern for a domain, a dedicated PMS server allows to push monitoring related label stacks of arbitrary depth on this server." Sentence is not easy to parse. I guess you mean: "If the monitoring of a specific topology/domain requires pushing a large = label stack, one may use a software based implementation which is usually m= ore flexible than an hardware based one." --- "RFC 4379 [RFC7276] specifies a Connectivity Verification for MPLS domain= s." Do you mean 4379 or 7276 or both? (I would assume :s/[RFC7276]/[RFC4379]) --- :s/As RFC 7276 sates/As RFC 7276 states --- =A73 Connectivity Verification. The below text seems duplicated: " RFC 7276 [RFC7276] defines Connectivity Verification as a mechanism to check connectivity between two nodes by checking whether a path between both can be used. RFC 4379 [RFC7276] specifies a Connectivity Verification for MPLS domains. As RFC 7276 sates, Connectivity Verification and Continuity Checks are considered complementary mechanisms and are often used in conjunction with each other. The use cases following merely treat SR based network monitoring as adding a new method to realise a Continuity Check. In special cases, the SR based Continuity Check offers limited Connectivity Verification properties. This will be in the use case descriptions, if applicable." If so, one has to be removed. --- OLD: " The use cases following merely treat SR based network monitoring as adding a new method to realise a Continuity Check. In special cases, the SR based Continuity Check offers limited Connectivity Verification properties. This will be in the use case descriptions, if applicable." Proposed rephrasing to improve readability NEW This document propose the use of SR based network monitoring as a new Conti= nuity Check method. In some special cases, it also covers some limited Conn= ectivity Verification. When applicable, this is indicated in the descriptio= n of the use case. --- OLD: a topology data base of MPLS SR domain to be monitored. NEW: a topology data base of the MPLS SR domain to be monitored. --- =A75.1 " Finally, the PMS sets up and sends packets to monitor connectivity of the ECMP routed paths. The PMS does this by creating a measurement packet with the following label stack (top to bottom): 20 - 30 - 10. The ping packets reliably use the monitored path, if the IP-address information which has been detected by the MPLS trace route is used as the IP destination address (note that this IP address isn't used or required for any IP routing)." >From the first sentence, I'm understanding that the traceroute part is fini= shed and now, end to end monitoring packets are sent using the regualr MPLS= dataplane. In such context, I'm not following the latest sentence. You are saying that the PMS sends a measurement packet with label stack 20 = - 30 - 10 and IP destination address previously detected. For me, such measurement packet will follow the path LERi (20), LERj (30), = PMS (10). A priori the PSM will send capture back the packet, hence this pa= cket will not be forwarded using the IP destination address. So why is this= IP destination address important? --- =A75.1 " If correct forwarding along the desired paths has to be checked, or multiple physical connections exist between any two nodes, either additional information based on an MPLS trace route or additional Adj-SIDs are required to deal with ECMP." You seem to want to avoid ECMP. In this case, why not using: "a label stack including all Adj-SIDs along that path" rather than "a label stack including all Node-SIDs along that path" ? That seems to do what you want (no ECMP), with no additional label/complexi= ty required --- =A75.2 "R1 addresses Lx by the Adjacency SID 99x" Notation "Lx" has never been used so far. I guess: NEW: R1 addresses link x (Lx) by the Adjacency SID 99x --- =A75.2 " If the connected router is not SR compliant, a tunneling technique can be used to tunnel the probe and its MPLS stack to the first SR router. " That detail has already been discussed elsewhere in the draft, so to improv= e clarity, I'd propose to remove that sentence. --- =A7 7 "The delay measurements of PMS and where compared based on a statistical te= st published by the IPPM WG [RFC6576]." A word seems missing after "and". Possible NEW: The delay measurements where compared based on a statistical = test published by the IPPM WG [RFC6576]. --- =A78 "MPLS SR topology awareness should allow the SID to monitor liveliness of S= IDs" May be you mean :s/should allow the SID/should allow the PMS --- =A78 The following rephrasing may be easier to read OLD: To match control plane information with data plane information, MPLS OAM functions as defined for example by RFC4379 [RFC4379] are enhanced to allow collection of data relevant to check all relevant types of Segment IDs by [I-D.draft-ietf-mpls-spring-lsp-ping]. NEW: To match control plane information with data plane information for all relevant types of Segment IDs, [I-D.draft-ietf-mpls-spring-lsp-ping] enhance MPLS OAM functions defined by RFC4379 [RFC4379]. Thanks, Regards, Bruno From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Sent: Tuesday, February 07, 2017 9:55 AM To: DECRAENE Bruno IMT/OLN Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-chairs@= ietf.org Subject: WG: draft-ietf-spring-oam-usecase - shepherd review Hi Bruno, thanks for your thorough review. Your comments help to clarify how to use S= R to improve monitoring of an MPLS domain. We've adapted text, there's some= mostly minor discussion on a few issues. Comments are marked [RG] in your = text below. Version -05 has just been submitted. Regards, Ruediger Von: bruno.decraene@orange.com [mailto:br= uno.decraene@orange.com] Gesendet: Dienstag, 17. Januar 2017 17:35 An: draft-ietf-spring-oam-usecase@ietf.org Cc: spring@ietf.org; spring-chairs@ietf.org Betreff: draft-ietf-spring-oam-usecase - shepherd review Hi authors, As the document shepherd, I have reviewed draft-ietf-spring-oam-usecase-04. Please find some comments below. Best regards, Bruno --- =3D=3D=3D=3D=3D Major comment Multiple sections or text of the document seems to mix continuity check and= connectivity verification. I think the document would be clearer if both p= oints were more structured. e.g. introducing each, then explaining their in= teractions, then detailing each one independently, possibly in independent = sub-section. [RG] Good point, done (added section "Terminology"). =3D=3D=3D=3D=3D Minor comments =A72 "enabling MPLS topology detection based on IGP signaled segments as specifi= ed at [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]." You could probably add draft-ietf-idr-bgp-ls-segment-routing-ext, as an e= xternal server is less likely to be part of the IGP. [RG] Done. ---- "As compared to LDP, Segment Routing is expected to simplify the system by = enabling MPLS topology detection based on IGP signaled segments" I find the term "MPLS topology" loosely defined. As I read it, it could enc= ompass: - the network topology, which can be learnt by listening to the IGP, regard= less of the use of LDP or Segment Routing - MPLS signaling topology. With segment routing, it can be learnt by listen= ing to IGP. For LDP, it would require looking at the LDP configuration or L= DP status. - MPLS signaled labels. With segment routing, it can be learnt by listening= to IGP. For LDP, it would require one T-LDP session per node. Could you please elaborate on what is exactly meant with "MPLS topology"? [RG] Again, good point, done (at least tried to..). --- One paragraph is about the use of SRMS in LDP network. "The system applies = to monitoring of LDP LSP's ...." Another paragraph is about the use of SRMS in pre-segment routing networks.= "The MPLS path monitoring system described by this document can be realise= d with pre-Segment Routing (SR) based technology." It's not crystal clear to mean what you mean by "pre-Segment Routing (SR) b= ased technology." I could read "LDP", in which case, both paragraph are abo= ut the same subject. In which case, an editorial update would be useful to = merge those two paragraphs, as they are related to the same case. (or at le= ast very related) [RG] Clarified sentence, moved text, added a reference to the section textt= was moved to. --- "The system offers several benefits for network monitoring." I would expect those benefits to be spelled out in the document. The senten= ce is indeed followed by a set of sentences, but it's not clear to me wheth= er those sentences details those benefits or not. The first two sentences l= ooks like benefits. The third one ["MPLS path trace function (whose specifi= cation and features are not part of this use case) is required, if the actu= al data plane of a router should be checked against its control plane.]", d= oes not looks like a benefit to me. Could you please highlight which are the specific benefits? [RG] Good point, changed paragraph to bullet point list, focus is on "benef= its". --- "MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane." That sentence is 2 years old. Since then, has the MPLS WG progressed on thi= s? If so, could you please indicate the related draft. If not, why? [RG] Done. And is this related to a further paragraph: " Documents discussing SR OAM requirements and possible solutions to allow SR usage as described by this document have been submitted already, see [I-D.ietf-spring-sr-oam-requirement] and [I-D.ietf-mpls-spring-lsp-ping]." If so, both could probably be merged. Any may be "already" is not appropriate for an RFC. [RG] The statement has been changed. AFAIK the requirements cover more than the features added by I-D.ietf-mpls-spring-lsp-ping. I think it's fair= to keep them separate. And I don't think it's up to the authors of the use cases to decide about a merge. --- >From an editorial standpoint, I feel that the text mixes: - the monitoring part, which is expected to be forwarded in the dataplane j= ust like users packets. - the trace/OAM features, which requires specific features on transit nodes= , hence are not forwarded in the dataplane like users packets. May be those 2 functions could be better distinguished in the text. [RG] Done. --- "By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379],= a segment based routing LSP monitoring system may: o easily detect ECMP functionality and properties of paths at data leve= l." It's not clear to me what is meant by "properties" nor "at data level". Regarding detecting ECMP functionality, it could be detected with SR IGP ex= tensions, both for layer 3 ECMP (adj_SID) and layer 2 ECMP (draft-ietf-isi= s-l2bundles). Or may be you mean load-balancing behavior over ECMP links/path. But this i= s not what is written. --- "limit the MPLS label stack of an OAM packet to a minmum of 3 labels." Do you mean :s/minmum/maximum Why is this important? - If this is a hard limitation on the SRMS, then the probing packets would = also need to have a max of 3 labels. Which is typically not achievable. - Why would the SRMS have such a limitation for a pure software based featu= re? [RG] Changed text and still like to maintain the idea of using no more than= 3 labels as an alternative to specify a path by labels only. MPLS trace is a fair option i= n the case of multiple physical interfaces & ECMP between two nodes. --- "It doesn't have to support any specialised protocol stack," What do you mean by this? It does need to support the MPLS protocol stack, probably the IP protocol s= tack, the IGP protocol stack in order to learn the topology/labels, the LSP= Ping protocol stack if OAM test are required.... [RG] Changed the sentence. IP/MPLS packet formats need to be understood, pa= ckets must be built, sent and received, RFC4379 must be supported and IGP/M= PLS topology should be maintained (i.e., IGP listening, SPF and optional co= rrelation with MPLS traceroute). Static MPLS and IP routes do. Nothing else. --- "The MPLS monitoring servers are the single entities pushing monitoring pac= ket label stacks." may be :s/single/only :s/pushing/sending and receiving [RG] Changed the section and the sentence, added receiving. --- "If the depth of label stacks to be pushed by a path monitoring system (PMS) are of concern for a domain, a dedicated server based path monitoring architecture allows limiting monitoring related label stack pushes to these servers." If the limitation is on the PMS, as already expressed I don't see why a pur= e software packet sender would be limited in term of the number of labels (= which are just bytes) sent. If the limitation is elsewhere, could you pleas= e elaborate. The second part of the sentence could be rephrased for an easier understand= ing. (it took me 3 readings to guess that the important part is running the= PMS on dedicated server. Although I'm even sure why using a software on a = server solves the problem compared to using a software on the routing engin= e of a router (which may also be x86). [RG] Changed the sentence, saying a server has no label stack depth limitat= ions. --- =A73 "It can send pure monitoring packets" What do you mean by "pure"? >From the next sentence, I'd guess that you mean "monitoring packets with an= y payload" --- "Segment Routing here is used as a means of adding label stacks and hence transport to standard MPLS OAM packets, which then detect correspondence of control and data plane of this (or any other addressed) path." Could probably be better rephrased. e.g. Segment Routing here is used as a mean of transporting probes or standard M= PLS OAM packets, along any path. When MPLS OAM packets are used, consist= ency between control and data plane may be checked. [RG] Good point, should be better phrased now. --- "if the PMS is an IP host not connected to the MPLS domain, the PMS can send its probe with the list of SIDs/Labels onto a suitable tunnel providing an MPLS access to a router which is part of the monitored MPLS domain." Probably some text should be added to cover this point. (e.g. the tunnel MU= ST be secured and provide authentication of the sender and cryptographic si= gnature. Also this has security implication as MPLS VPNs are based on the inability = of the sender to send MPLS packet, while this option open this door. This s= hould be discussed in the security consideration section. [RG] Fair observation, I've added some text. ---- =A74.1 "To be able to work with the smallest possible SR label stack, first a suit= able MPLS OAM method is used to detect the ECMP routed path between LER i t= o LER j which is to be monitored " This is not very clear to me. Could this be rephrased? e.g. What to do mean= by "MPLS OAM method?" Is this MPLS OAM API (e.g. LSP ping)? Is this an alg= orithm to define the path? (but the end of the sentence seems to indicate t= hat the path is given as input "which is to be monitored") is "detect" the = best term? Also, this really the first sentence of the section. Could you first introd= uce the global picture and the goal, rather than starting with an optimisat= ion "To be able to work with the smallest possible SR label stack" [RG] Rephrased the paragraph. --- "The packet will only reliably use the monitored path, if the label and address information used in combination with the MPLS OAM method of choice is identical to that of the monitoring packet." Could this be rephrased to improve clarity? [RG] Rephrased the paragraph. ---- "The path PMS to LER i must be available." "The path LER j to PMS must be a= vailable." Given that the goal is to monitor paths which are assumed to be available, = if you detect a packet loss, how do you know which segment has an error? In= deed, packet loss could happen on this PMS to LERi path, while you think th= at you are measuring the path LER i to LER j. --- "This path must be detectable" What does this mean? [RG] Rephrased the paragraph. --- "If ECMP is deployed, it may be desired to measure along both possible path= s which a packet may use between LER i and LER j." - ECMP may be more than both. - If you don't want to follow an ECMP path, why are you sending packet alon= g an ECMP path? SR allows enforcing a single path among multiple ECMPs. [RG] Rephrased the sentence. ---- "Further changes in ECMP functionality at LER i will impact results." Can you elaborate on this? Some LSR dynamically change their load-balancing= behavior in order to try to equally spread the load on all ECMP paths. Is = this behavior an issue? (i.e. are PMS and dynamic load-balancing adaptation= mutually incompatible?) Also if you want to monitor the (customer) ECMP path, would it be good to d= etect any change in this path, including a change trigger by such dynamic l= oad-balancing adaptation? And if you don't want to monitor the ECMP path, may be you should only moni= tor individual path. [RG] Rephrased the sentence. ---- " Determining a path to be executed prior to a measurement may also be done by setting up a label stack including all Node SIDs along that path (if LSR1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities." Adding all node SID do not remove ECMP functionnality. e.g. there could = be multiple links between LSR1 and LER i. [RG] You are right, added text. --- "Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with little effort and very excellent scalability." Why is the scalability excellent? It looks to me that some links near the P= MS will be "heavily" used to test all paths. "little effort" is not very specific. IMHO a key benefit is the ability to = monitor all network paths by deploying a single PMS, while some others tech= niques requires the deployment of many probes. [RG] Added text to clarify properties of the solution. --- "The PMS does not require access to LSR/LER management interfaces " The choice of the term "interfaces" seems debatble to me as it could be mis= read as physical interface being monitored. As the goal of this document is= to monitor path and interfaces, I'd rather use "interface" only to refer t= o physical interface. [RG] Replaced "interfaces" by "plane information". --- =A74.2 Same comment: if the PMS detects loss of probe packets, it does not know wh= ether the loss happens on the monitored bundle, or the path from the PMS to= R2 or the path from R1 to the PMS. So how do you compute/measure the characteristics of the sub-path (here the= bundle) that you want to monitor? [RG] You are right, added text. --- =A74.3 "In the previous example, a uni-directional fault on the middle link in direction of R2 to R1 would be localized by sending the following two probes with respective segment lists: o 72, 662, 992, 664 o 72, 663, 992, 664" "The first probe would fail while the second would succeed." I would have said the opposite as 663 maps to the middle link which is assu= med to be faulty. The formulation of the text is debatable as you are using the a priori know= nledge of the failure in order to define the probes which needs to be sent. More generally, as you are sending packets over a path longer than the one = to be tested, what you need is to also monitor those extra sub-path in orde= r to be able to check whether the failure is indeed on the sub-path that yo= u want to test, rather than the paths from the PMS to the first node on the= tested path, or the path from the last node on the tested path to the PMS. [RG] Thanks, added text and a generic statement addressing your second poi= nt. I don't want to describe a complete solution as part of a use case, I h= ope that's acceptable. --- =A76 "Next: LDP or RSVP-TE label identifying the path to LER j at LER i. if LER j is the ingress of the RSVP-TE LSP, LER j does not have a label ide= ntifying this LSP. Eventually, SR may allocate a binding SID to this RSVP-T= E LSP. if LER j is a transit LSR of the RSVP-TE LSP, how does the PMS learn this l= abels, which a priori is only know from LER j and its upstream LSR. [RG] I'm not an RSVP-TE expert. Next:... says path from LER i to LER j (a= t LER i), in case of RSVP TE a tunnel would start in LER I and terminate in= j. Changed text. If that can't be settled, I don't care about RSVP-TE and I'd rather remove = text than work on it. --- =A77 " MPLS SR topology awareness should allow the SID to monitor liveliness of most types of SIDs (this may not be recommendable if a SID identifies an inter domain interface)" Why would it not be recommendable to monitor an inter domain SID/interface? [RG] I'm sure that the principle works on interfaces within an IGP domain = (and that what the use case offers). As with RSVP-TE, it may also work on i= nter domain SIDs, however I prefer not to have to discuss that in detail, a= s I didn't think it through. Hence, if someone (not me) provides text on i= nter domain SID/interface or RSVP-TE. which is acceptable to the chairs/IE= TF, I'm happy to add it. If this must be a scetch of workable solution, and= I'm supposed to work it out, I'm not interested. I don't say, any of this = is impossible or a bad idea. I don't have time to work on it. --- "To match control plane information with data plane information, MPLS OAM functions as defined for example by RFC 4379 [RFC4379] should be enhanced to allow collection of data relevant to check all relevant types of Segment IDs." Is there a document working on this? (e.g. draft-ietf-mpls-spring-lsp-ping = ?) If so, it could be referenced. inter domain SID/interface [RG] Done. --- =A78 "While the PMS based use cases explained in Section 3 " I think uses-cases are explained in section 4. [RG] Done. --- =A76 "An implementation report on a PMS operating in an LDP domain is given in [= I-D.leipnitz-spring-pms-implementation-report]" This document is more than an implementation. IMHO it would deserve a short= text introducing its scope and result. e.g. "[I-D.leipnitz-spring-pms-implementation-report] present a PMS implementati= on report and compare delays measured with one PMS to the results of three = IPPM standard conformant Measurement Agents, using the IPPM methodology as = defined in [RFC6576]. The results show that the PMS measurements equal those captured by an IPPM conformant measurement system. The ADK test is successful by comparing the measurement values of the round-trip delays for packets with a size of 64 bytes." (but I'm not an IPPM expert, so authors should be able to provide a better = text) [RG] Thanks for the positive feedback, done. =3D=3D=3D=3D=3D Nits "IGP LSA" LSA is not defined nor expanded on first use. Plus it is protocol specific (OSPF). Could you cover both OSPF and IS-IS or= use a term which is not protocol specific? Especially since a priori you m= ean LSDB analysis, rather than LSA. --- :s/minmum/minimum --- OLD: used as a means of adding label stacks and hence transport to standard= MPLS OAM packets NEW: used as a mean of adding label stacks and hence transport standard MPL= S OAM packets to any node [RG] Text has been removed or changed.. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED56C59OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rued= iger,

&n= bsp;

Thanks = for the answer and the updated draft which is indeed improved.

&n= bsp;

Reading= the new version, I have additional comments below:

&n= bsp;

&n= bsp;

---

Idnits = report 1 issue: "=3D=3D It seems as if not all pages are separated by = form feeds - found 0 form feeds but 16 pages"

https://tools.ietf.org/idnits?url=3Dhttps://to= ols.ietf.org/id/draft-ietf-spring-oam-usecase-05.txt<= /p>

&n= bsp;

---

=A72

"T= his document describes illustrates a system"

syntax = error.

&n= bsp;

--=

"&= nbsp;  o  A single centralized MPLS monitoring system which is ab= le to

 &= nbsp;    perform a continuity check (ping) along all Label S= witched Paths

 &= nbsp;    of the SR domain.  Monitoring packets never le= ave data plane.

&n= bsp;

 &= nbsp; o  The MPLS ping (or continuity check) packets never leave the M= PLS

 &= nbsp;    data plane."

  =

Two lat= est sentences seems redundant. 

&n= bsp;

--=

"M= onitoring packets never leave data plane."

May be = :s/data plane/user data plane

&n= bsp;

On my s= ide, I'd see one addition advantage which does not seem to be mentioned:

since t= his is the same system sending and receiving the monitoring packet, the mon= itoring system may freely choose the payload of the packet. This allows sen= ding probing packets representing real customer traffic, possibly from multiple service (e.g. small VoIP packet, = larger HTTP packets), embedding useful monitoring data (e.g. accurate time = stamps since both sender and receiver have the same clock, sequence numbers= to ease the measurement...)

&n= bsp;

--=

" = o  An MPLS monitoring system, maybe several ones if redundancy is=

 &= nbsp;    desired, which apply SR for OAM purposes as describ= ed, offer the

 &= nbsp;    possibilty to scale and design a flexible MPLS OAM = platform as

 &= nbsp;    suitable for a provider."

&n= bsp;

I feel = that the sentence could be rephrased to enhance its readability.=

e.g. &q= uot;Such MPLS monitoring system offer flexibility in term of deployment: fr= om one single centralized one to a set of distributed systems (e.g. on a pe= r region or service base), and in term of redundancy from 1+1 to N+1"

&n= bsp;

--=

"c= onstruct ping packets respectively, which can be precisely steered to paths= whose connectivity is to be checked, also if ECMP is present"

- I'm n= ot sure what "respectively" refers to.

- may b= e :s/also if ECMP is present/including when ECMP is present

But fee= l free to disregard the comment as English is not my first language.

&n= bsp;

---

" = If the

 &= nbsp; depth of label stacks to be pushed for the purpose of path monitoring=

 &= nbsp; is of concern for a domain, a dedicated PMS server allows to push

 &= nbsp; monitoring related label stacks of arbitrary depth on this server.&qu= ot;

 &= nbsp;

 S= entence is not easy to parse. I guess you mean: 

 &= quot;If the monitoring of a specific topology/domain requires pushing a lar= ge label stack, one may use a software based implementation which is usuall= y more flexible than an hardware based one."

 -= --

  = "RFC 4379 [RFC7276] specifies a Connectivity Verification for MPLS dom= ains."

  = Do you mean 4379 or 7276 or both? (I would assume :s/[RFC7276]/[RFC4379])

  =

 -= --

:s/As R= FC 7276 sates/As RFC 7276 states

 -= --

=A73 Co= nnectivity Verification.

 T= he below text seems duplicated:

"&= nbsp;      RFC 7276 [RFC7276] defines Connectivity= Verification as a

 &= nbsp;     mechanism to check connectivity between two n= odes by checking

 &= nbsp;     whether a path between both can be used. = ; RFC 4379 [RFC7276]

 &= nbsp;     specifies a Connectivity Verification for MPL= S domains.  As RFC

 &= nbsp;     7276 sates, Connectivity Verification and Con= tinuity Checks are

 &= nbsp;     considered complementary mechanisms and are o= ften used in

 &= nbsp;     conjunction with each other.  The use ca= ses following merely

 &= nbsp;     treat SR based network monitoring as adding a= new method to

 &= nbsp;     realise a Continuity Check.  In special = cases, the SR based

 &= nbsp;     Continuity Check offers limited Connectivity = Verification

 &= nbsp;     properties.  This will be in the use cas= e descriptions, if

 &= nbsp;     applicable."

&n= bsp;

If so, = one has to be removed.

&n= bsp;

---

OLD:

  = "    The use cases following merely

 &= nbsp;     treat SR based network monitoring as adding a= new method to

 &= nbsp;     realise a Continuity Check.  In special = cases, the SR based

 &= nbsp;     Continuity Check offers limited Connectivity = Verification

 &= nbsp;     properties.  This will be in the use cas= e descriptions, if

 &= nbsp;     applicable."   

&n= bsp;

Propose= d rephrasing to improve readability

NEW

This do= cument propose the use of SR based network monitoring as a new Continuity C= heck method. In some special cases, it also covers some limited Connectivit= y Verification. When applicable, this is indicated in the description of the use case.

&n= bsp;

---

OLD: a = topology data base of MPLS SR domain to be monitored.

NEW: a = topology data base of the MPLS SR domain to be monitored.=

&n= bsp;

---

=A75.1<= o:p>

" = Finally, the PMS sets up and sends packets to monitor

 &= nbsp; connectivity of the ECMP routed paths.  The PMS does this by cre= ating

 &= nbsp; a measurement packet with the following label stack (top to bottom):<= o:p>

 &= nbsp; 20 - 30 - 10.  The ping packets reliably use the monitored path,= if

 &= nbsp; the IP-address information which has been detected by the MPLS trace<= o:p>

 &= nbsp; route is used as the IP destination address (note that this IP

 &= nbsp; address isn't used or required for any IP routing)."<= /span>

 &= nbsp;

From th= e first sentence, I'm understanding that the traceroute part is finished an= d now, end to end monitoring packets are sent using the regualr MPLS datapl= ane. In such context, I'm not following the latest sentence.

You are= saying that the PMS sends a measurement packet with label stack 20 - 30 - = 10 and IP destination address previously detected.

For me,= such measurement packet will follow the path LERi (20), LERj (30), PMS (10= ). A priori the PSM will send capture back the packet, hence this packet wi= ll not be forwarded using the IP destination address. So why is this IP destination address important? 

&n= bsp;

&n= bsp;

---

=A75.1<= o:p>

" = If correct forwarding

 &= nbsp; along the desired paths has to be checked, or multiple physical<= /o:p>

 &= nbsp; connections exist between any two nodes, either additional=

 &= nbsp; information based on an MPLS trace route or additional Adj-SIDs are

 &= nbsp; required to deal with ECMP."

 &= nbsp;

You see= m to want to avoid ECMP. In this case, why not using:

"a= label stack including all Adj-SIDs along that path"=

rather = than

"a= label stack including all Node-SIDs along that path"

?<= /o:p>

That se= ems to do what you want (no ECMP), with no additional label/complexity requ= ired

&n= bsp;

---

=A75.2<= o:p>

"R= 1 addresses Lx by the Adjacency SID 99x"

&n= bsp;

Notatio= n "Lx" has never been used so far. I guess:

NEW: R1= addresses link x (Lx) by the Adjacency SID 99x

&n= bsp;

---

=A75.2<= o:p>

" = If the connected router

 &= nbsp; is not SR compliant, a tunneling technique can be used to tunnel the<= o:p>

 &= nbsp; probe and its MPLS stack to the first SR router. "

 &= nbsp;

That de= tail has already been discussed elsewhere in the draft, so to improve clari= ty, I'd propose to remove that sentence.

&n= bsp;

---

=A7 7

"T= he delay measurements of PMS and where compared based on a statistical test= published by the IPPM WG [RFC6576]."

A word = seems missing after "and".

Possibl= e NEW: The delay measurements where compared based on a statistical test pu= blished by the IPPM WG [RFC6576].

&n= bsp;

---

=A78

"M= PLS SR topology awareness should allow the SID to monitor liveliness of SID= s"

&n= bsp;

May be = you mean :s/should allow the SID/should allow the PMS

---

=A78

The fol= lowing rephrasing may be easier to read

&n= bsp;

OLD:

 &= nbsp; To match control plane information with data plane information, MPLS<= o:p>

 &= nbsp; OAM functions as defined for example by RFC4379 [RFC4379] are

 &= nbsp; enhanced to allow collection of data relevant to check all relevant

 &= nbsp; types of Segment IDs by [I-D.draft-ietf-mpls-spring-lsp-ping].

&n= bsp;

NEW:

 &= nbsp; To match control plane information with data plane information

 &= nbsp; for all relevant types of Segment IDs,

 &= nbsp; [I-D.draft-ietf-mpls-spring-lsp-ping] enhance MPLS<= /p>

 &= nbsp; OAM functions defined by RFC4379 [RFC4379].

&n= bsp;

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: Ruediger= .Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
Sent: Tuesday, February 07, 2017 9:55 AM
To: DECRAENE Bruno IMT/OLN
Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-= chairs@ietf.org
Subject: WG: draft-ietf-spring-oam-usecase - shepherd review

 

Hi Brun= o,

&n= bsp;

thanks = for your thorough review. Your comments help to clarify how to use SR to im= prove monitoring of an MPLS domain. We’ve adapted text, there’s= some mostly minor discussion on a few issues. Comments are marked [RG] in your text below.

&n= bsp;

Version= -05 has just been submitted.

&n= bsp;

Regards, R= uediger

 = ;

Von: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Gesendet: Dienstag, 17. Januar 201= 7 17:35
An: draft-ietf-spring-oam-usecase= @ietf.org
Cc: spring@ietf.org; spring-chairs@ietf.org
Betreff: draft-ietf-spring-oam-usecase - shepherd review<= /span>

 

Hi authors,

 

As the document shepherd, I hav= e reviewed draft-ietf-spring-oam-usecase-04.

Please find some comments below= .

 

Best regards,=

Bruno

---

 

=3D=3D=3D=3D=3D Major comment

Multiple sections or text of th= e document seems to mix continuity check and connectivity verification. I t= hink the document would be clearer if both points were more structured. e.g= . introducing each, then explaining their interactions, then detailing each one independently, possibly in ind= ependent sub-section.

&n= bsp;

[RG] Go= od point, done (added section “Terminology”).=

 

=3D=3D=3D=3D=3D Minor comments<= o:p>

=A72

"enabling MPLS topology de= tection based on IGP signaled segments as specified at [I-D.ietf-isis-segme= nt-routing-extensions] and

   [I-D.ietf-ospf-seg= ment-routing-extensions]."

You could probably add &nb= sp; draft-ietf-idr-bgp-ls-segment-routing-ext, as an external server is les= s likely to be part of the IGP.

&n= bsp;

[RG] Do= ne.

 

----

"As compared to LDP, Segme= nt Routing is expected to simplify the system by enabling MPLS topology det= ection based on IGP signaled segments"

I find the term "MPLS topo= logy" loosely defined. As I read it, it could encompass:

- the network topology, which c= an be learnt by listening to the IGP, regardless of the use of LDP or Segme= nt Routing

- MPLS signaling topology. With= segment routing, it can be learnt by listening to IGP. For LDP, it would r= equire looking at the LDP configuration or LDP status.

- MPLS signaled labels. With se= gment routing, it can be learnt by listening to IGP. For LDP, it would requ= ire one T-LDP session per node.

 

Could you please elaborate on w= hat is exactly meant with "MPLS topology"?

&n= bsp;

[RG] Ag= ain, good point, done (at least tried to..).

&n= bsp;

---

One paragraph is about the use = of SRMS in LDP network. "The system applies to monitoring of LDP LSP's= ...."

Another paragraph is about the = use of SRMS in pre-segment routing networks. "The MPLS path monitoring= system described by this document can be realised with pre-Segment Routing= (SR) based technology."

 

It's not crystal clear to mean = what you mean by "pre-Segment Routing (SR) based technology." I c= ould read "LDP", in which case, both paragraph are about the same= subject. In which case, an editorial update would be useful to merge those two paragraphs, as they are related to the same case. (or a= t least very related)

&n= bsp;

[RG] Cl= arified sentence, moved text, added a reference to the section textt was mo= ved to.

 

---

"The system offers several= benefits for network monitoring."

I would expect those benefits t= o be spelled out in the document. The sentence is indeed followed by a set = of sentences, but it's not clear to me whether those sentences details thos= e benefits or not. The first two sentences looks like benefits. The third one ["MPLS path trace function (whose = specification and features are not part of this use case) is required, if t= he actual data plane of a router should be checked against its control plan= e.]", does not looks like a benefit to me.

Could you please highlight whic= h are the specific benefits?

&n= bsp;

[RG] Go= od point, changed paragraph to bullet point list, focus is on “benefi= ts”.

---

"MPLS path trace function = (whose specification and features

   are not part of th= is use case) is required, if the actual data plane

   of a router should= be checked against its control plane."

 

That sentence is 2 years old. S= ince then, has the MPLS WG progressed on this? If so, could you please indi= cate the related draft. If not, why?

&n= bsp;

[RG] Do= ne.

 

And is this related to a furthe= r paragraph:

"   Documents di= scussing SR OAM requirements and possible solutions to

   allow SR usage as = described by this document have been submitted

   already, see [I-D.= ietf-spring-sr-oam-requirement] and

   [I-D.ietf-mpls-spr= ing-lsp-ping]."

   =

If so, both could probably be m= erged.

Any may be "already" = is not appropriate for an RFC.

&n= bsp;

[RG] Th= e statement has been changed. AFAIK the requirements cover more

than th= e features added by I-D.ietf-mpls-spring-lsp-ping. I think it’s fair = to

keep th= em separate. And I don’t think it’s up to the authors of the use

cases t= o decide about a merge.

 

---

From an editorial standpoint, I= feel that the text mixes:

- the monitoring part, which is= expected to be forwarded in the dataplane just like users packets.

- the trace/OAM features, which= requires specific features on transit nodes, hence are not forwarded in th= e dataplane like users packets.

 

May be those 2 functions could = be better distinguished in the text.

&n= bsp;

[RG] Do= ne.

 

---

"By utilising the ECMP rel= ated tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing L= SP monitoring system may:

   o  easily det= ect ECMP functionality and properties of paths at data level."

It's not clear to me what is me= ant by "properties"  nor "at data level".

Regarding detecting ECMP functi= onality, it could be detected with SR IGP extensions, both for layer 3 ECMP= (adj_SID)  and layer 2 ECMP (draft-ietf-isis-l2bundles).

Or may be you mean load-balanci= ng behavior over ECMP links/path. But this is not what is written.

 

---

"limit the MPLS label stac= k of an OAM packet to a minmum of 3 labels."

Do you mean :s/minmum/maximum <= o:p>

 

Why is this important?

- If this is a hard limitation = on the SRMS, then the probing packets would also need to have a max of 3 la= bels. Which is typically not achievable.

- Why would the SRMS have such = a limitation for a pure software based feature?

&n= bsp;

[RG] Ch= anged text and still like to maintain the idea of using no more than 3 labe= ls as an

alterna= tive to specify a path by labels only. MPLS trace is a fair option in the c= ase

of mult= iple physical interfaces & ECMP between two nodes.

 

---

"It doesn't have to suppor= t any specialised protocol stack,"

What do you mean by this? =

It does need to support the MPL= S protocol stack, probably the IP protocol stack, the IGP protocol stack in= order to learn the topology/labels, the LSP Ping protocol stack if OAM tes= t are required....

&n= bsp;

[RG] Ch= anged the sentence. IP/MPLS packet formats need to be understood, packets m= ust be built, sent and received, RFC4379 must be supported and IGP/MPLS top= ology should be maintained (i.e., IGP listening, SPF and optional correlation with MPLS traceroute). Static MPLS= and IP routes do. Nothing else.

&n= bsp;

---

"The MPLS monitoring serve= rs are the single entities pushing monitoring packet label stacks."

may be

:s/single/only

:s/pushing/sending and receivin= g

&n= bsp;

[RG] Ch= anged the section and the sentence, added receiving.

 

---

"If the depth

   of label stacks to= be pushed by a path monitoring system (PMS) are of

   concern for a doma= in, a dedicated server based path monitoring

   architecture allow= s limiting monitoring related label stack pushes to

   these servers.&quo= t;

   =

If the limitation is on the PMS= , as already expressed I don't see why a pure software packet sender would = be limited in term of the number of labels (which are just bytes) sent. If = the limitation is elsewhere, could you please elaborate.

The second part of the sentence= could be rephrased for an easier understanding. (it took me 3 readings to = guess that the important part is running the PMS on dedicated server. Altho= ugh I'm even sure why using a software on a server solves the problem compared to using a software on the routing= engine of a router (which may also be x86).

&n= bsp;

[RG] Ch= anged the sentence, saying a server has no label stack depth limitations.

&n= bsp;

---

=A73

"It can send pure monitori= ng packets"

What do you mean by "pure&= quot;?

From the next sentence, I'd gue= ss that you mean "monitoring packets with any payload"=

---

"Segment=

   Routing here is us= ed as a means of adding label stacks and hence

   transport to stand= ard MPLS OAM packets, which then detect

   correspondence of = control and data plane of this (or any other

   addressed) path.&q= uot;

   =

Could probably be better rephra= sed. e.g.   

 

Segment Routing here is used as= a mean of transporting probes or standard MPLS OAM packets, along any path= . When MPLS OAM packets are used,    consistency between con= trol and data plane may be checked.

&n= bsp;

[RG] Go= od point, should be better phrased now.

 

---

"if the PMS is an IP host = not connected to the MPLS domain,

   the PMS can send i= ts probe with the list of SIDs/Labels onto a

   suitable tunnel pr= oviding an MPLS access to a router which is part of

   the monitored MPLS= domain."

 

Probably some text should be ad= ded to cover this point. (e.g. the tunnel MUST be secured and provide authe= ntication of the sender and cryptographic signature.

Also this has security implicat= ion as MPLS VPNs are based on the inability of the sender to send MPLS pack= et, while this option open this door. This should be discussed in the secur= ity consideration section.

&n= bsp;

[RG] Fa= ir observation, I’ve added some text.

&n= bsp;

----

=A74.1

 

"To be able to work with t= he smallest possible SR label stack, first a suitable MPLS OAM method is us= ed to detect the ECMP routed path between LER i to LER j which is to be mon= itored "

This is not very clear to me. C= ould this be rephrased? e.g. What to do mean by "MPLS OAM method?"= ; Is this MPLS OAM API (e.g. LSP ping)? Is this an algorithm to define the = path? (but the end of the sentence seems to indicate that the path is given as input "which is to be monitored") is &= quot;detect" the best term?

 

Also, this really the first sen= tence of the section. Could you first introduce the global picture and the = goal, rather than starting with an optimisation "To be able to work wi= th the smallest possible SR label stack"

&n= bsp;

[RG] Re= phrased the paragraph.

&n= bsp;

---

"The packet will

   only reliably use = the monitored path, if the label and address

   information used i= n combination with the MPLS OAM method of choice is

   identical to that = of the monitoring packet."

 

   Could this be reph= rased to improve clarity?  

&n= bsp;

[RG] Re= phrased the paragraph.

----  

"The path PMS to LER i mus= t be available." "The path LER j to PMS must be available."

Given that the goal is to monit= or paths which are assumed to be available, if you detect a packet loss, ho= w do you know which segment has an error? Indeed, packet loss could happen = on this PMS to LERi path, while you think that you are measuring the path LER i to LER j.

---

"This path must be detecta= ble"

What does this mean?=

&n= bsp;

[RG] &n= bsp;Rephrased the paragraph.

 

---

"If ECMP is deployed, it m= ay be desired to measure along both possible paths which a packet may use b= etween LER i and LER j."

- ECMP may be more than both.

- If you don't want to follow a= n ECMP path, why are you sending packet along an ECMP path? SR allows enfor= cing a single path among multiple ECMPs.

&n= bsp;

[RG] &n= bsp;Rephrased the sentence.

 

----

"Further changes in ECMP f= unctionality at LER i will impact results."

Can you elaborate on this? Some= LSR dynamically change their load-balancing behavior in order to try to eq= ually spread the load on all ECMP paths. Is this behavior an issue? (i.e. a= re PMS and dynamic load-balancing adaptation mutually incompatible?)

Also if you want to monitor the= (customer) ECMP path, would it be good to detect any change in this path, = including a change trigger by such dynamic load-balancing adaptation?<= /o:p>

And if you don't want to monito= r the ECMP path, may be you should only monitor individual path.=

&n= bsp;

[RG] &n= bsp;Rephrased the sentence.

&n= bsp;

----

"   Determining = a path to be executed prior to a measurement may also be<= /p>

   done by setting up= a label stack including all Node SIDs along that

   path (if LSR1 has = Node SID 40 in the example and it should be passed

   between LER i and = LER j, the label stack is 20 - 40 - 30 - 10).  The

   advantage of this = method is, that it does not involve MPLS OAM

   functionality and = it is independent of ECMP functionalities."

 

   Adding all node SI= D do not remove ECMP functionnality. e.g. there could be multiple links bet= ween LSR1 and LER i.

&n= bsp;

[RG] &n= bsp;You are right, added text.

&n= bsp;

   ---

  "Monitoring an MPLS= domain by a PMS based on SR offers the option of

   monitoring complet= e MPLS domains with little effort and very

   excellent scalabil= ity."

Why is the scalability excellen= t? It looks to me that some links near the PMS will be "heavily" = used to test all paths.

"little effort" is no= t very specific. IMHO a key benefit is the ability to monitor all network p= aths by deploying a single PMS, while some others techniques requires the d= eployment of many probes.

&n= bsp;

[RG] &n= bsp;Added text to clarify properties of the solution.

&n= bsp;

---

"The PMS does not require = access to LSR/LER management interfaces "

The choice of the term "in= terfaces" seems debatble to me as it could be misread as physical inte= rface being monitored. As the goal of this document is to monitor path and = interfaces, I'd rather use "interface" only to refer to physical interface.

&n= bsp;

[RG] &n= bsp;Replaced “interfaces” by “plane information”.

---

=A74.2

Same comment: if the PMS detect= s loss of probe packets, it does not know whether the loss happens on the m= onitored bundle, or the path from the PMS to R2 or the path from R1 to the = PMS.

So how do you compute/measure t= he characteristics of the sub-path (here the bundle) that you want to monit= or?

&n= bsp;

[RG] &n= bsp;You are right, added text.

 

---

=A74.3

   "In the = previous example, a uni-directional fault on the middle link

   in direction of R2= to R1 would be localized by sending the following

   two probes with re= spective segment lists:

   o  72, 662, 9= 92, 664

   o  72, 663, 9= 92, 664"

   =

 

"The first probe would fai= l while the second would succeed."

I would have said the opposite = as 663 maps to the middle link which is assumed to be faulty.

 

The formulation of the text is = debatable as you are using the a priori knownledge of the failure in order = to define the probes which needs to be sent.

More generally, as you are send= ing packets over a path longer than the one to be tested, what you need is = to also monitor those extra sub-path in order to be able to check whether t= he failure is indeed on the sub-path that you want to test, rather than the paths from the PMS to the first nod= e on the tested path, or the path from the last node on the tested path to = the PMS.

&n= bsp;

[RG] &n= bsp;Thanks, added text and a generic statement addressing your second point= . I don’t want to describe a complete solution as part of a use case,= I hope that’s acceptable.

 

---

=A76

"Next: LDP or RSVP-TE labe= l identifying the path to LER j at LER i.

 

if LER j is the ingress of the = RSVP-TE LSP, LER j does not have a label identifying this LSP. Eventually, = SR may allocate a binding SID to this RSVP-TE LSP.

if LER j is a transit LSR of th= e RSVP-TE LSP, how does the PMS learn this labels, which a priori is only k= now from LER j and its upstream LSR.

&n= bsp;

[RG] &n= bsp;I’m not an RSVP-TE expert.  Next:… says path from LER = i to LER j (at LER i), in case of RSVP TE a tunnel would start in LER I and= terminate in j. Changed text.

If that= can’t be settled, I don’t care about RSVP-TE and I’d rat= her remove text than work on it.

---

=A77

"   MPLS SR topo= logy awareness should allow the SID to monitor liveliness=

   of most types of S= IDs (this may not be recommendable if a SID

   identifies an inte= r domain interface)"

   =

Why would it not be recommendab= le to monitor an inter domain SID/interface?

&n= bsp;

[RG] &n= bsp;I’m sure that the principle works on interfaces within an IGP dom= ain (and that what the use case offers). As with RSVP-TE, it may also work = on inter domain SIDs, however I prefer not to have to discuss that in detail, as I didn’t think it through. Hence, if s= omeone (not me) provides  text on inter domain SID/interface or RSVP-T= E. which is  acceptable to the chairs/IETF, I’= m happy to add it. If this must be a scetch of workable solution, and IR= 17;m supposed to work it out, I’m not interested. I don’t say, = any of this is impossible or a bad idea. I don’t have time to work on it.

&n= bsp;

---

      = "To match control plane information with data plane information, MPLS<= o:p>

   OAM functions as d= efined for example by RFC 4379 [RFC4379] should be

   enhanced to allow = collection of data relevant to check all relevant

   types of Segment I= Ds."

Is there a document working on = this? (e.g. draft-ietf-mpls-spring-lsp-ping ?) If so, it could be reference= d.

 

inter domain SID/interface

&n= bsp;

[RG] Do= ne.

---

=A78

"While the PMS based use c= ases explained in Section 3 "

I think uses-cases are explaine= d in section 4.

&n= bsp;

[RG] Do= ne.

---

=A76

"An implementation report = on a PMS operating in an LDP domain is given in [I-D.leipnitz-spring-pms-im= plementation-report]"

This document is more than an i= mplementation. IMHO it would deserve a short text introducing its scope and= result. e.g.

"[I-D.leipnitz-spring-pms-= implementation-report] present a PMS implementation report and compare dela= ys measured with one PMS to the results of three IPPM standard conformant M= easurement Agents, using the IPPM methodology as defined in [RFC6576].

The results show that the PMS m= easurements equal those captured by

   an IPPM conformant= measurement system.  The ADK test is successful by<= /p>

   comparing the meas= urement values of the round-trip delays for packets

   with a size of 64 = bytes."

   =

(but I'm not an IPPM expert, so= authors should be able to provide a better text) 

&n= bsp;

[RG] Th= anks for the positive feedback, done.

 

 

=3D=3D=3D=3D=3D Nits=

"IGP LSA"<= /span>

LSA is not defined nor expanded= on first use.

Plus it is protocol specific (O= SPF). Could you cover both OSPF and IS-IS or use a term which is not protoc= ol specific? Especially since a priori you mean LSDB analysis, rather than = LSA.

---

:s/minmum/minimum

---

OLD: used as a means of adding = label stacks and hence transport to standard MPLS OAM packets

NEW: used as a mean of adding l= abel stacks and hence transport standard MPLS OAM packets to any node<= /o:p>

&n= bsp;

[RG] Te= xt has been removed or changed..

&n= bsp;

 

______________________________________________________________________=
___________________________________________________
 
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, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout 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 fo=
r 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_53C29892C857584299CBF5D05346208A1ED56C59OPEXCLILM21corp_-- From nobody Mon Feb 13 02:08:36 2017 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 ED0081295A7 for ; Mon, 13 Feb 2017 02:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 ynf4cOnuCUBH for ; Mon, 13 Feb 2017 02:08:33 -0800 (PST) Received: from relais-inet.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 2E71712956B for ; Mon, 13 Feb 2017 02:08:33 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 9082DC0316 for ; Mon, 13 Feb 2017 11:08:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 74E89160070 for ; Mon, 13 Feb 2017 11:08:31 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 11:08:31 +0100 From: To: "spring@ietf.org" Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-central-epe Thread-Index: AdKF4G16AeXO0x1+TUqTRxaD/d2gag== Date: Mon, 13 Feb 2017 10:08:30 +0000 Message-ID: <4687_1486980511_58A1859F_4687_19025_2_53C29892C857584299CBF5D05346208A1ED5D0BC@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.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED5D0BCOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:08:35 -0000 --_000_53C29892C857584299CBF5D05346208A1ED5D0BCOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-central-epe-03 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *27th of February*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. Two IPR have been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-e= pe-03 [2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment= -routing-central-epe&submit=3Ddraft ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED5D0BCOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Working Group,

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-central-epe-03 = [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *27th of February*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

Two IPR have been disclosed = [2].

 

Thank you<= /p>

 

M&B

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-0= 3

[2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment-rou= ting-central-epe&submit=3Ddraft

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A1ED5D0BCOPEXCLILM21corp_-- From nobody Mon Feb 13 02:11:17 2017 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 7C0FF12956B for ; Mon, 13 Feb 2017 02:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 lbsgb2JRPC3s for ; Mon, 13 Feb 2017 02:11:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A5A1293DF for ; Mon, 13 Feb 2017 02:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2156; q=dns/txt; s=iport; t=1486980674; x=1488190274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=g2rgJNDRmmzKdvEjnHiRu3S0Bq/7P/8WK5LIsNB34cg=; b=lZxflTZBrdiORPOedFxCgFAdPoqfcCmd2NyxnCalUjr/GHLNRaK82wI3 UKAuByKTN4Kxt/1Aj9qeIvqJZ4EtyGH2cLe7JV0ZXjsbbRJK3aFxOhHKP 7fTIkHVfUEjPfLsYUAP+cjIj0rC9eJ6vvaiFOGH1bkYzNsHJECuP6VZe3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQBfhaFY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JhgQkHjVqRah+VNoIMHw2FLEoCgm0/GAECAQEBAQEBAWIdC4R?= =?us-ascii?q?pAQEBAwEBARsdNAsFCwIBCBgeECcLJQEBBA4FiWIIDrA+i0ABAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZMggUIgmKDF4EPEQEcgzSCMQWbcgGGboslgXuFF4NQhiO?= =?us-ascii?q?TFAEfOHgIURU9EQGGMXWIAIEhgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="scan'208";a="211562269" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 10:11:13 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1DABDnq007106 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 10:11:13 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 05:11:12 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 13 Feb 2017 05:11:12 -0500 From: "Stefano Previdi (sprevidi)" To: "bruno.decraene@orange.com" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Thread-Index: AdKF4G16AeXO0x1+TUqTRxaD/d2gagAKvrUA Date: Mon, 13 Feb 2017 10:11:12 +0000 Message-ID: <92E03E1E-1CF5-4665-9671-A6C7504AE59A@cisco.com> References: <4687_1486980511_58A1859F_4687_19025_2_53C29892C857584299CBF5D05346208A1ED5D0BC@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <4687_1486980511_58A1859F_4687_19025_2_53C29892C857584299CBF5D05346208A1ED5D0BC@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.72.243] Content-Type: text/plain; charset="us-ascii" Content-ID: <7407391EB8733946AF104D0ADD0AD2D5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 10:11:16 -0000 support as co-author. s. > On Feb 13, 2017, at 11:08 AM, bruno.decraene@orange.com wrote: >=20 > Hello Working Group, > =20 > This email starts a 2-week Working Group Last Call on draft-ietf-spring-s= egment-routing-central-epe-03 [1]. > =20 > Please read the document if you haven't read the most recent version yet,= and send your comments to the list, no later than the *27th of February*. > Note that this is *not only* a call for comments on the document; it is a= lso a call for support (or not) to publish this document as an Informationa= l RFC. > =20 > We have already polled for IPR knowledge on this document and all Authors= have replied. > Two IPR have been disclosed [2]. > =20 > Thank you > =20 > M&B > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central= -epe-03 > [2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segme= nt-routing-central-epe&submit=3Ddraft > =20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue Feb 14 02:34:00 2017 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 3955E12955A for ; Tue, 14 Feb 2017 02:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34QpL8OuKE_E for ; Tue, 14 Feb 2017 02:33:58 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 E163812950C for ; Tue, 14 Feb 2017 02:33:57 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id v77so2834224wmv.0 for ; Tue, 14 Feb 2017 02:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=HRM9rejIe9ocEuQiTiOkfLFW+w86TxoMHdnC56n0FwE=; b=Z1uI0Bq+zlnBia8C4LKQSQ2e6LIK3Z+NJ1kgJg3F3m50sJjwQvGcbQgbZfkliKVT+P zL3YQyY/YJvOkh8Y5Yd4+qk3K8WyQN6cx+gNoFtkyVSsL9F1jqYKm5h4yaybN7Dn42Tl NcSCxtPwN3k+hpo+mDaMlJnjI+lxsTu1152wwT6qCaSYzbso1kVzG60iP4ToHJKMcMKK 6VDckLlSFLHJd8UIEBIGHSki8UnfQG5sg6d++s+n/YfJcfqItth7Dwa7MLggXPKLCrYc LH76xpgilIM/Ofvv9nDlU2RrPXjXp07NO+1uiBRmpc97nflMox66NZqYVXFCvvDxrC6v X2jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=HRM9rejIe9ocEuQiTiOkfLFW+w86TxoMHdnC56n0FwE=; b=IugEEYyVIDBQs7ax0YHaEE2KF4FkpCxkqiuKY6nsTSZ1frPaowzZ29j2xTitjVCX+0 4RX/14ChBAHn3AtL3lq8NffuwpVwViraSiOAIZcTwIskW3oEuysaUqwbCo4Vh7dzOVUP knX4pKKsn+PT4u8Q5XDouspfYLypXdX9L+yZwIhFdn/bGbIakJSHxZsRej30AwBFLWKB G2HWDiXz0gKwHM/ILHHfrLncb9B4ZkYY+amIVBmWfp9bsxYotgtj6ZhvTszKC+Ah9Ej1 zA2fQXM2GmGc8ulIu8Iv8E497wrcJflOsuxyQLUj6QLQm7O65zrHRpNFhkzKQOn1aO3G rWNw== X-Gm-Message-State: AMke39nJtiEU8KPlWmUV3+At1lSn2LQaPTPZWR6zVG2E3XS7fswdMtKVD2Aviv46fUfwEQ== X-Received: by 10.28.228.213 with SMTP id b204mr2610948wmh.59.1487068436431; Tue, 14 Feb 2017 02:33:56 -0800 (PST) Received: from [10.228.10.41] ([94.119.64.52]) by smtp.gmail.com with ESMTPSA id y30sm208312wrc.23.2017.02.14.02.33.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 02:33:55 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Tue, 14 Feb 2017 02:33:48 -0800 From: Jeff Tantsura To: , "spring@ietf.org" Message-ID: Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3569884432_785763970" Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 10:34:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3569884432_785763970 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit yes/support Cheers, Jeff From: spring on behalf of Date: Monday, February 13, 2017 at 02:08 To: "spring@ietf.org" Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-segment-routing-central-epe-03 [1]. Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than the *27th of February*. Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as an Informational RFC. We have already polled for IPR knowledge on this document and all Authors have replied. Two IPR have been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-03 [2] https://datatracker.ietf.org/ipr/search/?id=draft-ietf-spring-segment-routing-central-epe&submit=draft _________________________________________________________________________________________________________________________ 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --B_3569884432_785763970 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

yes/support

 

 

Cheers,

Jeff

=

 

 =

From: spring <spring-bounces@ietf.org> on beh= alf of <bruno.decraene@orange.com>
Date: Monday, February 13= , 2017 at 02:08
To: "spring@ietf.org" <spring@ietf.or= g>
Subject: [spring] WG Last Call for draft-ietf-spring-segment= -routing-central-epe<= /o:p>

 

Hello = Working Group,

 

This email starts a 2-week Working Group Last Call on draf= t-ietf-spring-segment-routing-central-epe-03 [1].

 

Please read the documen= t if you haven't read the most recent version yet, and send your comments to= the list, no later than the *27th of February*.

Note that this is *not only* a call for comments on the document; i= t is also a call for support (or not) to publish this document as an Informa= tional RFC.

 

We have already polled for IPR knowledge on this document and= all Authors have replied.

Two IPR have = been disclosed [2].

 

Thank you

 <= o:p>

M&B

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routin= g-central-epe-03

[2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-iet= f-spring-segment-routing-central-epe&submit=3Ddraft

 

___________________________________=
____________________________________________________________________________=
__________
 
Ce message et se=
s pieces jointes peuvent contenir des informations confidentielles ou privil=
egiees et ne doivent donc
pas etre diffuses, exploites =
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,
Orange decline toute responsabilite si ce message a=
 ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or p=
rivileged information that may be protected by law;
the=
y should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the send=
er and delete this message and its attachments.
As emai=
ls may be altered, Orange is not liable for messages that have been modified=
, changed or falsified.
Thank you.

= _______________________________________________ spring mailing list spring@i= etf.org https://www.ietf.org/mailman/listinfo/spring

<= /div> --B_3569884432_785763970-- From nobody Tue Feb 14 08:57:14 2017 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 E66351296D5 for ; Tue, 14 Feb 2017 08:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 cZZ0waub2vhE for ; Tue, 14 Feb 2017 08:57:02 -0800 (PST) Received: from relais-inet.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 34A241293F8 for ; Tue, 14 Feb 2017 08:56:55 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 144D9100615; Tue, 14 Feb 2017 17:56:54 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id EB9F8C0073; Tue, 14 Feb 2017 17:56:53 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Tue, 14 Feb 2017 17:56:53 +0100 From: To: "draft-ietf-spring-segment-routing-central-epe@tools.ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Thread-Index: AdKF4G16AeXO0x1+TUqTRxaD/d2gagBAgt3g Date: Tue, 14 Feb 2017 16:56:53 +0000 Message-ID: <11889_1487091414_58A336D6_11889_9328_1_53C29892C857584299CBF5D05346208A1ED60F87@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <4687_1486980511_58A1859F_4687_19025_2_53C29892C857584299CBF5D05346208A1ED5D0BC@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <4687_1486980511_58A1859F_4687_19025_2_53C29892C857584299CBF5D05346208A1ED5D0BC@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.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED60F87OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:57:13 -0000 --_000_53C29892C857584299CBF5D05346208A1ED60F87OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Authors, As the document shepherd, please find below a set of comments. Thank you, Regards, Bruno =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Major comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name and descriptors' content are not aligned between draft-ietf-spring-seg= ment-routing-central-epe and draft-ietf-idr-bgpls-segment-routing-epe. Chan= ge seems to come from draft-previdi-idr-bgpls-segment-routing-epe-01.txt Oc= tober 25, 2014. e.g. BGP Egress Peer Engineering or BGP Peer Engineering; PeerNode SID vs P= eer-Node-SID; Node Descriptors vs Local Node Descriptors; Peer Descriptors = vs Remote Node Descriptors; Remote Node Descriptors containing a Router ID = vs not ... Note that this is also not aligned with draft-ietf-spring-segment-routing-1= 0. ---- Security section is empty. ---- Manageability section is empty. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minor Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Terminology: This document uses the term BGP-PE for "Peer Engineering" while the BGP doc= ument (draft-ietf-idr-bgpls-segment-routing-epe-07) use the terme BGP-EPE "= Egress Peer Engineering". A consistent name would be useful. Note also that= PE is already a very popular term for BGP VPNs and stands for Provider Edg= e. Given that both functions may be used on the same network/node, using a = different TLA would seem more user friendly. Note that even this doc use th= e term PE to sometimes refers to "Peer Engineering" and sometimes for "Prov= ider Edge" (e.g. =A71.2). This is confusing. Note that RFC 7855 and draft-ietf-spring-segment-routing-10 use the term "e= gress peer engineering" and "Egress Peer Engineering (EPE)" ---- Proposed: OLD: For editorial reasons, the solution is described for IPv4. A later se= ction describes how the same solution is applicable to IPv6. NEW: For editorial reasons, the solution is described for IPv4 and MPLS SID= . This solution is equally applicable to IPv6 with either MPLS-SR or IPv6 S= R. Given this, section 6 seems useless. --- Abstract "This document is on the informational track." This sentence is probably not required as this is already indicated in the = "Intended Status" of this same page. --- "The solution MUST be applicable to iBGP as well as eBGP peerings." I'm not sure to understand what is meant by "iBGP peering", and how does th= is solution apply to this case. --- OLD: A PeerSet segment to the set of peers (E and F). NEW: A PeerSet segment to the set of peers (E and F) belonging to the same = AS. --- Names of sections 3.1 to 3.5 are very long and not easy to quickly parse. M= ay be they could be shorten. e.g. OLD: BGP-PE Router advertising the Peer D and its PeerNode SID NEW: Peer-Node-SID to D --- In sections 3.x, in order to avoid being to IPv4 specific, may be OLD: IPv4 interface address NEW: IPv4/IPv6 interface address or may be NEW: IP interface address --- Somewhere in the doc (e.g. section 1), may be saying that the solution only= allow TE for outbound traffic, not inbound traffic. This is probably obvio= us for the authors, but may not be to some readers. --- The solution allows advertising a single set of Descriptors with both Peer-= Node-SID and Peer-Set-SID at the same time. (Which is good IMHO). But for P= eer-Adj-SID, it seems to require to advertise another set of Descriptors de= dicated to the Peer-Adj-SID. Why? And it's not clear to me whether this wou= ld be allowed to advertise the 3 types of EPE SIDs (Peer-Node-SID, Peer-Set= -SID and Peer-Adj-SID) at the same time (with a unique set of Descriptors) --- Section 2 would seem a good place to define what is a PeerNode Segment, Pee= rAdj Segment, PeerSet Segment. --- 3.6. Fast Reroute (FRR) "An BGP-PE enabled border router should allocate a FRR backup entry on a pe= r BGP Peering SID basis:" What do you mean by "should"? Is this "SHOULD"? "If multi-hop, backup via the remaining PeerADJ SIDs to the same peer." This is mandating FRR Link protection. What if people want node protection? "1. If multi-hop, backup via the remaining PeerADJ SIDs to the same peer." Do you mean _local_ PeerADJ SID? or may be :s/same peer/same Peer-Node-SID = (as in "2.", it seem restricted to local SID) "2. Else backup via local PeerNode SID to the same AS." Don't you mean backup via the local remaining PeerSet? (Otherwise, what's t= he purpose of PeerSet?) "3. Else pop the PeerNode SID and perform an IP lookup." This node is known to support BGP-EPE. It could possibly learn EPE SID from= other nodes. Why forbidding the use of an EPE SID advertised by another EP= E node? --- =A74.1 "The BGP-PE controller should collect all the paths advertised by all the e= ngineered peers." A reader could understand "paths" as EPE paths, while I think you are refer= ing to IP unicast external routes. BTW, this document never states it's applicability with regards to BGP AFI/= SAFI. A priori, it looks to me that this document is only application to IP= unicast route, i.e. AFI/SAFI 1/1 and 2/1. An possibly to IP labelled route= s assuming the labels are those from the external peer. (AFI/SAFI 1/4 and 2= /4) Could this be indicated somewhere in section 1? --- "Alternatively, Extended Metrics, as defined in [I-D.ietf-isis-te-metric-ex= tensions] could also be advertised using new BGP-LS attributes." What do you mean by "new"? "To be defined"? or "defined in draft-ietf-idr-t= e-pm-bgp"? or else? --- Terminology is not consistent. e.g. "BGP Peering Segments" vs "BGP Peer Seg= ments" Which is the right term? --- "A static IP/MPLS route can be programmed at the host H. The static route would define a destination prefix, a next-hop and a label stack to push. The global property of the IGP Prefix SID is particularly convenient: the same policy could be programmed across hosts connected to different routers." Labels (value) are local, not global, so the last sentence is debatable. Same comment for =A77: " o Ability to deploy the same input policy across hosts connected to di= fferent routers (avail the global property of IGP prefix SIDs)." --- "This RFC3107 policy route "overwrites" an equivalent or less-specific "best path". As the best-path is changed, this EPE input policy option influences the path propagated to the upstream peer/customers." Regarding the last sentence, unfortunately the exact behavior is implementa= tion specific. cf https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-00= #section-5 May be OLD: As the best-path is changed, this EPE input policy option influences t= he path propagated to the upstream peer/customers. NEW: As the best-path is changed, this EPE input policy option may influenc= e the path propagated to the upstream peer/customers. Indeed, implementatio= ns treating the SAFI-1 and SAFI-4 routes for a given prefix as comparable w= ould trigger a BGP WITHDRAW of the SAFI-1 route to them BGP upstream peers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nits: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OLD: set of peers (198.51.100.6 and 192.0.2.2) NEW: set of peers (198.51.100.6 for E and 192.0.2.2 for F) (Motivation: to ease the understanding as most people would not remember al= l IP addresses and they are also not indicated in the figure 1.) --- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Monday, February 13, 2017 11:08 AM To: spring@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-centra= l-epe Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-central-epe-03 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *27th of February*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. Two IPR have been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-e= pe-03 [2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment= -routing-central-epe&submit=3Ddraft ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED60F87OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Authors,=

 

As the = document shepherd, please find below a set of comments.

&n= bsp;

Thank y= ou,

Regards= ,

Bruno

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Major c= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Name an= d descriptors' content are not aligned between draft-ietf-spring-segment-ro= uting-central-epe and draft-ietf-idr-bgpls-segment-routing-epe. Change seem= s to come from draft-previdi-idr-bgpls-segment-routing-epe-01.txt October 25, 2014.

e.g. BG= P Egress Peer Engineering or BGP Peer Engineering; PeerNode SID vs Peer-Nod= e-SID; Node Descriptors vs Local Node Descriptors; Peer Descriptors vs Remo= te Node Descriptors; Remote Node Descriptors containing a Router ID vs not ...

Note th= at this is also not aligned with draft-ietf-spring-segment-routing-10.=

&n= bsp;

----

Securit= y section is empty.

&n= bsp;

----

Managea= bility section is empty.

&n= bsp;

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Minor C= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

Termino= logy:

This do= cument uses the term BGP-PE for "Peer Engineering" while the BGP = document (draft-ietf-idr-bgpls-segment-routing-epe-07) use the terme BGP-EP= E "Egress Peer Engineering". A consistent name would be useful. Note also that PE is already a very popular term for BGP VPNs a= nd stands for Provider Edge. Given that both functions may be used on the s= ame network/node, using a different TLA would seem more user friendly. Note= that even this doc use the term PE to sometimes refers to "Peer Engineering" and sometimes for &= quot;Provider Edge" (e.g. =A71.2). This is confusing.

Note th= at RFC 7855 and draft-ietf-spring-segment-routing-10 use the term "egr= ess peer engineering" and "Egress Peer Engineering (EPE)"

&n= bsp;

----

Propose= d:

OLD: Fo= r editorial reasons, the solution is described for IPv4.  A later sect= ion describes how the same solution is applicable to IPv6.

NEW: Fo= r editorial reasons, the solution is described for IPv4 and MPLS SID. This = solution is equally applicable to IPv6 with either MPLS-SR or IPv6 SR.=

&n= bsp;

Given t= his, section 6 seems useless.

&n= bsp;

---

Abstrac= t

"T= his document is on the informational track."

This se= ntence is probably not required as this is already indicated in the "I= ntended Status" of this same page.

&n= bsp;

---

"T= he solution MUST be applicable to iBGP as well as eBGP peerings."=

I'm not= sure to understand what is meant by "iBGP peering", and how does= this solution apply to this case.

&n= bsp;

---

OLD: A = PeerSet segment to the set of peers (E and F).

NEW: A = PeerSet segment to the set of peers (E and F) belonging to the same AS.

&n= bsp;

---

Names o= f sections 3.1 to 3.5 are very long and not easy to quickly parse. May be t= hey could be shorten. e.g.

OLD: BG= P-PE Router advertising the Peer D and its PeerNode SID

NEW: Pe= er-Node-SID to D

&n= bsp;

---

In sect= ions 3.x, in order to avoid being to IPv4 specific, may be

OLD: IP= v4 interface address

NEW: IP= v4/IPv6 interface address

or may = be NEW: IP interface address

&n= bsp;

---

Somewhe= re in the doc (e.g. section 1), may be saying that the solution only allow = TE for outbound traffic, not inbound traffic. This is probably obvious for = the authors, but may not be to some readers.

&n= bsp;

---

The sol= ution allows advertising a single set of Descriptors with both Peer-Node-SI= D and Peer-Set-SID at the same time. (Which is good IMHO). But for Peer-Adj= -SID, it seems to require to advertise another set of Descriptors dedicated to the Peer-Adj-SID. Why? And it's no= t clear to me whether this would be allowed to advertise the 3 types of EPE= SIDs (Peer-Node-SID, Peer-Set-SID and Peer-Adj-SID) at the same time (with= a unique set of Descriptors)

&n= bsp;

---

Section= 2 would seem a good place to define what is a PeerNode Segment, PeerAdj Se= gment, PeerSet Segment.

&n= bsp;

---

3.6.&nb= sp; Fast Reroute (FRR)

&n= bsp;

"A= n BGP-PE enabled border router should allocate a FRR backup entry on a per = BGP Peering SID basis:"

What do= you mean by "should"? Is this "SHOULD"?

&n= bsp;

"I= f multi-hop, backup via the remaining PeerADJ SIDs to the same peer."<= o:p>

This is= mandating FRR Link protection. What if people want node protection?

&n= bsp;

"1= .  If multi-hop, backup via the remaining PeerADJ SIDs to the same pee= r."

Do you = mean _local_ PeerADJ SID? or may be :s/same peer/same Peer-Node-SID (as in = "2.", it seem restricted to local SID)

&n= bsp;

"2= .  Else backup via local PeerNode SID to the same AS."=

Don't y= ou mean backup via the local remaining PeerSet? (Otherwise, what's the purp= ose of PeerSet?)

&n= bsp;

"3= .  Else pop the PeerNode SID and perform an IP lookup."

This no= de is known to support BGP-EPE. It could possibly learn EPE SID from other = nodes. Why forbidding the use of an EPE SID advertised by another EPE node?=

&n= bsp;

---

=A74.1<= o:p>

"T= he BGP-PE controller should collect all the paths advertised by all the eng= ineered peers."

A reade= r could understand "paths" as EPE paths, while I think you are re= fering to IP unicast external routes.

BTW, th= is document never states it's applicability with regards to BGP AFI/SAFI. A= priori, it looks to me that this document is only application to IP unicas= t route, i.e. AFI/SAFI 1/1 and 2/1. An possibly to IP labelled routes assuming the labels are those from the exte= rnal peer. (AFI/SAFI 1/4 and 2/4) Could this be indicated somewhere in sect= ion 1?

&n= bsp;

---

"A= lternatively, Extended Metrics, as defined in [I-D.ietf-isis-te-metric-exte= nsions] could also be advertised using new BGP-LS attributes."

What do= you mean by "new"? "To be defined"? or "defined i= n draft-ietf-idr-te-pm-bgp"? or else?

&n= bsp;

---

Termino= logy is not consistent. e.g. "BGP Peering Segments" vs "BGP = Peer Segments" Which is the right term?

&n= bsp;

---

 &= nbsp; "A static IP/MPLS route can be programmed at the host H.  T= he static

 &= nbsp; route would define a destination prefix, a next-hop and a label stack=

 &= nbsp; to push.  The global property of the IGP Prefix SID is particula= rly

 &= nbsp; convenient: the same policy could be programmed across hosts

 &= nbsp; connected to different routers."

 &= nbsp;

Labels = (value) are local, not global, so the last sentence is debatable. &nbs= p;

&n= bsp;

&n= bsp;

Same co= mment for =A77:

"&= nbsp;  o  Ability to deploy the same input policy across hosts co= nnected to different routers (avail the global property of IGP prefix SIDs)= ."

&n= bsp;

---

 &= nbsp; "This RFC3107 policy route "overwrites" an equivalent = or less-specific

 &= nbsp; "best path".  As the best-path is changed, this EPE in= put policy

 &= nbsp; option influences the path propagated to the upstream peer/customers.= "

 &= nbsp;

Regardi= ng the last sentence, unfortunately the exact behavior is implementation sp= ecific. cf https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-00#sectio= n-5

May be<= o:p>

OLD: As= the best-path is changed, this EPE input policy option influences the path= propagated to the upstream peer/customers.

NEW: As= the best-path is changed, this EPE input policy option may influence the p= ath propagated to the upstream peer/customers. Indeed, implementations trea= ting the SAFI-1 and SAFI-4 routes for a given prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 ro= ute to them BGP upstream peers.

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nits:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

&n= bsp;

OLD: se= t of peers (198.51.100.6 and 192.0.2.2)

NEW: se= t of peers (198.51.100.6 for E and 192.0.2.2 for F)

&n= bsp;

(Motiva= tion: to ease the understanding as most people would not remember all IP ad= dresses and they are also not indicated in the figure 1.)=

&n= bsp;

---

&n= bsp;

&n= bsp;

From:<= /b> spring [mailto:spring-bounces@ietf.= org] On Behalf Of bruno.decraene@orange.com
Sent: Monday, February 13, 2017 11:08 AM
To: spring@ietf.org
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing= -central-epe

 

Hello Working Group,

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-central-epe-03 = [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *27th of February*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

Two IPR have been disclosed = [2].

 

Thank you<= /p>

 

M&B

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-0= 3

[2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment-rou= ting-central-epe&submit=3Ddraft

 

______________________________________________________________________=
___________________________________________________
 
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_53C29892C857584299CBF5D05346208A1ED60F87OPEXCLILM21corp_-- From nobody Tue Feb 14 09:19:06 2017 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 BB67112941A for ; Tue, 14 Feb 2017 09:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 3JkKU1X2NZRc for ; Tue, 14 Feb 2017 09:19:00 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40109.outbound.protection.outlook.com [40.107.4.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612B71296CF for ; Tue, 14 Feb 2017 09:19:00 -0800 (PST) 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; bh=FLeYeaJFLd/grrPyU2qdwdlp3Yp7i+7EUqcev6H5vas=; b=eKXK3xffSGtZEDrSLRXUgq9U7VI61UWJMJTji5LBumTrjEKWahhompmp1xtBWuwoFUF+SnSY2+Hbqk8NDdZKYWQhTWDLnH+VM0zxzUdhDQ8lNKvWqMb6ak1Uf/Lwr5tASIhIqrQa/6gT42ZuoeDWzjgbiUyjFeCAOCMw/2XpLeg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [192.168.0.17] (88.182.48.47) by AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 14 Feb 2017 17:18:57 +0000 To: References: <148647545948.16284.8360784393021155625.idtracker@ietfa.amsl.com> <879DE4A5-E494-41A0-A6C4-335CA1A622FB@cisco.com> From: Martin Vigoureux Message-ID: <5615a7ea-0c5f-c4bc-423f-40db7428c32e@nokia.com> Date: Tue, 14 Feb 2017 18:18:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <879DE4A5-E494-41A0-A6C4-335CA1A622FB@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [88.182.48.47] X-ClientProxiedBy: HE1PR0901CA0033.eurprd09.prod.outlook.com (10.167.244.43) To AM5PR0701MB2465.eurprd07.prod.outlook.com (10.169.153.22) X-MS-Office365-Filtering-Correlation-Id: f410e349-805e-44c9-82cd-08d454fd8fd3 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM5PR0701MB2465; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 3:taiyMOM8r4ip00DORhHIFXzh4tA3D9bALhasB9NPqfeFPyyHOJYCxBKQZ/LzZ0SLCP2ZWAvdUhbqxZnVWsN9BJfdybcAhzXUg9g9+BVgEeF+8O/kMdVJSw6azSZaRrif2WOsGRkHF5yxTIjyTHrR6Ts6oYv1oVWmPvW09nRoY+yQNb3BEL09uvJ6Q1Dr4mRQgiZo2lEouIS8+CYmKGWGER2a3WaDCCV6PrgLNBUHPJBDCZpl4/MS6fkx2SgF0MNJxZwqa36TnCOEgksso8uouqTp6cM71ntR1r8GZavzxSo=; 25:9AWImZ1VanEN21lIrfCvYOFLc4JBOBPvUEbQ3lgNqU1G6+2G3bLac7z9lO7fDUCZEzc+ANnltTFBiY/YQeetGdBa/AKjMwOomJ/pn5M7jvJ6BXhx4zJcFxepEHPbL7BHyoNMP1oe2TBdPcnNQiEhl0Bufy6cNE0tw69kzKn0NxKv1UzISqQy9A59ISnMCIBoLsQCtzZTF2xT6WLVSc3iOD5gHTQlRFjosFlLrKphbDarLESMCZfjFu1gQ634GADDD/LDvo6P10tA2dvI1Pg/2yK4eZbW4J7wHBMHbAth8Lnnq9erLzdQgxsXow3mzsubL2+Hn2ANrYWVAZ9zDHz1zQnxHevBNFbvs/xJHwulBhlLOw9aVYYd1trMGdOtlExoVuEM28+pPhHGdWpsmxmWEuZXPjNEeIh0Hxku/My1p4O6sNQj9d/P9Sa4MC+yNZIF9v9akbTGQNjW0+5V5Mci3g== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 31:zkmZa/EYkNKDunFj0DlUU3iJAmSunRH4Df+/lLU5xY9WXTjGhK9kGChSN1gEyXNQe4VfRd97JhkFdtmRRojIRwEbkYq6HzdeXoYTtDOIdKY0KtooaWwS8i9FgoCa5hEOrnKakkkOL8bx1Iiy8jUKJNLATqbcV039uDqDDfKVGrNB4At9rhZmm3qpZLd8i29YCj7T0c+D/MejLzwk86fMYTKw7tb0HLNcrMJzsFbLfOU0VLKx071TdY60mZgrHCAZxYyZpUgbIUQ6aBhs5B2AUOMnSjpDK4LBavjbtTsvK+I=; 20:FEcyRu3VGvaJvWEUjX67fFHMO2jFh41Mfm7aiPOha753gQ3keGTbRfwgZ20Fd74dncO4BaXDisryOQgsR0xS65zbqz7iHPhFJNf3cWwSGU8rgZnLDoc4hdK0g0EvvUIVZ9D7lOqB6VsdRwfQ7OKlk4eUEYC3wGBmAykI/5babpEFWRRSRToJ/z4Y53Oc9UUa6S+nmsSjUdoAmWXmEWeBRouljF0NkfZKFozpaQCRxQ3UzqqPTPuwtpVDOBCj4mQAn6+0oeuZeqXG58yeQjIxVW9yymLPnpQpg535vmu5LQCgwN3JMDq9V0CJkN6Lo5opG4D6YcZQcoL8OeLIkBOb7QrZhBu+0ivJM50WLmVI4Ra8Z4GIKy5tvtpNhG2EYmq8qLavfD8VhVyoZAOdzisdTZy/N65vTUX2uuHyFuZMqp2QeGx342Wsh/qIABNIvPchR+5M9QzL23M1SoiBFfRGtqt38SjeLI7Fw2/CBOOfUDFiu2cPaMLPcp3X0hyUGs1F X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:AM5PR0701MB2465; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2465; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 4:ZxjykLVtDhYXes8Cd6QdQjNHg9zzUp9aO5r9nJappK/2ZoUX+yMJ40BI1uz72xJMkAIWt8Mm43YFJFOqTNTFuhzkEToAOM64IpDcOOmf0avVHcTiB19/g+dBUBh4g0KKYaNssy2QJNIUfEFblqq1F+dZx/1bLCkoYq+e7ptdCfUJ3HDLP9Xjcy1PLaSVTtVuNtXD2113sv22ONy6IAB6w+cz1NYtICy8yrTi9MMKillh3vQflMLzagN0vxZl/1hnFmB8Mt5NvmMxhL/BnLJzXV/RkJd4Ehz8kn57lPOBESLyovmyGmaGEDH4F0y+G2hIkOG3DDUf54frKgqnMoUk2I5GOc8P12Gt0ceAljbtShfRTuNRlJdloXpbs/VXIPRAZ8O8ukvyHm6106Cvqv9blsCGAc3pf956Eb96p18z5q4RVlaxFtP72E7pWTla8KQLy/rc3CydX6rBLuOGmrZnnGxZ/APTiCfnPqtRRTpXJkt9Y1H6dxvakzgARTgT9EFB2eDxvn9bqT6M0M08dJUZMbPsBq1lEMdhpVUmTcJtKI2CNQMhmUX3T9khtQLyij51RZiv5rqFq3QR9VTrMwAp1xxCuuZQeWYtFyw7ZZkFeerbGeShdjuc0DK6Qi8y4TlWxxy4qKVX9ybdFmH15NSBd501WHBVxmCtcOumPTTE/r4= X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39840400002)(39450400003)(39850400002)(39860400002)(39410400002)(199003)(377424004)(377454003)(189002)(24454002)(54356999)(6116002)(3846002)(50986999)(189998001)(450100001)(33646002)(31696002)(229853002)(4001350100001)(76176999)(8676002)(81156014)(92566002)(97736004)(65826007)(53936002)(2906002)(2870700001)(86362001)(7736002)(110136004)(38730400002)(6246003)(305945005)(2351001)(6306002)(50466002)(83506001)(81166006)(106356001)(6666003)(2950100002)(6916009)(36756003)(81003)(23746002)(105586002)(230783001)(68736007)(117156001)(6486002)(90366009)(77096006)(64126003)(5660300001)(101416001)(66066001)(65806001)(65956001)(31686004)(25786008)(42186005)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2465; H:[192.168.0.17]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM5PR0701MB2465; 23:zcC0AtJjpt2j1JEH1qrD4C1OtOGInJSh3bK?= =?Windows-1252?Q?sqXfLxUClJMRcRRax7h5rv2skJSri58OxR73a8l7yq1605EX3uF9eIs9?= =?Windows-1252?Q?HCJFFhiuXaJVauBi4CJadDE3EQRh408b6UM3TwkNONHyVprPaU4OMaM6?= =?Windows-1252?Q?Zg5OrTNKq1+wr3l0XXAnIcp3ADN4qU3id8fOB4dICYEVbsSSE9dqJuZI?= =?Windows-1252?Q?qtPJ/qzNF0+i3ai3amS/E7M49YaAGMwdDaTNJ78FvJQMWJFxC2nJHmQT?= =?Windows-1252?Q?LcNIVD/SMF3jMT8W67PD0/fXajU6kWwI+ugwDDKZ1krIB2UGccVcNr/t?= =?Windows-1252?Q?zkkTXApo7tuqMNYx3zb275FsLTYJiQfmD5s8MafP4dkrqKY9P0KPEDYW?= =?Windows-1252?Q?ePMb3CMLqwcaXCzSBxoNAIk+QTw/yZVPWo/H+EZ7ogPFQ7pFzLqtt6nz?= =?Windows-1252?Q?A75Q3fHR9UUC9ONLITBIWxNx+829Erst/hcd4TkZJ1el707vRVNxLatJ?= =?Windows-1252?Q?cWlSfP75MGLUfNlSvXjiYY7xbTp+7vUlNmPblXe1Lr8o9QerTWDBWO+J?= =?Windows-1252?Q?lo67Ug/XJJBBZdZhRBStmJHrp8niGFcEs/41miLSJ3lqEXi7zb0QRQ8a?= =?Windows-1252?Q?JXVpM9W7K5IAzf3JpvUalako9jENBGPTG2dMw1NdGpzYJTOYRMZ7+Odn?= =?Windows-1252?Q?5Zb8xUrPmdOMmbbXLG0b7RFEfCGKak5DKfOIcEPtVCz5sUuVRCshP/56?= =?Windows-1252?Q?ZmXXuKtARvJ6n+1d/bN7lvC7pVqRQyXnpR9B+QlzNSURxf5/8H5YG8ZV?= =?Windows-1252?Q?OLjox+P99iEVISnsW/C6xKgmwlF7nSt85NyfrN2QxF1MRXvblK3ZLZBI?= =?Windows-1252?Q?E2ZFY8Yo7aYlS1lO2VgG+rYYW09fE1k6MqVuWZbaveAxtZQbKJ71gZOp?= =?Windows-1252?Q?FlHXqX+aH/yq4hkXNxTs29q/1WXhc044/CV4kmg0F2TcDZ3JoeC0BkAN?= =?Windows-1252?Q?vqayYLmEQZ18/NNPlWH76eCPTPSLOAP9ePI5UlPjKVGGI8LClsJ/hJmM?= =?Windows-1252?Q?yJDqlpl0PQGGqNfJcVLgiBS2Y8If/TSCE29Rx/uSf2t0XaEK0GUdMRki?= =?Windows-1252?Q?sT+lXBudrDNS0SowZmRJ1ameSIpynj265Wu2QB0m0bdRfiyWB71q3TfW?= =?Windows-1252?Q?wZX5Wynj8KKG8Cn2c53KPq4nLTPY00rHNeYHUkgxyfKwjYXYbBLe3E/M?= =?Windows-1252?Q?PqppOQk+BnjFRu7YQpLMjsO7OCpOO+3i/4HaHtQ3Iev0I5wfILozyVdS?= =?Windows-1252?Q?V4RjR0VYHBl7+Kc/pFquEh7DPO+u57CcLlwAZo98XAX5hIkKToQrWHOw?= =?Windows-1252?Q?Ac8WWPIPlaPBIUfEwvdyCdg7nZ0DWGsDORxZpayzBM/ylmIHk5BeoetD?= =?Windows-1252?Q?Zvg987n0B3j8OVizjMKeJQrQalqQjjwW4v1t+EGGLCFTyJFoVNmp2nNx?= =?Windows-1252?Q?9vXE9NMfiWrWbtmpFbi251cCw9bEKdbYG5sJjBOahdjWI7Mt6ZBABtLr?= =?Windows-1252?Q?tx772/5T9rpw5076iLFimKl+1L6jYK860ZyAWj9rFRN2k52wqfVSaCeb?= =?Windows-1252?Q?WevPnizv5WQ/TIkCNoaXvsWbn+ADJfEPjSqbqhpMHzmZCgkWb45BFSvz?= =?Windows-1252?Q?+donLMHlclGZUpv/mnpkt7o+ljcpmZD7AKaK0LCH1DcTqi09YYcKQ9Mk?= =?Windows-1252?Q?B1nMd6bYeAGaOSkyseg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 6:qp+c86tLdKs7yUUdN9pTQ2Juao5tVa3LU2HpzmChwjHScEipoy8bd0Y7hlZaJQoNHrfsNA90IpkmbfU07qYoSu/r/x42qhtzwh+33992L8y3F/D1luXhgc9AxFQKyLbvMpXotAdE18Df6Lvy85tpv3pNc2W9RDEbl+mNunJWSqbQDXUPhlpxOfIMV8f0+ljdiOsKcGhvGUXkt2LOMWqUBVvueRq/Em7MKLZA2SKzeGaKcYkHY/ja/29dKGGAWh6A3w5z28RnAgARB+iSJbmccE4v4RNqto+H1IpGJW3boR/CkVhPBXOpzI4CInczOfeH3erSPmgkejjizu0cfUKq2wLXWO57q1hVcNXenmCxKWLSuEgiVUl3Mwq1L/Mn2+RI11SdoEnFeHsRu5CaO1DsBeFcMNRTwjFdWgCCgaVWaiU=; 5:U/Vo5xhhGEu2AxjEwSmUp/5el3hMrFcFivTLrgz88D9+hTKnFEERRKzFlY/WP+Ma68KbQ6udJ+tJboSpxtKhkSji1ncq30/RNmA12nDZw0fgdPqmm+f/wxDqd7DeWhq0fC8xdfysEPQFs0Hrg3DRnQ==; 24:UmJ0kuU0WQJmY0mdVk4BkILRRYfW/vbvOJBPMfvQ0Z+Qjugb8FLgfDjF6whK4LgbGpK1wNCnslykbp5DUINa55FyXOjZ9nSexr5l6D/svUY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2465; 7:7y5IqDc31FMMh0WYpq3N1F/o3Y1RIxgH9ASKoODqS5203JL9deckRwVY0tGJUFG+MqXDqDbOdywtAxtfSL5KdzO0y9qCr8RLwzPrJl3+PD3OI09yFDXWzy6O8lbnWjOCUf3L+b0I14sOANRrVf9k92QatTuhCLYB0kp0XmzlJDkWJJsdpm2CmkilA9p+uU044OY5drH52bFBvySpojJeuwmzlOyu+L3OvL6w/gzy5yAYqZhVTLft7kDMrMyDNHV9clhtvHW2qi6ARiW2AQ6j7e3ZI9pPGrA10u640JegP0uS2pFwHcdUwO8CY67VOTZCCjxFrA0UimdbQBxd6UylEg0TTStN3m0E/zAbIAu2l49ev899X7J1nyVaBnE0CpO9V33ob9wViuDh8ysab8c1+nwFbrfGNTSXtbkRV5OXezUJ9xnGsQOpuudNcpkCUPGzJ0Jo133UqbbOOS1pzLlCB8boWMSA8C3xFi9nXCu4q+VlIQraAw2mOdfr/9rlF4iCRdaiQy63cJRgYkvzPMsavQ== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2017 17:18:57.8952 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2465 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-mpls-07.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 17:19:05 -0000 Reviewers, Authors, thank you. We will now proceed towards requesting publication to IESG. -m Le 07/02/2017 à 14:52, Stefano Previdi (sprevidi) a écrit : > this is the updated version after all received comments. > > Thanks. > s. > > >> On Feb 7, 2017, at 2:50 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Source Packet Routing in Networking of the IETF. >> >> Title : Segment Routing with MPLS data plane >> Authors : Clarence Filsfils >> Stefano Previdi >> Ahmed Bashandy >> Bruno Decraene >> Stephane Litkowski >> Martin Horneffer >> Rob Shakir >> Jeff Tantsura >> Edward Crabbe >> Filename : draft-ietf-spring-segment-routing-mpls-07.txt >> Pages : 16 >> Date : 2017-02-07 >> >> Abstract: >> Segment Routing (SR) leverages the source routing paradigm. A node >> steers a packet through a controlled set of instructions, called >> segments, by prepending the packet with an SR header. In the MPLS >> dataplane, the SR header is instantiated through a label stack. A >> segment can represent any instruction, topological or service-based. >> Additional segments can be defined in the future. SR allows to >> enforce a flow through any topological path and/or service chain >> while maintaining per-flow state only at the ingress node to the SR >> domain. >> >> Segment Routing can be directly applied to the MPLS architecture with >> no change in the forwarding plane. This drafts describes how Segment >> Routing operates on top of the MPLS data plane. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-mpls-07 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Wed Feb 15 15:39:41 2017 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 8BBAD129BDB; Wed, 15 Feb 2017 15:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 gvyAMHC0erL4; Wed, 15 Feb 2017 15:39:38 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4CE17129BCF; Wed, 15 Feb 2017 15:39:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.124.244.62; From: "Susan Hares" To: Date: Wed, 15 Feb 2017 18:34:44 -0500 Message-ID: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01D287BA.2E176E40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , spring@ietf.org Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:39:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FA_01D287BA.2E176E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) There are two implementations describe on the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe %20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The authors will indicate on the list and in the wiki the following information : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-e pe/ Sue Hares ------=_NextPart_000_00FA_01D287BA.2E176E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) =    There are two implementations describe on the wiki at: =

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-= segment-routing-epe%20

 

The two = implementation are from  Cisco IOS-XR release 6.0.2 and Cisco = Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or = greater.   The authors will indicate on the list and in the = wiki the following information :

 =

1)      = Were = these implementations separate implementations?

2)      = What = were the results of the interoperability tests?

 

This work is linked = to the draft-ietf-spring-segment-routing-central-epe work in the SPRING = WG. Based on the two drafts, the WG should might consider: =  

1)      = Is there = need for this work in deployments in networks/

2)      = Is this = technically ready for publication?

3)      = Does it = fit with the spring informational draft?

 

For the ease of = reference the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-= routing-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing-central-epe/

 

Sue Hares =

------=_NextPart_000_00FA_01D287BA.2E176E40-- From nobody Thu Feb 16 03:07:01 2017 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 BA0771294E6; Thu, 16 Feb 2017 03:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJzNcKei7-3e; Thu, 16 Feb 2017 03:06:58 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 442D9128B38; Thu, 16 Feb 2017 03:06:58 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id e137so3392645itc.0; Thu, 16 Feb 2017 03:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dRveMkycAZhXe4faerwg9TalxraCdHIQRjz3guoCDsI=; b=LR/lpp4EDleWowZbbUQK4eJh2mhl9tXGxY+DhEPHSIGfax8D+Cb35xDqFkEfjeAjUQ 0D6ZK7muGcpFDLsBBwX1cjpVtSidW9Rn459BU1FTeVzCWt/bAKerfQPy0MlkUd+4e2vX yAbyZM4qz+HBZeiZHTPplTsPnp63574t9WeblZxbKt1M9hotkUIrj1zeT2x6rlszjEB5 GsYPzehSO3MgKDj7MtKRi8ODyf8ryYyoBncvtVCrBYOlOkZCouBzWNYUmQBwf3KngpvT Xd8jzlv50nEQVNQdVvSa6DQUcxbmzbbY6N6hb0werilKa/sSGwbVt9OMN6unfUoFz7AF EAGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dRveMkycAZhXe4faerwg9TalxraCdHIQRjz3guoCDsI=; b=bwzI2VT/KXcF5dEO/9lH5yBsctkXoBiEFTXWBazBLVR3I8lLZY2yIihBP/kXtHzE/q 5JOLUtZ3eMiLMVckm5nTv64jYaG9H70Pcy2QqGYbSvcC2Iu7ITz7PL5qTIhsebGLSUj2 N2KLcoVhYVf6xJhKl5Xg1cL9wyZagekGi+3z9udcsYnaI/yZv2wlpLMSn4jbHU+Z2xS/ hoPOGyvpotEKNl1lkHtUzPXwnFOc355lMEHSAoACLqiHoKkxZL+ilE4R/JPOYeeklk7h vYIToxnplvbrsrM9SUj2Ll0YWWqGi5H6JrYuyMk2A/CktiSGSL8Y+tQy6Unuv/uJgylc 9uuA== X-Gm-Message-State: AMke39nXQ6Ez2NtJnj4lAyWlLnAEFaw2UMWrAMCrFDwkhUDoPKQODmG8hNJNgbBTnsbbSA== X-Received: by 10.36.48.208 with SMTP id q199mr1672565itq.28.1487243217633; Thu, 16 Feb 2017 03:06:57 -0800 (PST) Received: from [22.70.247.45] ([172.56.13.228]) by smtp.gmail.com with ESMTPSA id m198sm4063388itg.1.2017.02.16.03.06.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 03:06:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14D27) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Date: Thu, 16 Feb 2017 11:06:53 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> To: Susan Hares Archived-At: Cc: idr@ietf.org, spring@ietf.org, "Alvaro Retana \(aretana\)" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:06:59 -0000 --Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes/support Regards, Jeff > On Feb 15, 2017, at 23:34, Susan Hares wrote: >=20 > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-rout= ing-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-e= pe%20 > =20 > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexu= s Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information := > =20 > 1) Were these implementations separate implementations? > 2) What were the results of the interoperability tests? > =20 > This work is linked to the draft-ietf-spring-segment-routing-central-epe w= ork in the SPRING WG. Based on the two drafts, the WG should might consider:= =20 > 1) Is there need for this work in deployments in networks/ > 2) Is this technically ready for publication? > 3) Does it fit with the spring informational draft? > =20 > For the ease of reference the web references are below: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/= > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central= -epe/ > =20 > Sue Hares > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes/support

Regards,
Jeff

On Feb 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week IDR WG last c= all on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) &nbs= p;  There are two implementations describe on the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-= routing-epe%20

 

The two implementation are from  Cisco= IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) o= r greater.   The authors will indicate on the list and in the wiki= the following information :

 = ;

1)      Were these implementa= tions separate implementations?

2) &n= bsp;    What were the results of the interoperability tests?

&= nbsp;

This work is linked to the draft-ietf-spring-segment-routing-central-epe w= ork in the SPRING WG. Based on the two drafts, the WG should might consider:=  

1)      = Is there need for this= work in deployments in networks/

2)   =    Is this technically ready for publication?

3)&nbs= p;     Does it fit with the spring informational draft?

&= nbsp;

For the ease of reference the web references are below: =

https= ://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing= -central-epe/">https://datatracker.ietf.org/doc/draft-ietf-spring-segment-ro= uting-central-epe/

 

<= span style=3D"font-size:12.0pt">Sue Hares

=
__________________________= _____________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailm= an/listinfo/spring
= --Apple-Mail-B2938CC4-65DC-4FBC-BB82-43E725A02EF5-- From nobody Thu Feb 16 03:30:49 2017 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 30FB1129A8C; Thu, 16 Feb 2017 03:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mAu1fcu5cC0; Thu, 16 Feb 2017 03:30:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C40912955F; Thu, 16 Feb 2017 03:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2017; q=dns/txt; s=iport; t=1487244640; x=1488454240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CzCHvWf8W90fqX/1IPeER+in+x8BdJ4EvGwa7MQ880Q=; b=hLzOHfFpyOi7nwCqqmJIFbnAWivNKw6Swb7u7O4Y8ukgAxmmtnFKnBM3 L/gP8w4R2ajm+WGA63OgbjkeAnceFOmxKzGTN5VKyUFSRz1B8XyZbu870 yubSSyzywldSfL3MhCqvctYEu0v9uTkiH109TvE1YLvP+xAuqN1ZjDTa9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCnjKVY/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqSEJUzggwfDYUsSgKCHT8YAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQMBAQE4NAsFCwIBCA4KHgULJwslAQEEDgWJZAgOsi+LOwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhkyCBYJqhFSDNIIxBZVYhiMBhm+LJpEGkxYBHziBAFEVPRE?= =?us-ascii?q?BhGqBSHWJKoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,168,1484006400"; d="scan'208";a="207458687" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 11:30:39 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1GBUdWe029030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 11:30:39 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 06:30:38 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 06:30:38 -0500 From: "Stefano Previdi (sprevidi)" To: Susan Hares Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAjf1oA Date: Thu, 16 Feb 2017 11:30:38 +0000 Message-ID: <49CD63A7-AA91-47D5-A1D8-69FDECD6AE15@cisco.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.209.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DD45BCFE8FA9D49827211F395761D32@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: idr wg , "spring@ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:30:43 -0000 > On Feb 16, 2017, at 12:34 AM, Susan Hares wrote: >=20 > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-rou= ting-epe from (2/15 to 3/1/2017) There are two implementations describe = on the wiki at:=20 > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-= epe%20 > =20 > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nex= us Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The= authors will indicate on the list and in the wiki the following informatio= n : > =20 > 1) Were these implementations separate implementations?=20 yes. > 2) What were the results of the interoperability tests?=20 the two implementations are interoperable on the set of features they suppo= rt. See https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-ro= uting-epe%20 for details. > This work is linked to the draft-ietf-spring-segment-routing-central-epe = work in the SPRING WG. Based on the two drafts, the WG should might conside= r: =20 > 1) Is there need for this work in deployments in networks/=20 yes. This work has been triggered after several operators requirements for = egress traffic engineering. > 2) Is this technically ready for publication?=20 the authors believe so. > 3) Does it fit with the spring informational draft?=20 yes. The use-case draft describing EPE (draft-ietf-spring-segment-routing-c= entral-epe) has been adopted as WG doc in SPRING and it started the shepher= d review. Thanks. s. > For the ease of reference the web references are below:=20 > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe= / > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centra= l-epe/ > =20 > Sue Hares=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Feb 16 03:34:14 2017 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 43A4F129A1C; Thu, 16 Feb 2017 03:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYuY4_XBzw15; Thu, 16 Feb 2017 03:34:04 -0800 (PST) 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 89E7D1299A9; Thu, 16 Feb 2017 03:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12880; q=dns/txt; s=iport; t=1487244844; x=1488454444; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DIQM70veXD/80/B4LkqN3fryBvZdOFCInqkBfcUlEO4=; b=ToNwb3W6epGowNYmngg3wtNrrzqPY8Pf/d7x5VjU25Rd3nVQ1Po68ZfH B/XSDajhdRdCdbe3X8tTdeSmDiLbpbX5/K1bqbA1dQW/buh3PxZVtUvlR n1QdNwXaWxmAcYiu2dToSv5ryoKWh4ZXbOPiXQiDTFQRaXl7EltN0foxB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAQDZjKVY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCQB4UsggwshXYCgh0/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEELUwQAgEIDgMEAQEkBAcyFAkIAQEEAQ0FCIlkDrIyizsBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZMhG+FCoUvBZVYhiMBhm+LHZEPkxYBHziBAFEVPYR8gUh?= =?us-ascii?q?1iSqBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,168,1484006400"; d="scan'208,217";a="181210320" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 11:34:03 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1GBY3df027375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 11:34:03 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 05:34:02 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 05:34:02 -0600 From: "Ketan Jivan Talaulikar (ketant)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAZHD7g Date: Thu, 16 Feb 2017 11:34:02 +0000 Message-ID: <79d597ffee2d4231af7d0e0439fca3d6@XCH-ALN-008.cisco.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.54.241] Content-Type: multipart/alternative; boundary="_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "spring@ietf.org" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 11:34:06 -0000 --_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support this draft. Thanks, Ketan From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares Sent: 16 February 2017 05:05 To: idr@ietf.org Cc: Alvaro Retana (aretana) ; spring@ietf.org Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routi= ng-epe - (2/15/2017 to 3/1/2017) This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares --_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support this draft.

 

Thanks,

Ketan

 

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares
Sent: 16 February 2017 05:05
To: idr@ietf.org
Cc: Alvaro Retana (aretana) <aretana@cisco.com>; spring@ietf.o= rg
Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segmen= t-routing-epe - (2/15/2017 to 3/1/2017)

 

This= begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-e= pe from (2/15 to 3/1/2017)    There are two implementations = describe on the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segme= nt-routing-epe%20

 

The = two implementation are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)     Were these implementations separate implementations?

2)     What were the results of the interoperability tests?

 

This= work is linked to the draft-ietf-spring-segment-routing-central-epe work i= n the SPRING WG. Based on the two drafts, the WG should might consider: &nb= sp;

1)     Is there need for this work in deployments in networks/

2)     Is this technically ready for publication?

3)     Does it fit with the spring informational draft?

 

For = the ease of reference the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routi= ng-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-rou= ting-central-epe/

 

Sue = Hares

--_000_79d597ffee2d4231af7d0e0439fca3d6XCHALN008ciscocom_-- From nobody Thu Feb 16 04:39:48 2017 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 39D31129578; Thu, 16 Feb 2017 04:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl_-wejMlpmn; Thu, 16 Feb 2017 04:39:45 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE621129566; Thu, 16 Feb 2017 04:39:45 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so12732302qtb.0; Thu, 16 Feb 2017 04:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CShJalkfJaqeJPB4jcsSd0Y9jT7UQG+kcq1WKonSMgo=; b=mdByE9V/1bjVR1nOWElIQ0o0lgolPWRa3NnxzDsJUL0ZXmqaXyvd+EkG6GI6MOgKFG H8r+BNf8vfwmHphYX3x9+deI5UFn2NanzOXqeXiaIatgIwAeyu1RpdLcXiF17tNjqVqK e4sd4uvoK1zLCmcpMyzRu/RETFjaqt3iEuH6p0OgnFvt7es64ExfTUUl/GuySeiJ0FRh elSUsykbaFZ6S6D9/Mj2/XioSMFPhPCFsOTMXAQ5uu3ApI+kvDNTl1moP24ExZNX/V5a ekwzgyW/hDOzSx/BPuqhCwQhsg9SYXnnEeAXCapS0a3lPaJXUFqSlF8lKru1Oj9sgA+C OEvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CShJalkfJaqeJPB4jcsSd0Y9jT7UQG+kcq1WKonSMgo=; b=PiSQB5ozHxecnU7FsXDMMN+gfDm9RXwsMhZzx5VJENmHhew+p2estH5QW+184jrDdH nBDF5USJY0VEifWHxins+NHdZvzhaH0AhmYiW289swLJ/yd8cCWStDldCJXI149PaLHe EoZ4O4d8arbei0LlPloZ8SbcJlTD7+0GcDl0oqSmSCGRFCJ5efY7GOE5SInekYVZP3hK Z0sysryEkD3bQh/xdcBlFHaScNBo0o4dSi7ferwV4U0kU6Nx9nedcR5g4p9166Vkb+Zc niMr0nB6f2W1wOsWtGsuV3hDT6DaXzGVfzjkTeVK9sjkmm0dQ46FADwLrjU8qzGTRV9b hiWA== X-Gm-Message-State: AMke39lrqILAG5+W87i1spFaRW/R0HtTUwAnQjOh7QM2mSA/DJ2TAw90LxhLbjbn/n6ulELjxoODBnipaMP/7Q== X-Received: by 10.237.43.36 with SMTP id p33mr1579215qtd.199.1487248784684; Thu, 16 Feb 2017 04:39:44 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 04:39:44 -0800 (PST) Received: by 10.140.28.69 with HTTP; Thu, 16 Feb 2017 04:39:44 -0800 (PST) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> From: Robert Raszuk Date: Thu, 16 Feb 2017 13:39:44 +0100 X-Google-Sender-Auth: ztrt8OKRQsz4_hFRuEanuIAi-e8 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c12507e80fcb40548a517fd Archived-At: Cc: idr wg , spring@ietf.org, "Alvaro Retana \(aretana\)" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:39:47 -0000 --94eb2c12507e80fcb40548a517fd Content-Type: text/plain; charset=UTF-8 Support. Thx R. On Feb 15, 2017 6:39 PM, "Susan Hares" wrote: > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe > from (2/15 to 3/1/2017) There are two implementations describe on the > wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls- > segment-routing-epe%20 > > > > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco > Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. > The authors will indicate on the list and in the wiki the following > information : > > > > 1) Were these implementations separate implementations? > > 2) What were the results of the interoperability tests? > > > > This work is linked to the draft-ietf-spring-segment-routing-central-epe > work in the SPRING WG. Based on the two drafts, the WG should might > consider: > > 1) Is there need for this work in deployments in networks/ > > 2) Is this technically ready for publication? > > 3) Does it fit with the spring informational draft? > > > > For the ease of reference the web references are below: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment- > routing-central-epe/ > > > > Sue Hares > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --94eb2c12507e80fcb40548a517fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

Thx=
R.

On Feb 15, 2017 6:39 PM, "Susan Hares" <<= a href=3D"mailto:shares@ndzh.com">shares@ndzh.com> wrote:

This begins a 2 week IDR= WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 t= o 3/1/2017) =C2=A0=C2=A0=C2=A0There are two implementations describe on the= wiki at:

https://trac.ietf.org/tr= ac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20

= =C2=A0

The two implementation are from = =C2=A0Cisco IOS-= XR release 6.0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS= 7.0(3)I1(1) or greater.=C2=A0=C2=A0 The authors will indicate on the list = and in the wiki the following information :

=

=C2=A0

= 1)=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 W= ere these implementations separate implementations?

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What were the results of the interoperab= ility tests?

=C2=A0

This work is linked to the draft-ietf-spring= -segment-routing-central-epe work in the SPRING WG. Based on the two d= rafts, the WG should might consider: =C2=A0

1)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Is there need for this work in deployments in networks/

<= /u>2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this technically ready for publ= ication?

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Does it fit with the= spring informational draft?

=C2=A0

For the ease of reference t= he web references are below:

https://da= tatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/<= /a>

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/

= =C2=A0

Sue Hares


___________________= ____________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--94eb2c12507e80fcb40548a517fd-- From nobody Thu Feb 16 05:29:04 2017 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 21B04129CF9; Thu, 16 Feb 2017 05:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkMwB-zh48RG; Thu, 16 Feb 2017 05:28:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03251129CF3; Thu, 16 Feb 2017 05:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17148; q=dns/txt; s=iport; t=1487251735; x=1488461335; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=74K8pWfFOY+IQBuP27LA+nNY708TArxVLJTYPv03yA0=; b=CZsyPHI648LeRHqGE8MNt0yVU1f2U7wF7BISmGpum717Y6L88kwdjnsS taoYqi3EZATOsrj1gZ6CeXPj/J8RkpNDuye5DXwg+pcB4iFYNowXzv+YD SHFkiuRPLqO7HU222ZQDZzP3rIhRd5ryMdAG1yQapj4axWDTPGswzxXqv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAQDHp6VY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB4NSigiSEJAHhSyCDCyFdgIagXk/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEEIwpMEAIBCA4DAwECJAcCAgIwHQgBAQQBDQWJbA6wHYIlK4sQAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGTIIFgmqEdIJmLoIxBZt/AYZviyeRBpMXAR8?= =?us-ascii?q?4gQBRFT0RAYRqgUh1iSqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207497264" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 13:28:55 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1GDSstW026682 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 13:28:55 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 08:28:54 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 08:28:54 -0500 From: "Zafar Ali (zali)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAdJtMA Date: Thu, 16 Feb 2017 13:28:54 +0000 Message-ID: <59F9549F-084E-42C4-AEC6-B91EF8447B53@cisco.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> 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.96.243] Content-Type: multipart/alternative; boundary="_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] [Idr] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:29:01 -0000 --_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCg0KSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZlIGl0IGlzIHJl YWR5IGZvciBwdWJsaWNhdGlvbi4NCg0KVGhhbmtzDQoNClJlZ2FyZHMg4oCmIFphZmFyDQoNCkZy b206IElkciA8aWRyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyBhdCA2 OjM0IFBNDQpUbzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NCkNjOiAic3ByaW5nQGll dGYub3JnIiA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogW0lkcl0gSURSIFdHIDIgd2VlayBX RyBMQyBvbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIC0gKDIvMTUv MjAxNyB0byAzLzEvMjAxNykNCg0KVGhpcyBiZWdpbnMgYSAyIHdlZWsgSURSIFdHIGxhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIGZyb20gKDIvMTUg dG8gMy8xLzIwMTcpICAgIFRoZXJlIGFyZSB0d28gaW1wbGVtZW50YXRpb25zIGRlc2NyaWJlIG9u IHRoZSB3aWtpIGF0Og0KaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQt aWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSUyMA0KDQpUaGUgdHdvIGltcGxlbWVu dGF0aW9uIGFyZSBmcm9tICBDaXNjbyBJT1MtWFIgcmVsZWFzZSA2LjAuMiBhbmQgQ2lzY28gTmV4 dXMgU3dpdGNoIE45MDAwL04zMDAwIHBsYXRmb3JtcyBydW5uaW5nIE5YLU9TIDcuMCgzKUkxKDEp IG9yIGdyZWF0ZXIuICAgVGhlIGF1dGhvcnMgd2lsbCBpbmRpY2F0ZSBvbiB0aGUgbGlzdCBhbmQg aW4gdGhlIHdpa2kgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiA6DQoNCg0KMSkgICAgICAgV2Vy ZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgc2VwYXJhdGUgaW1wbGVtZW50YXRpb25zPw0KDQoyKSAg ICAgICBXaGF0IHdlcmUgdGhlIHJlc3VsdHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdHM/ DQoNClRoaXMgd29yayBpcyBsaW5rZWQgdG8gdGhlIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1jZW50cmFsLWVwZSB3b3JrIGluIHRoZSBTUFJJTkcgV0cuIEJhc2VkIG9uIHRoZSB0 d28gZHJhZnRzLCB0aGUgV0cgc2hvdWxkIG1pZ2h0IGNvbnNpZGVyOg0KDQoxKSAgICAgICBJcyB0 aGVyZSBuZWVkIGZvciB0aGlzIHdvcmsgaW4gZGVwbG95bWVudHMgaW4gbmV0d29ya3MvDQoNCjIp ICAgICAgIElzIHRoaXMgdGVjaG5pY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uPw0KDQozKSAg ICAgICBEb2VzIGl0IGZpdCB3aXRoIHRoZSBzcHJpbmcgaW5mb3JtYXRpb25hbCBkcmFmdD8NCg0K Rm9yIHRoZSBlYXNlIG9mIHJlZmVyZW5jZSB0aGUgd2ViIHJlZmVyZW5jZXMgYXJlIGJlbG93Og0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2Vn bWVudC1yb3V0aW5nLWVwZS8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFsLWVwZS8NCg0KU3VlIEhhcmVzDQo= --_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <34935297E987A24091C2F4206549F3A8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0i Ij4NCjxtZXRhIG5hbWU9IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KcC5wMSwgbGkucDEsIGRpdi5wMQ0KCXttc28tc3R5bGUtbmFtZTpwMTsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTt9DQpzcGFuLnMxDQoJe21zby1zdHlsZS1uYW1lOnMxO30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTI1NDA3 NzY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDk0 OTk0Njk0IDEzNjg5NjIwOTggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWNvbG9yOmJs YWNrO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjEzODgwNjMzNzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE5ODAyNzU0NjggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5IaTogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJwMSI+PHNwYW4gY2xhc3M9InMxIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+SSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBiZWxpZXZl IGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+UmVn YXJkcyDigKYgWmFmYXIgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZHIgJmx0O2lkci1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyBhdCA2OjM0IFBN PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtpZHJAaWV0Zi5vcmcmcXVvdDsgJmx0O2lkckBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3By aW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bSWRyXSBJRFIgV0cgMiB3ZWVr IFdHIExDIG9uIGRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUgLSAoMi8x NS8yMDE3IHRvIDMvMS8yMDE3KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+VGhpcyBiZWdpbnMgYSAyIHdlZWsgSURSIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LWlkci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlIGZyb20gKDIvMTUgdG8gMy8xLzIwMTcpICZu YnNwOyZuYnNwOyZuYnNwO1RoZXJlIGFyZSB0d28gaW1wbGVtZW50YXRpb25zIGRlc2NyaWJlIG9u IHRoZSB3aWtpIGF0Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5p ZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGlu Zy1lcGUlMjAiPmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYt aWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUlMjA8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGUgdHdvIGltcGxlbWVudGF0aW9uIGFyZSBmcm9tDQo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2s7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Q2lzY28NCjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPklPUy1YUiByZWxlYXNlIDYuMC4yIGFu ZCBDaXNjbyBOZXh1cyBTd2l0Y2ggTjkwMDAvTjMwMDAgcGxhdGZvcm1zIHJ1bm5pbmcgTlgtT1Mg Ny4wKDMpSTEoMSkgb3IgZ3JlYXRlci4mbmJzcDsmbmJzcDsgVGhlIGF1dGhvcnMgd2lsbCBpbmRp Y2F0ZSBvbiB0aGUgbGlzdCBhbmQgaW4gdGhlIHdpa2kgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlv biA6PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ V2VyZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnMgc2VwYXJhdGUgaW1wbGVtZW50YXRpb25zPw0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5XaGF0IHdlcmUg dGhlIHJlc3VsdHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdHM/DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoaXMgd29yayBpcyBsaW5rZWQgdG8gdGhl IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFsLWVwZSB3b3JrIGluIHRo ZSBTUFJJTkcgV0cuIEJhc2VkIG9uIHRoZSB0d28gZHJhZnRzLCB0aGUgV0cgc2hvdWxkIG1pZ2h0 IGNvbnNpZGVyOiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEg bGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklzIHRoZXJlIG5lZWQgZm9yIHRoaXMg d29yayBpbiBkZXBsb3ltZW50cyBpbiBuZXR3b3Jrcy8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SXMgdGhp cyB0ZWNobmljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24/DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkRv ZXMgaXQgZml0IHdpdGggdGhlIHNwcmluZyBpbmZvcm1hdGlvbmFsIGRyYWZ0Pw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gb3IgdGhlIGVhc2Ugb2YgcmVmZXJl bmNlIHRoZSB3ZWIgcmVmZXJlbmNlcyBhcmUgYmVsb3c6DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItYmdw bHMtc2VnbWVudC1yb3V0aW5nLWVwZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUvPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUvIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJh bC1lcGUvPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+U3Vl IEhhcmVzIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_59F9549F084E42C4AEC6B91EF8447B53ciscocom_-- From nobody Thu Feb 16 06:02:44 2017 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 7473F1295E3; Thu, 16 Feb 2017 06:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C_hgDVB7NZ2; Thu, 16 Feb 2017 06:02:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A69E1295AD; Thu, 16 Feb 2017 06:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13699; q=dns/txt; s=iport; t=1487253755; x=1488463355; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+2zE2UBkyWErKWV28JWXbveGhyVDcCOdDS9wJfUie1c=; b=emzxe6rkpGGiBIUA3yeTNeGmOQMMRIXwTjWHzKGCgd+G0lJgvmglJZ3N FEE7C4KPJ/YDLMfNcHiWngq+G52nq+RA6+jwj2GbpDOVgxcFZarVTRb+k +qb3ghcpxiSF1+kBgHpxNm1KR2ooUGvN+VGj4ms9/0g7kvXvinoqsW1tP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQDwr6VY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCQB4UsggwshXYCggU/GAECAQEBAQEBAWIohHA?= =?us-ascii?q?BAQEELUwQAgEIDgMDAQIkBAcyFAkIAQEEAQ0FiWwOsleLPAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFizuEdIVFBZVchiMBhm+LJ5EGkxcBHziBAFEVPYR8gUh1iSq?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207508944" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 14:02:34 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1GE2YCW012465 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 14:02:34 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 09:02:33 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 09:02:33 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAeUxWA Date: Thu, 16 Feb 2017 14:02:33 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.195] Content-Type: multipart/alternative; boundary="_000_D4CB1B179CA03aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "spring@ietf.org" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:02:42 -0000 --_000_D4CB1B179CA03aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as a contributor. Thanks, Acee From: spring > on b= ehalf of Susan Hares > Date: Wednesday, February 15, 2017 at 6:34 PM To: IDR List > Cc: "Alvaro Retana (aretana)" >= , "spring@ietf.org" > Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routi= ng-epe - (2/15/2017 to 3/1/2017) This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares --_000_D4CB1B179CA03aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <38A6A5CD23D1964B922B8373A047828D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support as a contributor. 
Thanks,
Acee 

From: spring <spring-bounces@ietf.org> on behalf of Susan= Hares <shares@ndzh.com>
Date: Wednesday, February 15, 2017 = at 6:34 PM
To: IDR List <idr@ietf.org>
Cc: "Alvaro Retana (aretana)&q= uot; <aretana@cisco.com>, &q= uot;spring@ietf.org" <spring@ietf.org>
Subject: [spring] IDR WG 2 week WG = LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)

This begins a 2 wee= k IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 t= o 3/1/2017)    There are two implementations describe on the= wiki at:

ht= tps://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%= 20

 

The two implementat= ion are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)      Were th= ese implementations separate implementations?

2)      What we= re the results of the interoperability tests?

 

This work is linked= to the draft-ietf-spring-segment-routing-central-epe work in the SPRING WG= . Based on the two drafts, the WG should might consider:  <= /span>

1)      Is ther= e need for this work in deployments in networks/

2)      Is this= technically ready for publication?

3)      Does it= fit with the spring informational draft?

 

For the ease of ref= erence the web references are below:

https:/= /datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

ht= tps://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-ep= e/

 

Sue Hares

--_000_D4CB1B179CA03aceeciscocom_-- From nobody Thu Feb 16 07:39:48 2017 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 875AC12009C; Thu, 16 Feb 2017 07:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79pQnsDvew1S; Thu, 16 Feb 2017 07:39:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4620712965D; Thu, 16 Feb 2017 07:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10800; q=dns/txt; s=iport; t=1487259581; x=1488469181; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5zxV0t5qktU89pl54tQOX4JMgtQgWxXQo3aG0oBg3fg=; b=gKw0Q+ypaShEyuUIL7mBPAS5rS2BKPjCWfgbDXtLvV1XUvMS+Mq8V3n2 Y12w26v5zCa6tKEBMeOsn/3atQc8Mll4z8b2F69CXvkBK/tCMWVZsfefo 5ghPLmvldE1RaGtz3Lrqn6LCXoEZX+YJvmeTJFCM8zg9oAmbe/BaBTCbv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQA1x6VY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41akhCQB4UsggwfAQyFLEoCggo/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEEAQFsCxACAQgRAwECJAQHJwsUCQgCBAENBYlsDrJoizsBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZMhG+EdIVFBZVchiMBhm+LJ5EGkxcBHziBAFEVPYQ?= =?us-ascii?q?Nb4FIdYkqgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208,217";a="207545694" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2017 15:39:40 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1GFddLH010540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 15:39:40 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 10:39:39 -0500 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 10:39:39 -0500 From: "Gaurav Dawra (gdawra)" To: Robert Raszuk , Susan Hares Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSiGri+NyMNxA4e0i/ZPLgTjfcSg== Date: Thu, 16 Feb 2017 15:39:39 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.58.145] Content-Type: multipart/alternative; boundary="_000_D4CB07AE1D015Dgdawraciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg , "spring@ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:39:43 -0000 --_000_D4CB07AE1D015Dgdawraciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, -Gaurav From: spring > on b= ehalf of Robert Raszuk > Date: Thursday, February 16, 2017 at 4:39 AM To: Susan Hares > Cc: idr wg >, "spring@ietf.org" >, "Alvaro Retana (a= retana)" > Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-r= outing-epe - (2/15/2017 to 3/1/2017) Support. Thx R. On Feb 15, 2017 6:39 PM, "Susan Hares" > wrote: This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D4CB07AE1D015Dgdawraciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

Regards,

-Gaurav

From: spring <spring-bounces@ietf.org> on behalf of Rober= t Raszuk <robert@raszuk.net>=
Date: Thursday, February 16, 2017 a= t 4:39 AM
To: Susan Hares <shares@ndzh.com>
Cc: idr wg <idr@ietf.org>, "= spring@ietf.org" <spring@iet= f.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>
Subject: Re: [spring] IDR WG 2 week= WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017= )

Support.

Thx
R.

On Feb 15, 2017 6:39 PM, "Susan Hares"= <shares@ndzh.com> wrote:

This begins a 2 wee= k IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2= /15 to 3/1/2017)    There are two implementations describe o= n the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp= ls-segment-routing-epe%20

 

The two implementat= ion are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)      Were these imp= lementations separate implementations?

2)      What were the = results of the interoperability tests?

 

This work is linked= to the draft-ietf-spring-segment-routing-central-epe work in the SPRI= NG WG. Based on the two drafts, the WG should might consider:  =

1)      Is there need = for this work in deployments in networks/

2)      Is this techni= cally ready for publication?

3)      Does it fit wi= th the spring informational draft?

 

For the ease of ref= erence the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-seg= ment-routing-central-epe/

 

Sue Hares


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--_000_D4CB07AE1D015Dgdawraciscocom_-- From nobody Thu Feb 16 08:50:15 2017 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 B98E012960B; Thu, 16 Feb 2017 08:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 qm5qUPDe4ouD; Thu, 16 Feb 2017 08:50:08 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79C21294FA; Thu, 16 Feb 2017 08:50:07 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 9BF2860633; Thu, 16 Feb 2017 17:50:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 6DC00180055; Thu, 16 Feb 2017 17:50:06 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 17:50:06 +0100 From: To: Susan Hares , "idr@ietf.org" Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAj0X2g Date: Thu, 16 Feb 2017 16:50:05 +0000 Message-ID: <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , "spring@ietf.org" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:50:10 -0000 --_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've read the draft, please find below some minor comments: --- =A74.3 " * A 4 octet index defining the offset in the SID/Label space advert= ised by this router using the encodings defined in Section 3.1." - Following the recent addition of the SRLB Label Space, I'd rather have th= e text explicitly refers to name of that Label space. e.g. OLD: SID/Label space NEW: SRGB - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess someone= may imagine using the BGP "Originator SRGB TLV". Then what if the node run= s multiple IGP with different SRGB configured? - Note that this document has no "Section 3.1". The text seems borrowed fro= m the IS-IS SR draft, hence may be adding the name of this draft would just= solve the point. (with a normative reference to this IS-IS draft) --- OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by IANA) proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1) ("new" may become unspecific 2 years from now) --- One could probably argue that [I-D.ietf-spring-segment-routing] should be a= normative reference. Thanks, Regards, --Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, February 16, 2017 12:35 AM To: idr@ietf.org Cc: 'Alvaro Retana (aretana)'; spring@ietf.org Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routi= ng-epe - (2/15/2017 to 3/1/2017) This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information : 1) Were these implementations separate implementations? 2) What were the results of the interoperability tests? This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I’= ;ve read the draft, please find below some minor comments:

&n= bsp;

---

=A74.3<= o:p>

"&= nbsp;     *  A 4 octet index defining the offset i= n the SID/Label space advertised by this router using the encodings defined= in  Section 3.1."

&n= bsp;

- Follo= wing the recent addition of the SRLB Label Space, I'd rather have the text = explicitly refers to name of that Label space. e.g.

OLD: SI= D/Label space

NEW: SR= GB

&n= bsp;

- Which= (SRGB) advertisement? I'm assuming the IGP one, but I guess someone may im= agine using the BGP "Originator SRGB TLV". Then what if the node = runs multiple IGP with different SRGB configured?

&n= bsp;

- Note = that this document has no "Section 3.1". The text seems borrowed = from the IS-IS SR draft, hence may be adding the name of this draft would j= ust solve the point. (with a normative reference to this IS-IS draft)

&n= bsp;

---

OLD: Th= e Link NLRI uses the new Protocol-ID value (to be assigned by IANA)

propose= d NEW: The Link NLRI uses the BGP Protocol-ID (TBD1)

&n= bsp;

(“= ;new” may become unspecific 2 years from now)

&n= bsp;

---

One cou= ld probably argue that [I-D.ietf-spring-segment-routing] should be a normat= ive reference.

&n= bsp;

Thanks,=

Regards= ,

--Bruno=

&n= bsp;

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, February 16, 2017 12:35 AM
To: idr@ietf.org
Cc: 'Alvaro Retana (aretana)'; spring@ietf.org
Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segmen= t-routing-epe - (2/15/2017 to 3/1/2017)

 

This= begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-e= pe from (2/15 to 3/1/2017)    There are two implementations = describe on the wiki at:

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segme= nt-routing-epe%20

 

The = two implementation are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)      Were these implementations separate implementations?

2)      What were the results of the interoperability tests?

 

This= work is linked to the draft-ietf-spring-segment-routing-central-epe work i= n the SPRING WG. Based on the two drafts, the WG should might consider: &nb= sp;

1)      Is there need for this work in deployments in networks/

2)      Is this technically ready for publication?

3)      Does it fit with the spring informational draft?

 

For = the ease of reference the web references are below:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routi= ng-epe/

https://datatracker.ietf.org/doc/draft-ietf-spring-segment-rou= ting-central-epe/

 

Sue = Hares 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_-- From nobody Thu Feb 16 14:30:15 2017 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 B6530126B6D; Thu, 16 Feb 2017 14:30:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148728420973.1067.1725012678592216776.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 14:30:09 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-11.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:30:09 -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 of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-11.txt Pages : 28 Date : 2017-02-16 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a semantic local to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress nodes to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment Routing can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address of the packet. The next active segment is indicated by a pointer in the new routing header. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 16 14:31:36 2017 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 AF8E7129560 for ; Thu, 16 Feb 2017 14:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbotzrX4HjQB for ; Thu, 16 Feb 2017 14:31:34 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01530129457 for ; Thu, 16 Feb 2017 14:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3025; q=dns/txt; s=iport; t=1487284294; x=1488493894; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PchapOTIFRcH1Li7a+ctfzOHxY1wLaK+GIAfH8MNjYk=; b=P2IiJM7Vc9Sh57jCaFC0w/9Mn9suKW1303JHA/k7AZHsaEhAPk4FWbxy 8a9TEMoj5YS6/uHCOiNjB/XbrwnCqfWNRrE8PKTKVS8t8lpSROEQ7p9sS brgleHPMLxZw7rK+fgh2yOeWQpHcUkSOuwbxCloD5U0rF/biD/2IEXkRi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQDaJ6ZY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqRcB+VM4IMHwuFeAKCED8YAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQMBAQE4NBALAgEIEgYeECcLFw4CBBMJiVsIDrJ0i1YBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdhkyCBQiCYoMXgT0ygwKCMQWbfwGGb4sngXtThESJdIpaiD0BHzg?= =?us-ascii?q?8RFEVGCURAYYydQGJKYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="385879795" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 22:31:33 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1GMVWEh002873 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Feb 2017 22:31:32 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 17:31:32 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 17:31:31 -0500 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: I-D Action: draft-ietf-spring-segment-routing-11.txt Thread-Index: AQHSiKRDA7WrBPJiEU6hpQ2ZNv20NqFsi1wA Date: Thu, 16 Feb 2017 22:31:31 +0000 Message-ID: References: <148728420973.1067.1725012678592216776.idtracker@ietfa.amsl.com> In-Reply-To: <148728420973.1067.1725012678592216776.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.209.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <8C92044A5B8418469F00C60546C740F4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-11.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:31:36 -0000 Hi, this version integrates various comments received during the WG last call a= nd by the shepherd review. Thanks. s. > On Feb 16, 2017, at 11:30 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Source Packet Routing in Networking of t= he IETF. >=20 > Title : Segment Routing Architecture > Authors : Clarence Filsfils > Stefano Previdi > Bruno Decraene > Stephane Litkowski > Rob Shakir > Filename : draft-ietf-spring-segment-routing-11.txt > Pages : 28 > Date : 2017-02-16 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through an ordered list of instructions, called > segments. A segment can represent any instruction, topological or > service-based. A segment can have a semantic local to an SR node or > global within an SR domain. SR allows to enforce a flow through any > topological path and service chain while maintaining per-flow state > only at the ingress nodes to the SR domain. >=20 > Segment Routing can be directly applied to the MPLS architecture with > no change on the forwarding plane. A segment is encoded as an MPLS > label. An ordered list of segments is encoded as a stack of labels. > The segment to process is on the top of the stack. Upon completion > of a segment, the related label is popped from the stack. >=20 > Segment Routing can be applied to the IPv6 architecture, with a new > type of routing header. A segment is encoded as an IPv6 address. An > ordered list of segments is encoded as an ordered list of IPv6 > addresses in the routing header. The active segment is indicated by > the Destination Address of the packet. The next active segment is > indicated by a pointer in the new routing header. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Feb 16 14:34:18 2017 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 6ABFC1296DD; Thu, 16 Feb 2017 14:34:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148728445743.1027.18128759602323016329.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 14:34:17 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-central-epe-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:34:17 -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 of the IETF. Title : Segment Routing Centralized BGP Egress Peer Engineering Authors : Clarence Filsfils Stefano Previdi Ebben Aries Dmitry Afanasiev Filename : draft-ietf-spring-segment-routing-central-epe-04.txt Pages : 19 Date : 2017-02-16 Abstract: Segment Routing (SR) leverages source routing. A 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 and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-central-epe-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 16 14:35:19 2017 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 0956B129706 for ; Thu, 16 Feb 2017 14:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbpAjgrYI1uf for ; Thu, 16 Feb 2017 14:35:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95902124281 for ; Thu, 16 Feb 2017 14:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2719; q=dns/txt; s=iport; t=1487284515; x=1488494115; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=N8K0HktC6Y4VOLkts6gL86zgU74bn+3KhiI1dmp14hA=; b=KXtwvEk5MdZdV4kLLxBwL7a2vENCFk5HI79aN071FoP7LYSLsfV/B1dN 2PQLkbC5JWvH/UAE7Rpo65ga4y5H8o7CDw9R3B0EZ38Q3vOUX6xAO6fyy +V+ht6dLahShgz9rc2sSgEpY/mxvGmvXWlHxx7UvLTzpIKf8CpIisDMGx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQA1KKZY/4kNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVqRcB+VM4IMHw2FdgKCED8YAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQMBAQE4NBALAgEIEgYeECcLFw4CBBMJEolJCA6ydYtVAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYZMggUIgmKDF4E9MoMCgjEFm38Bhm+LJ4F7U4REiXSKWog9AR8?= =?us-ascii?q?4PERRFRglEQGGMnUBiSmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="207394171" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2017 22:35:14 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1GMZEcl015743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Feb 2017 22:35:14 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 17:35:13 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 16 Feb 2017 17:35:13 -0500 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: I-D Action: draft-ietf-spring-segment-routing-central-epe-04.txt Thread-Index: AQHSiKTanc0vu5pFvUab7SRQCb9bPaFsjGiA Date: Thu, 16 Feb 2017 22:35:13 +0000 Message-ID: References: <148728445743.1027.18128759602323016329.idtracker@ietfa.amsl.com> In-Reply-To: <148728445743.1027.18128759602323016329.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.209.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <4535A74021C8FB4E8D25FE1D56A4BEAF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-central-epe-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:35:17 -0000 Hi, this version integrates comments received during shepherd review.=20 Thanks. s. > On Feb 16, 2017, at 11:34 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Source Packet Routing in Networking of t= he IETF. >=20 > Title : Segment Routing Centralized BGP Egress Peer Engi= neering > Authors : Clarence Filsfils > Stefano Previdi > Ebben Aries > Dmitry Afanasiev > Filename : draft-ietf-spring-segment-routing-central-epe-04.txt > Pages : 19 > Date : 2017-02-16 >=20 > Abstract: > Segment Routing (SR) leverages source routing. A 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 and service chain while maintaining > per-flow state only at the ingress node of the SR domain. >=20 > The Segment Routing architecture can be directly applied to the MPLS > dataplane with no change on the forwarding plane. It requires minor > extension to the existing link-state routing protocols. >=20 > This document illustrates the application of Segment Routing to solve > the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based > BGP-EPE solution allows a centralized (SDN) controller to program any > egress peer policy at ingress border routers or at hosts within the > domain. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centra= l-epe/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe= -04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-cen= tral-epe-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Feb 16 22:56:51 2017 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 9F7D5128874; Thu, 16 Feb 2017 22:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 UEtr1sJMJrdS; Thu, 16 Feb 2017 22:56:49 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C521B1293F0; Thu, 16 Feb 2017 22:56:48 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so33718458qtg.3; Thu, 16 Feb 2017 22:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hi8QOpL9a+xF5ZAaNibNHqhFTVFEND8hp0V/bZ+mOjg=; b=kfierrtD9F33IiwKEK4Tmia7rIHRQZwDvpLcwp8HF1+SQDwPh+CcZnF8AbpwnbHnS8 zBUTpUm89e7xLrYSmlgl6nNT6ufPjio60fnhyMfkMgGL48aMQ/xHtV+PRmE5mYIxyhp7 oX8SfCpDmxEODrzzq+j+0GYChecfoK+sUVCClMfFwLQ2/qOInjDEIcztHsRx+cpRMNnu WrPt7xi4+ASexPllEc7am86/euzfm2U8zjXlNNv+cdUdBtPLk04mlsFVu+/s7LfZ/HlH YNepvUk8pMZg6AL4FmPtpi6VK0o5bJ4E4wRoQKB7mDNmCHau5tuxTB4uSf7WKMCZ5tED Urbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hi8QOpL9a+xF5ZAaNibNHqhFTVFEND8hp0V/bZ+mOjg=; b=TfG0uV/JS1n13lafs4hR/Vgo2PAejPjX2uhap95ORlowlqCSyg92PtPQXICen5kOCR HmEJW7wxOnp5Y1J3D2+Pe779Qt/RIxtKljh0g10E9/TEv1ahoRFpaxKqtU9YBnmygLCb cQ+MWSkKcmBLUklgIwvTUmrUiwExHYa3bppVKb2Pa81fvbSqGkznLK9UuNlqt/Idf7qs diTPTgr8zhs9zODC2wQa/unzN1d9uk3wCZfQAQ8pnCBwd7eNvy/ph+B/tXftmowEvcCm J2a5De5706NP67PRWxTJwBsrbrEyUyR1iccK4CqcmFq8T+ocQe9EVEHU8S93qP7oWmR5 fTjg== X-Gm-Message-State: AMke39nO4x2rh3EgbMG01tIA/twGit6EGAqOBpjdfOIZc2511bkc0zsqt2FOAdaH1NEZDa9wMb7u8zTfdgZsMQ== X-Received: by 10.237.38.133 with SMTP id q5mr5628127qtd.21.1487314607959; Thu, 16 Feb 2017 22:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.3.27 with HTTP; Thu, 16 Feb 2017 22:56:47 -0800 (PST) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> From: Miya Kohno Date: Fri, 17 Feb 2017 15:56:47 +0900 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114dabaee07f960548b46a8d Archived-At: Cc: idr@ietf.org, spring@ietf.org, "Alvaro Retana \(aretana\)" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 06:56:50 -0000 --001a114dabaee07f960548b46a8d Content-Type: text/plain; charset=UTF-8 I support this draft. Thanks! Miya Kohno On Thu, Feb 16, 2017 at 8:34 AM, Susan Hares wrote: > This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe > from (2/15 to 3/1/2017) There are two implementations describe on the > wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls- > segment-routing-epe%20 > > > > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco > Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. > The authors will indicate on the list and in the wiki the following > information : > > > > 1) Were these implementations separate implementations? > > 2) What were the results of the interoperability tests? > > > > This work is linked to the draft-ietf-spring-segment-routing-central-epe > work in the SPRING WG. Based on the two drafts, the WG should might > consider: > > 1) Is there need for this work in deployments in networks/ > > 2) Is this technically ready for publication? > > 3) Does it fit with the spring informational draft? > > > > For the ease of reference the web references are below: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment- > routing-central-epe/ > > > > Sue Hares > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --001a114dabaee07f960548b46a8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support this draft.


Th= anks!
Miya Kohno

On Thu, Feb 16, 2017 at 8:34 AM, Susan Hares <shares@nd= zh.com> wrote:

This = begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) =C2=A0=C2=A0=C2=A0There are two implementati= ons describe on the wiki at:

https= ://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routi= ng-epe%20

=C2=A0

The two implementation are from =C2=A0Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch N9000/N3000 plat= forms running NX-OS 7.0(3)I1(1) or greater.=C2=A0=C2=A0 The authors will in= dicate on the list and in the wiki the following information :

=C2=A0

1)Were these implementations separate implementations? =

<= u>2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What were the resul= ts of the interoperability tests?

=C2=A0

This work is linked to = the draft-ietf-spring-segment-routing-central-epe work in the SPRING W= G. Based on the two drafts, the WG should might consider: =C2=A0<= /u>

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= /u>Is there need for this work in deployme= nts in networks/

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Is this te= chnically ready for publication?

= 3)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Does it fit with the spring informational draft? =

=C2=A0

For= the ease of reference the web references are below: <= /p>

https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

= https:/= /datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centr= al-epe/

=C2=A0

Sue Hares


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

--001a114dabaee07f960548b46a8d-- From nobody Fri Feb 17 00:05:24 2017 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 EED37129527; Fri, 17 Feb 2017 00:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.786 X-Spam-Level: X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, 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 2Rnsk7LWfPvz; Fri, 17 Feb 2017 00:05:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29DB1294D3; Fri, 17 Feb 2017 00:05:20 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B88CA868AD9FF; Fri, 17 Feb 2017 08:05:16 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v1H85HOf031013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Feb 2017 09:05:18 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v1H85681006769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Feb 2017 08:05:17 GMT Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.227]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Fri, 17 Feb 2017 09:05:11 +0100 From: "Van De Velde, Gunter (Nokia - BE)" To: Susan Hares Thread-Topic: [ALU] Re: [Idr] [spring] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSiPSPHgVYM3zURr+F4Gs1EKSVZg== Date: Fri, 17 Feb 2017 08:05:09 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> In-Reply-To: <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" Subject: Re: [spring] [ALU] Re: [Idr] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:05:23 -0000 --_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIHRoZSBwYXBlciBhbmQgWWVwIEkgc3VwcG9ydA0KDQpHLw0KDQpGcm9tOiBJZHIgPGlk ci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQu aWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgMTYgRmVicnVhcnkgMjAxNyBhdCAxMjow Ng0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQpDYzogImlkckBpZXRmLm9yZyIg PGlkckBpZXRmLm9yZz4sICJzcHJpbmdAaWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbQUxVXSBSZTogW0lkcl0gW3NwcmluZ10gSURSIFdHIDIgd2VlayBXRyBMQyBvbmRyYWZ0 LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUgLSAoMi8xNS8yMDE3IHRvIDMvMS8y MDE3KQ0KDQpZZXMvc3VwcG9ydA0KDQpSZWdhcmRzLA0KSmVmZg0KDQpPbiBGZWIgMTUsIDIwMTcs IGF0IDIzOjM0LCBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6 aC5jb20+PiB3cm90ZToNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIElEUiBXRyBsYXN0IGNhbGwgb24g ZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSBmcm9tICgyLzE1IHRvIDMv MS8yMDE3KSAgICBUaGVyZSBhcmUgdHdvIGltcGxlbWVudGF0aW9ucyBkZXNjcmliZSBvbiB0aGUg d2lraSBhdDoNCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2lkci93aWtpL2RyYWZ0LWlldGYt aWRyLWJncGxzLXNlZ21lbnQtcm91dGluZy1lcGUlMjANCg0KVGhlIHR3byBpbXBsZW1lbnRhdGlv biBhcmUgZnJvbSAgQ2lzY28gSU9TLVhSIHJlbGVhc2UgNi4wLjIgYW5kIENpc2NvIE5leHVzIFN3 aXRjaCBOOTAwMC9OMzAwMCBwbGF0Zm9ybXMgcnVubmluZyBOWC1PUyA3LjAoMylJMSgxKSBvciBn cmVhdGVyLiAgIFRoZSBhdXRob3JzIHdpbGwgaW5kaWNhdGUgb24gdGhlIGxpc3QgYW5kIGluIHRo ZSB3aWtpIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24gOg0KDQoNCjEpICAgICAgIFdlcmUgdGhl c2UgaW1wbGVtZW50YXRpb25zIHNlcGFyYXRlIGltcGxlbWVudGF0aW9ucz8NCg0KMikgICAgICAg V2hhdCB3ZXJlIHRoZSByZXN1bHRzIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RzPw0KDQpU aGlzIHdvcmsgaXMgbGlua2VkIHRvIHRoZSBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctY2VudHJhbC1lcGUgd29yayBpbiB0aGUgU1BSSU5HIFdHLiBCYXNlZCBvbiB0aGUgdHdvIGRy YWZ0cywgdGhlIFdHIHNob3VsZCBtaWdodCBjb25zaWRlcjoNCg0KMSkgICAgICAgSXMgdGhlcmUg bmVlZCBmb3IgdGhpcyB3b3JrIGluIGRlcGxveW1lbnRzIGluIG5ldHdvcmtzLw0KDQoyKSAgICAg ICBJcyB0aGlzIHRlY2huaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbj8NCg0KMykgICAgICAg RG9lcyBpdCBmaXQgd2l0aCB0aGUgc3ByaW5nIGluZm9ybWF0aW9uYWwgZHJhZnQ/DQoNCkZvciB0 aGUgZWFzZSBvZiByZWZlcmVuY2UgdGhlIHdlYiByZWZlcmVuY2VzIGFyZSBiZWxvdzoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQt cm91dGluZy1lcGUvDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUvDQoNClN1ZSBIYXJlcw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5n IGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTI1NDA3NzY7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDk0OTk0Njk0IDEz Njg5NjIwOTggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgljb2xvcjpibGFjazt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEz ODgwNjMzNzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjE5ODAyNzU0NjggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSByZWFkIHRoZSBwYXBlciBhbmQgWWVwIEkg c3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5HLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWRyICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsg b24gYmVoYWxmIG9mIEplZmYgVGFudHN1cmEgJmx0O2plZmZ0YW50LmlldGZAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgMTYgRmVicnVhcnkgMjAxNyBhdCAxMjowNjxi cj4NCjxiPlRvOiA8L2I+U3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8YnI+DQo8 Yj5DYzogPC9iPiZxdW90O2lkckBpZXRmLm9yZyZxdW90OyAmbHQ7aWRyQGlldGYub3JnJmd0Oywg JnF1b3Q7c3ByaW5nQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPltBTFVdIFJlOiBbSWRyXSBbc3ByaW5nXSBJRFIgV0cgMiB3ZWVrIFdH IExDIG9uZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSAtICgyLzE1LzIw MTcgdG8gMy8xLzIwMTcpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ZZXMvc3VwcG9ydDxicj4NCjxicj4NClJlZ2FyZHMsIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkplZmY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBGZWIgMTUsIDIwMTcsIGF0IDIzOjM0LCBTdXNhbiBI YXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGlzIGJlZ2lucyBh IDIgd2VlayBJRFIgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQt cm91dGluZy1lcGUgZnJvbSAoMi8xNSB0byAzLzEvMjAxNykgJm5ic3A7Jm5ic3A7Jm5ic3A7VGhl cmUgYXJlIHR3byBpbXBsZW1lbnRhdGlvbnMgZGVzY3JpYmUgb24gdGhlIHdpa2kgYXQ6DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaWRyL3dp a2kvZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZSUyMCI+aHR0cHM6Ly90 cmFjLmlldGYub3JnL3RyYWMvaWRyL3dpa2kvZHJhZnQtaWV0Zi1pZHItYmdwbHMtc2VnbWVudC1y b3V0aW5nLWVwZSUyMDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPlRoZSB0d28gaW1wbGVtZW50YXRpb24gYXJlIGZyb20NCjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDtDaXNjbw0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7YmFj a2dyb3VuZDp3aGl0ZSI+SU9TLVhSIHJlbGVhc2UgNi4wLjIgYW5kIENpc2NvIE5leHVzIFN3aXRj aCBOOTAwMC9OMzAwMCBwbGF0Zm9ybXMgcnVubmluZyBOWC1PUyA3LjAoMylJMSgxKSBvciBncmVh dGVyLiZuYnNwOyZuYnNwOyBUaGUgYXV0aG9ycyB3aWxsIGluZGljYXRlIG9uIHRoZSBsaXN0IGFu ZCBpbiB0aGUgd2lraSB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIDo8L3NwYW4+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEp PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V2VyZSB0aGVzZSBpbXBsZW1l bnRhdGlvbnMgc2VwYXJhdGUgaW1wbGVtZW50YXRpb25zPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+V2hhdCB3ZXJlIHRoZSByZXN1bHRzIG9mIHRo ZSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RzPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGlzIHdvcmsgaXMgbGlua2VkIHRvIHRoZSBkcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGUgd29yayBpbiB0aGUgU1BSSU5HIFdHLiBCYXNl ZCBvbiB0aGUgdHdvIGRyYWZ0cywgdGhlIFdHIHNob3VsZCBtaWdodCBjb25zaWRlcjogJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm80Ij48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+SXMgdGhlcmUgbmVlZCBmb3IgdGhpcyB3b3JrIGluIGRlcGxveW1l bnRzIGluIG5ldHdvcmtzLw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVs MSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SXMgdGhpcyB0ZWNobmljYWxseSBy ZWFkeSBmb3IgcHVibGljYXRpb24/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPjMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Eb2VzIGl0IGZpdCB3aXRo IHRoZSBzcHJpbmcgaW5mb3JtYXRpb25hbCBkcmFmdD8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Rm9yIHRoZSBlYXNlIG9mIHJlZmVyZW5jZSB0aGUgd2ViIHJl ZmVyZW5jZXMgYXJlIGJlbG93Og0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQtcm91 dGluZy1lcGUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlk ci1iZ3Bscy1zZWdtZW50LXJvdXRpbmctZXBlLzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLWNlbnRyYWwtZXBlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWNlbnRyYWwtZXBlLzwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlN1ZSBIYXJlcyA8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B3307E1244314B2384C6A0BE9BA511AFalcatellucentcom_-- From nobody Fri Feb 17 00:22:02 2017 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 95C791293E4; Fri, 17 Feb 2017 00:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 mw9F6oh7Jgt1; Fri, 17 Feb 2017 00:21:59 -0800 (PST) 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 C5F26128B37; Fri, 17 Feb 2017 00:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13920; q=dns/txt; s=iport; t=1487319718; x=1488529318; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bAIDS1ynbBtZN0BHanpBPwabHjbxGHUETryb0ADXZGQ=; b=MoW3pS73AOqZx0ZC+G8Lu5MvdT5NQUanQze5bkAwawn+5DmI0v2AQmZW dzC0vdJE+rSbuhnja+Q0d4K2rqYSXTLcwQJDmPLcKPEP2z2gxPXntNvcW NJk/1j02g9ivnga9saJBcE3zMHC2p9omOz8Iy7JF0RgPa34vJ5TR4rw/G I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQBmsaZY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9iYYEJB41aohiFLIIMHwEMhSxKAoIWPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?xAgQBAStBCxACAQg7BAcnCxQRAgQBDQWJbA6yUiuLLQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFhkyEb4o5BZwAAYZwiyiRCJMbAR84gQBRFT2EfIFIdYlegQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,171,1484006400"; d="scan'208,217";a="386806449" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 08:21:57 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1H8Lvj5002834 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 08:21:57 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 02:21:57 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Fri, 17 Feb 2017 02:21:57 -0600 From: "Bertrand Duvivier (bduvivie)" To: "Van De Velde, Gunter (Nokia - BE)" , "Susan Hares" Thread-Topic: [Idr] [ALU] Re: [spring] IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) Thread-Index: AQHSiPSg2Nylgmp+6EK0TuDohdN8LKFtUVGA Date: Fri, 17 Feb 2017 08:21:57 +0000 Message-ID: References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.101.83] Content-Type: multipart/alternative; boundary="_000_D4CC701C752F0bduvivieciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" Subject: Re: [spring] [Idr] [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:22:00 -0000 --_000_D4CC701C752F0bduvivieciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fully support, yes. Best Regards Bertrand Duvivier On Feb 15, 2017, at 23:34, Susan Hares > wrote: This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routi= ng-epe from (2/15 to 3/1/2017) There are two implementations describe on= the wiki at: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-ep= e%20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus= Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The a= uthors will indicate on the list and in the wiki the following information = : 1) Were these implementations separate implementations? BD> YES 2) What were the results of the interoperability tests? BD > WORKING This work is linked to the draft-ietf-spring-segment-routing-central-epe wo= rk in the SPRING WG. Based on the two drafts, the WG should might consider: 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? For the ease of reference the web references are below: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-= epe/ Sue Hares _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D4CC701C752F0bduvivieciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AD5ACBC425CC447ACE07A32D53BF0F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Fully support, yes. 

Best Regards Bertrand Duvivier


On Feb 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 wee= k IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 t= o 3/1/2017)    There are two implementations describe on the= wiki at:

ht= tps://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%= 20

 <= /o:p>

The two implementat= ion are from  Cisco IOS-XR release 6= .0.2 and Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1)= or greater.   The authors will indicate on the list and in the w= iki the following information :

 

1)       Were th= ese implementations separate implementations?
BD> YES 

2)       What we= re the results of the interoperability tests?
BD > WORKING

 <= /o:p>

This work is linked= to the draft-ietf-spring-segment-routing-central-epe work in the SPRING WG= . Based on the two drafts, the WG should might consider:  =

1) &nb= sp;     Is there need = for this work in deployments in networks/

2) &nb= sp;     Is this techni= cally ready for publication?

3) &nb= sp;     Does it fit wi= th the spring informational draft?

 <= /o:p>

For the ease of ref= erence the web references are below:

https:/= /datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

ht= tps://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-ep= e/

 <= /o:p>

Sue Hares

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

 --_000_D4CC701C752F0bduvivieciscocom_-- From nobody Fri Feb 17 02:06:15 2017 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 BAA57127078 for ; Fri, 17 Feb 2017 02:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 fZlKoABuV3_S for ; Fri, 17 Feb 2017 02:06:11 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A32C128DF6 for ; Fri, 17 Feb 2017 02:06:11 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id E40B2120323; Fri, 17 Feb 2017 11:06:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id AD8DD18006F; Fri, 17 Feb 2017 11:06:09 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0319.002; Fri, 17 Feb 2017 11:06:09 +0100 From: To: "draft-ietf-spring-segment-routing-central-epe@tools.ietf.org" , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe Thread-Index: AdKF4G16+KsySq9QTpeCirSw76wCBABAgt3gAIiwEYA= Date: Fri, 17 Feb 2017 10:06:08 +0000 Message-ID: <19280_1487325969_58A6CB11_19280_7809_1_53C29892C857584299CBF5D05346208A1ED6928D@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <4687_1486980511_58A1859F_4687_19025_2_53C29892C857584299CBF5D05346208A1ED5D0BC@OPEXCLILM21.corporate.adroot.infra.ftgroup> <11889_1487091414_58A336D6_11889_9328_1_53C29892C857584299CBF5D05346208A1ED60F87@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <11889_1487091414_58A336D6_11889_9328_1_53C29892C857584299CBF5D05346208A1ED60F87@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.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED6928DOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 10:06:14 -0000 --_000_53C29892C857584299CBF5D05346208A1ED6928DOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefano, Thanks for the updated document. -04 address my comments. Thanks. -- Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, February 14, 2017 5:57 PM To: draft-ietf-spring-segment-routing-central-epe@tools.ietf.org Cc: spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ce= ntral-epe Hi Authors, As the document shepherd, please find below a set of comments. Thank you, Regards, Bruno =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Major comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name and descriptors' content are not aligned between draft-ietf-spring-seg= ment-routing-central-epe and draft-ietf-idr-bgpls-segment-routing-epe. Chan= ge seems to come from draft-previdi-idr-bgpls-segment-routing-epe-01.txt Oc= tober 25, 2014. e.g. BGP Egress Peer Engineering or BGP Peer Engineering; PeerNode SID vs P= eer-Node-SID; Node Descriptors vs Local Node Descriptors; Peer Descriptors = vs Remote Node Descriptors; Remote Node Descriptors containing a Router ID = vs not ... Note that this is also not aligned with draft-ietf-spring-segment-routing-1= 0. ---- Security section is empty. ---- Manageability section is empty. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minor Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Terminology: This document uses the term BGP-PE for "Peer Engineering" while the BGP doc= ument (draft-ietf-idr-bgpls-segment-routing-epe-07) use the terme BGP-EPE "= Egress Peer Engineering". A consistent name would be useful. Note also that= PE is already a very popular term for BGP VPNs and stands for Provider Edg= e. Given that both functions may be used on the same network/node, using a = different TLA would seem more user friendly. Note that even this doc use th= e term PE to sometimes refers to "Peer Engineering" and sometimes for "Prov= ider Edge" (e.g. =A71.2). This is confusing. Note that RFC 7855 and draft-ietf-spring-segment-routing-10 use the term "e= gress peer engineering" and "Egress Peer Engineering (EPE)" ---- Proposed: OLD: For editorial reasons, the solution is described for IPv4. A later se= ction describes how the same solution is applicable to IPv6. NEW: For editorial reasons, the solution is described for IPv4 and MPLS SID= . This solution is equally applicable to IPv6 with either MPLS-SR or IPv6 S= R. Given this, section 6 seems useless. --- Abstract "This document is on the informational track." This sentence is probably not required as this is already indicated in the = "Intended Status" of this same page. --- "The solution MUST be applicable to iBGP as well as eBGP peerings." I'm not sure to understand what is meant by "iBGP peering", and how does th= is solution apply to this case. --- OLD: A PeerSet segment to the set of peers (E and F). NEW: A PeerSet segment to the set of peers (E and F) belonging to the same = AS. --- Names of sections 3.1 to 3.5 are very long and not easy to quickly parse. M= ay be they could be shorten. e.g. OLD: BGP-PE Router advertising the Peer D and its PeerNode SID NEW: Peer-Node-SID to D --- In sections 3.x, in order to avoid being to IPv4 specific, may be OLD: IPv4 interface address NEW: IPv4/IPv6 interface address or may be NEW: IP interface address --- Somewhere in the doc (e.g. section 1), may be saying that the solution only= allow TE for outbound traffic, not inbound traffic. This is probably obvio= us for the authors, but may not be to some readers. --- The solution allows advertising a single set of Descriptors with both Peer-= Node-SID and Peer-Set-SID at the same time. (Which is good IMHO). But for P= eer-Adj-SID, it seems to require to advertise another set of Descriptors de= dicated to the Peer-Adj-SID. Why? And it's not clear to me whether this wou= ld be allowed to advertise the 3 types of EPE SIDs (Peer-Node-SID, Peer-Set= -SID and Peer-Adj-SID) at the same time (with a unique set of Descriptors) --- Section 2 would seem a good place to define what is a PeerNode Segment, Pee= rAdj Segment, PeerSet Segment. --- 3.6. Fast Reroute (FRR) "An BGP-PE enabled border router should allocate a FRR backup entry on a pe= r BGP Peering SID basis:" What do you mean by "should"? Is this "SHOULD"? "If multi-hop, backup via the remaining PeerADJ SIDs to the same peer." This is mandating FRR Link protection. What if people want node protection? "1. If multi-hop, backup via the remaining PeerADJ SIDs to the same peer." Do you mean _local_ PeerADJ SID? or may be :s/same peer/same Peer-Node-SID = (as in "2.", it seem restricted to local SID) "2. Else backup via local PeerNode SID to the same AS." Don't you mean backup via the local remaining PeerSet? (Otherwise, what's t= he purpose of PeerSet?) "3. Else pop the PeerNode SID and perform an IP lookup." This node is known to support BGP-EPE. It could possibly learn EPE SID from= other nodes. Why forbidding the use of an EPE SID advertised by another EP= E node? --- =A74.1 "The BGP-PE controller should collect all the paths advertised by all the e= ngineered peers." A reader could understand "paths" as EPE paths, while I think you are refer= ing to IP unicast external routes. BTW, this document never states it's applicability with regards to BGP AFI/= SAFI. A priori, it looks to me that this document is only application to IP= unicast route, i.e. AFI/SAFI 1/1 and 2/1. An possibly to IP labelled route= s assuming the labels are those from the external peer. (AFI/SAFI 1/4 and 2= /4) Could this be indicated somewhere in section 1? --- "Alternatively, Extended Metrics, as defined in [I-D.ietf-isis-te-metric-ex= tensions] could also be advertised using new BGP-LS attributes." What do you mean by "new"? "To be defined"? or "defined in draft-ietf-idr-t= e-pm-bgp"? or else? --- Terminology is not consistent. e.g. "BGP Peering Segments" vs "BGP Peer Seg= ments" Which is the right term? --- "A static IP/MPLS route can be programmed at the host H. The static route would define a destination prefix, a next-hop and a label stack to push. The global property of the IGP Prefix SID is particularly convenient: the same policy could be programmed across hosts connected to different routers." Labels (value) are local, not global, so the last sentence is debatable. Same comment for =A77: " o Ability to deploy the same input policy across hosts connected to di= fferent routers (avail the global property of IGP prefix SIDs)." --- "This RFC3107 policy route "overwrites" an equivalent or less-specific "best path". As the best-path is changed, this EPE input policy option influences the path propagated to the upstream peer/customers." Regarding the last sentence, unfortunately the exact behavior is implementa= tion specific. cf https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-00= #section-5 May be OLD: As the best-path is changed, this EPE input policy option influences t= he path propagated to the upstream peer/customers. NEW: As the best-path is changed, this EPE input policy option may influenc= e the path propagated to the upstream peer/customers. Indeed, implementatio= ns treating the SAFI-1 and SAFI-4 routes for a given prefix as comparable w= ould trigger a BGP WITHDRAW of the SAFI-1 route to them BGP upstream peers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nits: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OLD: set of peers (198.51.100.6 and 192.0.2.2) NEW: set of peers (198.51.100.6 for E and 192.0.2.2 for F) (Motivation: to ease the understanding as most people would not remember al= l IP addresses and they are also not indicated in the figure 1.) --- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Monday, February 13, 2017 11:08 AM To: spring@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-centra= l-epe Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-central-epe-03 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *27th of February*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. Two IPR have been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-e= pe-03 [2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment= -routing-central-epe&submit=3Ddraft ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED6928DOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stefano= ,

&n= bsp;

Thanks = for the updated document.

-04 add= ress my comments.

&n= bsp;

Thanks.=

-- Brun= o

&n= bsp;

From:<= /b> spring [mailto:spring-bounces@ietf.= org] On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, February 14, 2017 5:57 PM
To: draft-ietf-spring-segment-routing-central-epe@tools.ietf.org
Cc: spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-rou= ting-central-epe

 

Hi Authors,

 

As the = document shepherd, please find below a set of comments.

 <= /span>

Thank y= ou,

Regards= ,

Bruno

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Major c= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Name an= d descriptors' content are not aligned between draft-ietf-spring-segment-ro= uting-central-epe and draft-ietf-idr-bgpls-segment-routing-epe. Change seem= s to come from draft-previdi-idr-bgpls-segment-routing-epe-01.txt October 25, 2014.

e.g. BG= P Egress Peer Engineering or BGP Peer Engineering; PeerNode SID vs Peer-Nod= e-SID; Node Descriptors vs Local Node Descriptors; Peer Descriptors vs Remo= te Node Descriptors; Remote Node Descriptors containing a Router ID vs not ...

Note th= at this is also not aligned with draft-ietf-spring-segment-routing-10.

 <= /span>

----

Securit= y section is empty.

 <= /span>

----

Managea= bility section is empty.

 <= /span>

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Minor C= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

Termino= logy:

This do= cument uses the term BGP-PE for "Peer Engineering" while the BGP = document (draft-ietf-idr-bgpls-segment-routing-epe-07) use the terme BGP-EP= E "Egress Peer Engineering". A consistent name would be useful. Note also that PE is already a very popular term for BGP VPNs a= nd stands for Provider Edge. Given that both functions may be used on the s= ame network/node, using a different TLA would seem more user friendly. Note= that even this doc use the term PE to sometimes refers to "Peer Engineering" and sometimes for &= quot;Provider Edge" (e.g. =A71.2). This is confusing.

Note th= at RFC 7855 and draft-ietf-spring-segment-routing-10 use the term "egr= ess peer engineering" and "Egress Peer Engineering (EPE)"

 <= /span>

----

Propose= d:

OLD: Fo= r editorial reasons, the solution is described for IPv4.  A later sect= ion describes how the same solution is applicable to IPv6.

NEW: Fo= r editorial reasons, the solution is described for IPv4 and MPLS SID. This = solution is equally applicable to IPv6 with either MPLS-SR or IPv6 SR.

 <= /span>

Given t= his, section 6 seems useless.

 <= /span>

---

Abstrac= t

"T= his document is on the informational track."

This se= ntence is probably not required as this is already indicated in the "I= ntended Status" of this same page.

 <= /span>

---

"T= he solution MUST be applicable to iBGP as well as eBGP peerings."

I'm not= sure to understand what is meant by "iBGP peering", and how does= this solution apply to this case.

 <= /span>

---

OLD: A = PeerSet segment to the set of peers (E and F).

NEW: A = PeerSet segment to the set of peers (E and F) belonging to the same AS.

 <= /span>

---

Names o= f sections 3.1 to 3.5 are very long and not easy to quickly parse. May be t= hey could be shorten. e.g.

OLD: BG= P-PE Router advertising the Peer D and its PeerNode SID

NEW: Pe= er-Node-SID to D

 <= /span>

---

In sect= ions 3.x, in order to avoid being to IPv4 specific, may be

OLD: IP= v4 interface address

NEW: IP= v4/IPv6 interface address

or may = be NEW: IP interface address

 <= /span>

---

Somewhe= re in the doc (e.g. section 1), may be saying that the solution only allow = TE for outbound traffic, not inbound traffic. This is probably obvious for = the authors, but may not be to some readers.

 <= /span>

---

The sol= ution allows advertising a single set of Descriptors with both Peer-Node-SI= D and Peer-Set-SID at the same time. (Which is good IMHO). But for Peer-Adj= -SID, it seems to require to advertise another set of Descriptors dedicated to the Peer-Adj-SID. Why? And it's no= t clear to me whether this would be allowed to advertise the 3 types of EPE= SIDs (Peer-Node-SID, Peer-Set-SID and Peer-Adj-SID) at the same time (with= a unique set of Descriptors)

 <= /span>

---

Section= 2 would seem a good place to define what is a PeerNode Segment, PeerAdj Se= gment, PeerSet Segment.

 <= /span>

---

3.6.&nb= sp; Fast Reroute (FRR)

 <= /span>

"A= n BGP-PE enabled border router should allocate a FRR backup entry on a per = BGP Peering SID basis:"

What do= you mean by "should"? Is this "SHOULD"?

 <= /span>

"I= f multi-hop, backup via the remaining PeerADJ SIDs to the same peer."<= /span>

This is= mandating FRR Link protection. What if people want node protection?=

 <= /span>

"1= .  If multi-hop, backup via the remaining PeerADJ SIDs to the same pee= r."

Do you = mean _local_ PeerADJ SID? or may be :s/same peer/same Peer-Node-SID (as in = "2.", it seem restricted to local SID)

 <= /span>

"2= .  Else backup via local PeerNode SID to the same AS."

Don't y= ou mean backup via the local remaining PeerSet? (Otherwise, what's the purp= ose of PeerSet?)

 <= /span>

"3= .  Else pop the PeerNode SID and perform an IP lookup."

This no= de is known to support BGP-EPE. It could possibly learn EPE SID from other = nodes. Why forbidding the use of an EPE SID advertised by another EPE node?=

 <= /span>

---

=A74.1<= /span>

"T= he BGP-PE controller should collect all the paths advertised by all the eng= ineered peers."

A reade= r could understand "paths" as EPE paths, while I think you are re= fering to IP unicast external routes.

BTW, th= is document never states it's applicability with regards to BGP AFI/SAFI. A= priori, it looks to me that this document is only application to IP unicas= t route, i.e. AFI/SAFI 1/1 and 2/1. An possibly to IP labelled routes assuming the labels are those from the exte= rnal peer. (AFI/SAFI 1/4 and 2/4) Could this be indicated somewhere in sect= ion 1?

 <= /span>

---

"A= lternatively, Extended Metrics, as defined in [I-D.ietf-isis-te-metric-exte= nsions] could also be advertised using new BGP-LS attributes."<= o:p>

What do= you mean by "new"? "To be defined"? or "defined i= n draft-ietf-idr-te-pm-bgp"? or else?

 <= /span>

---

Termino= logy is not consistent. e.g. "BGP Peering Segments" vs "BGP = Peer Segments" Which is the right term?

 <= /span>

---

 &= nbsp; "A static IP/MPLS route can be programmed at the host H.  T= he static

 &= nbsp; route would define a destination prefix, a next-hop and a label stack=

 &= nbsp; to push.  The global property of the IGP Prefix SID is particula= rly

 &= nbsp; convenient: the same policy could be programmed across hosts

 &= nbsp; connected to different routers."

 &= nbsp;

Labels = (value) are local, not global, so the last sentence is debatable. &nbs= p;

 <= /span>

 <= /span>

Same co= mment for =A77:

"&= nbsp;  o  Ability to deploy the same input policy across hosts co= nnected to different routers (avail the global property of IGP prefix SIDs)= ."

 <= /span>

---

 &= nbsp; "This RFC3107 policy route "overwrites" an equivalent = or less-specific

 &= nbsp; "best path".  As the best-path is changed, this EPE in= put policy

 &= nbsp; option influences the path propagated to the upstream peer/customers.= "

 &= nbsp;

Regardi= ng the last sentence, unfortunately the exact behavior is implementation sp= ecific. cf https://tools.ietf.org/html/draft-ietf-mpls-rfc3107bis-00#section-5

May be<= /span>

OLD: As= the best-path is changed, this EPE input policy option influences the path= propagated to the upstream peer/customers.

NEW: As= the best-path is changed, this EPE input policy option may influence the p= ath propagated to the upstream peer/customers. Indeed, implementations trea= ting the SAFI-1 and SAFI-4 routes for a given prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 ro= ute to them BGP upstream peers.

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nits:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 <= /span>

OLD: se= t of peers (198.51.100.6 and 192.0.2.2)

NEW: se= t of peers (198.51.100.6 for E and 192.0.2.2 for F)

 <= /span>

(Motiva= tion: to ease the understanding as most people would not remember all IP ad= dresses and they are also not indicated in the figure 1.)=

 <= /span>

---

 <= /span>

 <= /span>

From:<= /b> spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Monday, February 13, 2017 11:08 AM
To: spring@ietf.org
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing= -central-epe

 

Hello Working Group,<= o:p>

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-central-epe-03 = [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *27th of February*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

Two IPR have been disclosed = [2].

 

Thank you<= /p>

 

M&B

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-central-epe-0= 3

[2] https://datatracker.ietf.org/ipr/search/?id=3Ddraft-ietf-spring-segment-rou= ting-central-epe&submit=3Ddraft

 

______________________________________________________________________=
___________________________________________________
 
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 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_53C29892C857584299CBF5D05346208A1ED6928DOPEXCLILM21corp_-- From nobody Fri Feb 17 06:27:51 2017 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 B8D51129A9A; Fri, 17 Feb 2017 06:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 JXLsKSiSW7tV; Fri, 17 Feb 2017 06:27:49 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FD5129443; Fri, 17 Feb 2017 06:27:48 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id i10so30868930wrb.0; Fri, 17 Feb 2017 06:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ioVwQBWaOVtAhxQJ+OG6JlRAU6xyUEUzjMbC3mQ+8Ss=; b=j9EDf5Ae7RIMWxLt0QQLLAdhyVEb4m8UpuCrKFMr7HtgqWa/wfYxyMM0sMUmz6M/3l msgJq36PO+MOiKUs/m9Ueeu0gNq9ODvIXmwgC9Asv1i5hUEDqLAgzus4iEWwgjmEbHe5 6deKyP1BRCgqzZxxcIbysbKf6ZGx9g701t057juWVK+k8pdkl0H+UcKIlIGqwoZwx2+5 oP0e6L0UpXydEEQWwQZQZqSVuM00etDQKdaXFRxw4K2OXZmE0uK6D1MeQEuvGzGoirr5 o2fojmXLnC0ZILo4cA40XLZLbfYOYROqyoUkwcJnPeyfCRKmDvW3bO8o/JJZzb2/ST+6 y+EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ioVwQBWaOVtAhxQJ+OG6JlRAU6xyUEUzjMbC3mQ+8Ss=; b=uCk8BTLrKXrLbImKn/Y6wDPeQM5IAVvXlh2PbjhwQ9x3yfGPamaQ3cGhBaR35IrdcF rlse65Hwthn2bNRpwWawRgcSStPrze7vSZ1tbuEJ4eUjlH6k9bVXy7b9/fisNhJnygN4 E2EtVt1uaRErcGKZoO4dVrbLzINmIOr4IW/ntWl2lXdRJ8EaeOVwTWX5C5BQ7axT0lVg U80XK4CWpqMRPnJHgYFcIXveEM+bWLabkbwSPer0EjTxozhyxoWgnEQRBD0uLJPDdptQ GBtXQylogMT0/gU0NpirU/l41OO56x+nL5roQaKOXyATyB6T28OF8B5huyp7xDIqgAWE K1Pg== X-Gm-Message-State: AMke39lYWs8f3/J4mJhhWwdDX3wD3D+0onf/fWd8inLFaI4LLt7CM8rKYvyKvGIV/pKrcA== X-Received: by 10.223.177.134 with SMTP id q6mr6601154wra.83.1487341666984; Fri, 17 Feb 2017 06:27:46 -0800 (PST) Received: from ams-giheron-nitro3.cisco.com ([173.38.220.39]) by smtp.gmail.com with ESMTPSA id k142sm1887664wmg.31.2017.02.17.06.27.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 06:27:46 -0800 (PST) From: Giles Heron Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 17 Feb 2017 14:27:44 +0000 In-Reply-To: To: "Bertrand Duvivier (bduvivie)" References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "idr@ietf.org" , "spring@ietf.org" , Susan Hares , "Van De Velde, Gunter \(Nokia - BE\)" Subject: Re: [spring] [Idr] [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 14:27:51 -0000 --Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Likewise. And it=E2=80=99s worth noting that OpenDaylight has an open-source = implementation of the draft, and interops ok with IOS XR. I may get = around to testing interop with NX-OS also. Giles > On 17 Feb 2017, at 08:21, Bertrand Duvivier (bduvivie) = wrote: >=20 > Fully support, yes.=20 >=20 > Best Regards Bertrand Duvivier >=20 >=20 > On Feb 15, 2017, at 23:34, Susan Hares > wrote: >=20 >> This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) = There are two implementations describe on the wiki at: >> = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-e= pe%20 = >> =20 >> The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco = Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. = The authors will indicate on the list and in the wiki the following = information : >> =20 >> 1) Were these implementations separate implementations? >=20 > BD> YES=20 >> 2) What were the results of the interoperability tests? >=20 > BD > WORKING >> =20 >> This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider: =20 >> 1) Is there need for this work in deployments in networks/ >> 2) Is this technically ready for publication? >> 3) Does it fit with the spring informational draft? >> =20 >> For the ease of reference the web references are below: >> = https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/= = >> = https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central= -epe/ = >> =20 >> Sue Hares=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring = ____________________________= ___________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Likewise.

And it=E2=80=99s worth noting that OpenDaylight has an = open-source implementation of the draft, and interops ok with IOS XR. =  I may get around to testing interop with NX-OS also.

Giles

On 17 Feb 2017, at 08:21, = Bertrand Duvivier (bduvivie) <bduvivie@cisco.com> wrote:

Fully = support, yes. 

Best Regards Bertrand Duvivier


On = Feb 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> wrote:

This = begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) =    There are two implementations describe on the wiki = at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segmen= t-routing-epe%20
 
The two implementation are = from  Cisco IOS-XR release 6.0.2 and = Cisco Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or = greater.   The authors will indicate on the list and in the = wiki the following information :
 
1)       Were these implementations = separate = implementations?
<= span style=3D"font-family: Calibri, sans-serif; font-size: 14px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">
BD> YES 
2)       What were the results of the = interoperability = tests?
BD > WORKING
 
This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider:  
1)       Is there need for this work in = deployments in networks/
2)       Is this technically ready for = publication?
3)       Does it fit with the spring = informational draft?
 
For the ease of reference the web = references are below:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-r= outing-epe/
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-rout= ing-central-epe/
 
Sue Hares 
_______________________________________________spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
= _______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_6243CB72-F4C1-4B7C-9543-2AE3D54858CD-- From nobody Mon Feb 20 16:05:56 2017 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 CC10C129415; Mon, 20 Feb 2017 16:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 K25WuMO4_sdZ; Mon, 20 Feb 2017 16:05:48 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 2ECB112943B; Mon, 20 Feb 2017 16:05:47 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.164.147; From: "Susan Hares" To: "'Giles Heron'" , "'Bertrand Duvivier \(bduvivie\)'" References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <1E319B28-BF06-4BEB-9D27-552530FC21EA@gmail.com> In-Reply-To: Date: Mon, 20 Feb 2017 19:01:27 -0500 Message-ID: <017001d28bd5$a6c85f10$f4591d30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01D28BAB.BDF404C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJT2wOnmfqsL5/KzR2EzWLnKupfBQFcWVRrAi7YyF4ChPeZ0gMNybK2oCcFdmA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, spring@ietf.org, "'Van De Velde, Gunter \(Nokia - BE\)'" Subject: Re: [spring] [Idr] [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 00:05:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0171_01D28BAB.BDF404C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Giles:=20 =20 It would be helpful to fill out the wiki on the =E2=80=9CSHOULD, MAY and = MUSTs=E2=80=9D. If it is easier, you can just send me the answers and = I will post it.=20 =20 Sue=20 =20 From: Giles Heron [mailto:giles.heron@gmail.com]=20 Sent: Friday, February 17, 2017 9:28 AM To: Bertrand Duvivier (bduvivie) Cc: Van De Velde, Gunter (Nokia - BE); Susan Hares; idr@ietf.org; = spring@ietf.org Subject: Re: [spring] [Idr] [ALU] Re: IDR WG 2 week WG LC = ondraft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) =20 Likewise. =20 And it=E2=80=99s worth noting that OpenDaylight has an open-source = implementation of the draft, and interops ok with IOS XR. I may get = around to testing interop with NX-OS also. =20 Giles =20 On 17 Feb 2017, at 08:21, Bertrand Duvivier (bduvivie) = wrote: =20 Fully support, yes.=20 =20 Best Regards Bertrand Duvivier =20 On Feb 15, 2017, at 23:34, Susan Hares < = shares@ndzh.com> wrote: This begins a 2 week IDR WG last call on = draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) = There are two implementations describe on the wiki at: = = https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-= epe%20 =20 The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco = Nexus Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. = The authors will indicate on the list and in the wiki the following = information : =20 1) Were these implementations separate implementations? BD> YES=20 2) What were the results of the interoperability tests? BD > WORKING =20 This work is linked to the draft-ietf-spring-segment-routing-central-epe = work in the SPRING WG. Based on the two drafts, the WG should might = consider: =20 1) Is there need for this work in deployments in networks/ 2) Is this technically ready for publication? 3) Does it fit with the spring informational draft? =20 For the ease of reference the web references are below: = = https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe= / = = https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-centra= l-epe/ =20 Sue Hares=20 _______________________________________________ spring mailing list spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring =20 ------=_NextPart_000_0171_01D28BAB.BDF404C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Giles:

 

It would be helpful to fill out the wiki on the =E2=80=9CSHOULD, MAY = and MUSTs=E2=80=9D.=C2=A0=C2=A0 If it is easier, you can just send me = the answers and I will post it.

 

Sue

 

From:= = Giles Heron [mailto:giles.heron@gmail.com]
Sent: Friday, = February 17, 2017 9:28 AM
To: Bertrand Duvivier = (bduvivie)
Cc: Van De Velde, Gunter (Nokia - BE); Susan Hares; = idr@ietf.org; spring@ietf.org
Subject: Re: [spring] [Idr] = [ALU] Re: IDR WG 2 week WG LC ondraft-ietf-idr-bgpls-segment-routing-epe = - (2/15/2017 to 3/1/2017)

 

Likewise.

 

And it=E2=80=99s worth noting that OpenDaylight has an = open-source implementation of the draft, and interops ok with IOS XR. =  I may get around to testing interop with NX-OS = also.

 

Giles

 

On 17 Feb 2017, at 08:21, Bertrand Duvivier (bduvivie) = <bduvivie@cisco.com> = wrote:

 

Fully = support, yes. 

 =

Best = Regards Bertrand Duvivier

 =


On Feb = 15, 2017, at 23:34, Susan Hares <shares@ndzh.com> = wrote:

This begins a 2 week IDR WG = last call on draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to = 3/1/2017)    There are two implementations describe on = the wiki at:=

 =

The two implementation are = from  Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch = N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater.   = The authors will indicate on the list and in the wiki the following = information :=

 =

1)       Were these implementations = separate implementations?=

BD> = YES 

2)       What were the results of = the interoperability tests?=

BD > = WORKING

 =

This work is linked to the = draft-ietf-spring-segment-routing-central-epe work in the SPRING WG. = Based on the two drafts, the WG should might consider: =  =

1)       Is there need for this work = in deployments in networks/=

2)       Is this technically ready = for publication?=

3)       Does it fit with the spring = informational draft?=

 =

For the ease of reference = the web references are below:=

 =

Sue Hares =

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

___________= ____________________________________
spring mailing list
spring@ietf.org
= https://www.ietf.org/mailman/listinfo/spring

<= /div>

 

------=_NextPart_000_0171_01D28BAB.BDF404C0-- From nobody Tue Feb 21 01:50:58 2017 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 73AB3129604 for ; Tue, 21 Feb 2017 01:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 1W3f5E_OKWbY for ; Tue, 21 Feb 2017 01:50:55 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D28F12959A for ; Tue, 21 Feb 2017 01:50:55 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id A929C1202E5 for ; Tue, 21 Feb 2017 10:50:53 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 8CA52160078 for ; Tue, 21 Feb 2017 10:50:53 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 10:50:53 +0100 From: To: "spring@ietf.org" Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Thread-Index: AdKMJ4Hwg4mKj2LrQwW7nmbydnVyPg== Date: Tue, 21 Feb 2017 09:50:52 +0000 Message-ID: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@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.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED7122EOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 09:50:56 -0000 --_000_53C29892C857584299CBF5D05346208A1ED7122EOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-msdc-02 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *7th of March*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. No IPR has been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02 [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED7122EOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Working Group,

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-msdc-02 [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *7th of March*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

No IPR has been disclosed [2= ].

 

Thank you<= /p>

 

M&B

 

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02

[2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc

 

 

 

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A1ED7122EOPEXCLILM21corp_-- From nobody Tue Feb 21 07:03:02 2017 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 0F80A129BEC for ; Tue, 21 Feb 2017 07:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 cnKkN4-SXvjO for ; Tue, 21 Feb 2017 07:02:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D9012947E for ; Tue, 21 Feb 2017 07:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2196; q=dns/txt; s=iport; t=1487689379; x=1488898979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MhDdMNQNLk6i7wCBXumhMUCJ+XHvPKvULTlBt2/lNOk=; b=J1gB6dVn5OHbt+750nk5x8rPigeAKiKefVMOGV+p3T+isRH79cQIkOBQ mDtVFK1mx8tC2DiD+xX0ZkwMsGa+Kdi+NPldu6cG23njJ6OBbqsa/eRSe NcF38dRfpyI1CKUZEMooz9MOoQwNdpfCatTn+EW/7V1l1MXoXf90FrCNK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQDUVaxY/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQkHjVySFpU0gg0fDYUsSgKCbj8YAQIBAQEBAQEBYh0LhHA?= =?us-ascii?q?BAQEDAQEBGx00CwULAgEIGB4QJwslAQEEDgWJZggOsFuLWAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhkyCBYJqgxeBDxEBHIM0gjEFnAgBhnOLKYF7hRuDUIYokyM?= =?us-ascii?q?BHzh4CFMVPhEBhjZ1iGKBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,190,1484006400"; d="scan'208";a="214805166" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2017 15:02:55 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1LF2rcr031610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 15:02:53 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 10:02:50 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 10:02:50 -0500 From: "Stefano Previdi (sprevidi)" To: "bruno.decraene@orange.com" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Thread-Index: AdKMJ4Hwg4mKj2LrQwW7nmbydnVyPgAVfpGA Date: Tue, 21 Feb 2017 15:02:50 +0000 Message-ID: <4E125039-FE75-49DB-8C58-750D6C3C11D6@cisco.com> References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.254.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C250AB9858EB84BB282C9C653E15A55@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:03:01 -0000 as co-author, I support the publication of this draft. Thanks. s. > On Feb 21, 2017, at 10:50 AM, bruno.decraene@orange.com wrote: >=20 > Hello Working Group, > =20 > This email starts a 2-week Working Group Last Call on draft-ietf-spring-s= egment-routing-msdc-02 [1]. > =20 > Please read the document if you haven't read the most recent version yet,= and send your comments to the list, no later than the *7th of March*. > Note that this is *not only* a call for comments on the document; it is a= lso a call for support (or not) to publish this document as an Informationa= l RFC. > =20 > We have already polled for IPR knowledge on this document and all Authors= have replied. > No IPR has been disclosed [2]. > =20 > Thank you > =20 > M&B > =20 > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02 > [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ie= tf-spring-segment-routing-msdc > =20 > =20 > =20 > =20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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 o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue Feb 21 07:37:32 2017 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 AA3B212950E for ; Tue, 21 Feb 2017 07:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 vmWEJWosilEZ for ; Tue, 21 Feb 2017 07:37:28 -0800 (PST) Received: from relais-inet.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 7A1E8129507 for ; Tue, 21 Feb 2017 07:37:28 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 311BE1203B4 for ; Tue, 21 Feb 2017 16:37:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 1A23080062 for ; Tue, 21 Feb 2017 16:37:27 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Tue, 21 Feb 2017 16:37:26 +0100 From: To: "spring@ietf.org" Thread-Topic: WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Thread-Index: AdKMJ4Hwg4mKj2LrQwW7nmbydnVyPgAMEbFw Date: Tue, 21 Feb 2017 15:37:26 +0000 Message-ID: <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED71F65OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:37:30 -0000 --_000_53C29892C857584299CBF5D05346208A1ED71F65OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi authors, As the document shepherd, I have reviewed the document and have the followi= ng comments. Thanks, Regards, Bruno =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Major comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Section 12 (Manageability) is empty ("TBD") - Section 13 (Security) is empty ("TBD") =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minor Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Section 11 (IANA) is empty ("TBD") - I-D.ietf-spring-segment-routing should probably be a normative reference --- =A71 Term "middle stage" is used twice but is not defined. May be replacing it w= ith the terms Tier-x which are defined. --- =A74.1 --- "all the nodes are allocated the same SRGB" Please expand SRGB on first use, and provides a reference ([I-D.ietf-spring= -segment-routing]) --- =A74.2.1 "BGP-Prefix Attribute" The name of the BGP attribute is "BGP Prefix-SID" and the TLV hosting the i= ndex is "Label-Index" --- =A74.2.1 "Then, Node10 sends the following eBGP3107 update to Node7: . NLRI: 192.0.2.11/32 . Label: 16011" As per RFC 3107, the NLRI is both the IP prefix and the label. Hence, propo= sed :s/NLRI/Prefix or :s/NLRI/IP Prefix (RFC 3107 uses the term "Prefix" but IMHO it implies "IP Prefix") --- =A74.2.1 OLD: it should allocate the label LOCAL-SRGB (16000) + "index" 11 (hence 16= 011) "LOCAL-SRGB" is undefined. I would suggest NEW: it should allocate the label from its own SRGB block, offset by the in= dex received in the BGP Prefix-SID attribute. (16000+11 hence 16011) --- =A77.3 seems very similar to me than =A77.2. e.g. =A77.2: " One particularly interesting instance of performance-aware routing is dynamic fault-avoidance. If some links or devices in the network start discarding packets due to a fault, the end-hosts could detect the path(s) being affected and steer their flows away from the problem spot. Similar logic applies to failure cases where packets get completely black-holed, e.g. when a link goes down." =A77.3 "if in the topology depicted on Figure 1 a link between spine switch Node5 and leaf node Node9 fails, HostA may exclude the segment corresponding to Node5 from the prefix matching the servers under Tier-2 devices Node9." May be =A77.3 should be removed or rephrased to better differentiate its co= ntent compared to =A77.2 --- =A78.1 "The Prefix Segment is a lightweight extension to BGP Labelled Unicast" "Prefix Segment" is loosely (un)defined. draft-ietf-idr-bgp-prefix-sid-04 u= ses the term "BGP-Prefix-SID" or "BGP-Prefix-SID Attribute" Please make a consistent use of the right term in the whole document. --- "Common SRGB" The call for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Pleas= e remove the duplicated text. (e.g. moving all related text to 8.1) --- "=A78 Additional Benefits [...] =A78.4 Incremental Deployments As explained in Section 4.2.5, this design can be deployed incrementally." As the incremental benefit is already discussed at length in =A74.2.5 there= is no need to create a one line section 8.4 as this is not an _additional_= benefit. So either removing =A78.4 or moving =A74.2.5 to 8.4. --- =A710 :/BGP Prefix SID attribute/BGP Prefix-SID attribute Plus may be adding the reference to the IDR document. :/ORIGINATOR_SRGB TLV/Originator SRGB TLV --- =A710 " Specifically, the ORIGINATOR_SRGB TLV in the BGP Prefix SID signals the SRGB of the switch that originated the BGP Prefix Segment. This allows to determine the local label allocated by any switch for any BGP Prefix Segment, despite the lack of a consistent unique SRGB in the domain." The above text is not clear enough for me to understand why and how the ORI= GINATOR_SRGB is used. I find the text in the IDR draft a little more clear. "It is used to build = SRTE policies when different SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc])."= Which is a pity given that the IDR draft refers to the SPRING draft for th= e reason and the use. So please rephrase/elaborate. On a side note, I would not call this node a "switch" which for me is a lay= er 2 devices (e.g. Ethernet). I'd rather use the term router or LSR (or (eg= ress) LER) And I fail see the relation with the title "Alternative options" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nits: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In figure 1 and 2, Node10 diagram outrun the box. :s/ 10 |/10 | --- "In other words, per-flow ECMP that does not perform efficiently when flow = life-time distribution is heavy-tailed." may be :s/that does/does --- "Referring to Figure 1Referring to Figure 1" duplicated. --- "In the MPLS case, we do not recommend to use different SRGBs at each node." May be avoiding (double) negation when positive statement is meant . e.g. N= EW: In the MPLS case, we do recommend to use same SRGBs at each node From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, February 21, 2017 10:51 AM To: spring@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-msdc-02 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *7th of March*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. No IPR has been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02 [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED71F65OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi auth= ors,

&n= bsp;

As the = document shepherd, I have reviewed the document and have the following comm= ents.

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Major c= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- Secti= on 12 (Manageability) is empty ("TBD")

- Secti= on 13 (Security) is empty ("TBD")

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Minor C= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- Secti= on 11 (IANA) is empty ("TBD")

- I-D.i= etf-spring-segment-routing should probably be a normative reference

&n= bsp;

---

=A71

Term &q= uot;middle stage" is used twice but is not defined. May be replacing i= t with the terms Tier-x which are defined.

&n= bsp;

---

=A74.1<= o:p>

&n= bsp;

---

"a= ll the nodes are allocated the same SRGB"

Please = expand SRGB on first use, and provides a reference ([I-D.ietf-spring-segmen= t-routing])

&n= bsp;

---

=A74.2.= 1

"B= GP-Prefix Attribute"

The nam= e of the BGP attribute is "BGP Prefix-SID" and the TLV hosting th= e index is "Label-Index"

&n= bsp;

---

=A74.2.= 1

&n= bsp;

"T= hen, Node10 sends the following eBGP3107 update to Node7:=

&n= bsp;

 &= nbsp; . NLRI:  192.0.2.11/32

 &= nbsp; . Label: 16011"

 &= nbsp;

As per = RFC 3107, the NLRI is both the IP prefix and the label. Hence, proposed

:s/NLRI= /Prefix

or :s/N= LRI/IP Prefix

&n= bsp;

(RFC 31= 07 uses the term "Prefix" but IMHO it implies "IP Prefix&quo= t;)

&n= bsp;

---

=A74.2.= 1

&n= bsp;

OLD: it= should allocate the label LOCAL-SRGB (16000) + "index" 11 (h= ence 16011)

"L= OCAL-SRGB" is undefined. I would suggest

NEW: it= should allocate the label from its own SRGB block, offset by the index rec= eived in the BGP Prefix-SID attribute. (16000+11 hence 16011)

&n= bsp;

---

=A77.3 = seems very similar to me than =A77.2. e.g.

&n= bsp;

=A77.2:=

"&= nbsp; One particularly interesting instance of performance-aware routing is=

 &= nbsp; dynamic fault-avoidance.  If some links or devices in the networ= k

 &= nbsp; start discarding packets due to a fault, the end-hosts could detect

 &= nbsp; the path(s) being affected and steer their flows away from the

 &= nbsp; problem spot.  Similar logic applies to failure cases where pack= ets

 &= nbsp; get completely black-holed, e.g. when a link goes down."

&n= bsp;

=A77.3<= o:p>

"i= f in the topology depicted on

 &= nbsp; Figure 1 a link between spine switch Node5 and leaf node Node9 fails,=

 &= nbsp; HostA may exclude the segment corresponding to Node5 from the prefix<= o:p>

 &= nbsp; matching the servers under Tier-2 devices Node9."

&n= bsp;

May be = =A77.3 should be removed or rephrased to better differentiate its content c= ompared to =A77.2  

&n= bsp;

---

=A78.1&= nbsp;

"T= he Prefix Segment is a lightweight extension to BGP Labelled Unicast"<= o:p>

"P= refix Segment" is loosely (un)defined. draft-ietf-idr-bgp-prefix-sid-0= 4 uses the term "BGP-Prefix-SID" or "BGP-Prefix-SID Attribut= e"

&n= bsp;

Please = make a consistent use of the right term in the whole document.

&n= bsp;

---

"C= ommon SRGB"  

The cal= l for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Please remov= e the duplicated text. (e.g. moving all related text to 8.1)

&n= bsp;

---

"= =A78 Additional Benefits

[...]

=A78.4 = Incremental Deployments

As expl= ained in Section 4.2.5, this design can be deployed incrementally."

&n= bsp;

As the = incremental benefit is already discussed at length in =A74.2.5 there is no = need to create a one line section 8.4 as this is not an _additional_ benefi= t.

&n= bsp;

So eith= er removing =A78.4 or moving =A74.2.5 to 8.4.

&n= bsp;

---

=A710

:/BGP P= refix SID attribute/BGP Prefix-SID attribute

&n= bsp;

Plus ma= y be adding the reference to the IDR document.

&n= bsp;

:/ORIGI= NATOR_SRGB TLV/Originator SRGB TLV

&n= bsp;

---

=A710

"&= nbsp;  Specifically, the ORIGINATOR_SRGB TLV in the BGP Prefix SID sig= nals

 &= nbsp; the SRGB of the switch that originated the BGP Prefix Segment.

&n= bsp;

 &= nbsp; This allows to determine the local label allocated by any switch for<= o:p>

 &= nbsp; any BGP Prefix Segment, despite the lack of a consistent unique SRGB<= o:p>

 &= nbsp; in the domain."

 &= nbsp;

The abo= ve text is not clear enough for me to understand why and how the ORIGINATOR= _SRGB is used.

I find = the text in the IDR draft a little more clear. "It is used to build SR= TE policies when different

 &= nbsp; SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc]= )." Which is a pity given that the IDR draft refers to the SPRING draf= t for the reason and the use.

 &= nbsp;

So plea= se rephrase/elaborate.

&n= bsp;

On a si= de note, I would not call this node a "switch" which for me is a = layer 2 devices (e.g. Ethernet). I'd rather use the term router or LSR (or = (egress) LER)

&n= bsp;

And I f= ail see the relation with the title "Alternative options" &n= bsp;

&n= bsp;

 &= nbsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nits:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In figu= re 1 and 2, Node10 diagram outrun the box. :s/ 10  |/10  |

&n= bsp;

---

"I= n other words, per-flow ECMP that does not perform efficiently when flow li= fe-time distribution is heavy-tailed."

&n= bsp;

may be = :s/that does/does

&n= bsp;

---

"R= eferring to Figure 1Referring to Figure 1"

&n= bsp;

duplica= ted.

&n= bsp;

---

"I= n the MPLS case, we do not recommend to use different SRGBs at each node.&q= uot;

May be = avoiding (double) negation when positive statement is meant . e.g. NEW: In = the MPLS case, we do recommend to use same SRGBs at each node

&n= bsp;

&n= bsp;

&n= bsp;

From:<= /b> spring [mailto:spring-bounces@ietf.= org] On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, February 21, 2017 10:51 AM
To: spring@ietf.org
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing= -msdc-02

 

Hello Working Group,

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-msdc-02 [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *7th of March*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

No IPR has been disclosed [2= ].

 

Thank you<= /p>

 

M&B

 

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02

[2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc

 

 

 

 

______________________________________________________________________=
___________________________________________________
 
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_53C29892C857584299CBF5D05346208A1ED71F65OPEXCLILM21corp_-- From nobody Wed Feb 22 01:10:42 2017 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 96FA21293DF; Wed, 22 Feb 2017 01:10:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148775464061.16950.14135721423957292752.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2017 01:10:40 -0800 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-06.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 09:10:40 -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 of the IETF. Title : A Scalable and Topology-Aware MPLS Dataplane Monitoring System Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-06.txt Pages : 16 Date : 2017-02-22 Abstract: This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and LSP path trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 22 03:02:11 2017 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 6C5A912968C; Wed, 22 Feb 2017 03:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enVLvw-LO78r; Wed, 22 Feb 2017 03:02:06 -0800 (PST) Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A9A1296D0; Wed, 22 Feb 2017 03:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1487761325; x=1519297325; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wUiN/oDkHQW5ij9QSOOclYbV/FWFA5RiF/hvexSgZms=; b=17m5k644/4je0gynBquD9G1yqjWdbiGAstmnPaRVT6ijHyboT3ukpJOg AJJEp8bCZKHoZQX9SDppbRuXj3x2hBqHpCBMakzppfn25TIchJBAqrhHx c5KdweCJaRd8sU78mgEaY6popffuxHPhP7jQ76T9egzQE3qz8tVPWB4HK kRwyvFl15RBdDzG3mT+G3Ln2c1D63CnrsWyH/54EqdmoZYa+c/EZbwjhr +StHj2OANMVs1AyhLt3HOwbNGL4d6Oig5LfDQkwWnaqaHL3f6kh91O0e+ SJ0dUYJl1K4HWkX5BWZ2Jfjxh/u+la6yWkdND7qJ9QEMcM85IMOUW05th A==; Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 22 Feb 2017 12:02:01 +0100 X-IronPort-AV: E=Sophos;i="5.35,193,1484002800"; d="scan'208,217";a="1131420564" Received: from he101659.emea1.cds.t-internal.com ([10.134.226.19]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2017 12:01:59 +0100 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101659.emea1.cds.t-internal.com (10.134.226.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 22 Feb 2017 12:01:54 +0100 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Wed, 22 Feb 2017 12:01:54 +0100 From: To: Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbgNDdW3AAKavA0AAzyNMcAHw1UTw Date: Wed, 22 Feb 2017 11:01:54 +0000 Message-ID: References: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com> <25080_1486748722_589DFC32_25080_2438_1_53C29892C857584299CBF5D05346208A1ED56C59@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <25080_1486748722_589DFC32_25080_2438_1_53C29892C857584299CBF5D05346208A1ED56C59@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.162.124] Content-Type: multipart/alternative; boundary="_000_d316aa2f39ec49e38b22e5afa414227eHE101653emea1cdstintern_" MIME-Version: 1.0 Archived-At: Cc: spring@ietf.org, spring-chairs@ietf.org, draft-ietf-spring-oam-usecase@ietf.org Subject: Re: [spring] draft-ietf-spring-oam-usecase - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 11:02:09 -0000 --_000_d316aa2f39ec49e38b22e5afa414227eHE101653emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bruno, thanks for your new review. I've tried to adapt text and deleted the relate= d sections below. In some cases, I didn't change text, that's discussed below (marked [RG]). Regards, Ruediger Name: draft-ietf-spring-oam-usecase Revision: 06 Title: A Scalable and Topology-Aware MPLS Dataplane Monitoring S= ystem Document date: 2017-02-21 Group: spring Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-oam-= usecase-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usec= ase/ Htmlized: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-0= 6 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-oam-u= secase-06 Von: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Gesendet: Freitag, 10. Februar 2017 18:45 An: Geib, R=FCdiger Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-chairs@= ietf.org Betreff: RE: draft-ietf-spring-oam-usecase - shepherd review Hi Ruediger, Thanks for the answer and the updated draft which is indeed improved. Reading the new version, I have additional comments below: --- Idnits report 1 issue: "=3D=3D It seems as if not all pages are separated b= y form feeds - found 0 form feeds but 16 pages" https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-oam-usecase-05.txt [RG] The document is edited in xml using an IETF template and uses the xml = to txt conversion of IETF. I can contact the rfc editor and/or tool author. I'd prefer the RFC editor to sol= ve the issue or give me guidance. [snip] --- =A75.1 " Finally, the PMS sets up and sends packets to monitor connectivity of the ECMP routed paths. The PMS does this by creating a measurement packet with the following label stack (top to bottom): 20 - 30 - 10. The ping packets reliably use the monitored path, if the IP-address information which has been detected by the MPLS trace route is used as the IP destination address (note that this IP address isn't used or required for any IP routing)." >From the first sentence, I'm understanding that the traceroute part is fini= shed and now, end to end monitoring packets are sent using the regualr MPLS= dataplane. In such context, I'm not following the latest sentence. You are saying that the PMS sends a measurement packet with label stack 20 = - 30 - 10 and IP destination address previously detected. For me, such measurement packet will follow the path LERi (20), LERj (30), = PMS (10). A priori the PSM will send capture back the packet, hence this pa= cket will not be forwarded using the IP destination address. So why is this= IP destination address important? [RG] I added a reference to Downstream Mapping information / RFC4379 in the= section, as your question is answered there. I think, a detailed explanation of how to apply= the RFC4379 tool set to monitor an MPLS network should be part of a separate document, if th= ere's community interest. Thanks, Regards, Bruno --_000_d316aa2f39ec49e38b22e5afa414227eHE101653emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brun= o,

&n= bsp;

thanks = for your new review. I’ve tried to adapt text and deleted the related= sections below.

In some= cases, I didn’t change text, that’s discussed below (marked [R= G]).

&n= bsp;

Regards, Ruediger=

 

Name:    = ;   draft-ietf-spring-oam-usecase

Revision:   06

Title:   &nbs= p;        A Scalable and Topology-Aware = MPLS Dataplane Monitoring System

Document date:  &n= bsp; 2017-02-21

Group:   &nbs= p;        spring

Pages:   &nbs= p;        16

URL:    =         https://www.ietf.org/internet-drafts/draft-ietf-spring-oam-usecase-0= 6.txt

Status:   &nb= sp;     https://datatracke= r.ietf.org/doc/draft-ietf-spring-oam-usecase/

Htmlized:   &= nbsp;   https://tools.ietf.org/html/dra= ft-ietf-spring-oam-usecase-06

Diff:       &n= bsp;   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-oam-usecase-06

 

 

Von: bruno.dec= raene@orange.com [mailto:bruno.decraene@orange.com]
Gesendet: Freitag, 10. Februar 2017 18:45
An: Geib, R=FCdiger
Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-= chairs@ietf.org
Betreff: RE: draft-ietf-spring-oam-usecase - shepherd review

 

Hi Rued= iger,

 <= /span>

Thanks = for the answer and the updated draft which is indeed improved.

 <= /span>

Reading= the new version, I have additional comments below:

 <= /span>

 <= /span>

---

Idnits = report 1 issue: "=3D=3D It seems as if not all pages are separated by = form feeds - found 0 form feeds but 16 pages"

https://tools.ietf.org/idnits?url=3Dhttps://to= ols.ietf.org/id/draft-ietf-spring-oam-usecase-05.txt

 <= /span>

[RG] Th= e document is edited in xml using an IETF template and uses the xml to txt = conversion of IETF. I can

contact= the rfc editor and/or tool author. I’d prefer the RFC editor to solv= e the issue or give me guidance.

&n= bsp;

&n= bsp;

[snip]<= /span>

---

=A75.1<= /span>

" = Finally, the PMS sets up and sends packets to monitor

 &= nbsp; connectivity of the ECMP routed paths.  The PMS does this by cre= ating

 &= nbsp; a measurement packet with the following label stack (top to bottom):<= /span>

 &= nbsp; 20 - 30 - 10.  The ping packets reliably use the monitored path,= if

 &= nbsp; the IP-address information which has been detected by the MPLS trace<= /span>

 &= nbsp; route is used as the IP destination address (note that this IP=

 &= nbsp; address isn't used or required for any IP routing)."

 &= nbsp;

From th= e first sentence, I'm understanding that the traceroute part is finished an= d now, end to end monitoring packets are sent using the regualr MPLS datapl= ane. In such context, I'm not following the latest sentence.

You are= saying that the PMS sends a measurement packet with label stack 20 - 30 - = 10 and IP destination address previously detected.

For me,= such measurement packet will follow the path LERi (20), LERj (30), PMS (10= ). A priori the PSM will send capture back the packet, hence this packet wi= ll not be forwarded using the IP destination address. So why is this IP destination address important? 

 <= /span>

[RG] I = added a reference to Downstream Mapping information / RFC4379 in the sectio= n, as your

questio= n is answered there. I think, a detailed explanation of how to apply the RF= C4379 tool

set to = monitor an MPLS network should be part of a separate document, if thereR= 17;s community interest.

 &= nbsp;=

Thanks,=

Regards= ,

Bruno

--_000_d316aa2f39ec49e38b22e5afa414227eHE101653emea1cdstintern_-- From nobody Wed Feb 22 05:00:25 2017 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 DACE31297F3 for ; Wed, 22 Feb 2017 05:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 H-u9HqqSgb9b for ; Wed, 22 Feb 2017 05:00:20 -0800 (PST) Received: from relais-inet.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 D601A1297CE for ; Wed, 22 Feb 2017 05:00:19 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 092631607C6 for ; Wed, 22 Feb 2017 14:00:18 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id DE23AC0060 for ; Wed, 22 Feb 2017 14:00:17 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 14:00:17 +0100 From: To: "spring@ietf.org" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Thread-Index: AdKMJ4Hwg4mKj2LrQwW7nmbydnVyPgAMEbFwAAEo+2A= Date: Wed, 22 Feb 2017 13:00:17 +0000 Message-ID: <15606_1487768417_58AD8B61_15606_5807_1_53C29892C857584299CBF5D05346208A1ED74B4A@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@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.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED74B4AOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:00:23 -0000 --_000_53C29892C857584299CBF5D05346208A1ED74B4AOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find below some additional points 1) "Abstract This document describes the motivation and benefits for applying segment routing in the data-center. It describes the design to deploy segment routing in the data-center, for both the MPLS and IPv6 dataplanes. =BB It looks to me that this document is limited to BGP-based large-scale data-= center (DC) design described in [RFC7938]. So may be :s/ the data-center./ BGP-based large-scale data-center. :s/ in the data-center,/ in those data-center, 2) For the document write up, are there any known deployment of draft-= ietf-spring-segment-routing-msdc? 3) =A7 2.1. Reference design " o Each node is its own AS (Node X has AS X) * For simple and efficient route propagation filtering, Nodes 5, 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS, Nodes 9 and 10 share the same AS. * For efficient usage of the scarce 2-byte Private Use AS pool, different Tier-3 nodes might share the same AS. * Without loss of generality, we will simplify these details in this document and assume that each node has its own AS." First 2 bullets are contradicting each other's. Please update/rephrase as needed. 4) [I-D.ietf-idr-bgp-prefix-sid] could be seen as a normative docum= ent. IDR WG is also initiating the WG last call, hence both document could = progress together. Thanks, Regards, Bruno From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, February 21, 2017 4:37 PM To: spring@ietf.org Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-ms= dc-02 Hi authors, As the document shepherd, I have reviewed the document and have the followi= ng comments. Thanks, Regards, Bruno =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Major comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Section 12 (Manageability) is empty ("TBD") - Section 13 (Security) is empty ("TBD") =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minor Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Section 11 (IANA) is empty ("TBD") - I-D.ietf-spring-segment-routing should probably be a normative reference --- =A71 Term "middle stage" is used twice but is not defined. May be replacing it w= ith the terms Tier-x which are defined. --- =A74.1 --- "all the nodes are allocated the same SRGB" Please expand SRGB on first use, and provides a reference ([I-D.ietf-spring= -segment-routing]) --- =A74.2.1 "BGP-Prefix Attribute" The name of the BGP attribute is "BGP Prefix-SID" and the TLV hosting the i= ndex is "Label-Index" --- =A74.2.1 "Then, Node10 sends the following eBGP3107 update to Node7: . NLRI: 192.0.2.11/32 . Label: 16011" As per RFC 3107, the NLRI is both the IP prefix and the label. Hence, propo= sed :s/NLRI/Prefix or :s/NLRI/IP Prefix (RFC 3107 uses the term "Prefix" but IMHO it implies "IP Prefix") --- =A74.2.1 OLD: it should allocate the label LOCAL-SRGB (16000) + "index" 11 (hence 16= 011) "LOCAL-SRGB" is undefined. I would suggest NEW: it should allocate the label from its own SRGB block, offset by the in= dex received in the BGP Prefix-SID attribute. (16000+11 hence 16011) --- =A77.3 seems very similar to me than =A77.2. e.g. =A77.2: " One particularly interesting instance of performance-aware routing is dynamic fault-avoidance. If some links or devices in the network start discarding packets due to a fault, the end-hosts could detect the path(s) being affected and steer their flows away from the problem spot. Similar logic applies to failure cases where packets get completely black-holed, e.g. when a link goes down." =A77.3 "if in the topology depicted on Figure 1 a link between spine switch Node5 and leaf node Node9 fails, HostA may exclude the segment corresponding to Node5 from the prefix matching the servers under Tier-2 devices Node9." May be =A77.3 should be removed or rephrased to better differentiate its co= ntent compared to =A77.2 --- =A78.1 "The Prefix Segment is a lightweight extension to BGP Labelled Unicast" "Prefix Segment" is loosely (un)defined. draft-ietf-idr-bgp-prefix-sid-04 u= ses the term "BGP-Prefix-SID" or "BGP-Prefix-SID Attribute" Please make a consistent use of the right term in the whole document. --- "Common SRGB" The call for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Pleas= e remove the duplicated text. (e.g. moving all related text to 8.1) --- "=A78 Additional Benefits [...] =A78.4 Incremental Deployments As explained in Section 4.2.5, this design can be deployed incrementally." As the incremental benefit is already discussed at length in =A74.2.5 there= is no need to create a one line section 8.4 as this is not an _additional_= benefit. So either removing =A78.4 or moving =A74.2.5 to 8.4. --- =A710 :/BGP Prefix SID attribute/BGP Prefix-SID attribute Plus may be adding the reference to the IDR document. :/ORIGINATOR_SRGB TLV/Originator SRGB TLV --- =A710 " Specifically, the ORIGINATOR_SRGB TLV in the BGP Prefix SID signals the SRGB of the switch that originated the BGP Prefix Segment. This allows to determine the local label allocated by any switch for any BGP Prefix Segment, despite the lack of a consistent unique SRGB in the domain." The above text is not clear enough for me to understand why and how the ORI= GINATOR_SRGB is used. I find the text in the IDR draft a little more clear. "It is used to build = SRTE policies when different SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc])."= Which is a pity given that the IDR draft refers to the SPRING draft for th= e reason and the use. So please rephrase/elaborate. On a side note, I would not call this node a "switch" which for me is a lay= er 2 devices (e.g. Ethernet). I'd rather use the term router or LSR (or (eg= ress) LER) And I fail see the relation with the title "Alternative options" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nits: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In figure 1 and 2, Node10 diagram outrun the box. :s/ 10 |/10 | --- "In other words, per-flow ECMP that does not perform efficiently when flow = life-time distribution is heavy-tailed." may be :s/that does/does --- "Referring to Figure 1Referring to Figure 1" duplicated. --- "In the MPLS case, we do not recommend to use different SRGBs at each node." May be avoiding (double) negation when positive statement is meant . e.g. N= EW: In the MPLS case, we do recommend to use same SRGBs at each node From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Tuesday, February 21, 2017 10:51 AM To: spring@ietf.org Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Hello Working Group, This email starts a 2-week Working Group Last Call on draft-ietf-spring-seg= ment-routing-msdc-02 [1]. Please read the document if you haven't read the most recent version yet, a= nd send your comments to the list, no later than the *7th of March*. Note that this is *not only* a call for comments on the document; it is als= o a call for support (or not) to publish this document as an Informational = RFC. We have already polled for IPR knowledge on this document and all Authors h= ave replied. No IPR has been disclosed [2]. Thank you M&B [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02 [2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A1ED74B4AOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please = find below some additional points

&n= bsp;

1)      “Abst= ract

 

   This d= ocument describes the motivation and benefits for applying

   segmen= t routing in the data-center.  It describes the design to

   deploy= segment routing in the data-center, for both the MPLS and IPv6<= /span>

   dataplanes. =BB

 

It look= s to me that this document is limited to BGP-based large-scale data-center&= nbsp; (DC) design described in [RFC7938].

So may = be

:s/ the= data-center./ BGP-based large-scale data-center.

:s/ in = the data-center,/ in those data-center,

&n= bsp;

= 2)      For the document write up, are there any known deployment of draft-ietf-sp= ring-segment-routing-msdc?


= 3)      =A7 2.1.  Reference design

“=    o  Each node is its own AS (Node X has AS X)

&n= bsp;

 &= nbsp;    *  For simple and efficient route propagation = filtering, Nodes 5,

 &= nbsp;       6, 7 and 8 share the same AS, Nod= es 3 and 4 share the same AS,

 &= nbsp;       Nodes 9 and 10 share the same AS.=

&n= bsp;

 &= nbsp;    *  For efficient usage of the scarce 2-byte Pr= ivate Use AS pool,

 &= nbsp;       different Tier-3 nodes might shar= e the same AS.

&n= bsp;

 &= nbsp;    *  Without loss of generality, we will simplif= y these details in

 &= nbsp;       this document and assume that eac= h node has its own AS.”

&n= bsp;

&n= bsp;

First 2= bullets are contradicting each other’s.

Please = update/rephrase as needed.

&n= bsp;

4)        = ; [I-D.ietf-idr-bgp-prefix= -sid] could be seen as a norm= ative document. IDR WG is also initiating the WG last call, hence both docu= ment could progress together.<= /o:p>

 

Thanks,=

Regards= ,

Bruno

&n= bsp;

&n= bsp;

&n= bsp;

sprin= g [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, February 21, 2017 4:37 PM
To: spring@ietf.org
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-rou= ting-msdc-02

 

Hi auth= ors,

 <= /span>

As the = document shepherd, I have reviewed the document and have the following comm= ents.

 <= /span>

Thanks,=

Regards= ,

Bruno

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Major c= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- Secti= on 12 (Manageability) is empty ("TBD")

- Secti= on 13 (Security) is empty ("TBD")

 <= /span>

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Minor C= omment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

- Secti= on 11 (IANA) is empty ("TBD")

- I-D.i= etf-spring-segment-routing should probably be a normative reference<= o:p>

 <= /span>

---

=A71

Term &q= uot;middle stage" is used twice but is not defined. May be replacing i= t with the terms Tier-x which are defined.

 <= /span>

---

=A74.1<= /span>

 <= /span>

---

"a= ll the nodes are allocated the same SRGB"

Please = expand SRGB on first use, and provides a reference ([I-D.ietf-spring-segmen= t-routing])

 <= /span>

---

=A74.2.= 1

"B= GP-Prefix Attribute"

The nam= e of the BGP attribute is "BGP Prefix-SID" and the TLV hosting th= e index is "Label-Index"

 <= /span>

---

=A74.2.= 1

 <= /span>

"T= hen, Node10 sends the following eBGP3107 update to Node7:=

 <= /span>

 &= nbsp; . NLRI:  192.0.2.11/32

 &= nbsp; . Label: 16011"

 &= nbsp;

As per = RFC 3107, the NLRI is both the IP prefix and the label. Hence, proposed

:s/NLRI= /Prefix

or :s/N= LRI/IP Prefix

 <= /span>

(RFC 31= 07 uses the term "Prefix" but IMHO it implies "IP Prefix&quo= t;)

 <= /span>

---

=A74.2.= 1

 <= /span>

OLD: it= should allocate the label LOCAL-SRGB (16000) + "index" 11 (h= ence 16011)

"L= OCAL-SRGB" is undefined. I would suggest

NEW: it= should allocate the label from its own SRGB block, offset by the index rec= eived in the BGP Prefix-SID attribute. (16000+11 hence 16011)

 <= /span>

---

=A77.3 = seems very similar to me than =A77.2. e.g.

 <= /span>

=A77.2:=

"&= nbsp; One particularly interesting instance of performance-aware routing is=

 &= nbsp; dynamic fault-avoidance.  If some links or devices in the networ= k

 &= nbsp; start discarding packets due to a fault, the end-hosts could detect

 &= nbsp; the path(s) being affected and steer their flows away from the=

 &= nbsp; problem spot.  Similar logic applies to failure cases where pack= ets

 &= nbsp; get completely black-holed, e.g. when a link goes down."<= o:p>

 <= /span>

=A77.3<= /span>

"i= f in the topology depicted on

 &= nbsp; Figure 1 a link between spine switch Node5 and leaf node Node9 fails,=

 &= nbsp; HostA may exclude the segment corresponding to Node5 from the prefix<= /span>

 &= nbsp; matching the servers under Tier-2 devices Node9."

 <= /span>

May be = =A77.3 should be removed or rephrased to better differentiate its content c= ompared to =A77.2  

 <= /span>

---

=A78.1&= nbsp;

"T= he Prefix Segment is a lightweight extension to BGP Labelled Unicast"<= /span>

"P= refix Segment" is loosely (un)defined. draft-ietf-idr-bgp-prefix-sid-0= 4 uses the term "BGP-Prefix-SID" or "BGP-Prefix-SID Attribut= e"

 <= /span>

Please = make a consistent use of the right term in the whole document.<= /o:p>

 <= /span>

---

"C= ommon SRGB"  

The cal= l for a common SRGB is duplicated in section 4.1, 4.2 and 8.1. Please remov= e the duplicated text. (e.g. moving all related text to 8.1)

 <= /span>

---

"= =A78 Additional Benefits

[...]

=A78.4 = Incremental Deployments

As expl= ained in Section 4.2.5, this design can be deployed incrementally."

 <= /span>

As the = incremental benefit is already discussed at length in =A74.2.5 there is no = need to create a one line section 8.4 as this is not an _additional_ benefi= t.

 <= /span>

So eith= er removing =A78.4 or moving =A74.2.5 to 8.4.

 <= /span>

---

=A710

:/BGP P= refix SID attribute/BGP Prefix-SID attribute

 <= /span>

Plus ma= y be adding the reference to the IDR document.

 <= /span>

:/ORIGI= NATOR_SRGB TLV/Originator SRGB TLV

 <= /span>

---

=A710

"&= nbsp;  Specifically, the ORIGINATOR_SRGB TLV in the BGP Prefix SID sig= nals

 &= nbsp; the SRGB of the switch that originated the BGP Prefix Segment.=

 <= /span>

 &= nbsp; This allows to determine the local label allocated by any switch for<= /span>

 &= nbsp; any BGP Prefix Segment, despite the lack of a consistent unique SRGB<= /span>

 &= nbsp; in the domain."

 &= nbsp;

The abo= ve text is not clear enough for me to understand why and how the ORIGINATOR= _SRGB is used.

I find = the text in the IDR draft a little more clear. "It is used to build SR= TE policies when different

 &= nbsp; SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc]= )." Which is a pity given that the IDR draft refers to the SPRING draf= t for the reason and the use.

 &= nbsp;

So plea= se rephrase/elaborate.

 <= /span>

On a si= de note, I would not call this node a "switch" which for me is a = layer 2 devices (e.g. Ethernet). I'd rather use the term router or LSR (or = (egress) LER)

 <= /span>

And I f= ail see the relation with the title "Alternative options" &n= bsp;

 <= /span>

 &= nbsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nits:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In figu= re 1 and 2, Node10 diagram outrun the box. :s/ 10  |/10  |=

 <= /span>

---

"I= n other words, per-flow ECMP that does not perform efficiently when flow li= fe-time distribution is heavy-tailed."

 <= /span>

may be = :s/that does/does

 <= /span>

---

"R= eferring to Figure 1Referring to Figure 1"

 <= /span>

duplica= ted.

 <= /span>

---

"I= n the MPLS case, we do not recommend to use different SRGBs at each node.&q= uot;

May be = avoiding (double) negation when positive statement is meant . e.g. NEW: In = the MPLS case, we do recommend to use same SRGBs at each node

 <= /span>

 <= /span>

 <= /span>

From:<= /b> spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Tuesday, February 21, 2017 10:51 AM
To: spring@ietf.org
Subject: [spring] WG Last Call for draft-ietf-spring-segment-routing= -msdc-02

 

Hello Working Group,<= o:p>

 

This email starts a 2-week W= orking Group Last Call on draft-ietf-spring-segment-routing-msdc-02 [1].

 

Please read the document if = you haven't read the most recent version yet, and send your comments to the= list, no later than the *7th of March*.

Note that this is *not only*= a call for comments on the document; it is also a call for support (or not= ) to publish this document as an Informational RFC.

 

We have already polled for I= PR knowledge on this document and all Authors have replied.

No IPR has been disclosed [2= ].

 

Thank you<= /p>

 

M&B

 

[1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02

[2] https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -spring-segment-routing-msdc

 

 

 

 

______________________________________________________________________=
___________________________________________________
 
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 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_53C29892C857584299CBF5D05346208A1ED74B4AOPEXCLILM21corp_-- From nobody Wed Feb 22 06:02:39 2017 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 31A421298CE; Wed, 22 Feb 2017 06:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.486 X-Spam-Level: X-Spam-Status: No, score=-4.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, 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 wiccvSoTzx8n; Wed, 22 Feb 2017 06:02:34 -0800 (PST) Received: from relais-inet.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 DF0F61298C4; Wed, 22 Feb 2017 06:02:33 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id D075B203C3; Wed, 22 Feb 2017 15:02:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 93A6F4007E; Wed, 22 Feb 2017 15:02:31 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Wed, 22 Feb 2017 15:02:31 +0100 From: To: "Ruediger.Geib@telekom.de" Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbgNDdW3AAKavA0AAzyNMcAHw1UTwAGI8VEA= Date: Wed, 22 Feb 2017 14:02:30 +0000 Message-ID: <4576_1487772151_58AD99F7_4576_7594_1_53C29892C857584299CBF5D05346208A1ED74D8E@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com> <25080_1486748722_589DFC32_25080_2438_1_53C29892C857584299CBF5D05346208A1ED56C59@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/mixed; boundary="_004_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-oam-usecase@ietf.org" Subject: Re: [spring] draft-ietf-spring-oam-usecase - shepherd review X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:02:38 -0000 --_004_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_ Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_" --_000_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ruediger, Thanks for the updated draft. Looks good to me. I'll upload the shepherd writeup SOON [1] ;-). i.e. today. Please find also comments inline [Bruno2] Regards, Bruno [1] https://tools.ietf.org/html/draft-farrel-soon-04 From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Sent: Wednesday, February 22, 2017 12:02 PM To: DECRAENE Bruno IMT/OLN Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-chairs@= ietf.org Subject: AW: draft-ietf-spring-oam-usecase - shepherd review Hi Bruno, thanks for your new review. I've tried to adapt text and deleted the relate= d sections below. In some cases, I didn't change text, that's discussed below (marked [RG]). Regards, Ruediger Name: draft-ietf-spring-oam-usecase Revision: 06 Title: A Scalable and Topology-Aware MPLS Dataplane Monitoring S= ystem Document date: 2017-02-21 Group: spring Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-oam-= usecase-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usec= ase/ Htmlized: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-oam-u= secase-06 Von: bruno.decraene@orange.com [mailto:br= uno.decraene@orange.com] Gesendet: Freitag, 10. Februar 2017 18:45 An: Geib, R=FCdiger Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-chairs@ietf= .org Betreff: RE: draft-ietf-spring-oam-usecase - shepherd review Hi Ruediger, Thanks for the answer and the updated draft which is indeed improved. Reading the new version, I have additional comments below: --- Idnits report 1 issue: "=3D=3D It seems as if not all pages are separated b= y form feeds - found 0 form feeds but 16 pages" https://tools.ietf.org/idnits?url=3Dhttps://tools.ietf.org/id/draft-ietf-sp= ring-oam-usecase-05.txt [RG] The document is edited in xml using an IETF template and uses the xml = to txt conversion of IETF. I can contact the rfc editor and/or tool author. I'd prefer the RFC editor to sol= ve the issue or give me guidance. [Bruno2] I've quickly looked at your XML and did not find specific issues. = Then I used the online XML2RFC tool and it produced a correct output with F= orm Feeds. Please find enclosed. Eventually, you may have selected the "unpaginated" option of the XML2RFC. = (I don't know whether you are running your local version or the online one) Could you please check on your side? (It's good to find the issue but I gue= ss the draft could be fixed in a latter version) [snip] --- =A75.1 " Finally, the PMS sets up and sends packets to monitor connectivity of the ECMP routed paths. The PMS does this by creating a measurement packet with the following label stack (top to bottom): 20 - 30 - 10. The ping packets reliably use the monitored path, if the IP-address information which has been detected by the MPLS trace route is used as the IP destination address (note that this IP address isn't used or required for any IP routing)." >From the first sentence, I'm understanding that the traceroute part is fini= shed and now, end to end monitoring packets are sent using the regualr MPLS= dataplane. In such context, I'm not following the latest sentence. You are saying that the PMS sends a measurement packet with label stack 20 = - 30 - 10 and IP destination address previously detected. For me, such measurement packet will follow the path LERi (20), LERj (30), = PMS (10). A priori the PSM will send capture back the packet, hence this pa= cket will not be forwarded using the IP destination address. So why is this= IP destination address important? [RG] I added a reference to Downstream Mapping information / RFC4379 in the= section, as your question is answered there. [Bruno2] ok, thanks. [RG] I think, a detailed explanation of how to apply the RFC4379 tool set to monitor an MPLS network should be part of a separate document, if th= ere's community interest. 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_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rued= iger,

&n= bsp;

Thanks = for the updated draft.

&n= bsp;

Looks g= ood to me. I’ll upload the shepherd writeup SOON [1] ;-). i.e. today.=

&n= bsp;

Please = find also comments inline [Bruno2]

&n= bsp;

Regards= ,

Bruno

&n= bsp;

[1] https://tools.ietf.org/html/draft-farrel-soon-04

&n= bsp;

&n= bsp;

From: Ruediger= .Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
Sent: Wednesday, February 22, 2017 12:02 PM
To: DECRAENE Bruno IMT/OLN
Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-= chairs@ietf.org
Subject: AW: draft-ietf-spring-oam-usecase - shepherd review

 

Hi Brun= o,

&n= bsp;

thanks = for your new review. I’ve tried to adapt text and deleted the related= sections below.

In some= cases, I didn’t change text, that’s discussed below (marked [R= G]).

&n= bsp;

Regards, R= uediger

 = ;

Name:    = ;   draft-ietf-spring-oam-usecase

Revision:   06

Title:   &nbs= p;        A Scalable and Topology-Aware = MPLS Dataplane Monitoring System

Document date:  &n= bsp; 2017-02-21

Group:   &nbs= p;        spring

Pages:   &nbs= p;        16

URL:    =         https://www.ietf.org/internet-drafts/draft-ietf-sp= ring-oam-usecase-06.txt

Status:   &nb= sp;     = https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/<= /span>

Htmlized:   &= nbsp;   https://tools= .ietf.org/html/draft-ietf-spring-oam-usecase-06

Diff:    &n= bsp;      https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-oam-usecase-06

 = ;

 = ;

Von: bruno.decraene@orange.com = [mailto:bruno.decraene@orange.= com]
Gesendet: Freitag, 10. Februar 2017 18:45
An: Geib, R=FCdiger
Cc: draft-= ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-chairs@ietf.org
Betreff: RE: draft-ietf-spring-oam-usecase - shepherd review

 

Hi Rued= iger,

 <= /span>

Thanks = for the answer and the updated draft which is indeed improved.

 <= /span>

Reading= the new version, I have additional comments below:

 <= /span>

 <= /span>

---

Idnits = report 1 issue: "=3D=3D It seems as if not all pages are separated by = form feeds - found 0 form feeds but 16 pages"

https://tools.ietf.org/idnits?url=3Dhttps://to= ols.ietf.org/id/draft-ietf-spring-oam-usecase-05.txt

 <= /span>

[RG] Th= e document is edited in xml using an IETF template and uses the xml to txt = conversion of IETF. I can

contact= the rfc editor and/or tool author. I’d prefer the RFC editor to solv= e the issue or give me guidance.

&n= bsp;

[Bruno2= ] I’ve quickly looked at your XML and did not find specific issues. T= hen I used the online XML2RFC tool and it produced a correct output with Fo= rm Feeds. Please find enclosed.

Eventua= lly, you may have selected the “unpaginated” option of the XML2= RFC. (I don’t know whether you are running your local version or the = online one)

Could y= ou please check on your side? (It’s good to find the issue but I gues= s the draft could be fixed in a latter version)

&n= bsp;

[snip]<= /span>

---

=A75.1<= /span>

" = Finally, the PMS sets up and sends packets to monitor

 &= nbsp; connectivity of the ECMP routed paths.  The PMS does this by cre= ating

 &= nbsp; a measurement packet with the following label stack (top to bottom):<= /span>

 &= nbsp; 20 - 30 - 10.  The ping packets reliably use the monitored path,= if

 &= nbsp; the IP-address information which has been detected by the MPLS trace<= /span>

 &= nbsp; route is used as the IP destination address (note that this IP=

 &= nbsp; address isn't used or required for any IP routing)."

 &= nbsp;

From th= e first sentence, I'm understanding that the traceroute part is finished an= d now, end to end monitoring packets are sent using the regualr MPLS datapl= ane. In such context, I'm not following the latest sentence.

You are= saying that the PMS sends a measurement packet with label stack 20 - 30 - = 10 and IP destination address previously detected.

For me,= such measurement packet will follow the path LERi (20), LERj (30), PMS (10= ). A priori the PSM will send capture back the packet, hence this packet wi= ll not be forwarded using the IP destination address. So why is this IP destination address important? 

 <= /span>

[RG] I = added a reference to Downstream Mapping information / RFC4379 in the sectio= n, as your

questio= n is answered there.

[Bruno2= ] ok, thanks.

&n= bsp;

[RG] I = think, a detailed explanation of how to apply the RFC4379 tool

set to = monitor an MPLS network should be part of a separate document, if thereR= 17;s community interest.

 &= nbsp;

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_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_-- --_004_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_ Content-Type: text/plain; name="draft-ietf-spring-oam-usecase-06(1).txt" Content-Description: draft-ietf-spring-oam-usecase-06(1).txt Content-Disposition: attachment; filename="draft-ietf-spring-oam-usecase-06(1).txt"; size=37145; creation-date="Wed, 22 Feb 2017 13:36:07 GMT"; modification-date="Wed, 22 Feb 2017 13:36:09 GMT" Content-Transfer-Encoding: base64 CgoKCnNwcmluZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFIuIEdlaWIsIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIERldXRzY2hlIFRlbGVrb20KSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEMuIEZpbHNmaWxzCkV4cGly ZXM6IEF1Z3VzdCAyNiwgMjAxNyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBQaWdu YXRhcm8sIEVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTi4gS3VtYXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMuCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMiwgMjAx NwoKCiAgICAgQSBTY2FsYWJsZSBhbmQgVG9wb2xvZ3ktQXdhcmUgTVBMUyBEYXRhcGxhbmUgTW9u aXRvcmluZyBTeXN0ZW0KICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNwcmluZy1vYW0t dXNlY2FzZS0wNgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGZlYXR1cmVz IG9mIGEgcGF0aCBtb25pdG9yaW5nIHN5c3RlbSBhbmQKICAgcmVsYXRlZCB1c2UgY2FzZXMuICBT ZWdtZW50IGJhc2VkIHJvdXRpbmcgZW5hYmxlcyBhIHNjYWxhYmxlIGFuZAogICBzaW1wbGUgbWV0 aG9kIHRvIG1vbml0b3IgZGF0YSBwbGFuZSBsaXZlbGluZXNzIG9mIHRoZSBjb21wbGV0ZSBzZXQg b2YKICAgcGF0aHMgYmVsb25naW5nIHRvIGEgc2luZ2xlIGRvbWFpbi4gIFRoZSBNUExTIG1vbml0 b3Jpbmcgc3lzdGVtIGFkZHMKICAgZmVhdHVyZXMgdG8gdGhlIHRyYWRpdGlvbmFsIE1QTFMgcGlu ZyBhbmQgTFNQIHBhdGggdHJhY2UsIGluIGEgdmVyeQogICBjb21wbGVtZW50YXJ5IHdheS4gIE1Q TFMgdG9wb2xvZ3kgYXdhcmVuZXNzIHJlZHVjZXMgbWFuYWdlbWVudCBhbmQKICAgY29udHJvbCBw bGFuZSBpbnZvbHZlbWVudCBvZiBPQU0gbWVhc3VyZW1lbnRzIHdoaWxlIGVuYWJsaW5nIG5ldyBP QU0KICAgZmVhdHVyZXMuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURy YWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lv bnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCAyNiwgMjAxNy4KCkNv cHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxNyBJRVRGIFRydXN0IGFuZCB0aGUg cGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3Vt ZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qg b24gdGhlIGRhdGUgb2YKCgoKR2VpYiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0 IDI2LCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgU1IgTVBMUyBtb25pdG9yaW5nIHN5c3RlbSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRz IGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFz CiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENv bnRlbnRzCgogICAxLiAgQWNyb255bXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuICBUZXJtaW5vbG9n eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog ICA0LiAgQW4gTVBMUyBUb3BvbG9neS1Bd2FyZSBQYXRoIE1vbml0b3JpbmcgU3lzdGVtIC4gLiAu IC4gLiAuIC4gLiAgIDYKICAgNS4gIFNSLWJhc2VkIFBhdGggTW9uaXRvcmluZyBVc2UgQ2FzZSBJ bGx1c3RyYXRpb24gIC4gLiAuIC4gLiAuIC4gICA3CiAgICAgNS4xLiAgVXNlIENhc2UgMSAtIExT UCBEYXRhcGxhbmUgTW9uaXRvcmluZyAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDUuMi4g IFVzZSBDYXNlIDIgLSBNb25pdG9yaW5nIGEgUmVtb3RlIEJ1bmRsZSAuIC4gLiAuIC4gLiAuIC4g LiAgMTAKICAgICA1LjMuICBVc2UgQ2FzZSAzIC0gRmF1bHQgTG9jYWxpemF0aW9uIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgIDYuICBGYWlsdXJlIE5vdGlmaWNhdGlvbiBmcm9tIFBN UyB0byBMRVJpIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMQogICA3LiAgQXBwbHlpbmcgU1Ig dG8gTW9uaXRvcmluZyBub24tU1IgYmFzZWQgTFNQcyAoTERQIGFuZCBwb3NzaWJseQogICAgICAg UlNWUC1URSkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTEKICAgOC4gIFBNUyBNb25pdG9yaW5nIG9mIERpZmZlcmVudCBTZWdtZW50IElEIFR5 cGVzICAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgIDkuICBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9u IFVzaW5nIFBNUyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICAxMC4gRXh0ZW5zaW9u cyBvZiBTcGVjaWZpY2F0aW9ucyBSZWxldmFudCB0byB0aGlzIFVzZSBDYXNlICAuIC4gLiAgMTMK ICAgMTEuIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDEzCiAgIDEyLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICAxMy4gQWNrbm93bGVkZ2VtZW50cyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQKICAgMTQuIFJl ZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDE0CiAgICAgMTQuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQKICAgQXV0aG9ycycgQWRkcmVz c2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1Cgox LiAgQWNyb255bXMKCiAgIEVDTVAgICAgRXF1YWwtQ29zdCBNdWx0aS1QYXRoCgogICBJR1AgICAg IEludGVyaW9yIEdhdGV3YXkgUHJvdG9jb2wKCiAgIExFUiAgICAgTGFiZWwgRWRnZSBSb3V0ZXIK CiAgIExTUCAgICAgTGFiZWwgU3dpdGNoZWQgUGF0aAoKICAgTFNSICAgICBMYWJlbCBTd2l0Y2hp bmcgUm91dGVyCgogICBPQU0gICAgIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQgTWFp bnRlbmFuY2UKCiAgIFBNUyAgICAgUGF0aCBNb25pdG9yaW5nIFN5c3RlbQoKICAgUlNWUC1URSBS ZXNvdXJjZSBSZXNlclZhdGlvbiBQcm90b2NvbC1UcmFmZmljIEVuZ2luZWVyaW5nCgoKCkdlaWIs IGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAxNyAgICAgICAgICAgICAg ICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNSIE1QTFMgbW9uaXRvcmluZyBz eXN0ZW0gICAgICAgICAgRmVicnVhcnkgMjAxNwoKCiAgIFNJRCAgICAgU2VnbWVudCBJZGVudGlm aWVyCgogICBTUiAgICAgIFNlZ21lbnQgUm91dGluZwoKICAgU1JHQiAgICBTZWdtZW50IFJvdXRp bmcgR2xvYmFsIEJsb2NrCgoyLiAgSW50cm9kdWN0aW9uCgogICBJdCBpcyBlc3NlbnRpYWwgZm9y IGEgbmV0d29yayBvcGVyYXRvciB0byBtb25pdG9yIGFsbCB0aGUgZm9yd2FyZGluZwogICBwYXRo cyBvYnNlcnZlZCBieSB0aGUgdHJhbnNwb3J0ZWQgdXNlciBwYWNrZXRzLiAgTW9uaXRvcmluZyBw YWNrZXRzCiAgIGFyZSBleHBlY3RlZCB0byBiZSBmb3J3YXJkZWQgaW4gZGF0YXBsYW5lIGluIGEg c2ltaWxhciB3YXkgYXMgdXNlcgogICBwYWNrZXRzLiAgU2VnbWVudCBSb3V0aW5nIGVuYWJsZXMg Zm9yd2FyZGluZyBvZiBwYWNrZXRzIGFsb25nIHByZS0KICAgZGVmaW5lZCBwYXRocyBhbmQgc2Vn bWVudHMgYW5kIHRodXMgYSBTZWdtZW50IFJvdXRlZCBtb25pdG9yaW5nCiAgIHBhY2tldCBjYW4g c3RheSBpbiBkYXRhcGxhbmUgd2hpbGUgcGFzc2luZyBhbG9uZyBvbmUgb3IgbW9yZSBzZWdtZW50 cwogICB0byBiZSBtb25pdG9yZWQuCgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHN5c3Rl bSB1c2luZyBNUExTIGRhdGEgcGxhbmUgcGF0aAogICBtb25pdG9yaW5nIGNhcGFiaWxpdGllcy4g IFRoZSB1c2UgY2FzZXMgaW50cm9kdWNlZCBoZXJlIGFyZSBsaW1pdGVkCiAgIHRvIGEgc2luZ2xl IEludGVyaW9yIEdhdGV3YXkgUHJvdG9jb2wgKElHUCkgTVBMUyBkb21haW4uCgogICBUaGUgc3lz dGVtIGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBwcmUgU2VnbWVudCBSb3V0aW5nIExTUCdzICgg bGlrZQogICBMRFApIGFzIHdlbGwgYXMgdG8gbW9uaXRvcmluZyBvZiBTZWdtZW50IFJvdXRlZCBM U1AncyAoc2VjdGlvbiA3CiAgIG9mZmVycyBzb21lIG1vcmUgaW5mb3JtYXRpb24pLiAgQXMgY29t cGFyZWQgdG8gcHJlIFNlZ21lbnQgUm91dGluZwogICBhcHByb2FjaGVzLCBTZWdtZW50IFJvdXRp bmcgaXMgZXhwZWN0ZWQgdG8gc2ltcGxpZnkgc3VjaCBhIG1vbml0b3JpbmcKICAgc3lzdGVtIGJ5 IGVuYWJsaW5nIE1QTFMgdG9wb2xvZ3kgZGV0ZWN0aW9uIGJhc2VkIG9uIElHUCBzaWduYWxlZAog ICBzZWdtZW50cyBhcyBzcGVjaWZpZWQgYnkgc3BlY2lmaWVkIGJ5CiAgIFtJLUQuaWV0Zi1pc2lz LXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zXSwKICAgW0ktRC5pZXRmLW9zcGYtc2VnbWVudC1y b3V0aW5nLWV4dGVuc2lvbnNdIGFuZAogICBbSS1ELmlldGYtaWRyLWJncC1scy1zZWdtZW50LXJv dXRpbmctZXh0XS4gIFRodXMgYSBjZW50cmFsaXNlZCBhbmQKICAgTVBMUyB0b3BvbG9neSBhd2Fy ZSBtb25pdG9yaW5nIHVuaXQgY2FuIGJlIHJlYWxpemVkIGluIGEgU2VnbWVudAogICBSb3V0ZWQg ZG9tYWluLiAgVGhpcyB0b3BvbG9neSBhd2FyZW5lc3MgY2FuIGJlIHVzZWQgZm9yIE9BTSBwdXJw b3NlcwogICBhcyBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudC4KCiAgIFRoZSBzeXN0ZW0gb2Zm ZXJzIHNldmVyYWwgYmVuZWZpdHMgZm9yIG5ldHdvcmsgbW9uaXRvcmluZzoKCiAgIG8gIEEgc2lu Z2xlIGNlbnRyYWxpemVkIE1QTFMgbW9uaXRvcmluZyBzeXN0ZW0gd2hpY2ggaXMgYWJsZSB0bwog ICAgICBwZXJmb3JtIGEgY29udGludWl0eSBjaGVjayAocGluZykgYWxvbmcgYWxsIExhYmVsIFN3 aXRjaGVkIFBhdGhzCiAgICAgIG9mIHRoZSBTUiBkb21haW4uCgogICBvICBUaGUgTVBMUyBwaW5n IChvciBjb250aW51aXR5IGNoZWNrKSBwYWNrZXRzIG5ldmVyIGxlYXZlIHRoZSBNUExTCiAgICAg IHVzZXIgZGF0YSBwbGFuZS4KCiAgIG8gIFNSIGFsbG93cyB0byB0cmFuc3BvcnQgTVBMUyBwYXRo IHRyYWNlIG9yIGNvbm5lY3Rpdml0eSB2YWxpZGF0aW9uCiAgICAgIHBhY2tldHMgZm9yIGFueSBl eGlzdGluZyBMYWJlbCBTd2l0Y2hlZCBQYXRoIHRvIGFsbCBub2RlcyBvZiBhbiBTUgogICAgICBk b21haW4uICBUaGlzIHVzZSBjYXNlIGRvZXNuJ3QgZGVzY3JpYmUgYW55IG5ldyBwYXRoIHRyYWNl CiAgICAgIGZlYXR1cmVzLCBidXQgdGhlIHN5c3RlbSBkZXNjcmliZWQgaGVyZSBhbGxvd3MgdG8g c2V0IHVwIGFuIFNSCiAgICAgIGRvbWFpbiB3aWRlIGNlbnRyYWxpc2VkIGNvbm5lY3Rpdml0eSB2 YWxpZGF0aW9uLgoKCgoKR2VpYiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI2 LCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAg U1IgTVBMUyBtb25pdG9yaW5nIHN5c3RlbSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgbyAg VGhlIHN5c3RlbSBzZW5kaW5nIHRoZSBtb25pdG9yaW5nIHBhY2tldCBpcyBhbHNvIHJlY2Vpdmlu ZyBpdC4KICAgICAgVGhlIHBheWxvYWQgb2YgdGhlIG1vbml0b3JpbmcgcGFja2V0IG1heSBiZSBj aG9zZW4gZnJlZWx5LiAgVGhpcwogICAgICBhbGxvd3Mgc2VuZGluZyBwcm9iaW5nIHBhY2tldHMg cmVwcmVzZW50aW5nIGN1c3RvbWVyIHRyYWZmaWMsCiAgICAgIHBvc3NpYmx5IGZyb20gbXVsdGlw bGUgc2VydmljZXMgKGUuZy4sIHNtYWxsIFZvSVAgcGFja2V0LCBsYXJnZXIKICAgICAgSFRUUCBw YWNrZXRzKSBhbmQgZW1iZWRkaW5nIG9mIHVzZWZ1bCBtb25pdG9yaW5nIGRhdGEgKGUuZy4sCiAg ICAgIGFjY3VyYXRlIHRpbWUgc3RhbXBzIHNpbmNlIGJvdGggc2VuZGVyIGFuZCByZWNlaXZlciBo YXZlIHRoZSBzYW1lCiAgICAgIGNsb2NrLCBzZXF1ZW5jZSBudW1iZXJzIHRvIGVhc2UgdGhlIG1l YXN1cmVtZW50Li4uKS4KCiAgIG8gIFNldCB1cCBvZiBhIGZsZXhpYmxlIE1QTFMgbW9uaXRvcmlu ZyBzeXN0ZW0gaW4gdGVybXMgb2YKICAgICAgZGVwbG95bWVudDogZnJvbSBvbmUgc2luZ2xlIGNl bnRyYWxpemVkIG9uZSB0byBhIHNldCBvZgogICAgICBkaXN0cmlidXRlZCBzeXN0ZW1zIChlLmcu LCBvbiBhIHBlciByZWdpb24gb3Igc2VydmljZSBiYXNlKSwgYW5kCiAgICAgIGluIHRlcm1zIG9m IHJlZHVuZGFuY3kgZnJvbSAxKzEgdG8gTisxLgoKICAgSW4gYWRkaXRpb24gdG8gbW9uaXRvcmlu ZyBwYXRocywgcHJvYmxlbSBsb2NhbGl6YXRpb24gaXMgcmVxdWlyZWQuCiAgIEZhdWx0cyBjYW4g YmUgbG9jYWxpemVkOgoKICAgbyAgYnkgY2FwdHVyaW5nIHRoZSBJbnRlcmlvciBHYXRld2F5IFBy b3RvY29sIChJR1ApIHRvcG9sb2d5IGFuZAogICAgICBhbmFseXNpbmcgSUdQIG1lc3NhZ2VzIGlu ZGljYXRpbmcgY2hhbmdlcyBvZiBpdC4KCiAgIG8gIGJ5IGNvcnJlbGF0aW9uIGJldHdlZW4gZGlm ZmVyZW50IFNSIGJhc2VkIG1vbml0b3JpbmcgcHJvYmVzLgoKICAgbyAgYnkgc2V0dGluZyB1cCBh biBNUExTIHRyYWNlcm91dGUgcGFja2V0IGZvciBhIHBhdGggKG9yIFNlZ21lbnQpIHRvCiAgICAg IGJlIHRlc3RlZCBhbmQgdHJhbnNwb3J0aW5nIGl0IHRvIGEgbm9kZSB0byB2YWxpZGF0ZSBwYXRo CiAgICAgIGNvbm5lY3Rpdml0eSBmcm9tIHRoYXQgbm9kZSBvbi4KCiAgIFRvcG9sb2d5IGF3YXJl bmVzcyBpcyBhbiBlc3NlbnRpYWwgcGFydCBvZiBsaW5rIHN0YXRlIElHUHMuICBBZGRpbmcKICAg TVBMUyB0b3BvbG9neSBhd2FyZW5lc3MgdG8gYW4gSUdQIHNwZWFraW5nIGRldmljZSBoZW5jZSBl bmFibGVzIGEKICAgc2ltcGxlIGFuZCBzY2FsYWJsZSBkYXRhIHBsYW5lIGJhc2VkIG1vbml0b3Jp bmcgbWVjaGFuaXNtLgoKICAgTVBMUyBPQU0gb2ZmZXJzIGZsZXhpYmxlIHRyYWNlcm91dGUgKGNv bm5lY3Rpdml0eSB2ZXJpZmljYXRpb24pCiAgIGZlYXR1cmVzIHRvIHJlY29nbmlzZSBhbmQgZXhl Y3V0ZSBkYXRhIHBhdGhzIG9mIGFuIE1QTFMgZG9tYWluLiAgQnkKICAgdXRpbGlzaW5nIHRoZSBF Q01QIHJlbGF0ZWQgdG9vbCBzZXQgb2ZmZXJlZCwgZS5nLiwgYnkgUkZDIDQzNzkKICAgW1JGQzQz NzldLCBhIFNSIGJhc2VkIE1QTFMgbW9uaXRvcmluZyBzeXN0ZW0gY2FuIGJlIGVuYWJsZWQgdG86 CgogICBvICBkZXRlY3QgaG93IHRvIHJvdXRlIHBhY2tldHMgYWxvbmcgZGlmZmVyZW50IEVDTVAg cm91dGVkIHBhdGhzLgoKICAgbyAgY29uc3RydWN0IHBpbmcgcGFja2V0cywgd2hpY2ggY2FuIGJl IHByZWNpc2VseSBzdGVlcmVkIHRvIHBhdGhzCiAgICAgIHdob3NlIGNvbm5lY3Rpdml0eSBpcyB0 byBiZSBjaGVja2VkLCBhbHNvIGlmIEVDTVAgaXMgcHJlc2VudC4KCiAgIG8gIGxpbWl0IHRoZSBN UExTIGxhYmVsIHN0YWNrIG9mIHN1Y2ggYSBwaW5nIHBhY2tldCBjaGVja2luZwogICAgICBjb250 aW51aXR5IG9mIGV2ZXJ5IHNpbmdsZSBJR1AtU2VnbWVudCB0byB0aGUgbWF4aW11bSBudW1iZXIg b2YgMwogICAgICBsYWJlbHMuICBBIHNtYWxsZXIgbGFiZWwgc3RhY2sgbWF5IGFsc28gYmUgaGVs cGZ1bCwgaWYgYW55IHJvdXRlcgogICAgICBpbnRlcnByZXRzIGEgbGltaXRlZCBudW1iZXIgb2Yg cGFja2V0IGhlYWRlciBieXRlcyB0byBkZXRlcm1pbmUgYW4KICAgICAgRUNNUCBwYXRoIGFsb25n IHdoaWNoIHRvIHJvdXRlIGEgcGFja2V0LgoKICAgQWx0ZXJuYXRpdmVseSwgYW55IHBhdGggbWF5 IGJlIGV4ZWN1dGVkIGJ5IGJ1aWxkaW5nIHN1aXRhYmxlIGxhYmVsCiAgIHN0YWNrcy4gIFRoaXMg YWxsb3dzIHBhdGggZXhlY3V0aW9uIHdpdGhvdXQgRUNNUCBhd2FyZW5lc3MuCgoKCgpHZWliLCBl dCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMTcgICAgICAgICAgICAgICAg W1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTUiBNUExTIG1vbml0b3Jpbmcgc3lz dGVtICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcKCgogICBUaGUgTVBMUyBQYXRoIE1vbml0b3Jpbmcg U3lzdGVtIG1heSBiZSBhbnkgc2VydmVyIHJlc2lkaW5nIGF0IGEKICAgc2luZ2xlIGludGVyZmFj ZSBvZiB0aGUgZG9tYWluIHRvIGJlIG1vbml0b3JlZC4gIFRoZSBQTVMgZG9lc24ndCBuZWVkCiAg IHRvIHN1cHBvcnQgdGhlIGNvbXBsZXRlIE1QTFMgcm91dGluZyBvciBjb250cm9sIHBsYW5lLiAg SXQgbmVlZHMgdG8KICAgYmUgY2FwYWJsZSB0byBsZWFybiBhbmQgbWFpbnRhaW4gYW4gYWNjdXJh dGUgTVBMUyBhbmQgSUdQIHRvcG9sb2d5LgogICBNUExTIHBpbmcgYW5kIHRyYWNlcm91dGUgcGFj a2V0cyBuZWVkIHRvIGJlIHNldCB1cCBhbmQgc2VudCB3aXRoIHRoZQogICBjb3JyZWN0IHNlZ21l bnQgc3RhY2suICBUaGUgUE1TIGZ1cnRoZXIgbXVzdCBiZSBhYmxlIHRvIHJlY2VpdmUgYW5kCiAg IGRlY29kZSByZXR1cm5pbmcgcGluZyBvciB0cmFjZXJvdXRlIHBhY2tldHMuICBQYWNrZXRzIHVz ZWQgdG8gY2hlY2sKICAgY29udGludWl0eSBjb3VsZCBoYXZlIEJGRCBvciBMU1AgUGluZyBmb3Jt YXQsIG9yIGhhdmUgYW55IG90aGVyIE9BTQogICBmb3JtYXQgc3VwcG9ydGVkIGJ5IHRoZSBQTVMu ICBBcyBsb25nIGFzIHRoZSBwYWNrZXQgdXNlZCB0byBjaGVjawogICBjb250aW51aXR5IHJldHVy bnMgYmFjayB0byB0aGUgc2VydmVyIHdoaWxlIG5vIElHUCBjaGFuZ2UgaXMKICAgZGV0ZWN0ZWQs IHRoZSBtb25pdG9yZWQgcGF0aCBjYW4gYmUgY29uc2lkZXJlZCBhcyB2YWxpZGF0ZWQuICBJZgog ICBtb25pdG9yaW5nIHJlcXVpcmVzIHB1c2hpbmcgYSBsYXJnZSBsYWJlbCBzdGFjaywgYSBzb2Z0 d2FyZSBiYXNlZAogICBpbXBsZW1lbnRhdGlvbiBpcyB1c3VhbGx5IG1vcmUgZmxleGlibGUgdGhh biBhbiBoYXJkd2FyZSBiYXNlZCBvbmUuCiAgIEhlbmNlIHJvdXRlciBsYWJlbCBzdGFjayBkZXB0 aCBhbmQgbGFiZWwgY29tcG9zaXRpb24gbGltaXRhdGlvbnMKICAgZG9uJ3QgbGltaXQgTVBMUyBP QU0gY2hvaWNlcy4KCiAgIERvY3VtZW50cyBkaXNjdXNzaW5nIFNSIE9BTSByZXF1aXJlbWVudHMg YW5kIE1QTFMgdHJhY2Vyb3V0ZQogICBlbmhhbmNlbWVudHMgYWRkaW5nIGZ1bmN0aW9uYWxpdHkg dG8gdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgYnkgdGhpcwogICBkb2N1bWVudCBhcmUgaW4gd29y ayB3aXRoaW4gSUVURiwgc2VlCiAgIFtJLUQuaWV0Zi1zcHJpbmctc3Itb2FtLXJlcXVpcmVtZW50 XSBhbmQKICAgW0ktRC5kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5nXS4KCjMuICBUZXJt aW5vbG9neQoKICAgQ29udGludWl0eSBDaGVjawoKICAgICAgIFJGQyA3Mjc2IFtSRkM3Mjc2XSBk ZWZpbmVzIENvbnRpbnVpdHkgQ2hlY2tzIHRvIGJlIHVzZWQgdG8gdmVyaWZ5CiAgICAgICB0aGF0 IGEgZGVzdGluYXRpb24gaXMgcmVhY2hhYmxlLCBhbmQgYXJlIHR5cGljYWxseSBzZW50CiAgICAg ICBwcm9hY3RpdmVseSwgdGhvdWdoIHRoZXkgY2FuIGJlIGludm9rZWQgb24tZGVtYW5kIGFzIHdl bGwuCiAgICAgICBTZWdtZW50IFJvdXRpbmcgYWxsb3dzIHRvIHJlYWxpc2UgYSBjb250aW51aXR5 IGNoZWNrIGFsb25nIGFueQogICAgICAgZ2l2ZW4gU1IgZG9tYWluIHBhdGggd2l0aGluIGRhdGEg cGxhbmUuCgogICBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uCgogICAgICAgUkZDIDcyNzYgW1JG QzcyNzZdIGRlZmluZXMgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBhcyBhCiAgICAgICBtZWNo YW5pc20gdG8gY2hlY2sgY29ubmVjdGl2aXR5IGJldHdlZW4gdHdvIG5vZGVzIGJ5IGNoZWNraW5n CiAgICAgICB3aGV0aGVyIGEgcGF0aCBiZXR3ZWVuIGJvdGggY2FuIGJlIHVzZWQuICBSRkMgNDM3 OSBbUkZDNDM3OV0KICAgICAgIHNwZWNpZmllcyBhIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24g Zm9yIE1QTFMgZG9tYWlucy4gIEFzIFJGQwogICAgICAgNzI3NiBzdGF0ZXMsIENvbm5lY3Rpdml0 eSBWZXJpZmljYXRpb24gYW5kIENvbnRpbnVpdHkgQ2hlY2tzIGFyZQogICAgICAgY29uc2lkZXJl ZCBjb21wbGVtZW50YXJ5IG1lY2hhbmlzbXMgYW5kIGFyZSBvZnRlbiB1c2VkIGluCiAgICAgICBj b25qdW5jdGlvbiB3aXRoIGVhY2ggb3RoZXIuICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1 c2Ugb2YKICAgICAgIFNSIGJhc2VkIG5ldHdvcmsgbW9uaXRvcmluZyBhcyBhIG5ldyBDb250aW51 aXR5IENoZWNrIG1ldGhvZC4gIEluCiAgICAgICBzb21lIHNwZWNpYWwgY2FzZXMsIGl0IGFsc28g Y292ZXJzIHNvbWUgbGltaXRlZCBDb25uZWN0aXZpdHkKICAgICAgIFZlcmlmaWNhdGlvbi4gIFdo ZW4gYXBwbGljYWJsZSwgdGhpcyBpcyBpbmRpY2F0ZWQgaW4gdGhlCiAgICAgICBkZXNjcmlwdGlv biBvZiB0aGUgdXNlIGNhc2UuCgogICBNUExTIHRvcG9sb2d5CgoKCgpHZWliLCBldCBhbC4gICAg ICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMTcgICAgICAgICAgICAgICAgW1BhZ2UgNV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTUiBNUExTIG1vbml0b3Jpbmcgc3lzdGVtICAgICAg ICAgIEZlYnJ1YXJ5IDIwMTcKCgogICAgICAgVGhlIE1QTFMgdG9wb2xvZ3kgb2YgYW4gTVBMUyBk b21haW4gaXMgdGhlIGNvbXBsZXRlIHNldCBvZiBNUExTLQogICAgICAgYW5kIElQLWFkZHJlc3Mg aW5mb3JtYXRpb24gYW5kIGFsbCByb3V0aW5nIGFuZCBkYXRhIHBsYW5lCiAgICAgICBpbmZvcm1h dGlvbiByZXF1aXJlZCB0byBhZGRyZXNzIGFuZCB1dGlsaXNlIGV2ZXJ5IE1QTFMgcGF0aAogICAg ICAgd2l0aGluIHRoaXMgZG9tYWluIGZyb20gYW4gTVBMUyBQYXRoIE1vbml0b3JpbmcgU3lzdGVt IGF0dGFjaGVkCiAgICAgICB0byB0aGlzIE1QTFMgZG9tYWluIGF0IGFuIGFyYml0cmFyeSBhY2Nl c3MuICBUaGlzIGRvY3VtZW50CiAgICAgICBhc3N1bWVzIGF2YWlsYWJpbGl0eSBvZiB0aGUgTVBM UyB0b3BvbG9neSAod2hpY2ggY2FuIGJlIGRldGVjdGVkCiAgICAgICB3aXRoIGF2YWlsYWJsZSBw cm90b2NvbHMgYW5kIGludGVyZmFjZXMpLiAgTm9uZSBvZiB0aGUgdXNlIGNhc2VzCiAgICAgICB3 aWxsIGRlc2NyaWJlIGhvdyB0byBzZXQgaXQgdXAuCgogICBUaGlzIGRvY3VtZW50IGZ1cnRoZXIg YWRvcHRzIHRoZSB0ZXJtaW5vbG9neSBhbmQgZnJhbWV3b3JrIGRlc2NyaWJlZAogICBpbiBbSS1E LmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ10uCgo0LiAgQW4gTVBMUyBUb3BvbG9neS1Bd2Fy ZSBQYXRoIE1vbml0b3JpbmcgU3lzdGVtCgogICBBbnkgbm9kZSBhdCBsZWFzdCBsaXN0ZW5pbmcg dG8gdGhlIElHUCBvZiBhbiBTUiBkb21haW4gaXMgTVBMUwogICB0b3BvbG9neSBhd2FyZSAodGhl IG5vZGUga25vd3MgYWxsIHJlbGF0ZWQgSVAgYWRkcmVzc2VzLCBTUiBTSURzIGFuZAogICBNUExT IGxhYmVscykuICBBbiBNUExTIFBNUyB3aGljaCBpcyBhYmxlIHRvIGxlYXJuIHRoZSBJR1AgTFNE QgogICAoaW5jbHVkaW5nIHRoZSBTSUQncykgaXMgYWJsZSB0byBleGVjdXRlIGFyYml0cmFyeSBj aGFpbnMgb2YgbGFiZWwKICAgc3dpdGNoZWQgcGF0aHMuICBUbyBtb25pdG9yIGFuIE1QTFMgU1Ig ZG9tYWluLCBhIFBNUyBuZWVkcyB0byBzZXQgdXAKICAgYSB0b3BvbG9neSBkYXRhIGJhc2Ugb2Yg dGhlIE1QTFMgU1IgZG9tYWluIHRvIGJlIG1vbml0b3JlZC4gIEl0IG1heQogICBiZSB1c2VkIHRv IHNlbmQgcGluZyB0eXBlIHBhY2tldHMgdG8gb25seSBjaGVjayBjb250aW51aXR5IGFsb25nIHN1 Y2gKICAgYSBwYXRoIGNoYWluIGJhc2VkIG9uIHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiBvbmx5 LiAgSW4gYWRkaXRpb24sCiAgIHRoZSBQTVMgY2FuIGJlIHVzZWQgdG8gdHJhY2UgTVBMUyBMYWJl bCBTd2l0Y2hlZCBQYXRoIGFuZCB0aHVzIHZlcmlmeQogICB0aGVpciBjb25uZWN0aXZpdHkgYW5k IGNvcnJlc3BvbmRlbmNlIGJldHdlZW4gY29udHJvbCBhbmQgZGF0YSBwbGFuZSwKICAgcmVzcGVj dGl2ZWx5LiAgVGhlIFBNUyBjYW4gZGlyZWN0IHN1aXRhYmxlIE1QTFMgdHJhY2Vyb3V0ZSBwYWNr ZXRzIHRvCiAgIGFueSBub2RlIGFsb25nIGEgcGF0aCBzZWdtZW50LgoKICAgTGV0IHVzIGRlc2Ny aWJlIGhvdyB0aGUgUE1TIGNvbnN0cnVjdHMgYSBsYWJlbHMgc3RhY2sgdG8gdHJhbnNwb3J0IGEK ICAgcGFja2V0IHRvIExFUiBpLCBtb25pdG9yIGl0cyBwYXRoIHRvIExFUiBqIGFuZCB0aGVuIHJl Y2VpdmUgdGhlCiAgIHBhY2tldCBiYWNrLgoKICAgVGhlIFBNUyBtYXkgZG8gc28gYnkgc2VuZGlu ZyBwYWNrZXRzIGNhcnJ5aW5nIHRoZSBmb2xsb3dpbmcgTVBMUwogICBsYWJlbCBzdGFjayBpbmZv cm1hdGlvbjoKCiAgIG8gIFRvcCBMYWJlbDogYSBwYXRoIGZyb20gUE1TIHRvIExFUiBpLCB3aGlj aCBpcyBleHByZXNzZWQgYXMgTm9kZQogICAgICBTSUQgb2YgTEVSIGkuCgogICBvICBOZXh0IExh YmVsOiB0aGUgcGF0aCB0aGF0IG5lZWRzIHRvIGJlIG1vbml0b3JlZCBmcm9tIExFUiBpIHRvIExF UgogICAgICBqLiAgSWYgdGhpcyBwYXRoIGlzIGEgc2luZ2xlIHBoeXNpY2FsIGludGVyZmFjZSAo b3IgYSBidW5kbGUgb2YKICAgICAgY29ubmVjdGVkIGludGVyZmFjZXMpLCBpdCBjYW4gYmUgZXhw cmVzc2VkIGJ5IHRoZSByZWxhdGVkCiAgICAgIEFkamFjZW5jeS1TSUQuICBJZiB0aGUgc2hvcnRl c3QgcGF0aCBmcm9tIExFUiBpIHRvIExFUiBqIGlzCiAgICAgIHN1cHBvc2VkIHRvIGJlIG1vbml0 b3JlZCwgdGhlIE5vZGUtU0lEIChMRVIgaikgY2FuIGJlIHVzZWQuCiAgICAgIEFub3RoZXIgb3B0 aW9uIGlzIHRvIGluc2VydCBhIGxpc3Qgb2Ygc2VnbWVudHMgZXhwcmVzc2luZyB0aGUKICAgICAg ZGVzaXJlZCBwYXRoIChob3AgYnkgaG9wIGFzIGFuIGV4dHJlbWUgY2FzZSkuICBJZiBMRVIgaSBw dXNoZXMgYQogICAgICBzdGFjayBvZiBMYWJlbHMgYmFzZWQgb24gYSBTUiBwb2xpY3kgZGVjaXNp b24gYW5kIHRoaXMgc3RhY2sgb2YKICAgICAgTFNQcyBpcyB0byBiZSBtb25pdG9yZWQsIHRoZSBQ TVMgbmVlZHMgYW4gaW50ZXJmYWNlIHRvIGNvbGxlY3QgdGhlCiAgICAgIGluZm9ybWF0aW9uIGVu YWJsaW5nIGl0IHRvIGFkZHJlc3MgdGhpcyBTUiBjcmVhdGVkIHBhdGguCgoKCgpHZWliLCBldCBh bC4gICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMTcgICAgICAgICAgICAgICAgW1Bh Z2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTUiBNUExTIG1vbml0b3Jpbmcgc3lzdGVt ICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcKCgogICBvICBOZXh0IExhYmVsIG9yIGFkZHJlc3M6IHRo ZSBwYXRoIGJhY2sgdG8gdGhlIFBNUy4gIExpa2VseSwgbm8KICAgICAgZnVydGhlciBzZWdtZW50 L2xhYmVsIGlzIHJlcXVpcmVkIGhlcmUuICBJbmRlZWQsIG9uY2UgdGhlIHBhY2tldAogICAgICBy ZWFjaGVzIExFUiBqLCB0aGUgJ3N0ZWVyaW5nJyBwYXJ0IG9mIHRoZSBzb2x1dGlvbiBpcyBkb25l IGFuZCB0aGUKICAgICAgcHJvYmUganVzdCBuZWVkcyB0byByZXR1cm4gdG8gdGhlIFBNUy4gIFRo aXMgaXMgYmVzdCBhY2hpZXZlZCBieQogICAgICBwb3BwaW5nIHRoZSBNUExTIHN0YWNrIGFuZCBy ZXZlYWxpbmcgYSBwcm9iZSBwYWNrZXQgd2l0aCBQTVMgYXMKICAgICAgZGVzdGluYXRpb24gYWRk cmVzcyAobm90ZSB0aGF0IGluIHRoaXMgY2FzZSwgdGhlIHNvdXJjZSBhbmQKICAgICAgZGVzdGlu YXRpb24gYWRkcmVzc2VzIGNvdWxkIGJlIHRoZSBzYW1lKS4gIElmIGFuIElQIGFkZHJlc3MgaXMK ICAgICAgYXBwbGllZCwgbm8gU0lEL2xhYmVsIGhhcyB0byBiZSBhc3NpZ25lZCB0byB0aGUgUE1T IChpZiBpdCBpcyBhCiAgICAgIGhvc3Qvc2VydmVyIHJlc2lkaW5nIGluIGFuIElQIHN1Ym5ldCBv dXRzaWRlIHRoZSBNUExTIGRvbWFpbikuCgogICBUaGUgUE1TIHNob3VsZCBiZSBwaHlzaWNhbGx5 IGNvbm5lY3RlZCB0byBhIHJvdXRlciB3aGljaCBpcyBwYXJ0IG9mCiAgIHRoZSBTUiBkb21haW4u ICBJdCBtdXN0IGJlIGFibGUgdG8gc2VuZCBhbmQgcmVjZWl2ZSBNUExTIHBhY2tldHMgdmlhCiAg IHRoaXMgaW50ZXJmYWNlLiAgQXMgbWVudGlvbmVkIGFib3ZlLCByb3V0aW5nIHByb3RvY29sIHN1 cHBvcnQgaXNuJ3QKICAgcmVxdWlyZWQgYW5kIHRoZSBQTVMgaXRzZWxmIGRvZXNuJ3QgaGF2ZSB0 byBiZSBpbnZvbHZlZCBpbiBJR1Agb3IKICAgTVBMUyByb3V0aW5nLiAgQSBzdGF0aWMgcm91dGUg d2lsbCBkby4gIEZ1cnRoZXIgb3B0aW9ucywgbGlrZQogICBkZXBsb3ltZW50IG9mIGEgUE1TIGNv bm5lY3RpbmcgdG8gdGhlIE1QTFMgZG9tYWluIGJ5IGEgdHVubmVsIG9ubHkKICAgcmVxdWlyZSBt b3JlIHRob3VnaHQsIGFzIHRoaXMgaW1wbGllcyBzZWN1cml0eSBhc3BlY3RzLiAgTVBMUyBzbyBm YXIKICAgc2VwYXJhdGVzIG5ldHdvcmtzIHNlY3VyZWx5IGJ5IGF2b2lkaW5nIHR1bm5lbCBhY2Nl c3MgdG8gTVBMUwogICBkb21haW5zLgoKNS4gIFNSLWJhc2VkIFBhdGggTW9uaXRvcmluZyBVc2Ug Q2FzZSBJbGx1c3RyYXRpb24KCjUuMS4gIFVzZSBDYXNlIDEgLSBMU1AgRGF0YXBsYW5lIE1vbml0 b3JpbmcKCiAgICAgICAgICAgICAgICAgICArLS0tKyAgICAgKy0tLS0rICAgICArLS0tLS0rCiAg ICAgICAgICAgICAgICAgICB8UE1TfCAgICAgfExTUjF8LS0tLS18TEVSIGl8CiAgICAgICAgICAg ICAgICAgICArLS0tKyAgICAgKy0tLS0rICAgICArLS0tLS0rCiAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgLyAgICAgIFwgICAgLwogICAgICAgICAgICAgICAgICAgICAgfCAgICAgLyAgICAg ICAgXF9fLwogICAgICAgICAgICAgICAgICAgICstLS0tLSsvICAgICAgICAgICAvfAogICAgICAg ICAgICAgICAgICAgIHxMRVIgbXwgICAgICAgICAgIC8gfAogICAgICAgICAgICAgICAgICAgICst LS0tLStcICAgICAgICAgLyAgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAv ICAgIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcKy0tLS0rICAgICArLS0tLS0rCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxMU1IyfC0tLS0tfExFUiBqfAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArLS0tLSsgICAgICstLS0tLSsKCiAgIEV4YW1wbGUgb2YgYSBQ TVMgYmFzZWQgTFNQIGRhdGFwbGFuZSBtb25pdG9yaW5nCgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGaWd1cmUgMQoKICAgRm9yIHRoZSBzYWtlIG9mIHNpbXBsaWNpdHksIGxldCdz IGFzc3VtZSB0aGF0IGFsbCB0aGUgbm9kZXMgYXJlCiAgIGNvbmZpZ3VyZWQgd2l0aCB0aGUgc2Ft ZSBTUkdCIFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nXS4KCiAgIExldCdzIGFzc2ln biB0aGUgZm9sbG93aW5nIE5vZGUgU0lEcyB0byB0aGUgbm9kZXMgb2YgdGhlIGZpZ3VyZTogUE1T CiAgID0gMTAsIExFUiBpID0gMjAsIExFUiBqID0gMzAuCgoKCgoKR2VpYiwgZXQgYWwuICAgICAg ICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdlIDddCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgU1IgTVBMUyBtb25pdG9yaW5nIHN5c3RlbSAgICAgICAg ICBGZWJydWFyeSAyMDE3CgoKICAgVGhlIGFpbSBpcyB0byBzZXQgdXAgYSBjb250aW51aXR5IGNo ZWNrIG9mIHRoZSBwYXRoIGJldHdlZW4gTEVSIGkgYW5kCiAgIExFUiBqLiAgQXMgaGFzIGJlZW4g c2FpZCwgdGhlIG1vbml0b3JpbmcgcGFja2V0cyBhcmUgdG8gYmUgc2VudCBhbmQKICAgcmVjZWl2 ZWQgYnkgdGhlIFBNUy4gIExldCdzIGFzc3VtZSB0aGUgZGVzaWduIGFpbSBpcyB0byBiZSBhYmxl IHRvCiAgIHdvcmsgd2l0aCB0aGUgc21hbGxlc3QgcG9zc2libGUgU1IgbGFiZWwgc3RhY2suICBJ biB0aGUgZ2l2ZW4KICAgdG9wb2xvZ3ksIGEgZmFpcmx5IHNpbXBsZSBvcHRpb24gaXMgdG8gcGVy Zm9ybSBhbiBNUExTIHBhdGggdHJhY2UsIGFzCiAgIHNwZWNpZmllZCBieSBSRkM0Mzc5ICh1c2lu ZyB0aGUgRG93bnN0cmVhbSAoRGV0YWlsZWQpIE1hcHBpbmcKICAgaW5mb3JtYXRpb24gcmVzdWx0 aW5nIGZyb20gYSAidHJlZSB0cmFjZSIsIHNlZSBbUkZDNDM3OV0pLiAgVGhlCiAgIHN0YXJ0aW5n IHBvaW50IGZvciB0aGUgcGF0aCB0cmFjZSBpcyBMRVIgaSBhbmQgdGhlIFBNUyBzZW5kcyB0aGUg TVBMUwogICBwYXRoIHRyYWNlIHBhY2tldCB0byBMRVIgaS4gIFRoZSBNUExTIGVjaG8gcmVwbHkg b2YgTEVSIGkgc2hvdWxkIGJlCiAgIHNlbnQgdG8gdGhlIFBNUy4gIEFzIGEgcmVzdWx0LCBJUCBk ZXN0aW5hdGlvbiBhZGRyZXNzIGNob2ljZXMgYXJlCiAgIGRldGVjdGVkLCB3aGljaCBhcmUgdGhl biB1c2VkIHRvIHRhcmdldCBhbnkgb25lIG9mIHRoZSBFQ01QIHJvdXRlZAogICBwYXRocyBiZXR3 ZWVuIExFUiBpIGFuZCBMRVIgaiBieSB0aGUgTVBMUyBwaW5nIHBhY2tldHMgdG8gbGF0ZXIgY2hl Y2sKICAgcGF0aCBjb250aW51aXR5LiAgVGhlIExhYmVsIHN0YWNrIG9mIHRoZXNlIHBpbmcgcGFj a2V0cyBkb2Vzbid0IG5lZWQKICAgdG8gY29uc2lzdCBvZiBtb3JlIHRoYW4gMyBsYWJlbHMuICBG aW5hbGx5LCB0aGUgUE1TIHNldHMgdXAgYW5kIHNlbmRzCiAgIHBhY2tldHMgdG8gbW9uaXRvciBj b25uZWN0aXZpdHkgb2YgdGhlIEVDTVAgcm91dGVkIHBhdGhzLiAgVGhlIFBNUwogICBkb2VzIHRo aXMgYnkgY3JlYXRpbmcgYSBtZWFzdXJlbWVudCBwYWNrZXQgd2l0aCB0aGUgZm9sbG93aW5nIGxh YmVsCiAgIHN0YWNrICh0b3AgdG8gYm90dG9tKTogMjAgLSAzMCAtIDEwLiAgVGhlIHBpbmcgcGFj a2V0cyByZWxpYWJseSB1c2UKICAgdGhlIG1vbml0b3JlZCBwYXRoLCBpZiB0aGUgSVAtYWRkcmVz cyBpbmZvcm1hdGlvbiB3aGljaCBoYXMgYmVlbgogICBkZXRlY3RlZCBieSB0aGUgTVBMUyB0cmFj ZSByb3V0ZSBpcyB1c2VkIGFzIHRoZSBJUCBkZXN0aW5hdGlvbgogICBhZGRyZXNzIChub3RlIHRo YXQgdGhpcyBJUCBhZGRyZXNzIGlzbid0IHVzZWQgb3IgcmVxdWlyZWQgZm9yIGFueSBJUAogICBy b3V0aW5nKS4KCiAgIExFUiBtIGZvcndhcmRzIHRoZSBwYWNrZXQgcmVjZWl2ZWQgZnJvbSB0aGUg UE1TIHRvIExTUjEuICBBc3N1bWluZwogICBQZW4tdWx0aW1hdGUgSG9wIFBvcHBpbmcgdG8gYmUg ZGVwbG95ZWQsIExTUjEgcG9wcyB0aGUgdG9wIGxhYmVsIGFuZAogICBmb3J3YXJkcyB0aGUgcGFj a2V0IHRvIExFUiBpLiAgVGhlcmUgdGhlIHRvcCBsYWJlbCBoYXMgYSB2YWx1ZSAzMCBhbmQKICAg TEVSIGkgZm9yd2FyZHMgaXQgdG8gTEVSIGouICBUaGlzIHdpbGwgYmUgZG9uZSB0cmFuc21pdHRp bmcgdGhlCiAgIHBhY2tldCB2aWEgTFNSMSBvciBMU1IyLiAgVGhlIExTUiB3aWxsIGFnYWluIHBv cCB0aGUgdG9wIGxhYmVsLiAgTEVSCiAgIGogd2lsbCBmb3J3YXJkIHRoZSBwYWNrZXQgbm93IGNh cnJ5aW5nIHRoZSB0b3AgbGFiZWwgMTAgdG8gdGhlIFBNUwogICAoYW5kIGl0IHdpbGwgcGFzcyBh IExTUiBhbmQgTEVSIG0pLgoKICAgQSBmZXcgb2JzZXJ2YXRpb25zIG9uIHRoZSBleGFtcGxlIGdp dmVuIGluIGZpZ3VyZSAxOgoKICAgbyAgVGhlIHBhdGggUE1TIHRvIExFUiBpIG11c3QgYmUgYXZh aWxhYmxlIChpLmUuLCBhIGNvbnRpbnVpdHkgY2hlY2sKICAgICAgb25seSBhbG9uZyB0aGUgcGF0 aCB0byBMRVIgaSBtdXN0IHN1Y2NlZWQpLiAgSWYgZGVzaXJlZCwgYW4gTVBMUwogICAgICB0cmFj ZSByb3V0ZSBtYXkgYmUgdXNlZCB0byBleGFjdGx5IGRldGVjdCB0aGUgZGF0YSBwbGFuZSBwYXRo CiAgICAgIHRha2VuIGZvciB0aGlzIE1QTFMgU2VnbWVudC4gIEl0IGlzIHVzdWFsbHkgc3VmZmlj aWVudCB0byBqdXN0CiAgICAgIGFwcGx5IGFueSBvZiB0aGUgZXhpc3RpbmcgU2hvcnRlc3QgUGF0 aCByb3V0ZWQgcGF0aHMuCgogICBvICBJZiBFQ01QIGlzIGRlcGxveWVkLCBzZXBhcmF0ZSBjb250 aW51aXR5IGNoZWNrcyBtb25pdG9yaW5nIGFsbAogICAgICBwb3NzaWJsZSBwYXRocyB3aGljaCBh IHBhY2tldCBtYXkgdXNlIGJldHdlZW4gTEVSIGkgYW5kIExFUiBqIG1heQogICAgICBiZSBkZXNp cmVkLiAgVGhpcyBjYW4gYmUgZG9uZSBieSBhcHBseWluZyBhbiBNUExTIHRyYWNlIHJvdXRlCiAg ICAgIGJldHdlZW4gTEVSIGkgYW5kIExFUiBqLiAgQW5vdGhlciBvcHRpb24gaXMgdG8gdXNlIFNS IHJvdXRpbmcsIGJ1dAogICAgICB0aGlzIHdpbGwgbGlrZWx5IHJlcXVpcmUgYWRkaXRpb25hbCBs YWJlbCBpbmZvcm1hdGlvbiB3aXRoaW4gdGhlCiAgICAgIGxhYmVsIHN0YWNrIG9mIHRoZSBwaW5n IHBhY2tldC4gIEZ1cnRoZXIsIGlmIG11bHRpcGxlIGxpbmtzIGFyZQogICAgICBkZXBsb3llZCBi ZXR3ZWVuIHR3byBub2RlcywgU1IgbWV0aG9kcyB0byBhZGRyZXNzIGVhY2ggaW5kaXZpZHVhbAog ICAgICBwYXRoIHJlcXVpcmUgYW4gQWRqLVNJRCB0byBiZSBhc3NpZ25lZCB0byBlYWNoIHNpbmds ZSBpbnRlcmZhY2UuCiAgICAgIFRoaXMgbWV0aG9kIGlzIGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUg aW5mb3JtYXRpb24gLSBhIGNvbm5lY3Rpdml0eQogICAgICB2ZXJpZmljYXRpb24gYmFzZWQgb24g TVBMUyB0cmFjZXJvdXRlIHNlZW1zIHRvIGJlIGEgZmFpcmx5IGdvb2QKCgoKR2VpYiwgZXQgYWwu ICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDE3ICAgICAgICAgICAgICAgIFtQYWdl IDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU1IgTVBMUyBtb25pdG9yaW5nIHN5c3RlbSAg ICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgICAgb3B0aW9uIHRvIGRlYWwgd2l0aCBFQ01QIGFu ZCB2YWxpZGF0aW9uIG9mIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmUKICAgICAgY29ycmVsYXRpb24u CgogICBvICBUaGUgcGF0aCBMRVIgaiB0byBQTVMgbXVzdCBiZSBhdmFpbGFibGUgKGkuZS4sIGEg Y29udGludWl0eSBjaGVjawogICAgICBvbmx5IGFsb25nIHRoZSBwYXRoIGZyb20gTEVSIGogdG8g UE1TIG11c3Qgc3VjY2VlZCkuICBJZiBkZXNpcmVkLAogICAgICBhbiBNUExTIHRyYWNlIHJvdXRl IG1heSBiZSB1c2VkIHRvIGV4YWN0bHkgZGV0ZWN0IHRoZSBkYXRhIHBsYW5lCiAgICAgIHBhdGgg dGFrZW4gZm9yIHRoaXMgTVBMUyBTZWdtZW50LiAgSXQgaXMgdXN1YWxseSBzdWZmaWNpZW50IHRv CiAgICAgIGp1c3QgYXBwbHkgYW55IG9mIHRoZSBleGlzdGluZyBTaG9ydGVzdCBQYXRoIHJvdXRl ZCBwYXRocy4KCiAgIE9uY2UgdGhlIE1QTFMgcGF0aHMgKE5vZGUtU0lEcykgYW5kIHRoZSByZXF1 aXJlZCBpbmZvcm1hdGlvbiB0byBkZWFsCiAgIHdpdGggRUNNUCBoYXZlIGJlZW4gZGV0ZWN0ZWQs IHRoZSBwYXRoIGNvbnRpbnVpdHkgYmV0d2VlbiBMRVIgaSBhbmQKICAgTEVSIGogY2FuIGJlIG1v bml0b3JlZCBieSB0aGUgUE1TLiAgUGF0aCBjb250aW51aXR5IG1vbml0b3JpbmcgYnkKICAgcGlu ZyBwYWNrZXRzIGRvZXMgbm90IHJlcXVpcmUgUkZDNDM3OSBNUExTIE9BTSBmdW5jdGlvbmFsaXR5 LiAgQWxsCiAgIG1vbml0b3JpbmcgcGFja2V0cyBzdGF5IG9uIGRhdGFwbGFuZSwgaGVuY2UgcGF0 aCBjb250aW51aXR5CiAgIG1vbml0b3JpbmcgZG9lcyBub3QgcmVxdWlyZSBjb250cm9sIHBsYW5l IGludGVyYWN0aW9uIGluIGFueSBMRVIgb3IKICAgTFNSIG9mIHRoZSBkb21haW4uICBUbyBlbnN1 cmUgY29uc2lzdGVudCBpbnRlcnByZXRhdGlvbiBvZiB0aGUKICAgcmVzdWx0cywgdGhlIFBNUyBz aG91bGQgYmUgYXdhcmUgb2YgYW55IGNoYW5nZXMgaW4gSUdQIG9yIE1QTFMKICAgdG9wb2xvZ3kg b3IgRUNNUCByb3V0aW5nLiAgV2hpbGUgdGhlIGRlc2NyaXB0aW9uIGdpdmVuIGhlcmUKICAgcHJv bm91bmNpbmcgcGF0aCBjb25uZWN0aXZpdHkgY2hlY2tpbmcgYXMgYSBzaW1wbGUgYmFzaWMgYXBw bGljYXRpb24sCiAgIG90aGVycyBsaWtlIGNoZWNraW5nIGNvbnRpbnVpdHkgb2YgdW5kZXJseWlu ZyBwaHlzaWNhbCBpbmZyYXN0cnVjdHVyZQogICBvciBkZWxheSBtZWFzdXJlbWVudHMgbWF5IGJl IGRlc2lyZWQuICBJbiBib3RoIGNhc2VzLCBhIGNoYW5nZSBpbgogICBFQ01QIHJvdXRpbmcgd2hp Y2ggaXMgbm90IGNhdXNlZCBieSBhbiBJR1Agb3IgTVBMUyB0b3BvbG9neSBjaGFuZ2UKICAgbWF5 IG5vdCBiZSBkZXNpcmFibGUuICBBIFBNUyB0aGVyZWZvcmUgc2hvdWxkIGFsc28gcGVyaW9kaWNh bGx5CiAgIHZlcmlmeSBjb25uZWN0aXZpdHkgb2YgdGhlIFNSIHBhdGhzIHdoaWNoIGFyZSBtb25p dG9yZWQgZm9yCiAgIGNvbnRpbnVpdHkuCgogICBEZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhl Y3V0ZWQgcHJpb3IgdG8gYSBtZWFzdXJlbWVudCBtYXkgYWxzbyBiZQogICBkb25lIGJ5IHNldHRp bmcgdXAgYSBsYWJlbCBzdGFjayBpbmNsdWRpbmcgYWxsIE5vZGUtU0lEcyBhbG9uZyB0aGF0CiAg IHBhdGggKGlmIExTUjEgaGFzIE5vZGUgU0lEIDQwIGluIHRoZSBleGFtcGxlIGFuZCBpdCBzaG91 bGQgYmUgcGFzc2VkCiAgIGJldHdlZW4gTEVSIGkgYW5kIExFUiBqLCB0aGUgbGFiZWwgc3RhY2sg aXMgMjAgLSA0MCAtIDMwIC0gMTApLiAgVGhlCiAgIGFkdmFudGFnZSBvZiB0aGlzIG1ldGhvZCBp cywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIFJGQyA0Mzc5CiAgIGNvbm5lY3Rpdml0eSB2ZXJp ZmljYXRpb24gYW5kLCBpZiB0aGVyZSdzIG9ubHkgb25lIHBoeXNpY2FsCiAgIGNvbm5lY3Rpb24g YmV0d2VlbiBhbGwgbm9kZXMsIHRoZSBhcHByb2FjaCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QCiAg IGZ1bmN0aW9uYWxpdGllcy4gIFRoZSBtZXRob2Qgc3RpbGwgaXMgYWJsZSB0byBtb25pdG9yIGFs bCBsaW5rCiAgIGNvbWJpbmF0aW9ucyBvZiBhbGwgcGF0aHMgb2YgYW4gTVBMUyBkb21haW4uICBJ ZiBjb3JyZWN0IGZvcndhcmRpbmcKICAgYWxvbmcgdGhlIGRlc2lyZWQgcGF0aHMgaGFzIHRvIGJl IGNoZWNrZWQsIG9yIG11bHRpcGxlIHBoeXNpY2FsCiAgIGNvbm5lY3Rpb25zIGV4aXN0IGJldHdl ZW4gYW55IHR3byBub2RlcywgYWxsIEFkai1TSURzIGFsb25nIHRoYXQgcGF0aAogICBzaG91bGQg YmUgcGFydCBvZiB0aGUgbGFiZWwgc3RhY2suCgogICBJbiB0aGVvcnkgYXQgbGVhc3QsIGEgc2lu Z2xlIFBNUyBpcyBhYmxlIHRvIG1vbml0b3IgZGF0YSBwbGFuZQogICBhdmFpbGFiaWxpdHkgb2Yg YWxsIExTUHMgaW4gdGhlIGRvbWFpbi4gIFRoZSBQTVMgbWF5IGJlIGEgcm91dGVyLCBidXQKICAg Y291bGQgYWxzbyBiZSBkZWRpY2F0ZWQgbW9uaXRvcmluZyBzeXN0ZW0uICBJZiBtZWFzdXJlbWVu dCBzeXN0ZW0KICAgcmVsaWFiaWxpdHkgaXMgYW4gaXNzdWUsIG1vcmUgdGhhbiBhIHNpbmdsZSBQ TVMgbWF5IGJlIGNvbm5lY3RlZCB0bwogICB0aGUgTVBMUyBkb21haW4uCgogICBNb25pdG9yaW5n IGFuIE1QTFMgZG9tYWluIGJ5IGEgUE1TIGJhc2VkIG9uIFNSIG9mZmVycyB0aGUgb3B0aW9uIG9m CiAgIG1vbml0b3JpbmcgY29tcGxldGUgTVBMUyBkb21haW5zIHdpdGggbGltaXRlZCBlZmZvcnQg YW5kIGEgdW5pcXVlCiAgIHBvc3NpYmlsaXR5IHRvIHNjYWxlIGEgZmxleGlibGUgbW9uaXRvcmlu ZyBzb2x1dGlvbiBhcyByZXF1aXJlZCBieQoKCgpHZWliLCBldCBhbC4gICAgICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMjYsIDIwMTcgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICBTUiBNUExTIG1vbml0b3Jpbmcgc3lzdGVtICAgICAgICAgIEZlYnJ1YXJ5 IDIwMTcKCgogICB0aGUgb3BlcmF0b3IgKHRoZSBudW1iZXIgb2YgUE1TIGRlcGxveWVkIGlzIGlu ZGVwZW5kZW50IG9mIHRoZQogICBsb2NhdGlvbnMgb2YgdGhlIG9yaWdpbiBhbmQgZGVzdGluYXRp b24gb2YgdGhlIG1vbml0b3JlZCBwYXRocykuICBUaGUKICAgUE1TIGNhbiBiZSBlbmFibGVkIHRv IHNlbmQgTVBMUyBPQU0gcGFja2V0cyB3aXRoIHRoZSBsYWJlbCBzdGFja3MgYW5kCiAgIGFkZHJl c3MgaW5mb3JtYXRpb24gaWRlbnRpY2FsIHRvIHRob3NlIG9mIHRoZSBtb25pdG9yaW5nIHBhY2tl dHMgdG8KICAgYW55IG5vZGUgb2YgdGhlIE1QTFMgZG9tYWluLiAgVGhlIHJvdXRlcnMgb2YgdGhl IG1vbml0b3JlZCBkb21haW4KICAgc2hvdWxkIHN1cHBvcnQgUkZDIDQzNzkgYW5kIGl0cyBzdGFu ZGFyZGlzZWQgZXh0ZW5zaW9ucyB0byBhbGxvdyBmb3IKICAgTVBMUyB0cmFjZSByb3V0ZS4gIFBp bmcgYmFzZWQgY29udGludWl0eSBjaGVja3MgZG9uJ3QgcmVxdWlyZSByb3V0ZXIKICAgY29udHJv bCBwbGFuZSBhY3Rpdml0eS4gIFByaW9yIHRvIG1vbml0b3JpbmcgYSBwYXRoLCBNUExTIE9BTSBt YXkgYmUKICAgdXNlZCB0byBkZXRlY3QgRUNNUCBkZXBlbmRhbnQgZm9yd2FyZGluZyBvZiBhIHBh Y2tldC4gIEEgUE1TIG1heSBiZQogICBkZXNpZ25lZCB0byBsZWFybiB0aGUgSVAgYWRkcmVzcyBp bmZvcm1hdGlvbiByZXF1aXJlZCB0byBleGVjdXRlIGEKICAgcGFydGljdWxhciBFQ01QIHJvdXRl ZCBwYXRoIGFuZCBpbnRlcmZhY2VzIGFsb25nIHRoYXQgcGF0aC4gIFRoaXMKICAgYWxsb3dzIHRv IG1vbml0b3IgdGhlc2UgcGF0aHMgd2l0aCBsYWJlbCBzdGFja3MgcmVkdWNlZCB0byBhIGxpbWl0 ZWQKICAgbnVtYmVyIG9mIE5vZGUtU0lEcyByZXN1bHRpbmcgZnJvbSBTUEYgcm91dGluZy4gIFRo ZSBQTVMgZG9lcyBub3QKICAgcmVxdWlyZSBhY2Nlc3MgdG8gTFNSIC8gTEVSIG1hbmFnZW1lbnQt IG9yIGRhdGEtcGxhbmUgaW5mb3JtYXRpb24gdG8KICAgZG8gc28uCgo1LjIuICBVc2UgQ2FzZSAy IC0gTW9uaXRvcmluZyBhIFJlbW90ZSBCdW5kbGUKCgogICAgICAgICAgICAgICArLS0tKyAgICBf ICAgKy0tKyAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0rCiAgICAgICAgICAgICAgIHwgICB8 ICAgeyB9ICB8ICB8LS0tOTkxLS0tTDEtLS02NjItLS18ICAgICAgIHwKICAgICAgICAgICAgICAg fFBNU3wtLXsgICB9LXxSMXwtLS05OTItLS1MMi0tLTY2My0tLXxSMiAoNzIpfAogICAgICAgICAg ICAgICB8ICAgfCAgIHtffSAgfCAgfC0tLTk5My0tLUwzLS0tNjY0LS0tfCAgICAgICB8CiAgICAg ICAgICAgICAgICstLS0rICAgICAgICArLS0rICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsK CgogICBTUiBiYXNlZCBwcm9iaW5nIG9mIGFsbCB0aGUgbGlua3Mgb2YgYSByZW1vdGUgYnVuZGxl CgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMgoKICAgSW4gdGhlIGZp Z3VyZSwgUjEgYWRkcmVzc2VzIExpbmsgIngiIEx4IGJ5IHRoZSBBZGphY2VuY3kgU0lEIDk5eCwK ICAgd2hpbGUgUjIgYWRkcmVzc2VzIExpbmsgTHggYnkgdGhlIEFkamFjZW5jeSBTSUQgNjYoeCsx KS4KCiAgIEluIHRoZSBhYm92ZSBmaWd1cmUsIHRoZSBQTVMgbmVlZHMgdG8gYXNzZXNzIHRoZSBk YXRhcGxhbmUKICAgYXZhaWxhYmlsaXR5IG9mIGFsbCB0aGUgbGlua3Mgd2l0aGluIGEgcmVtb3Rl IGJ1bmRsZSBjb25uZWN0ZWQgdG8KICAgcm91dGVycyBSMSBhbmQgUjIuCgogICBUaGUgbW9uaXRv cmluZyBzeXN0ZW0gcmV0cmlldmVzIHRoZSBTSUQvTGFiZWwgaW5mb3JtYXRpb24gZnJvbSB0aGUK ICAgSUdQIExTREIgYW5kIGFwcGVuZHMgdGhlIGZvbGxvd2luZyBzZWdtZW50IGxpc3QvbGFiZWwg c3RhY2s6IHs3MiwKICAgNjYyLCA5OTIsIDY2NH0gb24gaXRzIElQIHByb2JlICh3aG9zZSBzb3Vy Y2UgYW5kIGRlc3RpbmF0aW9uCiAgIGFkZHJlc3NlcyBhcmUgdGhlIGFkZHJlc3Mgb2YgdGhlIFBN UykuCgogICBQTVMgc2VuZHMgdGhlIHByb2JlIHRvIGl0cyBjb25uZWN0ZWQgcm91dGVyLiAgVGhl IE1QTFMvU1IgZG9tYWluIHRoZW4KICAgZm9yd2FyZHMgdGhlIHByb2JlIHRvIFIyICg3MiBpcyB0 aGUgTm9kZSBTSUQgb2YgUjIpLiAgUjIgZm9yd2FyZHMgdGhlCiAgIHByb2JlIHRvIFIxIG92ZXIg bGluayBMMSAoQWRqYWNlbmN5IFNJRCA2NjIpLiAgUjEgZm9yd2FyZHMgdGhlIHByb2JlCiAgIHRv IFIyIG92ZXIgbGluayBMMiAoQWRqYWNlbmN5IFNJRCA5OTIpLiAgUjIgZm9yd2FyZHMgdGhlIHBy b2JlIHRvIFIxCiAgIG92ZXIgbGluayBMMyAoQWRqYWNlbmN5IFNJRCA2NjQpLiAgUjEgdGhlbiBm b3J3YXJkcyB0aGUgSVAgcHJvYmUgdG8KICAgUE1TIGFzIHBlciBjbGFzc2ljIElQIGZvcndhcmRp bmcuCgoKCkdlaWIsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAxNyAg ICAgICAgICAgICAgIFtQYWdlIDEwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNSIE1QTFMg bW9uaXRvcmluZyBzeXN0ZW0gICAgICAgICAgRmVicnVhcnkgMjAxNwoKCiAgIEFzIGhhcyBiZWVu IG1lbnRpb25lZCBpbiBzZWN0aW9uIDUuMSwgdGhlIFBNUyBtdXN0IGJlIGFibGUgbW9uaXRvcgog ICBjb250aW51aXR5IG9mIHRoZSBwYXRoIFBNUyB0byBSMiAoTm9kZS1TSUQgNzIpIGFzIHdlbGwg YXMgY29udGludWl0eQogICBmcm9tIFIxIHRvIHRoZSBQTVMuICBJZiBib3RoIGFyZSBnaXZlbiBh bmQgcGFja2V0cyBhcmUgbG9zdCwKICAgZm9yd2FyZGluZyBvbiBvbmUgb2YgdGhlIHRocmVlIGlu dGVyZmFjZXMgY29ubmVjdGluZyBSMSB0byBSMiBtdXN0IGJlCiAgIGRpc3R1cmJlZC4KCjUuMy4g IFVzZSBDYXNlIDMgLSBGYXVsdCBMb2NhbGl6YXRpb24KCiAgIEluIHRoZSBwcmV2aW91cyBleGFt cGxlLCBhIHVuaS1kaXJlY3Rpb25hbCBmYXVsdCBvbiB0aGUgbWlkZGxlIGxpbmsKICAgaW4gZGly ZWN0aW9uIG9mIFIyIHRvIFIxIHdvdWxkIGJlIGxvY2FsaXplZCBieSBzZW5kaW5nIHRoZSBmb2xs b3dpbmcKICAgdHdvIHByb2JlcyB3aXRoIHJlc3BlY3RpdmUgc2VnbWVudCBsaXN0czoKCiAgIG8g IDcyLCA2NjIsIDk5MiwgNjY0CgogICBvICA3MiwgNjYzLCA5OTIsIDY2NAoKICAgVGhlIGZpcnN0 IHByb2JlIHdvdWxkIHN1Y2NlZWQgd2hpbGUgdGhlIHNlY29uZCB3b3VsZCBmYWlsLgogICBDb3Jy ZWxhdGlvbiBvZiB0aGUgbWVhc3VyZW1lbnRzIHJldmVhbHMgdGhhdCB0aGUgb25seSBkaWZmZXJl bmNlIGlzCiAgIHVzaW5nIHRoZSBBZGphY2VuY3kgU0lEIDY2MyBvZiB0aGUgbWlkZGxlIGxpbmsg ZnJvbSBSMiB0byBSMSBpbiB0aGUKICAgbm9uIHN1Y2Nlc3NmdWwgbWVhc3VyZW1lbnQuICBBc3N1 bWluZyB0aGUgc2Vjb25kIHByb2JlIGhhcyBiZWVuCiAgIHJvdXRlZCBjb3JyZWN0bHksIHRoZSBm YXVsdCBtdXN0IGhhdmUgYmVlbiBvY2N1cnJpbmcgaW4gUjIgd2hpY2gKICAgZGlkbid0IGZvcndh cmQgdGhlIHBhY2tldCB0byB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZWQgYnkgaXRzCiAgIEFkamFj ZW5jeSBTSUQgNjYzLgoKICAgVGhlIGV4YW1wbGUgYWJvdmUgb25seSBpbGx1c3RyYXRlcyBhIG1l dGhvZCB0byBsb2NhbGlzZSBhIGZhdWx0IGJ5CiAgIGNvcnJlbGF0ZWQgY29udGludWl0eSBjaGVj a3MuICBBbnkgb3BlcmF0aW9uYWwgZGVwbG95bWVudCByZXF1aXJlcyBhCiAgIHdlbGwgZGVzaWdu ZWQgZW5naW5lZXJpbmcgdG8gYWxsb3cgZm9yIHRoZSBkZXNpcmVkIG5vbiBhbWJpZ3VvdXMKICAg ZGlhZ25vc2lzIG9uIHRoZSBtb25pdG9yZWQgc2VjdGlvbiBvZiB0aGUgU1IgbmV0d29yay4gICdT ZWN0aW9uJyBoZXJlCiAgIGNvdWxkIGJlIGEgcGF0aCwgYSBzaW5nbGUgcGh5c2ljYWwgaW50ZXJm YWNlLCB0aGUgc2V0IG9mIGFsbCBsaW5rcyBvZgogICBhIGJ1bmRsZSBvciBhbiBhZGphY2VuY3kg b2YgdHdvIG5vZGVzLCBqdXN0IHRvIG5hbWUgYSBmZXcuICBTdWNoIGEKICAgZGVzaWduIGlzIG5v dCB3aXRoaW4gc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCjYuICBGYWlsdXJlIE5vdGlmaWNhdGlv biBmcm9tIFBNUyB0byBMRVJpCgogICBQTVMgb24gZGV0ZWN0aW5nIGFueSBmYWlsdXJlIGluIHRo ZSBwYXRoIGxpdmVsaW5lc3MgbWF5IHVzZSBhbnkgb3V0LQogICBvZi1iYW5kIG1lY2hhbmlzbSB0 byBzaWduYWwgdGhlIGZhaWx1cmUgdG8gTEVSIGkuICBUaGlzIGRvY3VtZW50IGRvZXMKICAgbm90 IHByb3Bvc2UgYW55IHNwZWNpZmljIG1lY2hhbmlzbSBhbmQgb3BlcmF0b3JzIGNhbiBjaG9vc2Ug YW55CiAgIGV4aXN0aW5nIG9yIG5ldyBhcHByb2FjaC4KCiAgIEFsdGVybmF0ZWx5LCB0aGUgT3Bl cmF0b3IgbWF5IGxvZyB0aGUgZmFpbHVyZSBpbiBsb2NhbCBtb25pdG9yaW5nCiAgIHN5c3RlbSBh bmQgdGFrZSBuZWNlc3NhcnkgYWN0aW9uIGJ5IG1hbnVhbCBpbnRlcnZlbnRpb24uCgo3LiAgQXBw bHlpbmcgU1IgdG8gTW9uaXRvcmluZyBub24tU1IgYmFzZWQgTFNQcyAoTERQIGFuZCBwb3NzaWJs eSBSU1ZQLQogICAgVEUpCgogICBUaGUgTVBMUyBwYXRoIG1vbml0b3Jpbmcgc3lzdGVtIGRlc2Ny aWJlZCBieSB0aGlzIGRvY3VtZW50IGNhbiBiZQogICByZWFsaXNlZCB3aXRoIHByZS1TZWdtZW50 IFJvdXRpbmcgKFNSKSBiYXNlZCB0ZWNobm9sb2d5LiAgTWFraW5nIHN1Y2gKICAgYSBwcmUtU1Ig TVBMUyBtb25pdG9yaW5nIHN5c3RlbSBhd2FyZSBvZiBhIGRvbWFpbidzIGNvbXBsZXRlIE1QTFMK CgoKR2VpYiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDE3ICAgICAg ICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU1IgTVBMUyBtb25p dG9yaW5nIHN5c3RlbSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgdG9wb2xvZ3kgcmVxdWly ZXMsIGUuZy4sIG1hbmFnZW1lbnQgcGxhbmUgYWNjZXNzIHRvIHRoZSByb3V0ZXJzIG9mCiAgIHRo ZSBkb21haW4gdG8gYmUgbW9uaXRvcmVkIG9yIHNldCB1cCBvZiBhIGRlZGljYXRlZCBULUxEUCB0 dW5uZWwgcGVyCiAgIHJvdXRlciB0byBzZXQgdXAgYW4gTERQIGFkamFjZW5jeS4gIFRvIGF2b2lk IHRoZSB1c2Ugb2Ygc3RhbGUgTVBMUwogICBsYWJlbCBpbmZvcm1hdGlvbiwgdGhlIElHUCBtdXN0 IGJlIG1vbml0b3JlZCBhbmQgTVBMUyB0b3BvbG9neSBtdXN0CiAgIGJlIHRpbWVseSBhbGlnbmVk IHdpdGggSUdQIHRvcG9sb2d5LiAgT2J2aW91c2x5LCBlbmhhbmNpbmcgSUdQcyB0bwogICBleGNo YW5nZSBvZiBNUExTIHRvcG9sb2d5IGluZm9ybWF0aW9uIGFzIGRvbmUgYnkgU1Igc2lnbmlmaWNh bnRseQogICBzaW1wbGlmaWVzIGFuZCBzdGFiaWxpc2VzIHN1Y2ggYW4gTVBMUyBwYXRoIG1vbml0 b3Jpbmcgc3lzdGVtLgoKICAgQSBTUiBiYXNlZCBQTVMgY29ubmVjdGVkIHRvIGEgTVBMUyBkb21h aW4gY29uc2lzdGluZyBvZiBMRVIgYW5kIExTUgogICBzdXBwb3J0aW5nIFNSIGFuZCBMRFAgb3Ig UlNWUC1URSBpbiBwYXJhbGxlbCBpbiBhbGwgbm9kZXMgbWF5IHVzZSBTUgogICBwYXRocyB0byB0 cmFuc21pdCBwYWNrZXRzIHRvIGFuZCBmcm9tIHN0YXJ0IGFuZCBlbmQgcG9pbnRzIG9mIG5vbi1T UgogICBiYXNlZCBMU1AgcGF0aHMgdG8gYmUgbW9uaXRvcmVkLiAgSW4gdGhlIGFib3ZlIGV4YW1w bGUsIHRoZSBsYWJlbAogICBzdGFjayB0b3AgdG8gYm90dG9tIG1heSBiZSBhcyBmb2xsb3dzLCB3 aGVuIHNlbnQgYnkgdGhlIFBNUzoKCiAgIG8gIFRvcDogU1IgYmFzZWQgTm9kZS1TSUQgb2YgTEVS IGkgYXQgTEVSIG0uCgogICBvICBOZXh0OiBMRFAgb3IgUlNWUC1URSBsYWJlbCBpZGVudGlmeWlu ZyB0aGUgcGF0aCBvciB0dW5uZWwsCiAgICAgIHJlc3BlY3RpdmVseSBmcm9tIExFUiBpIHRvIExF UiBqIChhdCBMRVIgaSkuCgogICBvICBCb3R0b206IFNSIGJhc2VkIE5vZGUtU0lEIGlkZW50aWZ5 aW5nIHRoZSBwYXRoIHRvIHRoZSBQTVMgYXQgTEVSIGoKCiAgIFdoaWxlIHRoZSBtaXhlZCBvcGVy YXRpb24gc2hvd24gaGVyZSBzdGlsbCByZXF1aXJlcyB0aGUgUE1TIHRvIGJlCiAgIGF3YXJlIG9m IHRoZSBMRVIgTERQLU1QTFMgdG9wb2xvZ3ksIHRoZSBQTVMgbWF5IGxlYXJuIHRoZSBTUiBNUExT CiAgIHRvcG9sb2d5IGJ5IElHUCBhbmQgdXNlIHRoaXMgaW5mb3JtYXRpb24uCgogICBBbiBpbXBs ZW1lbnRhdGlvbiByZXBvcnQgb24gYSBQTVMgb3BlcmF0aW5nIGluIGFuIExEUCBkb21haW4gaXMg Z2l2ZW4KICAgaW4gW0ktRC5sZWlwbml0ei1zcHJpbmctcG1zLWltcGxlbWVudGF0aW9uLXJlcG9y dF0uICBJbiBhZGRpdGlvbiwKICAgdGhpcyByZXBvcnQgY29tcGFyZXMgZGVsYXlzIG1lYXN1cmVk IHdpdGggYSBzaW5nbGUgUE1TIHRvIHRoZSByZXN1bHRzCiAgIG1lYXN1cmVkIGJ5IHRocmVlIElQ IFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IFdvcmsgR3JvdXAgKElQUE0gV0cpCiAgIHN0YW5kYXJk IGNvbmZvcm1hbnQgTWVhc3VyZW1lbnQgQWdlbnRzIChjb25uZWN0ZWQgdG8gYW4gTVBMUyBkb21h aW4KICAgYXQgdGhyZWUgZGlmZmVyZW50IHNpdGVzKS4gIFRoZSBkZWxheSBtZWFzdXJlbWVudHMg b2YgdGhlIFBNUyBhbmQgdGhlCiAgIElQUE0gTWVhc3VyZW1lbnQgQWdlbnRzIHdlcmUgY29tcGFy ZWQgYmFzZWQgb24gYSBzdGF0aXN0aWNhbCB0ZXN0CiAgIHB1Ymxpc2hlZCBieSB0aGUgSVBQTSBX R1tSRkM2NTc2XS4gIFRoZSBBbmRlcnNvbiBEYXJsaW5nIGstc2FtcGxlCiAgIHRlc3Qgc2hvd2Vk IHRoYXQgdGhlIFBNUyByb3VuZC10cmlwIGRlbGF5IG1lYXN1cmVtZW50cyBhcmUgZXF1YWwgdG8K ICAgdGhvc2UgY2FwdHVyZWQgYnkgYW4gSVBQTSBjb25mb3JtYW50IElQIG1lYXN1cmVtZW50IHN5 c3RlbSBmb3IgNjQKICAgQnl0ZSBtZWFzdXJlbWVudCBwYWNrZXRzIHdpdGggOTUlIGNvbmZpZGVu Y2UuCgogICBUaGUgYXV0aG9ycyBhcmUgbm90IGF3YXJlIG9mIHNpbWlsYXIgZGVwbG95bWVudCBm b3IgUlNWUC1URS4KICAgSWRlbnRpZmljYXRpb24gb2YgdHVubmVsIGVudHJ5LSBhbmQgdHJhbnNp dC1ub2RlcyBtYXkgYWRkIGNvbXBsZXhpdHkuCiAgIFRoZXkgYXJlIG5vdCB3aXRoaW4gc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4KCjguICBQTVMgTW9uaXRvcmluZyBvZiBEaWZmZXJlbnQgU2VnbWVu dCBJRCBUeXBlcwoKICAgTVBMUyBTUiB0b3BvbG9neSBhd2FyZW5lc3Mgc2hvdWxkIGFsbG93IHRo ZSBQTVMgdG8gbW9uaXRvciBsaXZlbGluZXNzCiAgIG9mIFNJRHMgcmVsYXRlZCB0byBpbnRlcmZh Y2VzIHdpdGhpbiB0aGUgU1IgYW5kIElHUCBkb21haW4sCiAgIHJlc3BlY3RpdmVseS4gIFRyYWNp bmcgYSBwYXRoIHdoZXJlIGFuIFNSIGNhcGFibGUgbm9kZSBhc3NpZ25zIGFuCiAgIEFkai1TSUQg Zm9yIGEgbm9uLVNSLWNhcGFibGUgbm9kZSBtYXkgZmFpbC4gIFRoaXMgYW5kIG90aGVyIGJhY2t3 YXJkCgoKCgpHZWliLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMTcg ICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICBTUiBNUExT IG1vbml0b3Jpbmcgc3lzdGVtICAgICAgICAgIEZlYnJ1YXJ5IDIwMTcKCgogICBjb21wYXRpYmls aXR5IHdpdGggbm9uIFNlZ21lbnQgUm91dGluZyBkZXZpY2VzIGFyZSBkaXNjdXNzZWQgYnkKICAg W0ktRC5kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5nXS4KCiAgIFRvIG1hdGNoIGNvbnRy b2wgcGxhbmUgaW5mb3JtYXRpb24gd2l0aCBkYXRhIHBsYW5lIGluZm9ybWF0aW9uIGZvcgogICBh bGwgcmVsZXZhbnQgdHlwZXMgb2YgU2VnbWVudCBJRHMsCiAgIFtJLUQuZHJhZnQtaWV0Zi1tcGxz LXNwcmluZy1sc3AtcGluZ11lbmhhbmNlcyBNUExTIE9BTSBmdW5jdGlvbnMKICAgZGVmaW5lZCBi eSBSRkMgNDM3OSBbUkZDNDM3OV0uCgo5LiAgQ29ubmVjdGl2aXR5IFZlcmlmaWNhdGlvbiBVc2lu ZyBQTVMKCiAgIFdoaWxlIHRoZSBQTVMgYmFzZWQgdXNlIGNhc2VzIGV4cGxhaW5lZCBpbiBTZWN0 aW9uIDUgYXJlIHN1ZmZpY2llbnQKICAgdG8gcHJvdmlkZSBjb250aW51aXR5IGNoZWNrIGJldHdl ZW4gTEVSIGkgYW5kIExFUiBqLCBpdCBtYXkgbm90IGhlbHAKICAgcGVyZm9ybSBjb25uZWN0aXZp dHkgdmVyaWZpY2F0aW9uLiAgU28gaW4gc29tZSBjYXNlcyBsaWtlIGRhdGEgcGxhbmUKICAgcHJv Z3JhbW1pbmcgY29ycnVwdGlvbiwgaXQgaXMgcG9zc2libGUgdGhhdCBhIHRyYW5zaXQgbm9kZSBi ZXR3ZWVuCiAgIExFUiBpIGFuZCBMRVIgaiBlcnJvbmVvdXNseSByZW1vdmVzIHRoZSB0b3Agc2Vn bWVudCBJRCBhbmQgZm9yd2FyZHMgYQogICBtb25pdG9yaW5nIHBhY2tldCB0byB0aGUgUE1TIGJh c2VkIG9uIHRoZSBib3R0b20gc2VnbWVudCBJRCBsZWFkaW5nCiAgIHRvIGEgZmFsc2lmaWVkIHBh dGggbGl2ZWxpbmVzcyBpbmRpY2F0aW9uIGJ5IHRoZSBQTVMuCgogICBUaGVyZSBhcmUgdmFyaW91 cyBtZXRob2QgdG8gcGVyZm9ybSBiYXNpYyBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uCiAgIGxp a2UgaW50ZXJtaXR0ZW50bHkgc2V0dGluZyB0aGUgVFRMIHRvIDEgaW4gYm90dG9tIGxhYmVsIHNv IExFUiBqCiAgIHNlbGVjdGl2ZWx5IHBlcmZvcm0gY29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbi4g IE90aGVyIG1ldGhvZHMgYXJlCiAgIHBvc3NpYmxlIGFuZCBtYXkgYmUgYWRkZWQgd2hlbiByZXF1 aXJlbWVudHMgYW5kIHNvbHV0aW9ucyBhcmUKICAgc3BlY2lmaWVkLgoKMTAuICBFeHRlbnNpb25z IG9mIFNwZWNpZmljYXRpb25zIFJlbGV2YW50IHRvIHRoaXMgVXNlIENhc2UKCiAgIFRoZSBmb2xs b3dpbmcgYWN0aXZpdGllcyBhcmUgd2VsY29tZSBlbmhhbmNlbWVudHMgc3VwcG9ydGluZyB0aGlz IHVzZQogICBjYXNlLCBidXQgdGhleSBhcmUgbm90IHBhcnQgb2YgaXQ6CgogICBSRkM0Mzc5IFtS RkM0Mzc5XSBmdW5jdGlvbnMgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgRmxvdy0gYW5k CiAgIEVudHJvcHkgTGFiZWwgYmFzZWQgRUNNUC4KCjExLiAgSUFOQSBDb25zaWRlcmF0aW9ucwoK ICAgVGhpcyBtZW1vIGluY2x1ZGVzIG5vIHJlcXVlc3QgdG8gSUFOQS4KCjEyLiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMKCiAgIEFzIG1lbnRpb25lZCBpbiB0aGUgaW50cm9kdWN0aW9uLCBhIFBN UyBtb25pdG9yaW5nIHBhY2tldCBzaG91bGQKICAgbmV2ZXIgbGVhdmUgdGhlIGRvbWFpbiB3aGVy ZSBpdCBvcmlnaW5hdGVkLiAgSXQgdGhlcmVmb3JlIHNob3VsZAogICBuZXZlciB1c2Ugc3RhbGUg TVBMUyBvciBJR1Agcm91dGluZyBpbmZvcm1hdGlvbi4gIEZ1cnRoZXIsIGFzc2lnbmluZwogICBk aWZmZXJlbnQgbGFiZWwgcmFuZ2VzIGZvciBkaWZmZXJlbnQgcHVycG9zZXMgbWF5IGJlIHVzZWZ1 bC4gIEEgd2VsbAogICBrbm93biBnbG9iYWwgc2VydmljZSBsZXZlbCByYW5nZSBtYXkgYmUgZXhj bHVkZWQgZm9yIHV0aWxpc2F0aW9uCiAgIHdpdGhpbiBQTVMgbWVhc3VyZW1lbnQgcGFja2V0cy4g IFRoZXNlIGlkZWFzIHNob3VsZG4ndCBzdGFydCBhCiAgIGRpc2N1c3Npb24uICBUaGV5IHJhdGhl ciBzaG91bGQgcG9pbnQgb3V0LCB0aGF0IHN1Y2ggYSBkaXNjdXNzaW9uIGlzCiAgIHJlcXVpcmVk IHdoZW4gU1IgYmFzZWQgT0FNIG1lY2hhbmlzbXMgbGlrZSBhIFNSIGFyZSBzdGFuZGFyZGlzZWQu CgoKCgoKR2VpYiwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDI2LCAyMDE3ICAg ICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgU1IgTVBMUyBt b25pdG9yaW5nIHN5c3RlbSAgICAgICAgICBGZWJydWFyeSAyMDE3CgoKICAgU2hvdWxkIHRoZSBh cHByb2FjaCBvZiBhIFBNUyBjb25uZWN0ZWQgdG8gYW4gU1IgZG9tYWluIGJ5IGEgdHVubmVsIGJl CiAgIHBpY2tlZCB1cCwgc29tZSBmdW5kYW1lbnRhbCBNUExTIHNlY3VyaXR5IHByb3BlcnRpZXMg bmVlZCB0byBiZQogICBkaXNjdXNzZWQuICBNUExTIGRvbWFpbnMgc28gZmFyIGFsbG93IHRvIHNl cGFyYXRlIHRoZSBNUExTIG5ldHdvcmsKICAgZnJvbSBhbiBJUCBuZXR3b3JrIGJ5IGFsbG93aW5n IG5vIHR1bm5lbGVkIE1QTFMgYWNjZXNzIHRvIGFuIE1QTFMKICAgZG9tYWluLgoKMTMuICBBY2tu b3dsZWRnZW1lbnRzCgogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIE5vYm8gQWtp eWEgZm9yIGhpcyBjb250cmlidXRpb24uCiAgIFJhaWsgTGVpcG5pdHoga2luZGx5IHByb3ZpZGVk IGFuIGVkaXRvcmlhbCByZXZpZXcuICBUaGUgYXV0aG9ycyB3b3VsZAogICBhbHNvIGxpa2UgdG8g dGhhbmsgRmFpc2FsIElxYmFsIGZvciBhbiBpbnNpZ2h0ZnVsIHJldmlldyBhbmQgYSB1c2VmdWwK ICAgc2V0IG9mIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4gIEZpbmFsbHksIEJydW5vIERlY3Jh ZW5lJ3Mgc2hlcGVyZAogICByZXZpZXcgbGVkIHRvIGEgY2xhcmlmaWVkIGRvY3VtZW50LgoKMTQu ICBSZWZlcmVuY2VzCgoxNC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkM0Mzc5XSAg S29tcGVsbGEsIEsuIGFuZCBHLiBTd2FsbG93LCAiRGV0ZWN0aW5nIE11bHRpLVByb3RvY29sCiAg ICAgICAgICAgICAgTGFiZWwgU3dpdGNoZWQgKE1QTFMpIERhdGEgUGxhbmUgRmFpbHVyZXMiLCBS RkMgNDM3OSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNDM3OSwgRmVicnVhcnkgMjAw NiwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQzNzk+ LgoKICAgW1JGQzcyNzZdICBNaXpyYWhpLCBULiwgU3ByZWNoZXIsIE4uLCBCZWxsYWdhbWJhLCBF LiwgYW5kIFkuCiAgICAgICAgICAgICAgV2VpbmdhcnRlbiwgIkFuIE92ZXJ2aWV3IG9mIE9wZXJh dGlvbnMsIEFkbWluaXN0cmF0aW9uLAogICAgICAgICAgICAgIGFuZCBNYWludGVuYW5jZSAoT0FN KSBUb29scyIsIFJGQyA3Mjc2LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3Mjc2LCBK dW5lIDIwMTQsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmM3Mjc2Pi4KCjE0LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmRyYWZ0LWll dGYtbXBscy1zcHJpbmctbHNwLXBpbmddCiAgICAgICAgICAgICAgSUVURiwgIkxhYmVsIFN3aXRj aGVkIFBhdGggKExTUCkgUGluZy9UcmFjZSBmb3IgU2VnbWVudAogICAgICAgICAgICAgIFJvdXRp bmcgTmV0d29ya3MgVXNpbmcgTVBMUyBEYXRhcGxhbmUiLCBJRVRGLAogICAgICAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbXBscy1zcHJpbmctCiAg ICAgICAgICAgICAgbHNwLXBpbmcvLCAyMDE2LgoKICAgW0ktRC5pZXRmLWlkci1iZ3AtbHMtc2Vn bWVudC1yb3V0aW5nLWV4dF0KICAgICAgICAgICAgICBJRVRGLCAiQkdQIExpbmstU3RhdGUgZXh0 ZW5zaW9ucyBmb3IgU2VnbWVudCBSb3V0aW5nIiwKICAgICAgICAgICAgICBJRVRGLCAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItCiAgICAgICAgICAgICAg YmdwLWxzLXNlZ21lbnQtcm91dGluZy1leHQvLCAyMDE2LgoKICAgW0ktRC5pZXRmLWlzaXMtc2Vn bWVudC1yb3V0aW5nLWV4dGVuc2lvbnNdCiAgICAgICAgICAgICAgSUVURiwgIklTLUlTIEV4dGVu c2lvbnMgZm9yIFNlZ21lbnQgUm91dGluZyIsIElFVEYsCiAgICAgICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtCiAgICAgICAg ICAgICAgcm91dGluZy1leHRlbnNpb25zLywgMjAxNi4KCgoKCgpHZWliLCBldCBhbC4gICAgICAg ICAgICAgRXhwaXJlcyBBdWd1c3QgMjYsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSAxNF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICBTUiBNUExTIG1vbml0b3Jpbmcgc3lzdGVtICAgICAgICAg IEZlYnJ1YXJ5IDIwMTcKCgogICBbSS1ELmlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5z aW9uc10KICAgICAgICAgICAgICBJRVRGLCAiT1NQRiBFeHRlbnNpb25zIGZvciBTZWdtZW50IFJv dXRpbmciLCBJRVRGLAogICAgICAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LQogICAgICAgICAgICAgIHJvdXRpbmctZXh0ZW5z aW9ucy8sIDIwMTYuCgogICBbSS1ELmlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ10KICAgICAg ICAgICAgICBJRVRGLCAiU2VnbWVudCBSb3V0aW5nIEFyY2hpdGVjdHVyZSIsIElFVEYsCiAgICAg ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJp bmctCiAgICAgICAgICAgICAgc2VnbWVudC1yb3V0aW5nLywgMjAxNi4KCiAgIFtJLUQuaWV0Zi1z cHJpbmctc3Itb2FtLXJlcXVpcmVtZW50XQogICAgICAgICAgICAgIElFVEYsICJPQU0gUmVxdWly ZW1lbnRzIGZvciBTZWdtZW50IFJvdXRpbmcgTmV0d29yayIsCiAgICAgICAgICAgICAgSUVURiwg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5nLQogICAg ICAgICAgICAgIHNyLW9hbS1yZXF1aXJlbWVudC8sIDIwMTYuCgogICBbSS1ELmxlaXBuaXR6LXNw cmluZy1wbXMtaW1wbGVtZW50YXRpb24tcmVwb3J0XQogICAgICAgICAgICAgIExlaXBuaXR6LCBS LiBhbmQgUi4gR2VpYiwgIkEgc2NhbGFibGUgYW5kIHRvcG9sb2d5IGF3YXJlCiAgICAgICAgICAg ICAgTVBMUyBkYXRhIHBsYW5lIG1vbml0b3Jpbmcgc3lzdGVtIiwgSUVURiwgIGRyYWZ0LWxlaXBu aXR6LQogICAgICAgICAgICAgIHNwcmluZy1wbXMtaW1wbGVtZW50YXRpb24tcmVwb3J0LTAwLCAy MDE2LgoKICAgW1JGQzY1NzZdICBHZWliLCBSLiwgRWQuLCBNb3J0b24sIEEuLCBGYXJkaWQsIFIu LCBhbmQgQS4gU3RlaW5taXR6LAogICAgICAgICAgICAgICJJUCBQZXJmb3JtYW5jZSBNZXRyaWNz IChJUFBNKSBTdGFuZGFyZCBBZHZhbmNlbWVudAogICAgICAgICAgICAgIFRlc3RpbmciLCBCQ1Ag MTc2LCBSRkMgNjU3NiwgRE9JIDEwLjE3NDg3L1JGQzY1NzYsIE1hcmNoCiAgICAgICAgICAgICAg MjAxMiwgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2NTc2Pi4KCkF1dGhvcnMn IEFkZHJlc3NlcwoKICAgUnVlZGlnZXIgR2VpYiAoZWRpdG9yKQogICBEZXV0c2NoZSBUZWxla29t CiAgIEhlaW5yaWNoIEhlcnR6IFN0ci4gMy03CiAgIERhcm1zdGFkdCAgNjQyOTUKICAgR2VybWFu eQoKICAgUGhvbmU6ICs0OSA2MTUxIDU4MTI3NDcKICAgRW1haWw6IFJ1ZWRpZ2VyLkdlaWJAdGVs ZWtvbS5kZQoKCiAgIENsYXJlbmNlIEZpbHNmaWxzCiAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAg QnJ1c3NlbHMKICAgQmVsZ2l1bQoKICAgRW1haWw6IGNmaWxzZmlsQGNpc2NvLmNvbQoKCgoKCgoK CkdlaWIsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyNiwgMjAxNyAgICAgICAg ICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgIFNSIE1QTFMgbW9uaXRv cmluZyBzeXN0ZW0gICAgICAgICAgRmVicnVhcnkgMjAxNwoKCiAgIENhcmxvcyBQaWduYXRhcm8g KGVkaXRvcikKICAgQ2lzY28gU3lzdGVtcywgSW5jLgogICA3MjAwIEtpdCBDcmVlayBSb2FkCiAg IFJlc2VhcmNoIFRyaWFuZ2xlIFBhcmssIE5DICAyNzcwOS00OTg3CiAgIFVTCgogICBFbWFpbDog Y3BpZ25hdGFAY2lzY28uY29tCgoKICAgTmFnZW5kcmEgS3VtYXIKICAgQ2lzY28gU3lzdGVtcywg SW5jLgogICA3MjAwIEtpdCBDcmVlayBSb2FkCiAgIFJlc2VhcmNoIFRyaWFuZ2xlIFBhcmssIE5D ICAyNzcwOQogICBVUwoKICAgRW1haWw6IG5haWt1bWFyQGNpc2NvLmNvbQoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkdlaWIsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEF1 Z3VzdCAyNiwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDE2XQo= --_004_53C29892C857584299CBF5D05346208A1ED74D8EOPEXCLILM21corp_-- From nobody Thu Feb 23 04:08:18 2017 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 D509A12A1A0; Thu, 23 Feb 2017 04:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, 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=eci365.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 mQsvOnZxPnsD; Thu, 23 Feb 2017 04:08:13 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0137.outbound.protection.outlook.com [104.47.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D4E1296DC; Thu, 23 Feb 2017 04:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iEQRrKQcvWRaZBiHy6DLeGb/dbali6Qq8d7BmItCjx8=; b=Uq0lvTAXnLwWKfxDHXW9Nw0bVaw5fSTwqhpGt/83P9yJUVzD0xND/qDPEPM3d1hG4nGFKZfdZDesGTAThLRRMZxiyWik1+crYu9E5Y3e4VG+WhMMDOPyGnU2HjLRGbROJpKREfZvjo6m/q3ZVORwLuoFMJK6PCeFBRhtq4BAYHw= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2569.eurprd03.prod.outlook.com (10.168.125.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 12:08:07 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 12:08:07 +0000 From: Alexander Vainshtein To: "draft-ietf-isis-segment-routing-extensions@ietf.org" Thread-Topic: A question regarding IS-IS Segment Routing Extensions Thread-Index: AdKNyy6fYQKN924yQXSA3llgPNQdyQ== Date: Thu, 23 Feb 2017 12:08:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2569; 7:XaF+GjoIngQP1Ozc6YE5f/ORKprdKaLreTMgqVhZtdmS4hxrTutZaLHZE3dvipMaVVu/WrkGHUDZ4+PDYhUCsJqCkGEVTVyHTqZDREtZGrjFvWqd1APYYZ7gfWks9AHaz1pkCmX+JpvZLW+xSNOY5v9/slRFw0AU16wsyGCnfHaEx0t1J0BX34pkzC2MOg7rWnzXPqx7AkUWlAd+dP0oBdsg96Q4gHHYV2XAn+YKi1ldFkJJ7QsSHpzze3wtWmAEWm5TSk7QHoeQrIpcmyFPtqvcN9Q03XbOv5HGgW/8S9OrsB2RhiZzugO05bp8FeQ/hrX9/dq+LLURdGzIRSBgig== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(39850400002)(51874003)(53754006)(199003)(252514010)(189002)(102836003)(5660300001)(66066001)(81156014)(8676002)(97736004)(8936002)(81166006)(99286003)(189998001)(2900100001)(5630700001)(7696004)(92566002)(38730400002)(53936002)(107886003)(7736002)(110136004)(68736007)(122556002)(5640700003)(3280700002)(6506006)(3660700001)(25786008)(9686003)(54906002)(54896002)(54356999)(6116002)(50986999)(790700001)(77096006)(6916009)(55016002)(101416001)(2351001)(106356001)(74316002)(4326007)(33656002)(86362001)(6436002)(2501003)(3846002)(6306002)(105586002)(2906002)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2569; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 3dfe0cc6-40ba-4c1e-835b-08d45be4a0bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0301MB2569; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:HE1PR0301MB2569; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2569; x-forefront-prvs: 02272225C5 received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB226655A07BFE439DABAFC4569D530HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 12:08:07.2347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2569 Archived-At: Cc: "isis@ietf.org" , "spring@ietf.org" , Rotem Cohen , Michael Gorokhovsky , Ron Sdayoor Subject: [spring] A question regarding IS-IS Segment Routing Extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 12:08:17 -0000 --_000_HE1PR0301MB226655A07BFE439DABAFC4569D530HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, My colleagues and I have a couple of questions about some behavioral aspect= s of IS-IS Segment Routing (SR) extensions. Suppose that we have an IS-IS domain where some routers run IS-IS with SR e= xtensions, and some routers run "vanilla" IS-IS for IPv4. 1. What is supposed to happen when router A that runs IS-ISD without = SR extensions establishes an adjacency with router B that runs IS-IS with S= R extensions. Our expectations are that: a. An adjacency between A and B would be allowed to progress to its F= ULL state. Is that correct? b. B will distribute all SR-related TLVs and sub-TLVs to A. Is that co= rrect? c. A will silently discard all SR-related TLVs and sub-TLVs it has re= ceived from B. Is that correct? 2. What is supposed to happen if IS-IS adjacency between A and B reac= hes its FULL state, and then SR extensions are enabled in A. We expect that= : a. It is possible to enable SR extensions in A without resetting its = adjacency with B (or any other adjacent router). Is that correct? b. Once B learns that SR capabilities of A have changed, it floods its= LSP database with all SR-related TLVs and sub-TLVs to A. Is that correct? A brief scan of the draft did not yield answers to any of the questions abo= ve. Timely feedback would be very highly appreciated. Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com --_000_HE1PR0301MB226655A07BFE439DABAFC4569D530HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

My colleagues and I have a couple of questions about= some behavioral aspects of IS-IS Segment Routing (SR) extensions.

 

Suppose that we have an IS-IS domain where some rout= ers run IS-IS with SR extensions, and some routers run “vanilla”= ; IS-IS for IPv4.

1.     &= nbsp; What is supposed to happen= when router A that runs IS-ISD without SR extensions establishes an adjace= ncy with router B that runs IS-IS with SR extensions. Our expectations are = that:

a.       An adjacency between A and= B would be allowed to progress to its FULL state. Is that correct?

b.      B will distribute all SR-r= elated TLVs and sub-TLVs to A. Is that correct?

c.       A will silently discard al= l SR-related TLVs and sub-TLVs it has received from B. Is that correct?

2.     &= nbsp; What is supposed to happen= if IS-IS adjacency between A and B reaches its FULL state, and then SR ext= ensions are enabled in A. We expect that:

a.       It is possible to enable S= R extensions in A without resetting its adjacency with B (or any other adja= cent router). Is that correct?

b.      Once B learns that SR capa= bilities of A have changed, it floods its LSP database with all SR-related = TLVs and sub-TLVs to A. Is that correct?

 

 

A brief scan of the draft did not yield answers to a= ny of the questions above. Timely feedback would be very highly appreciated= .

 

Regards, and lots of thanks in advance,

Sasha

 

Office: +972-39266302

Cell:      +972-5492663= 02

Email:   Alexander.Vainshtein@ecitele.com<= o:p>

 

--_000_HE1PR0301MB226655A07BFE439DABAFC4569D530HE1PR0301MB2266_-- From nobody Thu Feb 23 05:45:21 2017 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 E4B6E1297A7; Thu, 23 Feb 2017 05:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 KDMYSq1M5TZv; Thu, 23 Feb 2017 05:45:18 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00136.outbound.protection.outlook.com [40.107.0.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C8C12978B; Thu, 23 Feb 2017 05:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rVwK0aDp39hU/h25s2z5wgD47FA9vh0ocsvmS1GwFVY=; b=TdtbPF7zlXBiZN2O3hmMFlqn7oFWW84I6IaQ0s4EaftxmD9OU0mcld6plCTD+RJXNKwTg9CIYeZeFwS3Y/Xy999sUTClTiP9SKlzsxpdcfIwWz3neTeUtBj+UIpzSX+qpm8Ky7z/BJ04GbbvAJ61fGIA2dKeAZ8vsm0TxiE7BGY= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2572.eurprd03.prod.outlook.com (10.168.125.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 13:45:12 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 13:45:12 +0000 From: Alexander Vainshtein To: "draft-ietf-spring-sr-yang@ietf.org" Thread-Topic: A question regarding mode of SR/LDP interop Thread-Index: AdKN2a7lc/ubG7yNQ7GVRDzDBTPxgw== Date: Thu, 23 Feb 2017 13:45:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2572; 7:yPvru9ji9tKkpm3fdlnsTZhnwxbqkRI2XABnKJ+UARmD+GYTjSEUqdBhsFUSE3W8pOKPM5syAszscNQfZnzm+bk0rGwxzcv+IIJ9CAb1zkhaqTN8MPZ7pza4TmEXQZAUkIBWlOukLUT07I9R6UUKJzO3WJfCspBzSzT1WCcbvE1FBoWEGEvzJtY3knr/GuEtjU1PN0RcVofd//e9Az7VkNw4A1dkNud5P/b6Bi96PBRTfHiA+LENpdfCLAKWwTXoHCOQp182PTRb2fSkBguZSNwF+BgqiiWLCQLbe+ljOS0fidr5H4Dz+mbr0g9nhBlbPZWFLjzOIx/0cQcZ1LNk+Q== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(189002)(199003)(252514010)(53754006)(43544003)(51874003)(189998001)(7906003)(122556002)(92566002)(5630700001)(3660700001)(66066001)(2906002)(2900100001)(33656002)(3280700002)(4326007)(97736004)(450100001)(107886003)(110136004)(53936002)(38730400002)(86362001)(105586002)(2501003)(7736002)(9686003)(6306002)(8676002)(6916009)(68736007)(102836003)(106356001)(8936002)(77096006)(6116002)(54896002)(54356999)(5660300001)(81166006)(3846002)(790700001)(55016002)(81156014)(99286003)(74316002)(2351001)(606005)(7696004)(25786008)(54906002)(101416001)(6436002)(5640700003)(236005)(50986999)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2572; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 5dceea6e-7f48-4aaf-60c2-08d45bf230cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0301MB2572; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:HE1PR0301MB2572; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2572; x-forefront-prvs: 02272225C5 received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB2266D60F93DC6AA704A3EAA29D530HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 13:45:12.2724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2572 Archived-At: Cc: "spring@ietf.org" , Michael Gorokhovsky Subject: [spring] A question regarding mode of SR/LDP interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 13:45:20 -0000 --_000_HE1PR0301MB2266D60F93DC6AA704A3EAA29D530HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to point to what looks to me as inconsistency between the curr= ent (-05) version of the SR YANG Data Model draft and the latest (-06) v= ersion of the Segment Routing Interop with LDP draft= . The following text has been added to the latter: Section 2 describes the co-existence of SR with other MPLS Control Plane. Section 3 documents a method to migrate from LDP to SR-based MPLS tunneling. Section 4 documents the interworking between SR and LDP in the case of non-homogeneous deployment. Section 5 describes how a partial SR deployment can be used to provide SR benefits to LDP-based traffic including a possible application of SR in the context of inter-domain MPLS use-cases. Typically, an implementation will allow an operator to select (through configuration) which of the described modes of SR and LDP co-existence to use. To the best of my understanding, there is no match for the highlighted conf= iguration parameter in the former document. (This is expected since such a parameter has not been mentioned in the prev= ious (-05) version of the former). I hope the next version of the YANG Model draft will take care of that. Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com --_000_HE1PR0301MB2266D60F93DC6AA704A3EAA29D530HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I would like to point to what looks to me as inconsi= stency between the current (-05) version of the SR YANG Data Model draft and the latest (-06) version of the Segment Routing Interop with LDP draft.

 

The following text has been added to the latter:

 

  Section 2 describes the co-existence of SR with other MPLS Con= trol

   Plane.  Section 3 documents a method to migrate fro= m LDP to SR-based

   MPLS tunneling.  Section 4 documents the interworki= ng between SR and

   LDP in the case of non-homogeneous deployment.  Sec= tion 5 describes

   how a partial SR deployment can be used to provide SR be= nefits to

   LDP-based traffic including a possible application of SR= in the

   context of inter-domain MPLS use-cases.

 

   Typically, an implementation wi= ll allow an operator to select

   (through configur= ation) which of the described modes of SR and LDP

   co-existence to u= se.

 

To the best of my understanding, there is no match f= or the highlighted configuration parameter in the former document.

(This is expected since such a parameter has not bee= n mentioned in the previous (-05) version of the former).

 

I hope the next version of the YANG Model draft will= take care of that.

 

Regards, and lots of thanks in advance,

Sasha

 

Office: +972-39266302

Cell:      +972-5492663= 02

Email:   Alexander.Vainshtein@ecitele.com<= o:p>

 

--_000_HE1PR0301MB2266D60F93DC6AA704A3EAA29D530HE1PR0301MB2266_-- From nobody Thu Feb 23 06:16:30 2017 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 7516C129868; Thu, 23 Feb 2017 06:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 aujBSIOUDE3z; Thu, 23 Feb 2017 06:16:22 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FAF1296D2; Thu, 23 Feb 2017 06:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3026; q=dns/txt; s=iport; t=1487859382; x=1489068982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9HIbL48ioBwdqOQgMNl6aIsobCDlqNx+quZoKAdf4Wg=; b=VyM6rwXDzmdnVWFlZx2A/FZWpOsAZEUP0iUZoYABM+DMsS6KnyJ3UetN J9VV0f6KqZqCC11zMZavumrPLeGTvcHZ7h40uWgT/cCmbJdUiiLDtL8a9 JEZCHn72XBAt70/8rhMdfVGnEq8KjfBm7MRKcM9WqcUFlyfcwihYPl5DU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQBB7q5Y/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1CBageDVIoIkVuVNIINhiICGoMEPxgBAgEBAQEBAQFiKIRwAQE?= =?us-ascii?q?BAwEjEUUFCQICAQgYAgImAgICFBwVEAEBBA4FiAgDgWIIriOCJotDAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR8FgQaFQYIFgmqEJhEBHBcjgkyCXwWcFAGSI4F7iG2GKZM?= =?us-ascii?q?nAR84VSMIVBVPAYQ5HYFhdYkYgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="389417964" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 14:16:21 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1NEGLkG006839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 14:16:21 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 09:16:20 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 09:16:20 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: A question regarding IS-IS Segment Routing Extensions Thread-Index: AdKNyy6fYQKN924yQXSA3llgPNQdyQAPiB4A Date: Thu, 23 Feb 2017 14:16:20 +0000 Message-ID: <8A1CF914-4E63-45E5-97FB-918398973399@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.227.71] Content-Type: text/plain; charset="utf-8" Content-ID: <8B92EA9856503942802F67A6C6615630@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions@ietf.org" , "isis@ietf.org" , Michael Gorokhovsky , Ron Sdayoor , Rotem Cohen Subject: Re: [spring] A question regarding IS-IS Segment Routing Extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:16:28 -0000 DQo+IE9uIEZlYiAyMywgMjAxNywgYXQgMTowOCBQTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4g TXkgY29sbGVhZ3VlcyBhbmQgSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9ucyBhYm91dCBzb21l IGJlaGF2aW9yYWwgYXNwZWN0cyBvZiBJUy1JUyBTZWdtZW50IFJvdXRpbmcgKFNSKSBleHRlbnNp b25zLg0KPiAgDQo+IFN1cHBvc2UgdGhhdCB3ZSBoYXZlIGFuIElTLUlTIGRvbWFpbiB3aGVyZSBz b21lIHJvdXRlcnMgcnVuIElTLUlTIHdpdGggU1IgZXh0ZW5zaW9ucywgYW5kIHNvbWUgcm91dGVy cyBydW4g4oCcdmFuaWxsYeKAnSBJUy1JUyBmb3IgSVB2NC4NCj4gMS4gICAgICAgV2hhdCBpcyBz dXBwb3NlZCB0byBoYXBwZW4gd2hlbiByb3V0ZXIgQSB0aGF0IHJ1bnMgSVMtSVNEIHdpdGhvdXQg U1IgZXh0ZW5zaW9ucyBlc3RhYmxpc2hlcyBhbiBhZGphY2VuY3kgd2l0aCByb3V0ZXIgQiB0aGF0 IHJ1bnMgSVMtSVMgd2l0aCBTUiBleHRlbnNpb25zLiBPdXIgZXhwZWN0YXRpb25zIGFyZSB0aGF0 Og0KPiBhLiAgICAgICBBbiBhZGphY2VuY3kgYmV0d2VlbiBBIGFuZCBCIHdvdWxkIGJlIGFsbG93 ZWQgdG8gcHJvZ3Jlc3MgdG8gaXRzIEZVTEwgc3RhdGUuIElzIHRoYXQgY29ycmVjdD8NCg0KDQp5 ZXMuDQoNCg0KPiBiLiAgICAgIEIgd2lsbCBkaXN0cmlidXRlIGFsbCBTUi1yZWxhdGVkIFRMVnMg YW5kIHN1Yi1UTFZzIHRvIEEuIElzIHRoYXQgY29ycmVjdD8NCg0KDQp5ZXMuDQoNCg0KPiBjLiAg ICAgICBBIHdpbGwgc2lsZW50bHkgZGlzY2FyZCBhbGwgU1ItcmVsYXRlZCBUTFZzIGFuZCBzdWIt VExWcyBpdCBoYXMgcmVjZWl2ZWQgZnJvbSBCLiBJcyB0aGF0IGNvcnJlY3Q/DQoNCg0KeWVzLiBI b3dldmVyIOKAnGRpc2NhcmTigJ0gaXMgbm90IHRoZSByaWdodCB0ZXJtLiDigJxpZ25vcmXigJ0g aXMgdGhlIHJpZ2h0IG9uZS4NCg0KDQo+IDIuICAgICAgIFdoYXQgaXMgc3VwcG9zZWQgdG8gaGFw cGVuIGlmIElTLUlTIGFkamFjZW5jeSBiZXR3ZWVuIEEgYW5kIEIgcmVhY2hlcyBpdHMgRlVMTCBz dGF0ZSwgYW5kIHRoZW4gU1IgZXh0ZW5zaW9ucyBhcmUgZW5hYmxlZCBpbiBBLiBXZSBleHBlY3Qg dGhhdDoNCj4gYS4gICAgICAgSXQgaXMgcG9zc2libGUgdG8gZW5hYmxlIFNSIGV4dGVuc2lvbnMg aW4gQSB3aXRob3V0IHJlc2V0dGluZyBpdHMgYWRqYWNlbmN5IHdpdGggQiAob3IgYW55IG90aGVy IGFkamFjZW50IHJvdXRlcikuIElzIHRoYXQgY29ycmVjdD8NCg0KDQp5ZXMuDQoNCg0KPiBiLiAg ICAgIE9uY2UgQiBsZWFybnMgdGhhdCBTUiBjYXBhYmlsaXRpZXMgb2YgQSBoYXZlIGNoYW5nZWQs IGl0IGZsb29kcyBpdHMgTFNQIGRhdGFiYXNlIHdpdGggYWxsIFNSLXJlbGF0ZWQgVExWcyBhbmQg c3ViLVRMVnMgdG8gQS4gSXMgdGhhdCBjb3JyZWN0Pw0KDQoNCkxTREJzIGFyZSBub3QgZmxvb2Rl ZCBhZ2FpbiBpZiB0aGVyZeKAmXMgbm8gY2hhbmdlIGluIGFkamFjZW5jeSBzdGF0ZS4NCg0KTGlu ayBzdGF0ZSBwcm90b2NvbHMgd29yayBzdWNoIHRoYXQgZWFjaCByb3V0ZXIgKFNSIGNhcGFibGUg b3Igbm90KSBpcyBzdXBwb3NlZCB0byBrZWVwIHRoZSBlbnRpcmUgTFNEQiAoZXZlbiB0aGUgVExW cyBpdCBkb2VzbuKAmXQgdW5kZXJzdGFuZCkuIFdoZW4gc3VkZGVubHkgU1IgaXMgZW5hYmxlZCwg dGhlIHJvdXRlciByZS1yZWFkIGl0cyBMU0RCIGFuZCBwcm9jZXNzIHRoZSBTUiBUTFZzL1N1Yi1U TFZzIGFjY29yZGluZ2x5Lg0KDQoNCj4gQSBicmllZiBzY2FuIG9mIHRoZSBkcmFmdCBkaWQgbm90 IHlpZWxkIGFuc3dlcnMgdG8gYW55IG9mIHRoZSBxdWVzdGlvbnMgYWJvdmUuDQoNCg0KYmVjYXVz ZSB0aGlzIGlzIG5vdCByZWxhdGVkIHRvIFNSIGJ1dCB0byB0aGUgbm9ybWFsIGJlaGF2aW9yIG9m IGxpbmstc3RhdGUgcm91dGluZy4NCg0KDQo+IFRpbWVseSBmZWVkYmFjayB3b3VsZCBiZSB2ZXJ5 IGhpZ2hseSBhcHByZWNpYXRlZC4NCg0KDQpob3BlIHRoaXMgaGVscHMuDQpzLg0KDQoNCj4gIA0K PiBSZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5jZSwNCj4gU2FzaGENCj4gIA0K PiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPiBF bWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KDQo= From nobody Thu Feb 23 06:17:20 2017 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 9E32412986D; Thu, 23 Feb 2017 06:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 9pg0nSxjnG4v; Thu, 23 Feb 2017 06:17:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C7F1296D2; Thu, 23 Feb 2017 06:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2476; q=dns/txt; s=iport; t=1487859438; x=1489069038; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tCs846aEn+z7Sk2TC+hzXj+1wXMtkcmi1Rjscg3ChBg=; b=j6FH0q/FRC0GKBh2sypCAapf5OvYiOYEgCJKZHNp7eYxxkVkA4O0Ooah ELhoniFytI3lbfwnNNK0XpBGskhSqk1Qbn6eaJpQWSsxSInrKA2ANhFk2 kMJYKkMLX8oTtelcVSHQDI99Q7yX9h5YbHcqC2pebTmnuwt7/iKktCBsX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQBB7q5Y/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJE8H5U0gg0fC4UuSgIagwQ/GAECAQEBAQEBAWI?= =?us-ascii?q?ohHABAQEDAQEBIRE6CwUJAgIBCBgCAiYCAgIUEQsVEAEBBA4FiW0IDq4VgiaLQ?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYEGhUGCBQiCYoQmCgcBHBcjgkwugjE?= =?us-ascii?q?FnBQBkiOREZMnAR84eAhUFT4RAYY3dYkJDxeBCoENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="215776783" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 14:17:17 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1NEHHYG007604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 14:17:17 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 09:17:16 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 09:17:16 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: [spring] A question regarding mode of SR/LDP interop Thread-Index: AdKN2a7lc/ubG7yNQ7GVRDzDBTPxgwAL8IuA Date: Thu, 23 Feb 2017 14:17:16 +0000 Message-ID: <7E6CF524-AB37-4395-A4C6-3CB2215E2A74@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.227.71] Content-Type: text/plain; charset="utf-8" Content-ID: <1D39E1E4F6DD5B47B55F6225F146A332@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , Michael Gorokhovsky , "draft-ietf-spring-sr-yang@ietf.org" Subject: Re: [spring] A question regarding mode of SR/LDP interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:17:19 -0000 DQo+IE9uIEZlYiAyMywgMjAxNywgYXQgMjo0NSBQTSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4g SSB3b3VsZCBsaWtlIHRvIHBvaW50IHRvIHdoYXQgbG9va3MgdG8gbWUgYXMgaW5jb25zaXN0ZW5j eSBiZXR3ZWVuIHRoZSBjdXJyZW50ICgtMDUpIHZlcnNpb24gb2YgdGhlIFNSIFlBTkcgRGF0YSBN b2RlbCBkcmFmdCBhbmQgdGhlIGxhdGVzdCAoLTA2KSB2ZXJzaW9uIG9mIHRoZSBTZWdtZW50IFJv dXRpbmcgSW50ZXJvcCB3aXRoIExEUCBkcmFmdC4NCj4gIA0KPiBUaGUgZm9sbG93aW5nIHRleHQg aGFzIGJlZW4gYWRkZWQgdG8gdGhlIGxhdHRlcjoNCj4gIA0KPiAgIFNlY3Rpb24gMiBkZXNjcmli ZXMgdGhlIGNvLWV4aXN0ZW5jZSBvZiBTUiB3aXRoIG90aGVyIE1QTFMgQ29udHJvbA0KPiANCj4g ICAgUGxhbmUuICBTZWN0aW9uIDMgZG9jdW1lbnRzIGEgbWV0aG9kIHRvIG1pZ3JhdGUgZnJvbSBM RFAgdG8gU1ItYmFzZWQNCj4gDQo+ICAgIE1QTFMgdHVubmVsaW5nLiAgU2VjdGlvbiA0IGRvY3Vt ZW50cyB0aGUgaW50ZXJ3b3JraW5nIGJldHdlZW4gU1IgYW5kDQo+IA0KPiAgICBMRFAgaW4gdGhl IGNhc2Ugb2Ygbm9uLWhvbW9nZW5lb3VzIGRlcGxveW1lbnQuICBTZWN0aW9uIDUgZGVzY3JpYmVz DQo+IA0KPiAgICBob3cgYSBwYXJ0aWFsIFNSIGRlcGxveW1lbnQgY2FuIGJlIHVzZWQgdG8gcHJv dmlkZSBTUiBiZW5lZml0cyB0bw0KPiANCj4gICAgTERQLWJhc2VkIHRyYWZmaWMgaW5jbHVkaW5n IGEgcG9zc2libGUgYXBwbGljYXRpb24gb2YgU1IgaW4gdGhlDQo+IA0KPiAgICBjb250ZXh0IG9m IGludGVyLWRvbWFpbiBNUExTIHVzZS1jYXNlcy4NCj4gDQo+ICANCj4gDQo+ICAgIFR5cGljYWxs eSwgYW4gaW1wbGVtZW50YXRpb24gd2lsbCBhbGxvdyBhbiBvcGVyYXRvciB0byBzZWxlY3QNCj4g DQo+ICAgICh0aHJvdWdoIGNvbmZpZ3VyYXRpb24pIHdoaWNoIG9mIHRoZSBkZXNjcmliZWQgbW9k ZXMgb2YgU1IgYW5kIExEUA0KPiANCj4gICAgY28tZXhpc3RlbmNlIHRvIHVzZS4NCj4gDQo+ICAN Cj4gVG8gdGhlIGJlc3Qgb2YgbXkgdW5kZXJzdGFuZGluZywgdGhlcmUgaXMgbm8gbWF0Y2ggZm9y IHRoZSBoaWdobGlnaHRlZCBjb25maWd1cmF0aW9uIHBhcmFtZXRlciBpbiB0aGUgZm9ybWVyIGRv Y3VtZW50Lg0KDQoNCndlbGwsIGZyb20gYW4gU1IgcGVyc3BlY3RpdmUsIOKAnHRocm91Z2ggY29u ZmlndXJhdGlvbuKAnSBpcyBub3QgbGltaXRlZCB0byBZQU5HLi4uDQoNCnMuDQoNCg0KPiAoVGhp cyBpcyBleHBlY3RlZCBzaW5jZSBzdWNoIGEgcGFyYW1ldGVyIGhhcyBub3QgYmVlbiBtZW50aW9u ZWQgaW4gdGhlIHByZXZpb3VzICgtMDUpIHZlcnNpb24gb2YgdGhlIGZvcm1lcikuDQo+ICANCj4g SSBob3BlIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIFlBTkcgTW9kZWwgZHJhZnQgd2lsbCB0YWtl IGNhcmUgb2YgdGhhdC4NCj4gIA0KPiBSZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2 YW5jZSwNCj4gU2FzaGENCj4gIA0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gQ2VsbDogICAg ICArOTcyLTU0OTI2NjMwMg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbQ0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== From nobody Thu Feb 23 06:20:30 2017 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 87E80129868; Thu, 23 Feb 2017 06:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, 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=eci365.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 moIE8alqTuQr; Thu, 23 Feb 2017 06:20:21 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0113.outbound.protection.outlook.com [104.47.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268A71297CA; Thu, 23 Feb 2017 06:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EY82l78PvKkhp8oShbe73RgLBeCyG11jujTtO89u2g0=; b=gvo5qhewgZOJrnKOihGbas4M5zhnuPZ0TtIkppwMbZnXKoMkEPm+n3SIABsiklbQUplA/gm9tI9iAw3adidCwcAsm7nzf4hY4qGvBtJwoZK/uUoVYmDcXF1ppeMQESuNqyWeUHAMXwPSrMjx25hx/Roslul1vV64nA2XRiHDihc= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2571.eurprd03.prod.outlook.com (10.168.125.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 14:20:18 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 14:20:18 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: A question regarding IS-IS Segment Routing Extensions Thread-Index: AdKNyy6fYQKN924yQXSA3llgPNQdyQAPiB4AAApZKrA= Date: Thu, 23 Feb 2017 14:20:18 +0000 Message-ID: References: <8A1CF914-4E63-45E5-97FB-918398973399@cisco.com> In-Reply-To: <8A1CF914-4E63-45E5-97FB-918398973399@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2571; 7:lNgfilZk93uVHkAqR3c6eWBwtx17Zi/3RnGtS6tf0ck3Ok/dh2GEip6YrBVqVeeQbu1hqdvwvTnbGW5gjapccZpABMB9bKRYkE8dyND6CwvvNC5m2P34TjC2fpgngpyj1DVXqrDNmlf6yREXfNuxtgXvpxtxJgw4+MW4pzAB9jyg1BfGAqmBhLJf43MaiwU2tjr+InPAJXp+aCtlerTuwZvRORdBApSSHxIRzACakHQna3qhV13tD0mIVz9W1yj0Z9Vg3JloAwvDDq7QnqbgkKW5bw81qG2ZjwFYvviIu4Pi4H9ghViComadnYOyDhvXusmXYPVp0y6u8UypsyAL2A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39850400002)(39840400002)(13464003)(51874003)(53754006)(252514010)(24454002)(199003)(189002)(377454003)(86362001)(81166006)(8936002)(2950100002)(110136004)(107886003)(8676002)(6246003)(81156014)(9686003)(38730400002)(53936002)(33656002)(66066001)(3280700002)(74316002)(106356001)(2906002)(4326007)(105586002)(7696004)(7736002)(76176999)(50986999)(54356999)(5660300001)(305945005)(102836003)(6916009)(101416001)(25786008)(3846002)(6116002)(54906002)(68736007)(2900100001)(189998001)(77096006)(55016002)(6436002)(6506006)(53546006)(229853002)(99286003)(3660700001)(122556002)(92566002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2571; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: d7d59682-b028-4761-c87b-08d45bf717ec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0301MB2571; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:HE1PR0301MB2571; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2571; x-forefront-prvs: 02272225C5 received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 14:20:18.0434 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2571 Archived-At: Cc: "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions@ietf.org" , "isis@ietf.org" , Michael Gorokhovsky , Ron Sdayoor , Rotem Cohen Subject: Re: [spring] A question regarding IS-IS Segment Routing Extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:20:29 -0000 U3RlZmFubywNCkxvdHMgb2YgdGhhbmtzLCBpdCByZWFsbHkgaGVscHMhDQoNClJlZ2FyZHMsDQpT YXNoYQ0KDQpPZmZpY2U6ICs5NzItMzkyNjYzMDINCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDIN CkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWls dG86c3ByZXZpZGlAY2lzY28uY29tXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAx NyA0OjE2IFBNDQpUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tPg0KQ2M6IGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5z aW9uc0BpZXRmLm9yZzsgaXNpc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBNaWNoYWVsIEdv cm9raG92c2t5IDxNaWNoYWVsLkdvcm9raG92c2t5QGVjaXRlbGUuY29tPjsgUm9uIFNkYXlvb3Ig PFJvbi5TZGF5b29yQGVjaXRlbGUuY29tPjsgUm90ZW0gQ29oZW4gPFJvdGVtLkNvaGVuQGVjaXRl bGUuY29tPg0KU3ViamVjdDogUmU6IEEgcXVlc3Rpb24gcmVnYXJkaW5nIElTLUlTIFNlZ21lbnQg Um91dGluZyBFeHRlbnNpb25zDQoNCg0KPiBPbiBGZWIgMjMsIDIwMTcsIGF0IDE6MDggUE0sIEFs ZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4gd3Jv dGU6DQo+IA0KPiBIaSBhbGwsDQo+IE15IGNvbGxlYWd1ZXMgYW5kIEkgaGF2ZSBhIGNvdXBsZSBv ZiBxdWVzdGlvbnMgYWJvdXQgc29tZSBiZWhhdmlvcmFsIGFzcGVjdHMgb2YgSVMtSVMgU2VnbWVu dCBSb3V0aW5nIChTUikgZXh0ZW5zaW9ucy4NCj4gIA0KPiBTdXBwb3NlIHRoYXQgd2UgaGF2ZSBh biBJUy1JUyBkb21haW4gd2hlcmUgc29tZSByb3V0ZXJzIHJ1biBJUy1JUyB3aXRoIFNSIGV4dGVu c2lvbnMsIGFuZCBzb21lIHJvdXRlcnMgcnVuIOKAnHZhbmlsbGHigJ0gSVMtSVMgZm9yIElQdjQu DQo+IDEuICAgICAgIFdoYXQgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIHdoZW4gcm91dGVyIEEgdGhh dCBydW5zIElTLUlTRCB3aXRob3V0IFNSIGV4dGVuc2lvbnMgZXN0YWJsaXNoZXMgYW4gYWRqYWNl bmN5IHdpdGggcm91dGVyIEIgdGhhdCBydW5zIElTLUlTIHdpdGggU1IgZXh0ZW5zaW9ucy4gT3Vy IGV4cGVjdGF0aW9ucyBhcmUgdGhhdDoNCj4gYS4gICAgICAgQW4gYWRqYWNlbmN5IGJldHdlZW4g QSBhbmQgQiB3b3VsZCBiZSBhbGxvd2VkIHRvIHByb2dyZXNzIHRvIGl0cyBGVUxMIHN0YXRlLiBJ cyB0aGF0IGNvcnJlY3Q/DQoNCg0KeWVzLg0KDQoNCj4gYi4gICAgICBCIHdpbGwgZGlzdHJpYnV0 ZSBhbGwgU1ItcmVsYXRlZCBUTFZzIGFuZCBzdWItVExWcyB0byBBLiBJcyB0aGF0IGNvcnJlY3Q/ DQoNCg0KeWVzLg0KDQoNCj4gYy4gICAgICAgQSB3aWxsIHNpbGVudGx5IGRpc2NhcmQgYWxsIFNS LXJlbGF0ZWQgVExWcyBhbmQgc3ViLVRMVnMgaXQgaGFzIHJlY2VpdmVkIGZyb20gQi4gSXMgdGhh dCBjb3JyZWN0Pw0KDQoNCnllcy4gSG93ZXZlciDigJxkaXNjYXJk4oCdIGlzIG5vdCB0aGUgcmln aHQgdGVybS4g4oCcaWdub3Jl4oCdIGlzIHRoZSByaWdodCBvbmUuDQoNCg0KPiAyLiAgICAgICBX aGF0IGlzIHN1cHBvc2VkIHRvIGhhcHBlbiBpZiBJUy1JUyBhZGphY2VuY3kgYmV0d2VlbiBBIGFu ZCBCIHJlYWNoZXMgaXRzIEZVTEwgc3RhdGUsIGFuZCB0aGVuIFNSIGV4dGVuc2lvbnMgYXJlIGVu YWJsZWQgaW4gQS4gV2UgZXhwZWN0IHRoYXQ6DQo+IGEuICAgICAgIEl0IGlzIHBvc3NpYmxlIHRv IGVuYWJsZSBTUiBleHRlbnNpb25zIGluIEEgd2l0aG91dCByZXNldHRpbmcgaXRzIGFkamFjZW5j eSB3aXRoIEIgKG9yIGFueSBvdGhlciBhZGphY2VudCByb3V0ZXIpLiBJcyB0aGF0IGNvcnJlY3Q/ DQoNCg0KeWVzLg0KDQoNCj4gYi4gICAgICBPbmNlIEIgbGVhcm5zIHRoYXQgU1IgY2FwYWJpbGl0 aWVzIG9mIEEgaGF2ZSBjaGFuZ2VkLCBpdCBmbG9vZHMgaXRzIExTUCBkYXRhYmFzZSB3aXRoIGFs bCBTUi1yZWxhdGVkIFRMVnMgYW5kIHN1Yi1UTFZzIHRvIEEuIElzIHRoYXQgY29ycmVjdD8NCg0K DQpMU0RCcyBhcmUgbm90IGZsb29kZWQgYWdhaW4gaWYgdGhlcmXigJlzIG5vIGNoYW5nZSBpbiBh ZGphY2VuY3kgc3RhdGUuDQoNCkxpbmsgc3RhdGUgcHJvdG9jb2xzIHdvcmsgc3VjaCB0aGF0IGVh Y2ggcm91dGVyIChTUiBjYXBhYmxlIG9yIG5vdCkgaXMgc3VwcG9zZWQgdG8ga2VlcCB0aGUgZW50 aXJlIExTREIgKGV2ZW4gdGhlIFRMVnMgaXQgZG9lc27igJl0IHVuZGVyc3RhbmQpLiBXaGVuIHN1 ZGRlbmx5IFNSIGlzIGVuYWJsZWQsIHRoZSByb3V0ZXIgcmUtcmVhZCBpdHMgTFNEQiBhbmQgcHJv Y2VzcyB0aGUgU1IgVExWcy9TdWItVExWcyBhY2NvcmRpbmdseS4NCg0KDQo+IEEgYnJpZWYgc2Nh biBvZiB0aGUgZHJhZnQgZGlkIG5vdCB5aWVsZCBhbnN3ZXJzIHRvIGFueSBvZiB0aGUgcXVlc3Rp b25zIGFib3ZlLg0KDQoNCmJlY2F1c2UgdGhpcyBpcyBub3QgcmVsYXRlZCB0byBTUiBidXQgdG8g dGhlIG5vcm1hbCBiZWhhdmlvciBvZiBsaW5rLXN0YXRlIHJvdXRpbmcuDQoNCg0KPiBUaW1lbHkg ZmVlZGJhY2sgd291bGQgYmUgdmVyeSBoaWdobHkgYXBwcmVjaWF0ZWQuDQoNCg0KaG9wZSB0aGlz IGhlbHBzLg0Kcy4NCg0KDQo+ICANCj4gUmVnYXJkcywgYW5kIGxvdHMgb2YgdGhhbmtzIGluIGFk dmFuY2UsIFNhc2hhDQo+ICANCj4gT2ZmaWNlOiArOTcyLTM5MjY2MzAyDQo+IENlbGw6ICAgICAg Kzk3Mi01NDkyNjYzMDINCj4gRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20NCg0K From nobody Thu Feb 23 06:42:22 2017 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 6A75C1298CE; Thu, 23 Feb 2017 06:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 P5xOWiZ2a4lz; Thu, 23 Feb 2017 06:42:18 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30126.outbound.protection.outlook.com [40.107.3.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CEE129955; Thu, 23 Feb 2017 06:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kcnw/jYBI47xFejTvOwKibR12PKoAARuRKsDJg5kZV0=; b=ObSRW9PY9NWdMCbMLhb86BbwNXkNjToQPEoFoN734dCjdpuEW8mjS9hsqqwOH5nOJJ+4QCJMwHqZ0Kd7rJGPMcwOgIuh3sMENPoVO8OZEG2p4eAd8sA57ttmsTUEbfB3Tb8mVBxYdLOulIpoPUjADO3r50vDqZrcMpe998I8LNM= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2572.eurprd03.prod.outlook.com (10.168.125.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 14:42:15 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 14:42:15 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] A question regarding mode of SR/LDP interop Thread-Index: AdKN2a7lc/ubG7yNQ7GVRDzDBTPxgwAL8IuAAApZDFA= Date: Thu, 23 Feb 2017 14:42:15 +0000 Message-ID: References: <7E6CF524-AB37-4395-A4C6-3CB2215E2A74@cisco.com> In-Reply-To: <7E6CF524-AB37-4395-A4C6-3CB2215E2A74@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2572; 7:zcGxgTYMzN4GCO9RcovrB8IjER+oRYdVzXeJqw5btYlZwLm2yl4TFxM6a7KMRV6ltnTm7dday9f5ga7RtKwHPWJYJdqucTce1Ke2sEN3gNpOstL76ByWJ5vaiq6LrDphodt0eEMqUVwO21qnKzn/kyYLWiUPIMO3EmaUVTSfp5qTMt16m2GEQ06hQTXEmh07jTUqTpyle8KjgEX+SCq5bAfrQe4sXI+M8Dq+npj13V+JayTIwnBLqKPrHhixaNcuvCuruc5eWj2vti5bZNwzK8iUJD7NKo4CMSz/PfE52WWVZNiwsRev90c6zREqPkHmQfUlFUhNreSG/h3XB7dGNQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39850400002)(39410400002)(189002)(199003)(252514010)(377454003)(53754006)(24454002)(13464003)(43544003)(51874003)(189998001)(122556002)(92566002)(53546006)(3660700001)(66066001)(2906002)(2900100001)(33656002)(3280700002)(4326007)(97736004)(110136004)(107886003)(53936002)(38730400002)(86362001)(6246003)(105586002)(7736002)(9686003)(6306002)(8676002)(229853002)(6916009)(68736007)(102836003)(305945005)(106356001)(8936002)(77096006)(2950100002)(6116002)(5660300001)(54356999)(3846002)(81166006)(55016002)(81156014)(99286003)(74316002)(7696004)(25786008)(54906002)(6436002)(101416001)(50986999)(76176999)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2572; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 2ca0d66a-6d81-4078-00c9-08d45bfa28fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0301MB2572; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:HE1PR0301MB2572; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2572; x-forefront-prvs: 02272225C5 received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 14:42:15.2916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2572 Archived-At: Cc: "spring@ietf.org" , Michael Gorokhovsky , "draft-ietf-spring-sr-yang@ietf.org" Subject: Re: [spring] A question regarding mode of SR/LDP interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:42:20 -0000 U3RlZmFubywNCkkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLiANCg0KRnJvbSBteSBQT1YgWUFORyBk YXRhIG1vZGVscyAoc2FtZSBhcyBNSUJzIGJlZm9yZSB0aGVtKSBhcmUgc3VwcG9zZWQgdG8gcHJv dmlkZSBhIGNvbXByZWhlbnNpdmUgbGlzdCBvZiBjb25maWd1cmFibGUgcGFyYW1ldGVycyB0aGF0 IGltcGFjdCBvcGVyYXRpb24gb2YgYSBwcm90b2NvbCB3aXRoaW4gdGhlIGxpbWl0cyBkZWZpbmVk IGJ5IHRoZSBjb3JyZXNwb25kaW5nIHByb3RvY29sIHNwZWMuDQoNCk15IDJjLA0KU2FzaGENCg0K T2ZmaWNlOiArOTcyLTM5MjY2MzAyDQpDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQpFbWFpbDog ICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2 aWRpQGNpc2NvLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgNDoxNyBQ TQ0KVG86IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCkNjOiBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nQGlldGYub3JnOyBzcHJpbmdAaWV0 Zi5vcmc7IE1pY2hhZWwgR29yb2tob3Zza3kgPE1pY2hhZWwuR29yb2tob3Zza3lAZWNpdGVsZS5j b20+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gQSBxdWVzdGlvbiByZWdhcmRpbmcgbW9kZSBvZiBT Ui9MRFAgaW50ZXJvcA0KDQoNCj4gT24gRmViIDIzLCAyMDE3LCBhdCAyOjQ1IFBNLCBBbGV4YW5k ZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IHdyb3RlOg0K PiANCj4gSGkgYWxsLA0KPiBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgdG8gd2hhdCBsb29rcyB0byBt ZSBhcyBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIGN1cnJlbnQgKC0wNSkgdmVyc2lvbiBvZiB0 aGUgU1IgWUFORyBEYXRhIE1vZGVsIGRyYWZ0IGFuZCB0aGUgbGF0ZXN0ICgtMDYpIHZlcnNpb24g b2YgdGhlIFNlZ21lbnQgUm91dGluZyBJbnRlcm9wIHdpdGggTERQIGRyYWZ0Lg0KPiAgDQo+IFRo ZSBmb2xsb3dpbmcgdGV4dCBoYXMgYmVlbiBhZGRlZCB0byB0aGUgbGF0dGVyOg0KPiAgDQo+ICAg U2VjdGlvbiAyIGRlc2NyaWJlcyB0aGUgY28tZXhpc3RlbmNlIG9mIFNSIHdpdGggb3RoZXIgTVBM UyBDb250cm9sDQo+IA0KPiAgICBQbGFuZS4gIFNlY3Rpb24gMyBkb2N1bWVudHMgYSBtZXRob2Qg dG8gbWlncmF0ZSBmcm9tIExEUCB0byANCj4gU1ItYmFzZWQNCj4gDQo+ICAgIE1QTFMgdHVubmVs aW5nLiAgU2VjdGlvbiA0IGRvY3VtZW50cyB0aGUgaW50ZXJ3b3JraW5nIGJldHdlZW4gU1IgDQo+ IGFuZA0KPiANCj4gICAgTERQIGluIHRoZSBjYXNlIG9mIG5vbi1ob21vZ2VuZW91cyBkZXBsb3lt ZW50LiAgU2VjdGlvbiA1IGRlc2NyaWJlcw0KPiANCj4gICAgaG93IGEgcGFydGlhbCBTUiBkZXBs b3ltZW50IGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgU1IgYmVuZWZpdHMgdG8NCj4gDQo+ICAgIExE UC1iYXNlZCB0cmFmZmljIGluY2x1ZGluZyBhIHBvc3NpYmxlIGFwcGxpY2F0aW9uIG9mIFNSIGlu IHRoZQ0KPiANCj4gICAgY29udGV4dCBvZiBpbnRlci1kb21haW4gTVBMUyB1c2UtY2FzZXMuDQo+ IA0KPiAgDQo+IA0KPiAgICBUeXBpY2FsbHksIGFuIGltcGxlbWVudGF0aW9uIHdpbGwgYWxsb3cg YW4gb3BlcmF0b3IgdG8gc2VsZWN0DQo+IA0KPiAgICAodGhyb3VnaCBjb25maWd1cmF0aW9uKSB3 aGljaCBvZiB0aGUgZGVzY3JpYmVkIG1vZGVzIG9mIFNSIGFuZCBMRFANCj4gDQo+ICAgIGNvLWV4 aXN0ZW5jZSB0byB1c2UuDQo+IA0KPiAgDQo+IFRvIHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRp bmcsIHRoZXJlIGlzIG5vIG1hdGNoIGZvciB0aGUgaGlnaGxpZ2h0ZWQgY29uZmlndXJhdGlvbiBw YXJhbWV0ZXIgaW4gdGhlIGZvcm1lciBkb2N1bWVudC4NCg0KDQp3ZWxsLCBmcm9tIGFuIFNSIHBl cnNwZWN0aXZlLCDigJx0aHJvdWdoIGNvbmZpZ3VyYXRpb27igJ0gaXMgbm90IGxpbWl0ZWQgdG8g WUFORy4uLg0KDQpzLg0KDQoNCj4gKFRoaXMgaXMgZXhwZWN0ZWQgc2luY2Ugc3VjaCBhIHBhcmFt ZXRlciBoYXMgbm90IGJlZW4gbWVudGlvbmVkIGluIHRoZSBwcmV2aW91cyAoLTA1KSB2ZXJzaW9u IG9mIHRoZSBmb3JtZXIpLg0KPiAgDQo+IEkgaG9wZSB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBZ QU5HIE1vZGVsIGRyYWZ0IHdpbGwgdGFrZSBjYXJlIG9mIHRoYXQuDQo+ICANCj4gUmVnYXJkcywg YW5kIGxvdHMgb2YgdGhhbmtzIGluIGFkdmFuY2UsIFNhc2hhDQo+ICANCj4gT2ZmaWNlOiArOTcy LTM5MjY2MzAyDQo+IENlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDINCj4gRW1haWw6ICAgQWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCj4gIA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmlu Z0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu Zw0KDQo= From nobody Thu Feb 23 06:52:50 2017 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 ED7ED12A146; Thu, 23 Feb 2017 06:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 6nhu4-LMxDsf; Thu, 23 Feb 2017 06:52:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB4F129B16; Thu, 23 Feb 2017 06:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4374; q=dns/txt; s=iport; t=1487861567; x=1489071167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Jw2V56D09jag97ktS/n0/d4VyF/qKB6G5bftByKM2c4=; b=TsRI56WxWqb13O+SZg51CX46jij0I16vyq5Liwh/dGSPUfOAL5E4FXLQ tDsBaiI8wJDKI59poE4q+u4Dw8H7tLaX4qbfVp0VGaz1kSRUVykQ1KN35 awPzcBRJ3FnLGMRwrWspCNeBEHCaFWm+HVb0Ys6g4YJnnTgxpZiN8AiWt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQA79q5Y/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgycpYYEJB4NUigiRPB+VNIINHwuFLkoCGoMGPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRwAQEBAwEBASEROgsFBwICAgEIEQQBAQECAiMDAgICFBELFAEICAEBBA4FH?= =?us-ascii?q?4lOCA6tfoImi0MBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBQWBBoVBggUIgmKEJgo?= =?us-ascii?q?HASMQI4JMLoIxBZwUAZIjkRGTJwEfOHgIVBU+EQGGN3WJCQ8XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="210018298" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 14:52:46 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1NEqklK001838 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 14:52:46 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 09:52:45 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 09:52:45 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: [spring] A question regarding mode of SR/LDP interop Thread-Index: AdKN2a7lc/ubG7yNQ7GVRDzDBTPxgwAL8IuAAApZDFD//7cggA== Date: Thu, 23 Feb 2017 14:52:45 +0000 Message-ID: <8DE178E4-8822-4292-893E-43DE5608E77A@cisco.com> References: <7E6CF524-AB37-4395-A4C6-3CB2215E2A74@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.227.71] Content-Type: text/plain; charset="utf-8" Content-ID: <5DF3A3AFAF5C56418A15A389E5999ACA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , Michael Gorokhovsky , "draft-ietf-spring-sr-yang@ietf.org" Subject: Re: [spring] A question regarding mode of SR/LDP interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:52:49 -0000 U2FzaGEsDQoNCg0KPiBPbiBGZWIgMjMsIDIwMTcsIGF0IDM6NDIgUE0sIEFsZXhhbmRlciBWYWlu c2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4gd3JvdGU6DQo+IA0KPiBT dGVmYW5vLA0KPiBJIHJlc3BlY3RmdWxseSBkaXNhZ3JlZS4gDQo+IA0KPiBGcm9tIG15IFBPViBZ QU5HIGRhdGEgbW9kZWxzIChzYW1lIGFzIE1JQnMgYmVmb3JlIHRoZW0pIGFyZSBzdXBwb3NlZCB0 byBwcm92aWRlIGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXJz IHRoYXQgaW1wYWN0IG9wZXJhdGlvbiBvZiBhIHByb3RvY29sIHdpdGhpbiB0aGUgbGltaXRzIGRl ZmluZWQgYnkgdGhlIGNvcnJlc3BvbmRpbmcgcHJvdG9jb2wgc3BlYy4NCg0KDQpGYXIgYmUgaXQg ZnJvbSBtZSB0byBxdWVzdGlvbiB5YW5nIGJlbmVmaXRzLi4uIDstKQ0KDQppdOKAmXMganVzdCB0 aGF0LCBmcm9tIGEgcHJvdG9jb2wgZGVmaW5pdGlvbiBwZXJzcGVjdGl2ZSwgSSB3b27igJl0IGFz c3VtZSBhIGdpdmVuIGNob2ljZSBmb3IgbWFuYWdlbWVudC9jb25maWd1cmF0aW9uIHNvIHRoYXQg cGVvcGxlIGNhbiB0aGVuIGNob3NlIHNubXAtbWlicywgeWFuZyBvciB3aGF0ZXZlciBjb21lcyBu ZXh0Lg0KDQpXaGVyZSBJIGFncmVlIHdpdGggeW91IGlzIG9uIHRoZSBuZWVkIGZvciB5YW5nIG1v ZGVscyB0byBzdXBwb3J0IHRoZSBzci9sZHAgaW50ZXJvcCBpZiB0aGUgdGFyZ2V0IGlzIHRvIGJl IHlhbmctY2FwYWJsZSBvbiBhbGwgYXNwZWN0cyBvZiBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbnMu DQoNCnMuDQoNCg0KPiANCj4gTXkgMmMsDQo+IFNhc2hhDQo+IA0KPiBPZmZpY2U6ICs5NzItMzky NjYzMDINCj4gQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMg0KPiBFbWFpbDogICBBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbQ0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlA Y2lzY28uY29tXSANCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE3IDQ6MTcgUE0N Cj4gVG86IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCj4gQ2M6IGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmdAaWV0Zi5vcmc7IHNwcmluZ0Bp ZXRmLm9yZzsgTWljaGFlbCBHb3Jva2hvdnNreSA8TWljaGFlbC5Hb3Jva2hvdnNreUBlY2l0ZWxl LmNvbT4NCj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEEgcXVlc3Rpb24gcmVnYXJkaW5nIG1vZGUg b2YgU1IvTERQIGludGVyb3ANCj4gDQo+IA0KPj4gT24gRmViIDIzLCAyMDE3LCBhdCAyOjQ1IFBN LCBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+ IHdyb3RlOg0KPj4gDQo+PiBIaSBhbGwsDQo+PiBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgdG8gd2hh dCBsb29rcyB0byBtZSBhcyBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIGN1cnJlbnQgKC0wNSkg dmVyc2lvbiBvZiB0aGUgU1IgWUFORyBEYXRhIE1vZGVsIGRyYWZ0IGFuZCB0aGUgbGF0ZXN0ICgt MDYpIHZlcnNpb24gb2YgdGhlIFNlZ21lbnQgUm91dGluZyBJbnRlcm9wIHdpdGggTERQIGRyYWZ0 Lg0KPj4gDQo+PiBUaGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gYWRkZWQgdG8gdGhlIGxhdHRl cjoNCj4+IA0KPj4gIFNlY3Rpb24gMiBkZXNjcmliZXMgdGhlIGNvLWV4aXN0ZW5jZSBvZiBTUiB3 aXRoIG90aGVyIE1QTFMgQ29udHJvbA0KPj4gDQo+PiAgIFBsYW5lLiAgU2VjdGlvbiAzIGRvY3Vt ZW50cyBhIG1ldGhvZCB0byBtaWdyYXRlIGZyb20gTERQIHRvIA0KPj4gU1ItYmFzZWQNCj4+IA0K Pj4gICBNUExTIHR1bm5lbGluZy4gIFNlY3Rpb24gNCBkb2N1bWVudHMgdGhlIGludGVyd29ya2lu ZyBiZXR3ZWVuIFNSIA0KPj4gYW5kDQo+PiANCj4+ICAgTERQIGluIHRoZSBjYXNlIG9mIG5vbi1o b21vZ2VuZW91cyBkZXBsb3ltZW50LiAgU2VjdGlvbiA1IGRlc2NyaWJlcw0KPj4gDQo+PiAgIGhv dyBhIHBhcnRpYWwgU1IgZGVwbG95bWVudCBjYW4gYmUgdXNlZCB0byBwcm92aWRlIFNSIGJlbmVm aXRzIHRvDQo+PiANCj4+ICAgTERQLWJhc2VkIHRyYWZmaWMgaW5jbHVkaW5nIGEgcG9zc2libGUg YXBwbGljYXRpb24gb2YgU1IgaW4gdGhlDQo+PiANCj4+ICAgY29udGV4dCBvZiBpbnRlci1kb21h aW4gTVBMUyB1c2UtY2FzZXMuDQo+PiANCj4+IA0KPj4gDQo+PiAgIFR5cGljYWxseSwgYW4gaW1w bGVtZW50YXRpb24gd2lsbCBhbGxvdyBhbiBvcGVyYXRvciB0byBzZWxlY3QNCj4+IA0KPj4gICAo dGhyb3VnaCBjb25maWd1cmF0aW9uKSB3aGljaCBvZiB0aGUgZGVzY3JpYmVkIG1vZGVzIG9mIFNS IGFuZCBMRFANCj4+IA0KPj4gICBjby1leGlzdGVuY2UgdG8gdXNlLg0KPj4gDQo+PiANCj4+IFRv IHRoZSBiZXN0IG9mIG15IHVuZGVyc3RhbmRpbmcsIHRoZXJlIGlzIG5vIG1hdGNoIGZvciB0aGUg aGlnaGxpZ2h0ZWQgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXIgaW4gdGhlIGZvcm1lciBkb2N1bWVu dC4NCj4gDQo+IA0KPiB3ZWxsLCBmcm9tIGFuIFNSIHBlcnNwZWN0aXZlLCDigJx0aHJvdWdoIGNv bmZpZ3VyYXRpb27igJ0gaXMgbm90IGxpbWl0ZWQgdG8gWUFORy4uLg0KPiANCj4gcy4NCj4gDQo+ IA0KPj4gKFRoaXMgaXMgZXhwZWN0ZWQgc2luY2Ugc3VjaCBhIHBhcmFtZXRlciBoYXMgbm90IGJl ZW4gbWVudGlvbmVkIGluIHRoZSBwcmV2aW91cyAoLTA1KSB2ZXJzaW9uIG9mIHRoZSBmb3JtZXIp Lg0KPj4gDQo+PiBJIGhvcGUgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgWUFORyBNb2RlbCBkcmFm dCB3aWxsIHRha2UgY2FyZSBvZiB0aGF0Lg0KPj4gDQo+PiBSZWdhcmRzLCBhbmQgbG90cyBvZiB0 aGFua3MgaW4gYWR2YW5jZSwgU2FzaGENCj4+IA0KPj4gT2ZmaWNlOiArOTcyLTM5MjY2MzAyDQo+ PiBDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQo+PiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNo dGVpbkBlY2l0ZWxlLmNvbQ0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPj4gc3ByaW5nQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAN Cg0K From nobody Thu Feb 23 06:58:53 2017 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 DA410129953; Thu, 23 Feb 2017 06:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 R-v1ILVm-tVJ; Thu, 23 Feb 2017 06:58:50 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10095.outbound.protection.outlook.com [40.107.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD18C12994E; Thu, 23 Feb 2017 06:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NsK4kSFRCxyNlJjvXEhhG2xwG9/LfBJ20PIIqSW6GrI=; b=Sec0qBdxOfDEuZF3jNp7PG8E5lq/NH27/GvbwDcgXBB36Z1CfA+22md/UpEfeIywOCWee8ldRTNksACgAxJeC34z1B6/z190VYObk7bzvzY2HWzu7GAZ9oyuvS49vQgjaIm+zN01Mx5YWk13ddJdDsSy5VYnkenYNSqkZ3yFT30= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2570.eurprd03.prod.outlook.com (10.168.125.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 14:58:47 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 14:58:47 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] A question regarding mode of SR/LDP interop Thread-Index: AdKN2a7lc/ubG7yNQ7GVRDzDBTPxgwAL8IuAAApZDFD//7cggIAAUm7Q Date: Thu, 23 Feb 2017 14:58:46 +0000 Message-ID: References: <7E6CF524-AB37-4395-A4C6-3CB2215E2A74@cisco.com> <8DE178E4-8822-4292-893E-43DE5608E77A@cisco.com> In-Reply-To: <8DE178E4-8822-4292-893E-43DE5608E77A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2570; 7:6o7YPaQLoyBwnpgVCDE1wwvSGI6PdWpDqnXUHSMl0cleE3OcUvj8FSggJIZ0224Xta+pJaf924EOsFn2fj+ZcLiLv6gTBs/HnQT7wjG1eg4VQaIQACoxstLNmKQAwDs8rWlXyNTpIqfnPeerStcp4+C30eoLJQAaAGX8pe7FtaYyxNasaqaVlDOQvluqpMuQRtbaXhqKWI3AUTpCyTIkbISrm91wdMNldoiGx0JctAjM5cdzwv6uqIK7DjYW2jHwFFGi54FRifpv+cfwIRVrwAHSBvbt9iKF28Dvc1dHWi8fzpWIS/4DidbIIGTIrsg5YQvKEgf+DLowvvqUNZ1okg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(199003)(13464003)(252514010)(24454002)(53754006)(377454003)(189002)(43544003)(51874003)(55016002)(77096006)(101416001)(50986999)(54356999)(74316002)(122556002)(8936002)(106356001)(66066001)(105586002)(76176999)(8676002)(229853002)(6916009)(81156014)(6436002)(33656002)(6306002)(99286003)(5660300001)(81166006)(2950100002)(25786008)(54906002)(53936002)(6506006)(7696004)(102836003)(3846002)(92566002)(6116002)(93886004)(97736004)(86362001)(3660700001)(305945005)(38730400002)(189998001)(3280700002)(2900100001)(7736002)(53546006)(2906002)(9686003)(68736007)(4326007)(107886003)(110136004)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2570; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 8c3c81dd-1a10-4131-b7fc-08d45bfc7816 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0301MB2570; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558025)(20161123560025)(6072148); SRVR:HE1PR0301MB2570; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2570; x-forefront-prvs: 02272225C5 received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 14:58:46.9442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2570 Archived-At: Cc: "spring@ietf.org" , Michael Gorokhovsky , "draft-ietf-spring-sr-yang@ietf.org" Subject: Re: [spring] A question regarding mode of SR/LDP interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:58:52 -0000 U3RlZmFubywNCkxvdHMgb2YgdGhhbmtzIGZvciBhIHByb21wdCByZXNwb25zZS4NCg0KTG9va3Mg YXMgYWN0dWFsbHkgd2UgYXJlIGluIHN5bmMuIEkganVzdCBob3BlIHRoYXQgdGhlIGF1dGhvcnMg b2YgdGhlIFlBTkcgTW9kZWwgZHJhZnQgd2lsbCBiZSBpbiBzeW5jIHdpdGggdXMgYXMgd2VsbC4N Cg0KUmVnYXJkcywNClNhc2hhDQoNCk9mZmljZTogKzk3Mi0zOTI2NjMwMg0KQ2VsbDogICAgICAr OTcyLTU0OTI2NjMwMg0KRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20N Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlZmFubyBQcmV2aWRpIChz cHJldmlkaSkgW21haWx0bzpzcHJldmlkaUBjaXNjby5jb21dIA0KU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDIzLCAyMDE3IDQ6NTMgUE0NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+DQpDYzogZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFu Z0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBNaWNoYWVsIEdvcm9raG92c2t5IDxNaWNoYWVs Lkdvcm9raG92c2t5QGVjaXRlbGUuY29tPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIEEgcXVlc3Rp b24gcmVnYXJkaW5nIG1vZGUgb2YgU1IvTERQIGludGVyb3ANCg0KU2FzaGEsDQoNCg0KPiBPbiBG ZWIgMjMsIDIwMTcsIGF0IDM6NDIgUE0sIEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4gd3JvdGU6DQo+IA0KPiBTdGVmYW5vLA0KPiBJIHJlc3Bl Y3RmdWxseSBkaXNhZ3JlZS4gDQo+IA0KPiBGcm9tIG15IFBPViBZQU5HIGRhdGEgbW9kZWxzIChz YW1lIGFzIE1JQnMgYmVmb3JlIHRoZW0pIGFyZSBzdXBwb3NlZCB0byBwcm92aWRlIGEgY29tcHJl aGVuc2l2ZSBsaXN0IG9mIGNvbmZpZ3VyYWJsZSBwYXJhbWV0ZXJzIHRoYXQgaW1wYWN0IG9wZXJh dGlvbiBvZiBhIHByb3RvY29sIHdpdGhpbiB0aGUgbGltaXRzIGRlZmluZWQgYnkgdGhlIGNvcnJl c3BvbmRpbmcgcHJvdG9jb2wgc3BlYy4NCg0KDQpGYXIgYmUgaXQgZnJvbSBtZSB0byBxdWVzdGlv biB5YW5nIGJlbmVmaXRzLi4uIDstKQ0KDQppdOKAmXMganVzdCB0aGF0LCBmcm9tIGEgcHJvdG9j b2wgZGVmaW5pdGlvbiBwZXJzcGVjdGl2ZSwgSSB3b27igJl0IGFzc3VtZSBhIGdpdmVuIGNob2lj ZSBmb3IgbWFuYWdlbWVudC9jb25maWd1cmF0aW9uIHNvIHRoYXQgcGVvcGxlIGNhbiB0aGVuIGNo b3NlIHNubXAtbWlicywgeWFuZyBvciB3aGF0ZXZlciBjb21lcyBuZXh0Lg0KDQpXaGVyZSBJIGFn cmVlIHdpdGggeW91IGlzIG9uIHRoZSBuZWVkIGZvciB5YW5nIG1vZGVscyB0byBzdXBwb3J0IHRo ZSBzci9sZHAgaW50ZXJvcCBpZiB0aGUgdGFyZ2V0IGlzIHRvIGJlIHlhbmctY2FwYWJsZSBvbiBh bGwgYXNwZWN0cyBvZiBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbnMuDQoNCnMuDQoNCg0KPiANCj4g TXkgMmMsDQo+IFNhc2hhDQo+IA0KPiBPZmZpY2U6ICs5NzItMzkyNjYzMDINCj4gQ2VsbDogICAg ICArOTcyLTU0OTI2NjMwMg0KPiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbQ0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZWZh bm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0KPiBTZW50 OiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgNDoxNyBQTQ0KPiBUbzogQWxleGFuZGVyIFZh aW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPg0KPiBDYzogZHJhZnQt aWV0Zi1zcHJpbmctc3IteWFuZ0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBNaWNoYWVsIA0K PiBHb3Jva2hvdnNreSA8TWljaGFlbC5Hb3Jva2hvdnNreUBlY2l0ZWxlLmNvbT4NCj4gU3ViamVj dDogUmU6IFtzcHJpbmddIEEgcXVlc3Rpb24gcmVnYXJkaW5nIG1vZGUgb2YgU1IvTERQIGludGVy b3ANCj4gDQo+IA0KPj4gT24gRmViIDIzLCAyMDE3LCBhdCAyOjQ1IFBNLCBBbGV4YW5kZXIgVmFp bnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+IHdyb3RlOg0KPj4gDQo+ PiBIaSBhbGwsDQo+PiBJIHdvdWxkIGxpa2UgdG8gcG9pbnQgdG8gd2hhdCBsb29rcyB0byBtZSBh cyBpbmNvbnNpc3RlbmN5IGJldHdlZW4gdGhlIGN1cnJlbnQgKC0wNSkgdmVyc2lvbiBvZiB0aGUg U1IgWUFORyBEYXRhIE1vZGVsIGRyYWZ0IGFuZCB0aGUgbGF0ZXN0ICgtMDYpIHZlcnNpb24gb2Yg dGhlIFNlZ21lbnQgUm91dGluZyBJbnRlcm9wIHdpdGggTERQIGRyYWZ0Lg0KPj4gDQo+PiBUaGUg Zm9sbG93aW5nIHRleHQgaGFzIGJlZW4gYWRkZWQgdG8gdGhlIGxhdHRlcjoNCj4+IA0KPj4gIFNl Y3Rpb24gMiBkZXNjcmliZXMgdGhlIGNvLWV4aXN0ZW5jZSBvZiBTUiB3aXRoIG90aGVyIE1QTFMg Q29udHJvbA0KPj4gDQo+PiAgIFBsYW5lLiAgU2VjdGlvbiAzIGRvY3VtZW50cyBhIG1ldGhvZCB0 byBtaWdyYXRlIGZyb20gTERQIHRvIA0KPj4gU1ItYmFzZWQNCj4+IA0KPj4gICBNUExTIHR1bm5l bGluZy4gIFNlY3Rpb24gNCBkb2N1bWVudHMgdGhlIGludGVyd29ya2luZyBiZXR3ZWVuIFNSIA0K Pj4gYW5kDQo+PiANCj4+ICAgTERQIGluIHRoZSBjYXNlIG9mIG5vbi1ob21vZ2VuZW91cyBkZXBs b3ltZW50LiAgU2VjdGlvbiA1IGRlc2NyaWJlcw0KPj4gDQo+PiAgIGhvdyBhIHBhcnRpYWwgU1Ig ZGVwbG95bWVudCBjYW4gYmUgdXNlZCB0byBwcm92aWRlIFNSIGJlbmVmaXRzIHRvDQo+PiANCj4+ ICAgTERQLWJhc2VkIHRyYWZmaWMgaW5jbHVkaW5nIGEgcG9zc2libGUgYXBwbGljYXRpb24gb2Yg U1IgaW4gdGhlDQo+PiANCj4+ICAgY29udGV4dCBvZiBpbnRlci1kb21haW4gTVBMUyB1c2UtY2Fz ZXMuDQo+PiANCj4+IA0KPj4gDQo+PiAgIFR5cGljYWxseSwgYW4gaW1wbGVtZW50YXRpb24gd2ls bCBhbGxvdyBhbiBvcGVyYXRvciB0byBzZWxlY3QNCj4+IA0KPj4gICAodGhyb3VnaCBjb25maWd1 cmF0aW9uKSB3aGljaCBvZiB0aGUgZGVzY3JpYmVkIG1vZGVzIG9mIFNSIGFuZCBMRFANCj4+IA0K Pj4gICBjby1leGlzdGVuY2UgdG8gdXNlLg0KPj4gDQo+PiANCj4+IFRvIHRoZSBiZXN0IG9mIG15 IHVuZGVyc3RhbmRpbmcsIHRoZXJlIGlzIG5vIG1hdGNoIGZvciB0aGUgaGlnaGxpZ2h0ZWQgY29u ZmlndXJhdGlvbiBwYXJhbWV0ZXIgaW4gdGhlIGZvcm1lciBkb2N1bWVudC4NCj4gDQo+IA0KPiB3 ZWxsLCBmcm9tIGFuIFNSIHBlcnNwZWN0aXZlLCDigJx0aHJvdWdoIGNvbmZpZ3VyYXRpb27igJ0g aXMgbm90IGxpbWl0ZWQgdG8gWUFORy4uLg0KPiANCj4gcy4NCj4gDQo+IA0KPj4gKFRoaXMgaXMg ZXhwZWN0ZWQgc2luY2Ugc3VjaCBhIHBhcmFtZXRlciBoYXMgbm90IGJlZW4gbWVudGlvbmVkIGlu IHRoZSBwcmV2aW91cyAoLTA1KSB2ZXJzaW9uIG9mIHRoZSBmb3JtZXIpLg0KPj4gDQo+PiBJIGhv cGUgdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgWUFORyBNb2RlbCBkcmFmdCB3aWxsIHRha2UgY2Fy ZSBvZiB0aGF0Lg0KPj4gDQo+PiBSZWdhcmRzLCBhbmQgbG90cyBvZiB0aGFua3MgaW4gYWR2YW5j ZSwgU2FzaGENCj4+IA0KPj4gT2ZmaWNlOiArOTcyLTM5MjY2MzAyDQo+PiBDZWxsOiAgICAgICs5 NzItNTQ5MjY2MzAyDQo+PiBFbWFpbDogICBBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bQ0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPj4gc3ByaW5nQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiANCg0K From nobody Sun Feb 26 21:33:06 2017 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 86B1B129B0A for ; Sun, 26 Feb 2017 21:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 6N_q1N-k0BcI for ; Sun, 26 Feb 2017 21:33:03 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 12A67129B06 for ; Sun, 26 Feb 2017 21:33:03 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n186so6037761qkb.3 for ; Sun, 26 Feb 2017 21:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6lL4i6HffwX1zA7KdkS5JEayUkTaP/efYSDCCbBYa9A=; b=fRWaBvLlM7uYzVh5O6UdCQjZzMJBLB4B8QAqc2t9T7nIw0PvXs0SEjxuDv9MuFF3pE 3ReGkbFq5rj1mUs3wB98o6PNFA5SJitffkyPpTqva+seDZQxlg+7tnZOxCM5S69b1nSs QNd+SiCrndD/O0+koOLc1PJNldb4pjS0I6RkJ9g3kyTVYuceO7k56Nj21D5JSzrKEvjn Z27dkryqt/+zUHy65PQUY4nF+xv8uzyh+DtqOOLsvM0grTwOgU0PftfxGXeud/X6vXS4 uHJ8rsA/uRc97Z5mq/aUPJXYfy8vBsFqhXdg/6v1NxsTBuBPXIoo8gh+eDWgmcb1yYvR 19Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6lL4i6HffwX1zA7KdkS5JEayUkTaP/efYSDCCbBYa9A=; b=aj77Jf82prtez77dGxxGV04mR0lO4q3hloWAgpNpmYQQjz+kROXxq8nCjz7lIQ2PZD Kr5icBC9/noeu1ynUlWE4k9BLqEWMLeDv74B6ZD+r6xStVptwqhoDPTKyBCe3x32UUvV Vp4j5TrBEzHFEKHcr2aO1qkpD+ZkbX/cDxHI+pJ1tPsQiupD0G/OOjozDn2HhI7Tjj6V ze0WOGstQMTzH6O4As3NKdWychyGbjSHXc25rbgSf7kFCbBV5IFaberukLVSrcyOZ5Ni HW+dEFBSdRZuTY2fiOKoYOS5d9KjM84XK03/hJwZEps02/Gb8gBoLn16b7dFHb7g0YLK J3ig== X-Gm-Message-State: AMke39l9YhNoQ/EW5OACC4WGU/gBQhwLsrzM2Y3c9O0vMIidPwAh51NL/BUVxxqP015XbtxLd06Qbf83QQh83Q== X-Received: by 10.237.45.198 with SMTP id i64mr14838245qtd.238.1488173582171; Sun, 26 Feb 2017 21:33:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.92.197 with HTTP; Sun, 26 Feb 2017 21:33:01 -0800 (PST) In-Reply-To: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Mohan Nanduri Date: Mon, 27 Feb 2017 00:33:01 -0500 Message-ID: To: Bruno Decraene Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 05:33:04 -0000 Support the publication of this draft. Cheers, -Mohan On Tue, Feb 21, 2017 at 4:50 AM, wrote: > Hello Working Group, > > > > This email starts a 2-week Working Group Last Call on > draft-ietf-spring-segment-routing-msdc-02 [1]. > > > > Please read the document if you haven't read the most recent version yet, > and send your comments to the list, no later than the *7th of March*. > > Note that this is *not only* a call for comments on the document; it is also > a call for support (or not) to publish this document as an Informational > RFC. > > > > We have already polled for IPR knowledge on this document and all Authors > have replied. > > No IPR has been disclosed [2]. > > > > Thank you > > > > M&B > > > > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-02 > > [2] > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing-msdc > > > > > > > > > > _________________________________________________________________________________________________________________________ > > 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. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Sun Feb 26 21:35:11 2017 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 06EDA12986E; Sun, 26 Feb 2017 21:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 33muAVOBSjAs; Sun, 26 Feb 2017 21:35:08 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 B68161293F4; Sun, 26 Feb 2017 21:35:08 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n186so6082996qkb.3; Sun, 26 Feb 2017 21:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KGzjVzzpVt1vLLz3mZnxCDmNtYONkaPfJR5+/pxwqhU=; b=Cr87mwCKVIzrh5LOEaS7r+cW2LQXI/z4FRiorWYHxXesIOomrG6F34JboUM8IpjJne gTrdXyMNt0Vg/NOsEtMkewuvlTX5xwTMZ5ZOGrcAerMnoD5WiQqjpgBJQYzyF8vflZTV XrcvGhLMGcqnR0S1paVyH8KVv2smD/pIzPLsk3lPMwSEGPmSPspcd0pQ15aT7mbAvxoy KXJWQcKJnRXLRgKWh/6GSxW6XCMmQSZPkBi3YwKY3O7oeIfEt//s/OiKM6yD49DRwudH SY4U+oESMhBEt1JJjakHg0eLKwwyUxeKjxFaWIKUdfUXjChBLTs+ByWKRZRaKkh6byUc GcIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KGzjVzzpVt1vLLz3mZnxCDmNtYONkaPfJR5+/pxwqhU=; b=U5GD6XXNMcC5+9hDUudUAeYyEVdQTlr2vQCrRdkxDSd7QzlQvJlql8hRoMLDByEKrW HJECPDH6jda4xoV/KR0+5C/4U4IkwEqTW/THHSRTE1DPrlLR/75ah73ehCTH7Se6PBHx yZEMj64iuStOd9s7D2Y+sAHuEdiyS805GzPu3K6WjNGP7a6GBqaX95tsm4FPyj6+Pevq Zf+vmmW1XQjxcjfnQf9qsxWSl0L0AXWMDo1ahCyJp4FchbhtH2AZeq0/RH3g6R+r/Dg0 OG0RYT4ACWJSnyKI0EfdoxXJXQu/yYPeei27u/Nw0LqQpOTWNarXbIG1wOn7BGDo6OJ6 QO2Q== X-Gm-Message-State: AMke39ln1q9mzOAp0v2K8PTxgGazsmeTLcVsjzbeIhxgSFoaqoLpLB2QR8yWZdRxajfZo3poCfh3DHq80qTieQ== X-Received: by 10.55.76.209 with SMTP id z200mr15136799qka.282.1488173707924; Sun, 26 Feb 2017 21:35:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.92.197 with HTTP; Sun, 26 Feb 2017 21:35:07 -0800 (PST) In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> From: Mohan Nanduri Date: Mon, 27 Feb 2017 00:35:07 -0500 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "idr@ietf.org List" , spring@ietf.org, "Alvaro Retana \(aretana\)" Subject: Re: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 05:35:10 -0000 Support the publication of this draft. Cheers, -Mohan On Wed, Feb 15, 2017 at 6:34 PM, Susan Hares wrote: > This begins a 2 week IDR WG last call on > draft-ietf-idr-bgpls-segment-routing-epe from (2/15 to 3/1/2017) There > are two implementations describe on the wiki at: > > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20 > > > > The two implementation are from Cisco IOS-XR release 6.0.2 and Cisco Nexus > Switch N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater. The > authors will indicate on the list and in the wiki the following information > : > > > > 1) Were these implementations separate implementations? > > 2) What were the results of the interoperability tests? > > > > This work is linked to the draft-ietf-spring-segment-routing-central-epe > work in the SPRING WG. Based on the two drafts, the WG should might > consider: > > 1) Is there need for this work in deployments in networks/ > > 2) Is this technically ready for publication? > > 3) Does it fit with the spring informational draft? > > > > For the ease of reference the web references are below: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/ > > > > Sue Hares > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Tue Feb 28 01:16:11 2017 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 251E912943E for ; Tue, 28 Feb 2017 01:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIkukuPWX-pM for ; Tue, 28 Feb 2017 01:16:09 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110DB126D74 for ; Tue, 28 Feb 2017 01:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1127; q=dns/txt; s=iport; t=1488273368; x=1489482968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Uxn8luPASYecn1nfQwwcrSwjQ7ckeP6rP2/5ylhj4gk=; b=Dw6VxaItI2JupltVFgg4hZfyrxSP9mC4XbwzuI49hw/JfAczE+9WwI+5 l1nVtqsm/lTaVmr1y69I7G9hLtkNmtdbB4XBHffliME+RVFzEKgrNkKNY 2LmCNFZDGz1PxBRSJ8heAs0VxKlNlw+6wNYomHy/cEcwktfQc9h0sPMsZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQD6PrVY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1CBageNXJFjlTWCDYYiAoInPxgBAgEBAQEBAQFiHQuEcAEBAQM?= =?us-ascii?q?BHVwFCwIBCBguMiUCBA4FiWwIsl+LNQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GT?= =?us-ascii?q?IIFgmqEVIM0gjEBBJwhAZIpkRiTMAEfOIEBVBVPAYY7dYkbgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,218,1484006400"; d="scan'208";a="211843880" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Feb 2017 09:16:08 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1S9G7Bv008062 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Feb 2017 09:16:08 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Feb 2017 04:16:07 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 28 Feb 2017 04:16:07 -0500 From: "Stefano Previdi (sprevidi)" To: "bruno.decraene@orange.com" Thread-Topic: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 Thread-Index: AQHSjFhvSzLwcTXrbE+YPFZw1aADF6F+gbSA Date: Tue, 28 Feb 2017 09:16:07 +0000 Message-ID: References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.84.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 09:16:10 -0000 Hi Bruno, thanks for the review. I integrated all the comments in the new version I= =92m going to submit very soon. One last comment here below: > On Feb 22, 2017, at 2:00 PM, bruno.decraene@orange.com wrote: > =20 > 2) For the document write up, are there any known deployment of draf= t-ietf-spring-segment-routing-msdc? >=20 >=20 > 3) =A7 2.1. Reference design >=20 > =93 o Each node is its own AS (Node X has AS X) > =20 > * For simple and efficient route propagation filtering, Nodes 5, > 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS, > Nodes 9 and 10 share the same AS. > =20 > * For efficient usage of the scarce 2-byte Private Use AS pool, > different Tier-3 nodes might share the same AS. > =20 > * Without loss of generality, we will simplify these details in > this document and assume that each node has its own AS.=94 > =20 > =20 > First 2 bullets are contradicting each other=92s. why so ? First bullet refers to tier-1 and tier-2. second bullet refers to = tier-3. thanks. s. =20 From nobody Tue Feb 28 11:29:48 2017 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 98FDB12969B for ; Tue, 28 Feb 2017 11:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjLIZ2CVk6UV for ; Tue, 28 Feb 2017 11:29:43 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 BB58C1294FD for ; Tue, 28 Feb 2017 11:29:42 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n186so33698372qkb.3 for ; Tue, 28 Feb 2017 11:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0jIxSQYMC8xXQOv2arW35UFWGmmGBBfK28fZMFWfl9U=; b=bNWsY+UIoWYpIF7EA3HVcG1SP0BPzZnvMV1cpAP90DdmQjEKNzKTdvbCPgDA+c55o3 9UcgXJ2WzEAm1K1lOQU5F0YN69iYLz3QlVPyOylay/NAB95OhL3B4Zp3uMAdFnIDCxZ/ PW2b9ImgBi7m6qWbWodlyhXlRqXNoSy9jZFhAS4SXV8bridL7ugT80toqKCdDkbnDpg8 ZbFUnLKxk2afBoep8IrOHc92Ex7nRTDxxmBSvuyn4ox3xujCUGBCKuvzA/UIwfRLWPGD EDQo0hVEiIkOMoBVNybIUR+5rj3M4791mI55I8c8fLpcKahuiTw9d2n+bZn0Kvh2yWZy 9m/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0jIxSQYMC8xXQOv2arW35UFWGmmGBBfK28fZMFWfl9U=; b=pMuFjiahPvBoCWhoitF9jfSgoVKs/Hy2W5Kr57t7jAA6E8TiOVno7YunzfeSnzJxJs j4fMkDiU9Z8FrpQ7oxfaYfe/iT5BlJfEuOzx4nPWnV/NwgzOrEbtvHFLHilXJROKMle0 cXKWIPq4zWecOGo3I8TqeMTkOml0IlMa+COaSEQpGyWt1FeK/Sr/6OtDfKSe6A9bLkV6 zZQ0e0WlS2QrZIRnyvhDPONl9apHR4An34FnD6uHHiFNyYlZ2zQpL0z5fyt5mGiQ6vf4 3MjmgYrh/FmBNoMG6Wug6xZAuWDZ08NSmGj6JEtiqXkD/aLeZNDjGOc0PtJ1NB/3+U3/ 1cMw== X-Gm-Message-State: AMke39lNS0J4t6+GroCzgKytrdMBcdgbxevBxt7fwhCaHTGPFjcujvbnkJn1fngqLB6YMpTeN5iRBrU7/LAXKA== X-Received: by 10.200.39.97 with SMTP id h30mr4796360qth.18.1488310181776; Tue, 28 Feb 2017 11:29:41 -0800 (PST) MIME-Version: 1.0 Sender: ghanwani@gmail.com Received: by 10.200.4.2 with HTTP; Tue, 28 Feb 2017 11:29:41 -0800 (PST) In-Reply-To: References: <27991_1487670653_58AC0D7D_27991_2292_1_53C29892C857584299CBF5D05346208A1ED7122E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <18673_1487691447_58AC5EB7_18673_4491_1_53C29892C857584299CBF5D05346208A1ED71F65@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Anoop Ghanwani Date: Tue, 28 Feb 2017 11:29:41 -0800 X-Google-Sender-Auth: 4_fGn9vC5Hzxxor6xjqZmwBYDLk Message-ID: To: "Stefano Previdi (sprevidi)" Content-Type: multipart/alternative; boundary=001a11404268b355d205499c37ca Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-msdc-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:29:44 -0000 --001a11404268b355d205499c37ca Content-Type: text/plain; charset=UTF-8 I support publication of the document as an informational RFC. Below are my comments. Thanks, Anoop == - pg 5, line 1 What is the criteria that allow sharing the AS number? Is there a reference? - pg 6 "This means that every new connection will be established obliviously (memory- less) with regards to the paths chosen before, or chosen by other nodes." I am not sure what "chosen by other nodes" adds. I think it can be removed. - pg 7 "local label 1600x" -> "local label (16000 + x). Also because of the way loopbacks are assigned, does this mean that the number nodes that this scheme can handle is 512? May be good to mention why this is considered a good number. - pg 11 "BGP Prefix Segment 16011 then directs the packet down to Node11 along the path (Node5, Node9, Node11)." I think it would be worth mentioning that node 9 need not appear in this path. In general, because of the nature of clos topologies, there is no need to have intermediate nodes between the spine and the ToR on the way down. (If there is, it would be good to know why.) Editorial - some inconsistencies throughout. would be good to make them consistent. Node1 and Node2 vs Nodes 1 and 2 vs "Node1" and "Node2" data center, data-center, DC - Spell out SRGB and AIGP at first use. - pg 1 "use-case use-cases" -> use-cases - pg 5 "via BGP session" -> "via a BGP session." (missing 'a' and period.) "address of it's loopback" -> "address of its loopback" "per-flow ECMP that does not" -> "per-flow ECMP does not" "placed on one path over others" -> "placed on one path over others." (missing period) " implements oblivious" -> "implements an oblivious" - pg 6 "Absence of path visibility" -> "The absence of path visibility" - pg 7 "Figure 2 zooms on" -> "Figure 2 zooms in on" - pg 8 "an nondeterministic label" -> "a non-deterministic label" - pg 9 "Referring to Figure 1Referring to Figure 1" -> "Referring to Figure 1" - pg 11 "if Node7 does not support" -> "even though Node7 does not support" - p12 Missing a period at the end of the first and second items in Sec 4.3. "Attribute adverting" -> "Attribute advertising" - pg 14 "let us illustrate this assuming" -> "let us illustrate this concept assuming" "flow to Z" -> "flow to HostZ" "assuming A is made aware" -> "assuming HostA is made aware" - pg 15 "the latter one" -> "the last one" - pg 16 "monitoring network elements health" -> "monitoring network elements' health" "inSection 7.2" -> "in Section 7.2" "BGP Labelled Unicast" -> "BGP Labeled Unicast" (also on pg 17) - pg 18 "thanks to PHP" -> "because of PHP" "Internet- scale" -> "Internet-scale" (extra space) "go-to-the- Internet" -> "go-to-the-Internet" " do not recommend to use" -> "do not recommend using" "operation viewpoint" -> "operational viewpoint" - pg 19 "allows to construct" -> "allows us to construct" "Spine5 and Spine 8" -> Node5 and Node8 "(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999]...)." -> "(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999], ...)." -> --001a11404268b355d205499c37ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support publication of the do= cument as an informational RFC.

<= div class=3D"gmail_extra">Below are my comments.

Thanks,
Anoop

=3D=3D

- pg 5, line 1
=C2=A0 What is = the criteria that allow sharing the AS number?=C2=A0 Is there a reference?<= br>

- = pg 6
=C2=A0 "This means that every new connection will be establi= shed=C2=A0
=C2=A0 =C2=A0obliviously (memory- less) with regards to the = paths chosen=C2=A0
=C2=A0 =C2=A0 before, or chosen by other nodes= ."
=C2=A0 I am not sure what "chosen by other nodes&quo= t; adds.=C2=A0 I think it=C2=A0
=C2=A0 can be removed.=C2=A0
<= /div>

- pg 7
=C2=A0 "local label 1600x&qu= ot; -> "local label (16000 + x).
=C2=A0 Also because of t= he way loopbacks are assigned, does this mean that the number nodes that th= is scheme can handle is 512?=C2=A0 May be good to mention why this is consi= dered a good number.

- pg 11
=C2=A0 "BGP= Prefix Segment 16011 then directs the packet down to Node11 along the path= (Node5, Node9, Node11)."
=C2=A0 I think it would be worth mention= ing that node 9 need not appear in this path.=C2=A0 In general, because of = the nature of clos topologies, there is no need to have intermediate nodes = between the spine and the ToR on the way down. =C2=A0(If there is, it would= be good to know why.)

Editorial

- some inconsistencies t= hroughout. =C2=A0would be good to make them consistent.
=C2=A0 Node1 and Node2 vs Nodes 1 and 2 vs "Node1" a= nd "Node2"
=C2=A0 data center, da= ta-center, DC

- Spell out SRGB and AIGP at first use.

- pg 1
=C2=A0 "use-case use-cases" -> use-cases

- pg 5
=C2=A0 "via BGP session" -> "via = a BGP session." =C2=A0(missing 'a' and period.)
=C2=A0 "address of it's loopback" ->= "address of its loopback"
= =C2=A0 "per-flow ECMP that does not" -> "per-flow ECMP do= es not"
=C2=A0 "placed on one pat= h over others" -> =C2=A0"placed on one path over others."= =C2=A0(missing period)
=C2=A0 " imple= ments oblivious" -> "implements an oblivious"

- pg 6
=C2=A0 "Absence of path visibility" -> &= quot;The absence of path visibility"
= =C2=A0=C2=A0
- pg 7
=C2=A0 "Figure 2 zooms on" -> "Figure 2 = zooms in on"

- pg 8=C2=A0
=C2=A0 "an no= ndeterministic label" -> "a non-deterministic label"

- pg 9
=C2=A0 "Referring to Figure 1Referring to Figure 1" -> = "Referring= to Figure 1"

- pg 11
=C2=A0 "if Node7 does not support" -> "even thoug= h Node7 does not support"

- p12=
=C2=A0 Missing a period at the end of the first and secon= d items in Sec 4.3.
=C2=A0 "Attribute adverting= " -> "Attribute advertising"

=
- pg 14
=C2=A0 "let us illustrate this ass= uming" -> "let us illustrate this concept assuming"
=C2=A0 "flow to Z" -> "flow to HostZ"
=C2=A0 "assuming A is made aware" -> "assu= ming HostA is made aware"
=C2=A0=C2=A0
- pg 15
=C2=A0 "the latter one" -> "t= he last one"

- pg 16
=C2=A0 "mon= itoring network elements health" -> "monitoring network elemen= ts' health"
=C2=A0 "inSection= 7.2" -> "in Section 7.2"
=C2=A0 "BGP Labelled Unicast" -> "BGP Labeled Unicast&qu= ot; =C2=A0(also on pg 17)

- pg 18
=C2=A0 "th= anks to PHP" -> "because of PHP"
=C2=A0 "Internet- scale" -> "Internet-scale"= =C2=A0(extra space)
=C2=A0 "go-to-the= - Internet" -> "go-to-the-Internet"
=C2=A0 " do not recommend to use" -> "do not r= ecommend using"
=C2=A0 "operation= viewpoint" -> "operational viewpoint"

- pg 19
=C2=A0 "allows to construct" -> "allows = us to construct"
=C2=A0 "Spine5 a= nd Spine 8" -> Node5 and Node8
=C2= =A0 "(e.g. ToR1&= #39;s SRGB is [1000, 1999], ToR2's SRGB is [2000, 2999]...)." ->= ;
=C2=A0=C2=A0"(e.g. ToR1's SRGB is [1000, 1999], ToR2's SRG= B is [2000, 2999], ...)." ->

--001a11404268b355d205499c37ca--