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

[Adrian Farrel <[e-mail]>]

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