Dear Rob, Med and IESG
Based on Ben's feedback, I submitted the final -11 version.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-11
I think the document is ready now for the RFC editor queue.
Best wishes
Thomas
-Original Message-
From: Benjamin Kaduk
Sent: Tuesday, September 14, 2021 1:57 AM
To: Graf Thomas, INI-NET-TCZ-ZH1
Cc: i...@ietf.org; draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org;
opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com
Subject: Re: Benjamin Kaduk's No Objection on
draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
Hi Thomas,
Many thanks; that looks like it should work quite nicely.
-Ben
On Sat, Sep 11, 2021 at 07:46:17AM +, thomas.g...@swisscom.com wrote:
> Hi Benjamin,
>
> Thanks for the clarifications and suggestions. Very much appreciated.
>
> > I think it would be good to add a few words to hint at dimensional
> > modeling, and maybe also to add a few words to clarify why
> > draft-hegde-spring-mpls-seamless-sr is being referenced.
>
> I put additional thoughts into that paragraph and changed the reference to
> RFC 8670 (BGP Prefix Segment in Large-Scale Data Centers) instead. RFC 7983
> (Use of BGP for Routing in Large-Scale Data Centers) describes the use of
> BGP labeled-unicast in large data center environments. Where RFC 8670 focuses
> on using Segmenting Routing with BGP by using the same architecture. RFC 8670
> describes the motivation of such a migration and is a stable document. I hope
> this makes more sense now.
>
>Also, [I-D.ali-spring-sr-traffic-accounting] describes how IP Flow
>Information Export [RFC7012] can be leveraged in dimensional data
>modelling to account traffic to MPLS SR label dimensions within a
>Segment Routing domain.
>
>Another use case is to monitor MPLS control plane migrations from
>dynamic BGP labels [RFC8277] to BGP Prefix-SIDs [RFC8669]. The
>motivation and benefits for such a migration is described in
>[RFC8670].
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2F%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fraw.githubusercontent.com
> %2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2Fmaster%2Fdraft-ie
> tf-opsawg-ipfix-mpls-sr-label-type-10.txt%26url2%3Dhttps%3A%2F%2Fraw.g
> ithubusercontent.com%2Fgraf3net%2Fdraft-tgraf-ipfix-mpls-sr-label-type
> %2Fmaster%2Fdraft-ietf-opsawg-ipfix-mpls-sr-label-type-11.txtdata
> =04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123c
> d4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000sdata=6J6eFY%2FHjJWFUIKugTO%2F0q%2FhSUm9a
> 54DE8qV2LSCa3E%3Dreserved=0
>
> Let me know your thoughts.
>
> Best wishes
> Thomas
>
> -Original Message-
> From: Benjamin Kaduk
> Sent: Saturday, September 11, 2021 4:02 AM
> To: Graf Thomas, INI-NET-TCZ-ZH1
> Cc: i...@ietf.org;
> draft-ietf-opsawg-ipfix-mpls-sr-label-t...@ietf.org;
> opsawg-cha...@ietf.org; opsawg@ietf.org; mohamed.boucad...@orange.com
> Subject: Re: Benjamin Kaduk's No Objection on
> draft-ietf-opsawg-ipfix-mpls-sr-label-type-08: (with COMMENT)
>
> Hi Thomas,
>
> On Thu, Sep 09, 2021 at 05:19:00AM +, thomas.g...@swisscom.com wrote:
> > Hi Benjamin,
> >
> > > I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of
> > > maturity to be a good reference here (and thus, that this example is
> > > worth including).
> > I agree. The only alternative is to reference
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mpls-seamless-mpls-07data=04%7C01%7CThomas.Graf%40swisscom.com%7C1555abcdd34d4bc8c47308d977123cd4%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637671742480108639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=W9Y9RGobCEdshkILs7JeW2HpAE3T%2BdJ322XTfbD9STo%3Dreserved=0
> > instead. The challenge is that Seamless MPLS is widely supported and used
> > at network vendors and operators but not yet standardized at IETF. Both
> > Seamless MPLS drafts are either in progress or expired. If you don't
> > object, I like to keep that example and reference for not having a better
> > alternative.
>
> To be clear, I don't have issues with referring to an individual draft in the
> abstract. It's more that for this particular draft, I came away very unsure
> what I was supposed to take away from reading it that made it worth
> referencing. It would probably be possible to add more words to
> draft-ietf-opsawg-ipfix-mpls-sr-label-type to help me know what to look for
> in draft-hedge-spring-mpls-seamless-sr, or to make edits to
> draft-hegde-spring-mpls-seamless-sr itself (or both), to help clarify what's
> interesting about it that we want the reader to think about. Since I am
> still unclear on
