Open jbouqui153 opened 4 years ago
This is an open debate within IETF:
https://datatracker.ietf.org/doc/minutes-interim-2020-opsawg-01-202004070700/
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-ccamp-01?useMonospaceFont=true
https://datatracker.ietf.org/meeting/108/materials/minutes-108-ccamp-01.htm
See also: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/66
I would suggest to keep this issue open pending resolution of the on-going discussion within CCAMP, OPSAWG and TEAS WGs.
2021-09-14 ACTN POI Call (Slot 2)
@oscargdd : provide updates on the UNI topology discovery discussion
2021-11-23 ACTN POI Call (Slot 1)
While waiting for more information, we can identify this as a gap: https://github.com/FabioPeruzzini/actn-poi/pull/69/commits/d77fc80552377378c74dd5eeeb77cf566fa4090c
During the LLDP discussion, it has been pointed out that the packet PNC may not be aware about whether an external Ethernet link is an inter-domain link (toward another BR) or a cross-layer layer (toward a ROADM)
Does the P-PNC knows if an external link is an access link (toward a CE)?
Could LLDP protocol between CE and PE be used also to discover access links?
I am wondering whether a common solution (based on Ethernet TE topology) to discover access links, inter-domain links and cross-layer links would be beneficial
2021-11-30 ACTN POI Call (Slot 2)
The P-PNC does not necessarily know whether an inter-domain link is an access link (between a PE and a CE), an inter-domain IP link (between two BRs) or a cross-layer link (between an IP router and an optical NE). This information can be discovered by the MDSC.
2021-12-21 ACTN POI call (Slot 1)
Agreed to describe this issue as a gap as proposed in draft PR #69
See https://github.com/IETF-TEAS-WG/actn-poi/pull/115#discussion_r1487671518
ACTN POI bi-weekly call (November 19, 2024)
During IETF 121, Oscar volunteered to provide some text proposal.
See: https://github.com/IETF-TEAS-WG/actn-poi/issues/31#issuecomment-2488331308
It has been agreed to add the guidelines on using TE Topology and SAP Topology if the text proposal is available before the document is ready for WG LC. Otherwise, considering that the scope of this I-D is to identify gaps, the document will be submitted to WG LC just highlighting the gap and without providing any guidance on how to address it.
It is worth noting that there is a similar issue in the TE topology profile draft and the gap can be addressed in that document.
- [x] @italobusi aend a mail reminding Oscar to provide some text proposal to address the gap
See: https://mailarchive.ietf.org/arch/msg/teas/FKjX1Y6ueKNxIkfUtYdE00oM2z4/
In section 3.2.3 YANG data models at the packet MPI we mentioned [CLIENT-TOPO] (https://datatracker.ietf.org/doc/draft-zheng-ccamp-client-topo-yang/ ). We should discuss further as for L3NM/L2NM, the authors are considering a recent draft proposal [UNI-TOPO] (https://datatracker.ietf.org/doc/draft-ogondio-opsawg-uni-topology/) which augments RFC8345 with the service attachment point abstraction for L3 or L2 VPNs network services.