From nobody Mon Jan 1 16:15:02 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF981270A3; Mon, 1 Jan 2018 16:14:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, bruno.decraene@orange.com, draft-ietf-spring-oam-usecase@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151485209195.22137.4888091412095566551.idtracker@ietfa.amsl.com> Date: Mon, 01 Jan 2018 16:14:51 -0800 Archived-At: Subject: [spring] Document Action: 'A Scalable and Topology-Aware MPLS Dataplane Monitoring System' to Informational RFC (draft-ietf-spring-oam-usecase-10.txt) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 00:14:52 -0000 The IESG has approved the following document: - 'A Scalable and Topology-Aware MPLS Dataplane Monitoring System' (draft-ietf-spring-oam-usecase-10.txt) as Informational RFC This document is the product of the Source Packet Routing in Networking Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ Technical Summary 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 Trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. Working Group Summary Support has been consistent in the WG. Document Quality There is a prototype implementation which has been running in a research backbone. The resulting measurements have been compared to the results measured by three IP Performance Measurement Work Group (IPPM WG) standard conformant Measurement Agents and the results are equivalents. This is documented in draft-leipnitz-spring-pms-implementation-report-00. Personnel Bruno Decraene is the Document Shepherd. Alvaro Retana is the Responsible Area Director. From nobody Tue Jan 2 06:11:07 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91C312706D; Tue, 2 Jan 2018 06:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0MDgvCTueF9; Tue, 2 Jan 2018 06:10:56 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 C60D41201F8; Tue, 2 Jan 2018 06:10:55 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w02EADIE031337; Tue, 2 Jan 2018 06:10:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=PPS1017; bh=5iQkuFxL7/H12K3cy8g89QPYp9NlQvEW1Y3m4IGaEt0=; b=Q5FFmqx+55Z9+NVwkC5jgED940HI8eLyAkisQEy45cv2oVa5Uf0MLI6pNCydhD0zF/OG p3HQEVBWXAaT46eCNg/pEAPw0f521mvPfvjtFDRTtCsA0FJxQ2h5X1FqcXE6fmzYugNr BZSPrCbsByvNXVqAWz7Y9lSnubBT5vEJ4OvuTRy1vMBKCD2Yc9z3I76R9HPoyHjc1ySB qdyVzY1cYLancreX95w7nCgJHHORYsSmIoa71CWVpGYEdmgGrs49q9s2HP0dksPWnfuD CoJS7IyHHPJAiW34avrauw7YzTsTYDuRprJOa2iIt0i0qr8i7F9hGr862btgBsjwtuck lg== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0048.outbound.protection.outlook.com [216.32.180.48]) by mx0b-00273201.pphosted.com with ESMTP id 2f864k0fw5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Jan 2018 06:10:53 -0800 Received: from [172.29.35.60] (66.129.241.11) by BY2PR05MB2295.namprd05.prod.outlook.com (10.166.112.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Tue, 2 Jan 2018 14:10:50 +0000 To: Robert Raszuk Cc: "bess@ietf.org" , draft-dawra-idr-srv6-vpn.authors@ietf.org, spring@ietf.org References: From: Eric C Rosen Message-ID: <7dd8f2db-72dd-da17-6dc7-39f6ab44f543@juniper.net> Date: Tue, 2 Jan 2018 09:10:45 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------54A25299DC12F9DDE693C821" Content-Language: en-US X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: MWHPR1401CA0024.namprd14.prod.outlook.com (10.174.253.162) To BY2PR05MB2295.namprd05.prod.outlook.com (10.166.112.145) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 02559f55-eb80-4058-5013-08d551eaa15a X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(48565401081)(2017052603307)(7153060); SRVR:BY2PR05MB2295; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 3:J1iOVesEXOOo9Ei6bZ58Zf4mUfKeiS3I4rVl/13TG4M1Mehe7bDRWEBqhbUxSDb6K/XTtsib7TuJjPjeXA8jRqOQ3AvHyTz4HshTf2IC7gpCg3q7WeZnchoBMOp8vU1zc41qsqwjfmg7HfRvG0MGLBbUv0SKwh8bTia5djUsELXKeScRBIkEz1K8Yalh4CDC/bAt7HwhJFwX7zxDcz5szyPbJtbGVTX8xJJD+RVTlwkGvgQl05BHomcd0ZEH7aff; 25:8E3AzeBlQBoOYPjfxLGtVYathxdKBxXr3av04H0mg3AK7zHepYkA5U+dit84kHVFI8X5xaR5CSSXlaKy9iiCvWI68UOD5R1KgPRRnal22JmgELbqJ0Wm4ZiWdv5eCNd3yPYtrx3ZArmi2Gylrvh84F9h6xlQTLfTmUa05HmwK9rm2rJHRNlI5EgiLTR9p1xBiPiIRXx3OoHBQhjNuUZiZM5sSC2CJ+KvhaUFpW8BahmF0b7te4dGnSnuRrPwG380E/z+zkSfJd3IVXlZfrQD8a4lKHTswINmPhDy2LT9OStreT847TEUlONtpzlJgp8vMokqCzuwM5Sb5wxXlQXmrA==; 31:nxYjL85cCIbbdwwpy/HYrlurrQhu3Llj9swntxNMnnyrsE9zomhUUb3aovTKsZhwlItSpGDpMdf3gK8bsj/DPRMFhpObu18r/UK3IymgJQSH88vw4zdgHl7Y6NGemM+Me5Qp85nw9hFXWgfmyxljYSrndC9rCyoNIogfP8S4hxszgFP0vYvgrKcAIPF6Y1WLHtxHlNFutUQas26vflOE2eMNYijqMeFgyeeftbGTNl8= X-MS-TrafficTypeDiagnostic: BY2PR05MB2295: X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 20:RTWHkgwOv4ZZpekM09rl2Cvg7e7vEp0sg41KPPK1l++klpQkKUMns5hssDCGKOpojTGkB+14SeEeV9QbJVkHWNITmw51oQ7+IMvB3W5l5lYAZs5fW6EGx1FkCAzHdn0JAcOmJ31skflo61IAQhFx1XQcaqnSbr9N9Pq39bvgmvFQUXm9j/Fib9oz9ICS4NshfS01W8bUgAS5PmDgeh8iyESoJ0ZHpsQnPoESsiAWaxEd17Q5UAXPEDrkk0pdYiflgX0Pj4zxhPxp2yT91pZCeFFQ0ooEdzCqBweFvEMAefHTQZaTDQfXKZZIuoi7tQv25G+FuVnRq4xogWY33VaIellEXU230hlKt6wSkeEH7xtfDAAAAKlV8HpRAKeg43JPImAyj9LSX6daMM6aAHY/+2mxgqYi32RbjR4hFrA3zwIQ8zHCwgjxKdVhJExpbcUaFeyMbNNWcH78ZytpeQMc5EugvObjNZUYKkCU7rPIctFQpBhj8qNhVAPgEfUyApozXYMbGIKgK7w4AqXzjmrUUt3xXWGORewWbAEkwqEKK+EpMmKsXGmoZ4QVNv+f2uqojg+u7ZFS8fPRx/xC/PrbN70JpHpcV/6qddNGr6QOCnQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(944501075)(3002001)(6055026)(6041268)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BY2PR05MB2295; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR05MB2295; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 4:RGeeU/lSwEj1L3L4QiIkzYZwWgoSS2V87C/hOL52IbW2N0BDIJNT6OCxH2Uor+iCHS+q8Caaps1GBUze/hdrirKURTn0AwU63/MgBjLvYTfakOZfYK0PWmRwDgxFw7XRJO2LDf0IzposkPki3eK8z+ujFoOL9N/V0FUoqHrnqRURXdVgI7iB67wBA4qbUO2brH+Wvsag0Ix/MjmPr8TpMAQtFGyyfm9oyyHlfJr5wXAJmN/xOP0spcLkcH1qSD63nENOYcoseRz9sb5WF4wQR1q5L++OD2ZIqxAyMHN+VzH6RSfhb2mosLB7FSL6/jTOL/IcDrrcEHzHx4lXqb/tbA== X-Forefront-PRVS: 0540846A1D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39380400002)(376002)(366004)(396003)(39860400002)(346002)(24454002)(199004)(189003)(230783001)(8676002)(65956001)(65806001)(81166006)(77096006)(3846002)(84326002)(6116002)(31686004)(83506002)(66066001)(90366009)(386003)(6486002)(53546011)(37036004)(81156014)(16576012)(58126008)(97736004)(68736007)(16586007)(59450400001)(316002)(54896002)(86362001)(64126003)(229853002)(76176011)(65826007)(2906002)(5660300001)(8936002)(4326008)(6246003)(31696002)(52116002)(7736002)(106356001)(6916009)(2950100002)(16526018)(478600001)(25786009)(36756003)(33964004)(3260700006)(53936002)(6666003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2295; H:[172.29.35.60]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB2295; 23:T+b0pLaHwu53Gs7gbdDsCx7S5D8tXc2edRD4EOqZr?= =?us-ascii?Q?WfFo4gwzDwBP7LAkJ40OI1YWRI2rKwWwKZ+39+2JVlm7MryaZsXjl+ANlaXX?= =?us-ascii?Q?EdP56Jm1BKF+uYEpru4X+dCJYgMGTDB0GeOhUKubzwgVr0oW9hqsglDdxDSg?= =?us-ascii?Q?99tZpCU3ZbY8fx1C103opI6M8vB22apiHe+5qjrYleg15SRF9Lh+JLevngEq?= =?us-ascii?Q?FsICdrS2C7KF+hdi87iiYY/MJQb1MClvthI8DQOGe61lhqEbGk4xYFZpxWP3?= =?us-ascii?Q?8pkvCuxoh4/ni10YDe6uWioT1uGEX/DEeN920mZV/0SztAHlbcs20DX4sTAo?= =?us-ascii?Q?1GiFzpcpY7dBAmIcTNU+//ZKrxFiXki7wKpQGC28DQvwWQUmxv7Ls5gymGeY?= =?us-ascii?Q?AIetdJYaf1bBFzYr6wbWTw6oPAazoMG39t9FDFJnHH4qX1NpeMx89lP1sJaD?= =?us-ascii?Q?P4B1gGqKA7bybmy0O10MNADsHmt+OQx1SmkuNEjDdVNYM9hNYXeNtABGoqY6?= =?us-ascii?Q?OitWxV/CBMXfdlJfbbGdqRb3zOb/VT6u4MnXPmrHOwL7rkdmfzOjszEjqZdE?= =?us-ascii?Q?1VoRy9IyJVkH+H8J5q801QTY7jnTvaUAXTHFeS/Tz5XpJCsMx+/3UoYmkjRm?= =?us-ascii?Q?jff9pFhdoNLQkpoquJnboHw6kdbGIDLx4t3s77XZpAjWIJ7CHw4tDiwaplEL?= =?us-ascii?Q?d+lFadFWgr1v9gJru/Qsi6Is+7pgs8pGPKZXPHWCpdEcy2dbCozWkBXkvs2W?= =?us-ascii?Q?US//601PRCP++hWA+gEv/bQI/VhfXt5rRbau2afdfrsT+g6Z8AvZMfdWBbQR?= =?us-ascii?Q?lpyQjHwujM0nQW4M0fLdoGslY3N0mLwZb/LRfDZX8wrY1zsJTPKVcUhmRqdS?= =?us-ascii?Q?ug5i/jyP7w1WQ2U3gaZm2apv7OMwIP834xtX27fHfGSf+0m8acgzPpg0JhT3?= =?us-ascii?Q?jh1/njcH6xlnLt4BkFWDroAn+jqS7OuWmjpblbrS54TYNlogcWYSwYmV+Bpt?= =?us-ascii?Q?UGYGxd9MXqhC6nILwVq+45ZfnVjOJVKYldJW7KMEBlsiTGutSaekhCBwW6iO?= =?us-ascii?Q?AGPHLMNjmkD44x0Zw0IXj1eIgU5T4ygPFHzPupCPTRc8BXVI26cRM+vmhLnH?= =?us-ascii?Q?J+SMmVxMfgdpQJmGXK94+qZWCmF2MV+NQ6Enzwr2ZinQ53EiVaYgA547QdZK?= =?us-ascii?Q?S9v7PzDOEVj54I6fB+sjNq/9G26bqDf0TNKMNk3bG+KYd6iUtNNYESXQ1EGK?= =?us-ascii?Q?KDGhK7jgTXhvwcFaCtO6qlLPpemXOMDk4rK7Sn/+uJ1NEh/R8/FfPMnEnm6d?= =?us-ascii?Q?124ZPYMHBmXVzDGi8ZiwMu9V2+d87uO9ANZJXkHdqTXw6RByk2gVjxCgBpzw?= =?us-ascii?Q?DdOqOtKWSB7ToTvtNSDFSdjtsniUgngu1+MiH90SK2qG8sZ?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB2295; 6:30sNbssdfCFWALN7n9wfjqVXH6Lo63XF1nqBo+/8ZVImUsxGPkf+PNpSJh5akqpNLmprJIfrYWlD0DG8HK816Z4P4Zp99fRC1xekjUlIEqCDhdVmD+37ilEMIso0+f2+a0jri+WO59Mus0JGschPcz5QOvRCVhb47HIAEUUpKbodkBf7TqLsp0Hhi5LFa+ILjsajZoEm2G0q/HGcAmNvUcCF2AlsreFUg0guz8Oe7NxLCDsS2cSDgIyR7zbu2RfJBJbXiC4j/KqZnqtaR5eGPStN+C/pxWJdBKDJLrL09arPQkukWv/oUEAQefvR9Qw//SJ5S88cD8E5yn2LkbeJnLfeTZ0HKBeEhszHNG6R4g8=; 5:HC5Qvva3YbMxL4P3/7xl3f40vxZxSI/vr+OAtxDVdqgCRp+Djk0o7x6obkjLLcnnJ1xAnP073PiSUmR5J7i6YSeOD7LfPn/cLIfcK2p424UZnef2hfqnUvZhSLx7yLIbFj8ZIviEJA5AiPC9kX/z0lTrT297Ot0rPii0aNGjVWc=; 24:mxOOsHbb66zToaTvUNzqF6QwgjbqOSjFIXqKWxdfV9AsI0/lPK9O10IGMr2PI/tgKRhsGzcT+BQ+7sQFGzoQwtTqe+z+KH1RDpKGA3mkso0=; 7:1S8AJwNla2TOjhAwLT2ZzYoDJWa4tX0ub/umLJ+7xv1ijAHOLMnAZ7/hzyMUnf29Dps1ruDh76Z7dUc6slv0+kvIVFG6C6Wq4dQl5YCu7ND8e42iTSTz5mumrWnFCXdSfRvScXiP6TtYTHXBLhUWEBoj5kb9KrOryjPtgYjtW0L0nd5ls7wuhyfaYUQ4TpITSnOPn1xrFWsvyZeAv77CxlGkAr9qKqI22CqlYwV3RTYad8o5yL7y1mbJX0x0ZdOI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2018 14:10:50.2790 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 02559f55-eb80-4058-5013-08d551eaa15a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2295 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020210 Archived-At: Subject: Re: [spring] Comments on draft-dawra-idr-srv6-vpn-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 02 Jan 2018 14:10:59 -0000 This is a multi-part message in MIME format. --------------54A25299DC12F9DDE693C821 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/28/2017 1:55 PM, Robert Raszuk wrote: > Ok let's start all over :) From the draft: The SRv6 VPN SID MAY be routable within the AS of the egress-PE and   serves the dual purpose of providing reachability between ingress-PE   and egress-PE while also encoding the VPN identifier. I took this to mean that  a single IPv6 address could cause the backbone to forward the packet to the egress-PE and cause the egress-PE to look up the payload's IP address in a VRF which is identified by that same IPv6 address.  Did I misunderstand that? > **** This suggests that an IPv6 address has to be assigned to each > VRF (for > **** per-VRF "labeling"), or even to each CE (for per-CE labeling). > > > ​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 > SID which when appended to IPv6 prefix forms a complete SRv6 SID. > Semantics does matter here. ​ Given the above quote from the draft, I'm not sure what is wrong with what I said. > > **** If those addresses are routable, doesn't this create a > security issue > **** as discussed in RFC 4023 Section 8.2? > > > ​PE's loopback address say /64 being routable causes any security risk ? ​ Please see the reference. > > **** The phrase "only has local significance" suggests that these > SIDs are > **** not routable. But later on there is a suggestion that they are > **** routable, or at least that they might be. > > > ​Again SIDs are not routable and they have only local significance - > true. ​They are prepended to say loopback address to form IPv6 SID. > > **** So there are a number of options: > **** - not routable > **** - globally routable > **** - routable only within egress AS > > > ​This is referring to routability of SID ... not right. SID does not > need to be routable. What prefix they are part of may be routable. ​​ Just replace my use of the term "SID" with the longer term "the IPv6 address of which the SID is a part". > >    and the BGP ingress device receiving this route >    MAY choose to encapsulate or insert an SRv6 SRH, second it > indicates >    the value of the SID to include in the SRH encapsulation.  For > L3VPN, >    only a single SRv6-VPN SID MAY be necessary. > > **** I don't understand the phrase "only a single SRv6-VPN SID MAY be > **** necessary". > > > ​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​ Still don't understand what is being said. > > >    If the BGP speaker supports MPLS based >    L3VPN simultaneously, it MAY also populate the Label values in > L3VPN >    route types and allow the BGP ingress device to decide which >    encapsulation to use.  If the BGP speaker does not support MPLS > based >    L3VPN services the MPLS Labels in L3VPN route types MUST be set to >    IMPLICIT-NULL. > > **** Please provide a reference that specifies how you set the > Label field > **** of a SAFI-4 or SAFI-128 route to "implicit null".  I don't > recall any > **** such thing existing in RFC 3107, 4364, or 8277. > > > > ​4364 does not restrict what value of VPN label is used - does it ? I > think this draft now right here defines ​how to read implicit-null > being placed there :) It's not my idea though - so I will let real > inventors to comment on it more. > > **** If you mean "set to three" (the value defined in RFC 3032 to > represent > **** "implicit null"), I don't think the SAFI-4/SAFI-128 > implementations > **** generally interpret the value three in that manner. > > > ​As mentioned I think it just is being defined here and now. ​ I didn't see any mention of the numeric value to put in the label field of the NLRI. > or to define a new special or reserved label ​for that embedded > signalling. Some discussion of why this won't cause any backwards compatibility problems would be appropriate. > > > **** I'm not really sure what you're trying to do here. There are > at least > **** four cases to consider: > > **** 1. For the case where the backbone doesn't have MPLS, there > is no harm > **** in saying "set the label to zero". > > > ​Really ? ​What does the backbone having or not having MPLS has to do > with this ? Underlay forwarding does not matter and this is what I > read as "backbone". What I meant is that if it is known a priori that SRv6 is being used instead of MPLS, the label value obviously doesn't matter, because it will never be used. > > **** 2. For the case where the backbone supports both MPLS and > SRv6, and > **** some PEs support L3VPN both ways, while others support only > MPLS-based > **** L3VPN, then a real label needs to be put in. > > > ​OK.​ > > **** 3. For the case where the backbone supports both MPLS and > SRv6, but a > **** particular egress PE only supports SRv6, there needs to be > some way to > **** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the > **** presence of the prefix-SID attribute with VPN-SID TLV is > sufficient. > > > ​Perhaps not ... and this is exactly ​the case trying to be addressed. Why isn't the presence of the attribute sufficient in this case? > > **** 4. For the case where the backbone supports both MPLS and > SRv6, the > **** egress PE supports both for transit, but the egress PE only > supports > **** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes > should be a > > > ​Label in SAFI 1 ? ​ Sorry, I meant SAFI-4.  Actually, only SAFI-128 really matters in this context, I think. --------------54A25299DC12F9DDE693C821 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/28/2017 1:55 PM, Robert Raszuk wrote:
Ok let's start all over :)

From the draft:

    The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
  serves the dual purpose of providing reachability between ingress-PE
  and egress-PE while also encoding the VPN identifier.

I took this to mean that  a single IPv6 address could cause the backbone to forward the packet to the egress-PE and cause the egress-PE to look up the payload's IP address in a VRF which is identified by that same IPv6 address.  Did I misunderstand that?

**** This suggests that an IPv6 address has to be assigned to each VRF (for
**** per-VRF "labeling"), or even to each CE (for per-CE labeling).

​No one suggests that. VPN SID is not IPv6 address .. it is part of v6 SID which when appended to IPv6 prefix forms a complete SRv6 SID. Semantics does matter here. ​

Given the above quote from the draft, I'm not sure what is wrong with what I said.


**** If those addresses are routable, doesn't this create a security issue
**** as discussed in RFC 4023 Section 8.2?

​PE's loopback address say /64 being routable causes any security risk ? ​

Please see the reference. 


**** The phrase "only has local significance" suggests that these SIDs are
**** not routable. But later on there is a suggestion that they are
**** routable, or at least that they might be.

​Again SIDs are not routable and they have only local significance - true. ​They are prepended to say loopback address to form IPv6 SID. 

**** So there are a number of options:
**** - not routable
**** - globally routable
**** - routable only within egress AS

​This is referring to routability of SID ... not right. SID does not need to be routable. What prefix they are part of may be routable. ​​

Just replace my use of the term "SID" with the longer term "the IPv6 address of which the SID is a part".

 
   and the BGP ingress device receiving this route
   MAY choose to encapsulate or insert an SRv6 SRH, second it indicates
   the value of the SID to include in the SRH encapsulation.  For L3VPN,
   only a single SRv6-VPN SID MAY be necessary.

**** I don't understand the phrase "only a single SRv6-VPN SID MAY be
**** necessary".

​Analogy to basic L3VPN when you have VPN label and underlay LDP label. ​

Still don't understand what is being said.



   If the BGP speaker supports MPLS based
   L3VPN simultaneously, it MAY also populate the Label values in L3VPN
   route types and allow the BGP ingress device to decide which
   encapsulation to use.  If the BGP speaker does not support MPLS based
   L3VPN services the MPLS Labels in L3VPN route types MUST be set to
   IMPLICIT-NULL.

**** Please provide a reference that specifies how you set the Label field
**** of a SAFI-4 or SAFI-128 route to "implicit null".  I don't recall any
**** such thing existing in RFC 3107, 4364, or 8277.


​4364 does not restrict what value of VPN label is used - does it ? I think this draft now right here defines ​how to read implicit-null being placed there :) It's not my idea though - so I will let real inventors to comment on it more. 
 
**** If you mean "set to three" (the value defined in RFC 3032 to represent
**** "implicit null"), I don't think the SAFI-4/SAFI-128 implementations
**** generally interpret the value three in that manner.

​As mentioned I think it just is being defined here and now. ​

I didn't see any mention of the numeric value to put in the label field of the NLRI.  

or to define a new special or reserved label ​for that embedded signalling.

Some discussion of why this won't cause any backwards compatibility problems would be appropriate.




**** I'm not really sure what you're trying to do here. There are at least
**** four cases to consider:

**** 1. For the case where the backbone doesn't have MPLS, there is no harm
**** in saying "set the label to zero".

​Really ? ​What does the backbone having or not having MPLS has to do with this ? Underlay forwarding does not matter and this is what I read as "backbone".

What I meant is that if it is known a priori that SRv6 is being used instead of MPLS, the label value obviously doesn't matter, because it will never be used.

 

**** 2. For the case where the backbone supports both MPLS and SRv6, and
**** some PEs support L3VPN both ways, while others support only MPLS-based
**** L3VPN, then a real label needs to be put in.

​OK.​
 
**** 3. For the case where the backbone supports both MPLS and SRv6, but a
**** particular egress PE only supports SRv6, there needs to be some way to
**** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
**** presence of the prefix-SID attribute with VPN-SID TLV is sufficient.

​Perhaps not ... and this is exactly ​the case trying to be addressed.

Why isn't the presence of the attribute sufficient in this case?


**** 4. For the case where the backbone supports both MPLS and SRv6, the
**** egress PE supports both for transit, but the egress PE only supports
**** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes should be a

​Label in SAFI 1 ? ​

Sorry, I meant SAFI-4.  Actually, only SAFI-128 really matters in this context, I think.


--------------54A25299DC12F9DDE693C821-- From nobody Tue Jan 2 07:29:57 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CBC12706D; Tue, 2 Jan 2018 07:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFQfaCEcshGD; Tue, 2 Jan 2018 07:29:48 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE3A124D68; Tue, 2 Jan 2018 07:29:48 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id l19so36479200wrc.2; Tue, 02 Jan 2018 07:29:48 -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=KrTdslgPCuPig7J7U1kptSvC4t8wJsrHXpDoiaH/RX8=; b=qobHAVj+1Wtx2L6hJV8uUgw+BnThgtc5/I93tBCvLHchdNwuGq3zqILhxOuEUEYpqr pdr10oApdk4/wLgmqlKjA1BXwCzG0scXztr2VFtZY1RIe/b4YBdk9gPtZIe/NV7j87Dt kOrpDYAStExfHDk/k1/Hfin15XMUxrxcHDxUaz85z248lJwYYn94IabOfp/Ek8pbA2N+ eoXDgn4xk27QePEelC37gN53EQRqEQLL1svqGSZqOYLOrPHfRNZKWQxk7XFkWaMGfP54 f/o0LJPafl7U7OK+KJLZGUJ1tba8EMVxobf67VB+9v/2NAelvtBQN+J9ntfqP5dY7NR/ 60Jg== 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=KrTdslgPCuPig7J7U1kptSvC4t8wJsrHXpDoiaH/RX8=; b=fZOX1osOx+MRe+J74xHHrruqxfDBmeSHLTunn8R1tLrEZ1WJXvpDcRBVjLud2OsTBE Bz9Wxjlv3YjI5qy6ep4UHVJ0RYqQtRavzhwHOlq8fs0+WAWik+6rNoVXU55Q1vbmxbsE yiu+UfmK1oJw0wi5qXwi/yXUKDsh5SYkQnfctkAxG7ik1sSCXOpapxZbQ8KNuOeP/OZn 9gAQBLI3IC/0kqAREibdTs5XZzigBeDguE/1KvDsgmMFrHS0+GHaI8BZaBB3eQ6I016V OuHaBH3gebwoHOwYOEMCPfLOCXsYvuLM9RM6HLnLs8t3vDH7oyqon1heMcBjp6bagsSh lwjA== X-Gm-Message-State: AKGB3mI/qUqqoKcP2YGvxt1dKkVVKqXgoFMADKqfdlhkyrCueFszrlg2 36Acxh7ZIwmY8cpSB4Svd8w7R3W2YbRTfxY6piz3fQ== X-Google-Smtp-Source: ACJfBov6YEEZne8Msf+TWb6xIXqefauidP3DJkKchzJiuXDl3y/MRpbWBIVGd48m2c0o4dghFvvXhDqBELSY5PkuKPc= X-Received: by 10.223.201.6 with SMTP id m6mr42382414wrh.107.1514906986198; Tue, 02 Jan 2018 07:29:46 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.54.217 with HTTP; Tue, 2 Jan 2018 07:29:45 -0800 (PST) In-Reply-To: <7dd8f2db-72dd-da17-6dc7-39f6ab44f543@juniper.net> References: <7dd8f2db-72dd-da17-6dc7-39f6ab44f543@juniper.net> From: Robert Raszuk Date: Tue, 2 Jan 2018 16:29:45 +0100 X-Google-Sender-Auth: 5SfXQQb8UJ2khQY4j3PGucUgKdo Message-ID: To: Eric C Rosen Cc: "bess@ietf.org" , draft-dawra-idr-srv6-vpn.authors@ietf.org, spring@ietf.org Content-Type: multipart/alternative; boundary="089e082f9bbcc7bb120561ccc4ad" Archived-At: Subject: Re: [spring] Comments on draft-dawra-idr-srv6-vpn-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 02 Jan 2018 15:29:51 -0000 --089e082f9bbcc7bb120561ccc4ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Being routable is not the same as having per VRF or per CE unique IPv6 address. Being routable to me means that lookup on first N bits of the address will result in forwarding action while the last N bits of the address can have local significance. The use of "dual purpose" is indeed a bit confusing in the draft however it is only MAY which one can also read as MAY NOT :) If operator wishes to have per VRF IPv6 SID implementation complaint with the draft allows that. However smart implementation may also provide mechanism not to require to have full IPv6 address per VRF or per CE. Cheers, R. On Tue, Jan 2, 2018 at 3:10 PM, Eric C Rosen wrote: > On 12/28/2017 1:55 PM, Robert Raszuk wrote: > > Ok let's start all over :) > > > From the draft: > > The SRv6 VPN SID MAY be routable within the AS of the egress-PE and > serves the dual purpose of providing reachability between ingress-PE > and egress-PE while also encoding the VPN identifier. > > I took this to mean that a single IPv6 address could cause the backbone > to forward the packet to the egress-PE and cause the egress-PE to look up > the payload's IP address in a VRF which is identified by that same IPv6 > address. Did I misunderstand that? > > **** This suggests that an IPv6 address has to be assigned to each VRF (f= or >> **** per-VRF "labeling"), or even to each CE (for per-CE labeling). >> > > =E2=80=8BNo one suggests that. VPN SID is not IPv6 address .. it is part = of v6 SID > which when appended to IPv6 prefix forms a complete SRv6 SID. Semantics > does matter here. =E2=80=8B > > > Given the above quote from the draft, I'm not sure what is wrong with wha= t > I said. > > > **** If those addresses are routable, doesn't this create a security issu= e >> **** as discussed in RFC 4023 Section 8.2? >> > > =E2=80=8BPE's loopback address say /64 being routable causes any security= risk ? =E2=80=8B > > > Please see the reference. > > > **** The phrase "only has local significance" suggests that these SIDs ar= e >> **** not routable. But later on there is a suggestion that they are >> **** routable, or at least that they might be. >> > > =E2=80=8BAgain SIDs are not routable and they have only local significanc= e - true. > =E2=80=8BThey are prepended to say loopback address to form IPv6 SID. > > **** So there are a number of options: >> **** - not routable >> **** - globally routable >> **** - routable only within egress AS >> > > =E2=80=8BThis is referring to routability of SID ... not right. SID does = not need > to be routable. What prefix they are part of may be routable. =E2=80=8B= =E2=80=8B > > > Just replace my use of the term "SID" with the longer term "the IPv6 > address of which the SID is a part". > > > >> and the BGP ingress device receiving this route >> MAY choose to encapsulate or insert an SRv6 SRH, second it indicates >> the value of the SID to include in the SRH encapsulation. For L3VPN, >> only a single SRv6-VPN SID MAY be necessary. >> >> **** I don't understand the phrase "only a single SRv6-VPN SID MAY be >> **** necessary". >> > > =E2=80=8BAnalogy to basic L3VPN when you have VPN label and underlay LDP = label. =E2=80=8B > > > Still don't understand what is being said. > > > > If the BGP speaker supports MPLS based >> L3VPN simultaneously, it MAY also populate the Label values in L3VPN >> route types and allow the BGP ingress device to decide which >> encapsulation to use. If the BGP speaker does not support MPLS based >> L3VPN services the MPLS Labels in L3VPN route types MUST be set to >> IMPLICIT-NULL. >> >> **** Please provide a reference that specifies how you set the Label fie= ld >> **** of a SAFI-4 or SAFI-128 route to "implicit null". I don't recall a= ny >> **** such thing existing in RFC 3107, 4364, or 8277. >> > > > =E2=80=8B4364 does not restrict what value of VPN label is used - does it= ? I > think this draft now right here defines =E2=80=8Bhow to read implicit-nul= l being > placed there :) It's not my idea though - so I will let real inventors to > comment on it more. > > >> **** If you mean "set to three" (the value defined in RFC 3032 to >> represent >> **** "implicit null"), I don't think the SAFI-4/SAFI-128 implementations >> **** generally interpret the value three in that manner. >> > > =E2=80=8BAs mentioned I think it just is being defined here and now. =E2= =80=8B > > > I didn't see any mention of the numeric value to put in the label field o= f > the NLRI. > > or to define a new special or reserved label =E2=80=8Bfor that embedded s= ignalling. > > > Some discussion of why this won't cause any backwards compatibility > problems would be appropriate. > > > > >> **** I'm not really sure what you're trying to do here. There are at lea= st >> **** four cases to consider: >> >> **** 1. For the case where the backbone doesn't have MPLS, there is no >> harm >> **** in saying "set the label to zero". >> > > =E2=80=8BReally ? =E2=80=8BWhat does the backbone having or not having MP= LS has to do with > this ? Underlay forwarding does not matter and this is what I read as > "backbone". > > > What I meant is that if it is known a priori that SRv6 is being used > instead of MPLS, the label value obviously doesn't matter, because it wil= l > never be used. > > > > **** 2. For the case where the backbone supports both MPLS and SRv6, and >> **** some PEs support L3VPN both ways, while others support only >> MPLS-based >> **** L3VPN, then a real label needs to be put in. >> > > =E2=80=8BOK.=E2=80=8B > > >> **** 3. For the case where the backbone supports both MPLS and SRv6, but= a >> **** particular egress PE only supports SRv6, there needs to be some way >> to >> **** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the >> **** presence of the prefix-SID attribute with VPN-SID TLV is sufficient= . >> > > =E2=80=8BPerhaps not ... and this is exactly =E2=80=8Bthe case trying to = be addressed. > > > Why isn't the presence of the attribute sufficient in this case? > > > **** 4. For the case where the backbone supports both MPLS and SRv6, the >> **** egress PE supports both for transit, but the egress PE only support= s >> **** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes should be a >> > > =E2=80=8BLabel in SAFI 1 ? =E2=80=8B > > > Sorry, I meant SAFI-4. Actually, only SAFI-128 really matters in this > context, I think. > > > --089e082f9bbcc7bb120561ccc4ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Being routable is not the same as having per VRF or = per CE unique IPv6 address. Being routable to me means that lookup on first= N bits of the address will result in forwarding action while the last N bi= ts of the address can have local significance.=C2=A0

The use of "dual purpose" is indee= d a bit confusing in the draft however it is only MAY which one can also re= ad as MAY NOT :) If operator wishes to have per VRF IPv6 SID implementation= complaint with the draft allows that. However smart implementation may als= o provide mechanism not to require to have full IPv6 address per VRF or per= CE.

Cheers,
R.


On Tue, Jan 2, 2018 at 3:10 PM, Er= ic C Rosen <erosen@juniper.net> wrote:
=20 =20 =20
On 12/28/2017 1:55 PM, Robert Raszuk wrote:
=20
Ok let's start all over :)

From the draft:

=C2=A0=C2=A0=C2=A0 The SRv6 VPN SID MAY be routable within the AS o= f the egress-PE and
=C2=A0 serves the dual purpose of providing reachability betwe= en ingress-PE
=C2=A0 and egress-PE while also encoding the VPN identifier.
I took this to mean that=C2=A0 a single IPv6 address could cause the backbone to forward the packet to the egress-PE and cause the egress-PE to look up the payload's IP address in a VRF which is identified by that same IPv6 address.=C2=A0 Did I misunderstand that?
**** This suggests that an IPv6 address has to be assigned to each VRF (for
**** per-VRF "labeling"), or even to each CE (for p= er-CE labeling).

=E2=80=8BNo one suggests that. VPN SID is not IPv6 address .. it is part of v6 SID which when appended to IPv6 prefix forms a complete SRv6 SID. Semantics does matter here. =E2=80=8B<= /div>

Given the above quote from the draft, I'm not sure what is wrong with what I said.


**** If those addresses are routable, doesn't this create a security issue
**** as discussed in RFC 4023 Section 8.2?

=E2=80=8BPE's loopback address say /64 being routable causes any security risk ? =E2=80=8B

Please see the reference.=C2=A0


**** The phrase "only has local significance" suggests that = these SIDs are
**** not routable. But later on there is a suggestion that they are
**** routable, or at least that they might be.

=E2=80=8BAgain SIDs are not routable and they have only local significance - true. =E2=80=8BThey are prepended to say loo= pback address to form IPv6 SID.=C2=A0

**** So there are a number of options:
**** - not routable
**** - globally routable
**** - routable only within egress AS

=E2=80=8BThis is referring to routability of SID ... not right. SID does not need to be routable. What prefix they are part of may be routable. =E2=80=8B=E2=80=8B

Just replace my use of the term "SID" with the longer term &q= uot;the IPv6 address of which the SID is a part".

=C2=A0
=C2=A0 =C2=A0and the BGP ingress device receiving this route
=C2=A0=C2=A0 MAY choose to encapsulate or insert an SRv6 SRH,= second it indicates
=C2=A0=C2=A0 the value of the SID to include in the SRH encapsulation.=C2=A0 For L3VPN,
=C2=A0=C2=A0 only a single SRv6-VPN SID MAY be necessary.

**** I don't understand the phrase "only a single SR= v6-VPN SID MAY be
**** necessary".

=E2=80=8BAnalogy to basic L3VPN when you have VPN label and underlay LDP label. =E2=80=8B

Still don't understand what is being said.



=C2=A0 =C2=A0If the BGP speaker supports MPLS based
=C2=A0=C2=A0 L3VPN simultaneously, it MAY also populate the L= abel values in L3VPN
=C2=A0=C2=A0 route types and allow the BGP ingress device to = decide which
=C2=A0=C2=A0 encapsulation to use.=C2=A0 If the BGP speaker d= oes not support MPLS based
=C2=A0=C2=A0 L3VPN services the MPLS Labels in L3VPN route ty= pes MUST be set to
=C2=A0=C2=A0 IMPLICIT-NULL.

**** Please provide a reference that specifies how you set the Label field
**** of a SAFI-4 or SAFI-128 route to "implicit null&quo= t;.=C2=A0 I don't recall any
**** such thing existing in RFC 3107, 4364, or 8277.


=E2=80=8B4364 does not restrict what value of VPN label is used - does it ? I think this draft now right here defines =E2=80=8Bhow= to read implicit-null being placed there :) It's not my idea though - so I will let real inventors to comment on it more.=C2=A0
=C2=A0
**** If you mean "set to three" (the value defined in RFC 3= 032 to represent
**** "implicit null"), I don't think the SAFI-4= /SAFI-128 implementations
**** generally interpret the value three in that manner.

=E2=80=8BAs mentioned I think it just is being defined here and now. =E2=80=8B

I didn't see any mention of the numeric value to put in the label field of the NLRI.=C2=A0=C2=A0

or to define a new special or reserved label =E2=80=8Bfor that embedded signalling.

Some discussion of why this won't cause any backwards compatibility problems would be appropriate.




**** I'm not really sure what you're trying to do her= e. There are at least
**** four cases to consider:

**** 1. For the case where the backbone doesn't have MPLS= , there is no harm
**** in saying "set the label to zero".

=E2=80=8BReally ? =E2=80=8BWhat does the backbone having or not having MPLS= has to do with this ? Underlay forwarding does not matter and this is what I read as "backbone".

What I meant is that if it is known a priori that SRv6 is being used instead of MPLS, the label value obviously doesn't matter, because it will never be used.

=C2=A0

**** 2. For the case where the backbone supports both MPLS and SRv6, and
**** some PEs support L3VPN both ways, while others support only MPLS-based
**** L3VPN, then a real label needs to be put in.

=E2=80=8BOK.=E2=80=8B
=C2=A0
**** 3. For the case where the backbone supports both MPLS and SRv6, but a
**** particular egress PE only supports SRv6, there needs to be some way to
**** instruct the ingress PEs to use SRv6 and not MPLS. Perhaps the
**** presence of the prefix-SID attribute with VPN-SID TLV is sufficient.

=E2=80=8BPerhaps not ... and this is exactly =E2=80=8Bthe case trying to be addressed.

Why isn't the presence of the attribute sufficient in this case?

**** 4. For the case where the backbone supports both MPLS and SRv6, the
**** egress PE supports both for transit, but the egress PE only supports
**** SRv6 for L3VPN, the label in the SAFI-1/SAFI-128 routes should be a

=E2=80=8BLabel in SAFI 1 ? =E2=80=8B

Sorry, I meant SAFI-4.=C2=A0 Actually, only SAFI-128 really matters in this context, I think.



--089e082f9bbcc7bb120561ccc4ad-- From nobody Tue Jan 2 16:17:34 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F25127137 for ; Tue, 2 Jan 2018 16:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 3W8R5T0N4SQg for ; Tue, 2 Jan 2018 16:17:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B842B124D37 for ; Tue, 2 Jan 2018 16:17:30 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w030HTQo011468 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jan 2018 18:17:29 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <90B427F3-839E-4FF9-93B1-3FA6C64F6105@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_80A233B8-4CC2-4703-A2A4-334BE8878675"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 2 Jan 2018 18:17:28 -0600 In-Reply-To: <67101beab2174cb29b814b6feea87466@XCH-ALN-001.cisco.com> Cc: The IESG , "martin.vigoureux@nokia.com" , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "aretana.ietf@gmail.com" To: "Les Ginsberg (ginsberg)" References: <151322061608.6162.117083228377789141.idtracker@ietfa.amsl.com> <67101beab2174cb29b814b6feea87466@XCH-ALN-001.cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jan 2018 00:17:32 -0000 --Apple-Mail=_80A233B8-4CC2-4703-A2A4-334BE8878675 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, thanks for the response. Comments inline: > On Dec 20, 2017, at 5:35 PM, Les Ginsberg (ginsberg) = wrote: >=20 > Ben - >=20 > Thanx for the review. > V14 has been published and it attempts to address the Security = concerns. > Look forward to your feedback. It=E2=80=99s not clear to me how the new version addresses Adam=E2=80=99s = major comment or Alissa=E2=80=99s second DISCUSS point. But it=E2=80=99s = probably best to discuss those points directly with Adam and Alissa. [=E2=80=A6] >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Substantive Comments: >>=20 >> - I support Alissa's discuss and Adam's major comment. >>=20 >> - Requirements Language: There are lower case instances of 2119 = keywords. >> Unless you mean for those to also be normative, please use the = boilerplate >> from RFC 8174. >>=20 >> -3.1.1, last paragraph: Why are the SHOULDs not MUSTs? >>=20 > [Les:] Failure to do the validation will result in the packet being = dropped when it reaches a node which does not support the algorithm = i.e., the algorithm specific label will not match any installed incoming = label. This is sub-optimal but not fatal - hence SHOULD rather than = MUST. Do you think that would ever be a reasonable implementation choice? If = so, it would help to add a sentence or two about the consequences into = the text. >=20 >> -12.2: The citations to the following references seem to be used = normatively: >> I-D.ietf-6man-segment-routing-header >> I-D.ietf-isis-segment-routing-extensions >> I-D.ietf-ospf-ospfv3-segment-routing-extensions >> I-D.ietf-ospf-segment-routing-extensions >>=20 > [Les:] I respectfully disagree. > The architecture document is NOT dependent upon the IGP/6man documents = - the dependency is the other way around. > The referenced documents are useful for readers who wish to better = understand how the architecture is supported by routing protocols/IPv6 - = but there is no dependency that the architecture definition has on the = implementation specifics. A reference is normative if reading it is necessary to understand or = implement this draft. I-D.ietf-6man-segment-routing-header is = referenced several times in the security considerations section in a way = that seems to make the security considerations incomplete unless you = read that. The other 3 seem necessary to implement IGP segment = advertising as described in section 3. [=E2=80=A6] --Apple-Mail=_80A233B8-4CC2-4703-A2A4-334BE8878675 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpMIRgACgkQgFZKbJXz 1A1INw/+NxufEapu3mQOBusg4RlylIeCiQta70NI/qAZqeL/yGbQU4pAzStzydDJ WLxXcWVJg//BvoxOVqJdMAXHbak1lIy6ivcnwA6MdzfJvN2estOSsMmMiFdDr5ig B2AR3dMahqddHm73LE3papXguND/vOa/LZ2PknAxE1zVNOn3OcMzoDeTGV6/a+iK s0mwKDcEeU/JUGevgMa8ITly9DxcnOKa2MaH5TQayWP5Heo+NRv8F0PWo5VDAsXn 8/W4q0Sp1KvmN9WqO1HRDc4TgsAXAscMucNu5/QmawQeIMnrYjdCucng2Sx+98XM K/55EditJKyTBXs2of9gtXwDNR4ame4AG0ZaCUqhsPCjbt0jSSnqrzbemEGGsWaL VhYCTZy5UDW07WnTSQfVY4NwqWFlm4rcyQ8XRQaj054XmlwJxyCo47MfXMmerCaE 3jeObLaeef5dJMg616z4E339WE4IIixbVa5csFesFq3DiHuqp6pdVCYa4o9h8ZRC c1eu/mEqoPnK2T0N5bQ+XI7TMNrcePmrIZq8GFDoPK8BP0kNgG6YMPXVkCL6+GV8 k+K+qBNBclS0tiL7WmactMRIzwyr7j1GFSnm1UKQAMicKGVrg29dFBidhLc8S0mx 7N0FHCsOhXvYiRfC8H2fgp1oadyL6aT5Po+Srp9W8IEnJRZnpzU= =pwzu -----END PGP SIGNATURE----- --Apple-Mail=_80A233B8-4CC2-4703-A2A4-334BE8878675-- From nobody Tue Jan 2 17:00:21 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8112711E; Tue, 2 Jan 2018 17:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zACCki5jfM50; Tue, 2 Jan 2018 17:00:18 -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 25D0C1200F3; Tue, 2 Jan 2018 17:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6462; q=dns/txt; s=iport; t=1514941218; x=1516150818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PjC8F7o4vVGE1y5bTJA+O5Vla5Miuwrfpky7wsY2254=; b=dJuXXWvMNYAHqTU6YqapOdDaWr65yQDuOzZGQFWX+Lx+dxc/by3Pl2T5 hGf78ftYeBQb/Bor2eEwhk3fMiqu7/FzlFRxg/9ryVktWcoSOqs927Qs1 mSLMIUHHj8Y1OWFxIfBRwp0dveWHXYvTIreCTQBbOf4lCxA9xcYmBuGc+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAwAzKkxa/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB4QAmT6CAYkIjiKCFQojhRgCGoQWQRYBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBAQMjERMtBQwEAgEIEQEDAQEBAgIjAwICAh8RFAECBggCBA4FCIoOA?= =?us-ascii?q?xUQsgmCJ4NAg38NgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgn2CEoFWgWm?= =?us-ascii?q?CIIEOgmtEAYUFgmUFik+PEokuPQKQNYR1giCGFoQQh0CNYoh0AhEZAYE7ASYCM?= =?us-ascii?q?IE3GG8VgmaCVBwZgU54AYYrLIEGgRYBAQE?= X-IronPort-AV: E=Sophos;i="5.45,499,1508803200"; d="scan'208";a="336688437" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2018 01:00:16 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w0310G0F011821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2018 01:00:16 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 2 Jan 2018 19:00:15 -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.1320.000; Tue, 2 Jan 2018 19:00:15 -0600 From: "Les Ginsberg (ginsberg)" To: Ben Campbell CC: The IESG , "martin.vigoureux@nokia.com" , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "aretana.ietf@gmail.com" Thread-Topic: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT) Thread-Index: AQHTdIgnAFQAGyHEf0iGsovuvF2mlqNM6xPAgBTg6wD//53TgA== Date: Wed, 3 Jan 2018 01:00:15 +0000 Message-ID: <3514c667f3e84cf68998350e7093ad83@XCH-ALN-001.cisco.com> References: <151322061608.6162.117083228377789141.idtracker@ietfa.amsl.com> <67101beab2174cb29b814b6feea87466@XCH-ALN-001.cisco.com> <90B427F3-839E-4FF9-93B1-3FA6C64F6105@nostrum.com> In-Reply-To: <90B427F3-839E-4FF9-93B1-3FA6C64F6105@nostrum.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.154.160.241] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jan 2018 01:00:20 -0000 QmVuIC0NCg0KSW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0NCj4gU2VudDogVHVlc2RheSwg SmFudWFyeSAwMiwgMjAxOCA0OjE3IFBNDQo+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8 Z2luc2JlcmdAY2lzY28uY29tPg0KPiBDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBtYXJ0 aW4udmlnb3VyZXV4QG5va2lhLmNvbTsgc3ByaW5nQGlldGYub3JnOw0KPiBzcHJpbmctY2hhaXJz QGlldGYub3JnOyBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmdAaWV0Zi5vcmc7DQo+ IGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20NCj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEJlbiBDYW1w YmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXNwcmluZy0NCj4gc2VnbWVudC1yb3V0 aW5nLTEzOiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGksIHRoYW5rcyBmb3IgdGhlIHJlc3BvbnNl LiBDb21tZW50cyBpbmxpbmU6DQo+IA0KPiA+IE9uIERlYyAyMCwgMjAxNywgYXQgNTozNSBQTSwg TGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCj4gPGdpbnNiZXJnQGNpc2NvLmNvbT4gd3JvdGU6DQo+ ID4NCj4gPiBCZW4gLQ0KPiA+DQo+ID4gVGhhbnggZm9yIHRoZSByZXZpZXcuDQo+ID4gVjE0IGhh cyBiZWVuIHB1Ymxpc2hlZCBhbmQgaXQgYXR0ZW1wdHMgdG8gYWRkcmVzcyB0aGUgU2VjdXJpdHkg Y29uY2VybnMuDQo+ID4gTG9vayBmb3J3YXJkIHRvIHlvdXIgZmVlZGJhY2suDQo+IA0KPiBJdOKA mXMgbm90IGNsZWFyIHRvIG1lIGhvdyB0aGUgbmV3IHZlcnNpb24gYWRkcmVzc2VzIEFkYW3igJlz IG1ham9yIGNvbW1lbnQNCj4gb3IgQWxpc3Nh4oCZcyBzZWNvbmQgRElTQ1VTUyBwb2ludC4gQnV0 IGl04oCZcyBwcm9iYWJseSBiZXN0IHRvIGRpc2N1c3MgdGhvc2UNCj4gcG9pbnRzIGRpcmVjdGx5 IHdpdGggQWRhbSBhbmQgQWxpc3NhLg0KPiANCltMZXM6XSBBZGFtIGhhcyBhbHJlYWR5IHJlc3Bv bmRlZCBwb3NpdGl2ZWx5LiBIZSBtYWRlIGEgc3VnZ2VzdGlvbiBmb3IgY2xhcmlmeWluZyB0ZXh0 IHdoaWNoIEkgYWdyZWVkIHRvIHB1dCBpbnRvIHRoZSBuZXh0IHZlcnNpb24uDQpXaWxsIHdhaXQg dG8gaGVhciBmcm9tIEFsaXNzYS4NCg0KPiBb4oCmXQ0KPiANCj4gPj4NCj4gPj4NCj4gPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4gQ09NTUVOVDoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ IC0NCj4gPj4NCj4gPj4gU3Vic3RhbnRpdmUgQ29tbWVudHM6DQo+ID4+DQo+ID4+IC0gSSBzdXBw b3J0IEFsaXNzYSdzIGRpc2N1c3MgYW5kIEFkYW0ncyBtYWpvciBjb21tZW50Lg0KPiA+Pg0KPiA+ PiAtIFJlcXVpcmVtZW50cyBMYW5ndWFnZTogVGhlcmUgYXJlIGxvd2VyIGNhc2UgaW5zdGFuY2Vz IG9mIDIxMTkNCj4ga2V5d29yZHMuDQo+ID4+IFVubGVzcyB5b3UgbWVhbiBmb3IgdGhvc2UgdG8g YWxzbyBiZSBub3JtYXRpdmUsIHBsZWFzZSB1c2UgdGhlDQo+ID4+IGJvaWxlcnBsYXRlIGZyb20g UkZDIDgxNzQuDQo+ID4+DQo+ID4+IC0zLjEuMSwgbGFzdCBwYXJhZ3JhcGg6IFdoeSBhcmUgdGhl IFNIT1VMRHMgbm90IE1VU1RzPw0KPiA+Pg0KPiA+IFtMZXM6XSBGYWlsdXJlIHRvIGRvIHRoZSB2 YWxpZGF0aW9uIHdpbGwgcmVzdWx0IGluIHRoZSBwYWNrZXQgYmVpbmcgZHJvcHBlZA0KPiB3aGVu IGl0IHJlYWNoZXMgYSBub2RlIHdoaWNoIGRvZXMgbm90IHN1cHBvcnQgdGhlIGFsZ29yaXRobSBp LmUuLCB0aGUNCj4gYWxnb3JpdGhtIHNwZWNpZmljIGxhYmVsIHdpbGwgbm90IG1hdGNoIGFueSBp bnN0YWxsZWQgaW5jb21pbmcgbGFiZWwuIFRoaXMgaXMgc3ViLQ0KPiBvcHRpbWFsIGJ1dCBub3Qg ZmF0YWwgLSBoZW5jZSBTSE9VTEQgcmF0aGVyIHRoYW4gTVVTVC4NCj4gDQo+IERvIHlvdSB0aGlu ayB0aGF0IHdvdWxkIGV2ZXIgYmUgYSByZWFzb25hYmxlIGltcGxlbWVudGF0aW9uIGNob2ljZT8g SWYgc28sDQo+IGl0IHdvdWxkIGhlbHAgdG8gYWRkIGEgc2VudGVuY2Ugb3IgdHdvIGFib3V0IHRo ZSBjb25zZXF1ZW5jZXMgaW50byB0aGUNCj4gdGV4dC4NCj4NCltMZXM6XSBJIGNhbiBhZGQgc29t ZSB0ZXh0Lg0KIA0KPiA+DQo+ID4+IC0xMi4yOiBUaGUgY2l0YXRpb25zIHRvIHRoZSBmb2xsb3dp bmcgcmVmZXJlbmNlcyBzZWVtIHRvIGJlIHVzZWQNCj4gbm9ybWF0aXZlbHk6DQo+ID4+IEktRC5p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcg0KPiA+PiBJLUQuaWV0Zi1pc2lzLXNlZ21l bnQtcm91dGluZy1leHRlbnNpb25zDQo+ID4+IEktRC5pZXRmLW9zcGYtb3NwZnYzLXNlZ21lbnQt cm91dGluZy1leHRlbnNpb25zDQo+ID4+IEktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnMNCj4gPj4NCj4gPiBbTGVzOl0gSSByZXNwZWN0ZnVsbHkgZGlzYWdyZWUuDQo+ID4g VGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBpcyBOT1QgZGVwZW5kZW50IHVwb24gdGhlIElHUC82 bWFuDQo+IGRvY3VtZW50cyAtIHRoZSBkZXBlbmRlbmN5IGlzIHRoZSBvdGhlciB3YXkgYXJvdW5k Lg0KPiA+IFRoZSByZWZlcmVuY2VkIGRvY3VtZW50cyBhcmUgdXNlZnVsIGZvciByZWFkZXJzIHdo byB3aXNoIHRvIGJldHRlcg0KPiB1bmRlcnN0YW5kIGhvdyB0aGUgYXJjaGl0ZWN0dXJlIGlzIHN1 cHBvcnRlZCBieSByb3V0aW5nIHByb3RvY29scy9JUHY2IC0gYnV0DQo+IHRoZXJlIGlzIG5vIGRl cGVuZGVuY3kgdGhhdCB0aGUgYXJjaGl0ZWN0dXJlIGRlZmluaXRpb24gaGFzIG9uIHRoZQ0KPiBp bXBsZW1lbnRhdGlvbiBzcGVjaWZpY3MuDQo+IA0KPiBBIHJlZmVyZW5jZSBpcyBub3JtYXRpdmUg aWYgcmVhZGluZyBpdCBpcyBuZWNlc3NhcnkgdG8gdW5kZXJzdGFuZCBvcg0KPiBpbXBsZW1lbnQg dGhpcyBkcmFmdC4gIEktRC5pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBpcyByZWZl cmVuY2VkDQo+IHNldmVyYWwgdGltZXMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNl Y3Rpb24gaW4gYSB3YXkgdGhhdCBzZWVtcyB0bw0KPiBtYWtlIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBpbmNvbXBsZXRlIHVubGVzcyB5b3UgcmVhZCB0aGF0LiBUaGUgb3RoZXINCj4gMyBz ZWVtIG5lY2Vzc2FyeSB0byBpbXBsZW1lbnQgSUdQIHNlZ21lbnQgYWR2ZXJ0aXNpbmcgYXMgZGVz Y3JpYmVkIGluDQo+IHNlY3Rpb24gMy4NCj4gDQpbTGVzOl0gVGhpcyBpcyBzdGlsbCBhIHBvaW50 IG9mIGRpc2FncmVlbWVudC4gDQoNClRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IC0g bm90IGFuIGltcGxlbWVudGF0aW9uIGRvY3VtZW50LiBTb2xlbHkgdXNpbmcgdGhpcyBkb2N1bWVu dCBpdCBpcyBub3QgcG9zc2libGUgdG8gaW1wbGVtZW50IGFueXRoaW5nIGJlY2F1c2UgdGhlIGRv Y3VtZW50IGRvZXMgbm90IHNwZWNpZnkgYW55IGltcGxlbWVudGF0aW9uLiBJdCBkb2VzIHByb3Zp ZGUgdGhlIGZyYW1ld29yayBmb3IgYWxsIGltcGxlbWVudGF0aW9uIHJlbGF0ZWQgU1IgZHJhZnRz Lg0KVGhlIGFyY2hpdGVjdHVyZSBkcmFmdCBzdGFuZHMgb24gaXRzIG93bi4gV2UgY291bGQgZWxp bWluYXRlIGFsbCBvZiB0aGUgU1IgZHJhZnQgcmVmZXJlbmNlcyBhbmQgdGhlIGRvY3VtZW50IHdv dWxkIHN0aWxsIGJlIGNvbXBsZXRlLiAgQnV0LCBpdCBpcyBjZXJ0YWlubHkgaGVscGZ1bCB0byBv bmUncyB1bmRlcnN0YW5kaW5nIG9mIHRoZSBhcmNoaXRlY3R1cmUgdG8gcmVhZCBhYm91dCBob3cg aXQgaXMgaW1wbGVtZW50ZWQgLSBhbmQgd2UgdGhlcmVmb3JlIGhhdmUgcHJvdmlkZWQgaW5mb3Jt YXRpb25hbCByZWZlcmVuY2VzIGZvciB0aG9zZSBkb2N1bWVudHMgd2hpY2ggY3VycmVudGx5IGV4 aXN0KHNpYykgYW5kIHNlZW0gcmVsZXZhbnQgYXMgYW4gYWlkIHRvIHRoZSByZWFkZXIuIEJ1dCB0 aGF0IGRvZXMgbm90IG1ha2UgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBkZXBlbmRlbnQgb24g dGhlc2UgcmVmZXJlbmNlcy4NCg0KVG8gZG8gd2hhdCB5b3Ugc3VnZ2VzdCB3b3VsZCBjcmVhdGUg YSB0d28gd2F5IGRlcGVuZGVuY3kgYmV0d2VlbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGFu ZCBldmVyeSBvdGhlciBzZWdtZW50IHJvdXRpbmcgc3BlY2lmaWNhdGlvbi4gQXMgcGVyIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L25vcm1hdGl2ZS1pbmZvcm1hdGl2ZS5odG1s IA0KDQoiIEFuIFJGQyBjYW5ub3QgYmUgcHVibGlzaGVkIHVudGlsIGFsbCBvZiB0aGUgZG9jdW1l bnRzIHRoYXQgaXQgbGlzdHMgYXMgbm9ybWF0aXZlIHJlZmVyZW5jZXMgaGF2ZSBiZWVuIHB1Ymxp c2hlZC4iDQoNCkdpdmVuIHRoYXQgdGhlcmUgYXJlIG1hbnkgaW1wbGVtZW50YXRpb24gcmVsYXRl ZCBTUiByZWxhdGVkIGRyYWZ0cyB3aGljaCBhcmUgaW4gdmFyaW91cyBzdGFnZXMgb2YgYmVpbmcg d3JpdHRlbiAtIGFzIHdlbGwgYXMgbWFueSBzdWNoIGRyYWZ0cyB3aGljaCBoYXZlIHlldCB0byBi ZSB3cml0dGVuLCBhdCB3aGF0IHBvaW50IGNhbiB3ZSBkZWNsYXJlIHRoZSBhcmNoaXRlY3R1cmUg ZG9jdW1lbnQgcHVibGlzaGFibGU/DQoNCiAgIExlcw0KDQo+IFvigKZdDQoNCg== From nobody Tue Jan 2 18:44:23 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757F512762F for ; Tue, 2 Jan 2018 18:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 dh1MKP6GwoAY for ; Tue, 2 Jan 2018 18:44:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 98B94127444 for ; Tue, 2 Jan 2018 18:44:19 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w032iH4x026863 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jan 2018 20:44:18 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <8B652041-29AF-4D74-BBE2-9A825F433C12@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E554A482-2E02-4B0C-BA94-74D57E4FBC2F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 2 Jan 2018 20:44:16 -0600 In-Reply-To: <3514c667f3e84cf68998350e7093ad83@XCH-ALN-001.cisco.com> Cc: The IESG , "martin.vigoureux@nokia.com" , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "aretana.ietf@gmail.com" To: "Les Ginsberg (ginsberg)" References: <151322061608.6162.117083228377789141.idtracker@ietfa.amsl.com> <67101beab2174cb29b814b6feea87466@XCH-ALN-001.cisco.com> <90B427F3-839E-4FF9-93B1-3FA6C64F6105@nostrum.com> <3514c667f3e84cf68998350e7093ad83@XCH-ALN-001.cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jan 2018 02:44:21 -0000 --Apple-Mail=_E554A482-2E02-4B0C-BA94-74D57E4FBC2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 More on the one point: > On Jan 2, 2018, at 7:00 PM, Les Ginsberg (ginsberg) = wrote: >=20 >>>=20 >>>=20 >>>> -12.2: The citations to the following references seem to be used >> normatively: >>>> I-D.ietf-6man-segment-routing-header >>>> I-D.ietf-isis-segment-routing-extensions >>>> I-D.ietf-ospf-ospfv3-segment-routing-extensions >>>> I-D.ietf-ospf-segment-routing-extensions >>>>=20 >>> [Les:] I respectfully disagree. >>> The architecture document is NOT dependent upon the IGP/6man >> documents - the dependency is the other way around. >>> The referenced documents are useful for readers who wish to better >> understand how the architecture is supported by routing = protocols/IPv6 - but >> there is no dependency that the architecture definition has on the >> implementation specifics. >>=20 >> A reference is normative if reading it is necessary to understand or >> implement this draft. I-D.ietf-6man-segment-routing-header is = referenced >> several times in the security considerations section in a way that = seems to >> make the security considerations incomplete unless you read that. The = other >> 3 seem necessary to implement IGP segment advertising as described in >> section 3. >>=20 > [Les:] This is still a point of disagreement. >=20 > This is an architecture document - not an implementation document. = Solely using this document it is not possible to implement anything = because the document does not specify any implementation. It does = provide the framework for all implementation related SR drafts. > The architecture draft stands on its own. We could eliminate all of = the SR draft references and the document would still be complete. But, = it is certainly helpful to one's understanding of the architecture to = read about how it is implemented - and we therefore have provided = informational references for those documents which currently exist(sic) = and seem relevant as an aid to the reader. But that does not make the = architecture document dependent on these references. It=E2=80=99s fairly common to have a standard track document that = describes things at a high level and normatively depends on other drafts = for details. On re-scanning the draft, I don=E2=80=99t see text to = indicate that this was not the intent. It=E2=80=99s entirely possible I = missed something. I think the issue is that the draft is not clear about it=E2=80=99s = purpose and relation to the extension drafts. As far as I can tell, = there is no text in the abstract or introduction that says that this is = an architecture draft. Some text in the abstract to say that this is an = architecture, and some text in the introduction to expand on that and to = talk about it=E2=80=99s relationship to the extension drafts would help. For example, as the text stands now I have trouble reading section 3 any = way except to say =E2=80=9CSegment routing requires advertising IGP = segments. You can do that using one of these referenced drafts=E2=80=9D. = That=E2=80=99s why I thought the references should be normative. Now, if what you mean to say is =E2=80=9CDefining segment routing = requires defining how you reference IGP segments. That work is ongoing = at the time of this writing. See the referenced drafts for the status of = that work=E2=80=9D, then the references would seem informational. > To do what you suggest would create a two way dependency between the = architecture document and every other segment routing specification. As = per https://www.ietf.org/iesg/statement/normative-informative.html > " An RFC cannot be published until all of the documents that it lists = as normative references have been published.=E2=80=9D >=20 > Given that there are many implementation related SR related drafts = which are in various stages of being written - as well as many such = drafts which have yet to be written, at what point can we declare the = architecture document publishable? As mentioned above, I would not object to calling these informational = references with some clarifying text about the purpose of this draft and = it=E2=80=99s relationship to the referenced drafts. Ben. --Apple-Mail=_E554A482-2E02-4B0C-BA94-74D57E4FBC2F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpMQ4AACgkQgFZKbJXz 1A3CPRAAyiiVzy57gktJPf4qKk6+fAf0e3Bm7nqHq6lw9vwJ32x6cBpLarXxFGcc Rq2UcwDoQ82l8BmS74NJg2hBN8nzHord8sIRnVk3T+nyKGHmaZARQfJ13YMiLZzl fBk35wreLU/60k5CDjb8W1NGVNL0YqczcMrxL/6X+NbNy6BV40QUm3V1vHXk7zdS mjaO+OZfuxrs7wrhIOoZHjv8BzqP3mPla6fwJsqg2aeb6kG/vuBcFyF1t9m0dyGu MkS+G2OJB+r4lbSxUJ6UezkLPgZdtopVKd4VG5OBMytEAIX2CLIdLl8qZ4pxCaDo DtTNjeuPQHXmQrsak+/oAmuIZkNUc6JRfyTgnbBR+sCX7bIbCH0K6ZaKSpHSPfi9 w1hnWF3PPAQeYjNWsgurrXLiEOvAhs/DnJCSY8Xr1JiNzNC3hijDjxNW/+ayt6el Tr6FvgvEylCfitPxHC1x6I5Eyc3mNqVnIW4J1S1EPB5ow590iIhA1UlaJVxC60fi athiKh798IEiLpyFghhFWCmylr935Eo9/uQXN+3fb53YQ6Ox+HjaWCea75jrneDM QcY3bCRToKoZrjikuyMlfWHGlHI4JS/uzIk1RyJ9taDbw5hsQpnys6fqpjunt3Rd qOY6z2+HRxkYMcHTIXQ+mcTNv2nufyyLgkiADRaCEZblUsCEmsI= =xy16 -----END PGP SIGNATURE----- --Apple-Mail=_E554A482-2E02-4B0C-BA94-74D57E4FBC2F-- From nobody Wed Jan 3 13:28:53 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337EC129C6C; Wed, 3 Jan 2018 13:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ4nV5L2AJ2y; Wed, 3 Jan 2018 13:28:43 -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 E10D11270AC; Wed, 3 Jan 2018 13:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28548; q=dns/txt; s=iport; t=1515014923; x=1516224523; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dbfu7XgBSOVXAZq41+XNJgLuWp3F7Td14uBQWHdemYg=; b=STOut2HrCuiyE4xIG2KAkBHzW0dXpxuKAfgi8y4XGm7xgkeYEuvMzTic 5HrK8sgKeEunOrtNOAeQ7YKQy53/f+6sJZRQvQWdCxDxXDlB/wh6sH/jx PpCid6xbCqgvu5h0RYCeDVrso7q+Fu4S0ciZC1fl1WPa61SYiIsLLptVx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAQDRSU1a/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRS9mdCcHhACKJI8GggGJCI4ighUKI4UYAhqEFj8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIwEBAQECASMKRQIFBQcEAgEIEQEDAQEoAwICAh8RFAMGCAIEDgUIi?= =?us-ascii?q?UJMAw0IELFqgieHQQ2CcAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhBOCEoFWgWm?= =?us-ascii?q?DLoJrRAGFBYJlBaMUPQKQNoR1giCKKYdBjWWIdAIRGQGBOwEfOT94GG8VGYJNg?= =?us-ascii?q?lQcGYFOeAGINYEWAQEB?= X-IronPort-AV: E=Sophos;i="5.45,504,1508803200"; d="scan'208,217";a="332690500" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2018 21:28:40 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w03LSe0k011097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2018 21:28:40 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 3 Jan 2018 15:28:40 -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.1320.000; Wed, 3 Jan 2018 15:28:40 -0600 From: "Les Ginsberg (ginsberg)" To: Ben Campbell CC: The IESG , "martin.vigoureux@nokia.com" , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "aretana.ietf@gmail.com" Thread-Topic: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT) Thread-Index: AQHTdIgnAFQAGyHEf0iGsovuvF2mlqNM6xPAgBTg6wD//53TgIAAizEAgADN3/A= Date: Wed, 3 Jan 2018 21:28:39 +0000 Message-ID: <0d4e2421e6ea49c4b745d890b923453e@XCH-ALN-001.cisco.com> References: <151322061608.6162.117083228377789141.idtracker@ietfa.amsl.com> <67101beab2174cb29b814b6feea87466@XCH-ALN-001.cisco.com> <90B427F3-839E-4FF9-93B1-3FA6C64F6105@nostrum.com> <3514c667f3e84cf68998350e7093ad83@XCH-ALN-001.cisco.com> <8B652041-29AF-4D74-BBE2-9A825F433C12@nostrum.com> In-Reply-To: <8B652041-29AF-4D74-BBE2-9A825F433C12@nostrum.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.25.13] Content-Type: multipart/alternative; boundary="_000_0d4e2421e6ea49c4b745d890b923453eXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jan 2018 21:28:46 -0000 --_000_0d4e2421e6ea49c4b745d890b923453eXCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVuIC0NCg0KDQoNCkkgd2FudCB0byBlbXBoYXNpemUgdGhhdCB3ZSBoYXZlIGEgY29tbW9uIGdv YWwgLSB3ZSBib3RoIHdhbnQgdGhlIGRvY3VtZW50IHRvIGJlIGNsZWFyIG9uIGl0cyBzY29wZSBh bmQgcmVsYXRpb25zaGlwIHRvIG90aGVyIGRvY3VtZW50cy4NCg0KDQoNCkkgdGhpbmsgdGhlIGRv Y3VtZW50IGFzIHdyaXR0ZW4gaXMgY2xlYXIgKG1vcmUgb24gdGhhdCBiZWxvdykgLSBidXQgYXMg SSBhbSBvbmUgb2YgdGhlIGF1dGhvcnMgaXQgbWF5IGJlIHRoYXQgSSBkbyBub3Qgc2VlIG9taXNz aW9ucyBhcyBjbGVhcmx5IGFzIGEgcmVhZGVyIHdobyBjb21lcyB3aXRob3V0IHRoZSB1bmRlcmx5 aW5nIGNvbnRleHQgdGhhdCBkb2N1bWVudCB3cml0ZXJzIGRldmVsb3AuIFlvdXIgZnJlc2ggcGVy c3BlY3RpdmUgaXMgYSB2YWx1YWJsZSBpbnB1dCB0aGF0IEkgZG8gbm90IHdhbnQgdG8gaWdub3Jl Lg0KDQoNCg0KVGhlIHRpdGxlIG9mIHRoZSBkb2N1bWVudCBpcyAiU2VnbWVudCBSb3V0aW5nIEFy Y2hpdGVjdHVyZSIuDQoNClRoZSBwaHJhc2UgIlNSIEFyY2hpdGVjdHVyZSIgaXMgdXNlZCBudW1l cm91cyB0aW1lcyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4NCg0KDQoNCkkgYW0gbm90IHN1cmUg aG93IHdlIGNvdWxkIGJlIG1vcmUgY2xlYXIgYWJvdXQgdGhlIGludGVudC4NCg0KQ2VydGFpbmx5 IHN0YXRpbmcgdGhhdCB0aGlzIGlzIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVudCB3b3VsZCBiZSBy ZWR1bmRhbnQgYW5kIEkgYW0gbm90IHN1cmUgd2hhdCB2YWx1ZSB0aGF0IGFkZHMuDQoNCg0KDQpZ b3UgYXJlIGNvbmNlcm5lZCB0aGF0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGlzIGRvY3Vt ZW50IGFuZCB0aGUgbnVtZXJvdXMgZG9jdW1lbnRzIHdoaWNoIGRlZmluZSBob3cgdG8gaW1wbGVt ZW50IHBvcnRpb25zIG9mIHRoZSBhcmNoaXRlY3R1cmUgaXMgbm90IGNsZWFyIC0gYnV0IHRvIG1l IHRoaXMgaXMgaW1wbGljaXQgaW4gdGhlIG5vdGlvbiBvZiAiYXJjaGl0ZWN0dXJlIiAtIHdoaWNo IGRlZmluZXMgdGhlIHN0cnVjdHVyZSBhbmQgZGVzaWduIG9mIHNvbWV0aGluZy4gSXMgaXQgbmVj ZXNzYXJ5IHRvIG1ha2UgaXQgZXhwbGljaXQgdGhhdCBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQg aXMgTk9UIGRlZmluaW5nIGltcGxlbWVudGF0aW9uIG5vciBkb2VzIGl0IG5lZWQgdG8gZG8gc28/ IEZvciBleGFtcGxlLCBkb2VzIGl0IG1ha2UgYSBkaWZmZXJlbmNlIHRvIHRoZSBhcmNoaXRlY3R1 cmUgaW4gd2hhdCBjb250YWluZXIgYSBwcm90b2NvbCBhZHZlcnRpc2VzIGEgU0lEPyBJdCBjZXJ0 YWlubHkgY291bGQgbWFrZSBhIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgYXMgdG8gdGhlIGVhc2Ug b2YgbWFpbnRhaW5pbmcgYSBkYXRhYmFzZSAoZm9yIGV4YW1wbGUpLCBidXQgcmVkZWZpbmluZyBh IHByb3RvY29sIGFkdmVydGlzZW1lbnQgbWFrZXMgbm8gZGlmZmVyZW5jZSB0byB0aGUgYXJjaGl0 ZWN0dXJlIGRlZmluaXRpb24uDQoNCg0KDQpUaGF0IHNhaWQsIGhlcmUgaXMgc29tZSBwcm9wb3Nl ZCB0ZXh0IHRoYXQgY291bGQgYmUgaW5zZXJ0ZWQgaW50byB0aGUgSW50cm9kdWN0aW9uLiBJIGFt IG5vdCBmdWxseSBjb252aW5jZWQgdGhpcyBpcyBuZWVkZWQgYW5kL29yIGlzIHRydWx5IGhlbHBm dWwsIGJ1dCBpZiBpdCBoZWxwcyB5b3UgYXMgYSByZWFkZXIgdG8gaGF2ZSBhIGNsZWFyZXIgdW5k ZXJzdGFuZGluZyB0aGVuIHRoYXQgbWF5IGJlIHN1ZmZpY2llbnQganVzdGlmaWNhdGlvbi4gTGV0 IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuIElmIGl0IHNlZW1zIGhlbHBmdWwgdG8geW91IHRoZW4g aXQgY2FuIGJlIHJldmlld2VkIGJ5IHRoZSBvdGhlciBjby1hdXRob3JzLg0KDQoNCg0KIlRoaXMg ZG9jdW1lbnQgZGVmaW5lcyB0aGUgYXJjaGl0ZWN0dXJlIGZvciBTZWdtZW50IFJvdXRpbmcsIGlu Y2x1ZGluZyBkZWZpbml0aW9ucyBvZiBiYXNpYyBvYmplY3RzIGFuZCBmdW5jdGlvbnMgYW5kIGEg ZGVzY3JpcHRpb24gb2YgdGhlIG92ZXJhbGwgZGVzaWduLg0KDQpJdCBkb2VzIE5PVCBkZWZpbmUg dGhlIG1lYW5zIG9mIGltcGxlbWVudGluZyB0aGUgYXJjaGl0ZWN0dXJlIC0gdGhhdCBpcyBjb250 YWluZWQgaW4gbnVtZXJvdXMgcmVmZXJlbmNpbmcgZG9jdW1lbnRzLCBzb21lIG9mIHdoaWNoIGFy ZSBtZW50aW9uZWQgaW4gdGhpcyBkb2N1bWVudCBhcyBhIGNvbnZlbmllbmNlIHRvIHRoZSByZWFk ZXIuIg0KDQoNCg0KICAgTGVzDQoNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KDQo+IEZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0NCg0KPiBT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDAyLCAyMDE4IDY6NDQgUE0NCg0KPiBUbzogTGVzIEdpbnNi ZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT4NCg0KPiBDYzogVGhlIElFU0cgPGll c2dAaWV0Zi5vcmc+OyBtYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbTsgc3ByaW5nQGlldGYub3Jn Ow0KDQo+IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZ0BpZXRmLm9yZzsNCg0KPiBhcmV0YW5hLmlldGZAZ21haWwuY29tDQoNCj4gU3ViamVj dDogUmU6IFtzcHJpbmddIEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm LXNwcmluZy0NCg0KPiBzZWdtZW50LXJvdXRpbmctMTM6ICh3aXRoIENPTU1FTlQpDQoNCj4NCg0K PiBNb3JlIG9uIHRoZSBvbmUgcG9pbnQ6DQoNCj4NCg0KPiA+IE9uIEphbiAyLCAyMDE4LCBhdCA3 OjAwIFBNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPG1haWx0 bzpnaW5zYmVyZ0BjaXNjby5jb20+Pg0KDQo+IHdyb3RlOg0KDQo+ID4NCg0KPiA+Pj4NCg0KPiA+ Pj4NCg0KPiA+Pj4+IC0xMi4yOiBUaGUgY2l0YXRpb25zIHRvIHRoZSBmb2xsb3dpbmcgcmVmZXJl bmNlcyBzZWVtIHRvIGJlIHVzZWQNCg0KPiA+PiBub3JtYXRpdmVseToNCg0KPiA+Pj4+IEktRC5p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcg0KDQo+ID4+Pj4gSS1ELmlldGYtaXNpcy1z ZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0KDQo+ID4+Pj4gSS1ELmlldGYtb3NwZi1vc3BmdjMt c2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMNCg0KPiA+Pj4+IEktRC5pZXRmLW9zcGYtc2VnbWVu dC1yb3V0aW5nLWV4dGVuc2lvbnMNCg0KPiA+Pj4+DQoNCj4gPj4+IFtMZXM6XSBJIHJlc3BlY3Rm dWxseSBkaXNhZ3JlZS4NCg0KPiA+Pj4gVGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBpcyBOT1Qg ZGVwZW5kZW50IHVwb24gdGhlIElHUC82bWFuDQoNCj4gPj4gZG9jdW1lbnRzIC0gdGhlIGRlcGVu ZGVuY3kgaXMgdGhlIG90aGVyIHdheSBhcm91bmQuDQoNCj4gPj4+IFRoZSByZWZlcmVuY2VkIGRv Y3VtZW50cyBhcmUgdXNlZnVsIGZvciByZWFkZXJzIHdobyB3aXNoIHRvIGJldHRlcg0KDQo+ID4+ IHVuZGVyc3RhbmQgaG93IHRoZSBhcmNoaXRlY3R1cmUgaXMgc3VwcG9ydGVkIGJ5IHJvdXRpbmcN Cg0KPiA+PiBwcm90b2NvbHMvSVB2NiAtIGJ1dCB0aGVyZSBpcyBubyBkZXBlbmRlbmN5IHRoYXQg dGhlIGFyY2hpdGVjdHVyZQ0KDQo+ID4+IGRlZmluaXRpb24gaGFzIG9uIHRoZSBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpY3MuDQoNCj4gPj4NCg0KPiA+PiBBIHJlZmVyZW5jZSBpcyBub3JtYXRpdmUg aWYgcmVhZGluZyBpdCBpcyBuZWNlc3NhcnkgdG8gdW5kZXJzdGFuZCBvcg0KDQo+ID4+IGltcGxl bWVudCB0aGlzIGRyYWZ0LiAgSS1ELmlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGlz DQoNCj4gPj4gcmVmZXJlbmNlZCBzZXZlcmFsIHRpbWVzIGluIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBzZWN0aW9uIGluIGENCg0KPiA+PiB3YXkgdGhhdCBzZWVtcyB0byBtYWtlIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbmNvbXBsZXRlIHVubGVzcw0KDQo+ID4+IHlvdSByZWFk IHRoYXQuIFRoZSBvdGhlcg0KDQo+ID4+IDMgc2VlbSBuZWNlc3NhcnkgdG8gaW1wbGVtZW50IElH UCBzZWdtZW50IGFkdmVydGlzaW5nIGFzIGRlc2NyaWJlZCBpbg0KDQo+ID4+IHNlY3Rpb24gMy4N Cg0KPiA+Pg0KDQo+ID4gW0xlczpdIFRoaXMgaXMgc3RpbGwgYSBwb2ludCBvZiBkaXNhZ3JlZW1l bnQuDQoNCj4gPg0KDQo+ID4gVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgLSBub3Qg YW4gaW1wbGVtZW50YXRpb24gZG9jdW1lbnQuIFNvbGVseQ0KDQo+IHVzaW5nIHRoaXMgZG9jdW1l bnQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGltcGxlbWVudCBhbnl0aGluZyBiZWNhdXNlIHRoZQ0K DQo+IGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgYW55IGltcGxlbWVudGF0aW9uLiBJdCBkb2Vz IHByb3ZpZGUgdGhlDQoNCj4gZnJhbWV3b3JrIGZvciBhbGwgaW1wbGVtZW50YXRpb24gcmVsYXRl ZCBTUiBkcmFmdHMuDQoNCj4gPiBUaGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IHN0YW5kcyBvbiBpdHMg b3duLiBXZSBjb3VsZCBlbGltaW5hdGUgYWxsIG9mIHRoZSBTUg0KDQo+IGRyYWZ0IHJlZmVyZW5j ZXMgYW5kIHRoZSBkb2N1bWVudCB3b3VsZCBzdGlsbCBiZSBjb21wbGV0ZS4gIEJ1dCwgaXQgaXMN Cg0KPiBjZXJ0YWlubHkgaGVscGZ1bCB0byBvbmUncyB1bmRlcnN0YW5kaW5nIG9mIHRoZSBhcmNo aXRlY3R1cmUgdG8gcmVhZCBhYm91dA0KDQo+IGhvdyBpdCBpcyBpbXBsZW1lbnRlZCAtIGFuZCB3 ZSB0aGVyZWZvcmUgaGF2ZSBwcm92aWRlZCBpbmZvcm1hdGlvbmFsDQoNCj4gcmVmZXJlbmNlcyBm b3IgdGhvc2UgZG9jdW1lbnRzIHdoaWNoIGN1cnJlbnRseSBleGlzdChzaWMpIGFuZCBzZWVtIHJl bGV2YW50DQoNCj4gYXMgYW4gYWlkIHRvIHRoZSByZWFkZXIuIEJ1dCB0aGF0IGRvZXMgbm90IG1h a2UgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudA0KDQo+IGRlcGVuZGVudCBvbiB0aGVzZSByZWZl cmVuY2VzLg0KDQo+DQoNCj4gSXTigJlzIGZhaXJseSBjb21tb24gdG8gaGF2ZSBhIHN0YW5kYXJk IHRyYWNrIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoaW5ncyBhdA0KDQo+IGEgaGlnaCBsZXZl bCBhbmQgbm9ybWF0aXZlbHkgZGVwZW5kcyBvbiBvdGhlciBkcmFmdHMgZm9yIGRldGFpbHMuIE9u IHJlLQ0KDQo+IHNjYW5uaW5nIHRoZSBkcmFmdCwgSSBkb27igJl0IHNlZSB0ZXh0IHRvIGluZGlj YXRlIHRoYXQgdGhpcyB3YXMgbm90IHRoZSBpbnRlbnQuDQoNCj4gSXTigJlzIGVudGlyZWx5IHBv c3NpYmxlIEkgbWlzc2VkIHNvbWV0aGluZy4NCg0KPg0KDQo+IEkgdGhpbmsgdGhlIGlzc3VlIGlz IHRoYXQgdGhlIGRyYWZ0IGlzIG5vdCBjbGVhciBhYm91dCBpdOKAmXMgcHVycG9zZSBhbmQgcmVs YXRpb24gdG8NCg0KPiB0aGUgZXh0ZW5zaW9uIGRyYWZ0cy4gQXMgZmFyIGFzIEkgY2FuIHRlbGws IHRoZXJlIGlzIG5vIHRleHQgaW4gdGhlIGFic3RyYWN0IG9yDQoNCj4gaW50cm9kdWN0aW9uIHRo YXQgc2F5cyB0aGF0IHRoaXMgaXMgYW4gYXJjaGl0ZWN0dXJlIGRyYWZ0LiBTb21lIHRleHQgaW4g dGhlDQoNCj4gYWJzdHJhY3QgdG8gc2F5IHRoYXQgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmUsIGFu ZCBzb21lIHRleHQgaW4gdGhlIGludHJvZHVjdGlvbg0KDQo+IHRvIGV4cGFuZCBvbiB0aGF0IGFu ZCB0byB0YWxrIGFib3V0IGl04oCZcyByZWxhdGlvbnNoaXAgdG8gdGhlIGV4dGVuc2lvbiBkcmFm dHMNCg0KPiB3b3VsZCBoZWxwLg0KDQo+DQoNCj4gRm9yIGV4YW1wbGUsIGFzIHRoZSB0ZXh0IHN0 YW5kcyBub3cgSSBoYXZlIHRyb3VibGUgcmVhZGluZyBzZWN0aW9uIDMgYW55IHdheQ0KDQo+IGV4 Y2VwdCB0byBzYXkg4oCcU2VnbWVudCByb3V0aW5nIHJlcXVpcmVzIGFkdmVydGlzaW5nIElHUCBz ZWdtZW50cy4gWW91IGNhbg0KDQo+IGRvIHRoYXQgdXNpbmcgb25lIG9mIHRoZXNlIHJlZmVyZW5j ZWQgZHJhZnRz4oCdLiBUaGF04oCZcyB3aHkgSSB0aG91Z2h0IHRoZQ0KDQo+IHJlZmVyZW5jZXMg c2hvdWxkIGJlIG5vcm1hdGl2ZS4NCg0KPg0KDQo+IE5vdywgaWYgd2hhdCB5b3UgbWVhbiB0byBz YXkgaXMg4oCcRGVmaW5pbmcgc2VnbWVudCByb3V0aW5nIHJlcXVpcmVzIGRlZmluaW5nDQoNCj4g aG93IHlvdSByZWZlcmVuY2UgSUdQIHNlZ21lbnRzLiBUaGF0IHdvcmsgaXMgb25nb2luZyBhdCB0 aGUgdGltZSBvZiB0aGlzDQoNCj4gd3JpdGluZy4gU2VlIHRoZSByZWZlcmVuY2VkIGRyYWZ0cyBm b3IgdGhlIHN0YXR1cyBvZiB0aGF0IHdvcmvigJ0sIHRoZW4gdGhlDQoNCj4gcmVmZXJlbmNlcyB3 b3VsZCBzZWVtIGluZm9ybWF0aW9uYWwuDQoNCj4NCg0KPg0KDQo+ID4gVG8gZG8gd2hhdCB5b3Ug c3VnZ2VzdCB3b3VsZCBjcmVhdGUgYSB0d28gd2F5IGRlcGVuZGVuY3kgYmV0d2VlbiB0aGUNCg0K PiA+IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBhbmQgZXZlcnkgb3RoZXIgc2VnbWVudCByb3V0aW5n IHNwZWNpZmljYXRpb24uDQoNCj4gPiBBcyBwZXIgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9z dGF0ZW1lbnQvbm9ybWF0aXZlLWluZm9ybWF0aXZlLmh0bWwNCg0KPiA+ICIgQW4gUkZDIGNhbm5v dCBiZSBwdWJsaXNoZWQgdW50aWwgYWxsIG9mIHRoZSBkb2N1bWVudHMgdGhhdCBpdCBsaXN0cyBh cw0KDQo+IG5vcm1hdGl2ZSByZWZlcmVuY2VzIGhhdmUgYmVlbiBwdWJsaXNoZWQu4oCdDQoNCj4g Pg0KDQo+ID4gR2l2ZW4gdGhhdCB0aGVyZSBhcmUgbWFueSBpbXBsZW1lbnRhdGlvbiByZWxhdGVk IFNSIHJlbGF0ZWQgZHJhZnRzIHdoaWNoDQoNCj4gYXJlIGluIHZhcmlvdXMgc3RhZ2VzIG9mIGJl aW5nIHdyaXR0ZW4gLSBhcyB3ZWxsIGFzIG1hbnkgc3VjaCBkcmFmdHMgd2hpY2gNCg0KPiBoYXZl IHlldCB0byBiZSB3cml0dGVuLCBhdCB3aGF0IHBvaW50IGNhbiB3ZSBkZWNsYXJlIHRoZSBhcmNo aXRlY3R1cmUNCg0KPiBkb2N1bWVudCBwdWJsaXNoYWJsZT8NCg0KPg0KDQo+IEFzIG1lbnRpb25l ZCBhYm92ZSwgSSB3b3VsZCBub3Qgb2JqZWN0IHRvIGNhbGxpbmcgdGhlc2UgaW5mb3JtYXRpb25h bA0KDQo+IHJlZmVyZW5jZXMgd2l0aCBzb21lIGNsYXJpZnlpbmcgdGV4dCBhYm91dCB0aGUgcHVy cG9zZSBvZiB0aGlzIGRyYWZ0IGFuZCBpdOKAmXMNCg0KPiByZWxhdGlvbnNoaXAgdG8gdGhlIHJl ZmVyZW5jZWQgZHJhZnRzLg0KDQo+DQoNCj4gQmVuLg0KDQo+DQoNCj4NCg0KPg0KDQo+DQoNCj4N Cg0KDQo= --_000_0d4e2421e6ea49c4b745d890b923453eXCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMTI5Ljc1cHQgMS4waW4gMTI5LjdwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZW4gLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIHdhbnQgdG8gZW1waGFzaXplIHRoYXQgd2UgaGF2ZSBhIGNvbW1vbiBnb2FsIC0g d2UgYm90aCB3YW50IHRoZSBkb2N1bWVudCB0byBiZSBjbGVhciBvbiBpdHMgc2NvcGUgYW5kIHJl bGF0aW9uc2hpcCB0byBvdGhlciBkb2N1bWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkkgdGhpbmsgdGhlIGRvY3VtZW50IGFzIHdyaXR0ZW4gaXMgY2xlYXIgKG1vcmUgb24gdGhh dCBiZWxvdykgLSBidXQgYXMgSSBhbSBvbmUgb2YgdGhlIGF1dGhvcnMgaXQgbWF5IGJlIHRoYXQg SSBkbyBub3Qgc2VlIG9taXNzaW9ucyBhcyBjbGVhcmx5IGFzIGEgcmVhZGVyIHdobyBjb21lcyB3 aXRob3V0IHRoZSB1bmRlcmx5aW5nIGNvbnRleHQgdGhhdCBkb2N1bWVudCB3cml0ZXJzIGRldmVs b3AuIFlvdXINCiBmcmVzaCBwZXJzcGVjdGl2ZSBpcyBhIHZhbHVhYmxlIGlucHV0IHRoYXQgSSBk byBub3Qgd2FudCB0byBpZ25vcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSB0 aXRsZSBvZiB0aGUgZG9jdW1lbnQgaXMgJnF1b3Q7U2VnbWVudCBSb3V0aW5nIEFyY2hpdGVjdHVy ZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBwaHJh c2UgJnF1b3Q7U1IgQXJjaGl0ZWN0dXJlJnF1b3Q7IGlzIHVzZWQgbnVtZXJvdXMgdGltZXMgdGhy b3VnaG91dCB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYW0g bm90IHN1cmUgaG93IHdlIGNvdWxkIGJlIG1vcmUgY2xlYXIgYWJvdXQgdGhlIGludGVudC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNlcnRhaW5seSBzdGF0aW5nIHRo YXQgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgd291bGQgYmUgcmVkdW5kYW50IGFu ZCBJIGFtIG5vdCBzdXJlIHdoYXQgdmFsdWUgdGhhdCBhZGRzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Zb3UgYXJlIGNvbmNlcm5lZCB0aGF0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2Vl biB0aGlzIGRvY3VtZW50IGFuZCB0aGUgbnVtZXJvdXMgZG9jdW1lbnRzIHdoaWNoIGRlZmluZSBo b3cgdG8gaW1wbGVtZW50IHBvcnRpb25zIG9mIHRoZSBhcmNoaXRlY3R1cmUgaXMgbm90IGNsZWFy IC0gYnV0IHRvIG1lIHRoaXMgaXMgaW1wbGljaXQgaW4gdGhlIG5vdGlvbiBvZiAmcXVvdDthcmNo aXRlY3R1cmUmcXVvdDsgLSB3aGljaCBkZWZpbmVzDQogdGhlIHN0cnVjdHVyZSBhbmQgZGVzaWdu IG9mIHNvbWV0aGluZy4gSXMgaXQgbmVjZXNzYXJ5IHRvIG1ha2UgaXQgZXhwbGljaXQgdGhhdCBh biBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMgTk9UIGRlZmluaW5nIGltcGxlbWVudGF0aW9uIG5v ciBkb2VzIGl0IG5lZWQgdG8gZG8gc28/IEZvciBleGFtcGxlLCBkb2VzIGl0IG1ha2UgYSBkaWZm ZXJlbmNlIHRvIHRoZSBhcmNoaXRlY3R1cmUgaW4gd2hhdCBjb250YWluZXIgYSBwcm90b2NvbCBh ZHZlcnRpc2VzDQogYSBTSUQ/IEl0IGNlcnRhaW5seSBjb3VsZCBtYWtlIGEgc2lnbmlmaWNhbnQg ZGlmZmVyZW5jZSBhcyB0byB0aGUgZWFzZSBvZiBtYWludGFpbmluZyBhIGRhdGFiYXNlIChmb3Ig ZXhhbXBsZSksIGJ1dCByZWRlZmluaW5nIGEgcHJvdG9jb2wgYWR2ZXJ0aXNlbWVudCBtYWtlcyBu byBkaWZmZXJlbmNlIHRvIHRoZSBhcmNoaXRlY3R1cmUgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhhdCBzYWlkLCBoZXJlIGlzIHNvbWUgcHJvcG9zZWQgdGV4dCB0 aGF0IGNvdWxkIGJlIGluc2VydGVkIGludG8gdGhlIEludHJvZHVjdGlvbi4gSSBhbSBub3QgZnVs bHkgY29udmluY2VkIHRoaXMgaXMgbmVlZGVkIGFuZC9vciBpcyB0cnVseSBoZWxwZnVsLCBidXQg aWYgaXQgaGVscHMgeW91IGFzIGEgcmVhZGVyIHRvIGhhdmUgYSBjbGVhcmVyIHVuZGVyc3RhbmRp bmcgdGhlbiB0aGF0IG1heSBiZSBzdWZmaWNpZW50DQoganVzdGlmaWNhdGlvbi4gTGV0IG1lIGtu b3cgd2hhdCB5b3UgdGhpbmsuIElmIGl0IHNlZW1zIGhlbHBmdWwgdG8geW91IHRoZW4gaXQgY2Fu IGJlIHJldmlld2VkIGJ5IHRoZSBvdGhlciBjby1hdXRob3JzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGk+JnF1b3Q7VGhpcyBkb2N1bWVu dCBkZWZpbmVzIHRoZSBhcmNoaXRlY3R1cmUgZm9yIFNlZ21lbnQgUm91dGluZywgaW5jbHVkaW5n IGRlZmluaXRpb25zIG9mIGJhc2ljIG9iamVjdHMgYW5kIGZ1bmN0aW9ucyBhbmQgYSBkZXNjcmlw dGlvbiBvZiB0aGUgb3ZlcmFsbCBkZXNpZ24uPG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpPkl0IGRvZXMgTk9UIGRl ZmluZSB0aGUgbWVhbnMgb2YgaW1wbGVtZW50aW5nIHRoZSBhcmNoaXRlY3R1cmUgLSB0aGF0IGlz IGNvbnRhaW5lZCBpbiBudW1lcm91cyByZWZlcmVuY2luZyBkb2N1bWVudHMsIHNvbWUgb2Ygd2hp Y2ggYXJlIG1lbnRpb25lZCBpbiB0aGlzIGRvY3VtZW50IGFzIGEgY29udmVuaWVuY2UgdG8gdGhl IHJlYWRlci4mcXVvdDs8bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBMZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGcm9tOiBCZW4gQ2FtcGJlbGwg W21haWx0bzpiZW5Abm9zdHJ1bS5jb21dPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDAyLCAyMDE4IDY6NDQgUE08L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSAmbHQ7Z2luc2Jl cmdAY2lzY28uY29tJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQ2M6IFRo ZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgbWFydGluLnZpZ291cmV1eEBub2tpYS5jb207 IHNwcmluZ0BpZXRmLm9yZzs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHNwcmlu Zy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZ0BpZXRm Lm9yZzs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFyZXRhbmEuaWV0ZkBnbWFp bC5jb208L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFN1YmplY3Q6IFJlOiBbc3By aW5nXSBCZW4gQ2FtcGJlbGwncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zcHJpbmctPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzZWdtZW50LXJvdXRpbmctMTM6ICh3aXRo IENPTU1FTlQpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE1vcmUgb24gdGhlIG9uZSBwb2ludDo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBPbiBKYW4gMiwgMjAxOCwgYXQgNzowMCBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykg Jmx0OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5naW5zYmVyZ0BjaXNjby5jb208L3Nw YW4+PC9hPiZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdyb3RlOjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgLTEyLjI6IFRoZSBjaXRhdGlvbnMgdG8gdGhlIGZvbGxvd2luZyByZWZlcmVuY2Vz IHNlZW0gdG8gYmUgdXNlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDsgbm9ybWF0aXZlbHk6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IEktRC5pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlcjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJLUQuaWV0Zi1pc2lzLXNl Z21lbnQtcm91dGluZy1leHRlbnNpb25zPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEktRC5pZXRmLW9zcGYtb3NwZnYzLXNlZ21lbnQtcm91dGluZy1l eHRlbnNpb25zPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IEktRC5pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnM8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBbTGVzOl0gSSByZXNwZWN0ZnVsbHkgZGlzYWdy ZWUuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZndDsgVGhlIGFy Y2hpdGVjdHVyZSBkb2N1bWVudCBpcyBOT1QgZGVwZW5kZW50IHVwb24gdGhlIElHUC82bWFuPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBkb2N1bWVudHMgLSB0aGUg ZGVwZW5kZW5jeSBpcyB0aGUgb3RoZXIgd2F5IGFyb3VuZC48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUgcmVmZXJlbmNlZCBkb2N1bWVudHMgYXJlIHVz ZWZ1bCBmb3IgcmVhZGVycyB3aG8gd2lzaCB0byBiZXR0ZXI8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHVuZGVyc3RhbmQgaG93IHRoZSBhcmNoaXRlY3R1cmUgaXMg c3VwcG9ydGVkIGJ5IHJvdXRpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IHByb3RvY29scy9JUHY2IC0gYnV0IHRoZXJlIGlzIG5vIGRlcGVuZGVuY3kgdGhhdCB0 aGUgYXJjaGl0ZWN0dXJlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyBkZWZpbml0aW9uIGhhcyBvbiB0aGUgaW1wbGVtZW50YXRpb24gc3BlY2lmaWNzLjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEEgcmVmZXJlbmNlIGlzIG5vcm1hdGl2ZSBpZiByZWFkaW5n IGl0IGlzIG5lY2Vzc2FyeSB0byB1bmRlcnN0YW5kIG9yPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBpbXBsZW1lbnQgdGhpcyBkcmFmdC4mbmJzcDsgSS1ELmlldGYt Nm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGlzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyByZWZlcmVuY2VkIHNldmVyYWwgdGltZXMgaW4gdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaW4gYTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsgd2F5IHRoYXQgc2VlbXMgdG8gbWFrZSB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgaW5jb21wbGV0ZSB1bmxlc3M8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IHlvdSByZWFkIHRoYXQuIFRoZSBvdGhlcjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsgMyBzZWVtIG5lY2Vzc2FyeSB0byBpbXBsZW1lbnQgSUdQ IHNlZ21lbnQgYWR2ZXJ0aXNpbmcgYXMgZGVzY3JpYmVkIGluPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBzZWN0aW9uIDMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyBbTGVzOl0gVGhpcyBpcyBzdGlsbCBhIHBvaW50IG9mIGRpc2FncmVlbWVudC48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgVGhpcyBpcyBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgLSBub3QgYW4gaW1w bGVtZW50YXRpb24gZG9jdW1lbnQuIFNvbGVseTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgdXNpbmcgdGhpcyBkb2N1bWVudCBpdCBpcyBub3QgcG9zc2libGUgdG8gaW1wbGVtZW50 IGFueXRoaW5nIGJlY2F1c2UgdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBk b2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IGFueSBpbXBsZW1lbnRhdGlvbi4gSXQgZG9lcyBwcm92 aWRlIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZnJhbWV3b3JrIGZvciBh bGwgaW1wbGVtZW50YXRpb24gcmVsYXRlZCBTUiBkcmFmdHMuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IFRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgc3RhbmRzIG9uIGl0cyBv d24uIFdlIGNvdWxkIGVsaW1pbmF0ZSBhbGwgb2YgdGhlIFNSPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBkcmFmdCByZWZlcmVuY2VzIGFuZCB0aGUgZG9jdW1lbnQgd291bGQgc3Rp bGwgYmUgY29tcGxldGUuJm5ic3A7IEJ1dCwgaXQgaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IGNlcnRhaW5seSBoZWxwZnVsIHRvIG9uZSdzIHVuZGVyc3RhbmRpbmcgb2YgdGhl IGFyY2hpdGVjdHVyZSB0byByZWFkIGFib3V0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBob3cgaXQgaXMgaW1wbGVtZW50ZWQgLSBhbmQgd2UgdGhlcmVmb3JlIGhhdmUgcHJvdmlk ZWQgaW5mb3JtYXRpb25hbDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVmZXJl bmNlcyBmb3IgdGhvc2UgZG9jdW1lbnRzIHdoaWNoIGN1cnJlbnRseSBleGlzdChzaWMpIGFuZCBz ZWVtIHJlbGV2YW50PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcyBhbiBhaWQg dG8gdGhlIHJlYWRlci4gQnV0IHRoYXQgZG9lcyBub3QgbWFrZSB0aGUgYXJjaGl0ZWN0dXJlIGRv Y3VtZW50PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBkZXBlbmRlbnQgb24gdGhl c2UgcmVmZXJlbmNlcy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSXTigJlzIGZhaXJseSBjb21tb24gdG8gaGF2ZSBh IHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoaW5ncyBhdDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYSBoaWdoIGxldmVsIGFuZCBub3JtYXRpdmVseSBk ZXBlbmRzIG9uIG90aGVyIGRyYWZ0cyBmb3IgZGV0YWlscy4gT24gcmUtPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBzY2FubmluZyB0aGUgZHJhZnQsIEkgZG9u4oCZdCBzZWUgdGV4 dCB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50LjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSXTigJlzIGVudGlyZWx5IHBvc3NpYmxlIEkgbWlzc2VkIHNv bWV0aGluZy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgSSB0aGluayB0aGUgaXNzdWUgaXMgdGhhdCB0aGUgZHJhZnQg aXMgbm90IGNsZWFyIGFib3V0IGl04oCZcyBwdXJwb3NlIGFuZCByZWxhdGlvbiB0bzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIGV4dGVuc2lvbiBkcmFmdHMuIEFzIGZhciBh cyBJIGNhbiB0ZWxsLCB0aGVyZSBpcyBubyB0ZXh0IGluIHRoZSBhYnN0cmFjdCBvcjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaW50cm9kdWN0aW9uIHRoYXQgc2F5cyB0aGF0IHRo aXMgaXMgYW4gYXJjaGl0ZWN0dXJlIGRyYWZ0LiBTb21lIHRleHQgaW4gdGhlPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhYnN0cmFjdCB0byBzYXkgdGhhdCB0aGlzIGlzIGFuIGFy Y2hpdGVjdHVyZSwgYW5kIHNvbWUgdGV4dCBpbiB0aGUgaW50cm9kdWN0aW9uPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0byBleHBhbmQgb24gdGhhdCBhbmQgdG8gdGFsayBhYm91 dCBpdOKAmXMgcmVsYXRpb25zaGlwIHRvIHRoZSBleHRlbnNpb24gZHJhZnRzPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3b3VsZCBoZWxwLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGb3IgZXhhbXBs ZSwgYXMgdGhlIHRleHQgc3RhbmRzIG5vdyBJIGhhdmUgdHJvdWJsZSByZWFkaW5nIHNlY3Rpb24g MyBhbnkgd2F5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBleGNlcHQgdG8gc2F5 IOKAnFNlZ21lbnQgcm91dGluZyByZXF1aXJlcyBhZHZlcnRpc2luZyBJR1Agc2VnbWVudHMuIFlv dSBjYW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRvIHRoYXQgdXNpbmcgb25l IG9mIHRoZXNlIHJlZmVyZW5jZWQgZHJhZnRz4oCdLiBUaGF04oCZcyB3aHkgSSB0aG91Z2h0IHRo ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVmZXJlbmNlcyBzaG91bGQgYmUg bm9ybWF0aXZlLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBOb3csIGlmIHdoYXQgeW91IG1lYW4gdG8gc2F5IGlzIOKA nERlZmluaW5nIHNlZ21lbnQgcm91dGluZyByZXF1aXJlcyBkZWZpbmluZzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgaG93IHlvdSByZWZlcmVuY2UgSUdQIHNlZ21lbnRzLiBUaGF0 IHdvcmsgaXMgb25nb2luZyBhdCB0aGUgdGltZSBvZiB0aGlzPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyB3cml0aW5nLiBTZWUgdGhlIHJlZmVyZW5jZWQgZHJhZnRzIGZvciB0aGUg c3RhdHVzIG9mIHRoYXQgd29ya+KAnSwgdGhlbiB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IHJlZmVyZW5jZXMgd291bGQgc2VlbSBpbmZvcm1hdGlvbmFsLjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVG8gZG8gd2hhdCB5b3Ug c3VnZ2VzdCB3b3VsZCBjcmVhdGUgYSB0d28gd2F5IGRlcGVuZGVuY3kgYmV0d2VlbiB0aGU8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYXJjaGl0ZWN0dXJlIGRvY3VtZW50 IGFuZCBldmVyeSBvdGhlciBzZWdtZW50IHJvdXRpbmcgc3BlY2lmaWNhdGlvbi48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgQXMgcGVyIDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L25vcm1hdGl2ZS1pbmZvcm1hdGl2ZS5odG1sIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9ub3JtYXRpdmUtaW5mb3JtYXRpdmUuaHRtbDwv c3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZxdW90OyBB biBSRkMgY2Fubm90IGJlIHB1Ymxpc2hlZCB1bnRpbCBhbGwgb2YgdGhlIGRvY3VtZW50cyB0aGF0 IGl0IGxpc3RzIGFzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBub3JtYXRpdmUg cmVmZXJlbmNlcyBoYXZlIGJlZW4gcHVibGlzaGVkLuKAnTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBH aXZlbiB0aGF0IHRoZXJlIGFyZSBtYW55IGltcGxlbWVudGF0aW9uIHJlbGF0ZWQgU1IgcmVsYXRl ZCBkcmFmdHMgd2hpY2g8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFyZSBpbiB2 YXJpb3VzIHN0YWdlcyBvZiBiZWluZyB3cml0dGVuIC0gYXMgd2VsbCBhcyBtYW55IHN1Y2ggZHJh ZnRzIHdoaWNoPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBoYXZlIHlldCB0byBi ZSB3cml0dGVuLCBhdCB3aGF0IHBvaW50IGNhbiB3ZSBkZWNsYXJlIHRoZSBhcmNoaXRlY3R1cmU8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRvY3VtZW50IHB1Ymxpc2hhYmxlPzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBBcyBtZW50aW9uZWQgYWJvdmUsIEkgd291bGQgbm90IG9iamVjdCB0byBjYWxs aW5nIHRoZXNlIGluZm9ybWF0aW9uYWw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IHJlZmVyZW5jZXMgd2l0aCBzb21lIGNsYXJpZnlpbmcgdGV4dCBhYm91dCB0aGUgcHVycG9zZSBv ZiB0aGlzIGRyYWZ0IGFuZCBpdOKAmXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IHJlbGF0aW9uc2hpcCB0byB0aGUgcmVmZXJlbmNlZCBkcmFmdHMuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEJlbi48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0d4e2421e6ea49c4b745d890b923453eXCHALN001ciscocom_-- From nobody Fri Jan 5 07:30:38 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B52129C56; Fri, 5 Jan 2018 07:30:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-spring-segment-routing-msdc@ietf.org, aretana.ietf@gmail.com, spring-chairs@ietf.org, bruno.decraene@orange.com, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151516623675.14690.438133553046595412.idtracker@ietfa.amsl.com> Date: Fri, 05 Jan 2018 07:30:36 -0800 Archived-At: Subject: [spring] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-spring-segment-routing-msdc-08=3A_=28with_COMMENT=29?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 15:30:37 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-spring-segment-routing-msdc-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a question regarding this part in section 3: "The absence of path visibility leaves transport protocols, such as TCP, with a "blackbox" view of the network. Some TCP metrics, such as SRTT, MSS, CWND and few others could be inferred and cached based on past history, but those apply to destinations, regardless of the path that has been chosen to get there. Thus, for instance, TCP is not capable of remembering "bad" paths, such as those that exhibited poor performance in the past. This means that every new connection will be established obliviously (memory- less) with regards to the paths chosen before, or chosen by other nodes." Is that actually a well-known problem? This is not fully clear to me. Because given that usually all paths in a data center network have roughly the same characteristics (at least regarding the cached values such as SRTT and MSS) caching of TCP parameters should not be a problem in symmetric topologies like Clos. Or do you have any specific corner cases in mind? From nobody Tue Jan 9 14:25:33 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3019512422F; Tue, 9 Jan 2018 14:25:31 -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 0d0Rzst281TT; Tue, 9 Jan 2018 14:25:29 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1AB120726; Tue, 9 Jan 2018 14:25:29 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 141so6663346wme.3; Tue, 09 Jan 2018 14:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=qsJZX2agjcR9n9w6isEwMcjjboJA+iDo7OfFURSaMmo=; b=ZaX2oYQwVjwtJGlwbxp393HCy2ZMyo9zER3CXT/nw6iVZDIQy/FkAG72FOUeggRLuK /LZlyi9yrjnxewm1HTA7gQyQsLV/5kiY687H82IMm4GU8q3cySuDU5aFeKmlMhTMSaKh hTi0RLqPkd8wnIAqaFKw4BrYW3jWehWepJc5irsIImWhxQojuDbfUO0MaHrr9OuYoW5e VShk2yatfkjLubneTpVHX/K+iSY/NZno3ZCPxeixyLV2HR2/zGgV14tqqr1tB15xw6OS 44rXba/j0jKRGD7+x3Qa/DFGTdpNfa/swcE6F2yjAJDPs45QF5+BoUHdoi/ppQ7n9O+o YX7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=qsJZX2agjcR9n9w6isEwMcjjboJA+iDo7OfFURSaMmo=; b=n711OslZjaaFahLjef/+A/HCsutAyPk77jh7R6sMkGvDXLGAAEgXJ6sEFmqSUGL0jv O6JnBIWUL4HSX/BVCexy4UWVE5vjx0IXB7ix+nChbPwGBlErdDcchSgV45OFq8yaCml3 +Ll4f1U4qPzf43RACAaHsqGAi42GVQkazwcdJEBR0c6x8yWbDOvRXOJt7cYyS3h4MK7j 7UpEsCidLIs1jAa1V+HY724hkSvp28ynMrDvKfuluFoTtzeFp+VYb/xATqnvjnB5bCdX jp/NLxc18sgUpQZOnqZuGdiowVpdTzwPvVCBlxlY2B9wtaS6m0cauFA/RSjgS8ifdeiV Ar1w== X-Gm-Message-State: AKGB3mI8YAiP1DVsh0sRQML3d+4W6S9+Jbfy6q/dgc+K7oauhLA2XDmn jWVwTdyQU2A4aLxXK3MB+ihExw== X-Google-Smtp-Source: ACJfBouDeyj+Jk9p/9AkvORrsqT+xBj8hag69oh8NBf3wpdGHzo20UiD0buXeHaRjMVQHjhlrPatbw== X-Received: by 10.80.244.12 with SMTP id r12mr22498083edm.2.1515536727270; Tue, 09 Jan 2018 14:25:27 -0800 (PST) Received: from ?IPv6:2003:74:cf2e:4f44:8974:afae:e99a:bf6a? (p20030006532DAD448974AFAEE99ABF6A.dip0.t-ipconnect.de. [2003:6:532d:ad44:8974:afae:e99a:bf6a]) by smtp.googlemail.com with ESMTPSA id e46sm9857538edb.93.2018.01.09.14.25.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 14:25:26 -0800 (PST) From: Martin Stiemerling To: spring@ietf.org, tsv-art@ietf.org Message-ID: Date: Tue, 9 Jan 2018 23:25:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jan 2018 22:25:31 -0000 Hi all, I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Summary: This draft has serious issues in Section 7.1, 7.2 and in one part of Section3, described in the review, and needs to be rethought. The other sections are good AFAIK. Technicals: The overall draft looks ok, but the three points below look strange and need a fix before publication IMHO: Both Sections, 7.1. and 7.2., are describing ideas, but not well proven funcationality and not even safe to use functionality. Both are some sort discussing that different paths in the network could be used by the end host traffic. This sounds pretty much like the Path Aware Networking Proposed Research Group (https://irtf.org/panrg) and hints to the fact that there is no commonly understand and accepted engineering solution in this space. Section 7.1: [KANDULA04] is a really old reference that hasn't been followed up in recent times and even worse there is no evidence that this is going to work good enough or stable enough under real Internet traffic. Additionally, it is more than unclear how any modern TCP implementation will react to this Section 7.2: This section describes an idea without detailing too much about any further aspects. Further it changes the commonly accepted notion of what an end host can do with the network. At best this would require a good definition of what an end host in your setting is, e.g., a highly modified piece of (at least) software that usually not found in OS availble on the market (yet?) Further communicating instantaneous path characteristics to a central point is potentially a bad idea, as the data is already outdated when reported by any node. Section 3, 3rd bullet point: It is the foundation of TCP that the network is regarded as a black box and that you infer from the transmission of packets what the current state of the network path is. Inferring network path metrics (you mention SRTT, MSS, CWND ) is a bad idea, as this would required that all paths exhibit this and if not what is going to happen? It could be an interesting research field to change many points in TCP's behavior, but this once again points to the fact that this not the IETF works but IRTF or elsewhere. Kind regards, Martin From nobody Wed Jan 10 20:01:29 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8A1242F7; Wed, 10 Jan 2018 20:01:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-spring-segment-routing-msdc@ietf.org, aretana.ietf@gmail.com, spring-chairs@ietf.org, bruno.decraene@orange.com, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151564328492.18377.10335503943075639602.idtracker@ietfa.amsl.com> Date: Wed, 10 Jan 2018 20:01:24 -0800 Archived-At: Subject: [spring] Adam Roach's No Objection on draft-ietf-spring-segment-routing-msdc-08: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 04:01:25 -0000 Adam Roach has entered the following ballot position for draft-ietf-spring-segment-routing-msdc-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I spent a long time trying to understand the following text from section 2, where the sub-bullet appears to flatly contradict its parent bullet: o Each node is its own AS (Node X has AS X). 4-byte AS numbers are recommended ([RFC6793]). * For simple and efficient route propagation filtering, Node5, Node6, Node7 and Node8 use the same AS, Node3 and Node4 use the same AS, Node9 and Node10 use the same AS. After a great deal of study of these and the following bullets, I convinced myself (perhaps incorrectly?) that the intention here is to say "We're going to talk about these nodes as if they each have their own AS, although in real deployments they'll probably be grouped together." Is that the intention? If so, it would be much easier to read if the sub-bullet made this clearer. From nobody Thu Jan 11 01:30:16 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4512EAD2; Thu, 11 Jan 2018 01:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkVx0_wrXYd6; Thu, 11 Jan 2018 01:30:08 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B1912EAC4; Thu, 11 Jan 2018 01:30:02 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id f8so1559890wre.4; Thu, 11 Jan 2018 01:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=kh8T7brrv/cjhjR3OTaVmYAvcRZYJ+BCUuJ8lf9m7ps=; b=lzdbeFPNe0CGQSHrqbDeVhv7OV3PbN+iIYIzgMBBq0SZue6/+eWy/GACahvDIgFQu2 rAv2rKJGQp0l0PYAsy/SzRc0HO7nqpxQq7p1nEUBn2bTl+75fGbl4qpyIUpj9Natgdma sh1llgUskEJtelne6QdzqAd8O+arehmoB2wYZPm7gVNwUIumbFcaKDP665oW929sZ8eN Qc9bH0pSibr3Iuyf2S+ZSQAkXDT/S1vAqE7MfpP+fdbCe++Tir8hzO9oRVRvMQLKQE02 Y/IwyPuGXpxX7LeVUeK8h1YCsavehDvBpRWmLkW++S9dbBQg69nt2uc1ZJ57PmfjFEmH wSgg== 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:from:date:message-id:subject :to:cc; bh=kh8T7brrv/cjhjR3OTaVmYAvcRZYJ+BCUuJ8lf9m7ps=; b=igaBGZttTe1RW8hDBkQzQmwP48DgNHFVNKo4Udu2OKDQWbHHfeJbHGMRVW1fwftZCx HTQgZLPUZNL2ou71kq49pZMOGKR6+0bXp7GJp1qDqYcZY0WGB+I7lrqC5i/DBW/c63mt f37NZHqaKVOUg0Q29PPaVq5up2JVQH3+WyOLDMh9Ze1qRczgMAOTXOjxnkFCuIweXmgI gFcVQpkybSsGRxFCviaXi68VFFagp4wFzKcphvNDyhDo635mIk+i/HbUY+DyrJr4M67Q OviW9LqzmhKmiA/3InIHMdesc1cIAtxwJtpFKIa0x9dqBraeo3bHNBXXvN5aULwNzOvS zmbQ== X-Gm-Message-State: AKGB3mIS5vWi8b4EuljH9cFfSyn2yjgCbT4g+U3KW48Jzt7OZO20KE1S 9J0EffnjSoD5vttGpxd86sEXOWsM+YU0vseFhycBPA== X-Google-Smtp-Source: ACJfBouGfOqpROp74qVWV2bAPOh1k9+n/jJnzJbnwG8gHj3iTZTMXxEPccQQ3ct2PCtfRTj9wyF90HY7n4f5VyTHuew= X-Received: by 10.223.162.138 with SMTP id s10mr18444858wra.239.1515663000744; Thu, 11 Jan 2018 01:30:00 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Thu, 11 Jan 2018 01:30:00 -0800 (PST) From: Robert Raszuk Date: Thu, 11 Jan 2018 10:30:00 +0100 X-Google-Sender-Auth: J8FHB4iM-Aawfk291TNE-C289v0 Message-ID: To: rift@ietf.org Cc: spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045e97f8c2381405627cca15" Archived-At: Subject: [spring] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 09:30:10 -0000 --f403045e97f8c2381405627cca15 Content-Type: text/plain; charset="UTF-8" Hi, I have one little question/doubt on scalability point of RIFT ... Assume that someone would like to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT. Wouldn't it result in amount of protocol state in full analogy to massive deaggregation - which as of today is designed to be very careful and limited operation only at moments of failure(s) ? I sort of find it a bit surprising that RIFT draft does not provide encoding for SID distribution when it is positioned as an alternative to other protocols (IGPs or BGP) which already provide ability to carry all types of SIDs. Cheers, Robert. PS1: Horizontal links which were discussed could be installed to offload from fabric transit massive amount of data (ex: storage mirroring) directly between leafs or L3 TORs and not to be treated as "backup". PS2: Restricting any protocol to specific topologies seems like pretty slippery slope to me. In any case if protocol does that it should also contain self detection mechanism of "unsupported topology" and flash red light in any NOC. --f403045e97f8c2381405627cca15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">I have one little question/doubt on scalability point of = RIFT ...=C2=A0

Assume = that someone would like to signal IPv6 prefix SID for Segment Routing in th= e underlay within RIFT.=C2=A0

Wouldn't it result in amount of protocol state in full analogy= to massive deaggregation - which as of today is designed to be very carefu= l and limited operation only at moments of failure(s) ?=C2=A0

I sort of find it a bit surprising = that RIFT draft does not provide encoding for SID distribution when it is p= ositioned as an alternative to other protocols (IGPs or BGP) which already = provide ability to carry all types of SIDs.=C2=A0
<= br>
Cheers,
Robert.

=
PS1: Horizontal links which were discussed could b= e installed to offload from fabric transit massive amount of data (ex: stor= age mirroring) directly between leafs or L3 TORs and not to be treated as &= quot;backup".=C2=A0

PS2: Restricting any protocol to specific topologies seems like pretty s= lippery slope to me. In any case if protocol does that it should also conta= in self detection mechanism of "unsupported topology" and flash r= ed light in any NOC.=C2=A0


--f403045e97f8c2381405627cca15-- From nobody Thu Jan 11 01:30:42 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE29C12EAC7; Thu, 11 Jan 2018 01:30:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-spring-segment-routing-msdc@ietf.org, aretana.ietf@gmail.com, spring-chairs@ietf.org, bruno.decraene@orange.com, spring@ietf.org, tinatsou6@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151566303970.12739.2150770765764492742.idtracker@ietfa.amsl.com> Date: Thu, 11 Jan 2018 01:30:39 -0800 Archived-At: Subject: [spring] Benoit Claise's No Objection on draft-ietf-spring-segment-routing-msdc-08: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 09:30:41 -0000 Benoit Claise has entered the following ballot position for draft-ietf-spring-segment-routing-msdc-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- OPS DIR review from Tina: I found this document well written to be READY for publication as an informational document. Some nits: 4.2 eBGP Labeled Unicast (RFC8277) Each node peers with its neighbors via a eBGP session should be Each node peers with its neighbors via an eBGP session 7. Addressing the open problems the same could be re-used in context of other domains as well A period is missing in the end. Are the centralized controller and centralized agent the same components? Even though the design in this document is specified for same domain, it would be useful to develop an approach for inter-domain without leaking intra-domain topology and policy. Have this feature been included or being aligned with carrier grade FIB in FD.io VPP https://wiki.fd.io/view/VPP ? From nobody Thu Jan 11 06:41:26 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F19812EB84; Thu, 11 Jan 2018 06:41:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-spring-segment-routing-msdc@ietf.org, aretana.ietf@gmail.com, spring-chairs@ietf.org, bruno.decraene@orange.com, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568168038.29462.6836614119659892188.idtracker@ietfa.amsl.com> Date: Thu, 11 Jan 2018 06:41:20 -0800 Archived-At: Subject: [spring] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-spring-segment-routing-msdc-08=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 14:41:20 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-spring-segment-routing-msdc-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sorry for the late input, but based on the additional TSV review provided by Martin Stiemerling (Thanks!), I got convenienced that I would like to discuss the TCP related parts of this document further before publication (even though this is "only" an informational doc). I agree with the TSV review that the solution approaches discussed in 7.1 and 7.2 are slightly speculative and should therefore probably not be published in an RFC without further discussions in respective other groups of the IETF. Per-packet/flowlet path switching (7.1) will have an impact on the TCP machinery and should be further discussed in a tsv group before it would be presented as a solution approach in an RFC. Performance-aware routing (7.2) is actually a hard problem as congestion state is changing very dynamically and an attempt to utilize this information on a different time-scale than TCP does can lead to unwanted interfere and interdependencies. We currently have a proposed research group (PANRG) for this sort of problems, and this group would probably a better place for discussing these problems and proposed solutions (instead of an RFC-to-be). The easiest way to address my concerns is probably to removed TCP-related paragraph from section 3 as well as remove section 7.1 and 7.2 entirely and follow on those discussions in tsv area/tcpm and panrg instead. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a question regarding this part in section 3: "The absence of path visibility leaves transport protocols, such as TCP, with a "blackbox" view of the network. Some TCP metrics, such as SRTT, MSS, CWND and few others could be inferred and cached based on past history, but those apply to destinations, regardless of the path that has been chosen to get there. Thus, for instance, TCP is not capable of remembering "bad" paths, such as those that exhibited poor performance in the past. This means that every new connection will be established obliviously (memory- less) with regards to the paths chosen before, or chosen by other nodes." Is that actually a well-known problem? This is not fully clear to me. Because given that usually all paths in a data center network have roughly the same characteristics (at least regarding the cached values such as SRTT and MSS) caching of TCP parameters should not be a problem in symmetric topologies like Clos. Or do you have any specific corner cases in mind? From nobody Thu Jan 11 09:40:57 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3117A12D87A; Thu, 11 Jan 2018 09:40: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 Yy0zFXMceXHE; Thu, 11 Jan 2018 09:40:47 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54EB12AF6E; Thu, 11 Jan 2018 09:40:46 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id g75so7192334wme.0; Thu, 11 Jan 2018 09:40:46 -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=28LzpsAOotuG0kTesPyhckSUU7GjJaKZZTZr25OZ7Tg=; b=Kw5diFxbvFji8IgBYw826CWHCjtbP96aYs8CbS1/JyvEmCwfmDFf9BQemp5mcS107L hr4N2V8/IKTvPT1QoudwpMDGdVWEIVaav9bwSDKpeb0mXhDPGBU6fXeFdgbfAGd+i4QD EfWutEW92RR0o9iXBqaqc0lW8MyfVP4BMinovVMXWJv6K2hiaemFz/OZAwcZFaOMAqRW +By8fDok4BfHJ90XKp3N4ymo3aaI9CU/rqi9Y+XvIvDXcFy/smNNInn+f+/LI4OiIGfx BcRNRsDGat45w0VQK1TrQLdrh19YUdmpM+Xclz/j8Q7f91Y8xyKjIrMz5elvORs9qWOZ 7Sgg== 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=28LzpsAOotuG0kTesPyhckSUU7GjJaKZZTZr25OZ7Tg=; b=fNe7RfolSDlRAAMWmZBiBg2WklZ1J7DRnqzI7rQpjlwdYIaOvKnM3lt+Qv/SBsMYuJ OlfdjlUoT/fahGK/s9D8pF/kgx2CdXiMUEHTwJG43BEuBbrZiYYiVCpR+KAOiVF5QkR+ 14IgSpQSMaiXPNGXw/esj0WyB1CYNZjmDGwRWhW6Wn4fi/EmTcaOPjlEkqeG5f6Gael2 jsOZtLurYqBSqTVaZBahMTdxAUn22dXvrXlMzT7b6DpPfQNLh2E12CrRy0yANRKLJYPI Vn5+5WNOzLgRsygly59ntTxLytRgAOPWlLbtnGOnAqKimyLizeB8xJpZPLbd+2t3clMq +JNg== X-Gm-Message-State: AKwxytet5jgPEkXfMU4oX1ivB70D5TIStn+7L8BCkwPYddQGCJLsoBny lP1cuZF6GohgkUW+Y39mMsJLttDolmILwJiFYcJ1JxLg X-Google-Smtp-Source: ACJfBovE+dv/dnxi+8dmmt3c/ip9MbCW3y43Z8k3L5C2aLetXu8D6giGDE0CiOCwP5PW8PuvFn5TXMVgvoTQ6fOcVL8= X-Received: by 10.80.153.139 with SMTP id m11mr13471418edb.145.1515692445175; Thu, 11 Jan 2018 09:40:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 09:40:04 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 09:40:04 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0ec4fac89593056283a558" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 17:40:50 -0000 --94eb2c0ec4fac89593056283a558 Content-Type: text/plain; charset="UTF-8" Robert, productive points, thanks for raising them ... I go a bit in depth 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you run RIFT). The only one that comes up regularly is egress engineering and that IMO is equivalent to SID=leaf address (which could be a HV address of course once you have RIFT all way down to server) so really, what's the point to have a SID? It's probably much smarter to use IBGP & so on overlay to do this kind of synchronization if needed since labels/SIDs become very useful in overlay to distinguish lots stuff there like VPNs/services which you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 address. Having said that, discussion always to be had if you pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but again, no _real_ use case so far. And if your only concern is to "shape towards a prefix" we have PGP in the draft which doesn't need new silicon ;-P And then ultimately, yes, if you really, really want a SID per prefix everywhere then you'll carry SIDs to everywhere since unicast SIDs are really just a glorified way to say "I have this non-aggreagable 20 bit IP host address" which architecturally is a very interesting proposition in terms of scaling (but then again, no account for taste and RFC1925 clause 3 applies) ... Your LSDB will be still much smaller, your SPF will be still simple on leaf in RIFT but your FIB will blow up and anything changing on a leaf shakes all other leafs (unless you start to run pollicies to control distribution @ which point in time you start to baby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you will observe that RIFT can do anycast without need for ECMP, i.e. true anycast in a sense and with that having anycast SID serves no real purpose in RIFT and is actually generally much harder to do since you need globally unique label blocks and so on ... 2. Horizontal links on CLOSes are not used that way normally all I saw since your blocking goes to hell unless you provision some kind of really massive parallel links between ToRs _and_ understand your load. We _could_ build RIFT that way but you give up balancing through the fabric and loop-free property in a sense (that's a longish discussion and scaling since now you have prefixes showing up all kind of crazy places instead of default). I see enough demand, we get there ... Otherwise RFC1925 clause 10 and 5. 3. PS1: Yes, lots of things "could" be done and then we "could" build a protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless provisioned correctly will pretty much just ruin your blocking/loss on the fabric is the experience (which the math supports). In a sense if you know your big flows you can build a specialized topology to do the optimal distribution (MPLS tunnels anyone ;-) but the point of fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a good analogy would be that you like to build special RAM chips for the type of data structures you are storing and we know how well that scales over time. We know now that within 3-4 years characteristics of DC flows flip upside down without a sweat when people go from server/client to microservices, from servers to containers and so on and so on. So if you can't predict your load all the time you need a _regular_ topology where _regular_ is more of a mathematical than a protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and just stick them in" applies here. So RIFT is done largely to serve a well-known structure called a "lattice" (with some restrictions) since we need an "up" and "down". Things like hypercubes, thoroidal meshes and so on and so on exist but CLOS won for a very good reason in history for that kind of problems (once you move to NUMA other things win ;-) And if you know your loads and your can heft the OPEX and you like to play with protocols generally and if you can support the scale in terms of leaf FIB sizes, flooding, slower convergence & so on & so on and you run flat IGP on some kind of stuff that you build that doesn't even have to be regular in any sense. We spent many years solving THAT problem obviously and doing something like RIFT to replace normal IGP is of limited interest IMO (albeit certain aspects having to do with modern implemenation techniques may get us there one day but it's much less of pressing problem than solving specialized DC routing well IMO again). 3. PS2: RIFT cannot build an "unsupported topology" no matter how you cable (that's the point of it) or rather we have miscabling detection and do not form adjacencies when you read the draft carefully. That's your "flash red light" and it comes included for free with my compliments ;-) ... Otherwise RFC1925 clause 10. Otherwise, if you have concrete charter points you'd like to add, be more specific in your asks and we see what the list thinks after ... thanks --- tony On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > Hi, > > I have one little question/doubt on scalability point of RIFT ... > > Assume that someone would like to signal IPv6 prefix SID for Segment > Routing in the underlay within RIFT. > > Wouldn't it result in amount of protocol state in full analogy to massive > deaggregation - which as of today is designed to be very careful and > limited operation only at moments of failure(s) ? > > I sort of find it a bit surprising that RIFT draft does not provide > encoding for SID distribution when it is positioned as an alternative to > other protocols (IGPs or BGP) which already provide ability to carry all > types of SIDs. > > Cheers, > Robert. > > PS1: Horizontal links which were discussed could be installed to offload > from fabric transit massive amount of data (ex: storage mirroring) directly > between leafs or L3 TORs and not to be treated as "backup". > > PS2: Restricting any protocol to specific topologies seems like pretty > slippery slope to me. In any case if protocol does that it should also > contain self detection mechanism of "unsupported topology" and flash red > light in any NOC. > > > > _______________________________________________ > Dcrouting mailing list > Dcrouting@ietf.org > https://www.ietf.org/mailman/listinfo/dcrouting > > --94eb2c0ec4fac89593056283a558 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Robert, productive points, thanks for raisi= ng them ... I go a bit in depth

1. I saw no _r= eal_ use-cases for SID in DC so far to be frank (once you run RIFT). The on= ly one that comes up regularly is egress engineering and that IMO is equiva= lent to SID=3Dleaf address (which could be a HV address of course once you = have RIFT all way down to server) so really, what's the point to have a= SID? It's probably much smarter to use IBGP & so on overlay to do = this kind of synchronization if needed since labels/SIDs become very useful= in overlay to distinguish lots stuff there like VPNs/services which you= 9;d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 addr= ess. Having said that, discussion always to be had if you pay me dinner ;--= ) and I know _how_ we can do SIDs in RIFT since I thought it through but ag= ain, no _real_ use case so far. And if your only concern is to "shape = towards a prefix" we have PGP in the draft which doesn't need new = silicon ;-P And then ultimately, yes, if you really, really want a SID per = prefix everywhere then you'll carry=C2=A0 SIDs to everywhere since unic= ast SIDs are really just a glorified way to say "I have this non-aggre= agable 20 bit IP host address" which architecturally is a very interes= ting proposition in terms of scaling (but then again, no account for taste = and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much smalle= r, your SPF will be still simple on leaf in RIFT but your FIB will blow up = and anything changing on a leaf shakes all other leafs (unless you start to= run pollicies to control distribution @ which point in time you start to b= aby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID w= ould be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read= RIFT draft carefully you will observe that RIFT can do anycast without nee= d for ECMP, i.e. true anycast in a sense and with that having anycast SID s= erves no real purpose in RIFT and is actually generally much harder to do s= ince you need globally unique label blocks and so on ...=C2=A0

2. Horizontal links on CLOSes are not used that way normally all I saw si= nce your blocking goes to hell unless you provision some kind of really mas= sive parallel links between ToRs _and_ understand your load. We _could_ bui= ld RIFT that way but you give up balancing through the fabric and loop-free= property in a sense (that's a longish discussion=C2=A0 and scaling sin= ce now you have prefixes showing up all kind of crazy places instead of def= ault). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 clause= 10 and 5.=C2=A0

3. PS1: Yes, lots of things &quo= t;could" be done and then we "could" build a protocol to do = that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless prov= isioned correctly will pretty much just ruin your blocking/loss on the fabr= ic is the experience (which the math supports). In a sense if you know your= big flows you can build a specialized topology to do the optimal distribut= ion (MPLS tunnels anyone ;-) but the point of fabric is that it's a fab= ric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a g= ood analogy would be that you like to build special RAM chips for the type = of data structures you are storing and we know how well that scales over ti= me. We know now that within 3-4 years characteristics of DC flows flip upsi= de down without a sweat when people go from server/client to microservices,= from servers to containers and so on and so on. So if you can't predic= t your load all the time you need a _regular_ topology where _regular_ is m= ore of a mathematical than a protocol discussion. Fabric analogy of "b= uy more RAM chips in Fry's and just stick them in" applies here. S= o RIFT is done largely to serve a well-known structure called a "latti= ce" (with some restrictions) since we need an "up" and "= ;down". Things like hypercubes, thoroidal meshes and so on and so on e= xist but CLOS won for a very good reason in history for that kind of proble= ms (once you move to NUMA other things win ;-) And if you know your loads a= nd your can heft the OPEX and you like to play with protocols generally and= if you can support the scale in terms of leaf FIB sizes, flooding, slower = convergence & so on & so on and you run flat IGP on some kind of st= uff that you build that doesn't even have to be regular in any sense. W= e spent many years solving THAT problem obviously and doing something like = RIFT to replace normal IGP is of limited interest IMO (albeit certain aspec= ts having to do with modern implemenation techniques may get us there one d= ay but it's much less of pressing problem than solving specialized DC r= outing well IMO again).

3. PS2: RIFT cannot build = an "unsupported topology" no matter how you cable (that's the= point of it) or rather we have miscabling detection and do not form adjace= ncies when you read the draft carefully. That's your "flash red li= ght" and it comes included for free with my compliments=C2=A0 ;-) ... = Otherwise RFC1925 clause 10.

Otherwise, if you have concrete = charter points you'd like to add, be more specific in your asks and we = see what the list thinks after ...

thanks

--- tony


On Thu, Jan 11, 2018 at 1:30 AM, Robe= rt Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scalabi= lity point of RIFT ...=C2=A0

Assume that someone would like to signal = IPv6 prefix SID for Segment Routing in the underlay within RIFT.=C2=A0

=
Wouldn't it result in amount of protocol state in full analogy to mass= ive deaggregation - which as of today is designed to be very careful and li= mited operation only at moments of failure(s) ?=C2=A0

I sort of find = it a bit surprising that RIFT draft does not provide encoding for SID distr= ibution when it is positioned as an alternative to other protocols (IGPs or= BGP) which already provide ability to carry all types of SIDs.=C2=A0
=

<= /div>
= Cheers,
Robert.

PS1: Horizontal links which were discussed could be= installed to offload from fabric transit massive amount of data (ex: stora= ge mirroring) directly between leafs or L3 TORs and not to be treated as &q= uot;backup".=C2=A0

PS2: Restricting any protocol to specific topo= logies seems like pretty slippery slope to me. In any case if protocol does= that it should also contain self detection mechanism of "unsupported = topology" and flash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>


--94eb2c0ec4fac89593056283a558-- From nobody Thu Jan 11 10:14:45 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25212EC15; Thu, 11 Jan 2018 10:14:24 -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 YOjNLfWGTShX; Thu, 11 Jan 2018 10:14:20 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B0D12EC19; Thu, 11 Jan 2018 10:14:20 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g75so7377242wme.0; Thu, 11 Jan 2018 10:14:20 -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=UOdvwV2owj7LKJBCFUvzKuKbXklYBo2Tzi7cUB4ECRc=; b=IqXKUsHqGuE4APKsrKWL75XfXOBM2HR0zMqlYPlkiEr6TWFHeobqKTlJjeAG3ccE34 +L8onjMjMPPBXMWMdaxTZm4VZT+Y5l+NtV6h+w7zAg5QRtyx9RWJGQ4/mNHg1ixdm6KG gg7XhbAFl7hxaoY37DYa0Ou0DoIlO8A7fSKPzH2w69SxYjG++QxtNas/BYvHtmfrECWq qQOKJQn8Zxf+RfssAYJdYm6BWpek1Ea0RHYMYbVpZ4sHr0zCG3O0yLW65Skh5H7sR5AJ 8alFYYqovEKgfe+Y3VVoeQz3ksiY99WNHoZaNlOtCt6pHQj0J96DA29X2rajM2Vp5s2i OO3A== 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=UOdvwV2owj7LKJBCFUvzKuKbXklYBo2Tzi7cUB4ECRc=; b=SfIWI/8q38NpgdJKtLcrC3K0dVC09fOOez7zoAvxri0QDKTQGtyfgwwyzMLu5ThE1d jb+ERAlzmRU6ND9//z6jBNOFIUjpMw7dNJmCzEVjKWvYqlWxXGGaKSBKXnDRxNayYXT2 WbZ/qnqL+VCxJ8ic0mMuMDkNe6hM2LZBOBdrHC3igFv8PFKMKlbI95xZmyYhIr8s76UV erxxj48EximU8nkuBDCTJU/NKSWmE5PQ4Kteq/v5XVXPNM77ELwga+DFQ7VGJfV5SWBu BhSAyd5XStXk+q1FPN8cM+m0i5rdMjDb5fHRlvp9SwFbZS85uWWaaRhn/joaG26iNaji eNJQ== X-Gm-Message-State: AKGB3mLVKL6wQHc0WI1ee5Wm5GLbgPzq6n5RmD2xCVhkh/a96rJCF8nS LPllMHMDJmMzZJKieNK6dVWiBrw3o+b94TzeT0M= X-Google-Smtp-Source: ACJfBotIWCTtPLGvxSlzSPCOI090iis+G8Mp0Q1o6YOCSclT1TkiPamjc1ZPveo8AKu14+yM/XDB+0zjSUjjrpzLsgM= X-Received: by 10.80.155.89 with SMTP id a25mr32109737edj.290.1515694459077; Thu, 11 Jan 2018 10:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 10:13:38 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 10:13:38 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1aec78d2475b0562841d15" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 18:14:24 -0000 --94eb2c1aec78d2475b0562841d15 Content-Type: text/plain; charset="UTF-8" Having said that there are interesting use cases we talk of "some binding per node" but that's more of a KV store corner where people think it's very useful to have the spines pushing stuff down to all nodes or (at cost of stability) having a node push some stuff up that gets pushed down to all other nodes. That's more of a "per leaf node" information case and pretty good unless leafs go crazy doing dynamic re-assignment (but we can dampen that in spines @ every level if needed) but it's not _per prefix_ which you seemed to ask about .... --- tony On Thu, Jan 11, 2018 at 9:40 AM, Tony Przygienda wrote: > Robert, productive points, thanks for raising them ... I go a bit in depth > > 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you > run RIFT). The only one that comes up regularly is egress engineering and > that IMO is equivalent to SID=leaf address (which could be a HV address of > course once you have RIFT all way down to server) so really, what's the > point to have a SID? It's probably much smarter to use IBGP & so on overlay > to do this kind of synchronization if needed since labels/SIDs become very > useful in overlay to distinguish lots stuff there like VPNs/services which > you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 > address. Having said that, discussion always to be had if you pay me dinner > ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but > again, no _real_ use case so far. And if your only concern is to "shape > towards a prefix" we have PGP in the draft which doesn't need new silicon > ;-P And then ultimately, yes, if you really, really want a SID per prefix > everywhere then you'll carry SIDs to everywhere since unicast SIDs are > really just a glorified way to say "I have this non-aggreagable 20 bit IP > host address" which architecturally is a very interesting proposition in > terms of scaling (but then again, no account for taste and RFC1925 clause 3 > applies) ... Your LSDB will be still much smaller, your SPF will be still > simple on leaf in RIFT but your FIB will blow up and anything changing on a > leaf shakes all other leafs (unless you start to run pollicies to control > distribution @ which point in time you start to baby-sit your fabric @ high > OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast > (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you > will observe that RIFT can do anycast without need for ECMP, i.e. true > anycast in a sense and with that having anycast SID serves no real purpose > in RIFT and is actually generally much harder to do since you need globally > unique label blocks and so on ... > > 2. Horizontal links on CLOSes are not used that way normally all I saw > since your blocking goes to hell unless you provision some kind of really > massive parallel links between ToRs _and_ understand your load. We _could_ > build RIFT that way but you give up balancing through the fabric and > loop-free property in a sense (that's a longish discussion and scaling > since now you have prefixes showing up all kind of crazy places instead of > default). I see enough demand, we get there ... Otherwise RFC1925 clause > 10 and 5. > > 3. PS1: Yes, lots of things "could" be done and then we "could" build a > protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal > links, unless provisioned correctly will pretty much just ruin your > blocking/loss on the fabric is the experience (which the math supports). In > a sense if you know your big flows you can build a specialized topology to > do the optimal distribution (MPLS tunnels anyone ;-) but the point of > fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily > scalable). Otherwise a good analogy would be that you like to build special > RAM chips for the type of data structures you are storing and we know how > well that scales over time. We know now that within 3-4 years > characteristics of DC flows flip upside down without a sweat when people go > from server/client to microservices, from servers to containers and so on > and so on. So if you can't predict your load all the time you need a > _regular_ topology where _regular_ is more of a mathematical than a > protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and > just stick them in" applies here. So RIFT is done largely to serve a > well-known structure called a "lattice" (with some restrictions) since we > need an "up" and "down". Things like hypercubes, thoroidal meshes and so on > and so on exist but CLOS won for a very good reason in history for that > kind of problems (once you move to NUMA other things win ;-) And if you > know your loads and your can heft the OPEX and you like to play with > protocols generally and if you can support the scale in terms of leaf FIB > sizes, flooding, slower convergence & so on & so on and you run flat IGP on > some kind of stuff that you build that doesn't even have to be regular in > any sense. We spent many years solving THAT problem obviously and doing > something like RIFT to replace normal IGP is of limited interest IMO > (albeit certain aspects having to do with modern implemenation techniques > may get us there one day but it's much less of pressing problem than > solving specialized DC routing well IMO again). > > 3. PS2: RIFT cannot build an "unsupported topology" no matter how you > cable (that's the point of it) or rather we have miscabling detection and > do not form adjacencies when you read the draft carefully. That's your > "flash red light" and it comes included for free with my compliments ;-) > ... Otherwise RFC1925 clause 10. > > Otherwise, if you have concrete charter points you'd like to add, be more > specific in your asks and we see what the list thinks after ... > > thanks > > --- tony > > > On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > >> Hi, >> >> I have one little question/doubt on scalability point of RIFT ... >> >> Assume that someone would like to signal IPv6 prefix SID for Segment >> Routing in the underlay within RIFT. >> >> Wouldn't it result in amount of protocol state in full analogy to massive >> deaggregation - which as of today is designed to be very careful and >> limited operation only at moments of failure(s) ? >> >> I sort of find it a bit surprising that RIFT draft does not provide >> encoding for SID distribution when it is positioned as an alternative to >> other protocols (IGPs or BGP) which already provide ability to carry all >> types of SIDs. >> >> Cheers, >> Robert. >> >> PS1: Horizontal links which were discussed could be installed to offload >> from fabric transit massive amount of data (ex: storage mirroring) directly >> between leafs or L3 TORs and not to be treated as "backup". >> >> PS2: Restricting any protocol to specific topologies seems like pretty >> slippery slope to me. In any case if protocol does that it should also >> contain self detection mechanism of "unsupported topology" and flash red >> light in any NOC. >> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --94eb2c1aec78d2475b0562841d15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having said that there are interesting use cases we t= alk of "some binding per node" but that's more of a KV store = corner where people think it's very useful to have the spines pushing s= tuff down to all nodes or (at cost of stability) having a node push some st= uff up that gets pushed down to all other nodes. That's more of a "= ;per leaf node" information case and pretty good unless leafs go crazy= doing dynamic re-assignment (but we can dampen that in spines @ every leve= l if needed) but it's not _per prefix_ which you seemed to ask about ..= ..

--- tony

On Thu, Jan 11, 2018 at 9:40 AM, Tony Przygienda <ton= ysietf@gmail.com> wrote:
Robert, productive points, thanks for raising= them ... I go a bit in depth

1. I saw no _rea= l_ use-cases for SID in DC so far to be frank (once you run RIFT). The only= one that comes up regularly is egress engineering and that IMO is equivale= nt to SID=3Dleaf address (which could be a HV address of course once you ha= ve RIFT all way down to server) so really, what's the point to have a S= ID? It's probably much smarter to use IBGP & so on overlay to do th= is kind of synchronization if needed since labels/SIDs become very useful i= n overlay to distinguish lots stuff there like VPNs/services which you'= d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 addres= s. Having said that, discussion always to be had if you pay me dinner ;--) = and I know _how_ we can do SIDs in RIFT since I thought it through but agai= n, no _real_ use case so far. And if your only concern is to "shape to= wards a prefix" we have PGP in the draft which doesn't need new si= licon ;-P And then ultimately, yes, if you really, really want a SID per pr= efix everywhere then you'll carry=C2=A0 SIDs to everywhere since unicas= t SIDs are really just a glorified way to say "I have this non-aggreag= able 20 bit IP host address" which architecturally is a very interesti= ng proposition in terms of scaling (but then again, no account for taste an= d RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much smaller,= your SPF will be still simple on leaf in RIFT but your FIB will blow up an= d anything changing on a leaf shakes all other leafs (unless you start to r= un pollicies to control distribution @ which point in time you start to bab= y-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID wou= ld be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you read R= IFT draft carefully you will observe that RIFT can do anycast without need = for ECMP, i.e. true anycast in a sense and with that having anycast SID ser= ves no real purpose in RIFT and is actually generally much harder to do sin= ce you need globally unique label blocks and so on ...=C2=A0

= 2. Horizontal links on CLOSes are not used that way normally all I saw sinc= e your blocking goes to hell unless you provision some kind of really massi= ve parallel links between ToRs _and_ understand your load. We _could_ build= RIFT that way but you give up balancing through the fabric and loop-free p= roperty in a sense (that's a longish discussion=C2=A0 and scaling since= now you have prefixes showing up all kind of crazy places instead of defau= lt). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 clause 1= 0 and 5.=C2=A0

3. PS1: Yes, lots of things "= could" be done and then we "could" build a protocol to do th= at and RFC1925 clause 7 and 8 applies. Such horizontal links, unless provis= ioned correctly will pretty much just ruin your blocking/loss on the fabric= is the experience (which the math supports). In a sense if you know your b= ig flows you can build a specialized topology to do the optimal distributio= n (MPLS tunnels anyone ;-) but the point of fabric is that it's a fabri= c (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a goo= d analogy would be that you like to build special RAM chips for the type of= data structures you are storing and we know how well that scales over time= . We know now that within 3-4 years characteristics of DC flows flip upside= down without a sweat when people go from server/client to microservices, f= rom servers to containers and so on and so on. So if you can't predict = your load all the time you need a _regular_ topology where _regular_ is mor= e of a mathematical than a protocol discussion. Fabric analogy of "buy= more RAM chips in Fry's and just stick them in" applies here. So = RIFT is done largely to serve a well-known structure called a "lattice= " (with some restrictions) since we need an "up" and "d= own". Things like hypercubes, thoroidal meshes and so on and so on exi= st but CLOS won for a very good reason in history for that kind of problems= (once you move to NUMA other things win ;-) And if you know your loads and= your can heft the OPEX and you like to play with protocols generally and i= f you can support the scale in terms of leaf FIB sizes, flooding, slower co= nvergence & so on & so on and you run flat IGP on some kind of stuf= f that you build that doesn't even have to be regular in any sense. We = spent many years solving THAT problem obviously and doing something like RI= FT to replace normal IGP is of limited interest IMO (albeit certain aspects= having to do with modern implemenation techniques may get us there one day= but it's much less of pressing problem than solving specialized DC rou= ting well IMO again).

3. PS2: RIFT cannot build an= "unsupported topology" no matter how you cable (that's the p= oint of it) or rather we have miscabling detection and do not form adjacenc= ies when you read the draft carefully. That's your "flash red ligh= t" and it comes included for free with my compliments=C2=A0 ;-) ... Ot= herwise RFC1925 clause 10.

Otherwise, if you have concrete ch= arter points you'd like to add, be more specific in your asks and we se= e what the list thinks after ...

thanks
<= div>
--- tony


On Thu, Jan 11, = 2018 at 1:30 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scalability point of RIFT = ...=C2=A0

Assume that someone would like to signal IPv6 prefix SID for= Segment Routing in the underlay within RIFT.=C2=A0

Wouldn't it re= sult in amount of protocol state in full analogy to massive deaggregation -= which as of today is designed to be very careful and limited operation onl= y at moments of failure(s) ?=C2=A0

I sort of find it a bit surprising = that RIFT draft does not provide encoding for SID distribution when it is p= ositioned as an alternative to other protocols (IGPs or BGP) which already = provide ability to carry all types of SIDs.=C2=A0

Cheers,
Robert.
<= br>
PS1: Horizontal links which were discussed could be installed to offloa= d from fabric transit massive amount of data (ex: storage mirroring) direct= ly between leafs or L3 TORs and not to be treated as "backup".=C2= =A0

PS2: Restricting any protocol to specific topologies seems like pr= etty slippery slope to me. In any case if protocol does that it should also= contain self detection mechanism of "unsupported topology" and f= lash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--94eb2c1aec78d2475b0562841d15-- From nobody Thu Jan 11 10:52:30 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2FF12D87F; Thu, 11 Jan 2018 10:52:25 -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 g_0HrS5xo0Pq; Thu, 11 Jan 2018 10:52:22 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFA11270A7; Thu, 11 Jan 2018 10:52:22 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id m84so1441305ywd.5; Thu, 11 Jan 2018 10:52:22 -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=aaFOGPzT2lSvdyxETaeqU90LsoyLx5NeG1tIrgBwjwE=; b=D9nFLFTXzerUxk4njMDXdAYUlNpuudqQF4hmr+vOYPeClVcXk4stqbeoRCJnb/ih1U 1zmHXHxYH6N4bNXw0OtvKJeCHVMpY/l7piTqcW+6tiqb9WHNfnIMMlbNL03C/62i9MfA Lz3Swb2wnnZjrJEDYgdhjiuX+z3ViD9kpg2EjkCacJBx02EsIE9OA6abhLwnUBEGfXd6 ma/QwcndOspXXa0xxvHJ4qJQxGPmvu+IWRmcFig04bYzOyvL2+51yYt4fuLJ4LDmKg8S gK7TPYqElePlZZOVt3K4BpzG4DI0po1s2LPPDhAkSJd1U4ZLDNrc3XaIUFJ7EN8+TzPv N98g== 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=aaFOGPzT2lSvdyxETaeqU90LsoyLx5NeG1tIrgBwjwE=; b=MjfCD9B/pEW6XRl/SMXqLNl99ep7iS55ud2VxGDPQRoECE0OenEomOrEFCWX9WzpP8 YoA45wMI4q2STD7kPlmN2CuLbBxNON9s/RJESNHeWzFWyiQ9bXJnSuXGvA0gDW7DWlfQ 9yXr76MuhGfJ850DYbg1ZWkC6UxMp0CiUlzEVI7D1AjQPx6EQhaIgO0A6mgaRrJrQNag Re0SGyrscXl7rdODfj0vVatS0QSM3BLywlmp0C/TPU7pQhavBniCmdeOHZ8CQfUegdEf e1PqhGsW2qBFWEbXy3S9kmGF2hzdASSo9ALzWniRJKWGj29/k4XaHMYxgR/v9q+jgvlT IJIg== X-Gm-Message-State: AKGB3mJCoW0K0ifsk/n+g2fIkJ0Bb4PrL2221p33MDJ2sumzVQHKp5fb y/ZWNzCm99uy7QIUeQ1zCyAyyX5F4bELpslVOPo= X-Google-Smtp-Source: ACJfBovIObszOqf05eWJRMXIZGCswsm1++Vjg7R+MFGzcWecuk59yW++HaNVakycEtGeBoZ5ca3/O1sAyLzIC0YlquQ= X-Received: by 10.129.118.4 with SMTP id r4mr20900499ywc.109.1515696741561; Thu, 11 Jan 2018 10:52:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.129.16 with HTTP; Thu, 11 Jan 2018 10:52:21 -0800 (PST) In-Reply-To: <151568168038.29462.6836614119659892188.idtracker@ietfa.amsl.com> References: <151568168038.29462.6836614119659892188.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Thu, 11 Jan 2018 12:52:21 -0600 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-spring-segment-routing-msdc@ietf.org, bruno.decraene@orange.com, spring@ietf.org, spring-chairs@ietf.org, "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary="f403045ef482de3b4b056284a5f1" Archived-At: Subject: Re: [spring] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-spring-segment-routing-msdc-08=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 18:52:25 -0000 --f403045ef482de3b4b056284a5f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not able to be on this week's discussion (in China, going back to bed now), but if I support Mirja's Discuss on 7.1 and 7.2. For what that's worth. Do the right thing, of course. Spencer On Thu, Jan 11, 2018 at 8:41 AM, Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-spring-segment-routing-msdc-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Sorry for the late input, but based on the additional TSV review provided > by > Martin Stiemerling (Thanks!), I got convenienced that I would like to > discuss > the TCP related parts of this document further before publication (even > though > this is "only" an informational doc). I agree with the TSV review that th= e > solution approaches discussed in 7.1 and 7.2 are slightly speculative and > should therefore probably not be published in an RFC without further > discussions in respective other groups of the IETF. > > Per-packet/flowlet path switching (7.1) will have an impact on the TCP > machinery and should be further discussed in a tsv group before it would = be > presented as a solution approach in an RFC. > > Performance-aware routing (7.2) is actually a hard problem as congestion > state > is changing very dynamically and an attempt to utilize this information o= n > a > different time-scale than TCP does can lead to unwanted interfere and > interdependencies. We currently have a proposed research group (PANRG) fo= r > this > sort of problems, and this group would probably a better place for > discussing > these problems and proposed solutions (instead of an RFC-to-be). > > The easiest way to address my concerns is probably to removed TCP-related > paragraph from section 3 as well as remove section 7.1 and 7.2 entirely a= nd > follow on those discussions in tsv area/tcpm and panrg instead. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a question regarding this part in section 3: > "The absence of path visibility leaves transport protocols, such as > TCP, with a "blackbox" view of the network. Some TCP metrics, > such as SRTT, MSS, CWND and few others could be inferred and > cached based on past history, but those apply to destinations, > regardless of the path that has been chosen to get there. Thus, > for instance, TCP is not capable of remembering "bad" paths, such > as those that exhibited poor performance in the past. This means > that every new connection will be established obliviously (memory- > less) with regards to the paths chosen before, or chosen by other > nodes." > Is that actually a well-known problem? This is not fully clear to me. > Because > given that usually all paths in a data center network have roughly the sa= me > characteristics (at least regarding the cached values such as SRTT and MS= S) > caching of TCP parameters should not be a problem in symmetric topologies > like > Clos. Or do you have any specific corner cases in mind? > > > --f403045ef482de3b4b056284a5f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not able to be on this week's discussion (in C= hina, going back to bed now), but if I support Mirja's Discuss on 7.1 a= nd 7.2.=C2=A0

For what that's worth. Do the right th= ing, of course.

Spencer

=

On Thu, Jan 11, 2= 018 at 8:41 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net>= wrote:
Mirja K=C3=BChlewind has entered = the following ballot position for
draft-ietf-spring-segment-routing-msdc-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org= /doc/draft-ietf-spring-segment-routing-msdc/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Sorry for the late input, but based on the additional TSV review provided b= y
Martin Stiemerling (Thanks!), I got convenienced that I would like to discu= ss
the TCP related parts of this document further before publication (even tho= ugh
this is "only" an informational doc). I agree with the TSV review= that the
solution approaches discussed in 7.1 and 7.2 are slightly speculative and should therefore probably not be published in an RFC without further
discussions in respective other groups of the IETF.

Per-packet/flowlet path switching (7.1) will have an impact on the TCP
machinery and should be further discussed in a tsv group before it would be=
presented as a solution approach in an RFC.

Performance-aware routing (7.2) is actually a hard problem as congestion st= ate
is changing very dynamically and an attempt to utilize this information on = a
different time-scale than TCP does can lead to unwanted interfere and
interdependencies. We currently have a proposed research group (PANRG) for = this
sort of problems, and this group would probably a better place for discussi= ng
these problems and proposed solutions (instead of an RFC-to-be).

The easiest way to address my concerns is probably to removed TCP-related paragraph from section 3 as well as remove section 7.1 and 7.2 entirely and=
follow on those discussions in tsv area/tcpm and panrg instead.


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I have a question regarding this part in section 3:
"The absence of path visibility leaves transport protocols, such as =C2=A0 =C2=A0 =C2=A0 TCP, with a "blackbox" view of the network.= =C2=A0 Some TCP metrics,
=C2=A0 =C2=A0 =C2=A0 such as SRTT, MSS, CWND and few others could be inferr= ed and
=C2=A0 =C2=A0 =C2=A0 cached based on past history, but those apply to desti= nations,
=C2=A0 =C2=A0 =C2=A0 regardless of the path that has been chosen to get the= re.=C2=A0 Thus,
=C2=A0 =C2=A0 =C2=A0 for instance, TCP is not capable of remembering "= bad" paths, such
=C2=A0 =C2=A0 =C2=A0 as those that exhibited poor performance in the past.= =C2=A0 This means
=C2=A0 =C2=A0 =C2=A0 that every new connection will be established obliviou= sly (memory-
=C2=A0 =C2=A0 =C2=A0 less) with regards to the paths chosen before, or chos= en by other
=C2=A0 =C2=A0 =C2=A0 nodes."
Is that actually a well-known problem? This is not fully clear to me. Becau= se
given that usually all paths in a data center network have roughly the same=
characteristics (at least regarding the cached values such as SRTT and MSS)=
caching of TCP parameters should not be a problem in symmetric topologies l= ike
Clos. Or do you have any specific corner cases in mind?



--f403045ef482de3b4b056284a5f1-- From nobody Thu Jan 11 10:54:27 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C181512EC34; Thu, 11 Jan 2018 10:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX0ITynZDL13; Thu, 11 Jan 2018 10:54:11 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB0212EC28; Thu, 11 Jan 2018 10:54:10 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id w50so3140129wrc.11; Thu, 11 Jan 2018 10:54:10 -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=XBsVJdwaPGx2Oe8DF2MuJoBW8K3GxaHJzU3Al3NBB+U=; b=Nt7rkPYr7f6vk4HjRj7UDA2KSVB0pEVn7NTdeuqVeKDjktCYqjWWSx1Il38FJ+jwSO UyFwFFGTnaZ/ZPUlCkPJ9KK62oo/gPKcqlJIcLMFIe3C8BJkoTXKuY486u4DsvmDeT8P pOQzAA3HUmko8J+TEBFy7lJ3yGh1Y+ZtwOaCAm9iJgvJqDKyY3UfKV/ldMYNDjH/C/PK n90Wiy3e2T7xO1udpNfRKzQtb95xc17hoL7sOHvmipsb+c8K2DBPAvzB45ogguMix50L SmYqZ0+LHcYKV6PbPmn+AWLSLXdpWp4u1O5sUFB3pyy6ffxu+r6+eJMaV07Gp7u+i4wU xKaw== 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=XBsVJdwaPGx2Oe8DF2MuJoBW8K3GxaHJzU3Al3NBB+U=; b=QzhyCYOdXWzumINHBMmuCisWDebI7BUNP0oHE7vbCtDHXbUmMCzqxxFXOZ58ueTzmL pbzva8xkVq1qfuO1O7t3u5GiPHEM4ZUTZ/iQdMoSnG37olajd8CZEQ7S5eGHyrOghwkf NckhMlrEB2fFlZXH6kVsXYTfyeii8A9IPjwIsu+sEAShA1ZY4uMemaj9HQfjhLf20VyG xPxMmYEzYQcXUe88OFTlQIn3Jj1wbJzEuE1MUyO3XzyAvBw88G3kH7XUVJLWn4f1ONpd 9X9G1ti0rsExftbIdLM9O9Givc63L2/KncL1E5FaoGVPL4uLLpw1tIoIVHNZjp+SjS+B OMhA== X-Gm-Message-State: AKGB3mIEXzjbpAchfFgyScXzCZ68e1L07Wd747tLA7+nXXxTvlNKmlBy hKu5ArOOparWWwLNCkrgn437OG5mXok6UsW6hnY= X-Google-Smtp-Source: ACJfBotWZ+6WURyNM6XicTV2WRXclCfOF6oQ4Mr+UIAmsuvJYxRfW/bOXoLrErmMb+VVDL2OOubqjQL4N/y/JiVWcYE= X-Received: by 10.223.162.138 with SMTP id s10mr19970405wra.239.1515696848935; Thu, 11 Jan 2018 10:54:08 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Thu, 11 Jan 2018 10:54:07 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Thu, 11 Jan 2018 19:54:07 +0100 X-Google-Sender-Auth: 6e6RpwM60kiISNZLH8BBjo12tnQ Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045e97f844a0bc056284ac2a" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 18:54:14 -0000 --f403045e97f844a0bc056284ac2a Content-Type: text/plain; charset="UTF-8" Hi Tony, Thx for elaborating ... Two small comments: A) SID/SR use case in underlay could be as simple as gracefully taking a fabric node out of service. Not much OPEX needed if your NMS is decent. Otherwise in normal link state I can do overload bit, in BGP number of solutions from shutdown to MED to LP ... depending what is your BGP design. In RIFT how do you do that ? Note that overlay (if such exist) does not help here. B) For horizontal links imagine you have servers with 40 GB ports to TOR. Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I do know that servers behind those TORs need to talk to each other in a non blocking fashion _and_ I have spare 100 GB ports on TORs having routing protocol which does not allow me to do that seems pretty limited - wouldn't you agree ? Thx, R. On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda wrote: > Robert, productive points, thanks for raising them ... I go a bit in depth > > 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you > run RIFT). The only one that comes up regularly is egress engineering and > that IMO is equivalent to SID=leaf address (which could be a HV address of > course once you have RIFT all way down to server) so really, what's the > point to have a SID? It's probably much smarter to use IBGP & so on overlay > to do this kind of synchronization if needed since labels/SIDs become very > useful in overlay to distinguish lots stuff there like VPNs/services which > you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 > address. Having said that, discussion always to be had if you pay me dinner > ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but > again, no _real_ use case so far. And if your only concern is to "shape > towards a prefix" we have PGP in the draft which doesn't need new silicon > ;-P And then ultimately, yes, if you really, really want a SID per prefix > everywhere then you'll carry SIDs to everywhere since unicast SIDs are > really just a glorified way to say "I have this non-aggreagable 20 bit IP > host address" which architecturally is a very interesting proposition in > terms of scaling (but then again, no account for taste and RFC1925 clause 3 > applies) ... Your LSDB will be still much smaller, your SPF will be still > simple on leaf in RIFT but your FIB will blow up and anything changing on a > leaf shakes all other leafs (unless you start to run pollicies to control > distribution @ which point in time you start to baby-sit your fabric @ high > OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast > (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you > will observe that RIFT can do anycast without need for ECMP, i.e. true > anycast in a sense and with that having anycast SID serves no real purpose > in RIFT and is actually generally much harder to do since you need globally > unique label blocks and so on ... > > 2. Horizontal links on CLOSes are not used that way normally all I saw > since your blocking goes to hell unless you provision some kind of really > massive parallel links between ToRs _and_ understand your load. We _could_ > build RIFT that way but you give up balancing through the fabric and > loop-free property in a sense (that's a longish discussion and scaling > since now you have prefixes showing up all kind of crazy places instead of > default). I see enough demand, we get there ... Otherwise RFC1925 clause > 10 and 5. > > 3. PS1: Yes, lots of things "could" be done and then we "could" build a > protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal > links, unless provisioned correctly will pretty much just ruin your > blocking/loss on the fabric is the experience (which the math supports). In > a sense if you know your big flows you can build a specialized topology to > do the optimal distribution (MPLS tunnels anyone ;-) but the point of > fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily > scalable). Otherwise a good analogy would be that you like to build special > RAM chips for the type of data structures you are storing and we know how > well that scales over time. We know now that within 3-4 years > characteristics of DC flows flip upside down without a sweat when people go > from server/client to microservices, from servers to containers and so on > and so on. So if you can't predict your load all the time you need a > _regular_ topology where _regular_ is more of a mathematical than a > protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and > just stick them in" applies here. So RIFT is done largely to serve a > well-known structure called a "lattice" (with some restrictions) since we > need an "up" and "down". Things like hypercubes, thoroidal meshes and so on > and so on exist but CLOS won for a very good reason in history for that > kind of problems (once you move to NUMA other things win ;-) And if you > know your loads and your can heft the OPEX and you like to play with > protocols generally and if you can support the scale in terms of leaf FIB > sizes, flooding, slower convergence & so on & so on and you run flat IGP on > some kind of stuff that you build that doesn't even have to be regular in > any sense. We spent many years solving THAT problem obviously and doing > something like RIFT to replace normal IGP is of limited interest IMO > (albeit certain aspects having to do with modern implemenation techniques > may get us there one day but it's much less of pressing problem than > solving specialized DC routing well IMO again). > > 3. PS2: RIFT cannot build an "unsupported topology" no matter how you > cable (that's the point of it) or rather we have miscabling detection and > do not form adjacencies when you read the draft carefully. That's your > "flash red light" and it comes included for free with my compliments ;-) > ... Otherwise RFC1925 clause 10. > > Otherwise, if you have concrete charter points you'd like to add, be more > specific in your asks and we see what the list thinks after ... > > thanks > > --- tony > > > On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: > >> Hi, >> >> I have one little question/doubt on scalability point of RIFT ... >> >> Assume that someone would like to signal IPv6 prefix SID for Segment >> Routing in the underlay within RIFT. >> >> Wouldn't it result in amount of protocol state in full analogy to massive >> deaggregation - which as of today is designed to be very careful and >> limited operation only at moments of failure(s) ? >> >> I sort of find it a bit surprising that RIFT draft does not provide >> encoding for SID distribution when it is positioned as an alternative to >> other protocols (IGPs or BGP) which already provide ability to carry all >> types of SIDs. >> >> Cheers, >> Robert. >> >> PS1: Horizontal links which were discussed could be installed to offload >> from fabric transit massive amount of data (ex: storage mirroring) directly >> between leafs or L3 TORs and not to be treated as "backup". >> >> PS2: Restricting any protocol to specific topologies seems like pretty >> slippery slope to me. In any case if protocol does that it should also >> contain self detection mechanism of "unsupported topology" and flash red >> light in any NOC. >> >> >> >> _______________________________________________ >> Dcrouting mailing list >> Dcrouting@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrouting >> >> > --f403045e97f844a0bc056284ac2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

Thx for elaborating ...

=
Two small comments:

A) SID/SR use case in underlay could be as simple as gracefully taking a = fabric node out of service. Not much OPEX needed if your NMS is decent. Oth= erwise in normal link state I can do overload bit, in BGP number of solutio= ns from shutdown to MED to LP ... depending what is your BGP design. In RIF= T how do you do that ? Note that overlay (if such exist) does not help here= .=C2=A0

B) For horizon= tal links imagine you have servers with 40 GB ports to TOR. Then you have N= x100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabr= ic) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I= do know that servers behind those TORs need to talk to each other in a non= blocking fashion _and_ I have spare 100 GB ports on TORs having routing pr= otocol which does not allow me to do that seems pretty limited - wouldn'= ;t you agree ?=C2=A0

T= hx,
R.







On Thu, Jan 11, 2018 at 6:= 40 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
Robert, product= ive points, thanks for raising them ... I go a bit in depth
<= br>
1. I saw no _real_ use-cases for SID in DC so far to be frank= (once you run RIFT). The only one that comes up regularly is egress engine= ering and that IMO is equivalent to SID=3Dleaf address (which could be a HV= address of course once you have RIFT all way down to server) so really, wh= at's the point to have a SID? It's probably much smarter to use IBG= P & so on overlay to do this kind of synchronization if needed since la= bels/SIDs become very useful in overlay to distinguish lots stuff there lik= e VPNs/services which you'd carry e.g. in MPLSoUDP. In underlay just us= e the destination v4/v6 address. Having said that, discussion always to be = had if you pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since= I thought it through but again, no _real_ use case so far. And if your onl= y concern is to "shape towards a prefix" we have PGP in the draft= which doesn't need new silicon ;-P And then ultimately, yes, if you re= ally, really want a SID per prefix everywhere then you'll carry=C2=A0 S= IDs to everywhere since unicast SIDs are really just a glorified way to say= "I have this non-aggreagable 20 bit IP host address" which archi= tecturally is a very interesting proposition in terms of scaling (but then = again, no account for taste and RFC1925 clause 3 applies) ...=C2=A0 Your LS= DB will be still much smaller, your SPF will be still simple on leaf in RIF= T but your FIB will blow up and anything changing on a leaf shakes all othe= r leafs (unless you start to run pollicies to control distribution @ which = point in time you start to baby-sit your fabric @ high OPEX). One of the re= asons to do per-prefix SID would be non-ECMP anycast (where SIDs _are_ in f= act usefull) but if you read RIFT draft carefully you will observe that RIF= T can do anycast without need for ECMP, i.e. true anycast in a sense and wi= th that having anycast SID serves no real purpose in RIFT and is actually g= enerally much harder to do since you need globally unique label blocks and = so on ...=C2=A0

2. Horizontal links on CLOSes are not used th= at way normally all I saw since your blocking goes to hell unless you provi= sion some kind of really massive parallel links between ToRs _and_ understa= nd your load. We _could_ build RIFT that way but you give up balancing thro= ugh the fabric and loop-free property in a sense (that's a longish disc= ussion=C2=A0 and scaling since now you have prefixes showing up all kind of= crazy places instead of default). I see enough demand, we get there ...=C2= =A0 Otherwise RFC1925 clause 10 and 5.=C2=A0

3. P= S1: Yes, lots of things "could" be done and then we "could&q= uot; build a protocol to do that and RFC1925 clause 7 and 8 applies. Such h= orizontal links, unless provisioned correctly will pretty much just ruin yo= ur blocking/loss on the fabric is the experience (which the math supports).= In a sense if you know your big flows you can build a specialized topology= to do the optimal distribution (MPLS tunnels anyone ;-) but the point of f= abric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and eas= ily scalable). Otherwise a good analogy would be that you like to build spe= cial RAM chips for the type of data structures you are storing and we know = how well that scales over time. We know now that within 3-4 years character= istics of DC flows flip upside down without a sweat when people go from ser= ver/client to microservices, from servers to containers and so on and so on= . So if you can't predict your load all the time you need a _regular_ t= opology where _regular_ is more of a mathematical than a protocol discussio= n. Fabric analogy of "buy more RAM chips in Fry's and just stick t= hem in" applies here. So RIFT is done largely to serve a well-known st= ructure called a "lattice" (with some restrictions) since we need= an "up" and "down". Things like hypercubes, thoroidal = meshes and so on and so on exist but CLOS won for a very good reason in his= tory for that kind of problems (once you move to NUMA other things win ;-) = And if you know your loads and your can heft the OPEX and you like to play = with protocols generally and if you can support the scale in terms of leaf = FIB sizes, flooding, slower convergence & so on & so on and you run= flat IGP on some kind of stuff that you build that doesn't even have t= o be regular in any sense. We spent many years solving THAT problem obvious= ly and doing something like RIFT to replace normal IGP is of limited intere= st IMO (albeit certain aspects having to do with modern implemenation techn= iques may get us there one day but it's much less of pressing problem t= han solving specialized DC routing well IMO again).

3. PS2: RIFT cannot build an "unsupported topology" no matter h= ow you cable (that's the point of it) or rather we have miscabling dete= ction and do not form adjacencies when you read the draft carefully. That&#= 39;s your "flash red light" and it comes included for free with m= y compliments=C2=A0 ;-) ... Otherwise RFC1925 clause 10.

Othe= rwise, if you have concrete charter points you'd like to add, be more s= pecific in your asks and we see what the list thinks after ...
thanks

--- tony

On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk <robert@raszu= k.net> wrote:
<= div>
Hi,

I have one little question/doubt= on scalability point of RIFT ...=C2=A0

Assume that someone would like= to signal IPv6 prefix SID for Segment Routing in the underlay within RIFT.= =C2=A0

Wouldn't it result in amount of protocol state in full anal= ogy to massive deaggregation - which as of today is designed to be very car= eful and limited operation only at moments of failure(s) ?=C2=A0

=
I sor= t of find it a bit surprising that RIFT draft does not provide encoding for= SID distribution when it is positioned as an alternative to other protocol= s (IGPs or BGP) which already provide ability to carry all types of SIDs.= =C2=A0

Cheers,
Robert.

PS1: Horizontal links which were discus= sed could be installed to offload from fabric transit massive amount of dat= a (ex: storage mirroring) directly between leafs or L3 TORs and not to be t= reated as "backup".=C2=A0

PS2: Restricting any protocol to s= pecific topologies seems like pretty slippery slope to me. In any case if p= rotocol does that it should also contain self detection mechanism of "= unsupported topology" and flash red light in any NOC.=C2=A0

=

<= /div>

_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>



--f403045e97f844a0bc056284ac2a-- From nobody Thu Jan 11 13:20:25 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640F512DA47; Thu, 11 Jan 2018 13:20:06 -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 aDSWk7t2ahDJ; Thu, 11 Jan 2018 13:20:03 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 B2A6512EBEC; Thu, 11 Jan 2018 13:20:02 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id g75so8292981wme.0; Thu, 11 Jan 2018 13:20:02 -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=DQBG+dtO/SbWFKgey3PkCMYKx5eGzyyZTMSJYOrWMfM=; b=D1rlsc1hihilQE9BbfXvbsmZYe1oP+4sMkp2sn2plO6TUZnWDFZf7wt35GCbHUljyH CS+un3v+TcpgJep+Qsa0/uhzBuGQ5udaDvkQU/uN+oqPznJaaHZRMCW7rcmyPStnbQOF bAytvpDxImGs57nwBCl3Gnw6wHcpsNmg2aJTF9h7j+k6vAqE+/B6PH7OtCyNDqVx/JEn aCTZL659uRlgw3PxJLRVHP2YG2SwTiUYN/c9sc8tnYeaLcvrrs2JVAektj5kzGJ/YZTf 86BOx5XYQkNutvAAmYOGRo08/vmq8hs1LmCS1mDyGLzELzaikNkKRwCil2906iff4Ys1 +h0Q== 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=DQBG+dtO/SbWFKgey3PkCMYKx5eGzyyZTMSJYOrWMfM=; b=nSb4RhHLesRidW85iCwfuNipkTJXM17HlHhCVoaCfkfKZ637xQ19jODk6SiuchVY33 6K/vaxvvmJLYI2Z8Qg6y5sRbvXJXqWg6YlfzT87a18o7dsNe8O1PDFv0p+NshWEy1Hfn UpKYOJXPlgRIcTXysfMn8Ee5DauuRHXUqx3t0Jd6xStbhAhTLH1tiKcToqk3dsupIY/r lUDJ9bWD7fUYwaK96zaJkSkcVHnpvQ4spqjFbMSPAKkdqCD1hLck0lpQjqczdlUcU7MM YLLQJ8ZPKEx+DDoHuzfjlAQwE2DBYyJnJfqdIO56na2kQrxQBO2CQtqvOQspJmZSuvjb lTOg== X-Gm-Message-State: AKGB3mLulbLZbBjDNq3xM3v7NKCLfbeboAauFL+OeD/XmClY+GqVKRJ0 RPdgBrvoueqlbjLE+j+bRu8uu7vP8rp+gT8IDnA= X-Google-Smtp-Source: ACJfBotzQdfSmgV6vxmSUH/XtR6ztc3QHiUuWfBZm0vAAPsLuvIaa8g+PrELdcO7WMpaMJmK2kUQefyTTPGhDuCkLvY= X-Received: by 10.80.205.203 with SMTP id h11mr32269245edj.159.1515705601209; Thu, 11 Jan 2018 13:20:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.164.199 with HTTP; Thu, 11 Jan 2018 13:19:20 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Thu, 11 Jan 2018 13:19:20 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045dc2e0f1b7d0056286b55a" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 21:20:06 -0000 --f403045dc2e0f1b7d0056286b55a Content-Type: text/plain; charset="UTF-8" A. Reading the draft you'll find the overload bit on RIFT which IMO is the best out-of-production solution. B. Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIFT will do that just fine using LEAF2LEAF procedures in fact. If we start to run RIFT @ the server level then we'd need discuss but people do not do horizontal links in non-leaf-to-non-leaf as far I saw (except protection here and there) but then again, they mostly don't extend the fabric routing protocol into the server (which RIFT intends to do). So, for today you're good. Once you want RIFT on server I think having spine horizontals is not a good idea in general I hope that computes and I'd encourage you to read the draft again, maybe without the "it should work just like BGP or just like today's IGP" hat on ... ;-) Of course, paying me fancy dinners and asking questions, letting me ramble then is a valid substitute ;-) --- tony On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote: > Hi Tony, > > Thx for elaborating ... > > Two small comments: > > A) SID/SR use case in underlay could be as simple as gracefully taking a > fabric node out of service. Not much OPEX needed if your NMS is decent. > Otherwise in normal link state I can do overload bit, in BGP number of > solutions from shutdown to MED to LP ... depending what is your BGP design. > In RIFT how do you do that ? Note that overlay (if such exist) does not > help here. > > B) For horizontal links imagine you have servers with 40 GB ports to TOR. > Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR > (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to > interconnect TORs because I do know that servers behind those TORs need to > talk to each other in a non blocking fashion _and_ I have spare 100 GB > ports on TORs having routing protocol which does not allow me to do that > seems pretty limited - wouldn't you agree ? > > Thx, > R. > > > > > > > > On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda > wrote: > >> Robert, productive points, thanks for raising them ... I go a bit in depth >> >> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >> run RIFT). The only one that comes up regularly is egress engineering and >> that IMO is equivalent to SID=leaf address (which could be a HV address of >> course once you have RIFT all way down to server) so really, what's the >> point to have a SID? It's probably much smarter to use IBGP & so on overlay >> to do this kind of synchronization if needed since labels/SIDs become very >> useful in overlay to distinguish lots stuff there like VPNs/services which >> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 >> address. Having said that, discussion always to be had if you pay me dinner >> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but >> again, no _real_ use case so far. And if your only concern is to "shape >> towards a prefix" we have PGP in the draft which doesn't need new silicon >> ;-P And then ultimately, yes, if you really, really want a SID per prefix >> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >> really just a glorified way to say "I have this non-aggreagable 20 bit IP >> host address" which architecturally is a very interesting proposition in >> terms of scaling (but then again, no account for taste and RFC1925 clause 3 >> applies) ... Your LSDB will be still much smaller, your SPF will be still >> simple on leaf in RIFT but your FIB will blow up and anything changing on a >> leaf shakes all other leafs (unless you start to run pollicies to control >> distribution @ which point in time you start to baby-sit your fabric @ high >> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast >> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you >> will observe that RIFT can do anycast without need for ECMP, i.e. true >> anycast in a sense and with that having anycast SID serves no real purpose >> in RIFT and is actually generally much harder to do since you need globally >> unique label blocks and so on ... >> >> 2. Horizontal links on CLOSes are not used that way normally all I saw >> since your blocking goes to hell unless you provision some kind of really >> massive parallel links between ToRs _and_ understand your load. We _could_ >> build RIFT that way but you give up balancing through the fabric and >> loop-free property in a sense (that's a longish discussion and scaling >> since now you have prefixes showing up all kind of crazy places instead of >> default). I see enough demand, we get there ... Otherwise RFC1925 clause >> 10 and 5. >> >> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >> links, unless provisioned correctly will pretty much just ruin your >> blocking/loss on the fabric is the experience (which the math supports). In >> a sense if you know your big flows you can build a specialized topology to >> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily >> scalable). Otherwise a good analogy would be that you like to build special >> RAM chips for the type of data structures you are storing and we know how >> well that scales over time. We know now that within 3-4 years >> characteristics of DC flows flip upside down without a sweat when people go >> from server/client to microservices, from servers to containers and so on >> and so on. So if you can't predict your load all the time you need a >> _regular_ topology where _regular_ is more of a mathematical than a >> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >> just stick them in" applies here. So RIFT is done largely to serve a >> well-known structure called a "lattice" (with some restrictions) since we >> need an "up" and "down". Things like hypercubes, thoroidal meshes and so on >> and so on exist but CLOS won for a very good reason in history for that >> kind of problems (once you move to NUMA other things win ;-) And if you >> know your loads and your can heft the OPEX and you like to play with >> protocols generally and if you can support the scale in terms of leaf FIB >> sizes, flooding, slower convergence & so on & so on and you run flat IGP on >> some kind of stuff that you build that doesn't even have to be regular in >> any sense. We spent many years solving THAT problem obviously and doing >> something like RIFT to replace normal IGP is of limited interest IMO >> (albeit certain aspects having to do with modern implemenation techniques >> may get us there one day but it's much less of pressing problem than >> solving specialized DC routing well IMO again). >> >> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >> cable (that's the point of it) or rather we have miscabling detection and >> do not form adjacencies when you read the draft carefully. That's your >> "flash red light" and it comes included for free with my compliments ;-) >> ... Otherwise RFC1925 clause 10. >> >> Otherwise, if you have concrete charter points you'd like to add, be more >> specific in your asks and we see what the list thinks after ... >> >> thanks >> >> --- tony >> >> >> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I have one little question/doubt on scalability point of RIFT ... >>> >>> Assume that someone would like to signal IPv6 prefix SID for Segment >>> Routing in the underlay within RIFT. >>> >>> Wouldn't it result in amount of protocol state in full analogy to >>> massive deaggregation - which as of today is designed to be very careful >>> and limited operation only at moments of failure(s) ? >>> >>> I sort of find it a bit surprising that RIFT draft does not provide >>> encoding for SID distribution when it is positioned as an alternative to >>> other protocols (IGPs or BGP) which already provide ability to carry all >>> types of SIDs. >>> >>> Cheers, >>> Robert. >>> >>> PS1: Horizontal links which were discussed could be installed to offload >>> from fabric transit massive amount of data (ex: storage mirroring) directly >>> between leafs or L3 TORs and not to be treated as "backup". >>> >>> PS2: Restricting any protocol to specific topologies seems like pretty >>> slippery slope to me. In any case if protocol does that it should also >>> contain self detection mechanism of "unsupported topology" and flash red >>> light in any NOC. >>> >>> >>> >>> _______________________________________________ >>> Dcrouting mailing list >>> Dcrouting@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrouting >>> >>> >> > --f403045dc2e0f1b7d0056286b55a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A. Reading the draft you'll find the overloa= d bit on RIFT which IMO is the best out-of-production solution.
B.= Depends what your LEAF is. If LEAF is your TOR (most stuff today) then RIF= T will do that just fine using LEAF2LEAF procedures in fact. If we start to= run RIFT @ the server level then we'd need discuss but people do not d= o horizontal links in non-leaf-to-non-leaf as far I saw (except protection = here and there) but then again, they mostly don't extend the fabric rou= ting protocol into the server (which RIFT intends to do). So, for today you= 're good. Once you want RIFT on server I think having spine horizontals= is not a good idea in general

I hope that co= mputes and I'd encourage you to read the draft again, maybe without the= "it should work just like BGP or just like today's IGP" hat = on ...=C2=A0 ;-)=C2=A0 Of course, paying me fancy dinners and asking questi= ons, letting me ramble then is a valid substitute ;-)

--- tony

On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk <= ;robert@raszuk.net> wrote:
Hi Tony,

Thx for elaborating ...

Two small comments:

A) SID/SR use case= in underlay could be as simple as gracefully taking a fabric node out of s= ervice. Not much OPEX needed if your NMS is decent. Otherwise in normal lin= k state I can do overload bit, in BGP number of solutions from shutdown to = MED to LP ... depending what is your BGP design. In RIFT how do you do that= ? Note that overlay (if such exist) does not help here.=C2=A0

B) For horizontal links imagine yo= u have servers with 40 GB ports to TOR. Then you have Nx100 GB from TOR up.= You are going to oversubscribe on TOR (servers to fabric) most likely 2:1 = .. 3:1 etc. So if I want to interconnect TORs because I do know that server= s behind those TORs need to talk to each other in a non blocking fashion _a= nd_ I have spare 100 GB ports on TORs having routing protocol which does no= t allow me to do that seems pretty limited - wouldn't you agree ?=C2=A0=

Thx,
R.


=





On Th= u, Jan 11, 2018 at 6:40 PM, Tony Przygienda <tonysietf@gmail.com&g= t; wrote:
Robert, productive points, thanks for raising them ... I go a bit i= n depth

1. I saw no _real_ use-cases for SID i= n DC so far to be frank (once you run RIFT). The only one that comes up reg= ularly is egress engineering and that IMO is equivalent to SID=3Dleaf addre= ss (which could be a HV address of course once you have RIFT all way down t= o server) so really, what's the point to have a SID? It's probably = much smarter to use IBGP & so on overlay to do this kind of synchroniza= tion if needed since labels/SIDs become very useful in overlay to distingui= sh lots stuff there like VPNs/services which you'd carry e.g. in MPLSoU= DP. In underlay just use the destination v4/v6 address. Having said that, d= iscussion always to be had if you pay me dinner ;--) and I know _how_ we ca= n do SIDs in RIFT since I thought it through but again, no _real_ use case = so far. And if your only concern is to "shape towards a prefix" w= e have PGP in the draft which doesn't need new silicon ;-P And then ult= imately, yes, if you really, really want a SID per prefix everywhere then y= ou'll carry=C2=A0 SIDs to everywhere since unicast SIDs are really just= a glorified way to say "I have this non-aggreagable 20 bit IP host ad= dress" which architecturally is a very interesting proposition in term= s of scaling (but then again, no account for taste and RFC1925 clause 3 app= lies) ...=C2=A0 Your LSDB will be still much smaller, your SPF will be stil= l simple on leaf in RIFT but your FIB will blow up and anything changing on= a leaf shakes all other leafs (unless you start to run pollicies to contro= l distribution @ which point in time you start to baby-sit your fabric @ hi= gh OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast= (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully yo= u will observe that RIFT can do anycast without need for ECMP, i.e. true an= ycast in a sense and with that having anycast SID serves no real purpose in= RIFT and is actually generally much harder to do since you need globally u= nique label blocks and so on ...=C2=A0

2. Horizontal links on= CLOSes are not used that way normally all I saw since your blocking goes t= o hell unless you provision some kind of really massive parallel links betw= een ToRs _and_ understand your load. We _could_ build RIFT that way but you= give up balancing through the fabric and loop-free property in a sense (th= at's a longish discussion=C2=A0 and scaling since now you have prefixes= showing up all kind of crazy places instead of default). I see enough dema= nd, we get there ...=C2=A0 Otherwise RFC1925 clause 10 and 5.=C2=A0
<= div>
3. PS1: Yes, lots of things "could" be done an= d then we "could" build a protocol to do that and RFC1925 clause = 7 and 8 applies. Such horizontal links, unless provisioned correctly will p= retty much just ruin your blocking/loss on the fabric is the experience (wh= ich the math supports). In a sense if you know your big flows you can build= a specialized topology to do the optimal distribution (MPLS tunnels anyone= ;-) but the point of fabric is that it's a fabric (i.e. load agnostic,= cheap, no OPEX and easily scalable). Otherwise a good analogy would be tha= t you like to build special RAM chips for the type of data structures you a= re storing and we know how well that scales over time. We know now that wit= hin 3-4 years characteristics of DC flows flip upside down without a sweat = when people go from server/client to microservices, from servers to contain= ers and so on and so on. So if you can't predict your load all the time= you need a _regular_ topology where _regular_ is more of a mathematical th= an a protocol discussion. Fabric analogy of "buy more RAM chips in Fry= 's and just stick them in" applies here. So RIFT is done largely t= o serve a well-known structure called a "lattice" (with some rest= rictions) since we need an "up" and "down". Things like= hypercubes, thoroidal meshes and so on and so on exist but CLOS won for a = very good reason in history for that kind of problems (once you move to NUM= A other things win ;-) And if you know your loads and your can heft the OPE= X and you like to play with protocols generally and if you can support the = scale in terms of leaf FIB sizes, flooding, slower convergence & so on = & so on and you run flat IGP on some kind of stuff that you build that = doesn't even have to be regular in any sense. We spent many years solvi= ng THAT problem obviously and doing something like RIFT to replace normal I= GP is of limited interest IMO (albeit certain aspects having to do with mod= ern implemenation techniques may get us there one day but it's much les= s of pressing problem than solving specialized DC routing well IMO again). =

3. PS2: RIFT cannot build an "unsupported top= ology" no matter how you cable (that's the point of it) or rather = we have miscabling detection and do not form adjacencies when you read the = draft carefully. That's your "flash red light" and it comes i= ncluded for free with my compliments=C2=A0 ;-) ... Otherwise RFC1925 clause= 10.

Otherwise, if you have concrete charter points you'd= like to add, be more specific in your asks and we see what the list thinks= after ...

thanks

---= tony


On Thu, Jan 11, = 2018 at 1:30 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little question/doubt on scal= ability point of RIFT ...=C2=A0

Assume that someone would like to sign= al IPv6 prefix SID for Segment Routing in the underlay within RIFT.=C2=A0
<= br>
Wouldn't it result in amount of protocol state in full analogy to m= assive deaggregation - which as of today is designed to be very careful and= limited operation only at moments of failure(s) ?=C2=A0

I sort of fin= d it a bit surprising that RIFT draft does not provide encoding for SID dis= tribution when it is positioned as an alternative to other protocols (IGPs = or BGP) which already provide ability to carry all types of SIDs.=C2=A0
Cheers,
Robert.

PS1: Horizontal links which were discussed could = be installed to offload from fabric transit massive amount of data (ex: sto= rage mirroring) directly between leafs or L3 TORs and not to be treated as = "backup".=C2=A0

PS2: Restricting any protocol to specific to= pologies seems like pretty slippery slope to me. In any case if protocol do= es that it should also contain self detection mechanism of "unsupporte= d topology" and flash red light in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>




--f403045dc2e0f1b7d0056286b55a-- From nobody Thu Jan 11 13:57:22 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0E12E045; Thu, 11 Jan 2018 13:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, UNPARSEABLE_RELAY=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 8tUYXw1y4Eb9; Thu, 11 Jan 2018 13:57:17 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 5BE521273E2; Thu, 11 Jan 2018 13:57:17 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id a24so3442243otd.4; Thu, 11 Jan 2018 13:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ZOe/iqwAftGBwsC8/fs7dq1ebuYz+ysSo6aVUTbms4M=; b=iTxSbMj5lRrvBjuYoTXk3ZRVz+Dwet8rTNuOVajKnNSBbwdyLdR3TfMkD2Eu3yAy5T QLUXMBLqaLoXG1Q/72KKezoGckmL8irO4veWHFWAkqSGxnhkSvgnLHdKIy9Jp0AO3zOi +4UCXNl08/AXDp72AaJiNZtzVMghUejpLrEN+lbEOP6aFq/wJ/3/6nXzxW/v2/HV6ril TTPabuWJTetIgWCIpbhl0iqEjZPUVdaCYZW3Dhayw2Alx8i+4rEfsjF4NjN6x03evraB Yi57a0bTN+P53aEWPMhdbCoZyWfnoYIzrw6NbDyPvYP7oaL0kGvrhQV85PR+JOBh2Yfe XVCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ZOe/iqwAftGBwsC8/fs7dq1ebuYz+ysSo6aVUTbms4M=; b=bHQ1+kYCog28gbyiFO+tjwylSt4RbFoEL8zcgp83wLBFM9TpWkoRNy8nzZ+NHnU56b btHA23AW4xS6Ksw9Spg4EIG36s6Y4ImylvdPhASJplAZ5VHGZJCz0Iwp9IqUaziszrEi dji7GktiV89z78kEh/rEf57/0uc0klODV7FPCZMaP9cQJxrHmalnNcTYvYxzoFrX6CNh 8GsPGUVsYoHy1eZyTHJRckOpR+5s5fzHJ4GKXwl5D50G2Jkx2vBv7jLcTAO/m7L4vw9U jpRArWjza4WP5/MnAB6rMPZMou144X8A/RmLB4/axdZSVn1+RdlGLJ6+dzdJcPzAGeEw F3MA== X-Gm-Message-State: AKwxyte5jGt50TFR8ZhDWy3l3xvfExxvvxA5qvUoThXAlRUy+FQroVN+ R9jqLvBzVim+nM1BGT5VMwIQzpt2+6KD3kobbOE= X-Google-Smtp-Source: ACJfBosQrYngtEHsR0XQgD2ZhHgPJCMlAfZ/XeBzOKg/EYJMmjTP6ZS8Q0xuMOaVFNmi9B3kpmoB4o65wysgserfmVA= X-Received: by 10.157.48.108 with SMTP id w41mr3655669otd.289.1515707836652; Thu, 11 Jan 2018 13:57:16 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jan 2018 13:57:16 -0800 From: Alvaro Retana In-Reply-To: <89a53447d5dc423b8c4cd8c9376756e7@XCH-ALN-001.cisco.com> References: <151322370751.6222.4040293688172571956.idtracker@ietfa.amsl.com> <89a53447d5dc423b8c4cd8c9376756e7@XCH-ALN-001.cisco.com> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 11 Jan 2018 13:57:16 -0800 Message-ID: To: "Les Ginsberg (ginsberg)" , The IESG , Kathleen Moriarty Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "martin.vigoureux@nokia.com" Content-Type: multipart/alternative; boundary="001a113ac6f42fe28e0562873bde" Archived-At: Subject: Re: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 21:57:21 -0000 --001a113ac6f42fe28e0562873bde Content-Type: text/plain; charset="UTF-8" Kathleen: Hi! Any thoughts on the update to this document? Thanks! Alvaro. On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg) ( ginsberg@cisco.com) wrote: Kathleen - Thanx for the review. V14 has been published and it attempts to address the Security concerns raised by you and others. Look forward to your feedback. Inline. > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, December 13, 2017 7:55 PM > To: The IESG > Cc: draft-ietf-spring-segment-routing@ietf.org; aretana.ietf@gmail.com; > spring-chairs@ietf.org; martin.vigoureux@nokia.com; spring@ietf.org > Subject: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing- > 13: (with DISCUSS) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-spring-segment-routing-13: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > While I understand the assumption that following the capabilities of existing > protocols that incorporate similar functionality is okay, I'd like to walk through > the security properties left off in the security considerations section to > prevent tampering and see what can be done to correct that or minimally to > list out the considerations. > > There's a few places in the security considerations section to call out > specifically. > > Section 8.1: > "The received information is validated using > existing control plane protocols providing authentication and > security mechanisms. Segment Routing does not define any additional > security mechanism in existing control plane protocols." > > For MPLS what "security mechanisms" are referred to in this text? It would > be helpful to list any properties explicitly or drop this phrase if there are no > additional security mechanisms. Since segment routing lists an explicit list of > segments (I see that this can be done with MPLS labels and you note it is > already exposed), why is there no mention of integrity protection and origin > authentication to prevent tampering? I think EKR's comment is already > hinting at this with his comments on IPv6, but I'd like to see explicit text to > preferably fix this gap in the architecture, but minimally to document it and > the associated security threats that result from this gap for MPLS and IPv6. > [Les:] We have reemphasized that SR is designed to be used within a trusted domain. As such, any attacker who sees a segment list already has breached the domain protections. > Section 8.2: > > "From a network protection standpoint, there is an assumed trust model > such that any node adding an SRH to the packet is assumed to be > allowed to do so. Therefore, by default, the explicit routing > information MUST NOT be leaked through the boundaries of the > administered domain. Segment Routing extensions that have been > defined in various protocols, leverage the security mechanisms of > these protocols such as encryption, authentication, filtering, etc." > > This document focuses on the same threats as the MPLS use cases with no > mention of tampering or mitigations. Text should be added to describe how > origin authentication and integrity are provided in the source routing header > for IPv6 with the associated threats or to describe this gap if a solution does > not exist. I have not read the draft referred to at the start of this section, so I > don't know if it addresses the concern or not. In any case, this document > isn't complete without some text on tampering considerations within your > trusted domain. > [Les:] The architecture draft is NOT proposing support of SRH introduced outside the domain of trust. Such support is an exception to the architecture. When done the use of origin authentication would be appropriate, but such an exception is not being described nor advocated in this document. Les > Thank you. > > > --001a113ac6f42fe28e0562873bde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Kathleen:

Hi!

An= y thoughts on the update to this document?

Thanks!

Alvaro.

On December 20, 2017 at= 6:42:02 PM, Les Ginsberg (ginsberg) (ginsberg@cisco.com) wrote:

Kathleen -

Thanx for the review.
V14 has been published and it attempts to address the Security concerns= raised by you and others.
Look forward to your feedback.

Inline.

> -----Original Message-----
> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]
> Sent: Wednesday, December 13, 2017 7:55 PM
> To: The IESG <iesg@ietf.org>
> Cc: = draft-ietf-spring-segment-routing@ietf.org; aretana.ietf@gmail.com;
> spring-chairs@ietf.org; martin.vigoureux@nokia.co= m; spring@ietf.org
> Subject: Kathleen Moriarty's Discuss on draft-ietf-spring-segm= ent-routing-
> 13: (with DISCUSS)
> =20
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-spring-segment-routing-13: Discuss
> =20
> When responding, please keep the subject line intact and reply to = all email
> addresses included in the To and CC lines. (Feel free to cut this = introductory
> paragraph, however.)
> =20
> =20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT positions.
> =20
> =20
> The document, along with other ballot positions, can be found here= :
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-ro= uting/
> =20
> =20
> =20
> ------------------------------------------------------------------= ----
> DISCUSS:
> ------------------------------------------------------------------= ----
> =20
> While I understand the assumption that following the capabilities = of existing
> protocols that incorporate similar functionality is okay, I'd = like to walk through
> the security properties left off in the security considerations se= ction to
> prevent tampering and see what can be done to correct that or mini= mally to
> list out the considerations.
> =20
> There's a few places in the security considerations section to= call out
> specifically.
> =20
> Section 8.1:
> "The received information is validated using
> existing control plane protocols providing authentication and
> security mechanisms. Segment Routing does not define any addit= ional
> security mechanism in existing control plane protocols."
> =20
> For MPLS what "security mechanisms" are referred to in t= his text? It would
> be helpful to list any properties explicitly or drop this phrase i= f there are no
> additional security mechanisms. Since segment routing lists an ex= plicit list of
> segments (I see that this can be done with MPLS labels and you not= e it is
> already exposed), why is there no mention of integrity protection = and origin
> authentication to prevent tampering? I think EKR's comment is= already
> hinting at this with his comments on IPv6, but I'd like to see= explicit text to
> preferably fix this gap in the architecture, but minimally to docu= ment it and
> the associated security threats that result from this gap for MPLS= and IPv6.
> =20

[Les:] We have reemphasized that SR is designed to be used within a tru= sted domain. As such, any attacker who sees a segment list already has brea= ched the domain protections.

> Section 8.2:
> =20
> "From a network protection standpoint, there is an assumed= trust model
> such that any node adding an SRH to the packet is assumed to be
> allowed to do so. Therefore, by default, the explicit routing
> information MUST NOT be leaked through the boundaries of the
> administered domain. Segment Routing extensions that have been
> defined in various protocols, leverage the security mechanisms = of
> these protocols such as encryption, authentication, filtering, = etc."
> =20
> This document focuses on the same threats as the MPLS use cases wi= th no
> mention of tampering or mitigations. Text should be added to desc= ribe how
> origin authentication and integrity are provided in the source rou= ting header
> for IPv6 with the associated threats or to describe this gap if a = solution does
> not exist. I have not read the draft referred to at the start of = this section, so I
> don't know if it addresses the concern or not. In any case, t= his document
> isn't complete without some text on tampering considerations w= ithin your
> trusted domain.
> =20
[Les:] The architecture draft is NOT proposing support of SRH introduce= d outside the domain of trust. Such support is an exception to the architec= ture. When done the use of origin authentication would be appropriate, but = such an exception is not being described nor advocated in this document.

Les

> Thank you.
> =20
> =20
> =20

--001a113ac6f42fe28e0562873bde-- From nobody Thu Jan 11 13:58:55 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464B212E045; Thu, 11 Jan 2018 13:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, UNPARSEABLE_RELAY=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 mk8WvrXJ75Da; Thu, 11 Jan 2018 13:58:51 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 5B3B812DA72; Thu, 11 Jan 2018 13:58:51 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id a70so2697560oib.1; Thu, 11 Jan 2018 13:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=u2Pc2Tbs41HCowYrImFhFbiQDxWkfC3XnMf9Osun2Nc=; b=qq9QAaEVDKEuPEmS79Bggq3hIn8cpH65yY3dSp5QQXXb40mTIT2YAHHurMphcv+d9Q l/dbEYYYvoVBsOPsbNgheRa9CADh8/TUrUKDT1gnUQfjRdM+nQA9t7XB4Xb/+m8RFahS sJRYelz2fpCTQzVrnBppGOuBzW2Wz83dD+pOM1wCF3+X3MtOZQRkiW6aMr8gpSmS2hNo bcW4daw0ovJNqAUiTwoqTD7c2Jyzd45YHwF4cERVqFEL7ge/d3VPGq9XJQLdSgBHUKv8 AKl5W/LFdrrnOLfxR1RLz9m0MNGsgNU3TjzTWtbyEL7p7NC8QJjM+VM7/k0Ts5QH/4kh vM1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=u2Pc2Tbs41HCowYrImFhFbiQDxWkfC3XnMf9Osun2Nc=; b=RiJthO+5OLNWLoXZBRUXPJDsyYRcD0+gWwMPtfXoCUsqaB5mo+f6Yy0GoNxnlQGra7 M3iCri4VAGiaYENiDWejTwWU2HbJtCL21OD40f2GtF3TbIrmJ29eOJZYGaeQAR9SHHuy qFMgYMeIUZUbn1hrdVDoB4tpRwdfN7ac1XDiAk7OXUKUiQbVsWWGKHEmOLIaNM6h/p1V smkkigCz9p3+/HXICeA8YuN00XS1mfltxXLedYzpUVPW1805gtGjn/Ha+olbrrhR4GCd l7rZghEsEvZs+pl7spkkDl7aQQiUkPLagb6HYVGNx/OscURt92CsrgwWzzOvoOzYjsY4 /2Iw== X-Gm-Message-State: AKwxytfE7L5ySp39YNCZYsMEhK0vmLf+eknSbZ99v6GvTN4zuiXmgL4t edEFWb+PPhvLOQCaOvGxnJB7iL9WadBX3EUyyG8= X-Google-Smtp-Source: ACJfBotmVm2mEpGzhY8ZVT2RgBxdRdHXZ3/FL3RO7ax/eoNP1Q7/Hp23zrxtTZIx1//yswjVSYRNLG4fUm8qyXo/RlY= X-Received: by 10.202.45.7 with SMTP id t7mr7622835oit.356.1515707930653; Thu, 11 Jan 2018 13:58:50 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jan 2018 13:58:49 -0800 From: Alvaro Retana In-Reply-To: <404fda4a03294dfeac55074a0937a54c@XCH-ALN-001.cisco.com> References: <151319051482.30109.537791118842316529.idtracker@ietfa.amsl.com> <404fda4a03294dfeac55074a0937a54c@XCH-ALN-001.cisco.com> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 11 Jan 2018 13:58:49 -0800 Message-ID: To: "Les Ginsberg (ginsberg)" , Alissa Cooper , The IESG Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "martin.vigoureux@nokia.com" Content-Type: multipart/alternative; boundary="001a1137bebaca3ca20562874059" Archived-At: Subject: Re: [spring] Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jan 2018 21:58:54 -0000 --001a1137bebaca3ca20562874059 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alissa: Hi! Any thoughts on the update to this document? Thanks! Alvaro. On December 20, 2017 at 6:18:13 PM, Les Ginsberg (ginsberg) ( ginsberg@cisco.com) wrote: Alissa - Thanx for the review. V14 has been published and it attempts to address the Security concerns raised by you and others. Look forward to your feedback. Inline. > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Wednesday, December 13, 2017 10:42 AM > To: The IESG > Cc: draft-ietf-spring-segment-routing@ietf.org; aretana.ietf@gmail.com; > spring-chairs@ietf.org; martin.vigoureux@nokia.com; spring@ietf.org > Subject: Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13: > (with DISCUSS and COMMENT) > > Alissa Cooper has entered the following ballot position for > draft-ietf-spring-segment-routing-13: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I ended up reading draft-ietf-6man-segment-routing-header in tandem with > this document, and I have a question arising out of that. The trust model for > SRv6 outlined in this document appears to be one of reliance on the fact that > an SRH will only ever be inserted and appear within a single administrative > domain. > But Section 5.2.2 of draft-ietf-6man-segment-routing-header talks about an > SRH being inserted by a device outside of the segment routing domain. > Which is correct? I think this is an important question because the whole > trust model for the SR information seems to rely on out-of-band trust > between participating nodes. > > I also think this is important because there is no discussion in this document > of the impact of the inclusion of the SR metadata on the fingerprinting of the > device that inserted it. Section 5.1.4 of draft-ietf-6man-segment-routing- > header sort of alludes to this but seems to equate the capabilities of an > active attacker (who can conduct a traceroute) with a passive attacker who > could passively collect topology/fingerprinting information simply by > observing SRHes flowing by on the network. If the limitation to a single > administrative domain is meant to prevent such a passive attack (not sure if > that is really true, but perhaps the document assumes it?), that's another > reason that the existence of such a limitation needs to be clarified. > > [Les:] We share a common concern regarding trust issues. The architecture draft speaks to the default policy of only allowing trusted sources to insert SRH. The 6man draft currently discusses exceptions under the protection of authentication. I don=E2=80=99t see that as a contradiction. The risk/reward of allowing such exceptions can (and should) be discussed in the review of the 6man draft, but I am not convinced the architecture draft needs to speak to this since it is a clearly stated exception to the base trust model. The point that SR is intended to operate within a trusted domain has been clarified/reemphasized in the Security section changes. Les > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Per my DISCUSS comment, I think this document needs to include some > considerations concerning the additional metadata that SRv6 adds to the > packet. > This has implications not just for passive observers but also for any node that > logs the SRH. > --001a1137bebaca3ca20562874059 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Alissa:

Hi!

An= y thoughts on the update to this document?

Thanks!

Alvaro.

On December 20, 2017 at= 6:18:13 PM, Les Ginsberg (ginsberg) (ginsberg@cisco.com) wrote:

Alissa -

Thanx for the review.
V14 has been published and it attempts to address the Security concerns= raised by you and others.
Look forward to your feedback.

Inline.

> -----Original Message-----
> From: Alissa Cooper [mailto:a= lissa@cooperw.in]
> Sent: Wednesday, December 13, 2017 10:42 AM
> To: The IESG <iesg@ietf.org>
> Cc: = draft-ietf-spring-segment-routing@ietf.org; aretana.ietf@gmail.com;
> spring-chairs@ietf.org; martin.vigoureux@nokia.co= m; spring@ietf.org
> Subject: Alissa Cooper's Discuss on draft-ietf-spring-segment-= routing-13:
> (with DISCUSS and COMMENT)
> =20
> Alissa Cooper has entered the following ballot position for
> draft-ietf-spring-segment-routing-13: Discuss
> =20
> When responding, please keep the subject line intact and reply to = all email
> addresses included in the To and CC lines. (Feel free to cut this = introductory
> paragraph, however.)
> =20
> =20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT positions.
> =20
> =20
> The document, along with other ballot positions, can be found here= :
> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-ro= uting/
> =20
> =20
> =20
> ------------------------------------------------------------------= ----
> DISCUSS:
> ------------------------------------------------------------------= ----
> =20
> I ended up reading draft-ietf-6man-segment-routing-header in tande= m with
> this document, and I have a question arising out of that. The trus= t model for
> SRv6 outlined in this document appears to be one of reliance on th= e fact that
> an SRH will only ever be inserted and appear within a single admin= istrative
> domain.
> But Section 5.2.2 of draft-ietf-6man-segment-routing-header talks = about an
> SRH being inserted by a device outside of the segment routing doma= in.
> Which is correct? I think this is an important question because th= e whole
> trust model for the SR information seems to rely on out-of-band tr= ust
> between participating nodes.
> =20
> I also think this is important because there is no discussion in t= his document
> of the impact of the inclusion of the SR metadata on the fingerpri= nting of the
> device that inserted it. Section 5.1.4 of draft-ietf-6man-segment-= routing-
> header sort of alludes to this but seems to equate the capabilitie= s of an
> active attacker (who can conduct a traceroute) with a passive atta= cker who
> could passively collect topology/fingerprinting information simply= by
> observing SRHes flowing by on the network. If the limitation to a = single
> administrative domain is meant to prevent such a passive attack (n= ot sure if
> that is really true, but perhaps the document assumes it?), that&#= 39;s another
> reason that the existence of such a limitation needs to be clarifi= ed.
> =20
> =20
[Les:] We share a common concern regarding trust issues. The architectu= re draft speaks to the default policy of only allowing trusted sources to i= nsert SRH.
The 6man draft currently discusses exceptions under the protection of a= uthentication. I don=E2=80=99t see that as a contradiction.
The risk/reward of allowing such exceptions can (and should) be discuss= ed in the review of the 6man draft, but I am not convinced the architecture= draft needs to speak to this since it is a clearly stated exception to the= base trust model. =20

The point that SR is intended to operate within a trusted domain has be= en clarified/reemphasized in the Security section changes.

Les



> ------------------------------------------------------------------= ----
> COMMENT:
> ------------------------------------------------------------------= ----
> =20
> =20
> Per my DISCUSS comment, I think this document needs to include som= e
> considerations concerning the additional metadata that SRv6 adds t= o the
> packet.
> This has implications not just for passive observers but also for = any node that
> logs the SRH.
> =20

--001a1137bebaca3ca20562874059-- From nobody Fri Jan 12 10:59:05 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93818127201; Fri, 12 Jan 2018 10:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1w54FY4Crnn; Fri, 12 Jan 2018 10:59:01 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED404126D0C; Fri, 12 Jan 2018 10:59:00 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id y5so5053581pff.13; Fri, 12 Jan 2018 10:59:00 -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=UDKLxUBQ2GQ5ILBjhy2ojSr+0SAC8aehJuIr92DnHR4=; b=CpPTZTm7921ZDe7wn0lVw/Pfo2H9gsT6tgAZ576vF1SkhaWVGQKUxVgwc2dFCpCpc8 5Uo8eQni2OnKbxHb8VFVY2Uy3WHcU2NiQ1ed+s44F1I1AcxfcxWi+54BhtD6R6zkpTJv hoB+UVNPHE2+zbILF2wkFUxltrqdlXCRkhibudwkPMBOgnomiWIXeWfVD0UyM2kujkv6 bw6aZZ557ylUlRIjbLdN4iLG/UUtX9l7ZevvtX3N4/eg6dqaLXckeVxVvNk7gMvE4TYl gbgirf7F2DOd7el6KYHbpstzpgGaC8vD/h+DVN7FJTzayBG+ygbkYvBdVHOtK88AluxZ Ob8w== 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=UDKLxUBQ2GQ5ILBjhy2ojSr+0SAC8aehJuIr92DnHR4=; b=WXBWyKNqw3fYpQzI3xXM9ItiSSwdSvLfrwmUi4mCrRvvm8GMIY+71tMlu1RDx5YCUX cpLWMFnvYAnlM9dl5zrewSONfqd7YI5F/6CsqloyEvIhpnM5Xm5QSa++nNu26pgLFFpJ mK3vjyCmIvd/FkjwJ/pPbNET+wZ9Vks/n5U4CIoZk3zHVGA13u8jLeM9rs7HWKplDDmy 3CTNWYoF2cYoxaElifF3zu6lHy9z/Y6cEaf9as7tQsvoU309I2clmiuNd3OkhbnWl8Zi E23IYPLJh1nwscSk73bO1wXC8yVqXkB3ucspFjrvdJuFB2j/eBgHKt0Gl9TlsdqQrUoJ /xnw== X-Gm-Message-State: AKGB3mKFgswVXrFyDses2bXNdiscWF9dgRLxvMh7tikzcF8ROXhnZ4eh v22YFcfpcEoPgaSUVFSTHzEYKTXWNYTD/A3TJUY= X-Google-Smtp-Source: ACJfBouhyXjBmooRD24Ir2GXDos7YLLWqbz8V0k+B0gpF2qQ9237D+B2r4TX2qXfMa38DXKTi/3ooTxhQn9JPX78FH8= X-Received: by 10.98.141.141 with SMTP id p13mr24266376pfk.185.1515783540517; Fri, 12 Jan 2018 10:59:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Fri, 12 Jan 2018 10:58:20 -0800 (PST) In-Reply-To: References: <151322370751.6222.4040293688172571956.idtracker@ietfa.amsl.com> <89a53447d5dc423b8c4cd8c9376756e7@XCH-ALN-001.cisco.com> From: Kathleen Moriarty Date: Fri, 12 Jan 2018 13:58:20 -0500 Message-ID: To: Alvaro Retana Cc: "Les Ginsberg (ginsberg)" , The IESG , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "martin.vigoureux@nokia.com" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jan 2018 18:59:03 -0000 Hi, Alvaro! Thanks for bringing this to my attention, the message from Les slipped through the cracks. On Thu, Jan 11, 2018 at 4:57 PM, Alvaro Retana wrote: > Kathleen: > > Hi! > > Any thoughts on the update to this document? > > Thanks! > > Alvaro. > > On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg) > (ginsberg@cisco.com) wrote: > > Kathleen - > > Thanx for the review. > V14 has been published and it attempts to address the Security concerns > raised by you and others. > Look forward to your feedback. > > Inline. > >> -----Original Message----- >> From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] >> Sent: Wednesday, December 13, 2017 7:55 PM >> To: The IESG >> Cc: draft-ietf-spring-segment-routing@ietf.org; aretana.ietf@gmail.com; >> spring-chairs@ietf.org; martin.vigoureux@nokia.com; spring@ietf.org >> Subject: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing- >> 13: (with DISCUSS) >> >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-spring-segment-routing-13: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email >> addresses included in the To and CC lines. (Feel free to cut this >> introductory >> paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> While I understand the assumption that following the capabilities of >> existing >> protocols that incorporate similar functionality is okay, I'd like to walk >> through >> the security properties left off in the security considerations section to >> prevent tampering and see what can be done to correct that or minimally to >> list out the considerations. >> >> There's a few places in the security considerations section to call out >> specifically. >> >> Section 8.1: >> "The received information is validated using >> existing control plane protocols providing authentication and >> security mechanisms. Segment Routing does not define any additional >> security mechanism in existing control plane protocols." >> >> For MPLS what "security mechanisms" are referred to in this text? It would >> be helpful to list any properties explicitly or drop this phrase if there >> are no >> additional security mechanisms. Since segment routing lists an explicit >> list of >> segments (I see that this can be done with MPLS labels and you note it is >> already exposed), why is there no mention of integrity protection and >> origin >> authentication to prevent tampering? I think EKR's comment is already >> hinting at this with his comments on IPv6, but I'd like to see explicit >> text to >> preferably fix this gap in the architecture, but minimally to document it >> and >> the associated security threats that result from this gap for MPLS and >> IPv6. >> > > [Les:] We have reemphasized that SR is designed to be used within a trusted > domain. As such, any attacker who sees a segment list already has breached > the domain protections. > >> Section 8.2: >> >> "From a network protection standpoint, there is an assumed trust model >> such that any node adding an SRH to the packet is assumed to be >> allowed to do so. Therefore, by default, the explicit routing >> information MUST NOT be leaked through the boundaries of the >> administered domain. Segment Routing extensions that have been >> defined in various protocols, leverage the security mechanisms of >> these protocols such as encryption, authentication, filtering, etc." >> >> This document focuses on the same threats as the MPLS use cases with no >> mention of tampering or mitigations. Text should be added to describe how >> origin authentication and integrity are provided in the source routing >> header >> for IPv6 with the associated threats or to describe this gap if a solution >> does >> not exist. I have not read the draft referred to at the start of this >> section, so I >> don't know if it addresses the concern or not. In any case, this document >> isn't complete without some text on tampering considerations within your >> trusted domain. >> > [Les:] The architecture draft is NOT proposing support of SRH introduced > outside the domain of trust. Such support is an exception to the > architecture. When done the use of origin authentication would be > appropriate, but such an exception is not being described nor advocated in > this document. Here I'm asking about tampering within the trusted domain, not just a statement that this is expected to occur within a trusted domain. If there are no mitigations, that is a security consideration that should be stated explicitly as a risk and it's fine if you tie it to your assumed trust model. So describing the gap in the text as requested in one of the options to address the discuss seems like the approach needed here. Thank you, Kathleen > > Les > >> Thank you. >> >> >> > -- Best regards, Kathleen From nobody Fri Jan 12 15:06:32 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F5A126BF3; Fri, 12 Jan 2018 15:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH3DXqgvpVNT; Fri, 12 Jan 2018 15:06:25 -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 B6900124E15; Fri, 12 Jan 2018 15:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8970; q=dns/txt; s=iport; t=1515798384; x=1517007984; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Dff4cpuq6sueRPDLb9KKehxB3YucFVVqMfNsy2wpwIo=; b=OuQzfVpLbahSoFgPLSMt/6x/vMbBj9eoKIuvRX+eHBEVWPqK/lw3fXlW p7e6CqunO9jdELtbOCvdfOZSFKowCPpPJI73+ic67RemiXAVUITy/Zs6K fVxOr7TFPsjYAdbpsmnVRwsQQaFPeBCZIjtkOKBkrh7MbBCZDoVSD31oY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAQCFPlla/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNBZnQnB4QNiiSOYoICiQuOJhSCAgojhRgCGoQnPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQMjEUUMBAIBCBEBAwEBAQICIwMCAgIfERQBAgYIAgQBDQUIE?= =?us-ascii?q?4oAAxUQrj+CJ4dADYJwAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4MtghWBV4F?= =?us-ascii?q?pgy6Ca0QCAQEBAYE6ARIBNoMAgmUFh3eCXZhTPQKICodqU4R5giKGHYQVh0WKa?= =?us-ascii?q?IJWQIh6AhEZAYE7AR85YFcRCG8VPYIqgwmBTngBiUYNGAeBBoEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,350,1511827200"; d="scan'208";a="340953930" 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; 12 Jan 2018 23:06:23 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w0CN6NNT020941 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jan 2018 23:06:23 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 12 Jan 2018 17:06:22 -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.1320.000; Fri, 12 Jan 2018 17:06:22 -0600 From: "Les Ginsberg (ginsberg)" To: Kathleen Moriarty , Alvaro Retana CC: The IESG , "spring@ietf.org" , "spring-chairs@ietf.org" , "draft-ietf-spring-segment-routing@ietf.org" , "martin.vigoureux@nokia.com" Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS) Thread-Index: AQHTdI9WKmVqSARqCU+9XTnuZetI6qNM7ZnggCLcJgCAAWBXAP//3psg Date: Fri, 12 Jan 2018 23:06:22 +0000 Message-ID: References: <151322370751.6222.4040293688172571956.idtracker@ietfa.amsl.com> <89a53447d5dc423b8c4cd8c9376756e7@XCH-ALN-001.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.57.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jan 2018 23:06:27 -0000 S2F0aGxlZW4gLQ0KDQpJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBhZGRpdGlvbiB0byB0aGUgZW5k IG9mIFNlY3Rpb24gOC4NCg0KIlRoZSB1c2Ugb2YgYmVzdCBwcmFjdGljZXMgdG8gcmVkdWNlIHRo ZSByaXNrIG9mIHRhbXBlcmluZyB3aXRoaW4gDQp0aGUgdHJ1c3RlZCBkb21haW4gaXMgaW1wb3J0 YW50LiBTdWNoIHByYWN0aWNlcyBhcmUgZGlzY3Vzc2VkIGluDQpbUkZDNDM4MV0gYW5kIGFyZSBh cHBsaWNhYmxlIHRvIGJvdGggU1ItTVBMUyBhbmQgU1J2Ni4iDQoNCiAgICBMZXMNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEthdGhsZWVuIE1vcmlhcnR5IFttYWls dG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSmFu dWFyeSAxMiwgMjAxOCAxMDo1OCBBTQ0KPiBUbzogQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRm QGdtYWlsLmNvbT4NCj4gQ2M6IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNj by5jb20+OyBUaGUgSUVTRw0KPiA8aWVzZ0BpZXRmLm9yZz47IHNwcmluZ0BpZXRmLm9yZzsgc3By aW5nLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zcHJpbmctDQo+IHNlZ21lbnQtcm91dGlu Z0BpZXRmLm9yZzsgbWFydGluLnZpZ291cmV1eEBub2tpYS5jb20NCj4gU3ViamVjdDogUmU6IEth dGhsZWVuIE1vcmlhcnR5J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LQ0K PiByb3V0aW5nLTEzOiAod2l0aCBESVNDVVNTKQ0KPiANCj4gSGksIEFsdmFybyENCj4gDQo+IFRo YW5rcyBmb3IgYnJpbmdpbmcgdGhpcyB0byBteSBhdHRlbnRpb24sIHRoZSBtZXNzYWdlIGZyb20g TGVzIHNsaXBwZWQNCj4gdGhyb3VnaCB0aGUgY3JhY2tzLg0KPiANCj4gT24gVGh1LCBKYW4gMTEs IDIwMTggYXQgNDo1NyBQTSwgQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4N Cj4gd3JvdGU6DQo+ID4gS2F0aGxlZW46DQo+ID4NCj4gPiBIaSENCj4gPg0KPiA+IEFueSB0aG91 Z2h0cyBvbiB0aGUgdXBkYXRlIHRvIHRoaXMgZG9jdW1lbnQ/DQo+ID4NCj4gPiBUaGFua3MhDQo+ ID4NCj4gPiBBbHZhcm8uDQo+ID4NCj4gPiBPbiBEZWNlbWJlciAyMCwgMjAxNyBhdCA2OjQyOjAy IFBNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KPiA+IChnaW5zYmVyZ0BjaXNjby5jb20pIHdy b3RlOg0KPiA+DQo+ID4gS2F0aGxlZW4gLQ0KPiA+DQo+ID4gVGhhbnggZm9yIHRoZSByZXZpZXcu DQo+ID4gVjE0IGhhcyBiZWVuIHB1Ymxpc2hlZCBhbmQgaXQgYXR0ZW1wdHMgdG8gYWRkcmVzcyB0 aGUgU2VjdXJpdHkNCj4gPiBjb25jZXJucyByYWlzZWQgYnkgeW91IGFuZCBvdGhlcnMuDQo+ID4g TG9vayBmb3J3YXJkIHRvIHlvdXIgZmVlZGJhY2suDQo+ID4NCj4gPiBJbmxpbmUuDQo+ID4NCj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogS2F0aGxlZW4gTW9yaWFy dHkgW21haWx0bzpLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NCj4gPj4gU2VudDog V2VkbmVzZGF5LCBEZWNlbWJlciAxMywgMjAxNyA3OjU1IFBNDQo+ID4+IFRvOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gPj4gQ2M6IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Z0BpZXRmLm9yZzsNCj4gPj4gYXJldGFuYS5pZXRmQGdtYWlsLmNvbTsgc3ByaW5nLWNoYWlyc0Bp ZXRmLm9yZzsNCj4gPj4gbWFydGluLnZpZ291cmV1eEBub2tpYS5jb207IHNwcmluZ0BpZXRmLm9y Zw0KPiA+PiBTdWJqZWN0OiBLYXRobGVlbiBNb3JpYXJ0eSdzIERpc2N1c3Mgb24NCj4gPj4gZHJh ZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLQ0KPiA+PiAxMzogKHdpdGggRElTQ1VTUykN Cj4gPj4NCj4gPj4gS2F0aGxlZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGlu Zy0xMzogRGlzY3Vzcw0KPiA+Pg0KPiA+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPj4gZW1haWwgYWRkcmVz c2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0DQo+ ID4+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4+DQo+ID4+DQo+ ID4+IFBsZWFzZSByZWZlciB0bw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRl bWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4g VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KPiA+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmcvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+PiAtDQo+ID4+IERJU0NVU1M6DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAt DQo+ID4+DQo+ID4+IFdoaWxlIEkgdW5kZXJzdGFuZCB0aGUgYXNzdW1wdGlvbiB0aGF0IGZvbGxv d2luZyB0aGUgY2FwYWJpbGl0aWVzIG9mDQo+ID4+IGV4aXN0aW5nIHByb3RvY29scyB0aGF0IGlu Y29ycG9yYXRlIHNpbWlsYXIgZnVuY3Rpb25hbGl0eSBpcyBva2F5LA0KPiA+PiBJJ2QgbGlrZSB0 byB3YWxrIHRocm91Z2ggdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgbGVmdCBvZmYgaW4gdGhlDQo+ ID4+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdG8gcHJldmVudCB0YW1wZXJpbmcg YW5kIHNlZSB3aGF0IGNhbg0KPiA+PiBiZSBkb25lIHRvIGNvcnJlY3QgdGhhdCBvciBtaW5pbWFs bHkgdG8gbGlzdCBvdXQgdGhlIGNvbnNpZGVyYXRpb25zLg0KPiA+Pg0KPiA+PiBUaGVyZSdzIGEg ZmV3IHBsYWNlcyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0byBjYWxs DQo+ID4+IG91dCBzcGVjaWZpY2FsbHkuDQo+ID4+DQo+ID4+IFNlY3Rpb24gOC4xOg0KPiA+PiAi VGhlIHJlY2VpdmVkIGluZm9ybWF0aW9uIGlzIHZhbGlkYXRlZCB1c2luZyBleGlzdGluZyBjb250 cm9sIHBsYW5lDQo+ID4+IHByb3RvY29scyBwcm92aWRpbmcgYXV0aGVudGljYXRpb24gYW5kIHNl Y3VyaXR5IG1lY2hhbmlzbXMuIFNlZ21lbnQNCj4gPj4gUm91dGluZyBkb2VzIG5vdCBkZWZpbmUg YW55IGFkZGl0aW9uYWwgc2VjdXJpdHkgbWVjaGFuaXNtIGluIGV4aXN0aW5nDQo+ID4+IGNvbnRy b2wgcGxhbmUgcHJvdG9jb2xzLiINCj4gPj4NCj4gPj4gRm9yIE1QTFMgd2hhdCAic2VjdXJpdHkg bWVjaGFuaXNtcyIgYXJlIHJlZmVycmVkIHRvIGluIHRoaXMgdGV4dD8gSXQNCj4gPj4gd291bGQg YmUgaGVscGZ1bCB0byBsaXN0IGFueSBwcm9wZXJ0aWVzIGV4cGxpY2l0bHkgb3IgZHJvcCB0aGlz DQo+ID4+IHBocmFzZSBpZiB0aGVyZSBhcmUgbm8gYWRkaXRpb25hbCBzZWN1cml0eSBtZWNoYW5p c21zLiBTaW5jZSBzZWdtZW50DQo+ID4+IHJvdXRpbmcgbGlzdHMgYW4gZXhwbGljaXQgbGlzdCBv ZiBzZWdtZW50cyAoSSBzZWUgdGhhdCB0aGlzIGNhbiBiZQ0KPiA+PiBkb25lIHdpdGggTVBMUyBs YWJlbHMgYW5kIHlvdSBub3RlIGl0IGlzIGFscmVhZHkgZXhwb3NlZCksIHdoeSBpcw0KPiA+PiB0 aGVyZSBubyBtZW50aW9uIG9mIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBvcmlnaW4gYXV0aGVu dGljYXRpb24gdG8NCj4gPj4gcHJldmVudCB0YW1wZXJpbmc/IEkgdGhpbmsgRUtSJ3MgY29tbWVu dCBpcyBhbHJlYWR5IGhpbnRpbmcgYXQgdGhpcw0KPiA+PiB3aXRoIGhpcyBjb21tZW50cyBvbiBJ UHY2LCBidXQgSSdkIGxpa2UgdG8gc2VlIGV4cGxpY2l0IHRleHQgdG8NCj4gPj4gcHJlZmVyYWJs eSBmaXggdGhpcyBnYXAgaW4gdGhlIGFyY2hpdGVjdHVyZSwgYnV0IG1pbmltYWxseSB0bw0KPiA+ PiBkb2N1bWVudCBpdCBhbmQgdGhlIGFzc29jaWF0ZWQgc2VjdXJpdHkgdGhyZWF0cyB0aGF0IHJl c3VsdCBmcm9tIHRoaXMNCj4gPj4gZ2FwIGZvciBNUExTIGFuZCBJUHY2Lg0KPiA+Pg0KPiA+DQo+ ID4gW0xlczpdIFdlIGhhdmUgcmVlbXBoYXNpemVkIHRoYXQgU1IgaXMgZGVzaWduZWQgdG8gYmUg dXNlZCB3aXRoaW4gYQ0KPiB0cnVzdGVkDQo+ID4gZG9tYWluLiBBcyBzdWNoLCBhbnkgYXR0YWNr ZXIgd2hvIHNlZXMgYSBzZWdtZW50IGxpc3QgYWxyZWFkeSBoYXMNCj4gYnJlYWNoZWQNCj4gPiB0 aGUgZG9tYWluIHByb3RlY3Rpb25zLg0KPiA+DQo+ID4+IFNlY3Rpb24gOC4yOg0KPiA+Pg0KPiA+ PiAiRnJvbSBhIG5ldHdvcmsgcHJvdGVjdGlvbiBzdGFuZHBvaW50LCB0aGVyZSBpcyBhbiBhc3N1 bWVkIHRydXN0IG1vZGVsDQo+ID4+IHN1Y2ggdGhhdCBhbnkgbm9kZSBhZGRpbmcgYW4gU1JIIHRv IHRoZSBwYWNrZXQgaXMgYXNzdW1lZCB0byBiZQ0KPiA+PiBhbGxvd2VkIHRvIGRvIHNvLiBUaGVy ZWZvcmUsIGJ5IGRlZmF1bHQsIHRoZSBleHBsaWNpdCByb3V0aW5nDQo+ID4+IGluZm9ybWF0aW9u IE1VU1QgTk9UIGJlIGxlYWtlZCB0aHJvdWdoIHRoZSBib3VuZGFyaWVzIG9mIHRoZQ0KPiA+PiBh ZG1pbmlzdGVyZWQgZG9tYWluLiBTZWdtZW50IFJvdXRpbmcgZXh0ZW5zaW9ucyB0aGF0IGhhdmUg YmVlbg0KPiA+PiBkZWZpbmVkIGluIHZhcmlvdXMgcHJvdG9jb2xzLCBsZXZlcmFnZSB0aGUgc2Vj dXJpdHkgbWVjaGFuaXNtcyBvZg0KPiA+PiB0aGVzZSBwcm90b2NvbHMgc3VjaCBhcyBlbmNyeXB0 aW9uLCBhdXRoZW50aWNhdGlvbiwgZmlsdGVyaW5nLCBldGMuIg0KPiA+Pg0KPiA+PiBUaGlzIGRv Y3VtZW50IGZvY3VzZXMgb24gdGhlIHNhbWUgdGhyZWF0cyBhcyB0aGUgTVBMUyB1c2UgY2FzZXMg d2l0aA0KPiBubw0KPiA+PiBtZW50aW9uIG9mIHRhbXBlcmluZyBvciBtaXRpZ2F0aW9ucy4gVGV4 dCBzaG91bGQgYmUgYWRkZWQgdG8gZGVzY3JpYmUNCj4gaG93DQo+ID4+IG9yaWdpbiBhdXRoZW50 aWNhdGlvbiBhbmQgaW50ZWdyaXR5IGFyZSBwcm92aWRlZCBpbiB0aGUgc291cmNlIHJvdXRpbmcN Cj4gPj4gaGVhZGVyDQo+ID4+IGZvciBJUHY2IHdpdGggdGhlIGFzc29jaWF0ZWQgdGhyZWF0cyBv ciB0byBkZXNjcmliZSB0aGlzIGdhcCBpZiBhIHNvbHV0aW9uDQo+ID4+IGRvZXMNCj4gPj4gbm90 IGV4aXN0LiBJIGhhdmUgbm90IHJlYWQgdGhlIGRyYWZ0IHJlZmVycmVkIHRvIGF0IHRoZSBzdGFy dCBvZiB0aGlzDQo+ID4+IHNlY3Rpb24sIHNvIEkNCj4gPj4gZG9uJ3Qga25vdyBpZiBpdCBhZGRy ZXNzZXMgdGhlIGNvbmNlcm4gb3Igbm90LiBJbiBhbnkgY2FzZSwgdGhpcyBkb2N1bWVudA0KPiA+ PiBpc24ndCBjb21wbGV0ZSB3aXRob3V0IHNvbWUgdGV4dCBvbiB0YW1wZXJpbmcgY29uc2lkZXJh dGlvbnMgd2l0aGluIHlvdXINCj4gPj4gdHJ1c3RlZCBkb21haW4uDQo+ID4+DQo+ID4gW0xlczpd IFRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgaXMgTk9UIHByb3Bvc2luZyBzdXBwb3J0IG9mIFNSSCBp bnRyb2R1Y2VkDQo+ID4gb3V0c2lkZSB0aGUgZG9tYWluIG9mIHRydXN0LiBTdWNoIHN1cHBvcnQg aXMgYW4gZXhjZXB0aW9uIHRvIHRoZQ0KPiA+IGFyY2hpdGVjdHVyZS4gV2hlbiBkb25lIHRoZSB1 c2Ugb2Ygb3JpZ2luIGF1dGhlbnRpY2F0aW9uIHdvdWxkIGJlDQo+ID4gYXBwcm9wcmlhdGUsIGJ1 dCBzdWNoIGFuIGV4Y2VwdGlvbiBpcyBub3QgYmVpbmcgZGVzY3JpYmVkIG5vciBhZHZvY2F0ZWQg aW4NCj4gPiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gSGVyZSBJJ20gYXNraW5nIGFib3V0IHRhbXBl cmluZyB3aXRoaW4gdGhlIHRydXN0ZWQgZG9tYWluLCBub3QganVzdCBhDQo+IHN0YXRlbWVudCB0 aGF0IHRoaXMgaXMgZXhwZWN0ZWQgdG8gb2NjdXIgd2l0aGluIGEgdHJ1c3RlZCBkb21haW4uICBJ Zg0KPiB0aGVyZSBhcmUgbm8gbWl0aWdhdGlvbnMsIHRoYXQgaXMgYSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIHRoYXQgc2hvdWxkDQo+IGJlIHN0YXRlZCBleHBsaWNpdGx5IGFzIGEgcmlzayBhbmQg aXQncyBmaW5lIGlmIHlvdSB0aWUgaXQgdG8geW91cg0KPiBhc3N1bWVkIHRydXN0IG1vZGVsLg0K PiANCj4gU28gZGVzY3JpYmluZyB0aGUgZ2FwIGluIHRoZSB0ZXh0IGFzIHJlcXVlc3RlZCBpbiBv bmUgb2YgdGhlIG9wdGlvbnMNCj4gdG8gYWRkcmVzcyB0aGUgZGlzY3VzcyBzZWVtcyBsaWtlIHRo ZSBhcHByb2FjaCBuZWVkZWQgaGVyZS4NCj4gDQo+IFRoYW5rIHlvdSwNCj4gS2F0aGxlZW4NCj4g DQo+ID4NCj4gPiBMZXMNCj4gPg0KPiA+PiBUaGFuayB5b3UuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ ID4NCj4gDQo+IA0KPiANCj4gLS0NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gS2F0aGxlZW4NCg== From nobody Sat Jan 13 10:17:45 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF012D946; Sat, 13 Jan 2018 10:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[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 L4pFTk_zgke9; Sat, 13 Jan 2018 10:17:31 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43C312D944; Sat, 13 Jan 2018 10:17:30 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 141so17378599wme.3; Sat, 13 Jan 2018 10:17:30 -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=KEI6utxYxohvgPc2yEgIZxMMdheZ0eskVDfyStQqha0=; b=Sk8NH1HfG0PY0gyzDlj9w1Ij2nKT+98SXG0NPhOkXshs+aWwY58gVqOKPvQPTSWZCW ccfu1eLX44WV+QHreRnXJNINWWF4jQR7PYS0JH3JyQgWU7fr0Kig1rg8XJyfNXkJ9R3a et91NjkBNVi322Iq3OrNlOQSWo6qT4l9baKtkNCII6csDaFMItDsirYLZQ+gZiYrrY5x JxdOT/17AFlIcrrAy0MUl2V0IsiL10IkP+LCvXj7BUnXKxW2j6iR+RXQbX3pPyPI0/3p DeayJrLB+8ZvF14OTJqd5jfNHoK3SQAmV3BEoRlnN378xQfHYll+xyzXdST6USKxEBX3 zwrA== 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=KEI6utxYxohvgPc2yEgIZxMMdheZ0eskVDfyStQqha0=; b=OZWssFTHkupDt5YmMS64e/d5XrERTfAASSrZYZiGZtUvV+eJGv+HtQ+L7SBjGV8XSi +K2H4ymA45qnUmdGjc177ac7tM04ICRwd/VTPdul2kjNV1SeDYGPOpjcsjIiyGQAdCIc fT9rpyK5UO+3MIVH1RM4hLDdT9ufRwHQ8EEudYlHRz8Ce8Msz9lylsIqvQA4w4b1MQwU ySWNXJPboWwRC0rbcd9P0ohMTm6sRGtn4M5A6jDUXca13bTBaUzsP/yQYxt+0nDGOnmD qknYHHwFMZdM7c9tFUfcvI+MdRHIx/ubH18ktTtKhL301m2Fx3zNughRUyl+H9MiaJI7 E0Kg== X-Gm-Message-State: AKwxytfzAWz+55nDjzSWUzBZxi7Umip6ukUlV3FJm5YiTQ1PMDTPue6g DbOwD8gI+WeEghjJE9op0++SvE7/5lj82J9Vj0s/XXVy X-Google-Smtp-Source: ACJfBotiqIl9QK6CNqU+43tkCk2tmza3axvtrupMxh/Sl6VmZAajWCZM71A5Yj9RFgKEQnaSZQinwyfNAypcyKWIvd4= X-Received: by 10.80.155.90 with SMTP id a26mr3233443edj.290.1515867449013; Sat, 13 Jan 2018 10:17:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Sat, 13 Jan 2018 10:16:48 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Sat, 13 Jan 2018 10:16:48 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af462d338da0562ac649d" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 18:17:35 -0000 --94eb2c1af462d338da0562ac649d Content-Type: text/plain; charset="UTF-8" So I thought over your horizontal link case to shortcut the spine levels for some kind of traffic again and I think the current draft actually covers that if you're willing to provision things correctly yourself via S-PGP. Let me see whether we agree on this picture first: . +--------+ +--------+ . | | | | ^ N . |Spine 21| |Spine 22| | .Level 2 ++-+--+-++ ++-+--+-++ <-*-> E/W . | | | | | | | | | . P111/2| |P121 | | | | S v . ^ ^ ^ ^ | | | | . | | | | | | | | . +--------------+ | +-----------+ | | | +---------------+ . | | | | | | | | . South +-----------------------------+ | | ^ . | | | | | | | All TIEs . 0/0 0/0 0/0 +-----------------------------+ | . v v v | | | | | . | | +-+ +<-0/0----------+ | | . | | | | | | | | .+-+----++ optional +-+----++ ++----+-+ ++-----++ .| | E/W link | +=====+ | | | .|Node111+----------+Node112| |Node121| |Node122| .+-+---+-+ ++----+-+ +-+---+-+ ++---+--+ . | | | South | | | | . | +---0/0--->-----+ 0/0 | +----------------+ | . 0/0 | | | | | | | . | +---<-0/0-----+ | v | +--------------+ | | . v | | | | | | | .+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ .| | (L2L) | | | | Level 0 | | .|Leaf111~~~~~~~~~~~~Leaf112| |Leaf121| |Leaf122| .+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ . + + \ / + + . Prefix111 Prefix112 \ / Prefix121 Prefix122 . multi-homed . Prefix .+---------- Pod 1 ---------+ +---------- Pod 2 ---------+ I assume here that what you ask for is the following scenario: a) POD1 being a compute generating very heavy load towards storage in Prefix121. b) traffic from POD1 NOT being balanced through the spines but taking a horizontal link Node112 to Node121 to reach your storage in Prefix121 to save bandwidth? or delay? c) The key to riches is -04 section4.2.5.1 . Northbound SPF in the paragraph "Other south prefixes found when crossing E-W link MAY be used IIF". Now, we could make it a MUST (but it's really an implementation knob IMO) and what it says is that if you are willing to inject an "S-PGP" @ Node121 for Prefix121 it will get flooded to Node112 and Node112 will have a more specific match than the default in N-SPF. From 121 normal RIFT takes over since the normal N-Prefix for Leaf121 kicks in on Node121. I assume Node112 policy on the ingress is to not propagate the S-PGP south but use it for N-SPF only. Observe that a) you have to switch off miscabling detection for PoD# on those nodes since you are "crossing PoDs illegally" b) if you want whole Pod#1 to do that you either cable Node111 to Node121 as well (which will load balance whole Pod#1 towards storage without using Spine) OR you propagate S-PGPs south towards leafs (which will cost you leaf FIB of course but make sure ALL traffic to storage goes over Node112 only). c) Your forwarding on Node112 can actually even go haywire & load-balance some of the traffic to Prefix121 using this S-PGP over Node121 and some still using the default route towards spine(which here is a blatant violation of LPM of course) and RIFT will work just fine (unless you loop yourself to death with PGPs you install) but that of course is a deep rathole in itself. I just mention it to show why the "non-looping" design is so important and makes for the shortcomings for the SPF on a fabric, predicted by the non-directional mesh property that Dijkstra solved in his time. so? --- tony On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote: > Hi Tony, > > Thx for elaborating ... > > Two small comments: > > A) SID/SR use case in underlay could be as simple as gracefully taking a > fabric node out of service. Not much OPEX needed if your NMS is decent. > Otherwise in normal link state I can do overload bit, in BGP number of > solutions from shutdown to MED to LP ... depending what is your BGP design. > In RIFT how do you do that ? Note that overlay (if such exist) does not > help here. > > B) For horizontal links imagine you have servers with 40 GB ports to TOR. > Then you have Nx100 GB from TOR up. You are going to oversubscribe on TOR > (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to > interconnect TORs because I do know that servers behind those TORs need to > talk to each other in a non blocking fashion _and_ I have spare 100 GB > ports on TORs having routing protocol which does not allow me to do that > seems pretty limited - wouldn't you agree ? > > Thx, > R. > > > > > > > > On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda > wrote: > >> Robert, productive points, thanks for raising them ... I go a bit in depth >> >> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >> run RIFT). The only one that comes up regularly is egress engineering and >> that IMO is equivalent to SID=leaf address (which could be a HV address of >> course once you have RIFT all way down to server) so really, what's the >> point to have a SID? It's probably much smarter to use IBGP & so on overlay >> to do this kind of synchronization if needed since labels/SIDs become very >> useful in overlay to distinguish lots stuff there like VPNs/services which >> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 >> address. Having said that, discussion always to be had if you pay me dinner >> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through but >> again, no _real_ use case so far. And if your only concern is to "shape >> towards a prefix" we have PGP in the draft which doesn't need new silicon >> ;-P And then ultimately, yes, if you really, really want a SID per prefix >> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >> really just a glorified way to say "I have this non-aggreagable 20 bit IP >> host address" which architecturally is a very interesting proposition in >> terms of scaling (but then again, no account for taste and RFC1925 clause 3 >> applies) ... Your LSDB will be still much smaller, your SPF will be still >> simple on leaf in RIFT but your FIB will blow up and anything changing on a >> leaf shakes all other leafs (unless you start to run pollicies to control >> distribution @ which point in time you start to baby-sit your fabric @ high >> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycast >> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully you >> will observe that RIFT can do anycast without need for ECMP, i.e. true >> anycast in a sense and with that having anycast SID serves no real purpose >> in RIFT and is actually generally much harder to do since you need globally >> unique label blocks and so on ... >> >> 2. Horizontal links on CLOSes are not used that way normally all I saw >> since your blocking goes to hell unless you provision some kind of really >> massive parallel links between ToRs _and_ understand your load. We _could_ >> build RIFT that way but you give up balancing through the fabric and >> loop-free property in a sense (that's a longish discussion and scaling >> since now you have prefixes showing up all kind of crazy places instead of >> default). I see enough demand, we get there ... Otherwise RFC1925 clause >> 10 and 5. >> >> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >> links, unless provisioned correctly will pretty much just ruin your >> blocking/loss on the fabric is the experience (which the math supports). In >> a sense if you know your big flows you can build a specialized topology to >> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily >> scalable). Otherwise a good analogy would be that you like to build special >> RAM chips for the type of data structures you are storing and we know how >> well that scales over time. We know now that within 3-4 years >> characteristics of DC flows flip upside down without a sweat when people go >> from server/client to microservices, from servers to containers and so on >> and so on. So if you can't predict your load all the time you need a >> _regular_ topology where _regular_ is more of a mathematical than a >> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >> just stick them in" applies here. So RIFT is done largely to serve a >> well-known structure called a "lattice" (with some restrictions) since we >> need an "up" and "down". Things like hypercubes, thoroidal meshes and so on >> and so on exist but CLOS won for a very good reason in history for that >> kind of problems (once you move to NUMA other things win ;-) And if you >> know your loads and your can heft the OPEX and you like to play with >> protocols generally and if you can support the scale in terms of leaf FIB >> sizes, flooding, slower convergence & so on & so on and you run flat IGP on >> some kind of stuff that you build that doesn't even have to be regular in >> any sense. We spent many years solving THAT problem obviously and doing >> something like RIFT to replace normal IGP is of limited interest IMO >> (albeit certain aspects having to do with modern implemenation techniques >> may get us there one day but it's much less of pressing problem than >> solving specialized DC routing well IMO again). >> >> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >> cable (that's the point of it) or rather we have miscabling detection and >> do not form adjacencies when you read the draft carefully. That's your >> "flash red light" and it comes included for free with my compliments ;-) >> ... Otherwise RFC1925 clause 10. >> >> Otherwise, if you have concrete charter points you'd like to add, be more >> specific in your asks and we see what the list thinks after ... >> >> thanks >> >> --- tony >> >> >> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk wrote: >> >>> Hi, >>> >>> I have one little question/doubt on scalability point of RIFT ... >>> >>> Assume that someone would like to signal IPv6 prefix SID for Segment >>> Routing in the underlay within RIFT. >>> >>> Wouldn't it result in amount of protocol state in full analogy to >>> massive deaggregation - which as of today is designed to be very careful >>> and limited operation only at moments of failure(s) ? >>> >>> I sort of find it a bit surprising that RIFT draft does not provide >>> encoding for SID distribution when it is positioned as an alternative to >>> other protocols (IGPs or BGP) which already provide ability to carry all >>> types of SIDs. >>> >>> Cheers, >>> Robert. >>> >>> PS1: Horizontal links which were discussed could be installed to offload >>> from fabric transit massive amount of data (ex: storage mirroring) directly >>> between leafs or L3 TORs and not to be treated as "backup". >>> >>> PS2: Restricting any protocol to specific topologies seems like pretty >>> slippery slope to me. In any case if protocol does that it should also >>> contain self detection mechanism of "unsupported topology" and flash red >>> light in any NOC. >>> >>> >>> >>> _______________________________________________ >>> Dcrouting mailing list >>> Dcrouting@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrouting >>> >>> >> > --94eb2c1af462d338da0562ac649d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So I thought over your horizontal link case= to shortcut the spine levels
for some kind of traffic a= gain and I think the current draft actually
covers that = if you're willing to provision things correctly yourself via S-PGP.
Let me see whether we agree on this picture first:

= .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--------+
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ^ N
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Spine 21|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Spine 22|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.Level 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ++-+--+-++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ++-+--+-++=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-*-> E/W=
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P111/2|=C2=A0 |P121=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 S v
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ ^=C2=A0 ^ ^=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 |= |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |
.=C2=A0 +------------= --+ |=C2=A0 +-----------+=C2=A0 | |=C2=A0 | +---------------+
.=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
. South +------= -----------------------+ |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
.=C2=A0 |=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 All TIEs
.=C2=A0 0/0=C2=A0 0/0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0/0=C2=A0=C2=A0 +---------------------= --------+=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 v=C2=A0=C2=A0=C2=A0 v=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0 |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+=C2=A0=C2=A0=C2=A0 += <-0/0----------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0 |
.+-+----++ optional +-+----++=C2=A0=C2=A0= =C2=A0=C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ++-----++
.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | E/W link |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=3D=3D=3D=3D=3D+ =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Node111+----------+Node112|=C2= =A0=C2=A0=C2=A0=C2=A0 |Node121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |Node122|
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++---+--+
.=C2=A0 |= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0 South=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0 +---0/0--->-----+ 0/0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 +----------------+= |
. 0/0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | |
.=C2=A0 |=C2=A0=C2=A0 += ---<-0/0-----+ |=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0 +--------------+ | |
.=C2=A0 v=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | |
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--+--+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +---+-+-+
.|=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0 (L2L)=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= Level 0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Leaf111~~~~~~~~~~~~Le= af112|=C2=A0=C2=A0=C2=A0=C2=A0 |Leaf121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |Leaf122|
.+-+-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0 +--+--+-+=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-----+
.=C2=A0 +=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 /=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
.=C2=A0 Prefix111=C2=A0=C2=A0 Pre= fix112=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 Pref= ix121=C2=A0=C2=A0=C2=A0 Prefix122
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multi-homed
.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefi= x
.+---------- Pod 1 ---------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------- Pod = 2 ---------+

I assume here that what you ask for is the fo= llowing scenario:
a) POD1 being a compute generating very hea= vy load towards storage in
=C2=A0=C2=A0 Prefix121.
<= /span>
b) traffic from POD1 NOT being balanced through the spines but tak= ing
=C2=A0=C2=A0 a horizontal link Node112 to Node= 121 to reach your storage in Prefix121
=C2=A0=C2=A0 to s= ave bandwidth? or delay?
<= font size=3D"2">c) The key = to riches is -04 section
4.2.5.1. Northbound SPF

=C2=A0 in the paragraph "Other south prefixes found when crossing E= -W link MAY be used IIF". Now, we could make it a MUST (but it's r= eally an implementation knob IMO) and what it says is that if you are willi= ng to inject an "S-PGP" @ Node121 for Prefix121 it will get flood= ed to Node112 and Node112 will have a more specific match than the default = in N-SPF. From 121 normal RIFT takes over since the normal N-Prefix for Lea= f121 kicks in on Node121. I assume Node112 policy on the ingress is to not = propagate the S-PGP south but use it for N-SPF only.

=


Observe that

a) you have to switch off mis= cabling detection for PoD# on those nodes since you are "crossing PoDs= illegally"

b) if you want whole Pod#1 to do that you either cable Node111 to No= de121 as well (which will load balance whole Pod#1 towards storage without = using Spine)=C2=A0 OR you propagate S-PGPs south towards leafs (which will = cost you leaf FIB of course but make sure ALL traffic to storage goes over = Node112 only).

c) Your forwarding on Node112 can actually even go haywire & load= -balance some of the traffic to Prefix121 using this S-PGP over Node121 and= some still using the default route towards spine(which here is a blatant v= iolation of LPM of course) and RIFT will work just fine (unless you loop yo= urself to death with PGPs you install) but that of course is a deep rathole= in itself. I just mention it to show why the "non-looping" desig= n is so important and makes for the shortcomings for the SPF on a fabric, p= redicted by the non-directional mesh property that Dijkstra solved in his t= ime.

so?<= br>

--- tony <= br>






On Thu, Jan 11, 2018 at 10:= 54 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
Thx for elaborating ...

Two small comments:
A) SID/SR use case in underlay could be as simple= as gracefully taking a fabric node out of service. Not much OPEX needed if= your NMS is decent. Otherwise in normal link state I can do overload bit, = in BGP number of solutions from shutdown to MED to LP ... depending what is= your BGP design. In RIFT how do you do that ? Note that overlay (if such e= xist) does not help here.=C2=A0

B) For horizontal links imagine you have servers with 40 GB ports= to TOR. Then you have Nx100 GB from TOR up. You are going to oversubscribe= on TOR (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to int= erconnect TORs because I do know that servers behind those TORs need to tal= k to each other in a non blocking fashion _and_ I have spare 100 GB ports o= n TORs having routing protocol which does not allow me to do that seems pre= tty limited - wouldn't you agree ?=C2=A0

Thx,
R.





<= br>

On Thu, Jan 11, 2018 at 6:40 PM, Tony= Przygienda <tonysietf@gmail.com> wrote:
Robert, productive points,= thanks for raising them ... I go a bit in depth

1. I saw no _real_ use-cases for SID in DC so far to be frank (once you = run RIFT). The only one that comes up regularly is egress engineering and t= hat IMO is equivalent to SID=3Dleaf address (which could be a HV address of= course once you have RIFT all way down to server) so really, what's th= e point to have a SID? It's probably much smarter to use IBGP & so = on overlay to do this kind of synchronization if needed since labels/SIDs b= ecome very useful in overlay to distinguish lots stuff there like VPNs/serv= ices which you'd carry e.g. in MPLSoUDP. In underlay just use the desti= nation v4/v6 address. Having said that, discussion always to be had if you = pay me dinner ;--) and I know _how_ we can do SIDs in RIFT since I thought = it through but again, no _real_ use case so far. And if your only concern i= s to "shape towards a prefix" we have PGP in the draft which does= n't need new silicon ;-P And then ultimately, yes, if you really, reall= y want a SID per prefix everywhere then you'll carry=C2=A0 SIDs to ever= ywhere since unicast SIDs are really just a glorified way to say "I ha= ve this non-aggreagable 20 bit IP host address" which architecturally = is a very interesting proposition in terms of scaling (but then again, no a= ccount for taste and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be = still much smaller, your SPF will be still simple on leaf in RIFT but your = FIB will blow up and anything changing on a leaf shakes all other leafs (un= less you start to run pollicies to control distribution @ which point in ti= me you start to baby-sit your fabric @ high OPEX). One of the reasons to do= per-prefix SID would be non-ECMP anycast (where SIDs _are_ in fact usefull= ) but if you read RIFT draft carefully you will observe that RIFT can do an= ycast without need for ECMP, i.e. true anycast in a sense and with that hav= ing anycast SID serves no real purpose in RIFT and is actually generally mu= ch harder to do since you need globally unique label blocks and so on ...= =C2=A0

2. Horizontal links on CLOSes are not used that way no= rmally all I saw since your blocking goes to hell unless you provision some= kind of really massive parallel links between ToRs _and_ understand your l= oad. We _could_ build RIFT that way but you give up balancing through the f= abric and loop-free property in a sense (that's a longish discussion=C2= =A0 and scaling since now you have prefixes showing up all kind of crazy pl= aces instead of default). I see enough demand, we get there ...=C2=A0 Other= wise RFC1925 clause 10 and 5.=C2=A0

3. PS1: Yes, = lots of things "could" be done and then we "could" buil= d a protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal= links, unless provisioned correctly will pretty much just ruin your blocki= ng/loss on the fabric is the experience (which the math supports). In a sen= se if you know your big flows you can build a specialized topology to do th= e optimal distribution (MPLS tunnels anyone ;-) but the point of fabric is = that it's a fabric (i.e. load agnostic, cheap, no OPEX and easily scala= ble). Otherwise a good analogy would be that you like to build special RAM = chips for the type of data structures you are storing and we know how well = that scales over time. We know now that within 3-4 years characteristics of= DC flows flip upside down without a sweat when people go from server/clien= t to microservices, from servers to containers and so on and so on. So if y= ou can't predict your load all the time you need a _regular_ topology w= here _regular_ is more of a mathematical than a protocol discussion. Fabric= analogy of "buy more RAM chips in Fry's and just stick them in&qu= ot; applies here. So RIFT is done largely to serve a well-known structure c= alled a "lattice" (with some restrictions) since we need an "= ;up" and "down". Things like hypercubes, thoroidal meshes an= d so on and so on exist but CLOS won for a very good reason in history for = that kind of problems (once you move to NUMA other things win ;-) And if yo= u know your loads and your can heft the OPEX and you like to play with prot= ocols generally and if you can support the scale in terms of leaf FIB sizes= , flooding, slower convergence & so on & so on and you run flat IGP= on some kind of stuff that you build that doesn't even have to be regu= lar in any sense. We spent many years solving THAT problem obviously and do= ing something like RIFT to replace normal IGP is of limited interest IMO (a= lbeit certain aspects having to do with modern implemenation techniques may= get us there one day but it's much less of pressing problem than solvi= ng specialized DC routing well IMO again).

3. PS2:= RIFT cannot build an "unsupported topology" no matter how you ca= ble (that's the point of it) or rather we have miscabling detection and= do not form adjacencies when you read the draft carefully. That's your= "flash red light" and it comes included for free with my complim= ents=C2=A0 ;-) ... Otherwise RFC1925 clause 10.

Otherwise, if= you have concrete charter points you'd like to add, be more specific i= n your asks and we see what the list thinks after ...

thanks

--- tony

<= div class=3D"gmail_extra">
On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk <= robert@raszuk.net> wrote:
Hi,

=
I have one little question/doubt on scalability point of RIFT ...=C2=A0
Assume that someone would like to signal IPv6 prefix SID for Segment Rou= ting in the underlay within RIFT.=C2=A0

Wouldn't it result in amou= nt of protocol state in full analogy to massive deaggregation - which as of= today is designed to be very careful and limited operation only at moments= of failure(s) ?=C2=A0

I sort of find it a bit surprising that RIFT dr= aft does not provide encoding for SID distribution when it is positioned as= an alternative to other protocols (IGPs or BGP) which already provide abil= ity to carry all types of SIDs.=C2=A0

Cheers,
Robert.

PS1: Hor= izontal links which were discussed could be installed to offload from fabri= c transit massive amount of data (ex: storage mirroring) directly between l= eafs or L3 TORs and not to be treated as "backup".=C2=A0

PS2= : Restricting any protocol to specific topologies seems like pretty slipper= y slope to me. In any case if protocol does that it should also contain sel= f detection mechanism of "unsupported topology" and flash red lig= ht in any NOC.=C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>




--94eb2c1af462d338da0562ac649d-- From nobody Sat Jan 13 11:22:05 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394B812DA18; Sat, 13 Jan 2018 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 BnE0sAhOl5TL; Sat, 13 Jan 2018 11:21:37 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671CC12D775; Sat, 13 Jan 2018 11:21:37 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id r78so17754724wme.0; Sat, 13 Jan 2018 11:21:37 -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=nDC5tEdZeKOJidfY4+fIen3tufn96hcV08bzyS97DBY=; b=uq7/lVnLKN9THamLL+QuLOXqHYDsQbuZmgE4q8ykpR1lRozFmggV8IzTQDG8PCcImA /aJ7cmwukbtYSxtEOiexfDuZ2Vyi556sG2+5ek4yp+GZqCHEYct/Yl/0rM3p3r2fxriW 1XEluU3FZUKoZQuzXQPfpTUJ4abh9LLs/hb1bINeR8VDY26EGrZKA46X6+7ZT68FIafV WD/E51+1Oiv41pF3X9ZinqqYH8S3eURgTNtmY0Yz0l5Z4jFdgNtGRjMCXGdNtmHrq+qM ZAdRenmZL/iQpfbNPLor0TAoJElIjxA0v/1mNf/Y2idRRA4LLxeOlspXvAbr6eViQEcY nWhw== 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=nDC5tEdZeKOJidfY4+fIen3tufn96hcV08bzyS97DBY=; b=EuvYl3OafrsaGw/KHmrXKIiypzqfIcPZOJUdh5CettTVMVN0PNN+/T9mXMlJg/UPiu ZpnOOwhqex4EBV898fFHIwoFDBoJ0jSniwqT0cJ62w35ni5NR0vGi3uMVjE/gXPM4UYm L1hFnQGyGoAFew/GitFZs28jIhvi3YbC8mKvxRtLlt1gWc6y6Pds5s2tOy80c3q7i/1T usAUx5W+mli4AN1vAwG/+b346nbsux+Xo4gGkfs8935YK9yjwssOD4/vzsmoXdGbJeqz I/9lkjLbVAMHh/4LGlRZVSLzbPCtduD/IWzLug34TWC+0Ng6etVJZsfjCZSpTtz/jjVn rptQ== X-Gm-Message-State: AKwxytc1Yd6CbN9nr/T92SEUTNq8RilyaAuFrs+ssDnaWsBqKchO6arV Y0Y/gW0DuF1Sy8QwsBm5Ti9ZPpyESYk3wifWdLe/ubjB X-Google-Smtp-Source: ACJfBovPpqxlmA8Hdn0xevvQ8aPWiVNMs3E4RVDtvAUmIrYUDwuXdxAel2FqRzKp13SlHk1Z/4fSUnIFmbsi8c2Klu4= X-Received: by 10.28.61.68 with SMTP id k65mr6530537wma.147.1515871295478; Sat, 13 Jan 2018 11:21:35 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Sat, 13 Jan 2018 11:21:34 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 13 Jan 2018 20:21:34 +0100 X-Google-Sender-Auth: 7dHHwjSzFZUKamPXnSNXUpgcBSE Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a114b2d02179ff90562ad4af1" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 19:21:41 -0000 --001a114b2d02179ff90562ad4af1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tony, > =E2=80=8B if you're willing to provision things correctly yourself via S-PGP. I am not willing to do that. I would like routing to do it for me auto-magically. But yes you got the question right. I was asking for shortcuts between last levels of fabric. Not so much between Node 111 & Node 112 - but you said it is optional so ok. Side note: PGP abbrev. for vast majority of people means completely different thing then what you defined it to mean locally in your draft. I highly recommended you rename it in -05 version to PGD (policy guided destination(s) or PGR (policy guided reachability/routing). Now requirement to switch off miscabling detection is not acceptable. You are stating that only rift knows how should I cable my fabric ? And if I cable it some other way it will detect it as miscabling ? I think in most cases of correct cables check you actually define the intent then network detects if such intent is met. > Node112 can actually even go haywire That may be not best property of a routing protocol :) Best, R. On Sat, Jan 13, 2018 at 7:16 PM, Tony Przygienda wrote: > So I thought over your horizontal link case to shortcut the spine levels > for some kind of traffic again and I think the current draft actually > covers that > =E2=80=8B=E2=80=8B > if you're willing to provision things correctly yourself via S-PGP. > Let me see whether we agree on this picture first: > > . +--------+ +--------+ > . | | | | ^ N > . |Spine 21| |Spine 22| | > .Level 2 ++-+--+-++ ++-+--+-++ <-*-> E/W > . | | | | | | | | | > . P111/2| |P121 | | | | S v > . ^ ^ ^ ^ | | | | > . | | | | | | | | > . +--------------+ | +-----------+ | | | +---------------+ > . | | | | | | | | > . South +-----------------------------+ | | ^ > . | | | | | | | All TIEs > . 0/0 0/0 0/0 +-----------------------------+ | > . v v v | | | | | > . | | +-+ +<-0/0----------+ | | > . | | | | | | | | > .+-+----++ optional +-+----++ ++----+-+ ++-----++ > .| | E/W link | +=3D=3D=3D=3D=3D+ | | | > .|Node111+----------+Node112| |Node121| |Node122| > .+-+---+-+ ++----+-+ +-+---+-+ ++---+--+ > . | | | South | | | | > . | +---0/0--->-----+ 0/0 | +----------------+ | > . 0/0 | | | | | | | > . | +---<-0/0-----+ | v | +--------------+ | | > . v | | | | | | | > .+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ > .| | (L2L) | | | | Level 0 | | > .|Leaf111~~~~~~~~~~~~Leaf112| |Leaf121| |Leaf122| > .+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ > . + + \ / + + > . Prefix111 Prefix112 \ / Prefix121 Prefix122 > . multi-homed > . Prefix > .+---------- Pod 1 ---------+ +---------- Pod 2 ---------+ > > I assume here that what you ask for is the following scenario: > a) POD1 being a compute generating very heavy load towards storage in > Prefix121. > b) traffic from POD1 NOT being balanced through the spines but taking > a horizontal link Node112 to Node121 to reach your storage in > Prefix121 > to save bandwidth? or delay? > c) The key to riches is -04 section4.2.5.1 > . > Northbound SPF > > in the paragraph "Other south prefixes found when crossing E-W link MAY > be used IIF". Now, we could make it a MUST (but it's really an > implementation knob IMO) and what it says is that if you are willing to > inject an "S-PGP" @ Node121 for Prefix121 it will get flooded to Node112 > and Node112 will have a more specific match than the default in N-SPF. Fr= om > 121 normal RIFT takes over since the normal N-Prefix for Leaf121 kicks in > on Node121. I assume Node112 policy on the ingress is to not propagate th= e > S-PGP south but use it for N-SPF only. > > > Observe that > > a) you have to switch off miscabling detection for PoD# on those nodes > since you are "crossing PoDs illegally" > > b) if you want whole Pod#1 to do that you either cable Node111 to Node121 > as well (which will load balance whole Pod#1 towards storage without usin= g > Spine) OR you propagate S-PGPs south towards leafs (which will cost you > leaf FIB of course but make sure ALL traffic to storage goes over Node112 > only). > > c) Your forwarding on Node112 can actually even go haywire & load-balance > some of the traffic to Prefix121 using this S-PGP over Node121 and some > still using the default route towards spine(which here is a blatant > violation of LPM of course) and RIFT will work just fine (unless you loop > yourself to death with PGPs you install) but that of course is a deep > rathole in itself. I just mention it to show why the "non-looping" design > is so important and makes for the shortcomings for the SPF on a fabric, > predicted by the non-directional mesh property that Dijkstra solved in hi= s > time. > > so? > > --- tony > > > > > > > On Thu, Jan 11, 2018 at 10:54 AM, Robert Raszuk wrote= : > >> Hi Tony, >> >> Thx for elaborating ... >> >> Two small comments: >> >> A) SID/SR use case in underlay could be as simple as gracefully taking a >> fabric node out of service. Not much OPEX needed if your NMS is decent. >> Otherwise in normal link state I can do overload bit, in BGP number of >> solutions from shutdown to MED to LP ... depending what is your BGP desi= gn. >> In RIFT how do you do that ? Note that overlay (if such exist) does not >> help here. >> >> B) For horizontal links imagine you have servers with 40 GB ports to TOR= . >> Then you have Nx100 GB from TOR up. You are going to oversubscribe on TO= R >> (servers to fabric) most likely 2:1 .. 3:1 etc. So if I want to >> interconnect TORs because I do know that servers behind those TORs need = to >> talk to each other in a non blocking fashion _and_ I have spare 100 GB >> ports on TORs having routing protocol which does not allow me to do that >> seems pretty limited - wouldn't you agree ? >> >> Thx, >> R. >> >> >> >> >> >> >> >> On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda >> wrote: >> >>> Robert, productive points, thanks for raising them ... I go a bit in >>> depth >>> >>> 1. I saw no _real_ use-cases for SID in DC so far to be frank (once you >>> run RIFT). The only one that comes up regularly is egress engineering a= nd >>> that IMO is equivalent to SID=3Dleaf address (which could be a HV addre= ss of >>> course once you have RIFT all way down to server) so really, what's the >>> point to have a SID? It's probably much smarter to use IBGP & so on ove= rlay >>> to do this kind of synchronization if needed since labels/SIDs become v= ery >>> useful in overlay to distinguish lots stuff there like VPNs/services wh= ich >>> you'd carry e.g. in MPLSoUDP. In underlay just use the destination v4/v= 6 >>> address. Having said that, discussion always to be had if you pay me di= nner >>> ;--) and I know _how_ we can do SIDs in RIFT since I thought it through= but >>> again, no _real_ use case so far. And if your only concern is to "shape >>> towards a prefix" we have PGP in the draft which doesn't need new silic= on >>> ;-P And then ultimately, yes, if you really, really want a SID per pref= ix >>> everywhere then you'll carry SIDs to everywhere since unicast SIDs are >>> really just a glorified way to say "I have this non-aggreagable 20 bit = IP >>> host address" which architecturally is a very interesting proposition i= n >>> terms of scaling (but then again, no account for taste and RFC1925 clau= se 3 >>> applies) ... Your LSDB will be still much smaller, your SPF will be st= ill >>> simple on leaf in RIFT but your FIB will blow up and anything changing = on a >>> leaf shakes all other leafs (unless you start to run pollicies to contr= ol >>> distribution @ which point in time you start to baby-sit your fabric @ = high >>> OPEX). One of the reasons to do per-prefix SID would be non-ECMP anycas= t >>> (where SIDs _are_ in fact usefull) but if you read RIFT draft carefully= you >>> will observe that RIFT can do anycast without need for ECMP, i.e. true >>> anycast in a sense and with that having anycast SID serves no real purp= ose >>> in RIFT and is actually generally much harder to do since you need glob= ally >>> unique label blocks and so on ... >>> >>> 2. Horizontal links on CLOSes are not used that way normally all I saw >>> since your blocking goes to hell unless you provision some kind of real= ly >>> massive parallel links between ToRs _and_ understand your load. We _cou= ld_ >>> build RIFT that way but you give up balancing through the fabric and >>> loop-free property in a sense (that's a longish discussion and scaling >>> since now you have prefixes showing up all kind of crazy places instead= of >>> default). I see enough demand, we get there ... Otherwise RFC1925 clau= se >>> 10 and 5. >>> >>> 3. PS1: Yes, lots of things "could" be done and then we "could" build a >>> protocol to do that and RFC1925 clause 7 and 8 applies. Such horizontal >>> links, unless provisioned correctly will pretty much just ruin your >>> blocking/loss on the fabric is the experience (which the math supports)= . In >>> a sense if you know your big flows you can build a specialized topology= to >>> do the optimal distribution (MPLS tunnels anyone ;-) but the point of >>> fabric is that it's a fabric (i.e. load agnostic, cheap, no OPEX and ea= sily >>> scalable). Otherwise a good analogy would be that you like to build spe= cial >>> RAM chips for the type of data structures you are storing and we know h= ow >>> well that scales over time. We know now that within 3-4 years >>> characteristics of DC flows flip upside down without a sweat when peopl= e go >>> from server/client to microservices, from servers to containers and so = on >>> and so on. So if you can't predict your load all the time you need a >>> _regular_ topology where _regular_ is more of a mathematical than a >>> protocol discussion. Fabric analogy of "buy more RAM chips in Fry's and >>> just stick them in" applies here. So RIFT is done largely to serve a >>> well-known structure called a "lattice" (with some restrictions) since = we >>> need an "up" and "down". Things like hypercubes, thoroidal meshes and s= o on >>> and so on exist but CLOS won for a very good reason in history for that >>> kind of problems (once you move to NUMA other things win ;-) And if you >>> know your loads and your can heft the OPEX and you like to play with >>> protocols generally and if you can support the scale in terms of leaf F= IB >>> sizes, flooding, slower convergence & so on & so on and you run flat IG= P on >>> some kind of stuff that you build that doesn't even have to be regular = in >>> any sense. We spent many years solving THAT problem obviously and doing >>> something like RIFT to replace normal IGP is of limited interest IMO >>> (albeit certain aspects having to do with modern implemenation techniqu= es >>> may get us there one day but it's much less of pressing problem than >>> solving specialized DC routing well IMO again). >>> >>> 3. PS2: RIFT cannot build an "unsupported topology" no matter how you >>> cable (that's the point of it) or rather we have miscabling detection a= nd >>> do not form adjacencies when you read the draft carefully. That's your >>> "flash red light" and it comes included for free with my compliments ;= -) >>> ... Otherwise RFC1925 clause 10. >>> >>> Otherwise, if you have concrete charter points you'd like to add, be >>> more specific in your asks and we see what the list thinks after ... >>> >>> thanks >>> >>> --- tony >>> >>> >>> On Thu, Jan 11, 2018 at 1:30 AM, Robert Raszuk >>> wrote: >>> >>>> Hi, >>>> >>>> I have one little question/doubt on scalability point of RIFT ... >>>> >>>> Assume that someone would like to signal IPv6 prefix SID for Segment >>>> Routing in the underlay within RIFT. >>>> >>>> Wouldn't it result in amount of protocol state in full analogy to >>>> massive deaggregation - which as of today is designed to be very caref= ul >>>> and limited operation only at moments of failure(s) ? >>>> >>>> I sort of find it a bit surprising that RIFT draft does not provide >>>> encoding for SID distribution when it is positioned as an alternative = to >>>> other protocols (IGPs or BGP) which already provide ability to carry a= ll >>>> types of SIDs. >>>> >>>> Cheers, >>>> Robert. >>>> >>>> PS1: Horizontal links which were discussed could be installed to >>>> offload from fabric transit massive amount of data (ex: storage mirror= ing) >>>> directly between leafs or L3 TORs and not to be treated as "backup". >>>> >>>> PS2: Restricting any protocol to specific topologies seems like pretty >>>> slippery slope to me. In any case if protocol does that it should also >>>> contain self detection mechanism of "unsupported topology" and flash r= ed >>>> light in any NOC. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dcrouting mailing list >>>> Dcrouting@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dcrouting >>>> >>>> >>> >> > --001a114b2d02179ff90562ad4af1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tony,

> =E2=80=8B
if yo= u're willing to provision things correctly yourself via S-PGP.=C2=A0

I am not willing to do that. I would like routing to do it f= or me auto-magically. But yes you got the question right. I was asking for = shortcuts between last levels of fabric. Not so much between Node 111 &= Node 112 - but you said it is optional so ok.=C2=A0

<= div class=3D"gmail_default" style=3D"font-size:small">Side note: PGP abbrev. for vast majority of people means com= pletely different thing then what you defined it to mean locally in your dr= aft. I highly recommended you rename it in -05 version to PGD (policy guide= d destination(s) or PGR (policy guided reachability/routing).=C2=A0<= /div>

Now requirement to sw= itch off miscabling detection is not acceptable. You are stating that only = rift knows how should I cable my fabric ? And if I cable it some other way = it will detect it as miscabling ? I think in most cases of correct cables c= heck you actually define the intent then network detects if such intent is = met.=C2=A0

> Node112 can actually even go haywire

<= /div>
That may be not best property of a routing= protocol :)=C2=A0

Best,
R.

On Sat, Ja= n 13, 2018 at 7:16 PM, Tony Przygienda <tonysietf@gmail.com> wrote:
So I thought over your horizontal link case to shortcut= the spine levels
for some kind of traffic again and I t= hink the current draft actually
covers that
=E2=80=8B=E2=80=8B
if you're willing to pr= ovision things correctly yourself via S-PGP.
<= font size=3D"2">Let me see = whether we agree on this picture first:

.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------= -+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+
.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ N
.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |Spine 21|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |Spine 22|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |.Level 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-+--+-++=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-+--+-++=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 <-*-> E/W
.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |= =C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 P111/2|=C2=A0 |P121=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S v=
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ ^=C2=A0 ^ ^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0 | |
.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | |=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | |=C2=A0 | |
.=C2=A0 +--------------+ |=C2=A0 +-----------+=C2= =A0 | |=C2=A0 | +---------------+
.=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | |=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
. South +-----------------------------+ |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 All TIEs
.=C2=A0 0/0=C2=A0 0/0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0/0=C2=A0=C2=A0 +-----------------------------+=C2=A0=C2= =A0=C2=A0=C2=A0 |
.=C2=A0 v=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+=C2=A0=C2=A0=C2=A0 +<-0/0----------+= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0 |
.+-+----++ optional +-+----++=C2=A0=C2=A0=C2=A0=C2=A0 ++----= +-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++-----++.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | E/W link |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 +=3D=3D=3D=3D=3D+ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
.|Node111+----------+Node112|=C2=A0=C2=A0=C2=A0= =C2=A0 |Node121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |Node122|
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ++----+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++---+--+
.=C2=A0 |=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0 South=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0 |
.=C2=A0 |=C2=A0=C2=A0 +---0/0--->-----+ 0/0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 +----------------+ |
. 0/0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | |
.=C2=A0 |=C2=A0=C2=A0 +---<-0/0-= ----+ |=C2=A0 v=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 +--------------+ | |
.=C2=A0 v=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | |
.+-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +--+--+-+=C2=A0=C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +---+-+-+
.|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0 (L2L)=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Level 0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
.|Leaf111~~~~~~~~~~~~Leaf112|=C2= =A0=C2=A0=C2=A0=C2=A0 |Leaf121|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |Leaf122|
.+-+-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +-+---+-+=C2=A0=C2=A0=C2=A0=C2=A0 +--+--+-+=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-----+
.=C2=A0 +=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 /=C2=A0=C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +
.=C2=A0 Prefix111=C2=A0=C2=A0 Prefix112= =C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=C2=A0=C2=A0 Prefix121= =C2=A0=C2=A0=C2=A0 Prefix122
.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multi-homed
.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix
.= +---------- Pod 1 ---------+=C2=A0=C2=A0=C2=A0=C2=A0 +---------- Pod 2 ----= -----+

I assume here that what you ask for is the followin= g scenario:
a) POD1 being a compute generating very heavy loa= d towards storage in
=C2=A0=C2=A0 Prefix121.
=
b) traffic from POD1 NOT being balanced through the spines but taking
=C2=A0=C2=A0 a horizontal <= span style=3D"font-family:monospace,monospace">link Node112 to Node121 to r= each your storage in Prefix121
=C2=A0=C2=A0 to save band= width? or delay?
c) The key to ric= hes is -04 section
4.2.5.1. Northbound= SPF

<= font size=3D"2">=C2=A0 in the paragraph "Other south prefixes found wh= en crossing E-W link MAY be used IIF". Now, we could make it a MUST (b= ut it's really an implementation knob IMO) and what it says is that if = you are willing to inject an "S-PGP" @ Node121 for Prefix121 it w= ill get flooded to Node112 and Node112 will have a more specific match than= the default in N-SPF. From 121 normal RIFT takes over since the normal N-P= refix for Leaf121 kicks in on Node121. I assume Node112 policy on the ingre= ss is to not propagate the S-PGP south but use it for N-SPF only.


=

Observe that

a) you have to s= witch off miscabling detection for PoD# on those nodes since you are "= crossing PoDs illegally"

b) if you want whole Pod#1 to do that you either cable = Node111 to Node121 as well (which will load balance whole Pod#1 towards sto= rage without using Spine)=C2=A0 OR you propagate S-PGPs south towards leafs= (which will cost you leaf FIB of course but make sure ALL traffic to stora= ge goes over Node112 only).

c) Your forwarding on Node112 can actually even go haywi= re & load-balance some of the traffic to Prefix121 using this S-PGP ove= r Node121 and some still using the default route towards spine(which here i= s a blatant violation of LPM of course) and RIFT will work just fine (unles= s you loop yourself to death with PGPs you install) but that of course is a= deep rathole in itself. I just mention it to show why the "non-loopin= g" design is so important and makes for the shortcomings for the SPF o= n a fabric, predicted by the non-directional mesh property that Dijkstra so= lved in his time.

so?

= --- tony

=




<= /span>
=

On Thu, Jan 11, 2018 at 10:= 54 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,

Thx for = elaborating ...

Two small comments:

A) SID/SR use case in unde= rlay could be as simple as gracefully taking a fabric node out of service. = Not much OPEX needed if your NMS is decent. Otherwise in normal link state = I can do overload bit, in BGP number of solutions from shutdown to MED to L= P ... depending what is your BGP design. In RIFT how do you do that ? Note = that overlay (if such exist) does not help here.=C2=A0

B) For horizont= al links imagine you have servers with 40 GB ports to TOR. Then you have Nx= 100 GB from TOR up. You are going to oversubscribe on TOR (servers to fabri= c) most likely 2:1 .. 3:1 etc. So if I want to interconnect TORs because I = do know that servers behind those TORs need to talk to each other in a non = blocking fashion _and_ I have spare 100 GB ports on TORs having routing pro= tocol which does not allow me to do that seems pretty limited - wouldn'= t you agree ?=C2=A0

Thx,
R.







On Thu, Jan 11, 2018 at 6:40 PM, Tony Przygienda <<= a href=3D"mailto:tonysietf@gmail.com" target=3D"_blank">tonysietf@gmail.com= > wrote:
Robert, productive points, thanks for rais= ing them ... I go a bit in depth

1. I saw no _= real_ use-cases for SID in DC so far to be frank (once you run RIFT). The o= nly one that comes up regularly is egress engineering and that IMO is equiv= alent to SID=3Dleaf address (which could be a HV address of course once you= have RIFT all way down to server) so really, what's the point to have = a SID? It's probably much smarter to use IBGP & so on overlay to do= this kind of synchronization if needed since labels/SIDs become very usefu= l in overlay to distinguish lots stuff there like VPNs/services which you&#= 39;d carry e.g. in MPLSoUDP. In underlay just use the destination v4/v6 add= ress. Having said that, discussion always to be had if you pay me dinner ;-= -) and I know _how_ we can do SIDs in RIFT since I thought it through but a= gain, no _real_ use case so far. And if your only concern is to "shape= towards a prefix" we have PGP in the draft which doesn't need new= silicon ;-P And then ultimately, yes, if you really, really want a SID per= prefix everywhere then you'll carry=C2=A0 SIDs to everywhere since uni= cast SIDs are really just a glorified way to say "I have this non-aggr= eagable 20 bit IP host address" which architecturally is a very intere= sting proposition in terms of scaling (but then again, no account for taste= and RFC1925 clause 3 applies) ...=C2=A0 Your LSDB will be still much small= er, your SPF will be still simple on leaf in RIFT but your FIB will blow up= and anything changing on a leaf shakes all other leafs (unless you start t= o run pollicies to control distribution @ which point in time you start to = baby-sit your fabric @ high OPEX). One of the reasons to do per-prefix SID = would be non-ECMP anycast (where SIDs _are_ in fact usefull) but if you rea= d RIFT draft carefully you will observe that RIFT can do anycast without ne= ed for ECMP, i.e. true anycast in a sense and with that having anycast SID = serves no real purpose in RIFT and is actually generally much harder to do = since you need globally unique label blocks and so on ...=C2=A0

2. Horizontal links on CLOSes are not used that way normally all I saw s= ince your blocking goes to hell unless you provision some kind of really ma= ssive parallel links between ToRs _and_ understand your load. We _could_ bu= ild RIFT that way but you give up balancing through the fabric and loop-fre= e property in a sense (that's a longish discussion=C2=A0 and scaling si= nce now you have prefixes showing up all kind of crazy places instead of de= fault). I see enough demand, we get there ...=C2=A0 Otherwise RFC1925 claus= e 10 and 5.=C2=A0

3. PS1: Yes, lots of things &qu= ot;could" be done and then we "could" build a protocol to do= that and RFC1925 clause 7 and 8 applies. Such horizontal links, unless pro= visioned correctly will pretty much just ruin your blocking/loss on the fab= ric is the experience (which the math supports). In a sense if you know you= r big flows you can build a specialized topology to do the optimal distribu= tion (MPLS tunnels anyone ;-) but the point of fabric is that it's a fa= bric (i.e. load agnostic, cheap, no OPEX and easily scalable). Otherwise a = good analogy would be that you like to build special RAM chips for the type= of data structures you are storing and we know how well that scales over t= ime. We know now that within 3-4 years characteristics of DC flows flip ups= ide down without a sweat when people go from server/client to microservices= , from servers to containers and so on and so on. So if you can't predi= ct your load all the time you need a _regular_ topology where _regular_ is = more of a mathematical than a protocol discussion. Fabric analogy of "= buy more RAM chips in Fry's and just stick them in" applies here. = So RIFT is done largely to serve a well-known structure called a "latt= ice" (with some restrictions) since we need an "up" and &quo= t;down". Things like hypercubes, thoroidal meshes and so on and so on = exist but CLOS won for a very good reason in history for that kind of probl= ems (once you move to NUMA other things win ;-) And if you know your loads = and your can heft the OPEX and you like to play with protocols generally an= d if you can support the scale in terms of leaf FIB sizes, flooding, slower= convergence & so on & so on and you run flat IGP on some kind of s= tuff that you build that doesn't even have to be regular in any sense. = We spent many years solving THAT problem obviously and doing something like= RIFT to replace normal IGP is of limited interest IMO (albeit certain aspe= cts having to do with modern implemenation techniques may get us there one = day but it's much less of pressing problem than solving specialized DC = routing well IMO again).

3. PS2: RIFT cannot build= an "unsupported topology" no matter how you cable (that's th= e point of it) or rather we have miscabling detection and do not form adjac= encies when you read the draft carefully. That's your "flash red l= ight" and it comes included for free with my compliments=C2=A0 ;-) ...= Otherwise RFC1925 clause 10.

Otherwise, if you have concrete= charter points you'd like to add, be more specific in your asks and we= see what the list thinks after ...

thanks

--- tony


On Thu, Jan 11, 2018 at 1:30 AM, Robert = Raszuk <robert@raszuk.net> wrote:
Hi,

I have one little q= uestion/doubt on scalability point of RIFT ...=C2=A0

Assume that som= eone would like to signal IPv6 prefix SID for Segment Routing in the underl= ay within RIFT.=C2=A0

Wouldn't it result in amount of protocol sta= te in full analogy to massive deaggregation - which as of today is designed= to be very careful and limited operation only at moments of failure(s) ?= =C2=A0

I sort of find it a bit surprising that RIFT draft does not pro= vide encoding for SID distribution when it is positioned as an alternative = to other protocols (IGPs or BGP) which already provide ability to carry all= types of SIDs.=C2=A0

Cheers,
Robert.

PS1: Horizontal links wh= ich were discussed could be installed to offload from fabric transit massiv= e amount of data (ex: storage mirroring) directly between leafs or L3 TORs = and not to be treated as "backup".=C2=A0

PS2: Restricting an= y protocol to specific topologies seems like pretty slippery slope to me. I= n any case if protocol does that it should also contain self detection mech= anism of "unsupported topology" and flash red light in any NOC.= =C2=A0



_______________________________________________
Dcrouting mailing list
Dcrouting@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dcrouting<= /a>





--001a114b2d02179ff90562ad4af1-- From nobody Sat Jan 13 12:06:30 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956612DA45; Sat, 13 Jan 2018 12:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[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 O0Czzf8z_CFd; Sat, 13 Jan 2018 12:06:24 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C75A12785F; Sat, 13 Jan 2018 12:06:24 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id 81so6974156wmb.1; Sat, 13 Jan 2018 12:06:24 -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=M6tStLQI2nMWJkmv3cYNWsAz2C4w7C4yQit3Yek2nxM=; b=bjp42liFBKDgjbXHjRbJCNG7zjVdX9c8coJHTMAVkU7vbTjhkLTF3BKnWg8cl9oB5E eNamGvU0SaND0A+lVuDYT9bAfi3BqAbLZhRzFkOQTu1CzB0SBQoWJFa31BdchOjkjlGe LP1yFBSlKaWfzAGub++6REcXkPPUqAAKuq/0SriEiRmU26+Yo0E8md8IgqnAHGGgknfm ZgxLnSuRATfi8YF65t675rNztSY/sJamESkt0bxIiH8wxUOzcZYRVpyFjjFwdP0OFIlK YG43dhb7GMgK6wkpifzfxVF4LodO4jYIIseEFhiOJTVjbBk7fdQTTczRKyZ6plgGiimk 76Ng== 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=M6tStLQI2nMWJkmv3cYNWsAz2C4w7C4yQit3Yek2nxM=; b=hOtXTOuCPymc4VitxiS3RRJPv5m0ktu6agDNXcne62IcUnHq4MdavXYuUXAq31PAi4 VNiWTQAq+J7AoTFE0bkSagbd+ZfqiygpvaCtPlV3BBCqrZavMcVcB3wETADlDMM7bpHs xLsHMPaYMimdxLm0RCvyB4+ccp9jNDH/GBLmZkY582L20W71LRw9P64zLALlMLQPzQo5 CxcvV1lWJfRHPkA7eVZRJhxb/RkJrBlBbk+Ql5hI1MlGLB7CbxUJNfkK+79CaS3E7uax hw6EceSbkigjCrzGI0zwEEJog0d+s+iszVROzk/bGFrRp0J4Jx7M4XNhe947DnCXpGHR ny8Q== X-Gm-Message-State: AKwxyteHH3PH9cp1au6INBn/u3j4folZFC31DDZBhUP4tntN9vt9jf8j 1pqJ+x0HtcNgtBhuBqfpsh4AJVr+7iWUhhPkYaPsvw== X-Google-Smtp-Source: ACJfBosSCqJa79P15j3WrVpS9xs0vvhDNOAsuM56a+S7ar0hMu/L+t5hiMtcFIxzoJRDJ3HX1T2hArViavNSoSEef98= X-Received: by 10.80.148.217 with SMTP id t25mr3272264eda.121.1515873982606; Sat, 13 Jan 2018 12:06:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.148.4 with HTTP; Sat, 13 Jan 2018 12:05:42 -0800 (PST) In-Reply-To: References: From: Tony Przygienda Date: Sat, 13 Jan 2018 12:05:42 -0800 Message-ID: To: Robert Raszuk Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="f403045c231641f1bf0562adea23" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 20:06:26 -0000 --f403045c231641f1bf0562adea23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote: > Hi Tony, > > > =E2=80=8B > if you're willing to provision things correctly yourself via S-PGP. > > I am not willing to do that. I would like routing to do it for me > auto-magically. > The price of that would be that you can run strict SPF only then and loose all the non-equal cost forwarding, including true anycast. Plus, once you think that through in general sense you basically end up with host addresses everywhere (since if you use aggregates you'll blackhole on link failures). If you want to avoid SPF and host routes while still asking for all the things you ask, then as a very experienced and highly regarded architect here puts it to end such discussions "your problem is overly constrained" and there is no protocol/algebra whatsoever that will give you that ... > But yes you got the question right. I was asking for shortcuts between > last levels of fabric. Not so much between Node 111 & Node 112 - but you > said it is optional so ok. > > Side note: PGP abbrev. for vast majority of people means completely > different thing then what you defined it to mean locally in your draft. I > highly recommended you rename it in -05 version to PGD (policy guided > destination(s) or PGR (policy guided reachability/routing). > Sigh, I warned when the acronym was picked. Come up with something that is a word, the funnier the better, easier to remember for our brains that way. Can be 4 letters ;-) and will get you an Ack mention l;-) > > Now requirement to switch off miscabling detection is not acceptable. You > are stating that only rift knows how should I cable my fabric ? > No, it doesn't. You asked in your previous email for "red lights" when topology is built incorrectly and you have it. Now you don't want it. Both states cannot be true @ the same time unless you are entangled ;-) > Node112 can actually even go haywire > > That may be not best property of a routing protocol :) > > "haywire" is the wrong word. Rather, I should have said "it will even allow that". Now, why would you want the same src/dst pair sometimes shortcut on the horizontal link and sometimes go up to spine I can't imagine but you ask for all kind of very non-obvious things you seem to like so I'm just pointing the space of possibilities out to you ... -- tony --f403045c231641f1bf0562adea23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net" target=3D"_blank">robert@raszuk.net= > wrote:
Hi Tony,

> =E2=80=8B
if you're willing to provis= ion things correctly yourself via S-PGP.=C2=A0

I am not willing to do that. I would like routing = to do it for me auto-magically.

The price of that would be that you can run strict SPF only then a= nd loose all the non-equal cost forwarding, including true anycast. Plus, o= nce you think that through in general sense you basically end up with host = addresses everywhere (since if you use aggregates you'll blackhole on l= ink failures). If you want to avoid SPF and host routes while still asking = for all the things you ask, then as a very experienced and highly regarded = architect here puts it to end such discussions "your problem is overly= constrained" and there is no protocol/algebra whatsoever that will gi= ve you that ...
=C2=A0
<= div dir=3D"ltr">
But yes you got = the question right. I was asking for shortcuts between last levels of fabri= c. Not so much between Node 111 & Node 112 - but you said it is optiona= l so ok.=C2=A0

<= /span>
Side note: PGP abbrev. for vast majority of people means completely dif= ferent thing then what you defined it to mean locally in your draft. I high= ly recommended you rename it in -05 version to PGD (policy guided destinati= on(s) or PGR (policy guided reachability/routing).=C2=A0
=

Sigh, I warned when the acronym was picked= .=C2=A0 Come up with something that is a word, the funnier the better, easi= er to remember for our brains that way. Can be 4 letters ;-)=C2=A0 and will= get you an Ack mention l;-)
=C2=A0

Now requirement to switch off miscabling de= tection is not acceptable. You are stating that only rift knows how should = I cable my fabric ?

No,= it doesn't. You asked in your previous email for "red lights"= ; when topology is built incorrectly and you have it. Now you don't wan= t it. Both states cannot be true @ the same time unless you are entangled ;= -)=C2=A0

> Node112 can actually even go haywire

That may be not best property of a routing protocol :)=C2=A0


&quo= t;haywire" is the wrong word. Rather,=C2=A0 I should have said "i= t will even allow that". Now, why would you want the same src/dst pair= sometimes shortcut on the horizontal link and sometimes go up to spine I c= an't imagine but you ask for all kind of very non-obvious things you se= em to like so I'm just pointing the space of possibilities out to you .= ..


-- tony
--f403045c231641f1bf0562adea23-- From nobody Sat Jan 13 13:37:42 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD512DB6D; Sat, 13 Jan 2018 13:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxFdkbiV-xJb; Sat, 13 Jan 2018 13:37:34 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F74012DA6B; Sat, 13 Jan 2018 13:37:33 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id g21so8215473wrb.13; Sat, 13 Jan 2018 13:37:33 -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=Bjm5Czc5xjrY6UBeaM1gFgjOnLr74zNjwlIqSs7533A=; b=dAUhUHQCxBFwpePgRTGBGM9QfC+nXZbI2eyenyikuZBnLs021RGkgaC3zbb0tPQ+yS tSwtgLRWD0RSxHes/0L+/2cj2JhMKOV8zSfbzRHmtaFX7cNU/vnZ4Bwjnh2QcDxSwRXq QxhXhYCVVI5RH3PVkmqW9ietUvWxKHreV0mWkOjqagR7Pc2IGxjeFnVs06nv9xORDD4M yI24pNZYqXOVe9wTRH+acfqWjbGFV8Ylj5hs4BB1O83KG9IW9aJSAyrrQv1x+1m7H9gv 7V8jqswROQIc/hSe0gqWYEY/LHcrYVakxE9rM9j/wJeHx/QMZLGLk/gv3PmmlS/iYqg2 Qk7w== 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=Bjm5Czc5xjrY6UBeaM1gFgjOnLr74zNjwlIqSs7533A=; b=WkIIDsMbreIiCSHc+hqbZnfsQXxnB1Corpxv2qT6CynZLQAKYEyzb1Cex8zzWg4jgZ L8iFOvdTFRyOye66lAxFzvGYY6kMTfIH+FrVX8ailxoSlC0SfBRLeWFIeCfKUSz0qJwb vUACIE73CMe8Sa7it/Pf0WuzWSqW3aZr4YxydQnpp9yQti4JssRhkVlAZfICCPkeBOrJ yWaIIGrp6zQ/WSHd26kSGfkdPO74FoAb45tEumaomRT8nBvsA0SqwEtvILuXczr1eO55 4ukS48gaUs6AySfa9yLXVZowegWBRp58tS4ko3LSWUZyUoIjmrN5kY8YHYGKd7HMMjkM 1P0A== X-Gm-Message-State: AKwxytejqIx55lAu/DKEHeJpd1S/HJmpD40jY+GDLD3PYsh6mAg9IFF5 ZtxREMIjv4TzS/BSh1IRcYc5gTs+PndD6JmQWbI= X-Google-Smtp-Source: ACJfBotV/qx9Bu4066HISmr0EA5JqSt8IG/Uz8OjTM2eN+xycprV5DDnQZQgZ2cZJxA1IuukhX3seih8G0wJxYPf6Rs= X-Received: by 10.223.138.133 with SMTP id y5mr6035043wry.224.1515879451701; Sat, 13 Jan 2018 13:37:31 -0800 (PST) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.28.24.71 with HTTP; Sat, 13 Jan 2018 13:37:30 -0800 (PST) In-Reply-To: References: From: Robert Raszuk Date: Sat, 13 Jan 2018 22:37:30 +0100 X-Google-Sender-Auth: MvTUuWUvbGroOZvv_J7rPbzIbEc Message-ID: To: Tony Przygienda Cc: rift@ietf.org, spring@ietf.org, dcrouting@ietf.org Content-Type: multipart/alternative; boundary="001a113c2ca23db6000562af300b" Archived-At: Subject: Re: [spring] [Dcrouting] draft-przygienda-rift-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 21:37:36 -0000 --001a113c2ca23db6000562af300b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tony, > The price of that would be that you can run strict SPF only then and loose all the non-equal cost forwarding, including true anycast. 1. Did anyone really asked that we should refrain from running "strict SPF" in DCs ? Contrary I see group of folks keen on running it based on BGP-LS like feeds :) 2. Is non-ECMP fwd-ing a feature or a bug in DC fabric ? When I described to customers that with MPLS you can run non ECMP load balancing it was shock .. but in WAN there are some use cases for it. But in DC fabric - I doubt it. 3. True anycast is clearly possible with native link state and native distance vector. Why the new "hybrid" glue of both would not allow it ? Because it counts on massive aggregation - right ? > Plus, once you think that through in general sense you basically end up with host addresses everywhere (since if you use aggregates you'll blackhole on link failures). If you want to avoid SPF and host routes Host routes are just leaves so they hang off nodes and do not make SPF any harder. Besides I am not convinced that building flat underlays with 1M host routes is the right architecture - even if some folks ask you about it. Best, R. On Sat, Jan 13, 2018 at 9:05 PM, Tony Przygienda wrote: > > > On Sat, Jan 13, 2018 at 11:21 AM, Robert Raszuk wrote= : > >> Hi Tony, >> >> > =E2=80=8B >> if you're willing to provision things correctly yourself via S-PGP. >> >> I am not willing to do that. I would like routing to do it for me >> auto-magically. >> > > The price of that would be that you can run strict SPF only then and loos= e > all the non-equal cost forwarding, including true anycast. Plus, once you > think that through in general sense you basically end up with host > addresses everywhere (since if you use aggregates you'll blackhole on lin= k > failures). If you want to avoid SPF and host routes while still asking fo= r > all the things you ask, then as a very experienced and highly regarded > architect here puts it to end such discussions "your problem is overly > constrained" and there is no protocol/algebra whatsoever that will give y= ou > that ... > > >> But yes you got the question right. I was asking for shortcuts between >> last levels of fabric. Not so much between Node 111 & Node 112 - but you >> said it is optional so ok. >> >> Side note: PGP abbrev. for vast majority of people means completely >> different thing then what you defined it to mean locally in your draft. = I >> highly recommended you rename it in -05 version to PGD (policy guided >> destination(s) or PGR (policy guided reachability/routing). >> > > Sigh, I warned when the acronym was picked. Come up with something that > is a word, the funnier the better, easier to remember for our brains that > way. Can be 4 letters ;-) and will get you an Ack mention l;-) > > >> >> Now requirement to switch off miscabling detection is not acceptable. Yo= u >> are stating that only rift knows how should I cable my fabric ? >> > > No, it doesn't. You asked in your previous email for "red lights" when > topology is built incorrectly and you have it. Now you don't want it. Bot= h > states cannot be true @ the same time unless you are entangled ;-) > > > Node112 can actually even go haywire >> >> That may be not best property of a routing protocol :) >> >> > "haywire" is the wrong word. Rather, I should have said "it will even > allow that". Now, why would you want the same src/dst pair sometimes > shortcut on the horizontal link and sometimes go up to spine I can't > imagine but you ask for all kind of very non-obvious things you seem to > like so I'm just pointing the space of possibilities out to you ... > > > -- tony > --001a113c2ca23db6000562af300b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony,

> The price of that would be that you can run strict SPF only the= n and loose all the non-equal cost forwarding, including true anycast.=C2= =A0

1. Did anyone really asked t= hat we should refrain from running "strict SPF" in DCs ? Contrary= I see group of folks keen on running it based on BGP-LS like feeds :)=C2= =A0

2. Is non-ECMP fwd-ing a fea= ture or a bug in DC fabric ? When I described to customers that with MPLS y= ou can run non ECMP load balancing it was shock .. but in WAN there are som= e use cases for it. But in DC fabric - I doubt it.=C2=A0
=
3. True anycast is clearly possible with native link= state and native distance vector. Why the new "hybrid" glue of b= oth would not allow it ? Because it counts on massive aggregation - right ?= =C2=A0

> Plus, once you think t= hat through in general sense you basically end up with host addresses every= where (since if you use aggregates you'll blackhole on link failures). = If you want to avoid SPF and host routes

<= /div>
Host routes are just leaves so they hang off nodes and do not make SPF a= ny harder. Besides I am not convinced that building flat underlays with 1M = host routes is the right architecture - even if some folks ask you about it= .=C2=A0

= Best,
R.

<= /div>



On Sat, Jan 13, 2018 at 9:05 PM, To= ny Przygienda <tonysietf@gmail.com> wrote:


On Sat, Jan 13, 2018 at 11:21 AM, R= obert Raszuk <robert@raszuk.net> wrote:
Hi Tony,

> =E2=80=8B
if you're willing to provision things correctly yours= elf via S-PGP.=C2=A0

I am not willing to do that. I would like routing to d= o it for me auto-magically.
The price of that would be that you can run strict SPF only the= n and loose all the non-equal cost forwarding, including true anycast. Plus= , once you think that through in general sense you basically end up with ho= st addresses everywhere (since if you use aggregates you'll blackhole o= n link failures). If you want to avoid SPF and host routes while still aski= ng for all the things you ask, then as a very experienced and highly regard= ed architect here puts it to end such discussions "your problem is ove= rly constrained" and there is no protocol/algebra whatsoever that will= give you that ...
=C2=A0
But yes you got the question right. I was asking for shortcuts between = last levels of fabric. Not so much between Node 111 & Node 112 - but yo= u said it is optional so ok.=C2=A0

Side note: PGP abbrev. for vast majority of peopl= e means completely different thing then what you defined it to mean locally= in your draft. I highly recommended you rename it in -05 version to PGD (p= olicy guided destination(s) or PGR (policy guided reachability/routing).=C2= =A0

Sigh, I warne= d when the acronym was picked.=C2=A0 Come up with something that is a word,= the funnier the better, easier to remember for our brains that way. Can be= 4 letters ;-)=C2=A0 and will get you an Ack mention l;-)
=C2=A0
=

Now requirement to switch off miscabling detection is not acceptable. You = are stating that only rift knows how should I cable my fabric ?

No, it doesn't. You ask= ed in your previous email for "red lights" when topology is built= incorrectly and you have it. Now you don't want it. Both states cannot= be true @ the same time unless you are entangled ;-)=C2=A0

=
> Node112 can actually even go haywire

That m= ay be not best property of a routing protocol :)=C2=A0


"haywire&qu= ot; is the wrong word. Rather,=C2=A0 I should have said "it will even = allow that". Now, why would you want the same src/dst pair sometimes s= hortcut on the horizontal link and sometimes go up to spine I can't ima= gine but you ask for all kind of very non-obvious things you seem to like s= o I'm just pointing the space of possibilities out to you ...
=

-- tony

--001a113c2ca23db6000562af300b-- From nobody Thu Jan 25 01:26:08 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5338312D868; Thu, 25 Jan 2018 01:26:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151687236730.15838.4571722029981060199@ietfa.amsl.com> Date: Thu, 25 Jan 2018 01:26:07 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-15.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 09:26:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Les Ginsberg Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-15.txt Pages : 31 Date : 2018-01-25 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 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15 https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 25 01:28:56 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A91412E87B for ; Thu, 25 Jan 2018 01:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 I0CtkGHx-71K for ; Thu, 25 Jan 2018 01:28:52 -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 8E0AC12D969 for ; Thu, 25 Jan 2018 01:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3291; q=dns/txt; s=iport; t=1516872532; x=1518082132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pKT7WEtZH2Lu9NwPlIIFc3wTGCMb5KlcFajSwVe2yxM=; b=fh3VpqtAT+dpvJpmv3/ZctFkgOonJwxEAmFXh/o9wc2Iz7eUXhi5Hw0N Z1gfl+MTt6BBpTRsY7o4ILGZuYn2noq1rZ4oF1o1GgFzKMEAo0yGZG8Hh GmfsVFyBO2FDMhSdWlW5eFsHJNEXhvttMSitOcZLUTV4IvwxgS5NHScYL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAQCqomla/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB416jmiCApdDghcKGA2ER08ChF1UGAEBAQEBAQEBAms?= =?us-ascii?q?dC4UjAQEBBAEBODQLDAQCAQgRAQMBAR8JBycLFAMGCAIEDgUIii0Qt0eKYAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2EUYIVgVeBaIMugy8BAQIBAReHUgWkCQKIE41?= =?us-ascii?q?EgiRnhTiLa41aiVECERkBgTsBHzmBUHAVGSSCKgmETniNNIEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,411,1511827200"; d="scan'208";a="60881850" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 09:28:51 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w0P9Sp1k015022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jan 2018 09:28:51 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.1320.4; Thu, 25 Jan 2018 03:28:51 -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.1320.000; Thu, 25 Jan 2018 03:28:50 -0600 From: "Les Ginsberg (ginsberg)" To: "spring@ietf.org" CC: Ben Campbell , Kathleen Moriarty , Adam Roach , "Alvaro Retana" Thread-Topic: [spring] I-D Action: draft-ietf-spring-segment-routing-15.txt Thread-Index: AQHTlb6OB/On6d8/8ESWkeDB/TiEOKOEUbFw Date: Thu, 25 Jan 2018 09:28:50 +0000 Message-ID: References: <151687236730.15838.4571722029981060199@ietfa.amsl.com> In-Reply-To: <151687236730.15838.4571722029981060199@ietfa.amsl.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.37.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-15.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jan 2018 09:28:54 -0000 A new version has been posted which addresses all outstanding comments. Specifically comments from: Ben Campbell Adam Roach Kathleen Moriarty Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, January 25, 2018 1:26 AM > To: i-d-announce@ietf.org > Cc: spring@ietf.org > Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-15.txt >=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 WG o= f > the IETF. >=20 > Title : Segment Routing Architecture > Authors : Clarence Filsfils > Stefano Previdi > Les Ginsberg > Bruno Decraene > Stephane Litkowski > Rob Shakir > Filename : draft-ietf-spring-segment-routing-15.txt > Pages : 31 > Date : 2018-01-25 >=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 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 are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15 > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-1= 5 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-15 >=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 Fri Jan 26 03:15:22 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0079512D960 for ; Fri, 26 Jan 2018 03:15:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151696532099.24351.5365099532065044079.idtracker@ietfa.amsl.com> Date: Fri, 26 Jan 2018 03:15:20 -0800 From: IETF Secretariat Archived-At: Subject: [spring] Milestones changed for spring WG X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 11:15:21 -0000 Changed milestone "One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.", resolved as "Done". Changed milestone "Specification of a high-level abstract architecture for SPRING.", resolved as "Done". Changed milestone "One or more control protocol extensions requirements documents.", resolved as "Done". Changed milestone "Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols.", resolved as "Done". URL: https://datatracker.ietf.org/wg/spring/about/ From nobody Fri Jan 26 03:18:43 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7C12D779; Fri, 26 Jan 2018 03:18:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: martin.vigoureux@nokia.com, spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151696552115.24343.14078154318231475765.idtracker@ietfa.amsl.com> Date: Fri, 26 Jan 2018 03:18:41 -0800 Archived-At: Subject: [spring] spring - New Meeting Session Request for IETF 101 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 11:18:41 -0000 A new meeting session request has just been submitted by Martin Vigoureux, a Chair of the spring working group. --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Martin Vigoureux Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: mpls isis ospf sfc Second Priority: bess rtgwg People who must be present: Bruno Decraene Martin Vigoureux Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jan 27 23:15:21 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4A0129516; Sat, 27 Jan 2018 23:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RXGJ0EvBKh3Q; Sat, 27 Jan 2018 23:15:12 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD0F127AD4; Sat, 27 Jan 2018 23:15:12 -0800 (PST) Received: from [192.168.1.10] (unknown [119.94.167.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 30F9F1801569; Sun, 28 Jan 2018 08:15:05 +0100 (CET) From: Loa Andersson To: "mpls@ietf.org" Cc: draft-ietf-mpls-spring-entropy-label@ietf.org, "mpls-chairs@ietf.org" , "spring@ietf.org" References: <7a3329e1-fd00-7af0-f951-09916fcaa28a@pi.nu> Message-ID: <0317dbec-5f0c-0fea-d595-491daf5dd99a@pi.nu> Date: Sun, 28 Jan 2018 15:14:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <7a3329e1-fd00-7af0-f951-09916fcaa28a@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Closed -- working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 07:15:15 -0000 Working Group, This working group last call is closed, we have support to request publication. Authors, should verify that they are ready to go ahead with the current version, or indicate that they want to do updates. The document shepherd will start preparing the shepherd write-up. /Loa On 2017-12-08 21:17, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on draft- > ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > Since this is a second wglc on this document, the current document > address all comments all comments from the previous wglc, but it is > more than 18 months since the previous wqglc, we have decided to do > a full two week call. > > There are no IPRs disclosed against draft-ietf-mpls-spring-entropy- > label. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any other IPRs that relates > to this document. > > This working group last call ends December 22, 2017. > > This wglc is copied to the SPRING wg mailing list, please address all > comments to mpls@ietf.org. > > > /Loa > MPLS wg co-chair -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Jan 28 22:48:26 2018 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0612C131696; Sun, 28 Jan 2018 22:48:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151720849997.3003.15240198792779407607@ietfa.amsl.com> Date: Sun, 28 Jan 2018 22:48:20 -0800 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-mpls-anycast-segments-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 06:48:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Anycast Segments in MPLS based Segment Routing Authors : Pushpasis Sarkar Hannes Gredler Clarence Filsfils Stefano Previdi Bruno Decraene Martin Horneffer Filename : draft-ietf-spring-mpls-anycast-segments-02.txt Pages : 19 Date : 2018-01-28 Abstract: Instead of forwarding to a specific device or to all devices in a group, anycast addresses, let network devices forward a packet to (or steer it through) one or more topologically nearest devices in a specific group of network devices. The use of anycast addresses has been extended to the Segment Routing (SR) network, wherein a group of SR-capable devices can represent a anycast address, by having the same Segment Routing Global Block (SRGB) provisioned on all the devices and each one of them advertising the same anycast prefix segment (or Anycast SID). This document describes a proposal for implementing anycast prefix segments in a MPLS-based SR network, without the need to have the same SRGB block (label ranges) provisioned across all the member devices in the group. Each node can be provisioned with a separate SRGB from the label range supported by the specfic hardware platform. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02 https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-anycast-segments-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-mpls-anycast-segments-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 28 22:59:34 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9A1316B9 for ; Sun, 28 Jan 2018 22:59:33 -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 D2jDa08TCdrk for ; Sun, 28 Jan 2018 22:59:26 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4161316B8 for ; Sun, 28 Jan 2018 22:59:26 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id f34so6480746ioi.13 for ; Sun, 28 Jan 2018 22:59:26 -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; bh=Tz4BwpEBEZ0BnKMIz74/C7uLdzVGBE0m49W7qIXGlIc=; b=T89vLrBUv7GbUwmhz2EnNWaI5/1Zc0i0X4UyQbB3w38QD0JxByAN0PQt5hcTWkANPf I0eRXDI6Z2+oR/Gd6SeDmz34OWWba2UUi46o8eugtYti6siPJOOR97pTAWyOz+38ulm5 DkIugCxmg5eI2eV6RfqnwiDGmAo5aAicZtqNyx0kJib5cz5ybJaaPoIlCT6DLA++QdD/ aNFYhUcA+9RUIkl8mKcYqiKEwU1XIyEXi2OXagCPTCPmSY43GJtiBhKTIyPux3UWRUe4 Kkd6waZnYnWY6aG3pWTpJApIxdKUnUHUI04n4/j4wTew5f93s3oyn4PyOUTnSYzXC0Vg PdJg== 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; bh=Tz4BwpEBEZ0BnKMIz74/C7uLdzVGBE0m49W7qIXGlIc=; b=REcjN3szMZiL+1eyASt1hvRnMXBguVx/R46k3/hFRjwGj7sJRDOwUMjRd0E2OWnjTK U89PxWZ8m72k1Mfl+3kxaVl/w1nPJ6HnTdJOF/nJ5Yb05d1/z96v337nH6WXGVNbfMBT 71YhRX8FXwe07ecaINsduUsMwRqGkWi9Mqj3gc7QMoxw+IJFpO7FlehRRVfrhcrtJC99 HHJv7lUc2p5Gy4aeutaSzPL3Ix1ts5iLnHu0WNRKtQSuNTi0eYla1Lx8aBvCmtR501zz z60St9sQwV1RfFTSFMN7n04ocsBTe7k3V3mGLPM2/rCYf07FGFpY4kPZdrvOJ9UVGYQt 45NQ== X-Gm-Message-State: AKwxytd2cXkgTO21CwXxOjXgHzL+NAyAW0esVF39JkzHaO8VdMSTSAc+ T/Ek+VRZXkdgCEqL0MnMDLKhsW6GWf3Bv2SHdpI= X-Google-Smtp-Source: AH8x226fCeEliMkxcbU99mHycvKFoEvlhPlcLxfQNLnGDCV6PafDj2bvYh7ZEkNy7OcXfg0tKb/AKari1XmLy6jinFk= X-Received: by 10.107.182.197 with SMTP id g188mr11652321iof.77.1517209165250; Sun, 28 Jan 2018 22:59:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.150.101 with HTTP; Sun, 28 Jan 2018 22:59:24 -0800 (PST) In-Reply-To: <151720849997.3003.15240198792779407607@ietfa.amsl.com> References: <151720849997.3003.15240198792779407607@ietfa.amsl.com> From: Pushpasis Sarkar Date: Mon, 29 Jan 2018 12:29:24 +0530 Message-ID: To: spring@ietf.org Content-Type: multipart/alternative; boundary="001a114ac58858435c0563e4c9da" Archived-At: Subject: [spring] Fwd: I-D Action: draft-ietf-spring-mpls-anycast-segments-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 06:59:33 -0000 --001a114ac58858435c0563e4c9da Content-Type: text/plain; charset="UTF-8" Hi All, I have uploaded the latest version addressing some of the comments received from some of the WG members. Please review the document and let us know if you have anymore comments. Hi Chairs, We (the authors) believe that the document is ready for WG Last call. Request to get the Last call started on this document. Thanks and Best regards, -Pushpasis ---------- Forwarded message ---------- From: Date: Mon, Jan 29, 2018 at 12:18 PM Subject: [spring] I-D Action: draft-ietf-spring-mpls-anycast-segments-02.txt To: i-d-announce@ietf.org Cc: spring@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Anycast Segments in MPLS based Segment Routing Authors : Pushpasis Sarkar Hannes Gredler Clarence Filsfils Stefano Previdi Bruno Decraene Martin Horneffer Filename : draft-ietf-spring-mpls-anycast-segments-02.txt Pages : 19 Date : 2018-01-28 Abstract: Instead of forwarding to a specific device or to all devices in a group, anycast addresses, let network devices forward a packet to (or steer it through) one or more topologically nearest devices in a specific group of network devices. The use of anycast addresses has been extended to the Segment Routing (SR) network, wherein a group of SR-capable devices can represent a anycast address, by having the same Segment Routing Global Block (SRGB) provisioned on all the devices and each one of them advertising the same anycast prefix segment (or Anycast SID). This document describes a proposal for implementing anycast prefix segments in a MPLS-based SR network, without the need to have the same SRGB block (label ranges) provisioned across all the member devices in the group. Each node can be provisioned with a separate SRGB from the label range supported by the specfic hardware platform. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-anycast-segments/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02 https://datatracker.ietf.org/doc/html/draft-ietf-spring- mpls-anycast-segments-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-mpls-anycast-segments-02 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 --001a114ac58858435c0563e4c9da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have uploaded the latest vers= ion addressing some of the comments received from some of the WG members. P= lease review the document and let us know if you have anymore comments.=C2= =A0

Hi Chairs,

We (the au= thors) believe that the document is ready for WG Last call. Request to get = the Last call started on this document.

Thanks and= Best regards,
-Pushpasis


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jan= 29, 2018 at 12:18 PM
Subject: [spring] I-D Action: draft-ietf-spring-mp= ls-anycast-segments-02.txt
To: = i-d-announce@ietf.org
Cc: spring@= ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Source Packet Routing in Networking WG of = the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Anycast Segments in MPLS based Segment Routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Push= pasis Sarkar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Gredler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Clarence Filsfils
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Stefano Previdi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bruno Decraene
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Martin Horneffer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-spring-mpls-anycast-segments-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-01-28

Abstract:
=C2=A0 =C2=A0Instead of forwarding to a specific device or to all devices i= n a
=C2=A0 =C2=A0group, anycast addresses, let network devices forward a packet= to (or
=C2=A0 =C2=A0steer it through) one or more topologically nearest devices in= a
=C2=A0 =C2=A0specific group of network devices.=C2=A0 The use of anycast ad= dresses has
=C2=A0 =C2=A0been extended to the Segment Routing (SR) network, wherein a g= roup of
=C2=A0 =C2=A0SR-capable devices can represent a anycast address, by having = the
=C2=A0 =C2=A0same Segment Routing Global Block (SRGB) provisioned on all th= e
=C2=A0 =C2=A0devices and each one of them advertising the same anycast pref= ix
=C2=A0 =C2=A0segment (or Anycast SID).

=C2=A0 =C2=A0This document describes a proposal for implementing anycast pr= efix
=C2=A0 =C2=A0segments in a MPLS-based SR network, without the need to have = the
=C2=A0 =C2=A0same SRGB block (label ranges) provisioned across all the memb= er
=C2=A0 =C2=A0devices in the group.=C2=A0 Each node can be provisioned with = a separate
=C2=A0 =C2=A0SRGB from the label range supported by the specfic hardware pl= atform.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.or= g/doc/draft-ietf-spring-mpls-anycast-segments/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02
https://datatracker.= ietf.org/doc/html/draft-ietf-spring-mpls-anycast-segments-02<= br>
A diff from the previous version is available at:
https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-spring-mpls-anycast-segments-02


Please note that it may take a couple of minutes from the time of submissio= n
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

--001a114ac58858435c0563e4c9da-- From nobody Mon Jan 29 09:02:58 2018 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42F120721; Mon, 29 Jan 2018 09:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 N2zRjm29Afj6; Mon, 29 Jan 2018 09:02:50 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC1212F2B0; Mon, 29 Jan 2018 09:02:32 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 3E3156157B; Mon, 29 Jan 2018 18:02:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 1F1CC18005A; Mon, 29 Jan 2018 18:02:31 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0382.000; Mon, 29 Jan 2018 18:02:30 +0100 From: To: Loa Andersson , "mpls@ietf.org" CC: "draft-ietf-mpls-spring-entropy-label@ietf.org" , "mpls-chairs@ietf.org" , "spring@ietf.org" Thread-Topic: Closed -- working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHTcCbgMm34xFFdNEKvyWEBj3Zyi6OJHlcAgAJHE4A= Date: Mon, 29 Jan 2018 17:02:30 +0000 Message-ID: <7660_1517245351_5A6F53A7_7660_73_1_9E32478DFA9976438E7A22F69B08FF921EB34098@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <7a3329e1-fd00-7af0-f951-09916fcaa28a@pi.nu> <0317dbec-5f0c-0fea-d595-491daf5dd99a@pi.nu> In-Reply-To: <0317dbec-5f0c-0fea-d595-491daf5dd99a@pi.nu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Closed -- working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jan 2018 17:02:52 -0000 SGkgTG9hLA0KDQpXZSBhcmUgcmVhZHkgdG8gZ28gd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uLiAN Cg0KQnJnZHMsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb2EgQW5kZXJz c29uIFttYWlsdG86bG9hQHBpLm51XSANClNlbnQ6IFN1bmRheSwgSmFudWFyeSAyOCwgMjAxOCAw ODoxNQ0KVG86IG1wbHNAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJv cHktbGFiZWxAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmcN ClN1YmplY3Q6IENsb3NlZCAtLSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwNCg0KV29ya2luZyBHcm91cCwNCg0KVGhpcyB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBpcyBjbG9zZWQsIHdlIGhhdmUgc3VwcG9ydCB0byByZXF1ZXN0 IHB1YmxpY2F0aW9uLg0KDQpBdXRob3JzLCBzaG91bGQgdmVyaWZ5IHRoYXQgdGhleSBhcmUgcmVh ZHkgdG8gZ28gYWhlYWQgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uLCBvciBpbmRpY2F0ZSB0aGF0 IHRoZXkgd2FudCB0byBkbyB1cGRhdGVzLg0KDQpUaGUgZG9jdW1lbnQgc2hlcGhlcmQgd2lsbCBz dGFydCBwcmVwYXJpbmcgdGhlIHNoZXBoZXJkIHdyaXRlLXVwLg0KDQovTG9hDQoNCk9uIDIwMTct MTItMDggMjE6MTcsIExvYSBBbmRlcnNzb24gd3JvdGU6DQo+IFdvcmtpbmcgR3JvdXAsDQo+IA0K PiBUaGlzIGlzIHRvIGluaXRpYXRlIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwg b24gZHJhZnQtIA0KPiBpZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwuDQo+IA0KPiBQbGVh c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlzdCAobXBsc0Bp ZXRmLm9yZykuDQo+IA0KPiBTaW5jZSB0aGlzIGlzIGEgc2Vjb25kIHdnbGMgb24gdGhpcyBkb2N1 bWVudCwgdGhlIGN1cnJlbnQgZG9jdW1lbnQgDQo+IGFkZHJlc3MgYWxsIGNvbW1lbnRzIGFsbCBj b21tZW50cyBmcm9tIHRoZSBwcmV2aW91cyB3Z2xjLCBidXQgaXQgaXMgDQo+IG1vcmUgdGhhbiAx OCBtb250aHMgc2luY2UgdGhlIHByZXZpb3VzIHdxZ2xjLCB3ZSBoYXZlIGRlY2lkZWQgdG8gZG8g YSANCj4gZnVsbCB0d28gd2VlayBjYWxsLg0KPiANCj4gVGhlcmUgYXJlIG5vIElQUnMgZGlzY2xv c2VkIGFnYWluc3QgZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LSANCj4gbGFiZWwuDQo+ IA0KPiBBbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyBoYXZlIHN0YXRlZCBvbiB0aGUg d29ya2luZyBncm91cCANCj4gbWFpbGluZyBsaXN0IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9m IGFueSBvdGhlciBJUFJzIHRoYXQgcmVsYXRlcyB0byANCj4gdGhpcyBkb2N1bWVudC4NCj4gDQo+ IFRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBEZWNlbWJlciAyMiwgMjAxNy4NCj4g DQo+IFRoaXMgd2dsYyBpcyBjb3BpZWQgdG8gdGhlIFNQUklORyB3ZyBtYWlsaW5nIGxpc3QsIHBs ZWFzZSBhZGRyZXNzIGFsbCANCj4gY29tbWVudHMgdG8gbXBsc0BpZXRmLm9yZy4NCj4gDQo+IA0K PiAvTG9hDQo+IE1QTFMgd2cgY28tY2hhaXINCg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAcGkubnUNClNlbmlvciBNUExTIEV4cGVydA0K SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIx IDY0DQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=