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

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.ietf@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.com@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-bounces@ietf.org> *On Behalf Of* Thomas.Graf@swisscom.com
>
>
> *Sent:* 31 July 2020 20:52
>
>
> *To:* hannes@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 <hannes@gredler.at>
>
>
> *Sent:* Wednesday, July 29, 2020 9:31 AM
>
>
> *To:* Graf Thomas, INI-NET-DCF <Thomas.Graf@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
> <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.Graf@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
> 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%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
>
> Lsr@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