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 now also to analyze and 
troubleshoot data plane forwarding.  That is a considerable departure I think 
from what IPFIX was intended.  I am not sure we want to add that layer of 
complexity into IPFIX.

Thomas> I have seen your feedback to Tarek and was puzzled about your remark 
about data plane encapsulation and IPFIX. I think you have a limited picture 
for what IPFIX has been intended and being used. I do not want to lecture, but 
it might be useful to go back to the origins of Netflow and IPFIX. At the 
beginning, the main reason for was to account traffic for BGP control-plane 
dimensions. Such as BGP peer AS, src and dst prefix attribute. These helped to 
account traffic in shared enviroments. Later also for datacenters. These was 
and is always in conjunction with the encapsulated header metrics of forwarded 
traffic and device dimensions such as ingress interface, egress interface, vrf 
id and vrf name. In order to have a proper picture about the forwarding plane, 
and to enable data correlation, key fields from other perspectives 
(control-plane, forwarding-plane, device) are necessary to enable data 
correlation with other protocols such as BMP and YANG.

Thomas> Going back to the initial conversation. Section 7.2 of RFC 5102
https://tools.ietf.org/html/rfc5102#section-7.2

   For ensuring extensibility of this information, IANA has created a
   new registry for MPLS label types and filled it with the initial list
   from the description Information Element #46, mplsTopLabelType.

Thomas> When IPFIX was specified, it has been defined in mind that other MPLS 
label protocols will be developed in the future. Which is the case with RFC 
8665, 8666, 8667 and 8669. All adding TLV's to carry segment routing SID's. In 
the presentation I gave, I showed one of many vendors implemented IE46 and 
showing the wrong value. Event though the label protocol was IS-IS SR TLV, the 
value shown was LDP. This is not acceptable. When new protocols are developed, 
we at IETF must ensure that they can be properly monitored. With IPFIX we have 
the proper protocol to do that. Even without modifications as section 4 in 
draft-ali-spring-sr-traffic-accounting mentioned: 
https://tools.ietf.org/html/draft-ali-spring-sr-traffic-accounting-01#section-4

Thomas> You have been referring to complexity. One of the key objectives of 
SR-MPLS was that it does not much change in the MPLS data plane. You need to 
explain on this WG how SR differs from other MPLS label protocols in terms of 
RIB/FIB. And then from there why an implementation would be difficult.. That's 
the discussion I am looking forward to.

Best wishes
Thomas

From: Gyan Mishra <hayabusa...@gmail.com>
Sent: Saturday, August 15, 2020 9:26 PM
To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com>
Cc: han...@gredler.at; ket...@cisco.com; lsr@ietf.org; ops...@ietf.org; 
spr...@ietf.org
Subject: Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type


Hi Thomas

Responses in-line

On Sat, Aug 15, 2020 at 2:02 AM 
<thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>> wrote:













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 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.



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%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758926165&sdata=wHBPYkw2k4iUxKMA9OZavfa7X8bO%2BrII7GQ7hhyo1K0%3D&reserved=0>,

describes the context.

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 now also to analyze and 
troubleshoot data plane forwarding.  That is a considerable departure I think 
from what IPFIX was intended.

I am not sure we want to add that layer of complexity into IPFIX.






  *   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... 
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.




>

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.



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%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758926165&sdata=aPDG5Npa0SXTJo06hspotby9nJ3diAINYePD6J8D%2BZ0%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%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758936119&sdata=Fsvq88N0tH7w2ksT50%2FtiB%2BjjSgMiYDczoL0LnrmP1Q%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%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758936119&sdata=zZ8aGGT4%2BhALWRePiWWnMSCN%2BwZOqhpjacfiyrQQyQ0%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%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758936119&sdata=msjazpFiGymlAxYRDGZkAk9JOdbsZsxCV5Pl1j7PUoM%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%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758946075&sdata=l0BxgILkPzTCw8VkgrGov6W22AQtX4Zs3Wm45QF37vo%3D&reserved=0>












_______________________________________________

OPSAWG mailing list

ops...@ietf.org<mailto:ops...@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758946075&sdata=qUj3CvJgp%2BWiHSyTmF5baL9P2OJ4HGl8cDJihIpV8eE%3D&reserved=0>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7CThomas.Graf%40swisscom.com%7C569e273bc05c4e6ea27b08d84151132d%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637331163758956033&sdata=Q1hTVdl%2FP5vcDFMFfbwkICQ%2F4uSqUX8ggxwPatqtGM0%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to