Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13
Chris Bowers <chrisbowers.ietf@gmail.com> Fri, 08 June 2018 18:14 UTC
Return-Path: <chrisbowers.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724A4130F62; Fri, 8 Jun 2018 11:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIMxHWkQ_MA4; Fri, 8 Jun 2018 11:14:21 -0700 (PDT)
Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 9B50E127333; Fri, 8 Jun 2018 11:14:21 -0700 (PDT)
Received: by mail-yw0-x242.google.com with SMTP id p14-v6so4397176ywm.11; Fri, 08 Jun 2018 11:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fr/N7wLsQQsTpNREEP3oOfhdeLZRPuYiupNwZAIxU4g=; b=n6cga07RxSGU6IArHfsDLz9nxhfdgKmxCbe/2b2OqcenPotjlk+j3MzkuDxbz8F3M8 3HUeZtcowFyJwBpbEoMCwcC6I4gbYt/jeoxHdJtIpPlpN+dby4uuZhuc1gaTIKO6sasY 0RB2CPSrqQSfQ58J6kxWjxSN2N0m1Butnim2PWDraT+4YGDEFg8P674rxnbiTo7yocif uh9Z6leYJLVQFMVvnzpUxuKKoh9Yf0QAVavViwo4AX5X3gzqB4VMBtznAjc60WDA/fb2 wXx1BO39wegxytN+c4vyZwWSnEfLEPsCEmE8qtXHmydJmuaUQiH+l1Jha8qpQQ/ijCPM jlpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fr/N7wLsQQsTpNREEP3oOfhdeLZRPuYiupNwZAIxU4g=; b=orZaVriRr5/0O7lW7oEVU92kZtW+zwUAAE9VOQl9WcCgB4lR/X7bEzLlcbc+1jItxl qFmjcnOd6y3A+LTxotiNkqaGK2Bp5mF0xI9glfmk494Zk2XS+Vlk5RfazcIGD17Q0eCb 8azWxzbm1GlAvgUvcjMif/Dcp24NE2oXJcJAxQFhRetp6GUG9N3W+avRR0+cDcQBkhR4 yuMIPPUVEk6dsRYdCk17F1lnmDORFA3rGRQWm0iVgdbpGTcepASOcp2J5hWCsssc6ne8 JdlNgb2K3rFB4yolTSfR+5C8YHOkDiUFlYQHtyxWr+xGfCNjjO59Yl71X8PZ9DCRxTvG wp2g==
X-Gm-Message-State: APt69E1GKUK2h5q+VfcLS2cq7zPP7nOw3XT3rBwqcwpmmJVg4/AWXSwK B0km7uO4LEV3JI3SM7uvUf9eSL3z/1FwLLTdNJG+Yg==
X-Google-Smtp-Source: ADUXVKIRyo0A6WbwSd8x0i3ymwpfCAMokxtDwOWHHAlfT7QJLEiKdWQjIDgosTZaNtLolVcfq/A68OeVdyixoTdx9RY=
X-Received: by 2002:a0d:c2c2:: with SMTP id e185-v6mr4148997ywd.326.1528481660437; Fri, 08 Jun 2018 11:14:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:4583:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 11:14:00 -0700 (PDT)
In-Reply-To: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <28960_1527182067_5B06F2F3_28960_194_1_53C29892C857584299CBF5D05346208A47A53592@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Chris Bowers <chrisbowers.ietf@gmail.com>
Date: Fri, 08 Jun 2018 13:14:00 -0500
Message-ID: <CAHzoHbtfjZQXivEXutZir5Uxdk5U1LH5SEKQJkHrPQWKVmdTfQ@mail.gmail.com>
To: SPRING WG List <spring@ietf.org>, bruno.decraene@orange.com
Cc: "draft-ietf-spring-segment-routing-mpls@ietf.org" <draft-ietf-spring-segment-routing-mpls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006a894a056e255efe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/CRi96MnH4Bsu-tqlz5u26Man9xw>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-segment-routing-mpls-13
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2018 18:14:26 -0000
SPRING WG, I generally support publication of draft-ietf-spring-segment-routing-mpls. However, I think that the text in sections 2.5 and 2.6 (on incoming label collisions) needs some work before publication. This text was added to the draft a few months ago, and has not gotten much review from the WG as a whole. The review and proposed text below focuses on these sections. As I understand the current text of the draft, the general approach to resolving incoming label collisions seems well-reasoned and complete. However, it is possible that my interpretation of these tie-breaking rules is not what the authors intended. I'd like to propose the examples below to be included in the draft to help clarify the tie-breaking rules for incoming label collisions described in section 2.5. I have highlighted several cases in these examples, where I think the rules in section 2.5 need to be clarified in order to unambiguously determine the winning FEC in an example. It may also be the case that the authors or other WG participants will disagree with the interpretation of the rules used to choose a winning FEC in some of these examples. In that case, we should discuss what is the correct interpretation, and clarify the text in the draft to make the correct interpretation clear. Incoming label collision examples ========= Node A OSPF default admin distance for implementation=50 ISIS default admin distance for implementation=60 ========= Example incoming label conflict for label=1005 on node A FEC1) OSPF prefix sid advertisement from node B for 198.51.100.5/32 with index=5 OSPF SRGB on node A = [1000,1999] Incoming label=1005 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.105/32 with index=5 ISIS SRGB on node A = [1000,1999] Incoming label=1005 FEC1 and FEC2 both use dynamic SID assignment. Since neither of the FEC types is SR Policy, we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins. ========= Example incoming label conflict for label=1006 on node A FEC1) OSPF prefix sid advertisement from node B for 198.51.100.6/32 with index=6 OSPF SRGB on node A = [1000,1999] Incoming label=1006 FEC2) ISIS adjacency sid advertisement from node A with label=1006 Incoming label=1006 Node A allocates this adjacency SID dynamically, and it may differ across router reboots. FEC1 and FEC2 both use dynamic SID assignment. Since neither of the FEC types is SR Policy, we use the default admin distances of 50 and 60 to break the tie. So FEC1 wins. ========= Example incoming label conflict for label=1007 on node A FEC1) OSPF prefix sid advertisement from node B for 198.51.100.7/32 with index=7 OSPF SRGB on node A = [1000,1999] Incoming label=1007 FEC2) ISIS adjacency sid advertisement from node A with label=1007 Incoming label=1007 Node A assigns this adjacency SID explicitly via configuration, so the adjacency SID survives router reboots. FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID assignment. So FEC2 wins. ========= Example incoming label conflict for label=1008 on node A FEC1) OSPF prefix sid advertisement from node B for 198.51.100.8/32 with index=8 OSPF SRGB on node A = [1000,1999] Incoming label=1008 FEC2) SR Policy advertisement from controller to node A Endpoint = 192.0.2.208, color = 100, SID-List = <S1, S2> Binding-SID label = 1008 FEC1 and FEC2 both use dynamic SID assignment. Since one of the FEC types is SR Policy, default admin distance is not used to break the tie. /* The text in Section 2.5.1 needs to be clarified to specify whether SR Policy always loses or always wins in this case. */ ========= Example incoming label conflict for label=1009 on node A FEC1) OSPF adjacency sid advertisement by node A with label=1009 Incoming label=1009 Node A assigns this adjacency SID explicitly via configuration, so the adjacency SID survives router reboots. FEC2) ISIS adjacency sid advertisement by node A with label=1009 Incoming label=1009 Node A assigns this adjacency SID explicitly via configuration, so the adjacency SID survives router reboots. FEC1 and FEC2 both use explicit SID assignment. This kind of incoming label collision should never occur, since an implement of explicit SID assignment MUST guarantee collision freeness on the same router. ======== Example incoming label conflict for label=1010 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.110/32 with index=10 ISIS SRGB on node A = [1000,1999] Incoming label=1010 FEC2) ISIS adjacency sid advertisement by node A with label=1010 Incoming label=1010 Node A allocates this adjacency SID dynamically, and it may differ across router reboots. FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. FEC1 has FEC type code-point=120, while FEC2 has FEC type code-point=130. Therefore, FEC1 wins. ========= Example incoming label conflict for label=1011 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.111/32 with index=11 ISIS SRGB on node A = [1000,1999] Incoming label=1011 FEC2) ISIS prefix sid advertisement from node C for 2001:DB8:1000::11/128 with index=11 ISIS SRGB on node A = [1000,1999] Incoming label=1011 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. Both FECs have FEC type code-point=120. So we compare address family. Since IPv4 is preferred over IPv6, FEC1 wins. ========= Example incoming label conflict for label=1012 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.112/32 with index=12 ISIS SRGB on node A = [1000,1999] Incoming label=1012 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.128/30 with index=12 ISIS SRGB on node A = [1000,1999] Incoming label=1012 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. Both FECs have FEC type code-point=120. So we compare address family. Both are IPv4 address family, so we compare prefix length. FEC1 has prefix length=32, and FEC2 has prefix length=30, so FEC2 wins. ========= Example incoming label conflict for label=1013 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.113/32 with index=13 ISIS SRGB on node A = [1000,1999] Incoming label=1013 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.213/32 with index=13 ISIS SRGB on node A = [1000,1999] Incoming label=1013 FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are from the same MCC, they have the same default admin distance. So we compare FEC type code-point. Both FECs have FEC type code-point=120. So we compare address family. Both are IPv4 address family, so we compare prefix length. Prefix lengths are the same, so we compare prefix. FEC1 has the lower prefix, so FEC1 wins. ========= Example incoming label conflict for label=1014 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.114/32 with index=14 Routing Instance ID = 1000 ISIS SRGB on node A = [1000,1999] Incoming label=1014 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.114/32 with index=14 Routing Instance ID = 2000 ISIS SRGB on node A = [1000,1999] Incoming label=1014 These two FECs match all the way through the prefix length and prefix. So Routing Instance ID breaks the tie, with FEC1 winning. ========= Example incoming label conflict for label=1015 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.115/32 with index=15 Routing Instance ID = 1000 ISIS Multi-topology ID = 50 ISIS SRGB on node A = [1000,1999] Incoming label=1015 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.115/32 with index=15 Routing Instance ID = 1000 ISIS Multi-topology ID = 40 ISIS SRGB on node A = [1000,1999] Incoming label=1015 These two FECs match all the way through the prefix length, prefix, and Routing Instance ID. We compare ISIS Multi-topology ID, so FEC2 wins. /* There appears to be a typo in section 2.5.1, with two different orderings shown for a prefix-based FEC: Prefix, Routing Instance, Topology, Algorithm and (Prefix Length, Prefix, SR Algorithm, routing_instance_id, Topology) This needs to be corrected. */ ========= Example incoming label conflict for label=1016 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.116/32 with index=16 Routing Instance ID = 1000 ISIS Multi-topology ID = 50 SR algorithm = 0 ISIS SRGB on node A = [1000,1999] Incoming label=1016 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.116/32 with index=16 Routing Instance ID = 1000 ISIS Multi-topology ID = 50 SR algorithm = 22 ISIS SRGB on node A = [1000,1999] Incoming label=1016 These two FECs match all the way through the prefix length, prefix, and Routing Instance ID, and Multi-topology ID. We compare SR algorithm ID, so FEC1 wins. ========= Example incoming label conflict for label=1017 on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.117/32 with index=17 ISIS SRGB on node A = [1000,1999] Incoming label=1017 FEC2) ISIS mapping server advertisement (SID/Label Binding TLV) from node D: Range=100, Prefix = 203.0.113.1/32 This mapping server advertisment generates 100 mappings, one of which maps 203.0.113.17/32 to index=17. ISIS SRGB on node A = [1000,1999] Incoming label=1017 The fact that FEC1 comes from a normal prefix sid advertisement and FEC2 is generated from a mapping server advertisement is not used as a tie-breaking parameter. Both FECs use dynamic SID assignment, are from the same MCC, have the same FEC type code-point=120. Their prefix lengths are the same as well. FEC2 wins based on lower numerical prefix value, since 203.0.113.17 is less than 203.0.113.117. ========= Example incoming label conflict for label=1018 on node A FEC1) ISIS IPv4 adjacency sid advertisement from node A with label=1018 corresponding to next-hop interface address=192.0.2.100, outgoing interface ID=5 Incoming label=1018 Node A allocates this adjacency SID dynamically, and it may differ across router reboots. FEC2) ISIS IPv6 adjacency sid advertisement from node A with label=1018 corresponding to 2001:DB8:2000::100/128, outgoing interface ID=6. Incoming label=1018 Node A allocates this adjacency SID dynamically, and it may differ across router reboots. Both FECs use dynamic SID assignment, are from the same MCC, and have the same FEC type code-point=130. FEC1 wins because IPv4 address family is preferred over IPv6. ========= Example incoming label conflict for label=1019 on node A FEC1) ISIS IPv4 adjacency sid advertisement from node A with label=1019 corresponding to next-hop interface address=192.0.2.220, outgoing interface ID=7 Incoming label=1019 Node A allocates this adjacency SID dynamically, and it may differ across router reboots. FEC2) ISIS IPv4 adjacency sid advertisement from node A with label=1019 corresponding to next-hop interface address=192.0.2.230, outgoing interface ID=8 Incoming label=1019 Node A allocates this adjacency SID dynamically, and it may differ across router reboots. Both FECs use dynamic SID assignment, are from the same MCC, and have the same FEC type code-point=130. Both FECs have to same address family. FEC1 wins based on having the lowest next-hop interface address. /* It is not clear how to construct an example that would result in using the outgoing interface ID as a tie-breaker. It would be useful to understand why this is and clarify it in the text. */ ========= Example incoming label conflict for label=1020 on node A FEC1) SR Policy advertisement from controller to node A Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2> Binding-SID label=1020 FEC2) SR Policy advertisement from controller to node A Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4> Binding-SID label=1020 The FECs match through the tie-breaks up to and including having the same FEC type code-point=140. FEC2 wins based on IPv4 address family being preferred over IPv6. ========= Example incoming label conflict for label=1021 on node A FEC1) SR Policy advertisement from controller to node A Endpoint address=192.0.2.70, color=100, SID-List=<S1, S2> Binding-SID label=1021 FEC2) SR Policy advertisement from controller to node A Endpoint address=192.0.2.71, color=100, SID-List=<S3, S4> Binding-SID label=1021 The FECs match through the tie-breaks up to and including having the same address family. FEC1 wins by having the lower numerical endpoint address value. ========= I'd like to propose the examples below to be included in the draft to help clarify section 2.6 (currently entitled "Outgoing Label Collision"). Examples of the Effect Incoming Label Collision on Outgoing Label Programming ==================================== Example of effect of incoming label collision for label=1022 on outgoing label programming on node A FEC1) ISIS prefix sid advertisement from node B for 203.0.113.122/32 with index=22 ISIS SRGB on node A = [1000,1999] Incoming label=1022 FEC2) ISIS prefix sid advertisement from node C for 203.0.113.222/32 with index=22 ISIS SRGB on node A = [1000,1999] Incoming label=1022 FEC1 wins based on lowest numerical prefix value. This means that node A installs a transit MPLS forwarding entry to SWAP incoming label=1022, with outgoing label N, and use outgoing interace I. N is determined by the index associated with FEC1 (index=22) and the SRGB advertised by the next-hop node on the shortest path to reach 203.0.113.122/32. Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for incoming prefix=203.0.113.122/32 pushing outgoing label N, and using outgoing interace I. The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry corresponding to FEC2 ( which would be for incoming prefix=203.0.113.222/32). ======== Example of effect of incoming label collision for label=1023 on outgoing label programming on node A FEC1) SR Policy advertisement from controller to node A Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2> Binding-SID label=1023 FEC2) SR Policy advertisement from controller to node A Endpoint address=192.0.2.81, color=100, SID-List=<S3, S4> Binding-SID label=1023 FEC1 wins by having the lower numerical endpoint address value. This means that node A installs a transit MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels and outgoing interface determined by the SID-List for FEC1. Node A will generally also install an ingress MPLS forwarding entry corresponding to FEC1 for incoming prefix=192.0.2.80/32 pushing outgoing labels and using the outgoing interface determined by the SID-List for FEC1. The rule in section 2.6 means that node A MUST NOT install an ingress MPLS forwarding entry corresponding to FEC2 ( which would be for incoming prefix=192.0.2.81/32). ======== General comment: section 2.6 title: existing: Outgoing Label Collision: proposed: Effect of Incoming Label Collision on Outgoing Label Programming : -------------------------------------- Thanks, Chris On Thu, May 24, 2018 at 12:14 PM, <bruno.decraene@orange.com> wrote: > Hello Working Group, > > > > This email starts a Working Group Last Call on draft-ietf-spring-segment-routing-mpls-13 [1] which is considered mature and ready for a final working group review. > > > > Please read this document if you haven't read the most recent version yet, and send your comments to the list, no later than *June 08*. > > > > As a reminder, this document had already passed a WGLC more than a year ago on version -06 [2], had been sent to the AD but then returned to the WG. > > Since then, the document has significantly changed, so please read it again. In particular, it now includes the resolution in case of incoming label collision. Hence it killed draft-ietf-spring-conflict-resolution. > > > > Both co-chairs co-author this document, hence: > > - Shraddha has agreed to be the document shepherd.. Thank you Shraddha. > > - Martin, our AD, has agreed to evaluate the WG consensus. > > > > Thank you, > > Bruno, Rob > > > > [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-13 > > [2] https://mailarchive.ietf.org/arch/msg/spring/STiYsQJWuVXA1C9hK4BiUnyMu7Y > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > >
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Adrian Farrel
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… 徐小虎(义先)
- Re: [spring] WG Last Call for draft-ietf-spring-s… Chris Bowers
- Re: [spring] WG Last Call for draft-ietf-spring-s… Przemyslaw Krol
- Re: [spring] WG Last Call for draft-ietf-spring-s… Przemyslaw Krol
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- [spring] WG Last Call for draft-ietf-spring-segme… bruno.decraene
- [spring] FW: WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Adrian Farrel
- Re: [spring] WG Last Call for draft-ietf-spring-s… Zafar Ali (zali)
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… Ahmed Bashandy
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… bruno.decraene
- Re: [spring] WG Last Call for draft-ietf-spring-s… Acee Lindem (acee)
- Re: [spring] WG Last Call for draft-ietf-spring-s… Chris Bowers