Hi Jeff, Thanks a lot for the review and feedback.
Please refer to my feedback to Ketan where elaborated more about why for label protocol migrations IE 46 is useful. * 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. I quote from the previous feedback to Ketan: I am not sure if you have seen the presentation in IETF 108 at OPSAWG and SPRING. https://www.ietf.org/proceedings/108/slides/slides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label Type identifier. There is an open ddts where vendor feasibility has been clarified. I do understand your point that not all the vendors are capable to implement IE 46. But that's not the point about the IPFIX IE registry. The IE registry enables that an IPFIX implementation can refer to the right code point. With RFC 5102 the decision has been made that MPLS Label Type identifier make sense and can be implemented. draft-tgraf-ipfix-mpls-sr-label-type just extends the IE 46 registry with the Segment Routing label protocol code points so when OSPFv2/OSPFv3/ISIS SR TLV is used, and IE 46 is supported, the IPFIX implementation can point to the right code point. I hope this makes sense. Looking forward to your feedback. Best Wishes Thomas From: Jeff Tantsura <jefftant.i...@gmail.com> Sent: Friday, August 14, 2020 8:54 PM To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com>; han...@gredler.at; Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org> Cc: lsr@ietf.org; SPRING WG <spr...@ietf.org> Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type 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<mailto: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<mailto:lsr-boun...@ietf.org>> On Behalf Of thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> Sent: 31 July 2020 20:52 To: han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto: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<mailto:han...@gredler.at>> Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Cc: lsr@ietf.org<mailto: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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8669&data=02%7C01%7CThomas.Graf%40swisscom.com%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340351625&sdata=ESqjEhY%2FAthUucGnGLX3TWPAb%2BmpJzZFlyLbJ52tq3I%3D&reserved=0> thanks, /hannes On 28.07.2020, at 10:11, thomas.g...@swisscom.com<mailto: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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340361562&sdata=JFcmLzj5dt7PM%2FFYD7FSFXWfmow6gR4l4Y3kmX%2FfW3g%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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340361562&sdata=GZDwtbZDSvo6CxSHwYUzZKqQ8bugVu9Xcf8ogCuXVU4%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 Lsr@ietf.org<mailto:Lsr@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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340371518&sdata=OWz24siAm5ZxCfzyGHaML%2Fm1VjeA3AqU9BPPiy2fD30%3D&reserved=0> _______________________________________________ spring mailing list spr...@ietf.org<mailto:spr...@ietf.org> https://www.ietf.org/mailman/listinfo/spring
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
