Subject: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

From: Tianran Zhou <[email-masked]>
Date: Wed, 24 Mar 2021 06:23:12 +0000

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call on draft-tgraf-ipfix-mpls-sr-label-type-07:
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/

Please respond with your comments and thoughts on this draft.

We will conclude on April 7, 2021.

Thanks,
Tianran as co-chair

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 24 Mar 2021 09:20:48 +0000

I've read this document and support its adoption.

Given that this document is only 6 pages long (really only 2 pages of substantial content) I hope that this document can move through the WG quickly.

Thanks,
Rob

From: OPSAWG <[email-masked]> On Behalf Of Tianran Zhou
Sent: 24 March 2021 06:23
To: [email-masked]
Subject: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi WG,

Thanks,
Tianran as co-chair

---

From: <[email-masked]>
Date: Wed, 24 Mar 2021 09:48:51 +0000

Hi all,

I support it as well.

As I expect that some usual suspects will raise a comment about IPv6, it is better to fix this by mentioning mplsTopLabelIPv6Address in addition to 47 already cited in the document.

I also suggest to update the description in Section 3 to mention for each entry this is about "extensions" for SR.

The authors may also clarify the relationship with (4      BGP: Any label associated with BGP or BGP routing).

Cheers,
Med

De : OPSAWG [mailto:[email-masked]] De la part de Rob Wilton (rwilton)
Envoyé : mercredi 24 mars 2021 10:21
À : Tianran Zhou <[email-masked]>; [email-masked]
Objet : Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Thanks,
Rob

From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: 24 March 2021 06:23
To: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi WG,

Thanks,
Tianran as co-chair

_________________________________________________________________________________________________________________________

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: Wed, 24 Mar 2021 11:31:02 +0000

Hi Med,

Many thanks for your review. I will include your input by adding "mplsTopLabelIPv6Address" and correcting from "extension" to "extensions" in -08.

In regards to IE46, distinguish between code point 4 and TBD4

4          | BGP: Any label associated with BGP or BGP routing
TBD4    | BGP Segment Routing Prefix-SID

This relates to the pending cleanup of the IE46 IPFIX MPLS label type registry at IANA. Slide deck attached. Slides 3 and 4.

Code point 4 will be updated to RFC 8277 as reference.

With "BGP: Any label associated with BGP or BGP routing" the following is being meant:

Using BGP to Bind MPLS Labels to Address Prefixes
https://tools.ietf.org/html/rfc8277#section-2

BGP Path Attributes - (14) MP_REACH_NLRI - Top Label
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2

Code point TBD4 will have RFC 8669 as reference.

With "BGP Segment Routing Prefix-SID" the following is being meant:

Segment Routing Prefix Segment Identifier Extensions for BGP
https://tools.ietf.org/html/rfc8669#section-3.1

BGP Prefix-SID Label-Index TLV Flags
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-prefix-sid-label-index-tlv-flags

I hope this clarifies it. Looking forward to your feedback.

Best wishes
Thomas

From: OPSAWG <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, March 24, 2021 10:49 AM
To: Rob Wilton (rwilton) <rwilton=[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi all,

I support it as well.

Cheers,
Med

De : OPSAWG [mailto:[email-masked]] De la part de Rob Wilton (rwilton)
Envoyé : mercredi 24 mars 2021 10:21
À : Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Thanks,
Rob

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call on draft-tgraf-ipfix-mpls-sr-label-type-07:
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C41a540a6788c4aec044708d8eeaa1c32%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521761664220921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OZiFofgEwz5mtCz7gotduDLp3mddOYpqOb5nhGKUA%2Fs%3D&reserved=0>

Thanks,
Tianran as co-chair

Thank you.

---

From: <[email-masked]>
Date: Wed, 24 Mar 2021 12:45:32 +0000

Re-,

Thanks, Thomas.

The description of 4 entry ("**Any label** associated with BGP") may suggest that labels disseminated in BGP as per RFC8669 are also covered by that one. You may include the clarification you provided below in your document to make things less ambiguous.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]]
Envoyé : mercredi 24 mars 2021 12:31
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; rwilton=[email-masked]; [email-masked]; [email-masked]
Objet : RE: Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi Med,

Best wishes
Thomas

From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, March 24, 2021 10:49 AM
To: Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi all,

I support it as well.

Cheers,
Med

Thanks,
Rob

Hi WG,

Thanks,
Tianran as co-chair

Thank you.

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 24 Mar 2021 14:59:22 +0100

I find this document useful and support its adoption.

Paolo

On 24/03/2021 07:23, Tianran Zhou wrote:
> Hi WG,
> 
> As discussed in the IETF110 meeting, we start a two weeks adoption call 
> on draft-tgraf-ipfix-mpls-sr-label-type-07:
> 
> <https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/>
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: <[email-masked]>
Date: Wed, 24 Mar 2021 14:51:26 +0000

Hi Med,

Thanks. Ack. Makes sense. I will include it in -08.

Best wishes
Thomas

From: [email-masked] <[email-masked]>
Sent: Wednesday, March 24, 2021 1:46 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[email-masked]>; rwilton=[email-masked]; [email-masked]; [email-masked]
Subject: RE: Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Re-,

Thanks, Thomas.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Envoyé : mercredi 24 mars 2021 12:31
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>; rwilton=[email-masked]<mailto:rwilton=[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : RE: Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi Med,

Using BGP to Bind MPLS Labels to Address Prefixes
https://tools.ietf.org/html/rfc8277#section-2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8277%23section-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdfa34634f9eb4820bebe08d8eec2c1ce%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521867542514175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LCHLaqQICttUjIVsL6y0%2B9ZNGs7Du9vp1jO%2FJCe94EU%3D&reserved=0>

BGP Path Attributes - (14) MP_REACH_NLRI - Top Label
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-parameters%2Fbgp-parameters.xhtml%23bgp-parameters-2&data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdfa34634f9eb4820bebe08d8eec2c1ce%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521867542514175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gnphnq70pqKfzB776wgc1wvMTOKk1lZlkyf1CMWygbs%3D&reserved=0>

Segment Routing Prefix Segment Identifier Extensions for BGP
https://tools.ietf.org/html/rfc8669#section-3.1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8669%23section-3.1&data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdfa34634f9eb4820bebe08d8eec2c1ce%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521867542514175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fbsp3ffGZJnfu0mLsgK%2BWZGVlfJ6RLN33ix%2FUr5EkL8%3D&reserved=0>

BGP Prefix-SID Label-Index TLV Flags
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-prefix-sid-label-index-tlv-flags<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-parameters%2Fbgp-parameters.xhtml%23bgp-prefix-sid-label-index-tlv-flags&data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdfa34634f9eb4820bebe08d8eec2c1ce%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521867542524130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ac9EbeQ6xhGFpcxgeI%2FqVhiHLJ3q8KPoUKfpYgmaEV0%3D&reserved=0>

Best wishes
Thomas

Hi all,

I support it as well.

Cheers,
Med

Thanks,
Rob

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call on draft-tgraf-ipfix-mpls-sr-label-type-07:
https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7Cdfa34634f9eb4820bebe08d8eec2c1ce%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637521867542524130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ad2T10d4182yqxJmhZDL8V55QlV4SlbzSCCl0pon07Y%3D&reserved=0>

Thanks,
Tianran as co-chair

Thank you.

Thank you.

---

From: tom petch <[email-masked]>
Date: Wed, 24 Mar 2021 16:54:42 +0000

From: OPSAWG <[email-masked]> on behalf of Tianran Zhou <[email-masked]>
Sent: 24 March 2021 06:23

Hi WG,

<tp>
I struggle to make sense of the IANA Considerations.

Usual practice is to start
'IANA is requested to .. '
which is
a) polite
b) easily changed to 'IANA has ...' when they have.

There are two separate actions, or perhaps not.  Usual practice is to have separate sections, one might be

3.1 IANA is requested to allocate four code points in the existing sub-registry "IPFIX MPLS label type (Value 46)" of the "IPFIX Information Elements" registry for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID Segment Routing extension 

3.2 IANA is requested to add one new "IPFIX Information Element"
   with a new sub-registry in the "IP Flow Information Export (IPFIX)
   Entities" name space.
and if 3.2 makes no sense to you it may be because the I-D makes no sense to me!.  Perhaps there is only one IANA Consideration.
This I think needs to be fixed before adoption.

Separately, 
2.  MPLS Segment Routing Top Label Type
is all about justification and motivation which I think that the heading should reflect.

' Adding an additional layer into
   the MPLS data plane to above described use case.'
is unclear to me

 ...'we get insight'  ..
is not the impersonal style that an RFC usually is
Perhaps 
Introducing four new code points to information element
   mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID,
   when Segment Routing with one of these four routing protocols is deployed, makes it possible to see what traffic is being forwarded, based on which MPLS control plane protocol

except that is not quite right.  These four are not 'MPLS control plane protocol' in the accepted sense of the phrase.

Perhaps -2 

Introducing four new code points to information element
   mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID,
   when Segment Routing with one of these four routing protocols is deployed, makes it possible to see what traffic is being forwarded by one of these four protocols'

HTH

Tom Petch

Thanks,
Tianran as co-chair

---

From: <[email-masked]>
Date: Tue, 30 Mar 2021 03:12:04 +0000

Hi Tom,

Thanks for input.

>   when Segment Routing with one of these four routing protocols is deployed, makes it possible to see what traffic is being forwarded by one of these four protocols'

Ack to both inputs. Will change wording accordingly. Makes perfectly sense.

>   the MPLS data plane to above described use case.'

This is refering to Seamless MPLS SR. The overall aim of this paragraph is to show two main motivations when mplsTopLabelType(46) is needed in context of MPLS SR.

1. IGP Migration from MPLS to MPLS SR 
2. BGP Migration from Seamless MPLS to MPLS SR

Now:

   A typical use case scenario is to monitor MPLS control plane
   migrations from LDP to IS-IS or OSPF Segment Routing.  Such a
   migration can be done node by node as described in RFC8661 [RFC8661]

   Another use case is the monitoring of a migration to a Seamless MPLS
   SR [I-D.hegde-spring-mpls-seamless-sr] architecture where prefixes
   are propagated with dynamic BGP labels according to RFC8277

   [RFC8277], BGP Prefix-SID according to RFC8669 [RFC8669] and used for
   the forwarding between IGP domains.  Adding an additional layer into
   the MPLS data plane to above described use case.

Proposal:

   A typical use case scenario is to monitor MPLS control plane
   migrations from LDP to IS-IS or OSPF Segment Routing.  Such a
   migration can be done node by node as described in RFC8661 [RFC8661]

   Another use case scenario is to monitor MPLS control plane migrations 
   from dynamic BGP labels according to RFC8277 [RFC8277] to BGP Prefix-SID 
   according to RFC8669 [RFC8669] in context of Seamless MPLS SR 
   [I-D.hegde-spring-mpls-seamless-sr].

I hope this makes better sense now. Looking forward to your reply.

Best wishes
Thomas

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of tom petch
Sent: Wednesday, March 24, 2021 5:55 PM
To: Tianran Zhou <[email-masked]>; [email-masked]
Subject: Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call on draft-tgraf-ipfix-mpls-sr-label-type-07:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tgraf-ipfix-mpls-sr-label-type%2F&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C97b62c881a014607166e08d8eee59342%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637522017072074230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=jI14Jw1em43U6PS5omPQPyLOwKA4XexXU3kVcwym1KM%3D&amp;reserved=0

<tp>

Separately,

 ...'we get insight'  ..
is not the impersonal style that an RFC usually is Perhaps Introducing four new code points to information element
   mplsTopLabelType(46) for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID,
   when Segment Routing with one of these four routing protocols is deployed, makes it possible to see what traffic is being forwarded, based on which MPLS control plane protocol

Perhaps -2 

HTH

Tom Petch

Thanks,
Tianran as co-chair

_______________________________________________
OPSAWG mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C97b62c881a014607166e08d8eee59342%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637522017072074230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VB4J5I3%2FnDZ1szaV3mVBWiOgmmz59b%2B66Lbh8hmxusg%3D&amp;reserved=0