Hi Thomas, I've clarified a few points inline. Thank you, -- Sergey
From: thomas.g...@swisscom.com <thomas.g...@swisscom.com> Sent: Tuesday, September 1, 2020 12:55 AM To: Fomin, Sergey (Nokia - US/Mountain View) <sergey.fo...@nokia.com>; ketant=40cisco....@dmarc.ietf.org Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org Subject: RE: [spring] [Lsr] 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 this type. Potentially this could also apply to SRv6 (draft-patki-srv6-ipfix) [SF] On the contrary, here I meant without extra details. I think someone mentioned that it might be challenging to put a protocol identifier there, so in such cases one option would be is to allow generic "Segment Routing" label type (just to distinguish it from LDP/RSVP). But I'm not sure it is needed. Just an option. * this seems to be significantly more complex to implement and arguably IPFIX may not be the best way to collect this info. You probably are referring to draft-ietf-spring-sr-yang-22, collecting MPLS-SR operational state information. Correct? https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-22#section-8.3 [SF] I'm not pointing in any specific direction, I believe there are multiple ways to achieve this; each with its own set of pros and cons. E.g. an operator may decide to collect control plane information using telemetry (yang push or openconfig gnmi or anything else) and any type of models (IETF, openconfig, vendor's proprietary), or go with BGP-LS, or put a sensor/NMS into an IGP domain, etc; and do a correlation with IPFIX statistics using an NMS at a later stage. Or do a simple data enrichment in kafka or whatever pipeline they use for collecting, processing & storing the data. [SF] But I'm not against SrSidType in the current form. As you know, TI-LFA pushing Adj-SID's in sub seconds, to take an example. From a vendor perspective, do you think it is technically feasible to get the label number and SID type through YANG push and label number and packet details from IPFIX within a time frame that the data can be correlated outside the router to understand that TI-LFA affected the mpls data plane. I fear from past experience in data-collection, that this is quiet a challenge. But I do also understand the constraints of IPFIX. [SF] Could you elaborate a little bit on this or correct me if I'm missing something? TI-LFA is a local action of re-programming the data plane, which you'll be able to see in IPFIX (assuming enough amount traffic & sampling rate). Next you only need to correlate a specific label to its type and the label itself has relatively long lifespan (or could be static, depending on the node config). I don't see how getting srsidtype via IPFIX or another method changes anything here. Though you won't be able to automatically assume whether it was a TI-LFA action or some other traffic engineering mechanism (if you have mix of both in a network), and not any TI-LFA actions results in adj-sid push. Best Wishes Thomas From: Fomin, Sergey (Nokia - US/Mountain View) <sergey.fo...@nokia.com> Sent: Monday, August 24, 2020 4:08 AM To: Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org>; Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com> Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org Subject: RE: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Ketan, all, While I tend to agree with Ketan that, in principle, specific control plane protocol name might not be the most useful bit of info, I would argue that it still makes more sense to keep IE46 in this format instead of replacing it with srsidtype. I.e. treat IE46 as in 'control plane protocol that is the source/owner of a particular label in LIB/LFIB'. Maybe we should consider adding a generic type 'Segment Routing' w/o extra details if this might become an implementation challenge? I'm in favor of keeping SrSidType as a separate entity -> this seems to be significantly more complex to implement and arguably IPFIX may not be the best way to collect this info. -- Sergey From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Ketan Talaulikar (ketant) Sent: Tuesday, August 18, 2020 7:23 AM To: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org> Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Thanks for your response. Let us also wait for inputs from others in the WGs. One small bit. [KT] By giving different types for OSPF and ISIS, is the intention to troubleshoot routing preference selection (done based on "admin distance" between protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over another from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option. KT2> The proposal to extend IE46 will cover the "sr-prefer" scenario and indicate whether the forwarding is happening with SR or LDP label. IMHO OSPF SR vs ISIS SR is perhaps not as useful? Also, from an operational perspective (looking holistically), we have LSP ping/trace tools specified for MPLS (including SR segments/labels) to verify/validate consistency between forwarding and control plane to determine which protocol/label is being used and lot's more details. Thanks, Ketan From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Sent: 18 August 2020 18:28 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org> Subject: 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 routers, collectors and analysers? Thomas> I am open to this approach to change IE46 to include segment types for RFC8402. I understand your concern to add additional fields. I would appreciate feedback from the wg if that is the path we like to go. [KT] By giving different types for OSPF and ISIS, is the intention to troubleshoot routing preference selection (done based on "admin distance" between protocol selection in RIB)? Thomas> "admin distance" is one reason why one path is considered over another from two different protocols. In case of LDP vs IS-IS, in IOS-XR as an examples, it is "sr-prefer" configuration option. [KT] From the document, I believe we are still talking only about the top of the stack label ... Thomas> Correct [KT] My point is why do we need to introduce another ElementID and why not use the existing Type 46 as suggested above? Thomas> See feedback above. [KT] To be clear, I am not talking from the POV of a specific implementation. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nuances into IPFIX since they require all that additional context/information to be made available at the "layer" (or component) from where IPFIX picks this info (traditionally from the "FIB"). This added information should have a strong enough justification of benefit - e.g. How does difference between Adj SID and LAN Adj SID matter? How relevant it is to determine if the SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount and sufficient information that is necessary for flow analysis. We need to note that there may be many more/other sources for "off-box enrichment" of flow information collected and perhaps not everything needs to be determined and reported by routers. Thomas> Absolutely. I fully agree on your feedback. We need to have the minimum possible in order to have a clear view about the MPL-SR forwarding. Since IPFIX using UDP for transport, without the possibility of fragmentation, we need to be careful as well not to add many more dimension's/fields. Best Wishes Thomas From: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>> Sent: Monday, August 17, 2020 8:51 AM To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org> Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, Please check inline below. From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Sent: 15 August 2020 11:31 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org> Subject: 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. [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 routers, collectors and analysers? * What value is provided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS? It is important to distinguish between intend and result. [KT] By giving different types for OSPF and ISIS, is the intention to troubleshoot routing preference selection (done based on "admin distance" between protocol selection in RIB)? If you migrate from one label distribution protocol to another, a network operator want's to understand if the data plane is still forwarding packets with the label distribution protocol which needs to be removed or not. IE46 enables that by looking at the result of the forwarded traffic and not at the intend. RFC 8661 section 3, https://tools.ietf.org/html/rfc8661#section-3<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8661%23section-3&data=02%7C01%7CThomas.Graf%40swisscom.com%7C0647afbf9ac64ead009f08d847d2945e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637338317042782523&sdata=iL1Qa%2FDkJ6lI3ww3nlzoK9L2yxcVBWyiNs2frbilVq8%3D&reserved=0>, describes the context. [KT] Sure, so adding the SR Segments to IE46, one can check whether the traffic forwarding is happening using LDP or SR labels at any link in the network.. * What value is provided for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID? Quote from RFC8402. "Segment Routing (SR) leverages the source routing paradigm". Means that not the routing protocol does all the forwarding decisions, the node can change the forwarding by pushing additional labels.. [KT] From the document, I believe we are still talking only about the top of the stack label ... With IPFIX SrSidType we are able to cover this dimension in IPFIX. Enabling to analyze the result of this decision. The example with " Adjacency SID or a LAN Adjacency SID" is not very useful because the difference of the two is the topology among the adjacency. If you compare " Adjacency SID with Prefix SID", that makes much more sense. Since it describes that a particular adjacency is chosen to forward the packet instead of a prefix. If IE 89, ForwardingStatus is drop, we understand that result of that decision lead to the drop and this enables to narrow down forwarding issues in segment routing networks more efficiently and quickly. [KT] My point is why do we need to introduce another ElementID and why not use the existing Type 46 as suggested above? * am asking for WG to weigh the implementation complexities For the WG and me, I would be important if you can describe more detailed what you mean with implementation complexities. I would like to have a better understanding where your fear is coming from. I would appreciate if you could differentiate between MPLS Label Type identifier, IE46, from which label protocol the label was coming from and SrSidType which SID type was used. [KT] To be clear, I am not talking from the POV of a specific implementation. Let me summarize my feedback and perspective: * Carefully consider the addition of more control plane elements and nuances into IPFIX since they require all that additional context/information to be made available at the "layer" (or component) from where IPFIX picks this info (traditionally from the "FIB"). This added information should have a strong enough justification of benefit - e.g. How does difference between Adj SID and LAN Adj SID matter? How relevant it is to determine if the SR signaling protocol is OSPF or ISIS? * Try to add/extend existing elements/fields with just the right amount and sufficient information that is necessary for flow analysis. We need to note that there may be many more/other sources for "off-box enrichment" of flow information collected and perhaps not everything needs to be determined and reported by routers. Thanks, Ketan Best wishes Thomas From: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>> Sent: Saturday, August 15, 2020 7:09 AM To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org> Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type Hi Thomas, I should have been more clear in my email. The proposal/suggestion is to add the following to the IPFIX MPLS Label type identifier registry: * SR Prefix SID * SR Adjacency SID * SR Binding SID * SR BGP Peering SID * ... and so on This helps identification of specific SR-MPLS segment types as well as differentiating them from LDP, RSVP-TE, etc. And my questions were: 1. What value is provided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS? 2. What value is provided for IPFIX analysis if it was a Adjacency SID or a LAN Adjacency SID? I am asking for WG to weigh the implementation complexities and overheads with the proposed details of SR-MPLS segments in IPFIX against the benefit (if any) that they provide for the flow analysis and monitoring. Thanks, Ketan From: thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> Sent: 15 August 2020 09:40 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; spr...@ietf.org<mailto:spr...@ietf.org>; ops...@ietf.org<mailto:ops...@ietf.org> Subject: 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 running multiple protocols and learning the same prefix from different IGPs. As Jeff already pointed out. Multiple IGP labelling protocols are used in networks when migrations are ongoing. Usually in a life cycle. Migrating from LDP to OSPFv2/OSPFv3/ISIS SR TLV. This is/was also the case at Swisscom when we first discovered this shortcoming in vendor implementations. The key point here, with these additional IPFIX MPLS Label Type identifiers we enable the possibility to verify the label protocol migration without taking the label value into the consideration. * 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. 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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-opsawg-export-of-mpls-sr-label-type-information-in-ipfix-00.pdf&data=02%7C01%7CThomas.Graf%40swisscom.com%7C0647afbf9ac64ead009f08d847d2945e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637338317042787502&sdata=Y6%2Bxg0NN%2B2qYCCTNHlSowB6MemBkXvKWrtu2ttNEcws%3D&reserved=0> 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. Ping me off the list when you like to have more details. 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. * On some nodes, the same Prefix SID may be learnt via both BGP and IGP - what would we use/show? In this case the IE 46 shows the label protocol which was used to program the FIB. * 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. I fully agree. As a network operator its still hard to understand the architecture and constraints within a router. When monitoring capabilities are discussed at IETF, this is the usual topic. What is possible, what make sense. By purpose, all available SID types are listed in the draft. This with the aim to start the discussion in the working groups what is possible what makes sense. I would be interested to get your and also Jeff's feedback. In above mentioned slides I described how TI-LFA application would benefit of visibility in the FIB by showing where Adj-SID was used. This should be a simple example why it make sense not only to look at which label protocol was used to forward a particular packet, but also which SID type to further understand the intend why this label is being pushed. I hope this makes all sense. Looking forward for reply. Best wishes Thomas From: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>> Sent: Friday, August 14, 2020 7:35 PM To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>; han...@gredler.at<mailto:han...@gredler.at> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG <spr...@ietf.org<mailto:spr...@ietf.org>> Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type < 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%7C0647afbf9ac64ead009f08d847d2945e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637338317042792477&sdata=fo4NJD1nYDHqHWrgVMvMTLG42TLWeEnEi8jdLDBP4WQ%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%7C0647afbf9ac64ead009f08d847d2945e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637338317042797456&sdata=0E%2FLFOaQZRg3CYdu6XUsBQRpJShIQkk%2BMq6pHJ%2BVp3M%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%7C0647afbf9ac64ead009f08d847d2945e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637338317042802435&sdata=18JiraxaujtFXtiuUPwG3dZutMRlBMBOhxpQ%2F7WfNSc%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%7C0647afbf9ac64ead009f08d847d2945e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637338317042807411&sdata=E4IYcbnhVjO7teyepOmTUqSCyAxV%2FFiqiJzn2wA94EE%3D&reserved=0>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
