Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
Adrian Farrel <adrian@olddog.co.uk> Mon, 28 February 2022 13:11 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512163A11D1; Mon, 28 Feb 2022 05:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1dXUYpoP6VN; Mon, 28 Feb 2022 05:11:33 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 11DF93A11CC; Mon, 28 Feb 2022 05:11:31 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21SDBSdY025291; Mon, 28 Feb 2022 13:11:28 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 273394604B; Mon, 28 Feb 2022 13:11:28 +0000 (GMT)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 06D5F46048; Mon, 28 Feb 2022 13:11:28 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS; Mon, 28 Feb 2022 13:11:27 +0000 (GMT)
Received: from LAPTOPK7AS653V ([148.252.133.209]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21SDBPPQ008943 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Feb 2022 13:11:27 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Lou Berger' <lberger@labn.net>, 'TEAS WG' <teas@ietf.org>
Cc: 'TEAS WG Chairs' <teas-chairs@ietf.org>, draft-bestbar-teas-ns-packet@ietf.org
References: <54263b17-4c97-8fcc-672c-146bed709b01@labn.net>
In-Reply-To: <54263b17-4c97-8fcc-672c-146bed709b01@labn.net>
Date: Mon, 28 Feb 2022 13:11:26 -0000
Organization: Old Dog Consulting
Message-ID: <064c01d82ca4$b23ed2f0$16bc78d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMSGMz8tyATXibH8mjnZXzf8CwUiao1FvlA
Content-Language: en-gb
X-Originating-IP: 148.252.133.209
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26742.007
X-TM-AS-Result: No--23.438-10.0-31-10
X-imss-scan-details: No--23.438-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26742.007
X-TMASE-Result: 10--23.437600-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbAzrPeIO/OIHmdrHMkUHHq8vfU/riSJXkXw6 H06bMgivumrocKW8orzcL6ACd2BGu8QTSPZE5H8g3nHtGkYl/Vp2ZYwNBqM6Iq56qUPGHxOhxMW +avqi6BquX8VumytIwkoLnrkl76CSKSbk9F7p9lbs3oPzM67VUZ+Z30eyNnRTNWBYotSYi+Tm19 rPMTwlY+sgt8JM77ebWo0SBooXS7TApTjLoiwjs0EOfoWOrvuOohrMq0nEhQciKqWY7QWAe6oHY SP2RcO0TQPMqkJM2T5RN4Birr9aknCTnAUR1pg5Yy6AtAy7YZfBPS/caXT3KD0VIALmCAEK+z9I eqWX7nfG79N75jg0CGA5vaEovDoP/1ormJWZ6Odo/qQE0v7mgzoSfZud5+Gga7JqOUUsotVPXOS +13nUuJo6GxI9r75nXTIePh48SgCHc6jpihSt1hd8ENHLtW0zALR/3svM0afRjBmBWsa9RGzTRl DGU3Pzb54sKlflk5PRVQW+FyfbMf5vmMlVb7wY6QScU5DdwdhWNh52V409tRKDqxulDiPJilvAb 18i4hPNiMd5aK+osiMi0zqEQpS7lrW6ecX6qSE4TxAlrwo4DzWBEYnpSn2FcJquQxzIpMCstoQv CgKRi7KMsYVtAmr0loKLbso+BGhl2TRC4OH7wbrbxxduc6FPvDRdfMz1as0l4DwEg5z3H6yRDZp BnTnX/D1sIvHJIgPMQN2xWFtdUtmwYg12mTn00e7jfBjhB8ccDnAff/bXEUYx760ONDcWHhox3S VYzz49OOHzBJuqXeDCsgoY8qMl9c0SSBk6D86eAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqtlExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/JI2-l8a5M0U3XL7u5YaVKWzQOeg>
Subject: Re: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 13:11:39 -0000
Hi Lou, all, I agree that the working group should have a document on this topic. While I see very many confusions, errors, and open questions, I believe that the authors could be persuaded to work on and fix these problems after adoption. However, given how much work is needed and how much the document will change, it may be pragmatic to produce a new version first and then see whether that has stabilised. There is one thing I think must be fixed as part of adoption: the references to draft-bestbar-teas-yang-slice-policy and draft-kompella- mpls-mspl4fa. These are presented as normative references and there is an implication that adopting this document would somehow give credence to those two documents. Fortunately, the references to draft-bestbar- teas-yang-slice-policy are clearly not normative, and are also not particularly relevant so they could be removed completely. Further, since the document purports to be technology-agnostic it would make sense not to make reference to the still-contentious draft-kompella- mpls-mspl4fa: if the authors want to, they could write a separate document called "Applicability of MSPL4FA for carrying the GIS". [See later note for why it is called the GIS.] The comments below are a mixture of concerns and editorial. They give a flavour of what is wrong with the draft. They do not comprise a full and detailed review. One other top level point: what a lot of IPR. Thanks to everyone for ensuring a timely disclosure, but ouch! With so much IPR, it makes me wonder whether the WG should look for a different approach that is not encumbered. Best, Adrian === It is quite worrying that this document attempts by design or accident to modify the architecture described in draft-ietf-teas-ietf-network- slices. In particular, compare draft-ietf-teas-ietf-network-slices figure 5 with figure 1 in this document. But there are plenty of other examples. --- I am puzzled that this document makes no reference to draft-ietf-teas- enhanced-vpn. That, too, is work that explains how to deliver a network slice over an IP/MPLS network. And since it is already a working group draft, one might expect this document to show how it fits in alongside VPN+. (I fully accept that there may be space for both approaches, but it is peculiar to make no attempt, and I expect the newcomer - this document - to be the one that shows the coexistence.) --- Please throw out the Abstract and replace it with something coherent. I have read and re-read the current text and can find nothing else useful to say about it! --- The document appears confused about the difference between a network slice service and a logical network. This is important. What is offered to the customer is a service and not a network or logical network. The service is a connectivity matrix with a set of commitments. The logical network is how the service provider may decide to organise their resources to deliver the service: that is, the logical network is part of the solution model and not something that "network slicing provides." --- The Introduction says that the document provides a path control technology agnostic solution. Why then do we find Section 6 describing the different path control technologies and how they can be used? --- The definition of the Slice-Flow Aggregate is very lacking in clarity. It takes several readings of the document to discover that the only purpose of this construct is to allow path provisioning aggregation within the NRP. This might be a useful scaling aspect depending on the number of slices that it is expected that a network will need to support between any two edge nodes. That means that it could be a good idea. Or it could be a waste of time. It's hard to know from this document. In particular, a modest number of slices and a careful number of NRPs is likely to give rise to no need for the aggregate. Otherwise, you are just introducing an intermediary step such that: - slices can be grouped into slice aggregates - groups of slice aggregates can be grouped/mapped onto NRPs? I feel there is also something missing in defining which slices can be grouped into aggregates. --- The Introduction concludes by saying... This document covers different modes of NRPs and discusses how each mode can ensure proper placement of Slice-Flow Aggregate paths and respective treatment of Slice-Flow Aggregate traffic. ...What is an NRP mode? What is a Slice-Flow Aggregate path? (Yes, I can look ahead into the document to find out, but then what is the point of an Introduction?) --- Why does this document feel the need to redefine the Network Resource Partition? --- While it is fine to observe that DiffServ can be used alongside slice (flow aggregate) identification, there are a couple of chunks of text that describe how DiffServ works and that, while they are very informative, are entirely irrelevant to the document and somewhat confusing for the reader. --- a Slice-Flow Aggregate comprises of one or more IETF network slice traffic streams This is ambiguous as a network slice may comprise multiple traffic streams, and we are talking about multiple slices. --- What are "NRP Policy selection criteria"? --- What's an "NRP domain"? --- 1.2 FASL: Flow Aggregate Selector Label as described in Section 5.1.1 I don't find any mention of the FASL until 5.2.3 -- Is NRP a Network Resource Partition, or a Network Resource Partition Policy? Section 1.1 seems unsure. --- It is no surprise to me that Figure 1 (which, incidentally, I drew for the authors as part of converging on figure 5 of draft-ietf-teas-ietf- network-slices) doesn't include the NRP. Perhaps a document that is claiming to be aligned with draft-ietf-teas-ietf-network-slices should make some attempt? Further, 3.4 is titled "Path Placement over NRP Topology" but doesn't actually mention the NRP topology preferring to talk about placement of paths over the Policy Filtered Topology (that draft-ietf-teas-ietf-network-slices calls the Filter Topology). --- 3.1 In what way do "resources ... meet specific SLOs"? Perhaps "can be used such that specific SLOs have a good chance of being met?" --- 3.2 The customer requests an IETF Network Slice Service specifying the CE-AC-PE points of attachment, the connectivity matrix, and the SLOs/ SLEs as described in [I-D.ietf-teas-ietf-network-slices]. These capabilities are always provided based on a Service Level Agreement (SLA) between the network slice costumer and the provider. These are not "capabilities". The SLOs/SLEs *are* the SLA. --- Why is 3.5 supposedly about NRP Policies when the text describes policies for handling slice aggregates? Is it because there is no difference between a slice aggregate and an NRP? --- Reading 3.7, and to be clear, you don't intend your mechanism to be available for CE-terminated slice services? --- The use of "MAY" in 3.7 implies that you don't expect it to be normal that the node at the edge of the slice (in your case, the PE) will mark traffic to allow the network to determine to which slice, aggregate, or NRP the packet belongs. That seems to be in contradiction with most of the rest of the document. --- 3.8 seems to have forgotten about the NRP. --- 4.1 has another paragraph describing DiffServ. Very interesting, but not relevant to this document. --- 4.1 has In this case, a Flow Aggregate Selector (FAS) MUST be carried in each packet to identify the Slice- Flow Aggregate that it belongs to. The ingress node of an NRP domain MAY also add an FAS to each Slice- Flow Aggregate packet. If the ingress node of the (undefined) NRP domain does not add the FAS, how does it get into the packet? Presumably the nodes outside the domain have no idea what an FAS is (by definition of the NRP domain). So I think you'll find that the ingress to the domain must add the FAS. In any case, why "also"? What else are they adding? --- 4.1 The transit nodes within an NRP domain MAY use the FAS to associate packets with a Slice-Flow Aggregate and to determine the Network Resource Partition Per Hop Behavior (NRP-PHB) that is applied to the packet (refer to Section 5.1.3 for further details). So you're saying that normally the transit nodes will not use the FAS for this purpose or at all? --- 4.1 The CS MAY be used to apply a Diffserv PHB on to the packet to allow differentiation of traffic treatment within the same Slice-Flow Aggregate. I think you're saying "DiffServ may be used to further qualify the PHB within the traffic flows belonging to a slice flow aggregate." --- 4.1 When data plane only NRP mode is used, routers may rely on a network state independent view of the topology to determine the best paths. You have switched to lower case "may". In either case, what would the router do in other cases? --- 4.1 The FAS field carried in each packet determines the specific NRP-PHB treatment along the selected path. You have already said this. --- 4.1 For example, the Segment-Routing Flexible Algorithm [I-D.ietf-lsr-flex-algo] may be deployed in a network to steer packets on the IGP computed lowest cumulative delay path. An NRP Policy may be used to allow links along the least latency path to share its data plane resources amongst multiple Slice-Flow Aggregates. In this case, the packets that are steered on a specific NRP carry the FAS that enables routers (along with the Diffserv CS) to determine the NRP-PHB to enforce on the Slice-Flow Aggregate traffic streams. 1. "This document provides a path control technology agnostic solution" So why the need to reference draft-ietf-lsr-flex-algo? 2. I feel fairly sure that this paragraph is intended to carry some useful meaning, but it eludes me. --- 4.2 To perform NRP state aware Traffic Engineering (NRP-TE), the resource reservation on each link needs to be NRP aware. Do you mean "on" or "for"? There's a substantial difference in how that is implemented. --- 4.2 The same physical link may be member of multiple slice policies that instantiate different NRPs. What is a slice policy? --- 4.3 So you believe that, in the case of oversubscription, you are actually achieving isolation? Or is it possible that there will be an out-queue of oversubscription traffic that will impede the flow of traffic from another slice? --- 5. The word "intent" is very cool, but it is wrong in this context. The slice customer does not express an intent, but a set of requirements. --- 5.1.1 Why "Global Identifier FAS (GIS)"? --- 5.1.1 A router MUST be able to identify a packet belonging to a Slice-Flow Aggregate before it can apply the associated dataplane forwarding treatment or NRP-PHB. One or more fields within the packet MAY be used as an FAS to do this. So you are saying that the FAS provides the NRP-ID? Or that the NRP policy includes a list of applicable FAS values? --- The text on the Global Identified Based Selector in 5.1.1 crosses the line between general explanatory text and a detailed solution. Careful that you technology agnostic document doesn't end up trying to persuade us all to adopt one specific solution. In particular, the reference to draft-kompella-mpls-mspl4fa is highly premature --- 5.1.1 A detailed review of NRP scale considerations is presented in [I-D.dong-teas-nrp-scalability]. What you say is true. However, I am far from convinced that that document means the same thing as you do when it says "NRP". That document does not talk about "slice aggregates". I think you are still lacking a lot of clarity about the difference between a slice aggregate and an NRP. --- 5.1.2 Here (and in the other places where you have similar text about resource sharing) you only talk about sharing resources between NRPs (or slice aggregates, as it may be). You don't talk about sharing those resources with non-slice traffic, but presumably you can. In fact, this section highlights the confusion between slice aggregate and NRP. You essentially have a set of slice aggregates within an NRP that share the resources of the NRP allowing for oversubscription etc. And you also have NRPs sharing resources or the network. It's all perfectly functional, but seems to have one too many layers of abstraction. --- I think 5.1.2 is predicated on resource reservation on the nodes. That is, oversubscription under the control of central accounting management (such as might be performed for SR-TE) cannot be achieved without risking the SLOs. Thus, you are advocating for putting the state in the network (which is fine by me), and this appears to be per slice aggregate flow state. --- 5.1.3 is off into DiffServ description again. You can probably cut this section down to two paragraphs (2 and 3) and one line saying "you can also use DiffServ as a subcategory of the NRP-PHB. --- 5.1.3 has The Slice-Flow Aggregate traffic may be identified at NRP ingress boundary nodes by carrying a FAS to allow routers to apply a specific forwarding treatment that guarantee the SLA(s). There is some passive voice here that makes it unclear whether you expect the packets to already include the FAS when they arrive at the domain. Additionally, the use of "may" is vague. --- 5.1.4 reads like the NRP Topology is the same as the Policy Filter Topology (or Filter Topology as it is called in draft-ietf-teas-ietf- network-slices. -- 5.2 A network slice originates at the edge nodes of a network slice provider. It is not helpful to contradict draft-ietf-teas-ietf-network-slices. --- 5.2 The network provider is responsible for ensuring that adequate network resources are provisioned and/or reserved to support the SLAs offered by the network end-to-end. "end-to-end" is a big ask especially given that the previous text is clear that the slice is edge-to-edge. --- 5.2.1 is either contradicting draft-ietf-teas-ietf-network-slices or specifically limiting the whole document to a subset of the possible deployment models. It's OK for the document to constrain itself to a subset (although I recall it was the network operators who were keen to extend slices to include the ACs), but it needs to make this very clear in the Abstract, Introduction, and probably title. --- 5.2.2 and MAY be able to That's a lower case "may" --- 5.2.2 be able to identify the packets belonging to a specific Slice-Flow Aggregate by inspecting the FAS field carried inside each packet, or by inspecting other fields within the packet that may identify the traffic streams that belong to a specific Slice-Flow Aggregate. For example, when data plane NRP mode is applied, interior nodes can use the FAS carried within the packet to apply the corresponding NRP-PHB forwarding behavior. I expected the example to be an example of using other fields to identify the traffic streams (because, obviously, the FAS is an example of using the FAS). What other fields have you in mind that can identify the slice flow aggregate (and how does that work if the traffic is encrypted)? --- 5.2.3 has a lot of words to say "Tunnel across areas of the network that are not NRP capable." On the other hand, nothing is said about how an NRP-capable node knows that its neighbour is not NRP capable, and where the next on-path NRP- capable node is. --- 6.1 The path selection in the network can be network state dependent, or network state independent as described in Section 5.1 of [I-D.ietf-teas-rfc3272bis]. You probably mean section 4.1, but you have possibly misunderstood that section which is describing how TE can adapt according to network state. You appear to be mixing TE with non-TE in your text and it is, perhaps, surprising that you think that "normal" SPF routing is not state dependent. I think you are actually describing the difference between TE and non-TE. --- 6.1 To enable TE path placement, the link state is advertised with current reservations Really? Like a list of which reservations have been made on each link? --- 6.1 When the network resource reservations are maintained for NRPs, the link state can carry per NRP state (e.g., reservable bandwidth). This allows path computation to take into account the specific network resources available for an NRP. In this case, we refer to the process of path placement and path provisioning as NRP aware TE (NRP-TE). I think you are proposing that the IGP distributes information of per-NRP resource reservation and availability per link. Do you think this scales? --- 6.2.2 is missing a statement about how resource reservation works in this type of network. --- 7. Routing protocols may need to be extended to carry additional per NRP link state. Well, do they or don't they? Per my comment on 6.1, it looks like you are saying that this extension is needed. --- 7. Need a reference for gRPC. --- 7. The NRP Policy YANG data model is outside the scope of this document, and is defined in [I-D.bestbar-teas-yang-slice-policy]. :-) It's out of scope, but let's talk about it anyway. --- Section 9 is a long way short of covering all of the bases. Three immediate things jump out: - Security is an SLE. A Filter Topology may be constructed using only secure links (e.g., links that use MACsec) resulting in the ability to provide a secure slice. - An attacker that modifies the FAS may be able to achieve far more subtle attacks than one that modifies the forwarding label or destination address. How is this protected against? - The visibility of the FAS within the network is an identifier of the traffic, and to some extent the customer. This allows someone doing surveillance to learn about customer traffic use (privacy) and to attack specific customer traffic (security). What are the mitigations? --- 10. Interesting that you thank one of the authors for reviewing the document :-) --- 10. Thanks to the authors for acknowledging me for the "detailed discussions that led to Section 3" of this document. On the other hand, no thanks for failing to acknowledge the material I wrote and that has been included in this document. This is poor behaviour that should be an embarrassment to all with their names on the front page. It really makes one think about who to have conversations with and who to try to help. --- On the subject of the front page: why is a document being put forward for adoption with 12 names on the front page? --- Is draft-ietf-teas-ietf-network-slices really not a normative reference? -----Original Message----- From: Teas <teas-bounces@ietf.org> On Behalf Of Lou Berger Sent: 18 February 2022 13:28 To: TEAS WG <teas@ietf.org> Cc: TEAS WG Chairs <teas-chairs@ietf.org>; draft-bestbar-teas-ns-packet@ietf.org Subject: [Teas] WG adoption poll: draft-bestbar-teas-ns-packet-08 Hello, This email begins a 2-week adoption poll for: https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/ Please note that IPR has been disclosed on this document: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bestbar-teas- ns-packet Please voice your support or objections to adoption on the list by the end of the day (any time zone) March 4. Thank you, Lou (as Co-chair) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas
- [Teas] WG adoption poll: draft-bestbar-teas-ns-pa… Lou Berger
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Chandrasekar Ramachandran
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Srihari Sangli
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Colby Barth
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… peng.shaofu
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Daniele Ceccarelli
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wen, Bin
- Re: [Teas] [E] WG adoption poll: draft-bestbar-te… Jalil, Luay
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… chen.ran
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… chen.ran
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Gyan Mishra
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] [**EXTERNAL**] Re: WG adoption poll: d… Rokui, Reza
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Joel M. Halpern
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Raveendra Torvi
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Joel M. Halpern
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Ogaki, Kenichi
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Ogaki, Kenichi
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Huzhibo
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Xufeng Liu
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Loa Andersson
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Adrian Farrel
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Adrian Farrel
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Abhishek Deshmukh
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Dongjie (Jimmy)
- [Teas] Fwd: WG adoption poll: draft-bestbar-teas-… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Vishnu Pavan Beeram
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Dhruv Dhody
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Daniele Ceccarelli
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Daniele Ceccarelli
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Adrian Farrel
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Lou Berger
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Lou Berger
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… mohamed.boucadair
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Dhruv Dhody
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Wubo (lana)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Tarek Saad
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Dongjie (Jimmy)
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Lou Berger
- Re: [Teas] WG adoption poll: draft-bestbar-teas-n… Gengxuesong (Geng Xuesong)