Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-03.txt
Hi Joe, Having the WGLC right after IETF#111 is a good plan. Thanks. Looking forward to receive your comments. Cheers, Med > -Message d'origine- > De : Joe Clarke (jclarke) [mailto:jcla...@cisco.com] > Envoyé : samedi 10 juillet 2021 20:53 > À : BOUCADAIR Mohamed INNOV/NET ; > opsawg@ietf.org; opsawg-cha...@ietf.org > Cc : draft-ietf-opsawg-l...@ietf.org > Objet : Re: I-D Action: draft-ietf-opsawg-l2nm-03.txt > > I've been following your minutes updates, and I didn't think you'd > make this much progress so soon (with new issues being opened). > Very nice. > Thanks to the authors and contributors for continuing to iterate on > this work. > > We'd prefer to hold on LC until after 111 as we're already in that > gravity, and people have much to read and review. Additionally, > with this being the summer, an extended LC is likely warranted to > ensure people get a chance to read it. > > I've briefly looked through the diffs, but I'll try and get a more > thorough review in before our meeting myself. > > Joe > > On 7/9/21 06:34, mohamed.boucad...@orange.com wrote: > > Hi all, > > > > We are pleased to share this major revision of the L2NM. Some of > the main changes are: > > * Rewrite of Section 6 + restructure it to better reflect the > content and rationale of the L2NM design. > > * Clarify the relationship between some nodes: signaling types, > VPN types, etc. > > * Rather than defining L2 encap types and pw types as part of the > L2MN, we defined two IANA-maintained modules to echo existing > registries. > > * Many examples to illustrate the use of the module: LDP-signaled, > BGP used for both auto-discovery and signaling, mutli-homing, EVPN, > auto-assignment of ESI, redundancy, etc. > > > > Please use the diff to track all the changes: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-03. > > > > The full set of closed issues can be tracked at: > https://github.com/IETF-OPSAWG- > WG/lxnm/issues?q=is%3Aissue+is%3Aclosed+label%3AL2NM. Majors issues > were reported to the mailing list (Thanks, Samier). > > > > We don't have any pending issue (https://github.com/IETF-OPSAWG- > WG/lxnm/issues). > > > > We think that the document is ready for the WGLC. We defer to the > Chairs whether to launch it before or after the IETF meeting. > > > > Reviews and comments are welcome. > > > > Cheers, > > Med > > > >> -Message d'origine- > >> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la > part > >> de internet-dra...@ietf.org Envoyé : vendredi 9 juillet 2021 > 12:19 À > >> : i-d-annou...@ietf.org Cc : opsawg@ietf.org Objet : I-D Action: > >> draft-ietf-opsawg-l2nm-03.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet- > Drafts > >> directories. > >> This draft is a work item of the Operations and Management Area > >> Working Group WG of the IETF. > >> > >> Title : A Layer 2 VPN Network YANG Model > >> Authors : Samier Barguil > >> Oscar Gonzalez de Dios > >> Mohamed Boucadair > >> Luis Angel Munoz > >>Filename: draft-ietf-opsawg-l2nm-03.txt > >>Pages : 149 > >>Date: 2021-07-09 > >> > >> Abstract: > >>This document defines an L2VPN Network YANG Model (L2NM) that > can > >> be > >>used to manage the provisioning of Layer 2 Virtual Private > >> Network > >>(VPN) services within a network (e.g., service provider > network). > >>The L2NM complements the Layer 2 Service Model (L2SM) by > >> providing a > >>network-centric view of the service that is internal to a > service > >>providers. As such, the L2NM is meant to be used by a network > >>controller to derive the configuration information that will > be > >> sent > >>to relevant network devices. > >> > >>Also, the document defines the initial versions of two IANA- > >>maintained modules that defines a set of identities of BGP > Layer > >> 2 > >>encapsulation types and pseudowire types. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/ > >> > >> There is also an htmlized version available at: > >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-03 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-03 > >> > >> > > > > _ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > > Orange decline toute respon
Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations
Eliot Lear wrote:
> The key issue is that the new query and resolution has to get picked up
> by the network management system. So long as that happens, then life
> is good. This means that the resolver needs to be integrated with the
> MUD manager, but also that the IoT device should also be careful to
> observe caching semantics, particularly in the case of a connection
> failure.
I agree that having a MUD-aware caching resolver can solve the problem.
It might be practical in some places for the MUD-aware network management
system to control DHCP, and be able to tell the IoT devices what DNS server
to use.
I don't have a problem writing this kind of advice, but it's no longer advice
to the IoT device creator, but the Enterprise operator of the MUD system.
> Those failures will happen with or without MUD.
Please explain: how do we see inconsistent application of DNS based rules
without MUD?
>> My takeaway from all of this was that essentially... if
>> geofenced/CDNed DNS is not gonna for for IoT devices with MUD
>> files... then maybe the advice about working around them is WRONG.
>> Maybe the right advice is... DON'T DO THAT.
>>
>> {ME: Doctor! Doctor! It hurts when I use a geographic CDN! Doctor:
>> Don't do that.}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations
> Those failures will happen with or without MUD. Please explain: how do we see inconsistent application of DNS based rules without MUD? What I meant in context was that there could be NAT binding timeouts and the like, but there are systems out there that do keep context based on name resolution. Eliot OpenPGP_signature Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08
Hi,
This is my AD review of draft-ietf-opsawg-vpn-common-08.
Thank you for this document. Again, just minor comments/suggestions.
1.
In section 3. Description of the VPN Common YANG Module
"Encapsulation features such as" -> "Encapsulation features. Such as"
"Routing features such as" -> "Routing features. Such as"
2.
As a very minor comment. Where you have lists (i.e., encapsulation features,
routing features, service type) and particularly because they have references,
it may be slightly easier to read if the list was indented. Also does it make
sense for this list to just be examples, or are they actually normative lists
of service types that are supported?
E.g.,
'service-type': Used to identify the VPN service type.
Examples of supported service types are:
o L3VPN,
o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
o VPLS using Label Distribution Protocol (LDP) [RFC4762],
o Virtual Private Wire Service (VPWS) [RFC8214],
o BGP MPLS-Based Ethernet VPN [RFC7432],
o Ethernet VPN (EVPN) [RFC8365], and
o Provider Backbone Bridging Combined with Ethernet
VPN (PBB-EVPN) [RFC7623].
In the Yang Module:
3. OPSA => OPSAWG
Please can you check if this needs to be fixed for the L3NM YANG model as well.
4.
feature qinany {
description
"Indicates the support of the QinAny encapsulation.";
}
Is there a reference, or perhaps a more detailed description that you can use
here?
5.
Very minor:
feature ipv4, feature ipv6, is it worth adding references to the RFCs? I
appreciate that they are obvious, but since you have references for everything
else, it seems like it might be worth using adding them?
6.
feature rtg-ospf-sham-link {
description
"Indicates support of OSPF sham links.";
Does this mean that feature rtg-ospf excldues this support? This feature seems
very specific relative to the other features in this YANG module.
7.
As mentioned in the other document, would "feature carrierscarrier" be better
as "feature carriers-carrier"?
8.
"Indicates the support of" => "Indicates support for"
"Indicates support of" -> "Indicates support for"
9.
This model defines a lot of features, and I wasn't sure how helpful that will
really be in practice. Is the intention here for an SP to use features to
customize the model to their needs? I wonder if the heavy use of features
won't work so well if both L2VPN and L3VPN's are being modelled and support
different protocols/etc. Will having the common features act as a limitation?
E.g., an alternative might be to express the features in the L2NM and L3NM
models directly allowing them to enabled/disable different features.
10. Status leaves:
Would UP, DOWN, UNKNWON be better as Up, Down, Unknown?
Would "admin-enabled" be better than "admin-up" and "admin-disabled" be better
than "admin-down".
For all the non-base identities, I would suggest removing the "Identity for"
prefix in the descriptions. It is self-evident that the descriptions are for
identities, and the extra words probably would not help a GUI rendering of the
description strings.
11. For all the "service type" identities, I would suggest ending all the
descriptions with "service".
E.g.,
"L3VPN service.";
"Provider Backbone Bridging (PBB) EVPNs service.";
"Virtual Private LAN Service (VPLS).";
"Point-to-point Virtual Private Wire Service (VPWS).";
"Provider Backbone Bridging (PBB) EVPN service.";
"MPLS based EVPN service.";
"VXLAN based EVPN service.";
12.
For the signalling identity descriptions:
"Layer 2 VPNs using BGP signalling";
"Targeted LDP signalling.";
"L2TP signalling.";
13.
For the bgp-signalling identity, does it make sense for the description to be
specific to L2VPNs? Couldn't bgp-signalling also be used for L3VPNs?
14.
For the routing-protocol-type generic identities, would it make sense to add a
"-routing" suffic to them, e.g., "direct-routing", "any-routing"? Otherwise
some of the identity names look fairly generic, but perhaps that is okay.
15.
vpn-topology:
Is No P2P topology identity required?
16.
For identity qos-profile-direction:
Rather than "site-to-wan" and "wan-to-site" identity names, would it be
better to use "vpn" or "service" instead of wan. E.g., "site-to-vpn", or
"site-to-service"?
17.
identity enhanced-vpn
identity ietf-network-slice
Would it be helpful to add RFC or draft references for these identities? E.g.,
[I-D.ietf-teas-enhanced-vpn], or an IETF network slice service
[I-D.ietf-teas-ietf-network-slices]
18.
identity protocol-type {
description
"Base identity for Protocol Type.";
}
identity unknown {
base protocol-type;
description
"Not known protocol type.";
}
Is this identity required/useful? Wouldn't it be better to ju
Re: [OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08
Hi Rob,
Many thanks for the review. A candidate updated version can be seen at:
https://tinyurl.com/vpn-common-latest
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> Envoyé : lundi 12 juillet 2021 17:15
> À : draft-ietf-opsawg-vpn-common@ietf.org
> Cc : opsawg@ietf.org
> Objet : AD review of draft-ietf-opsawg-vpn-common-08
>
> Hi,
>
> This is my AD review of draft-ietf-opsawg-vpn-common-08.
>
> Thank you for this document. Again, just minor
> comments/suggestions.
>
>
>
> 1.
> In section 3. Description of the VPN Common YANG Module
> "Encapsulation features such as" -> "Encapsulation features. Such
> as"
> "Routing features such as" -> "Routing features. Such as"
>
[Med] Fixed.
> 2.
> As a very minor comment. Where you have lists (i.e., encapsulation
> features, routing features, service type) and particularly because
> they have references, it may be slightly easier to read if the list
> was indented. Also does it make sense for this list to just be
> examples, or are they actually normative lists of service types that
> are supported?
[Med] Sure. These are only examples. We cite them as we need to list include in
the main text any reference quoted in the module.
>
> E.g.,
>'service-type': Used to identify the VPN service type.
> Examples of supported service types are:
>
> o L3VPN,
>
> o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
>
> o VPLS using Label Distribution Protocol (LDP) [RFC4762],
>
> o Virtual Private Wire Service (VPWS) [RFC8214],
>
> o BGP MPLS-Based Ethernet VPN [RFC7432],
>
> o Ethernet VPN (EVPN) [RFC8365], and
>
> o Provider Backbone Bridging Combined with Ethernet
> VPN (PBB-EVPN) [RFC7623].
>
>
> In the Yang Module:
>
> 3. OPSA => OPSAWG
> Please can you check if this needs to be fixed for the L3NM YANG
> model as well.
[Med] Fixed.
>
> 4.
> feature qinany {
> description
> "Indicates the support of the QinAny encapsulation.";
> }
>
> Is there a reference, or perhaps a more detailed description that
> you can use here?
>
[Med] This was also a comment raised in the WGLC, but we don't have any
acceptable authoritative reference to cite for it.
> 5.
> Very minor:
> feature ipv4, feature ipv6, is it worth adding references to the
> RFCs? I appreciate that they are obvious, but since you have
> references for everything else, it seems like it might be worth
> using adding them?
[Med] OK
>
> 6.
> feature rtg-ospf-sham-link {
> description
> "Indicates support of OSPF sham links.";
>
> Does this mean that feature rtg-ospf excldues this support? This
> feature seems very specific relative to the other features in this
> YANG module.
[Med] Yes. We are barrowing this one for RFC8299, fyi.
>
> 7.
> As mentioned in the other document, would "feature carrierscarrier"
> be better as "feature carriers-carrier"?
[Med] No problem. Fixed.
>
> 8.
> "Indicates the support of" => "Indicates support for"
> "Indicates support of" -> "Indicates support for"
[Med] Fixed.
>
> 9.
> This model defines a lot of features, and I wasn't sure how helpful
> that will really be in practice. Is the intention here for an SP to
> use features to customize the model to their needs? I wonder if the
> heavy use of features won't work so well if both L2VPN and L3VPN's
> are being modelled and support different protocols/etc. Will having
> the common features act as a limitation? E.g., an alternative might
> be to express the features in the L2NM and L3NM models directly
> allowing them to enabled/disable different features.
[Med] The "common" set of features was initially included to rationalize the
LxSM and LxNM. I don't know if/and to what extent this would have limitations
when both L2xM and L3xM.
>
> 10. Status leaves:
> Would UP, DOWN, UNKNWON be better as Up, Down, Unknown?
[Med] Fixed.
> Would "admin-enabled" be better than "admin-up" and "admin-disabled"
> be better than "admin-down".
[Med] I prefer the OLD as it is short + not problematic when including examples
and make no folding is used (please trust me, that's a nightmare).
>
> For all the non-base identities, I would suggest removing the
> "Identity for" prefix in the descriptions. It is self-evident that
> the descriptions are for identities, and the extra words probably
> would not help a GUI rendering of the description strings.
[Med] Good suggestion.
>
> 11. For all the "service type" identities, I would suggest ending
> all the descriptions with "service".
> E.g.,
> "L3VPN service.";
> "Provider Backbone Bridging (PBB) EVPNs service.";
> "Virtual Private LAN Service (VPLS).";
> "Point-to-point Virtual Private Wire Service (VPWS).";
> "Provider Backbone Bridging (PBB) EVPN service.";
> "MPLS based EVPN service.";
> "VXLAN based EVPN service.";
>
[Med] OK.
> 12.
> For t
Re: [OPSAWG] AD review of draft-ietf-opsawg-l3sm-l3nm-09
Re-,
Many thanks for the review. A candidate version can be tracked at:
https://tinyurl.com/l3nm-latest.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> Envoyé : lundi 12 juillet 2021 14:13
> À : draft-ietf-opsawg-l3sm-l3nm@ietf.org
> Cc : opsawg@ietf.org
> Objet : AD review of draft-ietf-opsawg-l3sm-l3nm-09
>
> Hi,
>
> Sorry for the delay in the review (it is a long draft). The review
> of the common l2vpn module will follow later today.
>
> I believe that this work will be really helpful for SPs modelling
> their networks and hence I would like to thank the authors,
> shepherd, and WG for the effort that they have put into this
> document.
>
> Most of my comments on this draft are either minor, or editorial in
> nature. I've listed the minor questions first, for which a response
> would be useful, and then the editorial/grammar suggestions are at
> the end, and in the attached copy of the draft (labelled with #RW:).
>
>
> 4. L3NM Reference Architecture
>
> The terminology from [RFC8309] is introduced to show the
> distinction
> between the customer service model, the service delivery
> model, the
> network configuration model, and the device configuration
> model. In
> that context, the "Domain Orchestration" and "Config
> Manager" roles
> may be performed by "Controllers".
>
> 1. Service delivery model doesn't seem to be included in figure 1,
[Med] This is supposed to be covered by "network model" in the figure. Updated
the figure with an explicit mention.
> and doesn't appear to be referenced further. Does it need to be
> mentioned at all?
>
>
> 7.3. VPN Services
>
> The 'vpn-service' is the data structure that abstracts a
> VPN service
> in the service provider network. Each 'vpn-service' is
> uniquely
> identified by an identifier: 'vpn-id'. Such 'vpn-id' is
> only
> meaningful locally within the network controller. The
> subtree of the
>
> 2. Why limit the vpn-id to the network controller? Presumably, an
> implementation could allow these identifiers to be unique within the
> SP's management network (e.g., perhaps by using a network controller
> specific prefix)?
[Med] Agree. Made this change: s/meaningful locally (e.g., within the network
controller)
>
>
> 7.4. VPN Instance Profiles
>
> | | | +--rw vpn-policies
> | | | +--rw import-policy? string
> | | | +--rw export-policy? string
>
> 3. Is it right that import-policy and export-policy are plain
> strings?
[Med] That usage is correct as we define vpn-id in the common draft as a
generic identifier. That is why we mention "service identifier" as an example.
We can make that more clearer in the common I-D.
>
>
> 7.6. VPN Network Access
>
> +--rw vpn-network-access* [id]
> +--rw id vpn-
> common:vpn-id
> +--rw port-id? vpn-
> common:vpn-id
>
> 4. I'm surprised that port-id is of type vpn-common:vpn:id
[Med] We don't require any structure for the identification of the port; hence
the use of the string (vpn-common:vpn-id) type.
Also, is
> the name port-id better than interface-id? E.g., if the
> connectivity was not via a physical port? I think that the
> description also defines this as an interface rather than a port.
[Med] The details about logical interfaces is covered in the connection and IP
connection (e.g., lx-termination-point).
>
>
> 'multipoint': Represents a broadcast connection between the
> endpoints. The controller must keep the association
> between a
> logical or physical interface on the device with the 'id'
> of
> the 'vpn-network-access'.
>
> 5. Is broadcast the right description here?
[Med] Updated to: "Represents a multipoint connection between the customer site
and the PEs".
>
>
> YANG Model:
>
> identity port-id {
> base bearer-inf-type;
> description
> "Identity for the priority-tagged interface.";
> }
>
> 6. Is this description right? Is port-id automatically priority-
> tagged?
[Med] What is meant here is defining an identity for priority-tagged interface.
Please note that we removed the bearer-inf-type as it is not used in the
module.
>
>
> identity lag-id {
> base bearer-inf-type;
> description
> "Identity for the lag-tagged interface.";
> }
>
> 7. Is "lag-tagged" right, should this be the just "Identity for LAG
> interface"?
[Med] Yes, that's better. Please note that we removed the bearer-inf-type as it
is not used in the module.
>
>
> typedef area-address {
> type string {
> pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
> }
> description
> "This type def
