Re: [Teas] LLDP snooping references for ACTN POI

Adrian Farrel <adrian@olddog.co.uk> Thu, 23 September 2021 16:04 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 114BA3A105A for <teas@ietfa.amsl.com>; Thu, 23 Sep 2021 09:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.894
X-Spam-Level:
X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAY_BE_FORGED=1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IfRpTnZJbjNi for <teas@ietfa.amsl.com>; Thu, 23 Sep 2021 09:04:25 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 19DA43A0A27 for <teas@ietf.org>; Thu, 23 Sep 2021 09:04:24 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 18NG47jB028918; Thu, 23 Sep 2021 17:04:07 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6906E4604B; Thu, 23 Sep 2021 17:04:07 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 523D24604F; Thu, 23 Sep 2021 17:04:07 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Thu, 23 Sep 2021 17:04:07 +0100 (BST)
Received: from LAPTOPK7AS653V (84.93.166.80.plusnet.pte-ag1.dyn.plus.net [84.93.166.80] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 18NG45IO005465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Sep 2021 17:04:06 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Scharf, Michael'" <Michael.Scharf@hs-esslingen.de>, 'Italo Busi' <Italo.Busi@huawei.com>, 'TEAS WG' <teas@ietf.org>
References: <254416234d704ad8bc0c3dc04abfad8e@huawei.com> <c962fe67db2e49f4b0096d4aad107af5@hs-esslingen.de>
In-Reply-To: <c962fe67db2e49f4b0096d4aad107af5@hs-esslingen.de>
Date: Thu, 23 Sep 2021 17:04:05 +0100
Organization: Old Dog Consulting
Message-ID: <010201d7b094$a317bfd0$e9473f70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01D7B09D.04DCEB20"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHDdAmScL3DSdvsb1nurUEOb7wa1QHk+KVSq8sV17A=
Content-Language: en-gb
X-Originating-IP: 84.93.166.80
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26426.001
X-TM-AS-Result: No--12.544-10.0-31-10
X-imss-scan-details: No--12.544-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26426.001
X-TMASE-Result: 10--12.543700-10.000000
X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbGgws6g0ewz2Msovp/h9OdE/gf7afIrQU6f8 ywj+IcaD5RIt/Bw/RjEVPgmpV3FgOkHGTQqAQaePEYHPPOKNS1UO9z+P2gwiBev+IWu9WP63REq 3u7TSlySh2o6NHzaVRI0/78e6y2upgagLLkxQ06TB5xi0VO7ouB+BIUePsyaQV7MQTbTl02/R83 d8gpmjD6bF/OIYMbaaY3R5s6obsJZSN5j/GgtDwVyuZHgmvm5oyiKgKtIyB4pilpHN7xKf9WJBW 1hFlEpiIoleh/k/Ialiul05CU8oezWg20/TdHCGcN+LFb07lxgZskwWqoib3KSn04A2kgkowSOg WCbsQUp1ZO9slaw5KUI9gXSBGMBFgqwL3a6GRCZiHXzsQd3ao/moZ6x4ZgCUsNBH46aqkw6h9iU bZL0B//VVwoXXRsKklbLUtB5NIWOrFF7xI4BLlZJrW03DacWEDyGPIvVxZnCFZ8seZFqLXTOFuT sPaz4Hzkovv0N3yYDflgIsjwKBIWJQK9wIJ221jWe5HOFKvuPJbE9r9HBJT1TtozDM/L4UUUVTX 6QzIH3xPHpt+GVuZzQe4wVeVQ2DIWERHkBDPUmOtWfhyZ77DovCfM9n8BmndDwP5ItpCOzesTw6 jtmPrkkk6yagWKEsr/EwLya77le0CeKFBeer6FICmG2RRehovO61PPXizylFdhD9u4+PBMTr/G2 4o7RrhWQmZZ+uR46qKXbpBKHp1VKTeVVwHCqXNmg1ckxsf6cSwak5eNXy+woDY6gYCVOTP0pcrF O+EMNVngNu1PoOXSMOiq+nK4FMYU0rw2R2nKaeAiCmPx4NwGgVPcrOkeoT6uoJcQY0vp+EFYiZR sDydSiR0s6CJiwH+Th5+DqhaJohY5x21XFakcTBkRv5k2XUNdsMAySVA7K9JXQL8nQUras+mn6v ysEfJ2bwMbUBgU1UVVnBtltL+lgpWCbva+Mm
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/pNjweq0AsbxipL7_KjrJ0IAxeU0>
Subject: Re: [Teas] LLDP snooping references for ACTN POI
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: Thu, 23 Sep 2021 16:04:30 -0000

Hi all,

 

>From where I look at this, protocol snooping is just snooping on a protocol  ;-)

 

That is, the protocol is specified and we know what is in various fields. Snooping is just looking at the packets (praying that there is no encryption) and extracting useful information.

 

I think that documenting that an implementation can snoop on a protocol and can draw specific information from what it sees, is OK for an Informational RFC or for some advisory text in a Standards Track RFC, but I would think it odd to mandate it in any RFC.

 

Looking at the links that people have conveniently posted in the github Italo pointed to, it seems that there are two differences between the various vendors:

*	Different ways to configure LLDP snooping
*	Some variation in what information is gathered

 

But so what?

 

I think what your work needs to do is:

*	Work out what information *could* be gathered by LLDP snooping (that is useful for this document)
*	List this information in the document and say that an implementation MAY gather the information through LLDP snooping, but also say that it MAY be gathered through other means such as configuration.

 

I wouldn’t include references to vendor implementations because:

*	It is hard to keep them up-to-date once the RFC is published
*	It creates the impression of favouring certain vendors
*	It’s not particularly interesting :-)

 

Best,

Adrian

 

From: Teas <teas-bounces@ietf.org> On Behalf Of Scharf, Michael
Sent: 19 September 2021 10:45
To: Italo Busi <Italo.Busi@huawei.com>; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] LLDP snooping references for ACTN POI

 

For what it is worth: Three years ago, when I was responsible for LLDP snooping running code, I would have argued that a mechanism that apparently most vendors implement could nicely be described in a short informational RFC. LLDP snooping may not require new standardization, but there could e.g. be operational aspects for which a description could be useful.

 

If an informational RFC is not a realistic option, and no other vendor-neutral reference elsewhere exists, I’d be perfectly fine with references to the documentation of running code.

 

My 2 cents

 

Michael

 

 

 

From: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > On Behalf Of Italo Busi
Sent: Thursday, September 16, 2021 11:28 AM
To: TEAS WG <teas@ietf.org <mailto:teas@ietf.org> >
Subject: [Teas] LLDP snooping references for ACTN POI

 

Dear TEAS WG,

 

In draft-ietf-teas-actn-poi-applicability, LLDP snooping is mentioned as the preferred method to discover the adjacency between an IP router port and an ROAD edge port

 

The issue we are facing is that LLDP snooping is not described in any standard document but only in vendors’ documentations so we are not sure which informative reference we should provide in the draft for LLDP snooping

 

For more information see: https://github.com/FabioPeruzzini/actn-poi/issues/39

 

Do you know if a similar issue been faced before and, if so, how it has been addressed?

 

Would be ok to add informative references to vendors’ documentation?

 

Thanks, Italo (on behalf of co-authors and contributors)