Hi Thomas,
Thank you for promptly addressing the comments.
Looks good to me, but idnits is still not happy with these long lines of Table
1:
==
** There are 12 instances of too long lines in the document, the longest
one being 2 characters in excess of 72.
==
One very very minor nit:
OLD:
These values are thus used for those
distinct purposes
NEW:
These values are thus used for those
distinct purposes.
For the intended status, I'm still not convinced we have valid arguments for
it. Let's see how to fix that.
Cheers,
Med
De : thomas.g...@swisscom.com [mailto:thomas.g...@swisscom.com]
Envoyé : jeudi 24 juin 2021 06:23
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>;
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org; opsawg-cha...@ietf.org
Cc : opsawg@ietf.org
Objet : RE: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type
Hi Med,
Many thanks for the shepherd review. I updated the document accordingly into
-03 version.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-03
I included all your suggestions and followed your example in using
abbreviations and changed the term "MPLS Segment Routing"
To "MPLS SR" throughout the document. The same for the term "subregistry"
instead of "sub-registry" or "SubRegistry".
I took the liberty to further simplify the use case paragraph in section 2. I
hope it is better readable now. Looking forward to your review.
Below in detail where I deviated to your suggestions. Mostly minor.
Regarding wherever this document should be on Standard Track or not. That's a
reasonable question. I doubled checked on
https://www.ietf.org/standards/process/informational-vs-experimental/, checked
also other IPFIX RFC's such as https://datatracker.ietf.org/doc/html/rfc8549
which also only specified new IPFIX code points for existing protocols, and
came to the same conclusion then Tianran that Informational does not fit.
Best wishes
Thomas
Section 1
---
Proposed:
Also [I-D.ali-spring-sr-traffic-accounting] describes
how IP Flow Information Export <xref target="RFC7012"/> can be leveraged
to account traffic to MPLS Segment Routing label dimensions within a
Segment Routing domain.
Changed to:
Also [I-D.ali-spring-sr-traffic-accounting] describes
how IP Flow Information Export <xref target="RFC7012"/> can be leveraged
to account traffic to MPLS SR label dimensions within a
Segment Routing domain.
Section 2
---
Proposed:
By introducing four new code points to the IPFIX IE
mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3, and BGP Prefix-SID,
it is possible to identify into which traffic is being
forwarded based upon which MPLS control plane protocol is in use.
Changed to:
By introducing four new code points to the IPFIX IE
mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID,
it is possible to identify which traffic is being
forwarded based upon which MPLS SR control plane protocol is in use.
Section 2
---
Proposed:
Both use cases can be verified by using mplsTopLabelType(46),
mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
mplsTopLabelStackSection(70), and forwardingStatus(89) IEs to infer:
o how many packets are forwarded or dropped,
o if dropped, for which reasons, and
o the MPLS provider edge loopback address and label protocol.
Changed to:
Both use cases can be verified by using mplsTopLabelType(46),
mplsTopLabelIPv4Address(47), mplsTopLabelIPv6Address(140),
mplsTopLabelStackSection(70) and forwardingStatus(89) IEs to infer
how many packets are forwarded or dropped to which MPLS provider
edge loopback address and label protocol, and if dropped for which
reasons.
Section 3
---
Proposed: Table 1: Updates to "IPFIX MPLS label type (Value 46)" SubRegistry
Changed to: Table 1: Updates to "IPFIX MPLS label type (Value 46)" subregistry
Section 4
---
Proposed: These values are thus used for distinct purposes
Changed to: These values are thus used for those distinct purposes
From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
Sent: Wednesday, June 23, 2021 5:47 PM
To:
draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org<mailto:draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org>;
opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: Shepherd Review of draft-ietf-opsawg-ipfix-mpls-sr-label-type
Hi Thomas, all,
I made a shepherd review of the document. The review can be found at:
* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-ietf-drip-reqs-06-rev%2520Med.pdf&data=04%7C01%7CThomas.Graf%40swisscom.com%7C6b1146929f844e45b53108d9365e31b0%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637600600448168824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LL21sIBfQASVe1nV6ZL3MrmVRp9RbZowyHBBSmBFgBk%3D&reserved=0>
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-drip-reqs-06-rev%20Med.docx<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-ietf-drip-reqs-06-rev%2520Med.docx&data=04%7C01%7CThomas.Graf%40swisscom.com%7C6b1146929f844e45b53108d9365e31b0%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637600600448178789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AjP1FU6uDFRM1LabzOIizUTuauJMaaO8aHWUKuh25EM%3D&reserved=0>
Almost all the comments are minor. These are basically to enhance the
readability of the document (shorten long sentences, etc.) and make idnits
happy.
There is one "procedural" comment that it is better to discuss now as I suspect
it will pop up in the process: Why the document is in the "Standard Track"?
I failed to see any valid reason especially that:
* The IANA policy for the target registry is Expert Review.
* We don't have any normative statements in the document.
Are there any reasons why the document should be in "Standards Track"?
Once these comments are fixed, I will start preparing the write-up.
Thank you.
Cheers,
Med
_________________________________________________________________________________________________________________________
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 responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
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 responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
