RE: Where to continue work on the Unified Identifier?
<email@example.com> Mon, 10 February 2020 22:56 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6997A120887; Mon, 10 Feb 2020 14:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([184.108.40.206]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXcw0-q5jIeO; Mon, 10 Feb 2020 14:56:51 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [220.127.116.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620DC120889; Mon, 10 Feb 2020 14:56:50 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48Gh9X3CVrz1y2T; Mon, 10 Feb 2020 23:56:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581375408; bh=ptznP5BGJFiyzyQawV/BIA1FWYkyvvCMUEyzLII/JHA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=jffwGG7pF96AVFDNCViKYeZ+SL++q7D24f8XawYII0SirGJ3bcUKsYlMGZLxWUwwT xbeRIKQ8PvQ78Ihqr/A883ZAgaLGXAa+gFHYM8JaS5/NpZZ5cw0jzUkOF4aFVPK5Oo QvgdhlqY914sd3hb3EJRnuW1G+nPQylw3tcshBHTidRxIgXxXGVfGFjpXaauIBSJUo RsUWIU9EF8ZquZpc5XXmK8bMgSNFihMQngaQuKhkmgddHfMzUiLoPgzcIcVMh85dsz OIYGvwGafLip9kNkHOergDrlufdgDw7tIH/PyCZJDOXFLz2FWBkJZPK16bMWKcsTD9 T5lPaWnUJtXpw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 48Gh9X1zkpzDq8Z; Mon, 10 Feb 2020 23:56:48 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Mon, 10 Feb 2020 23:56:47 +0100
To: Greg Mirsky <firstname.lastname@example.org>
CC: "email@example.com" <firstname.lastname@example.org>, 6man WG <email@example.com>, "firstname.lastname@example.org" <email@example.com>
Subject: RE: Where to continue work on the Unified Identifier?
Thread-Topic: Where to continue work on the Unified Identifier?
Date: Mon, 10 Feb 2020 22:56:47 +0000
Accept-Language: fr-FR, en-US
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48D9EC50OPEXCAUBM43corp_"
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 22:56:54 -0000
Dear Greg, As you know, there are a number of proposals in the so called ‘Beyond SRv6’ topic. Unifier Identifier is one, but there are others. Given that we are not seeing some natural convergence on a solution, I think that the WG needs to refine the technical issue(s) that we want to address and the requirements for the new solution(s)/extension(s). Cf slide 9 of latest chair’s slides https://datatracker.ietf.org/meeting/106/materials/slides-106-spring-sessa-chairs-slides-01 more specifically > Several solutions on the table. Need to be explicit about the goals and the costs of each proposal. > ■ Authors are invited to explicit both in their document (short text) Then we can look at merits and costs of each solution, possibly refine them, possibly converge on a single one, probably drop multiples. This first step is to be done in the SPRING WG. I’m assuming that this part be the hardest part. Once SPRING has figured out what we want to do on this topic, I would expect the header format and processing be done in the 6MAN WG. (This may eventually depends on the outcome of this first step; in particular this is assuming that both spring & 6man want & need something new) In order to prepare this first step, do you think that for the next meeting, the document could be updated to spell out: a) The goals/requirements that this proposal wants to address. Aka, why do we need a fourth SR data plane. b) Which goals/requirements are addressed by this proposal, and what are the costs. I would encourage to carefully think about “a” as it would be good to avoid discovering, in 3 years from now, that we missed something (again) and that a new team asks for a N+1 SR dataplane. On a personal note, I’d be also interested in any feedback about the reasons why we missed those requirements/goals when SRv6 has been originally proposed, discussed and specified, in order to avoid repeating the same mistakes. Thank you, Regards, --Bruno From: Greg Mirsky [mailto:firstname.lastname@example.org] Sent: Monday, February 10, 2020 11:16 PM To: 6man WG; email@example.com Cc: firstname.lastname@example.org Subject: Where to continue work on the Unified Identifier? Dear Chairs of SPRING and 6man WGs, on behalf of the authors of the Unified Identifier in SRH draft, I'm asking for your consideration and suggestion. We're looking for your decision on which WG may, at the time, become the adopter of this work. One the one hand, as the draft proposes an update to SRH by allocating the new field, 6man WG seems as logical as it was the group that has led the work on SRH specification. On the other hand, a significant part of the draft is on using the Unified Identifier to realize the Segment Routing with SRH in an IPv6 network. Please let us know if you have any further questions or concerns. Thank you for your consideration. Regards, Greg _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- Where to continue work on the Unified Identifier? Greg Mirsky
- RE: Where to continue work on the Unified Identif… bruno.decraene