I agree with Kethan and Jeff. This draft is extending IPFIX defined in RFC 7011 7012 to support SR segments over IP export.
Since SR-MPLS reuses the MPLS data plane, why would the existing IPFIX RFCs also not support SR-MPLS without having to dig into IGP control plane extensions as from an IPFIX perspective the MPLS data plane is still the same and using the same 4 byte MPLS shim used by LDP. Gyan On Fri, Aug 14, 2020 at 2:54 PM Jeff Tantsura <jefftant.i...@gmail.com> wrote: > > > > > > > > > > > > > In general, I agree with what Ketan said, what’s important - it is the > value that is being used in forwarding, even if multiple control plane > entries exist, think about IGP migrations, or LDP to SR, where more than 1 > protocol could be distributing the labels/SIDs.. I’m not sure the FIB is > the right place to collect this data though, since most of meta-data has > already been lost (flattened FIB structures often contain bare minimum) and > really heavily depends on the implementation. > > > > > > > > Cheers, > > Jeff > > > > > > > On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) <ketant= > 40cisco....@dmarc.ietf.org>, wrote: > > > > > > > < also copying Spring WG for their review/inputs > > > > > > > Hi Thomas/All, > > > > > > I have reviewed the draft and would like to share a different perspective.. > > > > > > What or how much value be there on determining whether a SR Prefix SID was > signalled/programmed on a node via OSPFv2/OSPFv3/ISIS – what matters and is > more important is that it is a Prefix SID. Hardly any deployments would be > running multiple protocols and learning the same prefix from different > IGPs. IPFIX may be picking this information from a FIB in some > implementation where the protocol does not matter and this information is > not available therein. > > > > > > On some nodes, the same Prefix SID may be learnt via both BGP and IGP – > what would we use/show? > > > > > > I would recommend using SR Prefix SID, SR Adjacency SID, SR Binding SID, > SR BGP Peering SID and so on … for the MPLS Label Type. > > > > > > This also takes away the need for the second table that is being proposed > to a large extent. For that table proposal, it is very difficult and in > some cases not possible to different between Prefix and Node and Anycast > SID. Many of these types are control plane elements and we can be sure more > get added. Is there really much value in differentiation between say an > Adjacency SID and LAN Adjacency SID? > > > > > > Could we evaluate the implementation overhead and complexity of this level > of categorization/information in IPFIX against their value in flow analysis > to perhaps consider a middle ground? > > > > > > Thanks, > > > Ketan > > > > > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of* thomas.g...@swisscom.com > > > *Sent:* 31 July 2020 20:52 > > > *To:* han...@gredler.at > > > *Cc:* l...@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Hi Hannes, > > > > > > Thanks a lot for the feedback. Yes, makes completely sense. Will take it > for the next update... > > > > > > Best Wishes > > > Thomas > > > > > > > > > > > > > > > > > *From:* Hannes Gredler <han...@gredler.at> > > > *Sent:* Wednesday, July 29, 2020 9:31 AM > > > *To:* Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com> > > > *Cc:* l...@ietf.org > > > *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type > > > > > > > > > > Thomas, > > > > > > > > > > > > I have one comment/suggestion to Paragraph 4 (IANA Considerations). > > > > > > > > > > > > > > Please add also a code point for BGP Prefix-SID - it’s quite popular in DC > deployments. > > > > > > > https://tools.ietf.org/html/rfc8669 > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8669&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801837133&sdata=NxcbyIGgKrjPmh5OZ5muKulfmzuM%2FlPvGo76WzrHpBM%3D&reserved=0> > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > /hannes > > > > > > > > > > > > > > > > On 28.07.2020, at 10:11, thomas.g...@swisscom.com wrote: > > > > > > > > > > > > Dear lsr, > > > > > > > > > > > > > > I presented the following draft > > > > > > > > > > > > > > Export of MPLS Segment Routing Label Type Information in IP Flow > Information Export (IPFIX) > > > > > > > https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04 > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-tgraf-ipfix-mpls-sr-label-type-04&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088&sdata=FhF3AgFGrHvqAYQ7Ec73TpqcQkeHzE9ZOMFGC8cuuDg%3D&reserved=0> > > > > > > > > > > > > > > at the spring working group at IETF 108 yesterday > > > > > > > > https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-spring-ip-flow-information-export-ipfix-00.pdf&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088&sdata=QZYs1ZXZuBy5cFfvXmrLnu00%2FQF0TiJbBgWHC%2Ffteic%3D&reserved=0> > > > > > > > > > > > > > > and today at OPSAWG where I call for adoption. > > > > > > > > > > > > > > This draft adds additional segment routing code points for in the IANA > IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types > to gain further insights into the MPLS-SR forwarding-plane. > > > > > > > > > > > > > > I have been asked to not only gather feedback from spring and opsawg but > also from lsr and mpls working groups since these code points are related > to link state routing protocols and mpls data plane. > > > > > > > > > > > > > > I am looking forward to your feedback and input. > > > > > > > > > > > > > > Best Wishes > > > > > > > Thomas Graf > > > > > _______________________________________________ > > > Lsr mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7CThomas.Graf%40swisscom..com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088&sdata=Twb%2F%2BDFnQxElkufzSIVWszZ54cphIssBgO2vawPRYT8%3D&reserved=0> > > > > > > > > > > > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > l...@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
