Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Dear LSR Working Group, I have read the document. Swisscom is one of the operators deploying “IGP Unreachable Prefix Announcement” in their SRv6 network. The document addresses the challenge of fast convergance in a SRv6 aggregated IGP domain. I therfore support the adoption in LSR. Best

Re: [Lsr] [GROW] [Idr] IGP Monitoring Protocol

Dear Robert, I reviewed draft-raszuk-lsr-imp-00 and have some firsts comments and suggestions. First of all, speaking as a network operator who is using BMP to gain visibility into the BGP control-plane, seeing the real benefits in operation every day, I was looking very forward at IETF

Re: [Lsr] [spring] draft-tgraf-ipfix-mpls-sr-label-type

Hi Sergey, Thanks for the feedback. I am fully in line with your comment. * Maybe we should consider adding a generic type 'Segment Routing' w/o extra details if this might become an implementation challenge? I would be interested to understand what extra details you would include in

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan, Thanks a lot for the feedback. So far Sergey feedbacked in favor to keep IE46 and SrSidType being separate. Lets see which opinion others have on the list. * Also, from an operational perspective (looking holistically), we have LSP ping/trace tools specified for MPLS (including

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan, Thank you very much for the feedback. [KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types from RFC8402)? It's a simpler change to an existing element/field that makes it easier for

Re: [Lsr] [OPSAWG] draft-tgraf-ipfix-mpls-sr-label-type

Hi Gyan, Gyan> IPFIX has been traditionally been used for flow analysis and to that end all that was required is support of the data plane encapsulation. With your proposed SR support idea you are really transforming the IPFIX to be used for not just flow monitoring at that level solely, but

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan, * This helps identification of specific SR-MPLS segment types as well as differentiating them from LDP, RSVP-TE, etc. To be precise, the existing MPLS Label Type identifier differentiates from LDP, RSVP-TE. Not the new SrSidType IPFIX IE being proposed. * What value is

Re: [Lsr] [spring] draft-tgraf-ipfix-mpls-sr-label-type

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

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan, Thank you very much for the review and feedback. * 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

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 Sent: Wednesday, July 29, 2020 9:31 AM To: Graf Thomas, INI-NET-DCF Cc: lsr@ietf.org Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Lsr] draft-tgraf-ipfix-mpls-sr-label-type

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