From nobody Tue May 5 12:13:25 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C03113A045B; Tue, 5 May 2020 11:58:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joerg Ott via Datatracker To: Cc: draft-ietf-lsvr-l3dl.all@ietf.org, lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158870511665.7532.2079643708622987385@ietfa.amsl.com> Reply-To: Joerg Ott Date: Tue, 05 May 2020 11:58:36 -0700 Archived-At: X-Mailman-Approved-At: Tue, 05 May 2020 12:13:24 -0700 Subject: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 18:58:37 -0000 Reviewer: Joerg Ott Review result: Ready with Issues The draft describes a peer/neighbour discovery mechanisms for large-scale L2/L3 topologies in data centres. The aim is provide a protocol by means of which the involved nodes can learn about other nodes connected to their (broadcast or point-to-point) L2 links and about their respectively support encapsulation schemes, identifiers, L2/L3 addresses, etc. This information is then provided to a higher layer for further processing. The document is well written and fairly easy to follow, but could benefit from a bit of extra context and target application domain in the introduction. E.g., explaining explicitly who would talk L3DL to whom. >From a transport perspective, I see three potential issues that deserve clarification or reconsideration: 1. Section 10 spells out a default HELLO interval of 60 seconds. With a large broadcast domain, this may create quite a bit of traffic. While this may not be an issue in well-provisioned data center networks, a remark about sensible value ranges and the implications may be worthwhile. Just to provide some guidelines to implementers (who want to offer choices) and operators (who pick them). 2. Section 10 also suggest that in response to HELLO messages nodes will issue OPEN PDUs to newly discovered peers. This appears to bear the clear risk of an OPEN implosion when many system come up at the same time. Shouldn't guidance be given to avoid repeated traffic surges and possible losses and thus unnecessary delays? (I noted that other places foresee exponential backoff when retransmitting OPEN and other ACKed PDUs). 3. When the protocol applies fragmentation, should there be a note on preventing bursts? Other notes: Section 7 on the checksum needs more detail. It also talks about a "suggested" algorithm but this should be clearly mandated or way to choose one by means of configuration for a complete data centre would need to be made explicit. I also assume that the pseudo code on p.11 would benefit from a leader '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might fill the high order bits with '1's, which is clearly not intended. Section 11, p.17, second to last para ("If a properly authenticated..."). From the text, it is unclear what is meant by an "OPEN with the Serial Number of the last data received". I am curious about the error code, providing 16 bits for additional explanation. Why not a text field? Also wondering if repeated retries (due to failure, not lost packets) could yield fast repeated transmissions. Section 15, should the KEEPALIVE interval have suggested (lower) bounds? At the top of p.26, it says "One per second is the default", the previous page at the bottom refers to the inter-KEEPALIVE interval of ten seconds. Not sure if the two are the same, I suppose so. If they are, the numbers should match. If they are not, we'll need some extra text to explain the difference. Nits: There are two spellings of "Encapsulation", capitalised and lower case. Use one consistently. p10, first para: comprise -> comprising From nobody Tue May 5 15:45:22 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6773A0C08; Tue, 5 May 2020 15:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B9ivpsDKtAb; Tue, 5 May 2020 15:45:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 775013A0C09; Tue, 5 May 2020 15:45:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jW6JN-0001bk-3s; Tue, 05 May 2020 22:45:13 +0000 Date: Tue, 05 May 2020 15:45:09 -0700 Message-ID: From: Randy Bush To: Joerg Ott via Datatracker Cc: , draft-ietf-lsvr-l3dl.all@ietf.org, lsvr@ietf.org In-Reply-To: <158870511665.7532.2079643708622987385@ietfa.amsl.com> References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 22:45:20 -0000 wow! thanks! great review. unfortunately the wg has gone dormant, so we have let the l3dl drafts expire. should it ever wake up, i will happly merge in your excellent suggestions. again, thank you! randy > Reviewer: Joerg Ott > Review result: Ready with Issues > > The draft describes a peer/neighbour discovery mechanisms for large-scale L2/L3 > topologies in data centres. The aim is provide a protocol by means of which the > involved nodes can learn about other nodes connected to their (broadcast or > point-to-point) L2 links and about their respectively support encapsulation > schemes, identifiers, L2/L3 addresses, etc. This information is then provided > to a higher layer for further processing. > > The document is well written and fairly easy to follow, but could benefit from > a bit of extra context and target application domain in the introduction. E.g., > explaining explicitly who would talk L3DL to whom. > > >From a transport perspective, I see three potential issues that deserve > clarification or reconsideration: > > 1. Section 10 spells out a default HELLO interval of 60 seconds. With a large > broadcast domain, this may create quite a bit of traffic. While this may not be > an issue in well-provisioned data center networks, a remark about sensible > value ranges and the implications may be worthwhile. Just to provide some > guidelines to implementers (who want to offer choices) and operators (who pick > them). > > 2. Section 10 also suggest that in response to HELLO messages nodes will issue > OPEN PDUs to newly discovered peers. This appears to bear the clear risk of an > OPEN implosion when many system come up at the same time. Shouldn't guidance be > given to avoid repeated traffic surges and possible losses and thus unnecessary > delays? (I noted that other places foresee exponential backoff when > retransmitting OPEN and other ACKed PDUs). > > 3. When the protocol applies fragmentation, should there be a note on > preventing bursts? > > Other notes: > Section 7 on the checksum needs more detail. It also talks about a "suggested" > algorithm but this should be clearly mandated or way to choose one by means of > configuration for a complete data centre would need to be made explicit. I also > assume that the pseudo code on p.11 would benefit from a leader '0' in > 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might fill the high > order bits with '1's, which is clearly not intended. > > Section 11, p.17, second to last para ("If a properly authenticated..."). From > the text, it is unclear what is meant by an "OPEN with the Serial Number of the > last data received". > > I am curious about the error code, providing 16 bits for additional > explanation. Why not a text field? Also wondering if repeated retries (due to > failure, not lost packets) could yield fast repeated transmissions. > > Section 15, should the KEEPALIVE interval have suggested (lower) bounds? > At the top of p.26, it says "One per second is the default", the previous page > at the bottom refers to the inter-KEEPALIVE interval of ten seconds. Not sure > if the two are the same, I suppose so. If they are, the numbers should match. > If they are not, we'll need some extra text to explain the difference. > > Nits: > There are two spellings of "Encapsulation", capitalised and lower case. Use one > consistently. p10, first para: comprise -> comprising > > > From nobody Wed May 6 00:35:36 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C253A0D72; Tue, 5 May 2020 22:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZberTSCV1PJ; Tue, 5 May 2020 22:30:42 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489483A0C4A; Tue, 5 May 2020 22:30:40 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id CD60B1C084C; Wed, 6 May 2020 07:30:37 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 12B491C0843; Wed, 6 May 2020 07:30:34 +0200 (CEST) (Extended-Queue-bit tech_kfyli@fff.in.tum.de) To: Randy Bush , Joerg Ott via Datatracker Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> From: Joerg Ott Message-ID: Date: Wed, 6 May 2020 07:30:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 06 May 2020 00:35:35 -0700 Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 05:30:45 -0000 Oops. I was told this was an "early" review, not a "late" one :-) Was a good read in any case... Cheers, Jörg On 06.05.20 00:45, Randy Bush wrote: > wow! thanks! great review. > > unfortunately the wg has gone dormant, so we have let the l3dl drafts > expire. should it ever wake up, i will happly merge in your excellent > suggestions. > > again, thank you! > > randy > >> Reviewer: Joerg Ott >> Review result: Ready with Issues >> >> The draft describes a peer/neighbour discovery mechanisms for large-scale L2/L3 >> topologies in data centres. The aim is provide a protocol by means of which the >> involved nodes can learn about other nodes connected to their (broadcast or >> point-to-point) L2 links and about their respectively support encapsulation >> schemes, identifiers, L2/L3 addresses, etc. This information is then provided >> to a higher layer for further processing. >> >> The document is well written and fairly easy to follow, but could benefit from >> a bit of extra context and target application domain in the introduction. E.g., >> explaining explicitly who would talk L3DL to whom. >> >> >From a transport perspective, I see three potential issues that deserve >> clarification or reconsideration: >> >> 1. Section 10 spells out a default HELLO interval of 60 seconds. With a large >> broadcast domain, this may create quite a bit of traffic. While this may not be >> an issue in well-provisioned data center networks, a remark about sensible >> value ranges and the implications may be worthwhile. Just to provide some >> guidelines to implementers (who want to offer choices) and operators (who pick >> them). >> >> 2. Section 10 also suggest that in response to HELLO messages nodes will issue >> OPEN PDUs to newly discovered peers. This appears to bear the clear risk of an >> OPEN implosion when many system come up at the same time. Shouldn't guidance be >> given to avoid repeated traffic surges and possible losses and thus unnecessary >> delays? (I noted that other places foresee exponential backoff when >> retransmitting OPEN and other ACKed PDUs). >> >> 3. When the protocol applies fragmentation, should there be a note on >> preventing bursts? >> >> Other notes: >> Section 7 on the checksum needs more detail. It also talks about a "suggested" >> algorithm but this should be clearly mandated or way to choose one by means of >> configuration for a complete data centre would need to be made explicit. I also >> assume that the pseudo code on p.11 would benefit from a leader '0' in >> 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might fill the high >> order bits with '1's, which is clearly not intended. >> >> Section 11, p.17, second to last para ("If a properly authenticated..."). From >> the text, it is unclear what is meant by an "OPEN with the Serial Number of the >> last data received". >> >> I am curious about the error code, providing 16 bits for additional >> explanation. Why not a text field? Also wondering if repeated retries (due to >> failure, not lost packets) could yield fast repeated transmissions. >> >> Section 15, should the KEEPALIVE interval have suggested (lower) bounds? >> At the top of p.26, it says "One per second is the default", the previous page >> at the bottom refers to the inter-KEEPALIVE interval of ten seconds. Not sure >> if the two are the same, I suppose so. If they are, the numbers should match. >> If they are not, we'll need some extra text to explain the difference. >> >> Nits: >> There are two spellings of "Encapsulation", capitalised and lower case. Use one >> consistently. p10, first para: comprise -> comprising >> >> >> > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > From nobody Wed May 6 01:22:14 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C6A3A084A; Wed, 6 May 2020 01:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L01MdQLmP-FW; Wed, 6 May 2020 01:22:10 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80139.outbound.protection.outlook.com [40.107.8.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69BA3A084E; Wed, 6 May 2020 01:22:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XgtNbQFk9CvOeVJYkKR8kUMHV1EB2Wu/lqFqtgr66L+/xsvNk7W2HXUKNtzB5KUwGwKO6rECj2NnAiB396wgkRF7jLj1GqGTPz0gy4VBPM7IJrm0zuSURCr/TFcSuYIIctIxeb53pcF9krQD3HlIg1o20M3YIzcJwzlTBD7AhfjOZ7/iV4cw12pnStPNo1JoPYcCgtkCD5MbH/7ySK3AbSWnvzgce85ajpr5Rz3mo9lqltnZ9I1rRb6cHaJOO3nEPxKMO/Zxu2xyDsk7oP4xc0Wi32SMsE7rIZZrA/0NgvQDytr9UbA95kJ24cpkgDAUhAz3JVFnvSA4F6mD9bs1wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VmKch0R6q9H57uJ/4sKUJHd1XBIQbxnBWQhi+rJk7FA=; b=acfLSfxZdtF5V6A9oqplQm/s/E/PDtprOsjFd1syQ33NK2zUVpxB17a7GHeFPH9quPqsgkB7Nl7S0M64+daSCZVJ4gdjgQssN8300CPaHD31PXzSjh3wWBkPhQ5SYShYZRlhv51RhenNym0Hx9ySJzJQa27pdGaBm0q0/+GQNiohd9gzBXvz8qb3ivKUnrYgoxj7iLPnZxwW8Vyt7hraZ1qZ+JJgt14P1YRX9SmkxTHraHCv31FJbM8WXDiMfodzoti5i2/Ns8mMHOOfj8gi8fRS/o7e1KQ9OX9GaAm4CQ0StiZCzX5zxFwS+UJ6Wurga5ZqVXBYj65/A6YQn0EvAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VmKch0R6q9H57uJ/4sKUJHd1XBIQbxnBWQhi+rJk7FA=; b=qplr5apESiPvJMKtVALUKGqcpdoKOaOEJP3N7YrMst5zIvJo/ZVhHYlUoyCq7Iu3oLFc5+fWcnRft7Jsg/o4bBOgt8RP/XNUGKAOPAVW35ZPIZYA3idV6dS2xpU3/ZgiAcSoWPxGBObcvHL9hq3HXSV73MQn0LCRJVhQX8LlkFk= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB4116.eurprd07.prod.outlook.com (2603:10a6:208:4f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Wed, 6 May 2020 08:22:07 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%5]) with mapi id 15.20.2979.027; Wed, 6 May 2020 08:22:07 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "draft-ietf-lsvr-applicability@ietf.org" CC: "lsvr@ietf.org" Thread-Topic: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020) Thread-Index: AdXFPESJQqXWSN51Tqy1DO85V6W27heQQbGA Date: Wed, 6 May 2020 08:22:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:a03f:4efb:7600:b5ca:18af:f844:a2fe] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e058626e-6597-447a-5af1-08d7f19690ef x-ms-traffictypediagnostic: AM0PR07MB4116: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P3aQkWMlqlfT4S6rCSp0zUax9TC6vzDgzrRG5tKnfwWAEf48Ai5dvANIVvcgD/PNIpOzqI2mkRJvQ/hpgbsOM/GQdFK0pr1vVmIzzIdgR2rtoXHnu7MnbVJdUJfLULvf1LvpYNhXu+FujVbDX2a1q6iR+rk4965VtkpZKp5oB0+gXTmVI1kciNhla63SLdeeIwLCqpqyrg8OpzNu5+RvLSY7DTItroRPd6zTcYMq4aOOwPZfZb1+d7LgZJa6yMQMpQ6cH5xR0Fy5mwgJAmrHMLUPBS5sHg2/O+NI/AfzdMRKjRl+deqtx7cQQb2YxfU4cHFnPEBHdYVVb7LiEmzguJQOnBjoIPoSkjMdt3UIVC2PTAEB3P7c2KdxpiIu67TbPkclWiDqxOk5sUQV5+xSy1MvRBvOqYSlm/+F/gdPI3tz8m8vACkC5+yRIhmN0+rH+KF0p4bbgMwYVyFjkBQ7GSCL2oK+uJfQ1H+BnZJe60LU6aqaz+Ny/NAtWvNwwXXR8gnZWLQv+ZpnUAXvygepoHwgWARzK/cvvf+0+1tfipDvvMvfmLZyaRoP4XXxTlFV8hIjCNNPKbiTGpRRk04CSOfnsP0PxDl9FtTKtZWdU7o= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(366004)(136003)(346002)(376002)(33430700001)(4326008)(6916009)(6506007)(966005)(7696005)(450100002)(71200400001)(55016002)(166002)(52536014)(186003)(53546011)(478600001)(76116006)(9686003)(66476007)(66446008)(66556008)(8676002)(64756008)(33440700001)(2906002)(8936002)(33656002)(316002)(86362001)(5660300002)(4744005)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: yK5Yb5Fx+KH5RyU4e6IsFE/A8Yn8BRskcFN3wasV+tYHBsqn+tLgKqnMb7LaMLJy1SV+zht3SlUc9O/7Dmd7TkqpJ8NnG4ipnaVLg9weVK7r/ryy/v+gOwj7Ze/lBr0LqI21qzue2Ukr5bGRBUsjC/QvSEVTiT/OaYk/b1RAjBnbEBN7jqwq4+nyTkCnnMNnOtYBweCTl31wLjjJ7jUU4Ekh9gLsiI/6Zo6RYLyT3lGvuXCB4R/jEL4exBuJ+MqW36V3jBHjPMCYzRcTGGm/vrFh5KFjjVVe1KvQZDn2cNV/REPNHMNLzjronCp5jg/CZCt+Ue16dMR8s/i99RHt3qmCuev/U4+faD1Di3URjVEt3yDiSqyTW9h1Bz8wer8OEtMpDmwpOAJBAkM0IOxdJqm+RZx9tg1qsPuqSK6tcao31iN1Gglj7Jl94K/7I30FldXc/NlEOAkg53yX0AX07xDNkfTFqGaKRxP2clItY144kQRwRQL21RmQwpHElKusDUl4Dsfrg/+YPw68BB8ib41I3N0qnx5kTpjmgbjgIAfBbzXo7CmsLAcpXJYa/VN5ZWRtZruzvXSSfsjPZgfNIJEnx6brOe94mpYUPBxEXMEq4u3lhQd/+XyCoJqEg14+fgojxKcoNdagk+pFRnNhzXEfsK9hvvWAWrw8v/99NQR/phwBDQJ7TWMwJkPDZ3xEjA/xespOCkZzh92iWLz8JYbC7D4f3483yedBAL0RPWVn2G/eLJUrwmj1Fvd5D3A3w+ReCoSwspDL6r97xYbEvNLpzjPdrwI6CkkZ3L2wO7zuOyVPBOoSIgg5J+NFDq2pwVf2/0oiR1crs0xfCUaWIj6dULCkTqdVNefbBmJF84fNe8JQgWKeA+PI+UIoxKIk x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB63860E99E91A6ADBAB676603E0A40AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: e058626e-6597-447a-5af1-08d7f19690ef X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 08:22:07.4322 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gU5oVVucX+EIGaGZGn/JXMHaJVeXJfRL2w4eZer4MTaMbdoQCQtfrXpP465Hx+Q8+HhTLqrqHdNbufHPHiq2sPaqCNJ+wvXowSESKg+QJ+c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4116 Archived-At: Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 08:22:13 -0000 --_000_AM0PR07MB63860E99E91A6ADBAB676603E0A40AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can all authors please respond to the IPR question? Only 2 from the authors have responded to the IPR request of "draft-ietf-ls= vr-applicability". Brgds, G/ From: Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Tuesday, January 7, 2020 10:39 To: lsvr@ietf.org Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020= ) Hi All, The LSVR WG initiates a working group last call for "draft-ietf-lsvr-applic= ability-04". Please send your comments to the list before Tuesday January 2= 1. https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/ All, please reply on-list indicating if you're aware of an implementation. If not already completed, please reply on-list indicating if you're aware o= f any relevant IPR. Brgds, Gunter & Victor LSVR WG co-chairs --_000_AM0PR07MB63860E99E91A6ADBAB676603E0A40AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can all authors please respond to the IPR question?<= o:p>

Only 2 from the authors have responded to the IPR re= quest of “draft-ietf-lsvr-applicability”.

 

Brgds,

G/

 

From: Van De Velde, Gunter (Nokia - BE/Antwer= p)
Sent: Tuesday, January 7, 2020 10:39
To: lsvr@ietf.org
Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 2= 1, 2020)

 

Hi All,
 
 
The LSVR WG initiates a working group last call for=
 "draft-ietf-lsvr-applicability-04". Please send your comments to=
 the list before Tuesday January 21.
 
https://datatr=
acker.ietf.org/doc/draft-ietf-lsvr-applicability/

 


All, please reply on-list indicating if you're awar=
e of an implementation.


If not already completed, please reply on-list indi=
cating if you're aware of any relevant IPR.


 


Brgds,


Gunter & Victor


LSVR WG co-chairs


 
--_000_AM0PR07MB63860E99E91A6ADBAB676603E0A40AM0PR07MB6386eurp_-- From nobody Wed May 6 02:13:24 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3330D3A0538; Wed, 6 May 2020 02:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNGxBVH7QCkC; Wed, 6 May 2020 02:13:20 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2106.outbound.protection.outlook.com [40.107.22.106]) (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 43D1D3A0486; Wed, 6 May 2020 02:13:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V3U55jBGzvz4o7C/dJT0oyYSCDXapq/sJ1AYEUQTkdseFOVmK0EI3hYrrsXJQeXd23F8bOUtfk7WlaU1f6T9ReYvoumvc/3+ErQQRqtNqMdWi7tFq2M2Zfr/F1OrRZP7L8OaD7EHMK2eZH2TS6itZhxGfNzJMiy3uy1cnazqnyxbPyp4XA3duoPwWS+8ratR8q8S5ALZGXZVOxeeJ/VCDoawQPkq+sWt2chfovOT1W1HSL2sk+BIjE279ZKRD+bDswXaBFZMjDxflLoTlS5PBjNHIonIs+zgvXYuCPCLDv5C+mo/l9NYMySKLO8Trerj6mN89U3D9f2D4orBu5VV2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w7rZXtZ4/in9jOG6kaqdfei3W+ZpgSdMjhrAixt6iH8=; b=JNO7xCCcqlTe0qnYWHw1jFG04gZ7tOVn1n5hxNXFXlKO6fqdGlKEeZuF18V10OV0kwfAYui5MOpFzy5ZcMB7CY6EZypuW8ubEXOldDPmRCVoBU/EcYndPrgeN+QFYTbRMODD5K9XrrIVfoV6yweT70OsVk7+NUnB0YtUs8L+BuVn+kncbRneGtINWs/nvwXwvT+3gXUbu90nee7rWVdPUkgJz/vrY3MZtbLCt/kd5bzbLormAGZQOtVT7B3TEd1WPn0C13V/FIO9KVwWaLIR1KtwGZAFNlzT2qHzH37hLLz3+gWQtE71IHppzRGYr6KKy/NlrEmLpbP7ZSS5vqfa3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w7rZXtZ4/in9jOG6kaqdfei3W+ZpgSdMjhrAixt6iH8=; b=dABSe1qWhVHBRYpcQDgPISOHtcUGG6FwtbklmhhghcPfVjR+loI2PLth8bFNUw3uI1QNEdLm3Pvf/vNMU4Vqm28UqpL/SEYq19nabDn2CY33mFsd/t0eFacNgymp9bFmnWlzaxOtX1Dzpm+ORJaM2amx+Ft8sNPhVHxq8Ys/7Xs= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB4801.eurprd07.prod.outlook.com (2603:10a6:208:e8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.23; Wed, 6 May 2020 09:13:16 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%5]) with mapi id 15.20.2979.027; Wed, 6 May 2020 09:13:16 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Randy Bush CC: "tsv-art@ietf.org" , "draft-ietf-lsvr-l3dl.all@ietf.org" , "lsvr@ietf.org" , Joerg Ott Thread-Topic: Tsvart early review of draft-ietf-lsvr-l3dl-03 Thread-Index: AQHWIw8xqnCpL7nU/E2odVm75LUBb6iaF4qAgACtwjA= Date: Wed, 6 May 2020 09:13:16 +0000 Message-ID: References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: psg.com; dkim=none (message not signed) header.d=none;psg.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:a03f:4efb:7600:b5ca:18af:f844:a2fe] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: be22cb88-2142-4467-65d7-08d7f19db63a x-ms-traffictypediagnostic: AM0PR07MB4801: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YdZMT+M9dNY3oqZKI/FcajyrvuiijdUTVrOC5f6v/fWkPIZo3O42uLdxDrbg39uUDOpJnVwJ2DRaP89OZAkwV1ZpKeAOabSEVv6rt7WuKCOFHiicywLzVn6YdD5ogeQdlEdQIjWBEqALvcgdUtubS83qoDiPb7eGZX5BGZl0uUZ9wMyYbI+22MStr7dGBG5bCOfUnRfJgsG3hobfYTbPjqRPA1/TQE228xuTcmfouepX8pVLsJHYMT6Wyk/3wAAy3bpQd7ur0A3S5WfYe7W3Ixljao/1WWHR5Y8ZhghhRSlTMYAb39e+//kKkEoJclXmvk5vGXTJo41UGmK2s+6pJOLKfdx9kaSy0EFRNnv5YRHNBru0aiSX9yzkPDqMO0w28QiPCgLGplkYa/3xFBE+vsIzZXz1xTGkTLGcEACn8uRz6qL+FwXCSK3iX4Jg7NVdePV47Yk4UIggk527OdbGDkYefsT/GYSK6ALHGzldqdwwaBrMfcxrWPrVO8HnPUHUb4O/f7tIGUH4UFEoVhn9EQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(33430700001)(8676002)(8936002)(4326008)(71200400001)(6916009)(66446008)(9686003)(64756008)(66476007)(66946007)(86362001)(52536014)(55016002)(478600001)(76116006)(66556008)(33656002)(2906002)(54906003)(186003)(53546011)(6506007)(316002)(33440700001)(7696005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: fOIqcxMycPhGEoYKpy9JzN4z11N2qmQTrF3uyMP5fhdFWGWuwjWlTn3WHkwmw23qFYCZlLtDLAwZ25BnDZEWj9DHCpGwAd/nn2wx4pF/h5tdfKfiur8XBbh7Qgl0lA8GjpByR15Q8KTozGtfP5JqS+BugF3oCG+bMoF6bCLO2u64J3KWGpzf1RX2ZKAtFWyTIRfKk4q7QRsHAMl/v9a2hDnmauJBuqOSSjqp+AHmqnKbWrg4LGcSyUbijhh0S7VIObzY6/58emx2zi9cAwWnbuX4ZVD5PPDnPIFGJClkGd8oyP7u1QOYLhWqaDiGNSBMVKvlpeBwRhT/d0+z/uKdfSIqWObRTUBGuN3cJIYo6De4WrCkHhmKRyuvYWLDBE2HGsM4Mcy5r6ACT98h5C8y6mmA3GsEpkZAuFcP7rScu2b1eoFP7ntAdsBk7S2movKiuWjWK5cf+dG57eLcGIDgGnM4lYiZuE+Hy4FjYw9gSOylxwRO5XN40msth0llwRccZYUgtkBfuqxItnTrzJmsQrzPzXXCgOVJ6S2gjs2s0+Jb+KNEUe4ewLoMxXujlyDzLe8iGbqXJBubcmlgmkSGG+GzPnyb6yq58XJ8ZeRXzAm3TY3apd9ZcWwE4YN7Iv0IL8IU0lAv7tR+nFCAHtHGHr0VO6GN/u2qaRU/YjV/tQYT7Xz3StyEX0FhXm/0HP/KOppojpcK6PXV0KB11iX3x8Mr4QJvN9mHe2XHec1PvCpwlAjRK6WqQoWvBLyc/ix3reYnnGKpPhzeR501nPKu9OK8hPK1OJx0aRgnSOlZab4LKHULQBQMk5YZjUcPopHfPIWOrkz4P5p9yUCAHWJatHiwyexBrweaKENy1V3huWAZhhUlGcAvyLFZcZM+sKJp x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: be22cb88-2142-4467-65d7-08d7f19db63a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 09:13:16.4280 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ufygBkWU7Fdv3imyXkxp8du1RN3ddBJChJgofJOjIdx2uTX8bC9GSK0GpaLTfo8VzLtOivWuoC0p+NU0X1NVzjejlEuTf3gY1eig96V7gRY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4801 Archived-At: Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:13:22 -0000 Hi Randy, Wake-up call received.=20 Can you refresh the draft-ietf-lsvr-l3dl-03 document and I'll launch WGLC o= n that document. Can you refresh " draft-ymbk-lsvr-l3dl-signing " and " draft-ymbk-lsvr-l3dl= -ulpc" and we'll launch a WG adoption call. Brgds, G/ -----Original Message----- From: Randy Bush =20 Sent: Wednesday, May 6, 2020 00:45 To: Joerg Ott via Datatracker Cc: tsv-art@ietf.org; draft-ietf-lsvr-l3dl.all@ietf.org; lsvr@ietf.org Subject: Re: Tsvart early review of draft-ietf-lsvr-l3dl-03 wow! thanks! great review. unfortunately the wg has gone dormant, so we have let the l3dl drafts expir= e. should it ever wake up, i will happly merge in your excellent suggestio= ns. again, thank you! randy > Reviewer: Joerg Ott > Review result: Ready with Issues >=20 > The draft describes a peer/neighbour discovery mechanisms for=20 > large-scale L2/L3 topologies in data centres. The aim is provide a=20 > protocol by means of which the involved nodes can learn about other=20 > nodes connected to their (broadcast or > point-to-point) L2 links and about their respectively support=20 > encapsulation schemes, identifiers, L2/L3 addresses, etc. This=20 > information is then provided to a higher layer for further processing. >=20 > The document is well written and fairly easy to follow, but could=20 > benefit from a bit of extra context and target application domain in=20 > the introduction. E.g., explaining explicitly who would talk L3DL to whom= . >=20 > >From a transport perspective, I see three potential issues that=20 > >deserve > clarification or reconsideration: >=20 > 1. Section 10 spells out a default HELLO interval of 60 seconds. With=20 > a large broadcast domain, this may create quite a bit of traffic.=20 > While this may not be an issue in well-provisioned data center=20 > networks, a remark about sensible value ranges and the implications=20 > may be worthwhile. Just to provide some guidelines to implementers=20 > (who want to offer choices) and operators (who pick them). >=20 > 2. Section 10 also suggest that in response to HELLO messages nodes=20 > will issue OPEN PDUs to newly discovered peers. This appears to bear=20 > the clear risk of an OPEN implosion when many system come up at the=20 > same time. Shouldn't guidance be given to avoid repeated traffic=20 > surges and possible losses and thus unnecessary delays? (I noted that=20 > other places foresee exponential backoff when retransmitting OPEN and oth= er ACKed PDUs). >=20 > 3. When the protocol applies fragmentation, should there be a note on=20 > preventing bursts? >=20 > Other notes: > Section 7 on the checksum needs more detail. It also talks about a "sugge= sted" > algorithm but this should be clearly mandated or way to choose one by=20 > means of configuration for a complete data centre would need to be=20 > made explicit. I also assume that the pseudo code on p.11 would=20 > benefit from a leader '0' in 0xffffffff -> 0x0ffffffff, otherwise=20 > expansion to 64 bits might fill the high order bits with '1's, which is c= learly not intended. >=20 > Section 11, p.17, second to last para ("If a properly=20 > authenticated..."). From the text, it is unclear what is meant by an=20 > "OPEN with the Serial Number of the last data received". >=20 > I am curious about the error code, providing 16 bits for additional=20 > explanation. Why not a text field? Also wondering if repeated retries=20 > (due to failure, not lost packets) could yield fast repeated transmission= s. >=20 > Section 15, should the KEEPALIVE interval have suggested (lower) bounds? > At the top of p.26, it says "One per second is the default", the=20 > previous page at the bottom refers to the inter-KEEPALIVE interval of=20 > ten seconds. Not sure if the two are the same, I suppose so. If they are,= the numbers should match. > If they are not, we'll need some extra text to explain the difference. >=20 > Nits: > There are two spellings of "Encapsulation", capitalised and lower=20 > case. Use one consistently. p10, first para: comprise -> comprising >=20 >=20 >=20 From nobody Wed May 6 02:25:53 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC823A05DE for ; Wed, 6 May 2020 02:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtsKkJkpVx52 for ; Wed, 6 May 2020 02:25:50 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70139.outbound.protection.outlook.com [40.107.7.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E857B3A0418 for ; Wed, 6 May 2020 02:25:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GMIRmYHHZhzYbAAStHq3J4bvKmcYVA00XyLqHndaESwty+TtyTmgSEtuYn0yLOlLealGfCPZftV0RHdox3m3ftyD3cmSbJUO86QDPlx3aaZGVagDLHirjfnJ7WFXxNHJGMCCZsq3McJBGTP+TDgGaQO+K2JYp+fncXeQqx1mZg5FxfnAQu9p7Ja1cUgl/rUzkcX9UoixYNefay79uj312+WDU8PbX7i2L+FCoX5TcpZUXfH6YhmuS1DszJHmX+KAKOMT5EGs9lDfiEJuqgFnJGe454+Y21w4E8oXmU96hRWV93oNi79Pu3q+ezOuPXzYHv5iwIM/nS6zDAKFvvPw9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vUqr6HmccuNX9voxUg/k0d6CxUSpgXVDdlOTjAFFr1o=; b=Mv3EIH0OdbIosKUL9nadmXK121Jz4YqgHW3Q0KN9K87/OoQWFFx1F39A+kJsDrw1tsXijoMdNMrRai8EeVkkkvYBOETb7ZSl9v7ZAY1w78OlRfuoxTuLxGuayeN1y1TsEgvxvQ/QgW3wiChLZmSgY5MYPZ7eDNX2piMgElrNL9R8HNyMzzZgHJ9ti3Cvwj7+JwqW8KHQy4q1GFw9l0Xqgv2q56Rz0p543WEtBCeTTXmsgo899R3/1r4b6ZFiSQ79d3fOh7SPdpzvU0QOJuCMq6xutMknRACj5VCKXr7gTVzS6kwWjjHiIzSwAyzFg81MIsnCH9j4oMM/vvNGMCGrEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vUqr6HmccuNX9voxUg/k0d6CxUSpgXVDdlOTjAFFr1o=; b=Xokej6mK+DXV8aN5hJ9hS8XOUV+tOapTebPA0VJyu/NldENMBlBkhUmDWqqiocfHgcpL9WkHWOyiZEw7WYsLFnVrtkm8uAT1BV9PfFWAAWEyVP5WJL6ps0dko2a813BN/fQ+GriWUpo+PZiqQsTGZT7AhT4hrIBYhoQ85oH6W9E= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB6113.eurprd07.prod.outlook.com (2603:10a6:208:10f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.21; Wed, 6 May 2020 09:25:47 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%5]) with mapi id 15.20.2979.027; Wed, 6 May 2020 09:25:47 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" Thread-Topic: LSVR WG Status update 6-May-2020 Thread-Index: AdYjf7LXWVLzQ/4TSKKobGtG7ASLXg== Date: Wed, 6 May 2020 09:25:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:a03f:4efb:7600:b5ca:18af:f844:a2fe] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 35dcb95f-6c9b-4782-98f4-08d7f19f75c7 x-ms-traffictypediagnostic: AM0PR07MB6113: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6sXgOQg88Zp68QAb0a+bAVaq0l+91R3tY0vQbaHHQ2eD4B5yRfBiMImChBPjXRX0O5ETDNUGcveayf8z68DeTE/5MMWyZ/VGnP37T4Gn5jthI4VY7MGPiZ7cMa5V0XYaTSNVpYBSfTQQ3Cb7ufJzu6t5CKEvnSdUK3ybAi7M/I4fiWbqI9dDPqMpTeXxHU0tDbZShUWj4mQq7t6pWzXQbfbPm0V0M1FeEVIvm7VgCnIb/h/vgXFmr6INabd4eTtI773uwPnIcAhsk7xsObTCPtS63Sxh/lwXNkhvLSfTxR8shdzuDVMhw52J7aRHSnNBOWrBkL384nI6lF0taWy/QWULd7b+q+mqKkHEDn7tqyWQ/ohKdFcoDsorVxSPWIZsn9w2KZ0Mc48p7vAqFfYnePEfCIS2X57eJfcorWH4Nxd4o29H/W1q0r59YpmrFzYp03Rt+IKNg9zc6+nP106bOpcsBzR+GTdwfEZ3a/PcbPeLVmoo3QSBh2E42fQ3NC+hUp8C4wBQ46MnMGFLfHj41g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(39860400002)(376002)(366004)(396003)(33430700001)(8676002)(33656002)(6506007)(478600001)(3480700007)(71200400001)(66556008)(186003)(64756008)(33440700001)(76116006)(9326002)(66946007)(66476007)(66446008)(8936002)(55016002)(2906002)(15650500001)(9686003)(6916009)(316002)(86362001)(7696005)(5660300002)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: SGh6H5Gs0yTw0dqax5lhnIzZ1L3cawsCsrIPz35MHl19HxFEfUPiIhsCgO0UosESr8a80EN6hmZUwG5UucNhFQKV9OgQ9z7ryN9/BVEvvrTU/iaw5297EDaTDbxPsVQMu/Dt6ZB3AX1b61srtx08gbEYvUqWCuooJi6L6/3rkNqQqhaUyJPqAOHz00lXuzCv87Y2WuMrwZgO8joWyAwT0DVy6BSaZ8AoT3XzfNYvZqT6VhW0XzTutpMqJW0Ayf+/JBvLnj6ohFHmgdiTYXSgH9cgp5Cx4r2H10rv71Ff2T4Z7NpNxbj65WM6Nw8Tiui6LweBMpNKhqLEKfZGHhfWDqz4Aag2IwE79V6ZMHGeWBrMMZQrCDdKJBb9Y2N6sbW2qHacd4U8RFb193++hQ0z08pzCbKm1quWdfoh+koHYeEZw0qJsedWAhVxO5fC41RbpFjjkKP0irHgKnS+i1wEqCrs0jaJkPyH4Y9bLQHNYdOLhaqCaVyU7JINXMVpFdw9LKe13YcqciPjEvNeD2NVhaDjxe3pfQRvs3MSUHLLcQ1oK9lpFEiBcx5K9YfdNSBRlHYdFN7cJgza29U8t8M5ukX6/ue9rG9iEOS/SzRqa0NzTLpMUf7kTSk8G8YgIhVTbKfPR201UyUCq/ZaPoLu+d/0Mgd80kRvUkBGNUuSFhAfhuyFAl7dZSABuDULEmORkO0QiS4cEbbYvnd2irZcU2ZU75hHPq+qvxeQH6WBumerX8SShAaoZSeR3GR0pYMgZnnQfDYJzzkzqs75YxvE6rtADwxi4cOegCPLtYGeVD0vvYjc5oyzpo1Tn/SswkgsTWh0OmdpRbYVLcOR2H8cUR6+6FpSKpEv4ThZ1kvZ32LySjDfOr+b3Y47TKv2MCBd x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB63863DD50F26F3F4F005EBD8E0A40AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35dcb95f-6c9b-4782-98f4-08d7f19f75c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 09:25:47.3347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lvRhlEOFPqxJlQKpK5APyCIUAoKunTHeev9Xn4hOHN44z8ubFnijRYE0VIxsCUbsrMOXkP/dhnSBRcD5Wy1l2vw9RElsVHyHmOVwYGCla0Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6113 Archived-At: Subject: [Lsvr] LSVR WG Status update 6-May-2020 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 09:25:52 -0000 --_000_AM0PR07MB63863DD50F26F3F4F005EBD8E0A40AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, It has been a while, and the very special IETF107 starts to be faded away i= n our memories. For your convenience find the LSVR document status update. WGLC Documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AD requested for drafts "draft-ietf-lsvr-bgp-spf" and "draft-ietf-lsvr-appl= icability" to be submitted as a combined package. draft-ietf-lsvr-bgp-spf-08 * Successfully passed WGLC and is ready to be send to IESG * Shepherd writeup in progress draft-ietf-lsvr-applicability-05 * Successfully passed WGLC * Waiting for all authors to respond to IPR awareness call * Shepherd writeup in progress Documents with pending WGLC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Layer 3 Discovery and Liveness (draft-ietf-lsvr-l3dl-03) * TSVART early review: ready with issues * Document is in good state * Implementations are being progressed * Once document is refresh WGLC is initiated Documents ready to be adopted =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Layer 3 Discovery and Liveness Signing (draft-ymbk-lsvr-l3dl-signing-00) * WG adoption requested once document refreshed in datatracker L3DL Upper Layer Protocol Configuration (draft-ymbk-lsvr-l3dl-ulpc-02) * WG adoption requested once document refreshed in datatracker Milestone Documents missing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D YANG specification for LSVR Brgds, Gunter & Victor LSVR co-chairs --_000_AM0PR07MB63863DD50F26F3F4F005EBD8E0A40AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

It has been a while, and the very special IETF107 st= arts to be faded away in our memories.

For your convenience find the LSVR document status u= pdate.

 

WGLC Documents

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

 

AD requested for drafts “draft-ietf-lsvr-bgp-s= pf” and “draft-ietf-lsvr-applicability” to be submitted a= s a combined package.

 

  draft-ietf-lsvr-bgp-spf-08

  • Successfully passed WGLC and is ready to be send to IESG
  • Shepherd writeup in progress

 

  draft-ietf-lsvr-applicability-05

  • Successfully passed WGLC
  • Waiting for all authors= to respond to IPR awareness call
  • Shepherd writeup in = progress

 

Documents with pending WGLC

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

 

  Layer 3 Discovery and Liveness (draft-ietf-ls= vr-l3dl-03)

  • TSVART early review: ready with issues
  • Document = is in good state
  • Implementations are being progressed<= o:p>
  • Once document is refresh WGLC is initiated<= /li>

 

Documents ready to be adopted

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

 

  Layer 3 Discovery and Liveness Signing (draft= -ymbk-lsvr-l3dl-signing-00)

  • WG adoption requested once document refreshed in datatracker

  L3DL Upper Layer Protocol Configuration (draf= t-ymbk-lsvr-l3dl-ulpc-02)

  • WG adoption requested once document refreshed in datatracker

 

Milestone Documents missing

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

 

  YANG specification for LSVR

 

 

Brgds,

Gunter & Victor

LSVR co-chairs

--_000_AM0PR07MB63863DD50F26F3F4F005EBD8E0A40AM0PR07MB6386eurp_-- From nobody Wed May 6 04:35:05 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD1D3A0969; Wed, 6 May 2020 04:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omnjfx3MwKkr; Wed, 6 May 2020 04:35:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 EC05E3A0937; Wed, 6 May 2020 04:34:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWIKH-0003iU-NV; Wed, 06 May 2020 11:34:57 +0000 Date: Wed, 06 May 2020 04:34:57 -0700 Message-ID: From: Randy Bush To: Joerg Ott Cc: Joerg Ott via Datatracker , tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org In-Reply-To: References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 11:35:02 -0000 > Oops. I was told this was an "early" review, not a "late" one :-) it was an early review. so early that too many people seemed to be asleep. but i see that the excellence of your review may have wakened them. thank you. randy From nobody Wed May 6 04:36:48 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642163A0973; Wed, 6 May 2020 04:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO9B5aLUljXi; Wed, 6 May 2020 04:36:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1B5463A0937; Wed, 6 May 2020 04:36:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWIM0-0003iw-O8; Wed, 06 May 2020 11:36:44 +0000 Date: Wed, 06 May 2020 04:36:44 -0700 Message-ID: From: Randy Bush To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "tsv-art@ietf.org" , "draft-ietf-lsvr-l3dl.all@ietf.org" , "lsvr@ietf.org" , Joerg Ott In-Reply-To: References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 11:36:47 -0000 hi gunter, > Wake-up call received. good morning! :) > Can you refresh the draft-ietf-lsvr-l3dl-03 document and I'll launch > WGLC on that document. > > Can you refresh " draft-ymbk-lsvr-l3dl-signing " and " > draft-ymbk-lsvr-l3dl-ulpc" and we'll launch a WG adoption call. will do so later today. on euro/noam research calls at this hour. thanks! randy From szandi@linkedin.com Wed May 6 10:59:59 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE453A0954 for ; Wed, 6 May 2020 10:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linkedin.com header.b=I44crKrS; dkim=pass (1024-bit key) header.d=microsoft.onmicrosoft.com header.b=rMHc4PsH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O-wiB7NknAR for ; Wed, 6 May 2020 10:59:57 -0700 (PDT) Received: from mail523.linkedin.com (mail523.linkedin.com [108.174.6.123]) (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 D64523A095C for ; Wed, 6 May 2020 10:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=d2048-201806-01; t=1588787994; bh=UNuyNnABjQ0E4M+/3Hkg7fWR/3lUfWjypAr7Q8LL8YA=; h=From:To:Subject:Date:Content-Type:MIME-Version; b=I44crKrSOiqYB0mPohGRQy6q9cXysBZzgVaEh2a7Xu9MjXd0leFz+faVWB7EKPvLN XYdH53N5LR9OTj1qrANO70ZQDS4D0JPb6JO1B2lB721rbzu1z4eBp1hPbL5eERCo7m h/UaqhzTbT56reJITNnyoVgShdIOAfBQk6NNG5piQozYlCicsqmCah55t4hN6gpRsc 2n1ilZOlBqZAdnDDVVf+AY2Y/2GdEpiY3m+5iaHFXBr2IEBdTHJGJcncHVpMsLKTm7 CFa9ww5UuYfS75QYI4gXEGHaHaNAQba6eDC8lHFt9ZYV6PxfDjC7fme2TW4EXguFoY xxdm5M/uUOVaA== Authentication-Results: mail523.prod.linkedin.com x-tls.subject="/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com"; auth=pass (cipher=AES256-GCM-SHA384) Authentication-Results: mail523.prod.linkedin.com; iprev=pass policy.iprev="104.47.58.107"; spf=softfail smtp.mailfrom="szandi@linkedin.com" smtp.helo="nam10-dm6-obe.outbound.protection.outlook.com"; dkim=pass header.d=microsoft.onmicrosoft.com; tls=pass (verified) key.ciphersuite="TLS_RSA_WITH_AES_256_GCM_SHA384" key.length="256" tls.v="tlsv1.2" cert.client="C=US,ST=Washington,L=Redmond,O=Microsoft Corporation,CN=mail.protection.outlook.com" cert.clientissuer="C=BE,O=GlobalSign nv-sa,CN=GlobalSign Organization Validation CA - SHA256 - G3" Received: from [104.47.58.107] ([104.47.58.107:35126] helo=NAM10-DM6-obe.outbound.protection.outlook.com) by mail523.prod.linkedin.com (envelope-from ) (ecelerity 3.6.21.53563 r(Core:3.6.21.0)) with ESMTPS (cipher=AES256-GCM-SHA384 subject="/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com") id 6A/C2-23143-A1BF2BE5; Wed, 06 May 2020 17:59:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JyWlFuTIELWnScubP99tElSPJID8/vD55qqbjbJgAmKuFuthe1oIFPQHJa9FG/siJI2qAqGcgorw/swl4zuH8AGJjxlxEY1g/dt9oZlhgMcOLjhjqqaFTmR/bkoXqSf9uLdCNWMYkJ+lx/CYwhcmaHOl6iaDTcujBEVQwCAu85qssjc/Tppwg+MxIKcGM8u3VxpwjE5hAHaGc5znGq+341gG6bRE35uF+Fmq/l1esbKN+OsdVrP4liVGg6+kENKpSKwuV4c380jUmU89prlWVLqlkG63sMltaAz/GOyRGyq0G1sJHP9GXCICmxYEBDrCAXQcGzQWtdSnGjXYdgyWzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UNuyNnABjQ0E4M+/3Hkg7fWR/3lUfWjypAr7Q8LL8YA=; b=D9qCM46WGvYzuy6hAh6ltMkE0Ne4IBMMBsxENEewe8jS4D7vhqdigwCC5EA/fpveZE9ZMcMCfQ3mRjCR8Fd530WZx7pGWGMy7XtxRk38jfR8rbyZtpOQOxMwGPP/09eZ7xrQGJ0kOClwhy//j1GbS0coHRxst/xXXaTuc6HamvO2mRK6udOByuKLND7j+kFeSdT0y6BVUMrOyxS77LAEsQCs7ubkpwnEepn9C0FMeMlbDvWDNO1wOcm+ATvO7hpgzGp19Ts6HEmBIe6ZQWpnHg4HXu/CwQCnrrzXspIiYoaBvEoSigZ6Gpn1Tmu3q6284kwtzlUfTAK57Pkw4JcdJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=linkedin.com; dmarc=pass action=none header.from=linkedin.com; dkim=pass header.d=linkedin.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.onmicrosoft.com; s=selector2-microsoft-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UNuyNnABjQ0E4M+/3Hkg7fWR/3lUfWjypAr7Q8LL8YA=; b=rMHc4PsHVYKMdMqvZFuTT0ysxsDDJYg1AbObtUlUaYZyRKqYIap2CxTfTL+ShWSc5EhkpKDhYwHr8N/sEkGWAMEe4LQEg/rQCC3P8FcwwOKtij6SJ9i0pFvDB34az9t/BQfrEHW8p9aLoO5kIBBLqIfF2xBRjB//YEkfbs8B7q0= Received: from BYAPR21MB1174.namprd21.prod.outlook.com (2603:10b6:a03:104::16) by BYAPR21MB1175.namprd21.prod.outlook.com (2603:10b6:a03:103::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.5; Wed, 6 May 2020 17:59:53 +0000 Received: from BYAPR21MB1174.namprd21.prod.outlook.com ([fe80::e4de:a07b:178c:e426]) by BYAPR21MB1174.namprd21.prod.outlook.com ([fe80::e4de:a07b:178c:e426%8]) with mapi id 15.20.3000.004; Wed, 6 May 2020 17:59:53 +0000 From: Shawn Zandi To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "draft-ietf-lsvr-applicability@ietf.org" CC: "lsvr@ietf.org" Thread-Topic: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020) Thread-Index: AdXFPESJQqXWSN51Tqy1DO85V6W27heQQbGAABSveX4= Date: Wed, 6 May 2020 17:59:52 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-05-06T17:59:06.4221366Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=linkedin.com; x-originating-ip: [73.71.74.70] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fe3f44fa-5736-424b-5616-08d7f1e74747 x-ms-traffictypediagnostic: BYAPR21MB1175: x-microsoft-antispam-prvs: x-o365ent-eop-header: Message Processed By - CBR_LInkedIn_Mail_To_External x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fEN2ay4Zl2fHm1hX4bqvoPX6JhPD7bXONXLr/Pqg9HMx5W5tRdoigH4bYjPOLt3orTqLkG9GiJal4hEYcQC8RRiUqA+R9I7gIbb7yrRJpDlWvA0Hskge2rfjf+6L5MNC0/nldIGUWRS6s5W0jlujbrm7rBBi7CxvcPpR6YPkr95cDwnA2AsnGtw0TYjIdv04Brc6HBzOpx4WpMnbQl1h8vaACdUDpQCaXt+A+bYQ4Ib2cqKZoMfuenMMg0R5rG+pqCb/nDaUZGj6ut4BFhuQ1dFbghzAt4xl0k2o5BqXMqaFCqZezTgV+FC07bBTx9ZDzxFPPcwOVj2dn5m/69fURmwgw+O4/APZXQ24V7A0VrlxJjZKPkM/Y8aUCN6zQmvWXhxfMePM7KiCDC5UkeQ+jVZvgTyvvt98BNhKShg1ecAPcNM/paSwzfuBToVHXfbv55V4LhhEtCrtPZLYxS1ijFxxFPRJDvyC+PexSElf9INubpJqcymJVyXFmSag/8JO6LWvDTestLQpqOVcfm40sPEcVnILILircrxIP8ANVr66vp39KQrtH0og0j/UgaSeNKnzx4t56+Uv2op0RG3lq4eEwtpNwy7LEFvq6h6F3cU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR21MB1174.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(136003)(376002)(396003)(39860400002)(33430700001)(82960400001)(66556008)(53546011)(76116006)(7696005)(82950400001)(64756008)(26005)(186003)(52536014)(66476007)(33656002)(5660300002)(19627235002)(66946007)(478600001)(166002)(6506007)(66446008)(2906002)(33440700001)(8990500004)(8936002)(86362001)(9686003)(4326008)(296002)(71200400001)(966005)(316002)(55016002)(110136005)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 4fD2PS9Y+GqegxdWcf8+O0gJ4ZObR/srZ6V88A+2KeQC1ubwt/cfTHCh17NHiff+3AA17leOaKVMKS/0L9xVvk9DvXvPL6kJv4qQTuJWN5D2z3EF0iju/9qu4PNENhhnb/ZM8r2rTihdWtJlMVojq1/hHRFqyUkgPvpw78fYPZ3Pg/31KNf6zsJuw0c6XRuqR+7av88R0xSmxPrZXwzYpmDg4CLJvVcjbG8EN8Tq5lFU2lr6Ydo9NFYeSbgABJVrlEboTbuG9tAX/h315kghiQ71//E45qlL2GngOxwtOSONJ3G3nspxN6ABoNsG8bK9v+jw15mUrkRRm9VPU+EGliaBO/P/YuEdU7/kM74bMu0gm4sJkFBlTTglj9Zb9OWB5rtuWuDCEOUpi4A8p3B3J9XB97U4ZNyfBHxzwfsLHy57qjKJEwz6IbEnhKEq5Ic5oLxAiUZiwQcD59lQRp1DFOLuhSJBDHhkmWFvkvrfPH/VnO//sTDi6NQvBSSS56Mg6HnkjQVq8et5x1ynrtJLBbw9r8cjv8408PaU1hh1zPBPV2kkJhxBvvfMXHSWcAy98hu+odp9Kd7ze8O7rXNP111yeFANdFquVdC/LYmIAqYDPK0emlTwwh2+fLBia+nDlgRj+Pzcn7PnIxNzhUUik/7hBqu84e9Mkhy5u/QaElgEGrROt+FAAvVeJHPaaCiqR9bF0koevGzEOeZ3U+ah4YYhC2SnRMQntfnRE3DAMmY8Y/gW5IESifEuVbtyUwkwEacleJTr56eCcEowIz0ECykBRr5hVfr+2JWqYoeNt70= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR21MB11743E33CCDD3AAB2ECE7EF7B8A40BYAPR21MB1174namp_" MIME-Version: 1.0 X-OriginatorOrg: linkedin.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe3f44fa-5736-424b-5616-08d7f1e74747 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 17:59:52.7753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lYttPJhwkJqRx2t1vvxM0feA42Uzx9LGR8BbKfBtUGiy9a2HW7b1TtZ4O9uP0Vav4cEtKABgEqWYiWTYMriElQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR21MB1175 Archived-At: Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:01:23 -0000 --_000_BYAPR21MB11743E33CCDD3AAB2ECE7EF7B8A40BYAPR21MB1174namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am not aware of any relevant IPR. -Shawn Sent via carrier pigeon ________________________________ From: Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Wednesday, May 6, 2020 1:22:07 AM To: draft-ietf-lsvr-applicability@ietf.org Cc: lsvr@ietf.org Subject: RE: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, = 2020) Can all authors please respond to the IPR question? Only 2 from the authors have responded to the IPR request of =93draft-ietf-= lsvr-applicability=94. Brgds, G/ From: Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Tuesday, January 7, 2020 10:39 To: lsvr@ietf.org Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020= ) Hi All, The LSVR WG initiates a working group last call for "draft-ietf-lsvr-applic= ability-04". Please send your comments to the list before Tuesday January 2= 1. https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/ All, please reply on-list indicating if you're aware of an implementation. If not already completed, please reply on-list indicating if you're aware o= f any relevant IPR. Brgds, Gunter & Victor LSVR WG co-chairs --_000_BYAPR21MB11743E33CCDD3AAB2ECE7EF7B8A40BYAPR21MB1174namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I am not aware of any relevant IPR.

-Shawn

Sent via carrier pigeon

From: Van De Velde, Gunter = (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Sent: Wednesday, May 6, 2020 1:22:07 AM
To: draft-ietf-lsvr-applicability@ietf.org <draft-ietf-lsvr-appli= cability@ietf.org>
Cc: lsvr@ietf.org <lsvr@ietf.org>
Subject: RE: WGLC for draft-ietf-lsvr-applicability-04 (to end Janua= ry 21, 2020)
 

Can all authors please respond to the IPR question= ?

Only 2 from the authors have responded to the IPR = request of =93draft-ietf-lsvr-applicability=94.

 

Brgds,

G/

 

From: Van De Velde, Gunter (Nokia - BE/Antw= erp)
Sent: Tuesday, January 7, 2020 10:39
To: lsvr@ietf.org
Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 2= 1, 2020)

 

Hi All,
 
 
The LSVR WG initiates a working group last call f=
or "draft-ietf-lsvr-applicability-04". Please send your comments =
to the list before Tuesday January 21.
 
https://datatracker.ietf.org/doc/draft-ietf-lsv=
r-applicability/
 
All, please reply on-list indicating if you're aw=
are of an implementation.
If not already completed, please reply on-list in=
dicating if you're aware of any relevant IPR.
 
Brgds,
Gunter & Victor
LSVR WG co-chairs

 

--_000_BYAPR21MB11743E33CCDD3AAB2ECE7EF7B8A40BYAPR21MB1174namp_-- From nobody Wed May 6 11:09:20 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0CD3A0991 for ; Wed, 6 May 2020 11:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX62X_3jntzK for ; Wed, 6 May 2020 11:09:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 574F13A098E for ; Wed, 6 May 2020 11:09:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWOTc-0004un-Kc; Wed, 06 May 2020 18:09:00 +0000 Date: Wed, 06 May 2020 11:09:00 -0700 Message-ID: From: Randy Bush To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "lsvr@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] LSVR WG Status update 6-May-2020 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:09:07 -0000 > Layer 3 Discovery and Liveness Signing (draft-ymbk-lsvr-l3dl-signing-00) > * WG adoption requested once document refreshed in datatracker > L3DL Upper Layer Protocol Configuration (draft-ymbk-lsvr-l3dl-ulpc-02) > * WG adoption requested once document refreshed in datatracker both drafts refreshed with no change draft-ymbk-lsvr-l3dl-signing-01.txt draft-ymbk-lsvr-l3dl-ulpc-03.txt randy From nobody Wed May 6 11:10:10 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE7B3A099C; Wed, 6 May 2020 11:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, 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 YDYkf2sw6eZ9; Wed, 6 May 2020 11:10:06 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 6A36E3A09AB; Wed, 6 May 2020 11:10:06 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id s18so1139012pgl.12; Wed, 06 May 2020 11:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=vmohV6a/iuzCVeDII8lVhM9Ic89gHTP39l5sSASSfN4=; b=pNIlwo03Mzg/83M7I4o2b5DQXG1po/ThPi4pzcABq75/Y0efwC5Tp9YGebXFdoHYMn eUjlgFYVykFSXTjviehf0aVsu5RurR3SHu4EasCnF7GamqgGx7XVKIdTU32SexFvF4L6 qAN0gsY1LNkk+7QG0wgeMT3CSHehEOqROzOfOg9XFx22cAHP6ZUNfBXYafA1bDbVjbxa VcP1CtPn5axAafIYe2tz/dw6BJhT21r6NkUug4qb/DJRkixYHFQ2uvMdO1yTaBMGXtdI K9vXmMLtbGGhiqIv+dlL18/EvfrOA4oNdqso9NUit4CvR6d6X5QSjRVHoyz70EBYXgTF lwEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=vmohV6a/iuzCVeDII8lVhM9Ic89gHTP39l5sSASSfN4=; b=tSpqemiP8070XYWv3Q3trsDYK34nZcZ6vT8HF96Gy9a+JVv7GFrfc8EGeqDDWbtLWz ZK3J/ps4QzGkOLznjndfyX8gabUzreZGih2hE+fF/rLrwEZWkLTSPUamsu1r98lgmabV zRbZIedQcxIbiycTJd3xbsplJAX/RW3MWx5ONPzpXIG6cr3BFuvqACq2ZfB083zIFlyb m6CuyqeGh62zLHiyx1BE83QWOgABTCZR1we4is5YXm66BvcpDtIfUcsA9qGOAvbb/CH+ E+rpoKWWchk55tXxKC8rfjKcyxlTWLuT47zXE1nxz/hBpAFnIM+NpBw4BDqfC4E1fKmd HbHw== X-Gm-Message-State: AGi0PuYg2l7EIuNSJTHRdtReZ+9M4fsrQqtIL/8YtGv4skkxjznuYrDF csogGbXEMkt7w9ojP2czJzPk6Dg4 X-Google-Smtp-Source: APiQypKNWRso/+5ROKkOggZsfodweClun0NJDt3FUJQz84qOVPDEqITGDSsm0ORQF0v++/ZCeNs1QQ== X-Received: by 2002:aa7:9d90:: with SMTP id f16mr9929111pfq.48.1588788605400; Wed, 06 May 2020 11:10:05 -0700 (PDT) Received: from ?IPv6:2601:646:9302:1230:e477:f3fc:21d4:7efb? ([2601:646:9302:1230:e477:f3fc:21d4:7efb]) by smtp.gmail.com with ESMTPSA id e10sm825703pfl.195.2020.05.06.11.10.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 11:10:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-809FADD1-F69E-44E6-B675-0740E593F934 Content-Transfer-Encoding: 7bit From: Gaurav Dawra Mime-Version: 1.0 (1.0) Date: Wed, 6 May 2020 11:10:03 -0700 Message-Id: References: Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "draft-ietf-lsvr-applicability@ietf.org" , "lsvr@ietf.org" In-Reply-To: To: Shawn Zandi X-Mailer: iPhone Mail (17A878) Archived-At: Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 18:10:09 -0000 --Apple-Mail-809FADD1-F69E-44E6-B675-0740E593F934 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not aware of any IPR Sent from my iPhone > On May 6, 2020, at 11:01 AM, Shawn Zandi wrote: >=20 > =EF=BB=BF > I am not aware of any relevant IPR. >=20 > -Shawn >=20 > Sent via carrier pigeon >=20 > From: Van De Velde, Gunter (Nokia - BE/Antwerp) > Sent: Wednesday, May 6, 2020 1:22:07 AM > To: draft-ietf-lsvr-applicability@ietf.org > Cc: lsvr@ietf.org > Subject: RE: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21,= 2020) > =20 > Can all authors please respond to the IPR question? > Only 2 from the authors have responded to the IPR request of =E2=80=9Cdraf= t-ietf-lsvr-applicability=E2=80=9D. > =20 > Brgds, > G/ > =20 > From: Van De Velde, Gunter (Nokia - BE/Antwerp)=20 > Sent: Tuesday, January 7, 2020 10:39 > To: lsvr@ietf.org > Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 202= 0) > =20 > Hi All, > =20 > =20 > The LSVR WG initiates a working group last call for "draft-ietf-lsvr-appli= cability-04". Please send your comments to the list before Tuesday January 2= 1. > =20 > https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/ > =20 > All, please reply on-list indicating if you're aware of an implementation.= > If not already completed, please reply on-list indicating if you're aware o= f any relevant IPR. > =20 > Brgds, > Gunter & Victor > LSVR WG co-chairs > =20 > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr --Apple-Mail-809FADD1-F69E-44E6-B675-0740E593F934 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not aware of any IPR

Sent from my iPhone

On= May 6, 2020, at 11:01 AM, Shawn Zandi <szandi=3D40linkedin.com@dmarc.iet= f.org> wrote:

=EF=BB=BF
I am not aware of any relevant IPR.

-Shawn

Sent via carrier pigeon

From: Van De Velde, Gunter (N= okia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Sent: Wednesday, May 6, 2020 1:22:07 AM
To: draft-ietf-lsvr-applicability@ietf.org <draft-ietf-lsvr-applic= ability@ietf.org>
Cc: lsvr@ietf.org <lsvr@ietf.org>
Subject: RE: WGLC for draft-ietf-lsvr-applicability-04 (to end Januar= y 21, 2020)
 

Can all authors please respond to the IPR question?=

Only 2 from the authors have responded to the IPR r= equest of =E2=80=9Cdraft-ietf-lsvr-applicability=E2=80=9D.

 

Brgds,

G/

 

From: Van De Velde, Gunter (Nokia - BE/Antwe= rp)
Sent: Tuesday, January 7, 2020 10:39
To: lsvr@ietf.org
Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 21= , 2020)

 

Hi All,
 
 
The LSVR WG initiates a working group last call for=
 "draft-ietf-lsvr-applicability-04". Please send your comments to the list b=
efore Tuesday January 21.
 
https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/<=
/span><=
/span>
 
All, please reply on-list indicating if you're awar=
e of an implementation.
If not already completed, please reply on-list indi=
cating if you're aware of any relevant IPR.
 
Brgds,
Gunter & Victor
LSVR WG co-chairs

 

_______________________________________________
Lsvr m= ailing list
Lsvr@ietf.org
https://www.ietf.o= rg/mailman/listinfo/lsvr
= --Apple-Mail-809FADD1-F69E-44E6-B675-0740E593F934-- From nobody Wed May 6 15:41:04 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFCF3A0DA0; Wed, 6 May 2020 15:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMTgDjicDLF6; Wed, 6 May 2020 15:40:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 121D33A0D9F; Wed, 6 May 2020 15:40:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWSii-0005Ru-Nc; Wed, 06 May 2020 22:40:52 +0000 Date: Wed, 06 May 2020 15:40:52 -0700 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?J=F6rg?= Ott Cc: tsv-art@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org, lsvr@ietf.org In-Reply-To: <158870511665.7532.2079643708622987385@ietfa.amsl.com> References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 22:41:02 -0000 j=F6rg: again, thanks for taking the time for a strong review. it is much appreciated. > could benefit from a bit of extra context and target application > domain in the introduction. E.g., explaining explicitly who would talk > L3DL to whom. how about the last para of intro getting a few more words along the line of In this document, the use case for L3DL is for point to point links in a datacenter Clos in order to exchange the data needed for BGP-SPF [I-D.ietf-lsvr-bgp-spf] bootstrap and continuity. Once layer two connectivity has been leveraged to get layer three addressability and forwarding capabilities, normal layer three forwarding and routing can take over. L3DL might be found to be more widely applicable to a range of routing and similar protocols which need layer three discovery and characterisation. > 1. Section 10 spells out a default HELLO interval of 60 seconds. With > a large broadcast domain, this may create quite a bit of > traffic. While this may not be an issue in well-provisioned data > center networks, a remark about sensible value ranges and the > implications may be worthwhile. Just to provide some guidelines to > implementers (who want to offer choices) and operators (who pick > them). If the configured destination address is one that is propagated by switches, the HELLO SHOULD be repeated at a configured interval, with a default of 60 seconds. This allows discovery by new devices which come up on the layer-2 mesh. In this multi-link scenario, the operator should be aware of the trade-off between timer tuning and network noise and adjust the inter-HELLO timer accordingly. > 2. Section 10 also suggest that in response to HELLO messages nodes > will issue OPEN PDUs to newly discovered peers. This appears to bear > the clear risk of an OPEN implosion when many system come up at the > same time. Shouldn't guidance be given to avoid repeated traffic > surges and possible losses and thus unnecessary delays? (I noted that > other places foresee exponential backoff when retransmitting OPEN and > other ACKed PDUs). added To ameliorate possible load spikes during bootstrap or event recovery, there SHOULD be a jittered delay between receipt of a HELLO and issue of the OPEN. The default delay range SHOULD BE zero to five seconds, and MUST be configurable. > 3. When the protocol applies fragmentation, should there be a note on > preventing bursts? likely part of this is our fault, as we did not mean 'fragmentation' in the classic "oops! we found a hop with a small mtu." does augmenting sec 6 as follow help? This is not classic 'fragmentation', but rather decomposition at the origin to allow PDU payloads larger than the frame allows. There are no intermediate devices capable of further fragmentation or reassembly. L3DL is carrying relatively small amounts of data on relatively high bandwidth links, and at a time when the link is not active with other data as it does not yet have layer three connectivity. So congestion is not considered a sufficiently significant risk to warrent additional complexity. > Section 7 on the checksum needs more detail. could you be more specific re in what area? > It also talks about a "suggested" algorithm but this should be clearly > mandated or way to choose one by means of configuration for a complete > data centre would need to be made explicit. The following code describes a suggested algorithm. This specification avoids mandatory to implement, algorithm agility, etc. What matters is that the same algorithm is used consistently in any deployment. > I also assume that the pseudo code on p.11 would benefit from a leader > '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might > fill the high order bits with '1's, which is clearly not intended. ok, but what kinky compiler are you using? :) result =3D (result >> 32) + (result & 0x0FFFFFFFF); result =3D (result >> 32) + (result & 0x0FFFFFFFF); > Section 11, p.17, second to last para ("If a properly > authenticated..."). From the text, it is unclear what is meant by an > "OPEN with the Serial Number of the last data received". If a properly authenticated OPEN arrives with a new Nonce from an LLEI with which the receiving logical link endpoint believes it already has an L3DL session (OPENs have already been exchanged), and the Serial Number in the OPEN PDU is non-zero, the receiver SHOULD establish a new session by sending an OPEN with the Serial Number being the same as that of the last sent and ACKed PDU. Each party MUST resume sending encapsulations etc. subsequent to the other party's Sequence Number. And each MUST retain all previously discovered encapsulation and other data. > I am curious about the error code, providing 16 bits for additional > explanation. Why not a text field? parsing by the receiver of error codes then becomes an larger unbounded chase. but this bit of syntactic sugar may be more pain than it is worth. free form or under-defined fields are too fertile a ground for interoperational incompatibility. opinions solicited. > Also wondering if repeated retries (due to failure, not lost packets) > could yield fast repeated transmissions. could you be specific about what you think could be improved in 12.1. Retransmission If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a VENDOR PDU, etc., and does not receive the ACK for a configurable time (default one second), and the interface is live at layer 2, the sender resends the PDU using exponential back-off, see [RFC1122]. This cycle MAY be repeated a configurable number of times (default three) before it is considered a failure. The session MAY BE considered closed in case of this ACK failure. > Section 15, should the KEEPALIVE interval have suggested (lower) > bounds? At the top of p.26, it says "One per second is the default", > the previous page at the bottom refers to the inter-KEEPALIVE interval > of ten seconds. Not sure if the two are the same, I suppose so. If > they are, the numbers should match. If they are not, we'll need some > extra text to explain the difference. whoops. how about ten seconds for both? > There are two spellings of "Encapsulation", capitalised and lower > case. Use one consistently. mind if we stall on this one? we were attempting to differentiate between the proper noun of a PDU type and normal use of the world. but looking at the text, it's a bit messy. full employment for rfc editors! :) > p10, first para: comprise -> comprising s/compare/comparing/ in [RFC1982] on DNS Serial Number Arithmetic for too much detail on comparing and incrementing a wrapping sequence number. pre-published text and xml are at https://git.rg.net/randy/draft-l3dl thanks again! randy From nobody Thu May 7 00:32:14 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5373A0C56; Wed, 6 May 2020 16:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBcjSZlO2ybV; Wed, 6 May 2020 16:40:53 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC9A3A0C54; Wed, 6 May 2020 16:40:52 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-196-134.hsd1.ma.comcast.net [73.47.196.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id A9A25139A0; Wed, 6 May 2020 23:40:49 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 8BB3C2014E48DE; Wed, 6 May 2020 19:41:03 -0400 (EDT) Date: Wed, 06 May 2020 19:41:03 -0400 From: Rob Austein To: Randy Bush Cc: =?ISO-8859-1?Q?J=F6rg?= Ott , tsv-art@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org, lsvr@ietf.org In-Reply-To: References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Message-Id: <20200506234103.8BB3C2014E48DE@minas-ithil.hactrn.net> Archived-At: X-Mailman-Approved-At: Thu, 07 May 2020 00:32:12 -0700 Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 23:40:55 -0000 On Wed, 06 May 2020 18:40:52 -0400, Randy Bush wrote: > > > I also assume that the pseudo code on p.11 would benefit from a leader > > '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might > > fill the high order bits with '1's, which is clearly not intended. > > ok, but what kinky compiler are you using? :) > > result = (result >> 32) + (result & 0x0FFFFFFFF); > result = (result >> 32) + (result & 0x0FFFFFFFF); Last I checked, the pedantic C syntax would be 0xFFFFFFFFU. But pseudo-code means whatever we define it to mean :) From nobody Thu May 7 00:34:48 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405413A0982; Thu, 7 May 2020 00:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqnYxm0EAxeN; Thu, 7 May 2020 00:34:42 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F1F3A07B3; Thu, 7 May 2020 00:34:40 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id 790BD1C084D; Thu, 7 May 2020 09:34:38 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 3CAA41C084C; Thu, 7 May 2020 09:34:36 +0200 (CEST) (Extended-Queue-bit tech_loxsz@fff.in.tum.de) To: Rob Austein , Randy Bush Cc: tsv-art@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org, lsvr@ietf.org References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <20200506234103.8BB3C2014E48DE@minas-ithil.hactrn.net> From: Joerg Ott Message-ID: <2329fb70-321a-2192-6346-2d3c8146c45b@in.tum.de> Date: Thu, 7 May 2020 09:34:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200506234103.8BB3C2014E48DE@minas-ithil.hactrn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 07:34:45 -0000 On 07.05.20 01:41, Rob Austein wrote: > On Wed, 06 May 2020 18:40:52 -0400, Randy Bush wrote: >> >>> I also assume that the pseudo code on p.11 would benefit from a leader >>> '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might >>> fill the high order bits with '1's, which is clearly not intended. >> >> ok, but what kinky compiler are you using? :) >> >> result = (result >> 32) + (result & 0x0FFFFFFFF); >> result = (result >> 32) + (result & 0x0FFFFFFFF); > > Last I checked, the pedantic C syntax would be 0xFFFFFFFFU. > But pseudo-code means whatever we define it to mean :) > Just leave it as is. If my dim memory on this serves me somewhat well, the issue arose with different compilers at some time in the past. Just checked and it seems fine for XCode now. I came across this multiple times, which is probably why it stuck. Jörg From nobody Thu May 7 01:20:59 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E79B3A0955; Thu, 7 May 2020 01:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQeeXLNnH0VS; Thu, 7 May 2020 01:20:53 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150099.outbound.protection.outlook.com [40.107.15.99]) (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 5B8413A07F7; Thu, 7 May 2020 01:20:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SSQTSGcc0Dz3YrVwLiunYgd1TcKXYXjlvpTFJLsuVAwIckIsZ9gPi93A1ZsIdmrqdRcAjhtV93jwbBHBE9mEO4Oe+DQGHtjDKf2ERsEvi6YXPmiK6AnCjVCQ4oOeVJOMIo34Vs3WJm5Nuos3OhKa1iUMsXlPokb1Z23bxm+P8Cs2hePQwKTTIobK5nOVhBJKsVGRx0YnZZ9bSWAEL+DzHC3GHyYBRsYrgwtcHPjPqG9k+EBbVftd1T857rSdpwasNDuNKtUuwkLH8QCRQ8edjieC8De9mEg8Ok1Fstct/DaE/vT+LuPRamZ9Ia2fupp2nKmvSbW+dw+1VJBlFEpUsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GUkp5MzXoMol9StJhy8x3cBmebi6AFKTWmb4nbnwxQo=; b=JelQURVdIqUT1Hk0Eorhq41tEcMA5zHaS5F/ljEAjQ7Yej+rrUkK/qdh/AVYW5tNDxHvcxq9jzmfaVsoNHLHalA1yTnEX+KT83ZTqZ5yD7PnDN4c1AJJcrytXYHpdTw6MC9nGeXCxc2npgjdPnZa601u4MO2dTkQjYGmauMW5oHilvHvI2u4aFodWwAitRHGMifB1xyZwLXNBIFFU8pzidxSrNeCWWctHLMx3bbilaMkgFX9lw8iJJezn9+G1Hs/MYA3xb02ltXrKd8arH3QjdyJ4DpLB00Y00YEoKP0j2wLuY/XXAVB1MuduCokbKzm12N4oRBHwSOSq5TrwHC6ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GUkp5MzXoMol9StJhy8x3cBmebi6AFKTWmb4nbnwxQo=; b=sQsbCCaFeMhGkn/r2XqJDnOGpTUKo1sT528sYMEr+iPBwE2ZkBYOrLjPQK8t49r6yIpjlO6r9zW2euWbXmLvShwmI9y9WuQP9kpQHg8n3HVJIeNlV7pO75fOrZ/nDxtk/r1dwnYyLqcgOPGmmdKY8YOZZ5lwvY41WSvV8m9EGnY= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB5969.eurprd07.prod.outlook.com (2603:10a6:208:10f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Thu, 7 May 2020 08:20:48 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%7]) with mapi id 15.20.3000.011; Thu, 7 May 2020 08:20:48 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" CC: Victor Kuarsingh , "draft-ymbk-lsvr-l3dl-ulpc@ietf.org" Thread-Topic: WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 21 May 2020) Thread-Index: AdYkSDxhl1hIWSVUSZuu5GZsy6VuRQ== Date: Thu, 7 May 2020 08:20:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:a03f:4efb:7600:24ec:cd9e:3f22:871e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 38fbd80e-49d1-4bbc-7e2d-08d7f25f8bf5 x-ms-traffictypediagnostic: AM0PR07MB5969: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w1DqkUUbTF21S6CnBaHFWJnekE+u+PEPJ91EI6VpOXj3IA2ygURHRBo3VGlu09WqpiJc++0AF+c+571u3Jk2RKIG2r0yQIvBKNZl+R/jRWKXkGRaHaN51c84ph5pUk2n7D2t9XPSIIbk/0ZTVg6DAZr6Jr/s7nF2QnbfAijte+BRy75QSOR6Gowo6WMHxi3qg5xv/wzHyOSL+oy0jQ7FlSwUu+LtYIcqrdj3SjkrcRgCEXQl52gwTSXnJF7CY7BSZ3BImuMahvTvzCBe8+s8Kj6UpXaMmPKSX1JJU0FyCYJX7RnGPyLJQtTI6kIH5AZEwwfYCRauP/2o98pgZ48l4skbBjbfAZPRs6BfKt/zk7OzbnMmGcb0CXQZp+qQUgshEBM2YVJr7MhyJoHw+ysHaqVRXSRpgcSZG3FHAPBg6WH/lwlTyXXlzvNK+79GrAFdrG0oy21KysKhkCnL1wUcuc5DIK2S4hViYmySt5BS9TQJ+q5M9QyWki5sheoVS8If0AuG32gATlK8+PatB4GJX5XJEGOcDArWfznxgqJNFvp/ZK6YTf38LWt/3TZepGbBW2Bnxf7fjPMq3/Fhtbub9Ep00AoOOy1ADOaLZnR4Nvw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(136003)(39860400002)(396003)(376002)(33430700001)(86362001)(54906003)(2906002)(9326002)(966005)(8676002)(52536014)(33656002)(4326008)(316002)(83290400001)(83310400001)(83300400001)(71200400001)(8936002)(83320400001)(83280400001)(166002)(5660300002)(6916009)(66446008)(186003)(478600001)(9686003)(6506007)(4744005)(66476007)(7696005)(76116006)(33440700001)(66946007)(55016002)(66556008)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: pq+ifFqeqxwS+GNVUjfP0V5/kouryq3osw/1dahqkPwMpUfl4BgmB7n5xGgn/CV7Xm1WbQ/zOjbetKWIVvaYk6/oUQFs7nB6M2pP+AcW7jnAYaRecjkjCTp8Em0oNeT4zOoJo6worG4lox3ACwvOc1gOvWlmYd/KC97nn7SNXO1vF/59SUbOQCx8PESIJWHuDMdbMWwAJf/wGSV5kO9Sx6J4e124IHmcycDo0Fn6ge5++9snhketnbgSBuTf3ZBk73ThpexpghUgfdTs2PP+aH9G8dwwXAB4mfv2pFCXYNi0GWnHf20jKOOIM6ygEBhQR2dJmSR+5oqfZR2wFAbeBlhIeXG1BNdWLaD7m5Ji6saCrCRgAmzn0AhWAqoFZsikY7b3xj+SOejVcAoC0lvx2asYAsScHw0akbpJtwhOCr57VU8yNadSTxJrqj+5O5HT8iy4oDHdGNq7QHkrXKL9SAkrYDkpqnJtPzV7I+VNB8iUPviENj9aFTrrzv7co9kf/KzUBL9MBzUP+NDPFIkeIkbOJ2kxTndGTOh6kkENA9W0VFVz4dJGxd3ZCgcR7QokO3kAZUrv7oUe0aLdezt6mPtMNqGaIp1W2D2l4mEHYxePRiNBef68c3uapzEeXdBUDYEGzlA5EHjAJ/fYBYI7jc9m5ByKg/I/OI+iwBq+epgPo7fHA87WvDApno0BJPwEES3sXDcH58UYS6b7PfU/UGQmQYNpD/Vg1/KYK8R6VccsCdtIzR8/YREG0mxkposdCGUMCXOs/xPUatgW8q2s4RVNOKhVf68kd0ea/KP0kj2aQFxeb8Upi0QJyUHo1X1woSujbSRatk/UR38TuZNGqeerPFZ8SZ4/lhMOnu3AIAzuTRG0peR9KDEpWguqCywW x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB638693562C873E9CFC979908E0A50AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 38fbd80e-49d1-4bbc-7e2d-08d7f25f8bf5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 08:20:47.8906 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c7LQ10DMr6jWjK9iSiQil4FCsRRB5cq12rdw67zWLO4qwGS7j0ZUJ/stS8GHeNy8LdmRgjW+DNVaocimeYhacWUDtKGURi5QTc+wpHOmVMI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5969 Archived-At: Subject: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 08:20:56 -0000 --_000_AM0PR07MB638693562C873E9CFC979908E0A50AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This begins a 2 week WG adoption call draft-ymbk-lsvr-l3dl-ulpc-03 (May 7 -= May 21) https://datatracker.ietf.org/doc/draft-ymbk-lsvr-l3dl-ulpc/ During your discussion in the WG Adoption Call, the chairs are looking for = more context as only a 'yeh' or 'ney'. Please indicate the following things: 1) Support to adopt draft "draft-ymbk-lsvr-l3dl-ulpc-03" as LSVR WG documen= t? 2) Are there any technical issues with this draft? 3) Which are current pain-points in the draft requiring additional content = and technical attention? 4) What is missing from this draft? The authors (or anybody else) of this draft should send their IPR statement= s in response to this email. Kind Regards, Gunter & Victor LSVR WG co-chairs --_000_AM0PR07MB638693562C873E9CFC979908E0A50AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,<= /span>

 

This begins a 2 wee= k WG adoption call draft-ymbk-lsvr-l3dl-ulpc-03 (May 7 – May 21)

 

https://datatracker.i= etf.org/doc/draft-ymbk-lsvr-l3dl-ulpc/

 

During your discuss= ion in the WG Adoption Call, the chairs are looking for more context as onl= y a 'yeh' or 'ney'.

 

Please indicate the= following things:

1) Support to adopt= draft "draft-ymbk-lsvr-l3dl-ulpc-03" as LSVR WG document?=

2) Are there any te= chnical issues with this draft?

3) Which are curren= t pain-points in the draft requiring additional content and technical atten= tion?

4) What is missing = from this draft?

 

The authors (or any= body else) of this draft should send their IPR statements in response to th= is email. 

 

Kind Regards,<= /o:p>

Gunter & Victor=

LSVR WG co-chairs

 

 

 

--_000_AM0PR07MB638693562C873E9CFC979908E0A50AM0PR07MB6386eurp_-- From nobody Thu May 7 02:27:41 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0B3A0B36; Thu, 7 May 2020 02:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOg-QhWbNA_V; Thu, 7 May 2020 02:27:35 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50133.outbound.protection.outlook.com [40.107.5.133]) (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 E2DC33A0AE2; Thu, 7 May 2020 02:27:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X39raEMpVkJrP2UxCBva+fzr1+SJfTmGgB89j32pz1dLsIr8xAXrFgHnita1hCXkXRTqkNTUsIm/oVCsKiTt07GBeISPrQM01LNLwvtMIsfee6lAcLSw6HQ+riutUGivKgZl/wGl50l+riuLSCfNwQct+eEnI+LkfjJ+asGcW3r63CZE2Ti2CZwhecjdFcJoGSaZEBKm7pEhFnwyXgdDmaGkBFvj9A8b7Cy1fro9EkbBZht6qvUqhvg0RMaiZLpn0kHJCA1+ciNaUB5pl1jVBGeiZBB/DdlTyiOcuis+2US4DNCcQnfVKs3rhJg0HhHCOEWKRiA6oUm2mi084jTkPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VlAzRZ18C8e/8uRh3zlYwSz4NbSuLJVdw8/aU4kEt0M=; b=mzEAnX8Vjs+Gx10WNOiLad/noFA/THIYPEwcJUsz4BxsPzsoVydXaZOIkNGsl8G+PPk5PGULHo/mdhW3oiHU3Z+etfltLUMDxjLvhziJRwXfDAx2rmN5D9RDD8U98TSel7QDBdS9bVdavYMMeJnFYXvA4dBoiZfI2x7QkwTxRKKP7rhStgpSaTdMWMM3ecHB0EzaLmvnjs4lV27s8P5EGbfVJBTIybA/yWaFhdPaCXjlKfuaeYMMgkpHQ2LX1N10s9z7NiQd2utjWKCiOhWl3qli7YIklTUeqwLocHKsy97uANaUF4HEcDPht5blaPui+wY77G4i9Qt4dwNFWYaT8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VlAzRZ18C8e/8uRh3zlYwSz4NbSuLJVdw8/aU4kEt0M=; b=EOtLQmN3i2Wg15BlotD9a/6FE6M0AgqqAAxGBBy1fLoYGyVpThQVftJX5S7Y+IMjhJsbpsdQpb8lDRmjRaj8UNqZwkPGQdi/OCnfRDbp4IiE5Zs4pfuoYukZ/jxB0AJV+qGsyW19PX2g1/qhZkEMRi4qBmD+UoUZ7pzT5lwfgqo= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB6289.eurprd07.prod.outlook.com (2603:10a6:20b:151::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Thu, 7 May 2020 09:27:27 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%7]) with mapi id 15.20.3000.011; Thu, 7 May 2020 09:27:27 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" CC: Victor Kuarsingh , "draft-ymbk-lsvr-l3dl-signing@ietf.org" Thread-Topic: WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) Thread-Index: AdYkUVDT0BnEGXp4RCOd+OLt56rHlA== Date: Thu, 7 May 2020 09:27:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:a03f:4efb:7600:24ec:cd9e:3f22:871e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c1c0b503-4da1-439d-bf94-08d7f268dbc5 x-ms-traffictypediagnostic: AM0PR07MB6289: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EnOOu2Hl7v8NzxL3cwKot0L4qxbaO65XIn5CjZ1iHIH+qT/Tc3PEaP8hbdn2S3qnt2mJYjZVVzGbSKm9Kkw+5EtqWX7/NInT9VZMQwKxFffw6oFNeANAKs+71Iq/PaT3oS4Pn1E3FkOKkpu424Nl5ZmXjnGn4zf5xf6QqzGPuUmADLEb4E/kHkowx7QRVYMcTi9HmRTzsxnQPt7PTw6iasOklV1TerCRffJhMQtspJbULa4Kku0y7anlgTUMTur2XLwlA+oB5pd0oZ71QDLzZgLzDCuPQsk6VilWM1gK2ITsQBCS6VSvlwAAHcvO3IhODSXed3rDar1plz6L0nxwVqgZ+wg7EiiKyBYb+Nq8ffGjw26WnyuffXP0vGHrqGqV81/g7EUjFLTnBSTs5IyazuAex97aHi3Ospy033HyFcRskklosLXcqTUiggFmQJul1ytuSLJ0FJrRKVdqViDeAamJbPydU2pElBT3n255cfHesI+Z3cHUiEWEulCEmeCofXwwWS/3UJgj+yEdgGya/qVYJ0VirzDOGNfvfu5wCsAy5Skg/TuqdyFkGzPS2geywg4cjCe9gzu7WlpqCLtuZXw87ffMlNCoi10VTis77bc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(33430700001)(478600001)(966005)(71200400001)(52536014)(9326002)(55016002)(4326008)(8936002)(9686003)(83310400001)(66446008)(33656002)(83300400001)(186003)(83290400001)(66556008)(66476007)(83280400001)(83320400001)(8676002)(76116006)(64756008)(316002)(166002)(6916009)(86362001)(66946007)(2906002)(4744005)(33440700001)(5660300002)(7696005)(6506007)(54906003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /OOPCIFFI3R4BaTxfuDRSluAYVNyS60vK/z898eL8AVZSYhamHimDJ9ZmV721uIzuITdKi5nrQmUuY/z+qQI1uWi9XX3KKx7aU1jHDVMZbTPRtlRJJeEuBfPixx7UKmP3Y7gnucVZAKSPugoZ4OgipFUqseiN9SkzGL6XpLf5WZJfqHP72zjszBII9UxNGkB0n7VmNm7rn7U25S9bd5Iel9h5NkNT42yYIW1plVz9U6i7Niwm54Infe66xllxEq2l3tcVqfRglgm5boRvkubEd6QukaF0LWNw8RPRFAPtk5rM5oeis37RVrvU0I+TU+DA/+tsUn/MqExixz7fCWo3CaFhgTBOj+wME2KR6QJIq7JMaJu3NXLB4O9T3yziSDzDx/3VcaiCvFaHw+MN25jKr/xxGw5dBZptIsA/ha6NVpKAttZT+uY2ZiIIfsGHU1Jng2LZeiyuCao5PbXFSkIMnaU4Weta1ns399NiHly22hjmX34etkUrzBtwsz1Wn2iW4JHLsiAN9xHyhURi0R6BT1Went99uEYZZNpvRugdsUwn7mrJQA3geT/qnEH6tYKs+0gxhHgepr3G/WCRmVLDuRYL30GYynr0Vn3da0ZMFQR1hpdYo0UYHCMZg1PT6RJJqNntLGyWL74wROWEgLyFjGdGH8sI06t59gjdyBPH8MaizkgocG2Z5ItKhee5qSP5M3C8en6rrm7lRz2J8wO5fhqRPRC+AepaSVrJwtyDjZgwwMT+eR12jAliZIhfh6eZsn1u97ou7Y6AdfXSlI+0KlFztdEO2Zqpx+HSg2+/re49kx2N2mvnXAMwe1tqIsJWWxPAvU43gr+GjouDzuB8Q6wEudvaM5Gyq41FvO/mR3uLhJXJ1AEn51JT6YXjqpN x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB6386F487559203E437F52E40E0A50AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1c0b503-4da1-439d-bf94-08d7f268dbc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 09:27:27.3626 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KnG4P13fzjn4MKJkoozYw0FTVO75Cteeg4qCdNcrux7jkhE8uD+eLGI0fW43Ee0ZtT6gbZB5SHwsZoO7jz3eoHZ6Z1ZKHyds/WTXhD49jXg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6289 Archived-At: Subject: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 09:27:38 -0000 --_000_AM0PR07MB6386F487559203E437F52E40E0A50AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This begins a 2 week WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (= May 7 - May 21) https://tools.ietf.org/html/draft-ymbk-lsvr-l3dl-signing-01/ During your discussion in the WG Adoption Call, the chairs are looking for = more context as only a 'yeh' or 'ney'. Please indicate the following things: 1) Support to adopt draft " draft-ymbk-lsvr-l3dl-signing-01" as LSVR WG doc= ument? 2) Are there any technical issues with this draft? 3) Which are current pain-points in the draft requiring additional content = and technical attention? 4) What is missing from this draft? The authors (or anybody else) of this draft should send their IPR statement= s in response to this email. Kind Regards, Gunter & Victor LSVR WG co-chairs --_000_AM0PR07MB6386F487559203E437F52E40E0A50AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,<= /span>

 

This begins a 2 wee= k WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (May 7 – May 21)

 

https://tools.ietf.or= g/html/draft-ymbk-lsvr-l3dl-signing-01/

 

During your discuss= ion in the WG Adoption Call, the chairs are looking for more context as onl= y a 'yeh' or 'ney'.

 

Please indicate the= following things:

1) Support to adopt= draft " draft-ymbk-lsvr-l3dl-signing-01" as L= SVR WG document?

2) Are there any te= chnical issues with this draft?

3) Which are curren= t pain-points in the draft requiring additional content and technical atten= tion?

4) What is missing = from this draft?

 

The authors (or any= body else) of this draft should send their IPR statements in response to th= is email. 

 

Kind Regards,<= /o:p>

Gunter & Victor=

LSVR WG co-chairs

 

--_000_AM0PR07MB6386F487559203E437F52E40E0A50AM0PR07MB6386eurp_-- From nobody Thu May 7 04:21:57 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3CB3A00B2; Thu, 7 May 2020 04:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCzi-fQ-m3W2; Thu, 7 May 2020 04:21:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 47C6A3A00C1; Thu, 7 May 2020 04:21:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWeb4-0003Zm-Sb; Thu, 07 May 2020 11:21:47 +0000 Date: Thu, 07 May 2020 04:21:46 -0700 Message-ID: From: Randy Bush To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "lsvr@ietf.org" , Victor Kuarsingh , "draft-ymbk-lsvr-l3dl-ulpc@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 11:21:55 -0000 thank you. and for the adoption call for draft-ymbk-lsvr-l3dl-signing randy From nobody Thu May 7 05:03:55 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF283A05DE; Thu, 7 May 2020 05:03:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsvr@ietf.org Message-ID: <158885303401.21145.15811342894094205671@ietfa.amsl.com> Date: Thu, 07 May 2020 05:03:54 -0700 Archived-At: Subject: [Lsvr] I-D Action: draft-ietf-lsvr-l3dl-04.txt X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:03:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Vector Routing WG of the IETF. Title : Layer 3 Discovery and Liveness Authors : Randy Bush Rob Austein Keyur Patel Filename : draft-ietf-lsvr-l3dl-04.txt Pages : 35 Date : 2020-05-07 Abstract: In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer 3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer 3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-04 https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-l3dl-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsvr-l3dl-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 7 05:06:22 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36D83A079A; Thu, 7 May 2020 05:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rq5FORRO_Z4; Thu, 7 May 2020 05:06:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7BDD93A05DE; Thu, 7 May 2020 05:06:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWfI8-0003fK-Fg; Thu, 07 May 2020 12:06:16 +0000 Date: Thu, 07 May 2020 05:06:15 -0700 Message-ID: From: Randy Bush To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "tsv-art@ietf.org" , "draft-ietf-lsvr-l3dl.all@ietf.org" , "lsvr@ietf.org" , Joerg Ott In-Reply-To: References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Lsvr] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 12:06:21 -0000 gunter et alia > Can you refresh the draft-ietf-lsvr-l3dl-03 document and I'll launch > WGLC on that document. i have published -04 after J=F6rg Ott's early transport review. i am not completely comfortable that it is of wglc quality, though i never am. i really would deeply appreciate if a few folk would take the time to give it a read. thanks. randy From nobody Thu May 7 11:22:09 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3453A0CFB for ; Thu, 7 May 2020 11:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 5DsNGXncxk-G for ; Thu, 7 May 2020 11:21:59 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866153A0CFA for ; Thu, 7 May 2020 11:21:58 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id w20so7417907ljj.0 for ; Thu, 07 May 2020 11:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Aa+2EkZBv3PaajUcwaK8Cs5OZ6AzWdknZ6uPJFjpSJI=; b=rGIUZ28AmIF4prbDBqsZDWPTC3KFcV2Owyqjtnk6wOBxLTsWBoAFPBbUSTFlXeGOY4 ea/7B2CjWXam/qaPrU3wmm7CC70Jt623TwByyBIU5tGW1kvd9rf/IJWrHvVPHDLZH5JG 9TJ8pKy5GRh56LkkvajwgSSVNki47+uU5HCD7Bz9kYtKL1Eg7jPBlptykDrS1Ptv0BaX ZuKATOqgtStkLG2jQLR6ZKk6n53JaBDikvAr9UOpUepKd0wcRMjIpYVhpsmd4jomCj4l 3hFF5R2EDRed45VaY0beDMxXJMq0UirGFaNd41K2YcuiaY/AlBF/lV5vuaqY2NEibV4L MWEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Aa+2EkZBv3PaajUcwaK8Cs5OZ6AzWdknZ6uPJFjpSJI=; b=DN59rntybjXPPM3yF7PcmFtDfitrojz0hwXC4FXvwT6mZbK8BBHQ8phyuRuCigAUWc ii44AT9MbIpOYa+Yd8gdc6QhUYCm8csQrjUOGoInbWW8BJ2L5mowaiJcwybBhvQUhDO/ c5OGCk9WOSdW5whDoAdX5cEBclLXDbJ9OBhToFDWj3oeeNVoFpTeUH9SE0fiQPtPjJ1f 7KbHvK45wwkqsZzL+JrsV4sBrFsBQwZZkVJxg0Z3kfvBFfTkNV2FoW6RO7gsTLDRNSEh vP9TYumz40FFWVE8lCFViT0B2T7o5b7j07wLhw8lEda3SVUUjxbxxotDVPUnnIHXll4g Z13w== X-Gm-Message-State: AGi0PuaWM9XZEptfaGDAMFIj+6L0Nuk3AkZS2JRF63PejKWJHnGN5A4f cbRtF0wFHfXJV71O+H/DljQjYMAbcLtqYyb93dg198jcFTI= X-Google-Smtp-Source: APiQypK4cc91ZBsWfua1e3mRVdVzjgLyhmUzbq9v1fl5QyJI4kKMyDlm6gXNYEBNeIcx+g8vHzazdybw7XgWE5juuug= X-Received: by 2002:a2e:9785:: with SMTP id y5mr8548428lji.66.1588875715855; Thu, 07 May 2020 11:21:55 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Thu, 7 May 2020 14:21:19 -0400 Message-ID: To: lsvr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 18:22:07 -0000 1) Support to adopt draft "draft-ymbk-lsvr-l3dl-*" as LSVR WG document? Yes -- I support the adoption of BOTH draft-ymbk-lsvr-l3dl-signing and draft-ymbk-lsvr-l3dl-ulpc. I reviewed these documents (ulpc more thoroughly than signing) while following the IDR BGP autoconfig work. 2) Are there any technical issues with this draft? Only minor / editorial / opinions... I *do* think that the last paragraph in Security Considerations of ulpc should remain as is though,... Nit: "Any keying material in the PDU SHOULD BE salted ad hashed." - "and". 3) Which are current pain-points in the draft requiring additional content and technical attention? A: I suspect that there are missing attributes that should be added, but I cannot think of any critical ones. B: I'm not 100% sure what the relationship is between this and the IDR BGP AutoConf work is - this looks like it provides much of the building blocks that the IDR work might use, but where is the line between them? C: It feels like more text is needed around "If a peering address has been announced as a loopback, a two or three (one or both ends could be loopbacks) hop BGP session will be established. " -- how do I know it is announced as a loopback? How do I know what route to install to reach the loopback? etc. Apologies if these have already been discussed and I missed them... 4) What is missing from this draft? See above... W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 7 12:16:48 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4B33A09F6 for ; Thu, 7 May 2020 12:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94bXEn6BCdF9 for ; Thu, 7 May 2020 12:16:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C3C3C3A09F4 for ; Thu, 7 May 2020 12:16:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWm0f-0004vG-A4; Thu, 07 May 2020 19:16:41 +0000 Date: Thu, 07 May 2020 12:16:40 -0700 Message-ID: From: Randy Bush To: Warren Kumari Cc: lsvr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 19:16:46 -0000 thanks for the support > I *do* think that the last paragraph in Security Considerations of > ulpc should remain as is though,... :) > "Any keying material in the PDU SHOULD BE salted ad hashed." - "and". thanks > A: I suspect that there are missing attributes that should be added, > but I cannot think of any critical ones. i admit to guilt-free obsessive minimalism > B: I'm not 100% sure what the relationship is between this and the IDR > BGP AutoConf work is - this looks like it provides much of the > building blocks that the IDR work might use, but where is the line > between them? ships in the night but i agree that this is useful as an example in the idr-dt. fwiw, i have queued homework over there. > C: It feels like more text is needed around "If a peering address has > been announced as a loopback, a two or three (one or both ends could > be loopbacks) hop > BGP session will be established. " -- how do I know it is announced > as a loopback? How do I know what route to install to reach the > loopback? etc. l3dl 13.2 tells you it is a loopback 13.2. Encapsulaion Flags The Encapsulation Flags are a sequence of bit fields as follows: 0 1 2 3 4 ... 7 +------------+------------+------------+------------+------------+ | Ann/With | Primary | Under/Over | Loopback | Reserved ..| +------------+------------+------------+------------+------------+ so how about For each BGP peering on a link here MUST be one agreed encapsulation, and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 Announcement PDUs. If a peering address has been announced as a loopback, i.e. MUST BE flagged as such in the L3DL Encapsulation PDU, a two or three hop BGP session will be established. Otherwise a direct one hop session is used. needs 2119 language MUST HAVE BEEN :) randy From nobody Thu May 7 13:48:48 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE53A0DA7 for ; Thu, 7 May 2020 13:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=kumari-net.20150623.gappssmtp.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 qBAdzuBZdspR for ; Thu, 7 May 2020 13:48:41 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 D84033A0DA5 for ; Thu, 7 May 2020 13:48:40 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id a21so7805679ljb.9 for ; Thu, 07 May 2020 13:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PeLYmIkyxt2+KvE17Thk/2aV1RU0EEP4rJGzu4yCmsY=; b=d33aqErSSgPT2A6K7d5o0L98eeUNriimcKEBXw2R+FE9Ryz3MnjePbctCkwFqH9e9F fSax4SN6X89O8JxG4PMh0Nfu03M5tbwSc2Q67OpEJchMnJtcGnNy6vrs+z0Z/n4duouM XnzZTFND86OqANudR+iDUs///p5NRz2Yf/GP1JQHSh6GlNpM5jGe4Fh9qj1wm6aMixAz kGvU380xwSvIfKBgrn0l4HGESr+hv+bK+cx/XV6543DYTEL1a57e+MI+iJUkSn+l0eGc SWr+8LcNhWw2dYU6RvwqocF+DFu2zOn4YxHzPe3DjCz7riSLDxqeREkoqZNc/FTDEyJ4 MVhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PeLYmIkyxt2+KvE17Thk/2aV1RU0EEP4rJGzu4yCmsY=; b=p3SI0f/REeDiABtZU18ygc9gZ0fCjGuNzJHH7LPF2hNpG4K8/ROhq+ZsS+kOuKnc1Y 2fbkGB0rXxavhXH9O7URyP5mNdCX0sY/Bafxnho7G/Fv4SzTzMWYUwhPrFsXW7HmODFe EoHoFLQOQ21A3y2aX51A2v3XhpR0HLjJQZk6zzR2SW0isRPGqr/lTSkoTil+/Dq8wcrV dC0nSsTSJWhZjepWRGI0b4mQpiyC+x8SS/O5a7nVTwtwpupRU1dAC0seRrTUwo8Q8Z8b tLhKFIwhBio1Lz3LSLUzmgx39na7ALUf5kfqEE+1JfUh+8vTjknINdzpglvFNtKh9D3S Of7Q== X-Gm-Message-State: AGi0PubxIYNM6VQMVJjwMVcLK94y+jpITSwO6bCQlV8KOptgJQvbhBkv NDvxi2wVZIS89MWSmar/DW1D9/5sqB062BMz/aLr/Q== X-Google-Smtp-Source: APiQypJrO299gfQmiuwGiBMrO3T7ElIuIGRSlXUcq6ngf4BG53cXgSFMXF1tKtyp0kmmvp6Z/BxN58Ac3iKfIGYFieg= X-Received: by 2002:a2e:9048:: with SMTP id n8mr9752834ljg.122.1588884518210; Thu, 07 May 2020 13:48:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Thu, 7 May 2020 16:48:01 -0400 Message-ID: To: Randy Bush Cc: lsvr@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 20:48:46 -0000 On Thu, May 7, 2020 at 3:16 PM Randy Bush wrote: > > thanks for the support > > > I *do* think that the last paragraph in Security Considerations of > > ulpc should remain as is though,... > > :) > > > "Any keying material in the PDU SHOULD BE salted ad hashed." - "and". > > thanks > > > A: I suspect that there are missing attributes that should be added, > > but I cannot think of any critical ones. > > i admit to guilt-free obsessive minimalism Fair 'nuff. > > > B: I'm not 100% sure what the relationship is between this and the IDR > > BGP AutoConf work is - this looks like it provides much of the > > building blocks that the IDR work might use, but where is the line > > between them? > > ships in the night > > but i agree that this is useful as an example in the idr-dt. fwiw, i > have queued homework over there. > > > C: It feels like more text is needed around "If a peering address has > > been announced as a loopback, a two or three (one or both ends could > > be loopbacks) hop > > BGP session will be established. " -- how do I know it is announced > > as a loopback? How do I know what route to install to reach the > > loopback? etc. > > l3dl 13.2 tells you it is a loopback Doh, I missed that... > > 13.2. Encapsulaion Flags > > The Encapsulation Flags are a sequence of bit fields as follows: > > 0 1 2 3 4 ... 7 > +------------+------------+------------+------------+------------+ > | Ann/With | Primary | Under/Over | Loopback | Reserved ..| > +------------+------------+------------+------------+------------+ > > so how about > > For each BGP peering on a link here MUST be one agreed encapsulation, > and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 > Announcement PDUs. If a peering address has been announced as a > loopback, i.e. MUST BE flagged as such in the L3DL Encapsulation PDU, > a two or three hop BGP session will be established. Otherwise a > direct one hop session is used. Close but no cigar -- I suspect I didn't fully explain my (second) question If router A says that I should peer with the loopback address 192.0.2.1, I need to know how to route *to* that address (this is sometimes confusingly called a recursive route, a term which has always seemed silly to me) -- is this route something that l3dl-ulpc should talk about, or is that something that a different document covers, or am I just off in the weeds? Whatever the case, I support adoption. > > needs 2119 language MUST HAVE BEEN :) You are welcome to write a -bis :-) W > > randy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 7 14:07:01 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717BB3A0E3F for ; Thu, 7 May 2020 14:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 aaveqW1tA7bw for ; Thu, 7 May 2020 14:06:46 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905263A0E58 for ; Thu, 7 May 2020 14:06:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1D51B300B69 for ; Thu, 7 May 2020 17:06:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z_FhGAdX5jTX for ; Thu, 7 May 2020 17:06:38 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id EF7A4300A01; Thu, 7 May 2020 17:06:37 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: Date: Thu, 7 May 2020 17:06:39 -0400 Cc: draft-ymbk-lsvr-l3dl-signing@ietf.org, gunter.van_de_velde@nokia.com, victor@jvknet.com To: lsvr@ietf.org X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 21:06:54 -0000 While I would prefer the PKI-based signature mechanisms, I understand = the reasons that the TOFU mechanism is included as well. For this = reason, I support adoption as is. I believe that the document needs to have a normative reference to RFC = 5280 for certificate validation. Russ --- Original Message --- Subject: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to = end 21 May 2020) From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" = To: "lsvr@ietf.org" CC: Victor Kuarsingh , = "draft-ymbk-lsvr-l3dl-signing@ietf.org" = Date: Thu, 7 May 2020 09:27:27 +0000 Hi All, This begins a 2 week WG adoption call for = draft-ymbk-lsvr-l3dl-signing-01 (May 7 - May 21) https://tools.ietf.org/html/draft-ymbk-lsvr-l3dl-signing-01/ During your discussion in the WG Adoption Call, the chairs are looking = for more context as only a 'yeh' or 'ney'. Please indicate the following things: 1) Support to adopt draft " draft-ymbk-lsvr-l3dl-signing-01" as LSVR WG = document? 2) Are there any technical issues with this draft? 3) Which are current pain-points in the draft requiring additional = content and technical attention? 4) What is missing from this draft? The authors (or anybody else) of this draft should send their IPR = statements in response to this email. Kind Regards, Gunter & Victor LSVR WG co-chairs From nobody Thu May 7 14:19:53 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC9F3A0E2A; Thu, 7 May 2020 14:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNV6Ffw1cHMR; Thu, 7 May 2020 14:19:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A2D193A0E1B; Thu, 7 May 2020 14:19:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWnvJ-0005Hz-CL; Thu, 07 May 2020 21:19:17 +0000 Date: Thu, 07 May 2020 14:19:16 -0700 Message-ID: From: Randy Bush To: Russ Housley Cc: lsvr@ietf.org, draft-ymbk-lsvr-l3dl-signing@ietf.org, gunter.van_de_velde@nokia.com, victor@jvknet.com In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 21:19:30 -0000 > I believe that the document needs to have a normative reference to RFC > 5280 for certificate validation. easy. and i have a stashed review from you that still needs to be incorporated. to be a bit more transparent i am sufficiently old skool that i do not move to adopt a document on which i am co-author. it feels tacky. and i think adoption is how one gets it into the wg to actually work on it, not to rubber stamp what has been discussed for three years in the call for adoption. so i expect this and l3dl-ulpc will both need more work once adopted randy From nobody Thu May 7 14:29:31 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12653A0B68 for ; Thu, 7 May 2020 14:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppbhsOeGp8xZ for ; Thu, 7 May 2020 14:29:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 7BAF83A0B49 for ; Thu, 7 May 2020 14:29:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jWo56-0005Jm-80; Thu, 07 May 2020 21:29:24 +0000 Date: Thu, 07 May 2020 14:29:23 -0700 Message-ID: From: Randy Bush To: Warren Kumari Cc: lsvr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 21:29:29 -0000 >>> C: It feels like more text is needed around "If a peering address has >>> been announced as a loopback, a two or three (one or both ends could >>> be loopbacks) hop >>> BGP session will be established. " -- how do I know it is announced >>> as a loopback? How do I know what route to install to reach the >>> loopback? etc. >> >> l3dl 13.2 tells you it is a loopback > > Doh, I missed that... > >> >> 13.2. Encapsulaion Flags >> >> The Encapsulation Flags are a sequence of bit fields as follows: >> >> 0 1 2 3 4 ... 7 >> +------------+------------+------------+------------+------------+ >> | Ann/With | Primary | Under/Over | Loopback | Reserved ..| >> +------------+------------+------------+------------+------------+ >> >> so how about >> >> For each BGP peering on a link here MUST be one agreed encapsulation, >> and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 >> Announcement PDUs. If a peering address has been announced as a >> loopback, i.e. MUST BE flagged as such in the L3DL Encapsulation PDU, >> a two or three hop BGP session will be established. Otherwise a >> direct one hop session is used. > > Close but no cigar -- I suspect I didn't fully explain my (second) question > If router A says that I should peer with the loopback address > 192.0.2.1, I need to know how to route *to* that address you will likely want to forward, not route , to the peer's address which was marked as Primary, iff it is in a subnet which you also share. if not, pick a forwarding next hop that is in a subnet you share. if there are multiple choices, you could have signaled which subnet in an Upper Layer Protocol Configuration PDU Attribute. if you share no subnets, then you do not have a valid underlying l3dl session see l3dl 13. The Encapsulations .... Further, to consider a logical link of a type to formally be established so that it may be pushed up to upper layer protocols, the addressing for the type must be compatible, e.g. on the same IP subnet. yes, you have to hold a lot of gorp in your head. sorry. but some clarifying text might keep others from falling down this rabbit hole. thanks. randy From nobody Fri May 8 02:34:43 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D683A095A; Fri, 8 May 2020 02:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj821cUja_sJ; Fri, 8 May 2020 02:34:39 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130123.outbound.protection.outlook.com [40.107.13.123]) (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 7D4273A0959; Fri, 8 May 2020 02:34:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n8NinJRXN02mROJ9g0bxIZjiQqQbffCSwq/kcmIjmUmWKT5CSWWImrmUmm8XCbnE6bqFUnB66XGjKMRkw1pksllQWnPyKz9kERFaYXFHwjwtUwAs2vyR4cyyi5BE5lBp84Oz+41tz6OLylPvyjkGMAgucI6f81RA3zgllb+uIQh4AMG+BsXf0pqSJ6O/ouDMkkF0/6usANDip74d4da8htGqlHYUL3Kn7UM99XPjwg0nq3UGjOfKv+bwAW4pSP/I9TqmAKZdRySTfjRxrfOxYQzP0H08A62jkeSz2N/pDeUb3NOUJuDXScKi6HjiM8EMqi488bXoB5zRjsjbPX/8hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OMZbpwDJXUyErojTp/R4Oy4GAe0KO38SF3V0kI+4yEI=; b=ISrr6ezAnvfcSBh1b/i9kSYF8tS1y/1sMjzLkcVEZkijfad5uz+OX7MnByXeaG2x1N9V+7AHQeq9/uTzcGpx1Unotqv6Uk/nIGfzLDOtA5ibxS1rbmPYZLIQhyyfXnSdBFXWE0KwJ04f9JnRgjKSXKY5W1IWVOe35KGd+FkWRDRDkBHVerLavZX37WgYx8UqbF0DJie9vemb/QT9FMeU+1NU4Dv63IOeQMACWq1JQ9L4Gx9SlhQb2XrlqbzvQ1VqQ+1EifpIfdEdvbChZ/SVAufzdxviK/0/WFQxpkG6qVl6uJ6pz6R1zhZ/F683HEuhbPMhXxHFTkvonulBes7q/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OMZbpwDJXUyErojTp/R4Oy4GAe0KO38SF3V0kI+4yEI=; b=qudx/gd47pMRzN9050rw4c8pSsx1Den7uUnoBBGlmsm4zTfesj8jeO9/RQCSdDaFhKcOft3KeLqu+88oBT0JBD1TgHKmzJH/bTFX+pp5WgLxs4zO2tg5b+VlHBrMX59SrpOKpuHf6VcvUcZ9pSBi41qV4Eu/7XVeGfn3fcxsaRw= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB4771.eurprd07.prod.outlook.com (2603:10a6:208:6c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.22; Fri, 8 May 2020 09:34:41 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%7]) with mapi id 15.20.3000.013; Fri, 8 May 2020 09:34:35 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" CC: Victor Kuarsingh , "draft-ietf-lsvr-l3dl@ietf.org" Thread-Topic: WGLC for draft draft-ietf-lsvr-l3dl-04 (to end May 22, 2020) Thread-Index: AdYlG5rhZs7dgZyWSY+SjVZl7zAOGg== Date: Fri, 8 May 2020 09:34:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:a03f:4efb:7600:6df8:75ed:e503:93bf] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 73c7d486-91d8-4be3-14cb-08d7f3330538 x-ms-traffictypediagnostic: AM0PR07MB4771: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JSPg+wz2dg8ZNGYDb5h+4Qt0SlNpbVlusvyEDWx83tSYpWTyPY7fCemdBR9/+q1u7uN5DSFyfszjts5o4YXSMmw0LIpT9fJiwxX3vTYeDeFHIstHtpCZ/n1AZlCZw06i7FUN7EJzRi+d+rtDB1gF6+W8mttEYCZx0EdSaq9Ysi87l9bfnMNdVJ54PoyN995d7pqGFt+RZkn5gPQjUuSPRWC0+p1MFXxMj+yA5QkFWKf1Yvqg495Wj8ILRJDoiUIqdOsFNkekIYzGrtgFFOjc2/aJE8ZnntFxrcwoKxJDty9CoF1XUASXwUdmaiTD5Ot93q6tdid/PbmyIsEyNv5fJEQULhWNyclPd3gHTMk/eQLuuMcJo3sDnQ2FGPNlnZ4d3v5tm/qZdgfkkbNpcEeu7vapnN+mL+CX7VpV3fYxAnpSjNtmtyelyZYL2tNucL641wa6ZDbbV+yV/Fj/SocM2pcT8onpGpr3TUmmxLIhca5tUfTx05lQ+T4ZD1Y1I5yGDmdRensPdBhsgm+hGYavrv73imd9bkg8nm8wyiFAwB0VmSDbO9z7VLt8qDBbHVXbQJJwdqUzHfqQSKltFSui7W+SXXc5DDEC8K5XMNQdODQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(366004)(39860400002)(396003)(33430700001)(66476007)(66556008)(64756008)(66946007)(966005)(6916009)(186003)(6506007)(9326002)(52536014)(316002)(33440700001)(8936002)(2906002)(5660300002)(66446008)(76116006)(54906003)(86362001)(55016002)(7696005)(8676002)(71200400001)(4744005)(4326008)(83320400001)(83290400001)(83280400001)(83310400001)(166002)(33656002)(478600001)(9686003)(83300400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JCMRatfupE57Zc+c8F49Upm7N8Lo4LF/TLXGiHivEQBp1qGBnbzaMLuTXngWU97PP/gslw/TCdc4SEH4tD398XUaKw/Xh07DgtxVq/6kFwmzpzorjoJWssgatNq8nw80g3a5vh5juV8ulwnyqmopny1eCD/RM9IetEhXdOt7X00cxi0FWapMqnpdDFYUd0OcbOXhFG4QipQD//BCiMcFAMs89HVTnnXC4G/Ue2h4cqq3G2U+uRB/FbYBFtF5zUO19UeQ68DjEsdz047U/kc/f9nB3cRrwowCoCAxe3ok6f46LaulhCvFCx6V28XKn8p1CrVxbyNCHv/TJsUkO9pMyks8bSraCeWYVWpBIrGeUv4YbdASxGx/bt6JMET0gRBHHa1r5dJyWHX8H5IOkR7C/NFbzaFa/kcFJUZTQVFx/a5dbker5AhwaJVr3wDlsVYcGC7Y9jaBEd3aIm5YVLkOx9MV+efnjUyuQE6tOLkqVKxXhqMaMB+8icpKCvLy/1SPQUyFG9jcEpMy5qaV2gEl1s+DNS2MBWyzq4LVQD9WBNx6CTYH2KhMF6EexZzXOJBt x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB638658735B03FB71320670B9E0A20AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73c7d486-91d8-4be3-14cb-08d7f3330538 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 09:34:35.1413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +P+5Q2Z5nocaDcoh2J7A3fuYV+b8VWu5XpEx/VdBeI0+EHhFHDIelXCpm8pQlrTlCPOM088T9G5pNlgQQKMEcMCgiHuCGfPNS/nMsSlGQm4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4771 Archived-At: Subject: [Lsvr] WGLC for draft draft-ietf-lsvr-l3dl-04 (to end May 22, 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 09:34:42 -0000 --_000_AM0PR07MB638658735B03FB71320670B9E0A20AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The LSVR WG initiates a working group last call for "draft-ietf-lsvr-l3dl-0= 4". Please send your comments to the list before Friday May 22. https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-04 All, please reply on-list indicating if you're aware of an implementation. If not already completed, please reply on-list indicating if you're aware o= f any relevant IPR. Brgds, Gunter & Victor LSVR WG co-chairs --_000_AM0PR07MB638658735B03FB71320670B9E0A20AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi All,
 
 
The LSVR WG initiates a working group last call for=
 "draft-ietf-lsvr-l3dl-04". Please send your comments to the list=
 before Friday May 22.
 
https://tools.ietf.org/htm=
l/draft-ietf-lsvr-l3dl-04
 
All, please reply on-list indicating if you're awar=
e of an implementation.
If not already completed, please reply on-list indi=
cating if you're aware of any relevant IPR.
 
Brgds,
Gunter & Victor
LSVR WG co-chairs

 

--_000_AM0PR07MB638658735B03FB71320670B9E0A20AM0PR07MB6386eurp_-- From nobody Fri May 8 02:40:42 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEFA3A0977; Fri, 8 May 2020 02:40:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158893083988.13647.16909730073859827788@ietfa.amsl.com> Date: Fri, 08 May 2020 02:40:39 -0700 Archived-At: Subject: [Lsvr] The LSVR WG has placed draft-ymbk-lsvr-l3dl-ulpc in state "Call For Adoption By WG Issued" X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 09:40:41 -0000 The LSVR WG has placed draft-ymbk-lsvr-l3dl-ulpc in state Call For Adoption By WG Issued (entered by Gunter Van de Velde) The document is available at https://datatracker.ietf.org/doc/draft-ymbk-lsvr-l3dl-ulpc/ From nobody Fri May 8 02:41:15 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9B13A097B; Fri, 8 May 2020 02:41:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.129.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158893087450.10929.12114935953386704792@ietfa.amsl.com> Date: Fri, 08 May 2020 02:41:14 -0700 Archived-At: Subject: [Lsvr] The LSVR WG has placed draft-ymbk-lsvr-l3dl-signing in state "Call For Adoption By WG Issued" X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2020 09:41:15 -0000 The LSVR WG has placed draft-ymbk-lsvr-l3dl-signing in state Call For Adoption By WG Issued (entered by Gunter Van de Velde) The document is available at https://datatracker.ietf.org/doc/draft-ymbk-lsvr-l3dl-signing/ From nobody Mon May 11 13:40:42 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761643A0B6E; Mon, 11 May 2020 13:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O7LySk89wwn; Mon, 11 May 2020 13:40:34 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F92E3A0B86; Mon, 11 May 2020 13:40:32 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id CAA871C0851; Mon, 11 May 2020 22:40:30 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id F26971C084A; Mon, 11 May 2020 22:40:27 +0200 (CEST) (Extended-Queue-bit tech_mewbi@fff.in.tum.de) To: Randy Bush Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> From: Joerg Ott Message-ID: Date: Mon, 11 May 2020 22:40:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 20:40:38 -0000 Randy, thanks much, inline. > again, thanks for taking the time for a strong review. it is much > appreciated. > >> could benefit from a bit of extra context and target application >> domain in the introduction. E.g., explaining explicitly who would talk >> L3DL to whom. > > how about the last para of intro getting a few more words along the line > of > > In this document, the use case for L3DL is for point to point links > in a datacenter Clos in order to exchange the data needed for BGP-SPF > [I-D.ietf-lsvr-bgp-spf] bootstrap and continuity. Once layer two > connectivity has been leveraged to get layer three addressability and > forwarding capabilities, normal layer three forwarding and routing > can take over. > > L3DL might be found to be more widely applicable to a range of > routing and similar protocols which need layer three discovery and > characterisation. Sounds (well: reads) good. >> 1. Section 10 spells out a default HELLO interval of 60 seconds. With >> a large broadcast domain, this may create quite a bit of >> traffic. While this may not be an issue in well-provisioned data >> center networks, a remark about sensible value ranges and the >> implications may be worthwhile. Just to provide some guidelines to >> implementers (who want to offer choices) and operators (who pick >> them). > > If the configured destination address is one that is propagated by > switches, the HELLO SHOULD be repeated at a configured interval, with > a default of 60 seconds. This allows discovery by new devices which > come up on the layer-2 mesh. In this multi-link scenario, the > operator should be aware of the trade-off between timer tuning and > network noise and adjust the inter-HELLO timer accordingly. Ack. >> 2. Section 10 also suggest that in response to HELLO messages nodes >> will issue OPEN PDUs to newly discovered peers. This appears to bear >> the clear risk of an OPEN implosion when many system come up at the >> same time. Shouldn't guidance be given to avoid repeated traffic >> surges and possible losses and thus unnecessary delays? (I noted that >> other places foresee exponential backoff when retransmitting OPEN and >> other ACKed PDUs). > > added > > To ameliorate possible load spikes during bootstrap or event > recovery, there SHOULD be a jittered delay between receipt of a HELLO > and issue of the OPEN. The default delay range SHOULD BE zero to > five seconds, and MUST be configurable. Ok. >> 3. When the protocol applies fragmentation, should there be a note on >> preventing bursts? > > likely part of this is our fault, as we did not mean 'fragmentation' in > the classic "oops! we found a hop with a small mtu." I didn't take it to mean classic fragmentation but rather ALF-style operation. Still, this could generate bursts depending on how much information there is to 'fragment'. > does augmenting sec 6 as follow help? > > This is not classic 'fragmentation', but rather decomposition at the > origin to allow PDU payloads larger than the frame allows. There are > no intermediate devices capable of further fragmentation or > reassembly. > > L3DL is carrying relatively small amounts of data on relatively high > bandwidth links, and at a time when the link is not active with other > data as it does not yet have layer three connectivity. So congestion > is not considered a sufficiently significant risk to warrent > additional complexity. Fine by me. I assume that the limited amount of information you carry in the first place would not yield more than 2 or 3 packets, so that the above sounds good. >> Section 7 on the checksum needs more detail. > > could you be more specific re in what area? Let me go back: The code is fine (and certainly a good idea). I was kind of expecting the code to be described in text, but given the code is there, the concise description is fine. Except that I got confused by "repeat until zero". What should be zero? Looking at the code, surely not the result. >> It also talks about a "suggested" algorithm but this should be clearly >> mandated or way to choose one by means of configuration for a complete >> data centre would need to be made explicit. > > The following code describes a suggested algorithm. This > specification avoids mandatory to implement, algorithm agility, etc. > What matters is that the same algorithm is used consistently in any > deployment. Ok. >> I also assume that the pseudo code on p.11 would benefit from a leader >> '0' in 0xffffffff -> 0x0ffffffff, otherwise expansion to 64 bits might >> fill the high order bits with '1's, which is clearly not intended. > > ok, but what kinky compiler are you using? :) > > result = (result >> 32) + (result & 0x0FFFFFFFF); > result = (result >> 32) + (result & 0x0FFFFFFFF); We had this and I am happy to undo this comment. Hasn't occurred lately but surely earlier. Probably not having the leading zero would ensure that people don't assume that it's just 7 x F instead of 8. >> Section 11, p.17, second to last para ("If a properly >> authenticated..."). From the text, it is unclear what is meant by an >> "OPEN with the Serial Number of the last data received". > > If a properly authenticated OPEN arrives with a new Nonce from an > LLEI with which the receiving logical link endpoint believes it > already has an L3DL session (OPENs have already been exchanged), and > the Serial Number in the OPEN PDU is non-zero, the receiver SHOULD > establish a new session by sending an OPEN with the Serial Number > being the same as that of the last sent and ACKed PDU. Each party > MUST resume sending encapsulations etc. subsequent to the other > party's Sequence Number. And each MUST retain all previously > discovered encapsulation and other data. Clear now. >> I am curious about the error code, providing 16 bits for additional >> explanation. Why not a text field? > > parsing by the receiver of error codes then becomes an larger unbounded > chase. but this bit of syntactic sugar may be more pain than it is > worth. free form or under-defined fields are too fertile a ground for > interoperational incompatibility. opinions solicited. fine by me either way, was just curious. >> Also wondering if repeated retries (due to failure, not lost packets) >> could yield fast repeated transmissions. > > could you be specific about what you think could be improved in I was trying to decipher my handwriting on the tablet, and it appears to say "wait before retry to prevent fast loops", scribbled on the bottom of p.22. I had to go back tot he text and I believe this refers back to p.18, first para: "The Key is specific to the operational environment. A failure to authenticate is a failure to start the L3DL session, an ERROR PDU MUST BE sent (Error Code 3), and HELLOs MUST be restarted." If you have a systematic auth failure, this would cause HELLOs to be restarted. Without any jittering (now you introduced some above), you could, in principle, get a loop: HELLO -> OPEN -> (Auth) ERROR -> HELLO -> OPEN -> (Auth) ERROR -> ... So misconfig could be bad unless there is some delay built in. > 12.1. Retransmission > > If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a > VENDOR PDU, etc., and does not receive the ACK for a configurable > time (default one second), and the interface is live at layer 2, the > sender resends the PDU using exponential back-off, see [RFC1122]. > This cycle MAY be repeated a configurable number of times (default > three) before it is considered a failure. The session MAY BE > considered closed in case of this ACK failure. > >> Section 15, should the KEEPALIVE interval have suggested (lower) >> bounds? At the top of p.26, it says "One per second is the default", >> the previous page at the bottom refers to the inter-KEEPALIVE interval >> of ten seconds. Not sure if the two are the same, I suppose so. If >> they are, the numbers should match. If they are not, we'll need some >> extra text to explain the difference. > > whoops. how about ten seconds for both? I have no specific opinion as long as it is consistent. 10s for both is fine. >> There are two spellings of "Encapsulation", capitalised and lower >> case. Use one consistently. > > mind if we stall on this one? we were attempting to differentiate > between the proper noun of a PDU type and normal use of the world. but > looking at the text, it's a bit messy. full employment for rfc editors! > :) yay! :-) >> p10, first para: comprise -> comprising > > s/compare/comparing/ in > > [RFC1982] on DNS Serial Number Arithmetic for too much detail on > comparing and incrementing a wrapping sequence number. > > pre-published text and xml are at https://git.rg.net/randy/draft-l3dl > Thanks much for the super-quick responses! Cheers, Jörg From nobody Tue May 12 08:03:55 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E196F3A0AEA; Tue, 12 May 2020 08:03:53 -0700 (PDT) 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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 WoJlfw2wYGrt; Tue, 12 May 2020 08:03:52 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 257963A0AE6; Tue, 12 May 2020 08:03:47 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id f3so14257665ioj.1; Tue, 12 May 2020 08:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hE6LZ7mnLO+ggnprPxs2qRklHd9IQBce3HpwOUshrCE=; b=cYMeth3NDYlxkLq3q6xWXTNmn3ryN/NpknHhpSNQXdLzbdjoQrpOUSubHSEV4gj7+8 xYY9ekGjykqXtbBJxjDp8+mAaCRamyt3m/d95dCAPPqxDrmuvO1NyunHSUy+z8iZeeL4 HmzFlXARMB6iba25whpTG0QA22VSN9ZEHsjawaEdo8MGtYVA/AQ/jZNLRK7QQOGlhA/x jBIDo70SA4EfbuCyDD7OYk+1R33h1pNk12+CI1g8w4/0fw6gZGSK2V1zwSKHKY5R+wCW hyGYuAf2u5mCl3Yooec5Y4K2WbSbpAXy0xjsGMXmqc+mnwAaR4Ba3HYGUFMxEifUou0S F+9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hE6LZ7mnLO+ggnprPxs2qRklHd9IQBce3HpwOUshrCE=; b=sRITPYWc+4w36NKaG0wZt0m44JCsczmxtQ6OyOOyh8+wzF5ajQRp6v9m7f6KFx4UfN 2jYMa5BCFCgjQIajEUdzbYUC+eJo3BqWtqAEkG8u4W72I7/jvpJnKNAbYcbYBrBJquzf lq/x/XfyRNPu0fyX4bnU5Glui8vw6KUBvUIOK5EwKvRqTyX04hNiSgPyhaeaGZQ9gg81 r1iJHw+YDFUyT7ZvH+tplskbmziRbvQcd/k0NDPexo99Kx+SKB/Cq+HqD6GXSB08tQyJ il+VqqXUY4icseLN8eCLlaNtO3BU9htVazGCoaY38oLUuothJMkoSZQjWfPrbqVq/J4H H0Tw== X-Gm-Message-State: AGi0PuZlXciP1Px99A2APTimS1bq8pRDD5aQl/JHu0D7vL2DeIXZAsIY p5jf+Ev/WUQN1g9vFZd6pt2q1OW3Wib/gM8RbIQ= X-Google-Smtp-Source: APiQypKieiWkY4S5HAZbJKNiAO0cfjY6BpARlaKV3asemwohzNEWLslGxCfyRtlbywDdPNOBeAdazLze2hqU4RgNIaM= X-Received: by 2002:a5e:c814:: with SMTP id y20mr20605190iol.135.1589295826248; Tue, 12 May 2020 08:03:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Santosh P K Date: Tue, 12 May 2020 20:33:35 +0530 Message-ID: To: Gaurav Dawra Cc: Shawn Zandi , "lsvr@ietf.org" , "draft-ietf-lsvr-applicability@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="0000000000002ab29305a574c5dc" Archived-At: Subject: Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 15:03:54 -0000 --0000000000002ab29305a574c5dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have read the draft and support it moving forward. Thanks Santosh P K On Wed, May 6, 2020 at 11:40 PM Gaurav Dawra wrote: > Not aware of any IPR > > Sent from my iPhone > > On May 6, 2020, at 11:01 AM, Shawn Zandi 40linkedin.com@dmarc.ietf.org> wrote: > > =EF=BB=BF > I am not aware of any relevant IPR. > > -Shawn > > Sent via carrier pigeon > > ------------------------------ > *From:* Van De Velde, Gunter (Nokia - BE/Antwerp) < > gunter.van_de_velde@nokia.com> > *Sent:* Wednesday, May 6, 2020 1:22:07 AM > *To:* draft-ietf-lsvr-applicability@ietf.org < > draft-ietf-lsvr-applicability@ietf.org> > *Cc:* lsvr@ietf.org > *Subject:* RE: WGLC for draft-ietf-lsvr-applicability-04 (to end January > 21, 2020) > > > Can all authors please respond to the IPR question? > > Only 2 from the authors have responded to the IPR request of > =E2=80=9Cdraft-ietf-lsvr-applicability=E2=80=9D. > > > > Brgds, > > G/ > > > > *From:* Van De Velde, Gunter (Nokia - BE/Antwerp) > *Sent:* Tuesday, January 7, 2020 10:39 > *To:* lsvr@ietf.org > *Subject:* WGLC for draft-ietf-lsvr-applicability-04 (to end January 21, > 2020) > > > > Hi All, > > > > > > The LSVR WG initiates a working group last call for "draft-ietf-lsvr-appl= icability-04". Please send your comments to the list before Tuesday January= 21. > > > > https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/ > > > > All, please reply on-list indicating if you're aware of an implementation= . > > If not already completed, please reply on-list indicating if you're aware= of any relevant IPR. > > > > Brgds, > > Gunter & Victor > > LSVR WG co-chairs > > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > --0000000000002ab29305a574c5dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read the draft and support it moving=C2=A0forward.<= div>
Thanks
Santosh P K

On Wed, May 6, 2020 = at 11:40 PM Gaurav Dawra <gdawr= a.ietf@gmail.com> wrote:
Not aware of any IPR

Sent from my iPhone

On May 6, 2020, at 11:01 AM, Shawn Zandi <szandi=3D40linkedin.com@dmarc.ietf.or= g> wrote:

=EF=BB=BF
I am not aware of any relevant IPR.

-Shawn

Sent via carrier pigeon

Fro= m: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<= /a>>
Sent: Wednesday, May 6, 2020 1:22:07 AM
To: draft-ietf-lsvr-applicability@ietf.org <draft-ietf-lsvr= -applicability@ietf.org>
Cc: lsvr@ietf.org= <lsvr@ietf.org>
Subject: RE: WGLC for draft-ietf-lsvr-applicability-04 (to end Janua= ry 21, 2020)
=C2=A0

Can all authors please respond to the IPR question?

Only 2 from the authors have responded to the IPR request of =E2=80=9Cdr= aft-ietf-lsvr-applicability=E2=80=9D.

=C2=A0

Brgds,

G/

=C2=A0

From: Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Tuesday, January 7, 2020 10:39
To: lsvr@ietf.org=
Subject: WGLC for draft-ietf-lsvr-applicability-04 (to end January 2= 1, 2020)

=C2=A0

Hi All,
=C2=A0
=C2=A0
The LSVR WG initiates a working group last call=
 for "draft-ietf-lsvr-applicability-04". Please send your comment=
s to the list before Tuesday January 21.
=C2=A0
https=
://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/

=C2=A0


All, please reply on-list indicating if you'=
;re aware of an implementation.


If not already completed, please reply on-list =
indicating if you're aware of any relevant IPR.


=C2=A0


Brgds,


Gunter & Victor


LSVR WG co-chairs


=C2=A0
_______________________________________________
Lsvr = mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/= lsvr
_______________________________= ________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr
--0000000000002ab29305a574c5dc-- From nobody Tue May 12 11:36:11 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFBE3A0919; Tue, 12 May 2020 11:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 hXGBbsSF_ggX; Tue, 12 May 2020 11:36:08 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 D0C303A0908; Tue, 12 May 2020 11:35:57 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id m5so13377724ilj.10; Tue, 12 May 2020 11:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5yFYv6ZiEC7JRQYpyWVTqimLL8UkLCjRVkP64lKhF7M=; b=FdyFs1buXmfG07Vbph7KJgGhWT2dqBZTvLbIbxI/lvp1vUsd6I538rbaGyIvkaRban xJA5y3eYA9Ox8MYVSZN/Up9sSaujh7+aAfeBdw+dpfS0RpDrYW1KTAMVoTKoynUufVXv sQYG94Mdspz92cWJSWnQITpsY//2XslHymKovGP7vJrB7wIfgz0mmwiuPHI8Hdqr0QB5 ixUAmybzYI0tnx81EN9rWuaCpTqB/49jZiN10CzPYPbnS6iQ/IDNQG+ko8JwumYr/Hks FK/cMSHZoxblkNv9AiOr2t0Nx8MS2cYP4uoU2RI5i3kMuNs3XlmsGYLJuQqlS7QlQxo9 8mRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5yFYv6ZiEC7JRQYpyWVTqimLL8UkLCjRVkP64lKhF7M=; b=r2Kc8VJ14lLBvgEyGk+si5TGCz/KLHwWq4PQL1iX3zZcmW8Ebt4ZyB60pFQ9QI56Tg 3APAZd4va1ulJ4HunfP+TdgNoxAzf1XrHTC/UzVsCPBaYf7dBZZaWrwrpXnBLk7cpdIg C0J2XqmPDZ+jS3Ax3IOtR4V+jJ77naXZmtwexUqEis+tmKgcCkxGuAufaT+A5KM+9mLB HxO2KA4mR91Kq8lEAdfbV70ya/lpO5zHup0xdrIU+Qs+41eodLADqDA/hhIzbooeOzB5 wcInIxtnL+slVX8c8zUGbPJAklYb8dS5W3r/xt60G6AfpWw5FYBZSbzaSunzVFQZ3gV9 353Q== X-Gm-Message-State: AGi0Puaq6ffNr0Y7pHZY1/J5Ytn7UZuhRv8zQSV5BKuw7vm3jV2zsVul x45uvIfcLtWiQMlogrL7V4bESJHbTqlle59s2JQ= X-Google-Smtp-Source: APiQypK/BIZ2VKgsp6077tMXy/b2Xg8ieZsDSTdrloCnSEpvcqR7d65+XPuYF9j51U40PBRHueurEpqAdKDofNWvpjQ= X-Received: by 2002:a92:d4c4:: with SMTP id o4mr23642135ilm.38.1589308557160; Tue, 12 May 2020 11:35:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Santosh P K Date: Wed, 13 May 2020 00:05:46 +0530 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "lsvr@ietf.org" , "draft-ietf-lsvr-l3dl@ietf.org" , Victor Kuarsingh Content-Type: multipart/alternative; boundary="000000000000fcf63105a577bbb6" Archived-At: Subject: Re: [Lsvr] WGLC for draft draft-ietf-lsvr-l3dl-04 (to end May 22, 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 18:36:10 -0000 --000000000000fcf63105a577bbb6 Content-Type: text/plain; charset="UTF-8" I have read this document and support to take it forward. Thanks Santosh P K On Fri, May 8, 2020 at 3:04 PM Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > Hi All, > > > > > > The LSVR WG initiates a working group last call for "draft-ietf-lsvr-l3dl-04". Please send your comments to the list before Friday May 22. > > > > https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-04 > > > > All, please reply on-list indicating if you're aware of an implementation. > > If not already completed, please reply on-list indicating if you're aware of any relevant IPR. > > > > Brgds, > > Gunter & Victor > > LSVR WG co-chairs > > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > --000000000000fcf63105a577bbb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read this document and support to take it forward.<= div>
Thanks
Santosh P K=C2=A0

On Fri, May 8, 2= 020 at 3:04 PM Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wr= ote:
Hi All,
=C2=A0
=C2=A0
The LSVR WG initiates a working group last call=
 for "draft-ietf-lsvr-l3dl-04". Please send your comments to the =
list before Friday May 22.
=C2=A0
https://=
tools.ietf.org/html/draft-ietf-lsvr-l3dl-04
=C2=A0
All, please reply on-list indicating if you'=
;re aware of an implementation.
If not already completed, please reply on-list =
indicating if you're aware of any relevant IPR.

=C2=A0


Brgds,


Gunter & Victor


LSVR WG co-chairs


=C2=A0
_______________________________________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr
--000000000000fcf63105a577bbb6-- From nobody Thu May 14 19:30:11 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904783A0538 for ; Thu, 14 May 2020 19:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 RhaxVvjU13mw for ; Thu, 14 May 2020 19:30:07 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 724DD3A0496 for ; Thu, 14 May 2020 19:30:07 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id ms17so325109pjb.0 for ; Thu, 14 May 2020 19:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q66QfR4r2dmk6loYcnkWC+BX4CNd/AoOrmEPbhep95c=; b=A7dI7eYqKkb/9QZsqtneQJhKUiSRVQpZNaeOqQnjyiJTxi6Wp5b9Q13EVA9tIN0MjF /WUWjYcNX1G3Y/+h6Yh/W+enRH1DJTusYsVqzkQ277qnODWtntDfsAXoxMhdxgkz5ssK tmjpFZ4tCO/dZRPQTp74S7oqc9ti1X1ygkSItJt2yhWCqTjx5Kn3AiaRWrIvsI70tp7m fGYTlY/TLE3Tku7paeymZc8gtlYJz3cNm8aSEeMEprYt5NONfp/TbllM/OPD7VTD2eum F+qesGXpM63rpD8lCqdWw6nILiNI5U5xtBGPdCIAwCosopNk5BIg4PqXWnoTML87vbTn x9Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=q66QfR4r2dmk6loYcnkWC+BX4CNd/AoOrmEPbhep95c=; b=e9yYBJpdkNIZ8ItAsP6rz64ooNIjCiPOVpG86aIU0GQXrqRmSvZ8/IXkVrM6x/4/vH 4LAM6wb4OnnXFimmhQU4qm3IvkRfdQD2nDevnBuDIo7d0vkZp82lRJTEZmM1CML1G86r 9AdrypaVs/JSrza+G7iFhXCNBEi0n1guoJ3b9Oa+VtQL1mvrl04jihfd0WXXYdLvHCGR Tw0TneG2Q8qS/E2MVi9ZtTxxo2B002xGBZlzI5S0ULa+WPFl87V+fgy4MYZnKiTcGC5Q 3gxaj7NTk1UHai6B/A5a9/SbL+1feg628q/7lsa9RPloONX7hqrO0JW1JISVVbhbrMQC Q4Tg== X-Gm-Message-State: AOAM530jj2M8Xj18Wd7v8WAE3Fit9peWPGNyVkv2NCKPfM+gOGiGUFrm 1DNniTAX/XLRyISVf/or6HE= X-Google-Smtp-Source: ABdhPJwbqBhAvMYbV+ZndYUo6VdjM69Q4cBeyvldit8kWMJwvh9cP2fl4OxiVeV60DPkX6aoAS3EWw== X-Received: by 2002:a17:902:694b:: with SMTP id k11mr1573120plt.59.1589509806763; Thu, 14 May 2020 19:30:06 -0700 (PDT) Received: from ?IPv6:2600:8801:880:3f6:81cf:6dc0:1f1f:a616? ([2600:8801:880:3f6:81cf:6dc0:1f1f:a616]) by smtp.gmail.com with ESMTPSA id b13sm424452pgi.58.2020.05.14.19.30.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2020 19:30:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Jacob Uecker In-Reply-To: Date: Thu, 14 May 2020 19:30:05 -0700 Cc: Warren Kumari , lsvr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7F8FFE3D-98B2-485D-B5BB-DDD459E539AA@gmail.com> References: To: Randy Bush X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 02:30:10 -0000 I likewise fell down that line of thinking but your explanation makes = sense. 1) I have read and support both draft-ymbk-lsvr-l3dl-signing and = draft-ymbk-lsvr-l3dl-ulpc as LSVR WG documents. 2) Not that I saw 3) See above.=20 4) I don=E2=80=99t have anything at this time. > On May 7, 2020, at 2:29 PM, Randy Bush wrote: >=20 >>>> C: It feels like more text is needed around "If a peering address = has >>>> been announced as a loopback, a two or three (one or both ends = could >>>> be loopbacks) hop >>>> BGP session will be established. " -- how do I know it is = announced >>>> as a loopback? How do I know what route to install to reach the >>>> loopback? etc. >>>=20 >>> l3dl 13.2 tells you it is a loopback >>=20 >> Doh, I missed that... >>=20 >>>=20 >>> 13.2. Encapsulaion Flags >>>=20 >>> The Encapsulation Flags are a sequence of bit fields as follows: >>>=20 >>> 0 1 2 3 4 ... 7 >>> +------------+------------+------------+------------+------------+ >>> | Ann/With | Primary | Under/Over | Loopback | Reserved ..| >>> +------------+------------+------------+------------+------------+ >>>=20 >>> so how about >>>=20 >>> For each BGP peering on a link here MUST be one agreed = encapsulation, >>> and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 >>> Announcement PDUs. If a peering address has been announced as a >>> loopback, i.e. MUST BE flagged as such in the L3DL Encapsulation = PDU, >>> a two or three hop BGP session will be established. Otherwise a >>> direct one hop session is used. >>=20 >> Close but no cigar -- I suspect I didn't fully explain my (second) = question >> If router A says that I should peer with the loopback address >> 192.0.2.1, I need to know how to route *to* that address >=20 > you will likely want to forward, not route , to > the peer's address which was marked as Primary, iff it is in a subnet > which you also share. if not, pick a forwarding next hop that is in a > subnet you share. if there are multiple choices, you could have > signaled which subnet in an Upper Layer Protocol Configuration PDU > Attribute. >=20 > if you share no subnets, then you do not have a valid underlying l3dl > session see l3dl >=20 > 13. The Encapsulations > .... > Further, to consider a logical link of a type to formally be > established so that it may be pushed up to upper layer protocols, = the > addressing for the type must be compatible, e.g. on the same IP > subnet. >=20 > yes, you have to hold a lot of gorp in your head. sorry. >=20 > but some clarifying text might keep others from falling down this = rabbit > hole. thanks. >=20 > randy >=20 > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr From nobody Fri May 15 08:01:20 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65873A0A86; Fri, 15 May 2020 08:01:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsvr@ietf.org Message-ID: <158955486681.29520.9871800779490140694@ietfa.amsl.com> Date: Fri, 15 May 2020 08:01:06 -0700 Archived-At: Subject: [Lsvr] I-D Action: draft-ietf-lsvr-bgp-spf-09.txt X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:01:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Vector Routing WG of the IETF. Title : Shortest Path Routing Extensions for BGP Protocol Authors : Keyur Patel Acee Lindem Shawn Zandi Wim Henderickx Filename : draft-ietf-lsvr-bgp-spf-09.txt Pages : 22 Date : 2020-05-15 Abstract: Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes a solution which leverages BGP Link-State distribution and the Shortest Path First (SPF) algorithm similar to Internal Gateway Protocols (IGPs) such as OSPF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsvr-bgp-spf-09 https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsvr-bgp-spf-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 19 00:28:40 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E693A12A3 for ; Tue, 19 May 2020 00:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 qUDaP8iCznEP for ; Tue, 19 May 2020 00:28:23 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 C62EB3A12A4 for ; Tue, 19 May 2020 00:28:23 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id d1so6028080qvl.6 for ; Tue, 19 May 2020 00:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jZDlkO1hBzE4nJmi/MW8lt+GfwcUev2kOjo9ROMa36Q=; b=ZrrxJwvZMjce9KJBslInfoFsuAKj60TuI7Vcu15q8GYHRG6ryeNh2ZdqMtZORzVFZT GRBCjQQ0JZ4plYAJBPw+e2nsIRVIbp6RLGJ2r1Bu5IRuzZ6Mr9c8i5k/gjd1ztv8vEe6 3FAkG7s1IeydKfN3JJRy+JUL2/aohyJgwoOxJHUAbtjJFDxsnRKwALpRUrS6Xw85xf6L aMPl48qapmots3qhePUWz8BBUA0bTOBq6J0VhfTkUniUrWWwxPYwNtw0Axwx14Wbc/68 XTOg1hUzdr28LKefMM1rUqjjFcyYk6Ku3Hpo1wTQ/J+HhSUmgGPvJOmsRfpOv4KjymvZ KKEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jZDlkO1hBzE4nJmi/MW8lt+GfwcUev2kOjo9ROMa36Q=; b=Z0mQn/e2XGsNkLSLtejokxpYegC5GWxeLwibg9/AkMqLaoRQotzQ/+GhgrQ1Ctlldv Fb5xxUTXnrePKnoqKkDCmTg7S8Zlgd+QX6s8WMyuOc3YDRBEYciClflmBIaVEvsIvdsx 2SgU0g/KsKuKpeA1nybXNN4l/gcjJBHWDy8L3M5egVgi65WEwRoKknLtjN3QPrx7YULa EbMrgxrbbQDpcFsY5x2LRSOX5KBuJNNhQ/A+iBXiwP7b74Aqxcn+PtM9/2q/WAwc3Jhj NvBbinRgb/wbw5yVpM+9TCLRuIeRHqoc8DkquwrXwXmiROnZFYY7907ntPrfhdYe3sS0 Ynlg== X-Gm-Message-State: AOAM530+Nicj5VgXIz5qL2n2VPRMzBlBEzx/3LcG3NkP4xtfmCgFgCFw CtQBslZgwicwONUJZiCrz+yk92ILVAlqeZ6WBtCRxxSs X-Google-Smtp-Source: ABdhPJwE72ot5shfdfWp9/pMTVSafpHozSR5jm1Z0wpXUmnDg5Pm1GO0ShORHtGn61OGQRi9KcO5Y7PfcBxudyiNoGA= X-Received: by 2002:ad4:580b:: with SMTP id dd11mr20217559qvb.145.1589873302370; Tue, 19 May 2020 00:28:22 -0700 (PDT) MIME-Version: 1.0 From: Harsha Kovuru Date: Tue, 19 May 2020 00:28:11 -0700 Message-ID: To: lsvr@ietf.org Content-Type: multipart/alternative; boundary="0000000000006cfb7b05a5fb3916" Archived-At: Subject: Re: [Lsvr] Adoption of draft-ymbk-lsvr-l3dl-(signing|ulpc) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 07:28:27 -0000 --0000000000006cfb7b05a5fb3916 Content-Type: text/plain; charset="UTF-8" As an implementor of l3dl, I accept these documents. --0000000000006cfb7b05a5fb3916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an implementor=C2=A0of l3dl, I accept these documents.<= /div> --0000000000006cfb7b05a5fb3916-- From nobody Sat May 23 11:32:56 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CBA3A0D2B; Sat, 23 May 2020 11:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97NOq6HaUgTb; Sat, 23 May 2020 11:32:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3CA993A0CD6; Sat, 23 May 2020 11:32:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jcYwv-0002S9-SO; Sat, 23 May 2020 18:32:46 +0000 Date: Sat, 23 May 2020 11:32:42 -0700 Message-ID: From: Randy Bush To: Joerg Ott Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org In-Reply-To: References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2020 18:32:54 -0000 sorry to take a while to get back to this. your review is really appreciated. i think we converged on most things. the following seemed open. >>> 3. When the protocol applies fragmentation, should there be a note on >>> preventing bursts? >> >> likely part of this is our fault, as we did not mean 'fragmentation' in >> the classic "oops! we found a hop with a small mtu." > > I didn't take it to mean classic fragmentation but rather ALF-style > operation. Still, this could generate bursts depending on how much > information there is to 'fragment'. yes, it is app level framing. perhaps we should call it that explicitly or even segmentataion or some term less well known. do you perhaps have a specific suggestion? >>> Section 7 on the checksum needs more detail. >> >> could you be more specific re in what area? > > Let me go back: > > The code is fine (and certainly a good idea). I was kind of expecting > the code to be described in text, but given the code is there, the > concise description is fine. Except that I got confused by > "repeat until zero". What should be zero? Looking at the code, surely > not the result. :) Sum up 32-bit unsigned ints in a 64-bit long, then take the high-order section, shift it right filling on the left with zeros, rotate, add it in, repeat until the high order 32 bits are all zero. >>> Also wondering if repeated retries (due to failure, not lost packets) >>> could yield fast repeated transmissions. >> >> could you be specific about what you think could be improved in > > I was trying to decipher my handwriting on the tablet, and it appears to > say "wait before retry to prevent fast loops", scribbled on the bottom > of p.22. I had to go back tot he text and I believe this refers back to > p.18, first para: > > "The Key is specific to the operational environment. A failure to > authenticate is a failure to start the L3DL session, an ERROR PDU > MUST BE sent (Error Code 3), and HELLOs MUST be restarted." > > If you have a systematic auth failure, this would cause HELLOs to be > restarted. Without any jittering (now you introduced some above), > you could, in principle, get a loop: > > HELLO -> OPEN -> (Auth) ERROR -> HELLO -> OPEN -> (Auth) ERROR -> ... > > So misconfig could be bad unless there is some delay built in. so i added Although delay and jitter in responding with an OPEN were specified above, beware of load created by long strings of authentication failures and retries. but i am unsure of what action to recommend. >> pre-published text and xml are at https://git.rg.net/randy/draft-l3dl still holds true randy From nobody Mon May 25 01:35:58 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE43A0D3A; Mon, 25 May 2020 01:35:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lsvr-chairs@ietf.org, gunter@vandevelde.cc, aretana.ietf@gmail.com, lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159039575561.9764.5842482943058659904@ietfa.amsl.com> Date: Mon, 25 May 2020 01:35:56 -0700 Archived-At: Subject: [Lsvr] lsvr - New Meeting Session Request for IETF 108 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 08:35:57 -0000 A new meeting session request has just been submitted by Gunter Van de Velde, a Chair of the lsvr working group. --------------------------------------------------------- Working Group Name: Link State Vector Routing Area Name: Routing Area Session Requester: Gunter Van de Velde Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: Conflicts to Avoid: Chair Conflict: idr bess lsr Technology Overlap: ript rtgwg rtgarea spring People who must be present: Gunter Van de Velde Alvaro Retana Victor Kuarsingh Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon May 25 08:49:51 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9960E3A0A78; Mon, 25 May 2020 08:49:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsvr@ietf.org Message-ID: <159042174954.26745.833193976645107155@ietfa.amsl.com> Date: Mon, 25 May 2020 08:49:09 -0700 Archived-At: Subject: [Lsvr] I-D Action: draft-ietf-lsvr-l3dl-05.txt X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 15:49:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Vector Routing WG of the IETF. Title : Layer 3 Discovery and Liveness Authors : Randy Bush Rob Austein Keyur Patel Filename : draft-ietf-lsvr-l3dl-05.txt Pages : 35 Date : 2020-05-25 Abstract: In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer 3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer 3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-05 https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-l3dl-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsvr-l3dl-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 25 12:27:56 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523E63A0903; Mon, 25 May 2020 12:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxRD7s0llOxr; Mon, 25 May 2020 12:27:19 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31233A08F0; Mon, 25 May 2020 12:27:18 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id EF39E1C08A2; Mon, 25 May 2020 21:27:14 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 2FF841C088D; Mon, 25 May 2020 21:27:12 +0200 (CEST) (Extended-Queue-bit tech_ykwmw@fff.in.tum.de) To: Randy Bush Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> From: Joerg Ott Message-ID: <30b32e49-9781-056d-0542-f736572a2139@in.tum.de> Date: Mon, 25 May 2020 21:27:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 19:27:23 -0000 No worries, I am happy about any break I get... On 23.05.20 20:32, Randy Bush wrote: > sorry to take a while to get back to this. your review is really > appreciated. > > i think we converged on most things. the following seemed open. > >>>> 3. When the protocol applies fragmentation, should there be a note on >>>> preventing bursts? >>> >>> likely part of this is our fault, as we did not mean 'fragmentation' in >>> the classic "oops! we found a hop with a small mtu." >> >> I didn't take it to mean classic fragmentation but rather ALF-style >> operation. Still, this could generate bursts depending on how much >> information there is to 'fragment'. > > yes, it is app level framing. perhaps we should call it that explicitly > or even segmentataion or some term less well known. > > do you perhaps have a specific suggestion? Not really. This all appears artificial if you need two or three packets for app layer fragmentation. Maybe one could write something substantially improved along the lines of: To prevent packet bursts, a sender SHOULD pace the transmission of application layer fragmented data units as follows: A sender MAY transmit up to K packets containing fragments in a burst and SHOULD pace bursts ... (but how?) >>>> Section 7 on the checksum needs more detail. >>> >>> could you be more specific re in what area? >> >> Let me go back: >> >> The code is fine (and certainly a good idea). I was kind of expecting >> the code to be described in text, but given the code is there, the >> concise description is fine. Except that I got confused by >> "repeat until zero". What should be zero? Looking at the code, surely >> not the result. > > :) > > Sum up 32-bit unsigned ints in a 64-bit long, then take the > high-order section, shift it right filling on the left with zeros, > rotate, add it in, repeat until the high order 32 bits are all zero. Sold :-) >>>> Also wondering if repeated retries (due to failure, not lost packets) >>>> could yield fast repeated transmissions. >>> >>> could you be specific about what you think could be improved in >> >> I was trying to decipher my handwriting on the tablet, and it appears to >> say "wait before retry to prevent fast loops", scribbled on the bottom >> of p.22. I had to go back tot he text and I believe this refers back to >> p.18, first para: >> >> "The Key is specific to the operational environment. A failure to >> authenticate is a failure to start the L3DL session, an ERROR PDU >> MUST BE sent (Error Code 3), and HELLOs MUST be restarted." >> >> If you have a systematic auth failure, this would cause HELLOs to be >> restarted. Without any jittering (now you introduced some above), >> you could, in principle, get a loop: >> >> HELLO -> OPEN -> (Auth) ERROR -> HELLO -> OPEN -> (Auth) ERROR -> ... >> >> So misconfig could be bad unless there is some delay built in. > > so i added > > Although delay and jitter in responding with an OPEN were specified > above, beware of load created by long strings of authentication > failures and retries. > > but i am unsure of what action to recommend. Count to N, raise an alert, pause. Or something like this? >>> pre-published text and xml are at https://git.rg.net/randy/draft-l3dl > > still holds true Thanks -- best, Jörg From nobody Mon May 25 22:35:30 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54523A0B03; Mon, 25 May 2020 22:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2urEZ0kGePsv; Mon, 25 May 2020 22:35:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 015213A0AFB; Mon, 25 May 2020 22:35:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jdSFF-0002kQ-1n; Tue, 26 May 2020 05:35:21 +0000 Date: Mon, 25 May 2020 22:35:20 -0700 Message-ID: From: Randy Bush To: Joerg Ott Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org In-Reply-To: <30b32e49-9781-056d-0542-f736572a2139@in.tum.de> References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <30b32e49-9781-056d-0542-f736572a2139@in.tum.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 05:35:27 -0000 >>>>> 3. When the protocol applies fragmentation, should there be a note on >>>>> preventing bursts? >>>> likely part of this is our fault, as we did not mean 'fragmentation' in >>>> the classic "oops! we found a hop with a small mtu." >>> I didn't take it to mean classic fragmentation but rather ALF-style >>> operation. Still, this could generate bursts depending on how much >>> information there is to 'fragment'. >> yes, it is app level framing. perhaps we should call it that explicitly >> or even segmentataion or some term less well known. >> do you perhaps have a specific suggestion? > Not really. This all appears artificial if you need two or three > packets for app layer fragmentation. Maybe one could write something > substantially improved along the lines of: > To prevent packet bursts, a sender SHOULD pace the transmission of > application layer fragmented data units as follows: A sender MAY > transmit up to K packets containing fragments in a burst and SHOULD > pace bursts ... (but how?) ok. i have stared at this three times today and have no bright ideas. i do not want to start pacing by measuring rtt or other known deep holes. so i will try to think some more. >>> So misconfig could be bad unless there is some delay built in. >> so i added >> >> Although delay and jitter in responding with an OPEN were specified >> above, beware of load created by long strings of authentication >> failures and retries. >> >> but i am unsure of what action to recommend. > > Count to N, raise an alert, pause. Or something like this? A confugurable failure count limit (default 8) SHOULD result in giving up on the connection attempt. randy From nobody Mon May 25 22:52:32 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60943A0B14; Mon, 25 May 2020 22:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUAak7nWy_K9; Mon, 25 May 2020 22:51:26 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFE13A0B12; Mon, 25 May 2020 22:51:26 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id 8521B1C08A3; Tue, 26 May 2020 07:51:23 +0200 (CEST) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 6F33C1C089C; Tue, 26 May 2020 07:51:21 +0200 (CEST) (Extended-Queue-bit tech_dnxmw@fff.in.tum.de) To: Randy Bush Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <30b32e49-9781-056d-0542-f736572a2139@in.tum.de> From: Joerg Ott Message-ID: <0087f88c-d4ef-4bbf-c227-0a208d1a378b@in.tum.de> Date: Tue, 26 May 2020 07:51:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 05:51:31 -0000 On 26.05.20 07:35, Randy Bush wrote: >>>>>> 3. When the protocol applies fragmentation, should there be a note on >>>>>> preventing bursts? >>>>> likely part of this is our fault, as we did not mean 'fragmentation' in >>>>> the classic "oops! we found a hop with a small mtu." >>>> I didn't take it to mean classic fragmentation but rather ALF-style >>>> operation. Still, this could generate bursts depending on how much >>>> information there is to 'fragment'. >>> yes, it is app level framing. perhaps we should call it that explicitly >>> or even segmentataion or some term less well known. >>> do you perhaps have a specific suggestion? >> Not really. This all appears artificial if you need two or three >> packets for app layer fragmentation. Maybe one could write something >> substantially improved along the lines of: >> To prevent packet bursts, a sender SHOULD pace the transmission of >> application layer fragmented data units as follows: A sender MAY >> transmit up to K packets containing fragments in a burst and SHOULD >> pace bursts ... (but how?) > > ok. i have stared at this three times today and have no bright ideas. > i do not want to start pacing by measuring rtt or other known deep > holes. so i will try to think some more. > One option could be to just have a note of warning. Any ideas how big your application layer messages will usually get...? From nobody Mon May 25 23:05:34 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CFE3A0B40; Mon, 25 May 2020 23:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8Qe7gmUt_Vd; Mon, 25 May 2020 23:04:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 417093A0B24; Mon, 25 May 2020 23:04:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jdShU-0002pl-Gj; Tue, 26 May 2020 06:04:32 +0000 Date: Mon, 25 May 2020 23:04:31 -0700 Message-ID: From: Randy Bush To: Joerg Ott Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org In-Reply-To: <0087f88c-d4ef-4bbf-c227-0a208d1a378b@in.tum.de> References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <30b32e49-9781-056d-0542-f736572a2139@in.tum.de> <0087f88c-d4ef-4bbf-c227-0a208d1a378b@in.tum.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 06:04:40 -0000 >>>>>>> 3. When the protocol applies fragmentation, should there be a note on >>>>>>> preventing bursts? >>>>>> likely part of this is our fault, as we did not mean 'fragmentation' in >>>>>> the classic "oops! we found a hop with a small mtu." >>>>> I didn't take it to mean classic fragmentation but rather ALF-style >>>>> operation. Still, this could generate bursts depending on how much >>>>> information there is to 'fragment'. >>>> yes, it is app level framing. perhaps we should call it that explicitly >>>> or even segmentataion or some term less well known. >>>> do you perhaps have a specific suggestion? >>> Not really. This all appears artificial if you need two or three >>> packets for app layer fragmentation. Maybe one could write something >>> substantially improved along the lines of: >>> To prevent packet bursts, a sender SHOULD pace the transmission of >>> application layer fragmented data units as follows: A sender MAY >>> transmit up to K packets containing fragments in a burst and SHOULD >>> pace bursts ... (but how?) >> >> ok. i have stared at this three times today and have no bright ideas. >> i do not want to start pacing by measuring rtt or other known deep >> holes. so i will try to think some more. >> > > One option could be to just have a note of warning. Any ideas how big > your application layer messages will usually get...? as you pointed out up-thread, a few frames. a dozen would be highly unlikely. but, it's the internet; so you never know. randy From nobody Tue May 26 01:34:28 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346B93A0CF6; Tue, 26 May 2020 01:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQJy46AquM0t; Tue, 26 May 2020 01:34:23 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60110.outbound.protection.outlook.com [40.107.6.110]) (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 5F8D83A0CF8; Tue, 26 May 2020 01:34:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OHfCteP6/aAMerhU20zs00sTXXmEWUoGmZrE1rzMI7YuTkzYdclAM3Z/MhvwWgP3X0T1pOrKWiYlEU0z/epVlK7dgwLsfbsFAGYoSnHi1jbqvx/pDecis8zFWtwy+gxv2lUmDuGr8HSmLo87WSaXA3gxMcEmNWTbdTuCHpXDrA5RwFE8k6wKV1lBF96f/crmB3ycYeJUmDWyTzzoUKLh1BHLluSJg1M8QcZbDk7cHJxX4ASTAwemTCiAiH6A6QxLtCT5WN3oFMjIFXGmE1cMivUk4PcTbFb4wekLJx5ANgP1aCt2rpWnCAH6FcZz+D4oqAn757qFagZz3M+CiiaCeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PiyiuW5vk0ahaomOK1W0EePTPZtc7Wx2z4Z9yx5ETm0=; b=evO+FRE2mivkJ+/2g9VUfF5UC3+uROgpGEOatUu4/mO8BBsXd95bkSRGSkGGtSdDKNRiKtlbZQVLNev/UyD6wikViwNk7JkZBoqfeuJ/f/AVd2Xadi1R7A2XqVJxZ9Y4h4UmJ3ePulxNyIL015W/PPK9klUQFmYUZ0GzoIwf6r0xlKvLewvpxo8nnF5rjek9w2Dpny3Fr7TCORHvKeMY+1fld++zDu7qtdd9FaYwKF4M6SrTUack6YdCTosAANbuzCQlUkTSu8aK6M9TWDw0+wGO/L3BIgiuDX3gDNTXwBghftsVqUmSzTWUuWV7zPyx9gtjchtfHyHgbu5fgBrUvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PiyiuW5vk0ahaomOK1W0EePTPZtc7Wx2z4Z9yx5ETm0=; b=UNmMDs/c0doSrBeZEhrJIVT++sWAo1qGP3E2xmeaiZMJp2w+iDmqbR3mT+hv1+m9i+t1qecjylwLRb8vHKgU1HGLiU8wi7ovjuPpBaXgL8tV+gTVbRYCshMrTDFXUBU1cAih8vLO5DL68iM8Ze3oRt95iqQ2Ef3Cx6/BZO6x6MM= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB4961.eurprd07.prod.outlook.com (2603:10a6:208:f4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.10; Tue, 26 May 2020 08:34:21 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%5]) with mapi id 15.20.3045.014; Tue, 26 May 2020 08:34:21 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" CC: "draft-ymbk-lsvr-l3dl-signing@ietf.org" , Victor Kuarsingh Thread-Topic: WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) Thread-Index: AdYkUVDT0BnEGXp4RCOd+OLt56rHlAO5fP6Q Date: Tue, 26 May 2020 08:34:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [109.131.92.163] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4871a95b-20b7-41d7-c4d3-08d8014f966a x-ms-traffictypediagnostic: AM0PR07MB4961: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 041517DFAB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: taoGT7D7t0IB2PEM5EdJdoGqHtq9Yt8FDUOUhpifCMzbagQy/txP4xYGt+TTo35QwjNvWtbllHWiokpA+t3wSsGfNFh9ummaT9ZhJG3NvuLVvAfuBF74N91cDnL+Dd2ZW/yXcLh0YXzvpPwJu4egqpHrROrrZAgaen0ZpIQB1HAQX+HUakgfcv4j3r19wBLLffvp5TEdWy1texqh4w02yP8Wbtuo61xLHir173b63jHaOzXBIliTLt/pWqaUWIg5mrwqDVcCQ2LDaJUTE8/e5IL+fKI6A39x2CvUQRWHperJMVOehVnt/mQPAxDR7I6sW9qvwrAQ+jeZSBUgztkJ+aJmq+6Q8SxMDx7qETuKh0lQ1DNM5opue1EYAfJsB5YympOJhAWx0+6wOeCKgOc4vw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(346002)(376002)(396003)(166002)(52536014)(8936002)(316002)(64756008)(66476007)(9686003)(66446008)(5660300002)(76116006)(54906003)(66556008)(66946007)(55016002)(86362001)(33656002)(7696005)(6916009)(478600001)(966005)(4326008)(186003)(71200400001)(26005)(6506007)(53546011)(2906002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: z6Iy3k0FjU8Axhpfm3V7B69I3PVTHiI+16ENY3qUMzb72fTUdjhvpb+YyQrvH/lVSVQCe8nh1nQrTurXPKAFMfTCEVoGnj91/NUxDEmTbvZLCNJBAynox1kAyWxMGXTWZpIibAyqF5uDIOERdlNfsLdsR6cZtkkAOFQUbuSOB2zZuTvWPtwvm2T2zhDkS3fmRXCOzSQtlv2954LZ7nx5aN2jXcjKv6hJco9q5oRkd0dk4tCTZ7xoFUVHzSwqt8saU2EB61+2Hmgf3wRdvIQ1bJA6NYfv7U+gLIMGLzeYz26JIF8v8R/2ogLT1S9Lj/C4n85HH1SET+8GzGxS/Z7iaQKqLm/W3z8DSgbeJcoel7BKdy57vy9a+J0WGlvfAOX87+g7kQIwcD22FiRrRl/qgiMaK2eb1NBMEz8UB3Vd8hhxmDAQfgvwiBTEScWVZcOAznbbofWCJNnCqJwHWuw+dIS+Q5tib0FPDcVKv7ga4u02jaEjeURCCorkTDphQtTN x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB6386CCF83730D146E6186AF8E0B00AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4871a95b-20b7-41d7-c4d3-08d8014f966a X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 08:34:20.9871 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kDj7Qp7X62dJunB5ShVDPZXXvY3Sxi5H4G3M9va1tfWCuZK1wGEVJjb/H6jF3tqcPwTUuP44Sz72/wFYzw8d7fZOj1YS3GLevbUwVW4cX40= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4961 Archived-At: Subject: Re: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 08:34:26 -0000 --_000_AM0PR07MB6386CCF83730D146E6186AF8E0B00AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The WG adoption call completed on 21 May 2020. Work to provide security to a new developed technology is critical. The WG adoption call caused few LSVR WG contributors to support, and I hope= that they will actively keep working to develop the technology further. The WG adoption call did not bounce into violent disagreement for adoption. @Authors, please submit this draft as WG document. Kind Regards, G/ From: Lsvr On Behalf Of Van De Velde, Gunter (Nokia= - BE/Antwerp) Sent: Thursday, May 7, 2020 11:27 To: lsvr@ietf.org Cc: draft-ymbk-lsvr-l3dl-signing@ietf.org; Victor Kuarsingh Subject: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to en= d 21 May 2020) Hi All, This begins a 2 week WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (= May 7 - May 21) https://tools.ietf.org/html/draft-ymbk-lsvr-l3dl-signing-01/ During your discussion in the WG Adoption Call, the chairs are looking for = more context as only a 'yeh' or 'ney'. Please indicate the following things: 1) Support to adopt draft " draft-ymbk-lsvr-l3dl-signing-01" as LSVR WG doc= ument? 2) Are there any technical issues with this draft? 3) Which are current pain-points in the draft requiring additional content = and technical attention? 4) What is missing from this draft? The authors (or anybody else) of this draft should send their IPR statement= s in response to this email. Kind Regards, Gunter & Victor LSVR WG co-chairs --_000_AM0PR07MB6386CCF83730D146E6186AF8E0B00AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG adoption call completed on 21 May 2020.<= /o:p>

 

Work to provide security to a new developed technolo= gy is critical.

 

The WG adoption call caused few LSVR WG contributors= to support, and I hope that they will actively keep working to develop the= technology further.

The WG adoption call did not bounce into violent dis= agreement for adoption.

 

@Authors, please submit this draft as WG document.

 

Kind Regards,

G/

 

 

From: Lsvr <lsvr-bounces@ietf.org> O= n Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Thursday, May 7, 2020 11:27
To: lsvr@ietf.org
Cc: draft-ymbk-lsvr-l3dl-signing@ietf.org; Victor Kuarsingh <vict= or@jvknet.com>
Subject: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01= (to end 21 May 2020)

 

Hi All,<= /span>

 

This begins a 2 wee= k WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (May 7 – May 21)

 

https://tools.ietf.or= g/html/draft-ymbk-lsvr-l3dl-signing-01/

 

During your discuss= ion in the WG Adoption Call, the chairs are looking for more context as onl= y a 'yeh' or 'ney'.

 

Please indicate the= following things:

1) Support to adopt= draft " draft-ymbk-lsvr-l3dl-signing-01" as L= SVR WG document?

2) Are there any te= chnical issues with this draft?

3) Which are curren= t pain-points in the draft requiring additional content and technical atten= tion?

4) What is missing = from this draft?

 

The authors (or any= body else) of this draft should send their IPR statements in response to th= is email. 

 

Kind Regards,<= /o:p>

Gunter & Victor=

LSVR WG co-chairs

 

--_000_AM0PR07MB6386CCF83730D146E6186AF8E0B00AM0PR07MB6386eurp_-- From nobody Tue May 26 01:39:58 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE82D3A0CEB; Tue, 26 May 2020 01:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_Y6E14M2S8l; Tue, 26 May 2020 01:39:51 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2131.outbound.protection.outlook.com [40.107.21.131]) (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 318DC3A0CDB; Tue, 26 May 2020 01:39:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VY2I/25Vtq3HExTzaQKb84WkEQTniOCeK8NXmIuz3QXmsrtJXOkw0lb11pR6u2A0H3iYCjVy2kk+jf9Ri+bCeNGP6zoid5ph1lxHIEHAD1/o+oU+FW6KeB3CDrx03L03b3EJneeLedaAAC6A6B1hUZTjRA1Ymjm7AJH24wGr2mCCYp/+XLA7EqVLO3gcxRx0WQ+GW8x0lAtTRQnAq9mZIohuXWTp9dGbs2w+sLVPs/3Ush7o1SbFg01ezy44FegyfumjoJdDyl+KmIZzM/ksd2I9uU1Qk9IsESlPAHcsy9kd3rN3Lg+mAOYfWLHId8q298mJsafxTZ0YVLDkfV91Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S5hD59WSMwdJQ9kdxXwR2spYHxMb21npbHyRUpjbg3I=; b=hw8JDmuRBikA4y0nR4dM8zK/2R8mrTWaFdB48WHeOIoRWn9vqSMqKfkw7/ysxYoUmADfbRUFTpwA7ehiv5lvUaF5s8EFXqZFfedF7Zqp8kIPoY//OTk8jeysEhZwvornSHqOxjcaQC7ihplUiRYa3sCM+MGkDy1qVrUP5JYKx0ARyYvCVnm7iZISGy93xRLOdD67xfZrGIWGwLxUcu/TEU9y0c4l+pB+Vj6dIWoowGjs32i3KCZEa6WWkuSQxGHiSWaaJ5zrhf088jkvRjqOQyBH1hc5YgDe8AsPN/E7SkrfcsvdzdjoFqrv1ebs0OoRoxmS5/jfRQZsfuDwgq7kaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S5hD59WSMwdJQ9kdxXwR2spYHxMb21npbHyRUpjbg3I=; b=wdcRSKSSsORySMczkJ4Co+YbzgZOfkksv1s4E4goWUjbFoU2tyr/KaR/31vM/2vHOHg2zGZtDVRYVyiTjHLiT8TTQEROVMTNPiIavf737gf3b4TTEoWdgKlSp5XEOJU4hIUVgSkrUBrT4NayDqo4+UIfNtdjtLBT2E/QXhToaP0= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB5427.eurprd07.prod.outlook.com (2603:10a6:208:fe::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.8; Tue, 26 May 2020 08:39:48 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%5]) with mapi id 15.20.3045.014; Tue, 26 May 2020 08:39:48 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" CC: Victor Kuarsingh , "draft-ymbk-lsvr-l3dl-ulpc@ietf.org" Thread-Topic: WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 21 May 2020) Thread-Index: AdYkSDxhl1hIWSVUSZuu5GZsy6VuRQO7tG4A Date: Tue, 26 May 2020 08:39:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [109.131.92.163] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ee815128-244e-4265-4f5c-08d8015059c9 x-ms-traffictypediagnostic: AM0PR07MB5427: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 041517DFAB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nAVKoCC/kS+fDPsBjkSkwXleUcuh/XskcV2+NGDamIZIKQOdgSPYxb+S5uuGcSzwro+Eo7E0NpRIBoarRnd1Llha5GPtDQOG4X7m+/nlYRcnTftYCYvO2nojfXul4hDaC68+5yKW2/4k1JykkFzK46Uhf1LLPt3stsHY7PydOb7PQMK8D3Z9d37tzWpS3TbpCVQme7t7p9dBTRlDAUJvTRHiKG2ljzXO1KwjRK3HvZBPiqe/IHKYPxsibUrBP5gULDVmjwg5+7U1ShB4H5v10VMcVL5QD+JXJzcFgul7o2y2R+CTLUCycuTv0BGUggofETp/a9egXobFLb3BcccEqmRIwrlb8EWC6StP1wbs9S9VqXcGKlCTf+CnolWvqlRPGAgW4xI16jQnlWeu526Ljg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(346002)(376002)(39860400002)(2906002)(76116006)(66946007)(64756008)(66556008)(52536014)(66476007)(66446008)(478600001)(966005)(166002)(9686003)(55016002)(33656002)(86362001)(4326008)(8936002)(5660300002)(6916009)(71200400001)(53546011)(54906003)(7696005)(316002)(6506007)(26005)(8676002)(9326002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: riflofjELL3s8F3tDxrkGJVoXoyyQiSkb24yQnJ/JTJvwLLeQ2jMCtREUcMCtXvjWaFkhJdbySsvJ1TYRvuttfZDE+aWsHkHsTBIjcezBpQtrWiy5ju4+sTws3G4L4WihS1/T4d1PxmHAcsfyusDPfhY9t1d+6poVp0rMeTRvXGVuhIBhF8AOZAKnUoUi0QUk+mYYRKUODa2LJ1WXT59qJ+Dgv691eo5FHdxS0V37HA86E/T/btMToiWJF+tD2NJ6VThS18f9p3BLp7rj2Gz8gtGJH8sHqcv82JDdxLqZQx2Ecsq11KPF+zMdFkEYp7MrPoS6Ldh3rN2293wAY5DZ6sJUOt0zWUKKfeDRkPkuNdHGWjKMUTktWXtAz8REE7bvBMyfdwdol//VKZcKfEnPIl+ZngSKPoSBMZEzOu8JhabFbZ1yD02khc/RK6swYIghTfxGgDwdRWqn97DgaQREB7kq0Ir0+4CM51xhYaimNiQFMHvBg2QD4cqM9cDr7/d x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB6386C9A51F969F556AE18E85E0B00AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee815128-244e-4265-4f5c-08d8015059c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 08:39:48.7246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PJz/Zu5DUjrM9ebTu6E3hu1Muu+iQTaWlPUdLghQRMeRwAcW7K9T+EfKbGt/ZSqyMS6TP80k6U00Ofd7dcmFoi1c7WfPxiRMOWRhHItmZqA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5427 Archived-At: Subject: Re: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 08:39:56 -0000 --_000_AM0PR07MB6386C9A51F969F556AE18E85E0B00AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The WG adoption call has ended for this draft. There were few voices for support, and there was no disagreement to adopt t= his work. Using LSVR BGP-SPF in an automated and hands-free configuration is an impor= tant technology property. @Authors of this draft, please submit your work as a LSVR WG document at yo= ur convenience, Kind Regards, Gunter From: Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Thursday, May 7, 2020 10:21 To: lsvr@ietf.org Cc: Victor Kuarsingh ; draft-ymbk-lsvr-l3dl-ulpc@ietf.or= g Subject: WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 21 May 2= 020) Hi All, This begins a 2 week WG adoption call draft-ymbk-lsvr-l3dl-ulpc-03 (May 7 -= May 21) https://datatracker.ietf.org/doc/draft-ymbk-lsvr-l3dl-ulpc/ During your discussion in the WG Adoption Call, the chairs are looking for = more context as only a 'yeh' or 'ney'. Please indicate the following things: 1) Support to adopt draft "draft-ymbk-lsvr-l3dl-ulpc-03" as LSVR WG documen= t? 2) Are there any technical issues with this draft? 3) Which are current pain-points in the draft requiring additional content = and technical attention? 4) What is missing from this draft? The authors (or anybody else) of this draft should send their IPR statement= s in response to this email. Kind Regards, Gunter & Victor LSVR WG co-chairs --_000_AM0PR07MB6386C9A51F969F556AE18E85E0B00AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The WG adoption call has ended for this draft.<= /o:p>

There were few voices for support, and there was no = disagreement to adopt this work.

 

Using LSVR BGP-SPF in an automated and hands-free co= nfiguration is an important technology property.

 

@Authors of this draft, please submit your work as a= LSVR WG document at your convenience,

 

Kind Regards,

Gunter

 

 

From: Van De Velde, Gunter (Nokia - BE/Antwer= p)
Sent: Thursday, May 7, 2020 10:21
To: lsvr@ietf.org
Cc: Victor Kuarsingh <victor@jvknet.com>; draft-ymbk-lsvr-l3dl= -ulpc@ietf.org
Subject: WG adoption call for draft-ymbk-lsvr-l3dl-ulpc-03 (to end 2= 1 May 2020)

 

Hi All,<= /span>

 

This begins a 2 wee= k WG adoption call draft-ymbk-lsvr-l3dl-ulpc-03 (May 7 – May 21)

 

https://datatracker.i= etf.org/doc/draft-ymbk-lsvr-l3dl-ulpc/

 

During your discuss= ion in the WG Adoption Call, the chairs are looking for more context as onl= y a 'yeh' or 'ney'.

 

Please indicate the= following things:

1) Support to adopt= draft "draft-ymbk-lsvr-l3dl-ulpc-03" as LSVR WG document?=

2) Are there any te= chnical issues with this draft?

3) Which are curren= t pain-points in the draft requiring additional content and technical atten= tion?

4) What is missing = from this draft?

 

The authors (or any= body else) of this draft should send their IPR statements in response to th= is email. 

 

Kind Regards,<= /o:p>

Gunter & Victor=

LSVR WG co-chairs

 

 

 

--_000_AM0PR07MB6386C9A51F969F556AE18E85E0B00AM0PR07MB6386eurp_-- From nobody Tue May 26 04:51:53 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB84D3A0ED2; Tue, 26 May 2020 04:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gunter Van de Velde via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Cc: lsvr-chairs@ietf.org, gunter.van_de_velde@nokia.com, lsvr@ietf.org, Gunter Van de Velde , iesg-secretary@ietf.org Message-ID: <159049391094.15133.1398098358541105033@ietfa.amsl.com> Date: Tue, 26 May 2020 04:51:50 -0700 Archived-At: Subject: [Lsvr] Publication has been requested for draft-ietf-lsvr-bgp-spf-09 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 11:51:51 -0000 Gunter Van de Velde has requested publication of draft-ietf-lsvr-bgp-spf-09 as Proposed Standard on behalf of the LSVR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/ From nobody Tue May 26 04:52:52 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 420433A0ECB; Tue, 26 May 2020 04:52:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gunter Van de Velde via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Cc: gunter.van_de_velde@nokia.com, Gunter Van de Velde , iesg-secretary@ietf.org, lsvr@ietf.org, lsvr-chairs@ietf.org Message-ID: <159049396325.6899.3492184990041760580@ietfa.amsl.com> Date: Tue, 26 May 2020 04:52:43 -0700 Archived-At: Subject: [Lsvr] Publication has been requested for draft-ietf-lsvr-applicability-05 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 11:52:50 -0000 Gunter Van de Velde has requested publication of draft-ietf-lsvr-applicability-05 as Informational on behalf of the LSVR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/ From nobody Tue May 26 05:12:26 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6D83A0EA1 for ; Tue, 26 May 2020 05:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl13LdlIu-xo for ; Tue, 26 May 2020 05:12:19 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70098.outbound.protection.outlook.com [40.107.7.98]) (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 432623A0EA0 for ; Tue, 26 May 2020 05:12:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X4iEvVQK4wQ/5HFP0/Ck0/KBl0X7E+hFl3WDUAPXb0o0VCsePJJOBu5zX8qSzshF6+uXGDEwbQbia2BZKA5K3vF5dKZq+47rPoTldj11p3aWGbD0Ho/HjYQM76/vq726IFqbSu4yR+jpDuLtTYSTi6iEnhnJjvJkFp0YnRRkbwJFQtgk+xxYp2JFLSPvv0YS9jjaHBAXM9jLXK3HiZdrlOwCcQeH570/90dimWj2ZvZb8mSYLDnJsQP3G54gLCeTTROrKsRwfBZopbWKD6GQv+t8T0o7W68zJhHpXCcQXtvbztlGCpnY5oFU6X0CPh/a3s64Q9JKeZwOj0SQ0jA/Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrsJWSfzdmh7K4ch4mqeuw7YnchqOXT/uT3ZuRxyfh4=; b=fo8p1LSyjCGw/zQgo5O2DUvjkl/XReuR6MtSf/RmxVd2UMumMw3s9GA3lW3sX0SfpBxx/VuZnek8oJC8Vxt+hJc85LDvxix16ZRx00pfIlJ8Pm54ypXLiZq77Pdghj9idcMrDcnH161sU4y1zdOjHE8azsULIK3P65nZcaWP9vteEOfKDjFaRNTvy9vuqavrQJAzRbHC2JLEo0xR+KbCZgRobRHmIt0658xZHW2zoeJukRIOt7jnHSUa6XEo9x+t9iN0n74U4LtD/jSaYde8A8AQJhUrg7mLa7iQEO1heNm0ZyQEODDMDtxON/sXzW2/u2SpSKQGvuGpss2bQJMC7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrsJWSfzdmh7K4ch4mqeuw7YnchqOXT/uT3ZuRxyfh4=; b=ZsxYG4VCbq7kTQh6DFEc9a+JOj2dJ6eRJSQ7efDpCtmh4cCOZG+DY2KQHnzDmusQMkstzNb+cg5fXXyoLdYGGjBtasdn1XctDkPAj+pAPpxQkTBp9OF1B+qyROgtxs8lD5QM2G6kAlKQM259V4juztEOvPgkMTozUFlW64UCbyY= Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by AM0PR07MB4164.eurprd07.prod.outlook.com (2603:10a6:208:b7::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Tue, 26 May 2020 12:12:16 +0000 Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::9ca9:ed1d:36b4:b0e9%5]) with mapi id 15.20.3045.014; Tue, 26 May 2020 12:12:16 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" CC: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Victor Kuarsingh Thread-Topic: LSVR WG Status update 26-May-2020 Thread-Index: AdYzVWd5HBqPF4mtTRiSjfzVc4mvdw== Date: Tue, 26 May 2020 12:12:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [109.131.92.163] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c05fd9ea-b8e1-4b4f-baa3-08d8016e07d6 x-ms-traffictypediagnostic: AM0PR07MB4164: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 041517DFAB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GLi8J4s4x17zAuNQ1yrncUDa9ACG+Ysl2KyrHc8+HnvW558xqt87AO0CA+fL+xTYDjTj8bEHv34us3ILZ45nDPJA6FSeeK677AhXd3Ipr+siVMSYY0Dwgenq0FKFLD2rsS2FXJIQnGDLy3Td0e91IWnHPSic0FgDRVQ/0pbhe/Zo6sgwJC9cVSo4cb8NlaFr5VO0F+sCMQbQy5IZXLKOZjA5GQGP24dnQsH1ywEzQShkPxm8apdef5T81qpSBV3TEcFQf8oADf3abJSBqC+GSeCFCO4XUl/ZflW8VLWf6wQ+8veRY0a748e6ZcYQMPZ/XN02Os55uRvOcqtvx4kzJAFKizWbg8VJpFMdUhz6YTJ/+dhjKd+ynIHcv1c9jaXs4L9zmRzj80X5UjBRysdEi2FAulX3ytr9fOCrDUQ14KiU3PUv4bFd9/V1RR7CmSHewcqqtSzARi/qvazAchwQ9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(396003)(39860400002)(366004)(346002)(86362001)(2906002)(54906003)(316002)(66446008)(66476007)(166002)(64756008)(8936002)(66946007)(76116006)(478600001)(4326008)(5660300002)(53546011)(26005)(6506007)(7696005)(55016002)(3480700007)(71200400001)(186003)(9326002)(8676002)(66556008)(52536014)(9686003)(6916009)(33656002)(15650500001)(489414009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 3A66ouY/o2QQJZ7OTsimKm7ZH/yyDy7i3i0iY+VDaA6TjHlf237sfwUS+Kb9JlQL6+DgHnSVX2+d2iyZZlQoVS09H31FUU7Lr35JwPurUf4n41MzI7deUgAB5XKoww5Xq+qykuhKTdsN8MAP/gCBEGufiQZxlm7kKswthazmJEER6xL6Fu0jU1sEFYx1VMVmpJvw6XRoFBlt8MWojfOTX1uzIVv8K04jVQDT5CYSXp4NAoxe8+qVOr2T8/qjVsjh7KJpEGVqxz23wQddmydJt7tFZQXjsPDzKo/cFTuAGqbx5B0k+F0svJ8S2dWMfAhEFIuto2sSsZKAtbpMLm9flmxQiSv3S/o7vGdiK2ANmoPz2tXNY04RWJh/kWs0LQn2UQaGDueiqRJ+KKQyz3dC38ggq+N6cfV/DdWczqBpa1n5N8GfUhQu2I52gRjirRtLoeKiNNayhuACHpGz240pwBiPWAPmwnOM+otChO/K9ub1Z09fEO58kptrP4ykpjrX Content-Type: multipart/alternative; boundary="_000_AM0PR07MB6386B616AC3399BBA575B335E0B00AM0PR07MB6386eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c05fd9ea-b8e1-4b4f-baa3-08d8016e07d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 12:12:16.1044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jYVvWwagwy7B8OuiDxF893d+O7dPHjrGlkF161SeoGr9Fy720jS2hVntq/ZM+w3Y2FUitMZiuPYQzKjYIoNjV2U8zObdBkiyZtMQr2ryzis= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4164 Archived-At: Subject: [Lsvr] LSVR WG Status update 26-May-2020 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 12:12:22 -0000 --_000_AM0PR07MB6386B616AC3399BBA575B335E0B00AM0PR07MB6386eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We are a few weeks later now, and the LSVR WG progressed some document stat= e's. Documents send to IESG with publication request draft-ietf-lsvr-bgp-spf-09 (send to IESG on 26 May 2020) draft-ietf-lsvr-applicability-05 (send to IESG on 26 May 2020) Documents passed WG adoption call and are adopted as WG document (document = submit is pending) Layer 3 Discovery and Liveness Signing (https://tools.ietf.org/html/draft= -ymbk-lsvr-l3dl-signing-01) L3DL Upper Layer Protocol Configuration (https://tools.ietf.org/html/draf= t-ymbk-lsvr-l3dl-ulpc-03) Documents in rework after the WGLC Layer 3 Discovery and Liveness (https://tools.ietf.org/html/draft-ietf-ls= vr-l3dl-05) Kind Regards, G/ From: Lsvr On Behalf Of Van De Velde, Gunter (Nokia= - BE/Antwerp) Sent: Wednesday, May 6, 2020 11:26 To: lsvr@ietf.org Subject: [Lsvr] LSVR WG Status update 6-May-2020 Hi All, It has been a while, and the very special IETF107 starts to be faded away i= n our memories. For your convenience find the LSVR document status update. WGLC Documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AD requested for drafts "draft-ietf-lsvr-bgp-spf" and "draft-ietf-lsvr-appl= icability" to be submitted as a combined package. draft-ietf-lsvr-bgp-spf-08 * Successfully passed WGLC and is ready to be send to IESG * Shepherd writeup in progress draft-ietf-lsvr-applicability-05 * Successfully passed WGLC * Waiting for all authors to respond to IPR awareness call * Shepherd writeup in progress Documents with pending WGLC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Layer 3 Discovery and Liveness (draft-ietf-lsvr-l3dl-03) * TSVART early review: ready with issues * Document is in good state * Implementations are being progressed * Once document is refresh WGLC is initiated Documents ready to be adopted =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Layer 3 Discovery and Liveness Signing (draft-ymbk-lsvr-l3dl-signing-00) * WG adoption requested once document refreshed in datatracker L3DL Upper Layer Protocol Configuration (draft-ymbk-lsvr-l3dl-ulpc-02) * WG adoption requested once document refreshed in datatracker Milestone Documents missing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D YANG specification for LSVR Brgds, Gunter & Victor LSVR co-chairs --_000_AM0PR07MB6386B616AC3399BBA575B335E0B00AM0PR07MB6386eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We are a few weeks later now, and the LSVR WG progre= ssed some document state’s.

 

Documents send to IESG with publication request=

  draft-ietf-lsvr-bgp-spf-09 (send to IESG on 2= 6 May 2020)

  draft-ietf-lsvr-applicability-05 (send to IES= G on 26 May 2020)

 

Documents passed WG adoption call and are adopted as= WG document (document submit is pending)

  Layer 3 Discovery and Liveness Signing (https://= tools.ietf.org/html/draft-ymbk-lsvr-l3dl-signing-01)

  L3DL Upper Layer Protocol Configuration (https://to= ols.ietf.org/html/draft-ymbk-lsvr-l3dl-ulpc-03)

 

Documents in rework after the WGLC

  Layer 3 Discovery and Liveness (https://tools.ietf.org/h= tml/draft-ietf-lsvr-l3dl-05)

 

Kind Regards,

G/

 

 

From: Lsvr <lsvr-bounces@ietf.org> O= n Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Wednesday, May 6, 2020 11:26
To: lsvr@ietf.org
Subject: [Lsvr] LSVR WG Status update 6-May-2020

 

Hi All,

 

It has been a while, and the very special IETF107 st= arts to be faded away in our memories.

For your convenience find the LSVR document status u= pdate.

 

WGLC Documents

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

 

AD requested for drafts “draft-ietf-lsvr-bgp-s= pf” and “draft-ietf-lsvr-applicability” to be submitted a= s a combined package.

 

  draft-ietf-lsvr-bgp-spf-08

  • Successfully passed WGLC and is ready to be send to IESG
  • Shepherd writeup in progress

 

  draft-ietf-lsvr-applicability-05

  • Successfully passed WGLC
  • Waiting for all authors= to respond to IPR awareness call
  • Shepherd writeup in = progress

 

Documents with pending WGLC

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

 

  Layer 3 Discovery and Liveness (draft-ietf-ls= vr-l3dl-03)

  • TSVART early review: ready with issues
  • Document = is in good state
  • Implementations are being progressed<= o:p>
  • Once document is refresh WGLC is initiated<= /li>

 

Documents ready to be adopted

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

 

  Layer 3 Discovery and Liveness Signing (draft= -ymbk-lsvr-l3dl-signing-00)

  • WG adoption requested once document refreshed in datatracker

  L3DL Upper Layer Protocol Configuration (draf= t-ymbk-lsvr-l3dl-ulpc-02)

  • WG adoption requested once document refreshed in datatracker

 

Milestone Documents missing

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

 

  YANG specification for LSVR

 

 

Brgds,

Gunter & Victor

LSVR co-chairs

--_000_AM0PR07MB6386B616AC3399BBA575B335E0B00AM0PR07MB6386eurp_-- From nobody Tue May 26 10:21:44 2020 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015C13A0B12; Tue, 26 May 2020 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAEqyIpvhH5q; Tue, 26 May 2020 10:21:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 637443A0AE9; Tue, 26 May 2020 10:21:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jddGb-0007KT-UN; Tue, 26 May 2020 17:21:30 +0000 Date: Tue, 26 May 2020 10:21:29 -0700 Message-ID: From: Randy Bush To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "lsvr@ietf.org" , "draft-ymbk-lsvr-l3dl-signing@ietf.org" , Victor Kuarsingh In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] WG adoption call for draft-ymbk-lsvr-l3dl-signing-01 (to end 21 May 2020) X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 17:21:43 -0000 thanks gunter and victor both drafts uploaded as wg -00s randy From nobody Wed May 27 01:15:34 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 535153A0B58; Wed, 27 May 2020 01:15:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsvr@ietf.org Message-ID: <159056733222.26320.9650341477856436344@ietfa.amsl.com> Date: Wed, 27 May 2020 01:15:32 -0700 Archived-At: Subject: [Lsvr] I-D Action: draft-ietf-lsvr-l3dl-signing-00.txt X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 08:15:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Vector Routing WG of the IETF. Title : Layer 3 Discovery and Liveness Signing Authors : Randy Bush Rob Austein Filename : draft-ietf-lsvr-l3dl-signing-00.txt Pages : 9 Date : 2020-05-26 Abstract: The Layer 3 Discovery and Liveness protocol OPEN PDU may contain a key and a certificate, which can be used to verify signatures on subsequent PDUs. This document describes two mechanisms based on digital signatures, one that is Trust On First Use (TOFU), and one that uses certificates to provide authentication as well as session integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl-signing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-signing-00 https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-l3dl-signing-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 27 01:16:16 2020 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C943A0BA6; Wed, 27 May 2020 01:16:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsvr@ietf.org Message-ID: <159056736770.26354.10122198949605373660@ietfa.amsl.com> Date: Wed, 27 May 2020 01:16:07 -0700 Archived-At: Subject: [Lsvr] I-D Action: draft-ietf-lsvr-l3dl-ulpc-00.txt X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 08:16:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Vector Routing WG of the IETF. Title : L3DL Upper Layer Protocol Configuration Authors : Randy Bush Keyur Patel Filename : draft-ietf-lsvr-l3dl-ulpc-00.txt Pages : 8 Date : 2020-05-26 Abstract: This document users the Layer 3 Liveness and Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper layer protocols such as the BGP family. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl-ulpc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-ulpc-00 https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-l3dl-ulpc-00 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/