[OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-10.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/3 VPN Common YANG Model Authors : Samier Barguil Oscar Gonzalez de Dios Mohamed Boucadair Qin Wu Filename: draft-ietf-opsawg-vpn-common-10.txt Pages : 69 Date: 2021-09-09 Abstract: This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: * "This version of this YANG module is part of RFC ;" * "RFC : A Layer 2/3 VPN Common YANG Model"; * reference: RFC Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-vpn-common-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vpn-common-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Alvaro Retana's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
Hi Alvaro, Thanks for the feedback. It appears I need reading glasses. I added a IANA note for moving the RFC references from the additional information to the reference column. https://www.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.txt=https://raw.githubusercontent.com/graf3net/draft-tgraf-ipfix-mpls-sr-label-type/master/draft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txt As soon as I have the feedback from Benjamin, I will submit -11 and move forward to the RFC editor queue. Best wishes Thomas -Original Message- From: Alvaro Retana Sent: Thursday, September 9, 2021 6:11 PM To: Graf Thomas, INI-NET-TCZ-ZH1 ; i...@ietf.org Cc: opsawg-cha...@ietf.org; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; mohamed.boucad...@orange.com; opsawg@ietf.org Subject: RE: Alvaro Retana's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT) On September 5, 2021 at 2:45:59 AM, thomas.g...@swisscom.com wrote: Thomas: Hi! ... > Regarding the second remark. Updating the "Additional Information" in > the IPFIX Information Elements registry for mplsTopLabelType. > > Throughout the process we had a lengthy exchange with IANA and the IE > doctors what the best course of action is since "Additional > Information" is not publicly visible. We came to the conclusion that > this is addressed best by adding the RFC which is describing the code point > to the "Reference" > column. The "Additional Information" column *is* publicly visible -- that is how I found it. ;-) https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml%23ipfix-information-elementsdata=04%7C01%7CThomas.Graf%40swisscom.com%7C4b2206a9ee624de0a93808d973ac7840%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637668006849700536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=MQPTRcTrtgJJM4IuF%2BgI9Byy0rLRoIVKlWVaxW4wV98%3Dreserved=0 > I could add an IANA remark that for the existing entries in > mplsTopLabelType, the RFC references described in "Additional > Information" could be moved to the reference column. That works for me -- I'm assuming you would also add a reference to this document, right? What about the current text in "Additional Information"? If it is left as-is, I think may still look incomplete (regardless of what the reference column points to). Thanks! Alvaro. smime.p7s Description: S/MIME Cryptographic Signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New Version Notification for draft-shytyi-opsawg-vysm-08.txt
Hello opsawg participants,
We are happy to anounce a new version of the VYSM uCPE draft:
https://datatracker.ietf.org/doc/draft-shytyi-opsawg-vysm/10/
What is new in this version?
- ETSI SOL006 included as deviation.
- ucpe yangs have more leafs.
- ietf package is defined with list majority of yang modules.
file "ietf-ucpe-network-service-pkg.json"
= NOTE: '\' line wrapping per BCP XX (RFC ) ===
{
"ietf-yang-instance-data:instance-data-set": {
"name": "ietf-ucpe-network-service-pkg",
"pkg-schema": {
package: "ietf-yang-package-defn-...@0.1.0.json"
},
"description": "YANG package for universal CPE network service",
"content-data": {
"ietf-yang-package-instance:yang-package": {
"name": "ietf-ucpe-network-service-pkg",
"version": "0.0.1",
"timestamp": "2021-09-09T17:00:00Z",
"organization": "IETF OPSAWG Working Group",
"contact" : "WG Web: ",
"description": "IETF uCPE network service YANG package.\
\
This package defines a small sample set of \
YANG modules that could represent the basic set of \
modules that a standard universal CPE device might be expected \
to support.",
"reference": "XXX, draft-shytyi-opsawg-vysm-10.xml",
"location": [ "https://github.com/dmytroshytyi/ucpe-ietf/\
ietf-ucpe-serv...@v0.0.1.json" ],
"module": [
{
"name": "ieee-dot1Q-types,
"revision": "2015-08-18",
"location": [ "/https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/ieee-dot1Q-types.yang" ],
},
{
"name": "ietf-interfaces",
"revision": "2018-02-20",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-interfaces%402018-02-20.yang" ],
},
{
"name": "ietf-ip",
"revision": "2018-02-22",
"location": [ "https://github.com/dmytroshytyi/ucpe-ietf\
/blob/master/ietf-ip%402018-02-22.yang" ],
},
{
"name": "ietf-logical-network-element",
"revision": "2019-01-25",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-logical-network-element%402019-01-25.yang"
],
},
{
"name": "ietf-network",
"revision": "2018-02-26",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-network%402018-02-26.yang" ],
},
{
"name": "ietf-network-instance",
"revision": "2019-01-21",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-network-instance%402019-01-21.yang" ],
},
{
"name": "ietf-network-topology",
"revision": "2018-02-26",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-network-topology%402018-02-26.yang" ],
},
{
"name": "ietf-routing-types",
"revision": "2017-12-04",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-routing-types%402017-12-04.yang" ],
},
{
"name": "ietf-te-topology",
"revision": "2019-02-07",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-te-topology%402019-02-07.yang" ],
},
{
"name": "ietf-te-topology-sf",
"revision": "2019-11-03",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-te-topology-sf%402019-11-03.yang" ],
},
{
"name": "ietf-te-types",
"revision": "2019-11-18",
"location": [ "https://github.com/dmytroshytyi/\
ucpe-ietf/blob/master/\
ietf-te-types%402019-11-18.yang" ],
},
{
"name":
Re: [OPSAWG] Alvaro Retana's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
On September 5, 2021 at 2:45:59 AM, thomas.g...@swisscom.com wrote: Thomas: Hi! ... > Regarding the second remark. Updating the "Additional Information" in the > IPFIX Information Elements registry for mplsTopLabelType. > > Throughout the process we had a lengthy exchange with IANA and the IE > doctors what the best course of action is since "Additional Information" is > not publicly visible. We came to the conclusion that this is addressed best > by adding the RFC which is describing the code point to the "Reference" > column. The "Additional Information" column *is* publicly visible -- that is how I found it. ;-) https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-elements > I could add an IANA remark that for the existing entries in mplsTopLabelType, > the RFC references described in "Additional Information" could be moved to > the reference column. That works for me -- I'm assuming you would also add a reference to this document, right? What about the current text in "Additional Information"? If it is left as-is, I think may still look incomplete (regardless of what the reference column points to). Thanks! Alvaro. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Last Call: (A Layer 3 VPN Network YANG Model) to Proposed Standard
Hi Tom,
Thank you for the review. An updated version that takes into account many of
your comments can be tracked at: https://tinyurl.com/l3nm-latest (or in the
datatracker when the revised version is public)
You did already raised the comment about ipv4/ipv6/dual-stack identities during
the WGLC. We clarified the intended behavior at the time. I don't see any new
element in your comment on this particular point, but I understand that you
want to increase awareness so that others may look at this. This is appreciated.
As mentioned in the IETF LC of the vpn-common, this identity is used to
characterize the connectivity type provided by the VPN service. We are not
manipulating AFIs/SAFIs as those will be derived when translating into specific
** device modules ** (which we aren't as the L3NM is a network model (as per
RFC8969)) from the VPN service type and the address family. We added a note
about this.
Selecting the routing protocol version or whether two sessions or one single
session will be enabled (BGP case, for example) is deployment-specific. For
example, when dual-stack is indicated in the L3NM, whether both OSPFv2 and
OPSFv3 instances will be activated or only OSPFv3 is used (i.e., also announce
IPv4 routes as per RFC5838) is a function of the underlying device capabilities
and local guidelines.
"dual-stack" identity was added to ** rationalize the module and factorize
items ** that are applicable for both IPv4 and IPv6. With this value, we can
have more compact network service definition. For example, with the current
specification we can express something such as (only an excerpt from the full
body):
==
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"vpn-targets": {
"vpn-target": [
{
"id": "1",
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
}
}
]
==
While the following would be needed to convey the same configuration if
dual-stack identity is not supported.
==
"address-family": [
{
"address-family": "vpn-common:ipv4",
"vpn-targets": {
"vpn-target": [
{
"id": "1",
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
}
},
{
"address-family": "vpn-common:ipv6",
"vpn-targets": {
"vpn-target": [
{
"id": "1",
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
}
}
]
==
The dual-stack identity is also useful when a policy is to be set for both IPv4
and IPv6 as ** a set **. For example, the current module can control the
maximum number of routes that will apply independently of the address family.
We don't require a 50%-50% split between the two as soon as the sum does not
exceed the indicated value. As such, we can indicate something such as:
==
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"vpn-targets": {
"vpn-target": [
{
"id": "1",
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
},
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 100
}
]
}
]
==
Absent that identity, only strict maximums are possible such as in this
example:
==
"address-family": [
{
"address-family": "vpn-common:ipv4",
"vpn-targets": {
"vpn-target": [
{
"id": "1",
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
}
]
},
"maximum-routes": [
{
"protocol":
[OPSAWG] Murray Kucherawy's No Objection on draft-ietf-opsawg-ipfix-mpls-sr-label-type-10: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-opsawg-ipfix-mpls-sr-label-type-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/ -- COMMENT: -- Nice work on the shepherd writeup. This was the only working group document on this week's IESG telechat, which is remarkable. It can truly be said that it got thorough IESG review. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.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 : Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) Author : Thomas Graf Filename: draft-ietf-opsawg-ipfix-mpls-sr-label-type-10.txt Pages : 6 Date: 2021-09-08 Abstract: This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on which MPLS control plane protocol used within a Segment Routing domain. In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for PCE, IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-mpls-sr-label-type-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
