Subject: [spring] review of draft-tgraf-ipfix-mpls-sr-label-type-01

From: "Aitken, Paul" <[email-masked]>
Date: Wed, 25 Mar 2020 10:10:02 +0000

Thomas, here's some feedback about draft-tgraf-ipfix-mpls-sr-label-type-01 :

Since Figure 1 is intended to update the "IPFIX Information Element #46" 
SubRegistry, it should contain the same columns as that registry - ie, 
Value, Description, Reference.

The ElementID, Abstract Data Type, and Data Type Semantics are already 
defined in the "IPFIX Information Elements" registry; they are not 
pertinent here.

So Figure 1 should be:

       -------------------------------------------
       |Value|      Description      | Reference |
       |-----------------------------------------|
       |TBD1 | IS-IS Segment Routing |  RFC8667  |
       |-----------------------------------------|
       |TBD2 | OSPF Segment Routing  |  RFC8665  |
       -------------------------------------------

If the draft is to be accepted by IANA then it needs to be published or 
archived somewhere, since RFC 7012 (and RFC 5102) say:

     The specification of new MPLS label types MUST be published using a
     well-established and persistent publication medium.

"not believed" in section 3 is not rigorous; the statement must be 
definite - eg "This document does not add any additional IPFIX security 
considerations.", or "The same security considerations apply as for the
IPFIX Protocol [RFC7012]."

Surely many of the Normative references are simply Informative? eg 
I-D.ali-spring-sr-traffic-accounting, RFC4364, RFC5036, RFC8277, 
RFC8660, RFC8665, RFC8667.

Typo: "laveraged" in the second paragraph of section 1.

P.

---

From: <[email-masked]>
Date: Thu, 26 Mar 2020 21:20:15 +0000

Hi Paul,

Many thanks for the review and the feedback. Ack on all. I updated the draft according to your and other input from the mailing list.

https://www.ietf.org/rfcdiff?url2=draft-tgraf-ipfix-mpls-sr-label-type-02

> If the draft is to be accepted by IANA then it needs to be published or archived somewhere

This was one of the unclarities I had. If I understand you correctly, this draft needs to be adopted by SPRING working group and published as RFC for documentation purposes before values can be assigned by IANA. Correct?

Best Wishes
Thomas

-----Original Message-----
From: Aitken, Paul <[email-masked]> 
Sent: Wednesday, March 25, 2020 11:10 AM
To: Graf Thomas, INI-NET-DCF <[email-masked]>
Cc: [email-masked]
Subject: review of draft-tgraf-ipfix-mpls-sr-label-type-01

Since Figure 1 is intended to update the "IPFIX Information Element #46" 
SubRegistry, it should contain the same columns as that registry - ie, Value, Description, Reference.

The ElementID, Abstract Data Type, and Data Type Semantics are already defined in the "IPFIX Information Elements" registry; they are not pertinent here.

So Figure 1 should be:

If the draft is to be accepted by IANA then it needs to be published or archived somewhere, since RFC 7012 (and RFC 5102) say:

"not believed" in section 3 is not rigorous; the statement must be definite - eg "This document does not add any additional IPFIX security considerations.", or "The same security considerations apply as for the IPFIX Protocol [RFC7012]."

Surely many of the Normative references are simply Informative? eg I-D.ali-spring-sr-traffic-accounting, RFC4364, RFC5036, RFC8277, RFC8660, RFC8665, RFC8667.

P.

---

From: "Aitken, Paul" <[email-masked]>
Date: Thu, 26 Mar 2020 22:31:04 +0000

Thomas,

Looks good!

Two nits:

In the new text in the last paragraph of section 1, remove "to" : "to which label protocol it belongs to".

In Figure 1, although the order is unimportant, could RFC 8665 come before RFC 8667 ?

Yes, publishing it as an RFC would be the most obvious solution. The language in RFC 7012 and RFC 5102 is flexible to allow for non-IETF documents.

P.

---

From: <[email-masked]>
Date: Fri, 27 Mar 2020 10:48:11 +0000

Hi Thomas,
 
> From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, March 26, 2020 10:20 PM
> 
> Hi Paul,
> 

https://tools.ietf.org/html/rfc7012#section-7.2 says:

   "New assignments for MPLS label types are administered by IANA through
   Expert Review [RFC5226], i.e., review by one of a group of experts
   designated by an IETF Area Director.  The group of experts must
   double-check the label type definitions with already-defined label
   types for completeness, accuracy, and redundancy.  The specification
   of new MPLS label types MUST be published using a well-established
   and persistent publication medium."

As far as I know, for the IETF " a well-established and persistent publication medium"  mostly translates as RFC (i.e. a draft is not enough). My reading is that any kind of RFC would work, including independent submission. However, the document would probably benefit from a technical review. I feel that both opsawg and spring would work, I don't have specific preference.

As an individual contributor, I have one question related to:

           | TBD1 | IS-IS Segment Routing |  RFC8667  |

           | TBD2 | OSPF Segment Routing  |  RFC8665  |

Do you want to make the distinction between OSPFv2 and OSPFv3?
OSPFv2 SR-MPLS extensions: https://tools.ietf.org/html/rfc8665
OSPFv3 SR-MPLS extensions: https://tools.ietf.org/html/rfc8666

Especially given the current work related to LSP ping: https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ospfv3-codepoint

Best wishes,
--Bruno

> The ElementID, Abstract Data Type, and Data Type Semantics are already defined in the "IPFIX Information Elements" registry; they are not pertinent here.

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Fri, 27 Mar 2020 16:44:42 +0000

Hi Paul,

Thanks for the feedback. Makes perfectly sense. All ack. Is queued for the next release.

Best Wishes
Thomas

From: Aitken, Paul <[email-masked]>
Sent: Thursday, March 26, 2020 11:31 PM
To: Graf Thomas, INI-NET-DCF <[email-masked]>
Cc: [email-masked]
Subject: Re: review of draft-tgraf-ipfix-mpls-sr-label-type-01

Thomas,

Looks good!

Two nits:

P.