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

From: <[email-masked]>
Date: Sun, 29 Mar 2020 06:47:07 +0000

Hi Bruno,

Thank your very much for the review and the input. Indeed it makes sense to include OPSFv3 as well. I updated the draft accordingly.

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

In the meanwhile I went one step further since I am going through the RFC process and ask for adoption at OPSAWG and present it also at SPRING. I added also another field called SrSidType to complement the mplsTopLabelType to not only understand which label protocol assigned the top label, but also for which SID type. The SID type brings additional insights into Segment Routing forwarding behavior which are interesting for LFA applications which are hard to troubleshoot without as an example.

I got that idea by looking at the sub-tlv IPFIX code-points for LSP Ping where I noticed the distinction between IGP-Prefix and IGP-Adjacency.
https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#sub-tlv-1-16-21

Since mplsTopLabelType represents the MPLS forwarding plane, where I could have added all the SID types for all the protocols as well, I went a more general approach to use a dedicated field for SID Type. That can be applied for MPLS-SR and SRv6 as well. It's debatable which approach would be simpler. Feedback more than welcome. 

If you and Paul could have a look at that as well would be fantastic. Thanks a lot.

Best Wishes
Thomas Graf

-----Original Message-----
From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, March 27, 2020 11:48 AM
To: Graf Thomas, INI-NET-DCF <[email-masked]>; [email-masked]
Cc: [email-masked]; Martin Vigoureux ([email-masked]) <[email-masked]>
Subject: Re: [spring] review of draft-tgraf-ipfix-mpls-sr-label-type-01

Hi Thomas,
 
> From: spring [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, March 26, 2020 10:20 PM
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Frfcdiff%3Furl2%3Ddraft-tgraf-ipfix-mpls-sr-label-type-02&am
> p;data=02%7C01%7CThomas.Graf%40swisscom.com%7Cc0971d8a798045b6732408d7
> d23c6d59%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C6372090292834402
> 52&amp;sdata=aQVYptB2DOXpxKTMMcgIdiSJt10uCdV0w%2B66%2Bsf9xFY%3D&amp;re
> served=0
> 
> > 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?

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7012%23section-7.2&amp;data=02%7C01%7CThomas.Graf%40swisscom.com%7Cc0971d8a798045b6732408d7d23c6d59%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637209029283450210&amp;sdata=QQe40VEEqfW0UlypEuEUuoKi7lrMKOzN9Sy1U1UM694%3D&amp;reserved=0 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8665&amp;data=02%7C01%7CThomas.Graf%40swisscom.com%7Cc0971d8a798045b6732408d7d23c6d59%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637209029283450210&amp;sdata=CuvFH47aNfFxvRPcZNQWBpmGKpXq1FnhHd6h7jcpQ20%3D&amp;reserved=0
OSPFv3 SR-MPLS extensions: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8666&amp;data=02%7C01%7CThomas.Graf%40swisscom.com%7Cc0971d8a798045b6732408d7d23c6d59%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637209029283450210&amp;sdata=yAJQyI%2BpBQn26MzSUq2H4hlyEHohhKD%2FUUsJUknvrZY%3D&amp;reserved=0

Especially given the current work related to LSP ping: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-mpls-lsp-ping-ospfv3-codepoint&amp;data=02%7C01%7CThomas.Graf%40swisscom.com%7Cc0971d8a798045b6732408d7d23c6d59%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637209029283450210&amp;sdata=Divm0em2OYqAzLWYvBQwnnWOYfSYKuY1veN69JjKiiM%3D&amp;reserved=0

Best wishes,
--Bruno

> 
> 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
> 
> 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.

_________________________________________________________________________________________________________________________

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.

_______________________________________________
spring mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7CThomas.Graf%40swisscom.com%7Cc0971d8a798045b6732408d7d23c6d59%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637209029283450210&amp;sdata=AGo3nRD99wE9uqlnrCV%2BdG5Ge8RiCRDfHORlgt1PPi8%3D&amp;reserved=0

---

From: "Aitken, Paul" <[email-masked]>
Date: Mon, 30 Mar 2020 21:07:10 +0000

Thomas,

I've highlighted lots of small changes, with other comments inline:

Abstract:

   This document introduces additional code points in the mplsTopLabelType IPFIX
   Information Element for IS-IS, OSPFv2, and OSPFv3 MPLS Segment
   Routing (SR) extensions, and a new SID type Information Element to enable Segment
   Routing label and segment type information in IP Flow Information
   Export (IPFIX).

1.  Introduction

   Besides existing MPLS control plane protocols such as BGP-4
   [RFC8277], LDP [RFC5036] and BGP VPN [RFC4364], three new routing-
   protocols, OSPFv2 Extensions [RFC8665], OSPFv3 Extensions [RFC8666]
   and IS-IS Extensions [RFC8667] have been added <where?> to propagate Segment
   Routing labels for the MPLS dataplane [RFC8660].

   Traffic Accounting in Segment Routing Networks
   [I-D.ali-spring-sr-traffic-accounting] describes how IPFIX can be
   leveraged to account traffic to MPLS-SR label dimensions within a
   Segment Routing domain.

I preferred that MPLS-SR was spelled out as "MPLS Segment Routing", especially for those of use who aren't familiar with the terminology. Else, add an xref to wherever MPLS-SR is defined?

2.  MPLS Segment Routing Top Label Type

   A typical use case scenario is to monitor MPLS control plane
   migrations from LDP to IS-IS or OSPF.  By looking at the MPLS label value
   itself, it is not always clear as to which label protocol it belongs,
   since they could potentially share the same label allocation range.
   This is the case for IGP-Adjacency SID's and LDP as an example.

There's a lot of terminology in the this paragraph. Perhaps the reader isn't familiar with LDP, SID. Consider adding a note at the end of section 1, "MPLS specific terminology used in this document is defined in <some RFC>".

3.  Segment Routing Segment Identifier Type

   By introducing a new Information Element called SrSidType, which
   contains the Segment Routing Segment Identifier type according to
   Segment Routing Architecture [RFC8402], we get the intended Segment
   Routing forwarding behaviour in the forwarding plane.

This suggests that the forwarding behaviour is dependent on the Information Element. Consider, "allows the Segment Routing forwarding behaviour to be exported in IPFIX" ?

Figure 2

  Description: This field identifies the Segment Routing Identifier Type of the top-of-stack.

Consider, "MPLS top-of-stack label", or similar - else there's nothing to constrain this to MPLS.

Figure 3

Consider reserving the zero value for "Unknown", for use when the SID type cannot be determined and for cases where the a flow record containing a SrSidType field is used for non MPLS traffic.

7.2.  Informative References

Note that this draft would be blocked until all the I-Ds become RFCs since it couldn't be published while citing WIP docs.

Check the nits:

  == The document doesn't use any RFC 2119 keywords, yet has text resembling
     RFC 2119 boilerplate text.

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPFIX-IE46'

  ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012)

P.