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: lsr@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: lsr@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 > > 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 > > > > 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 > > > > 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 > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > spring mailing list > spr...@ietf.org > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
