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

2020-09-01 Thread Thomas.Graf
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 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.

I am well aware on MPLS OAM. And indeed gives additional insights. There is a 
difference from a data plane viewpoint between packets traversing the MPLS 
domain vs. packets being generated within the MPLS domain though. Speaking from 
past maintenance windows, probing with MPLS OAM gave Swisscom limited insights 
into the MPLS data plane due to the amount of probes possible within a 1-2 
minute time frame and above mentioned constraints. IPFIX was mission critical 
in validating within minutes to understand if data plane changes was affecting 
the forwarding according the intend by using IE ingressInterface, 
egressInterface,  mplsTopLabelIPv4Address, mplsTopLabelStackSection and 
ForwardingStatus. This of course requires a big data infrastructure to make the 
data instantly accessible.

Best Wishes
Thomas

From: Ketan Talaulikar (ketant) 
Sent: Tuesday, August 18, 2020 4:23 PM
To: Graf Thomas, INI-NET-DCF ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [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> 
mailto:thomas.g...@swisscom.com>>
Sent: 18 August 2020 18:28
To: Ketan Talaulikar (ketant) 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 neces

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

2020-08-18 Thread Ketan Talaulikar (ketant)
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 
Sent: 18 August 2020 18:28
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 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) mailto:ket...@cisco.com>>
Sent: Monday, August 17, 2020 8:51 AM
To: Graf Thomas, INI-NET-DCF 
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> 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) 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 ext

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

2020-08-18 Thread Thomas.Graf
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) 
Sent: Monday, August 17, 2020 8:51 AM
To: Graf Thomas, INI-NET-DCF ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 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> 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) 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=02%7C01%7CThomas.Graf%40swisscom.com%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958595571=rHgl40uEad8j%2B%2BEPevE9%2FIjchXW6fb1gbAKVoJ%2BKLjo%3D=0>,
 describes the context.
[KT] Sure, so adding the SR Segments to IE46, one can check whether the t

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

2020-08-17 Thread Ketan Talaulikar (ketant)
Hi Thomas,

Please check inline below.

From: thomas.g...@swisscom.com 
Sent: 15 August 2020 11:31
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 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, 
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) mailto:ket...@cisco.com>>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF 
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 
iden

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

2020-08-16 Thread Tianran Zhou
Hi Thomas,

I think questions from both Ketan and Gyan on the IE usage are very important. 
The value should be described clearly in the draft. So that people now how to 
implement and use them.
Here your replay to Ketan on the mplsTopLabelType is clear to me. You want to 
account the traffic with different IGP distribution, to see if your network 
runs correct.
The SrSidType seems more complex.
"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."
Could you please make this use case more clear joint with IE89?
And this case want to justify the value of Adjacency SID. Is there any other 
use cases for accounting other sid types?

Thanks,
Tianran

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
thomas.g...@swisscom.com
Sent: Saturday, August 15, 2020 2:01 PM
To: ket...@cisco.com; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: Re: [OPSAWG] [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 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, 
describes the context.


?  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) mailto:ket...@cisco.com>>
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF 
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> 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) mailto:ket.

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

2020-08-15 Thread Thomas.Graf
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, 
describes the context.



  *   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) 
Sent: Saturday, August 15, 2020 7:09 AM
To: Graf Thomas, INI-NET-DCF ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 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> 
mailto:thomas.g...@swisscom.com>>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) 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/proceedin

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

2020-08-15 Thread Gyan Mishra
Ketan

>From an operations perspective at the end of the day the job of IPFIX is to
support the various data plane encapsulation types so that the flow graph
and fields flow data records can be constructed.

So here as long as you are able to capture the flow records, and record the
flows over the SR-MPLS data plane then to that end whatever is required to
meet that objective to construct capture and record all flows.

So that being said I think as long as the data plane encapsulation is
captured and supported for SR-MPLS label SID SRGB is supported then I think
the objective of the draft is solved.  I don’t think adding control plane
complexity into the flow records is necessary to accomplish the objective.

I see the point of being able to differentiate topmost label underlay of
MPLS label or TE from SR-MPLS.

That is as far as you need to go are my thoughts.

Kind Regards

Gyan


On Sat, Aug 15, 2020 at 1:09 AM Ketan Talaulikar (ketant)  wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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 
>
>
>
>
> *Sent:* 15 August 2020 09:40
>
>
> *To:* Ketan Talaulikar (ketant) ; han...@gredler.at
>
>
> *Cc:* lsr@ietf.org; spr...@ietf.org; 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
>
>
>
>
>
> 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 

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

2020-08-14 Thread Ketan Talaulikar (ketant)
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 
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) ; han...@gredler.at
Cc: lsr@ietf.org; spr...@ietf.org; 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

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) mailto:ket...@cisco.com>>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF 
mailto:thomas.g...@swisscom.com>>; 
han...@gredler.at<mailto:han...@gredler.at>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; SPRING WG 
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 

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

2020-08-14 Thread Thomas.Graf
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

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) 
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF ; han...@gredler.at
Cc: lsr@ietf.org; SPRING WG 
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 

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

2020-08-14 Thread Ketan Talaulikar (ketant)
< 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  On Behalf Of thomas.g...@swisscom.com
Sent: 31 July 2020 20:52
To: han...@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 mailto:han...@gredler.at>>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF 
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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801837133=NxcbyIGgKrjPmh5OZ5muKulfmzuM%2FlPvGo76WzrHpBM%3D=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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088=FhF3AgFGrHvqAYQ7Ec73TpqcQkeHzE9ZOMFGC8cuuDg%3D=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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088=QZYs1ZXZuBy5cFfvXmrLnu00%2FQF0TiJbBgWHC%2Ffteic%3D=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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088=Twb%2F%2BDFnQxElkufzSIVWszZ54cphIssBgO2vawPRYT8%3D=0>

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


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

2020-07-31 Thread Thomas.Graf
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

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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801837133=NxcbyIGgKrjPmh5OZ5muKulfmzuM%2FlPvGo76WzrHpBM%3D=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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088=FhF3AgFGrHvqAYQ7Ec73TpqcQkeHzE9ZOMFGC8cuuDg%3D=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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088=QZYs1ZXZuBy5cFfvXmrLnu00%2FQF0TiJbBgWHC%2Ffteic%3D=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=02%7C01%7CThomas.Graf%40swisscom.com%7Cf76df67b9faf4c04426908d83391629e%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637316046801847088=Twb%2F%2BDFnQxElkufzSIVWszZ54cphIssBgO2vawPRYT8%3D=0>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

2020-07-29 Thread Hannes Gredler
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 

thanks,

/hannes

> On 28.07.2020, at 10:11, 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 
> 
>  
> 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
>  
> 
>  
> 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 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr