[Teas] Final open issue with draft-ietf-teas-te-service-mapping-yang

Adrian Farrel <adrian@olddog.co.uk> Wed, 15 September 2021 10:03 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 ECFC73A0C24; Wed, 15 Sep 2021 03:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_NONE=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 i5zEmft9-ZzQ; Wed, 15 Sep 2021 03:03:21 -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 A39743A0C29; Wed, 15 Sep 2021 03:03:19 -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 18FA3HnZ005023; Wed, 15 Sep 2021 11:03:17 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0DCA84604B; Wed, 15 Sep 2021 11:03:17 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0AE5E4604A; Wed, 15 Sep 2021 11:03:17 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 15 Sep 2021 11:03:16 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.2.143]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 18FA3F6b026824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Sep 2021 11:03:16 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'TEAS WG'" <teas@ietf.org>
Cc: <draft-ietf-teas-te-service-mapping-yang@ietf.org>
Date: Wed, 15 Sep 2021 11:03:14 +0100
Organization: Old Dog Consulting
Message-ID: <1c2501d7aa18$e74a6b30$b5df4190$@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: AdeqFSzxLYinV5deTvW2Dv9po0kLNA==
Content-Language: en-gb
X-Originating-IP: 84.93.2.143
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-26408.007
X-TM-AS-Result: No--6.325-10.0-31-10
X-imss-scan-details: No--6.325-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26408.007
X-TMASE-Result: 10--6.325200-10.000000
X-TMASE-MatchedRID: tIBWMHlNqVMOwAmmWH5kBOUKNN5hHcABIiTd2l7lf6G5K2LUGgeo9hGG gsUwTpwibnWYA5okJfVS8kbMHAldSSldXBfCiub0mvnKSb020hwqaLKskc2Hcj+B/tp8itBTXML onY0f9RCgLYNgRfgG3SpaLgySBsfcOK1YuUtHUz3ece0aRiX9WsqFE6gRdRObUoXFjv/N8aJmWP 0XV61CjUr2ezdf24XmOEwF3UrxJfTTONCKXUvczjIjK23O9D334NNiN6MhlPCcDEEnLjX47pim4 buSmgpH5ntEnzMJPFETnoPZ/4PnOmE12GZvI1jlc+QhWKJM04OzIgf/2urnFseQfu6iwSfsTciQ mn84dep3AArVYKdueAtSywBC9hG2XrmIPORRwl6iDx9PivNo7gKflB9+9kWVNdIRQsBMxLm6o5p OE3X0plF1nDOfJQupmyswMyj9hRtMGPWd3bHvfrzgL/eLACDETJDl9FKHbrm5RTcaZKGriYLGtq R3Wrkrg3n8lw8GhrtsJt6HHrEkzIEA1AgGhA6pKpEngz2rs6/KIqAq0jIHiqr4vEVTsLe2VoIgK GEvCo9nHQJ2jUDp75GTpe1iiCJq0KkIUsNMdlTdB/CxWTRRu4as+d5/8j56tplATGm2uLPkJvIB zsAU5fJ+wSpauV4J4oj6JL1wyxU35c5BnKCu9g==
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/31VQJwe1hKrWGlTt7WGbqNa5frs>
Subject: [Teas] Final open issue with draft-ietf-teas-te-service-mapping-yang
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: Wed, 15 Sep 2021 10:03:24 -0000

Hi,

Appendix B shows two open issues. 

I think a previous thread disposed of the second one: calendaring. I didn't
see any disagreement, and saw some support for my proposal.

The first issue in appendix B is about how to indicate what traffic should
be mapped to a specific path. I think this is a fundamental usage
requirement, but I have some observations.

1. We have had the concept of TE LSPs for a few years, yet somehow we have
survived without a standardised way of stating what traffic the LSPs should
carry. Even the MIBs for MPLS-TE did not discuss this. That, of itself, is
not a good reason not to specify a description of traffic-to-path mapping,
but it may be an indication that there is less urgency.

2. A similar question occurred to the PCE working group: when a PCE tells a
PCC what LSP to set up, how does the PCC know what traffic to put on the
LSP? This led to draft-ietf-pce-pcep-flowspec which is in the RFC Editor
Queue. That document includes a way to describe traffic flows in PCEP.

3. The question also arises in the context of SFC. Here, traffic needs to be
"classified" onto a service function chain/path so that it receives the
correct treatment in the network.

4. From a YANG perspective, the question could be made very generic. "How
does the management station notify a network node how to classify traffic
and what to do with it?"

The principle of generalisation has run through a lot of the work in TEAS.
The intention has, I think, been to look for wide applicability for our work
rather than restricting it to niche uses. I think we would do well to
consider that principle in this case to. That is, we should consider working
on a YANG model that describes traffic and indicates what should be done
with it.

- For the description of traffic, I think we can learn a lot from the IDR
and PCE working groups, but also from RFC 8519 which provides a YANG model
for ACL.
- For the associated "action" I suspect that we only need to "point" to a
YANG object (such as an LSP, or path, or SFC, or ...)

So my proposal is that those interested in this question should start work
on a separate model, and that this issue should also be removed from
appendix B. Perhaps a few words would need to be added to the document to
indicate that this problem has to be solved "by local configuration or
through a YANG model developed in the future."

At that point, I wonder whether there is anything else that needs to be done
with this document.

Cheers,
Adrian