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

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

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

[Gyan Mishra]

Hi Thomas

Just a thought to build on what Tianran mentioned.

It almost seems as if IPFIX taking on the role of BGP-LU / PCE  centralized
controller function to to create a SR graph of the topology.  We already
have all the SR topology data in the PCE for path instantiation and
steering.

Do we also really need the data replicated into IPFIX.

The PCE may also be able to do fault isolation and troubleshooting as it
has the topology of the entire SR domain.

Something to consider.  Also gathering flat bits and pieces of information
is  not the same as what is being fed by BGP-LS into the PCE.  So am
wondering what value this will provide with the flat construction of the
network graph.

Gyan

On Sun, Aug 16, 2020 at 11:05 PM Tianran Zhou 
wrote:

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

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

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

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

[Gyan Mishra]

Hi Thomas

Sorry for any misunderstanding.  I am well aware of the origins and history
behind IPFIX and Neflow and use with BGP monitoring.

I was not aware of IE 46 and how that was being leveraged to support SR IGP
extensions sid types.

After  reviewing your IPFIX slides related to IE 46 registry for
mplsTopLabelType and this drafts solution to extend the IE 46 registry with
SR and now requiring new IGP codepoints to be allocated.

You had given an example in the LDP interworking example or others that
with this new IGP codepoint in case of multiple control planes present such
as both LDP and SR that with IPFIX and with the new IGP codepoint
allocations for each IGP type that you can see the forwarding resulting FIB
entry.  I can see that as a benefit for monitoring telemetry

In-line  below addresses complexity of extending IE46 for SR support.

On Sun, Aug 16, 2020 at 3:13 AM  wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
>
> Gyan> SR-MPLS reuses the MPLS data plane so from that  perspective is the
> same but how it differs is with SR steering and MSD SID depth with SR-TE
> especially when strict ERO is defined with adjacency SID the label stack is
> expanded.
>

With MPLS we are label swapping however with SR you are label
stacking.  So let’s say you have an SR-TE path instantiated and using the
strict ERO path with adjacency SIDs defined,  would just the active label
being used in the forwarding plane be the one that IPFIX would be
monitoring versus the entire stack of labels.

> In theory it appears that the IPFIX machinery is in place with IE 46 to
> support SR as what you have proposed in the draft.
>

As far as vendor compatibility as long as they support IE 46
they should support SR-MPLS.

I don’t see any issues now as far as complexities to support as the we are
using existing machinery IPFIX IE 46 to extend for SR support.

I think getting feedback from LSR 

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

[Thomas.Graf]

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 
Sent: Saturday, August 15, 2020 9:26 PM
To: Graf Thomas, INI-NET-DCF 
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 
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,

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