Dear Opsawg colleagues,
During the last months and with the help of our regular LxNM
calls we have been working in solving the open issues in github. Let me remind
that the complete list of issues is available at
https://github.com/IETF-OPSAWG-WG/l3nm/issues .
The issues that have been closed since the last meeting can be
found with the query
https://github.com/IETF-OPSAWG-WG/l3nm/issues?q=is%3Aissue+closed%3A%3E2020-03-01+
Let me comment briefly what was discussed to close the issue
(more details in the link). If anyone has a concern, the issue can be
revisited. Please feel free to ask more details about any of them.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/10 Nits in text
and reference to BESS-L3VPN. The draft text has been fully reviewed and is
ready for submission. The reference to bess
https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/ was removed since
it is no longer an active document. (can change if the document is back to
life).
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/18 Review VPN
profiles. The profiles were reviewed and maintained. Note that as per issue
https://github.com/IETF-OPSAWG-WG/l3nm/issues/113 explained later a new
forwarding profile was added. All the profiles are added to the common module.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/20 We need to
indicate whether the RT and RDs are provided by the Network Operator / service
orchestrator or they are automatically assigned by the controller which has the
l3nm module. After a first proposal, the solution was not 100% OK for the
implementors. The issue was also raised by Roque in
https://github.com/IETF-OPSAWG-WG/l3nm/issues/114 Please check that issue for
the latest proposal (it is still open).
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/25 Delete
extranet VPNs container. The extranet VPNS information coming from L3SM is
needed to be analyzed by the Network operator/service orchestrator and create
the necessary import/export policies that will apply in L3SM. The container has
been removed from the yang model (it is present in L3SM).
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/32 Review Yang
for containers that can directly imported from L3SM. This is solved with the
new vpn common module, so avoiding directly importing containers from L3SM.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/36: BGP Session
under vpn_node (erez proposal) or under vpn_network_access After several
discussions it was agreed to keep it under vpn-network-access. In the
implementation level there the fulfillment entity need to go down to the device
and set the BGP per VRF on the device level. each BGP over vpn-network-access
reflected as a neighbor configuration on the BGP instance on the VRF. Dual
homing is done from different PEs - metric is treated in the customer side.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/39 Add Local-AS
under the BGP session. The request is to Include the Local-AS as an option to
announce a different AS to the CE. Fixed in
https://github.com/IETF-OPSAWG-WG/l3nm/commit/f987d5b4b7fcbebf10b59f114fa316a54ba877cd
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/41 In
vpn_target, make route_target a list of route_targets (meaning an and operation
between all route_targets) AND OR operations have been added
https://github.com/IETF-OPSAWG-WG/l3nm/commit/003fcabcd15429c097f7b66f2fb4eb342231c27c
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/45 Add RP PIM
Anycast under multicast configuration. Solved in
https://github.com/IETF-OPSAWG-WG/l3nm/pull/54 and
https://github.com/IETF-OPSAWG-WG/l3nm/pull/75 It is required to add the
following information to detail the Multicast service: Provider Tunnel:
RSVP-TE, mLDP, PMSI-Type: iPMSI sPMSI Threshold rt. Solved together with issue
https://github.com/IETF-OPSAWG-WG/l3nm/issues/47
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/53 Custom QoS.
We agreed on leaving just standard QoS profile and removing custom QoS.
https://github.com/IETF-OPSAWG-WG/l3nm/commit/3b74db5a029d44e1c51a87c61c9e7a67696fc392
Hence, the definition of the QoS is done outside the model.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/73 This was just
the text for the I-D.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/111 Fix issues
from Yang doctor review. All issues are dealt. 1) The module seems NMDA
compliant, so it should be mentioned in Introduction (or some other) section.
NMDA compliance text added to the draft text (the draft-04 is to be published
after solving the common module discussion). 2) the filename's revision part
does not match the latest revision date (2020-04-03) of the module. Fixed in
new version (to be published). 3) All the imported modules must have their
document (RFC) in the normative references section. The references have been
added (done together with the new vpn common module). 4) Since RFC 8277 is
referenced in the module, it should appear in the normative references section.
On this one, we don't think we need to cite it as normative as RFC8407 says the
following: If the reference statement identifies an informative reference that
identifies a separate document, a corresponding informative reference to that
document MAY appear in the Informative References section. 5) Additional
indentation (3 spaces on each line except the first one) in the module's
contact statement seems weird and unnecessary/unintentional (fixed). 6) The
whole groupings part need a cleanup and maybe some structural changes: A new
vpn common module has been proposed with the reusable groupings. Unnecessary
groupings not reused are removed.
https://github.com/IETF-OPSAWG-WG/l3nm/pull/122 ) 7) description of the
service-status grouping seems to be invalid. Description of the service-status
is updated (see issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/62 ). 8)
typedef protocol-type: Are you really sure that the list of the underlying
protocols is fixed forever in all its instances? Having it in the form of
identity would allow later augmenting of the list of possible values. Protocol
types changed to identity refs as per yang doctor suggestion (see common
module). 9) I'm afraid about the usability of appendix A. The status of the
implementations will tent to change quite intensively and having such
information in RFC does not make much sense to me: Regarding the usability of
appendix A, The status of the implementations, this is to be removed once the
document is RFC. With this all issues are closed. Note that as soon as the vpn
common discussion is closed, we will properly reply to yang doctor's review
with the previous comments
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/112 Fix issues
from Tom Petch review in Opsawg mailing list. All points were solved and the
references updated in issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/115
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/113 Routing
policy vs forwarding policy difference. On the global routing profiles, it
should be a difference between routing and forwarding policies. A forwarding
profile (which refers to the treatment of the packets received by the VPN at
the interface of the vpn-network-access) is added in
https://github.com/IETF-OPSAWG-WG/l3nm/pull/118
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/115 Add
reference and descriptions to identityrefs for protocol-type. They are added in
https://github.com/IETF-OPSAWG-WG/l3nm/pull/164
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/117 Routing
policy: just a name or a reference to leaf in a routing policy yang? The model
does not force any particular policy model to be implemented. Also, maintaining
leafrefs adds complexity to implementations. It was agreed to keep just a hook.
Before the last IETF we closed a bunch of issues summarized below:
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/59 This issue is
about how to model the filtering happening at vpn-network-access level, as part
of the qos profile. The way the match (of L3 and L4 packets) is changed from
the L3SM style to the more recent and generic RFC 8519: YANG Data Model for
Network Access Control Lists (ACLs). Hence, the model imports from RFC 8519.
Solved in pull https://github.com/IETF-OPSAWG-WG/l3nm/pull/88
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/61 A pointer to
L3SM service id is added, so the relation between a service created in the
service orchestrator with L3SM and in the network controller instantiated with
L3NM is maintained. The pointer is OPTIONAL. Solved with
https://github.com/IETF-OPSAWG-WG/l3nm/pull/60 (yang change) and explanation in
text in https://github.com/IETF-OPSAWG-WG/l3nm/pull/72
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/62 Overal
service status. A container with the service status was added See
https://github.com/IETF-OPSAWG-WG/l3nm/pull/58 . Note that the status related
groupings and types are now being revisited to be part of the common module.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/70 control which
notifications should be supported for the service. This important issue will be
managed in a separate document. See
https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-00.html
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/71 Consider
exposing a set of VPN-related network capabilities. These capabilities may be
used by the service layer as input to service order handling (or service
activation). Examples can be:Limit on max routes per customer: supported/not,
FIB/RIB limits, Max supported VRF instances, link capacity. Max BGP sessions,
Encryption capabilities. It is an important line of work, but for the moment we
keep it out of the draft and we plan to initiate a new line of work related to
exposing the capabilities.
- Issue https://github.com/IETF-OPSAWG-WG/l3nm/issues/76 The model
does not support the creation of vrf-import & export profiles. Solved with
https://github.com/IETF-OPSAWG-WG/l3nm/commit/16fa91d76f9ecccbb16aca7052783c2266574ebb
by adding vrf import and export policies within vpn-targets container to
expand routing profiles functionality. Note that we are just pointing to a
policy. The information inside the policy is out of scope of the model. This
can be done, for example, with the routing-policy yang models defined in IETF
(https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-15).
Best Regards,
Oscar on behalf of L3NM authors and contributors
________________________________
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede
contener información privilegiada o confidencial y es para uso exclusivo de la
persona o entidad de destino. Si no es usted. el destinatario indicado, queda
notificado de que la lectura, utilización, divulgación y/o copia sin
autorización puede estar prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente
por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential
information intended only for the use of the individual or entity named above.
If the reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this communication
is strictly prohibited. If you have received this transmission in error, do not
read it. Please immediately reply to the sender that you have received this
communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
