Hi Tom, Thanks for input.
>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 > 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' Ack to both inputs. Will change wording accordingly. Makes perfectly sense. > ' Adding an additional layer into > the MPLS data plane to above described use case.' > is unclear to me 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 protected]> On Behalf Of tom petch Sent: Wednesday, March 24, 2021 5:55 PM To: Tianran Zhou <[email protected]>; [email protected] Subject: Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07 From: OPSAWG <[email protected]> on behalf of Tianran Zhou <[email protected]> Sent: 24 March 2021 06:23 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&data=04%7C01%7CThomas.Graf%40swisscom.com%7C97b62c881a014607166e08d8eee59342%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637522017072074230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jI14Jw1em43U6PS5omPQPyLOwKA4XexXU3kVcwym1KM%3D&reserved=0 Please respond with your comments and thoughts on this draft. <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 We will conclude on April 7, 2021. Thanks, Tianran as co-chair _______________________________________________ OPSAWG mailing list [email protected] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=04%7C01%7CThomas.Graf%40swisscom.com%7C97b62c881a014607166e08d8eee59342%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637522017072074230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VB4J5I3%2FnDZ1szaV3mVBWiOgmmz59b%2B66Lbh8hmxusg%3D&reserved=0
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
