results in adj-sid push.
Best Wishes
Thomas
From: Fomin, Sergey (Nokia - US/Mountain View)
Sent: Monday, August 24, 2020 4:08 AM
To: Ketan Talaulikar (ketant) ; Graf Thomas,
INI-NET-DCF
Cc: l...@ietf.org; spring@ietf.org; ops...@ietf.org
Subject: RE: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-typ
understand the constraints of IPFIX.
Best Wishes
Thomas
From: Fomin, Sergey (Nokia - US/Mountain View)
Sent: Monday, August 24, 2020 4:08 AM
To: Ketan Talaulikar (ketant) ; Graf Thomas,
INI-NET-DCF
Cc: l...@ietf.org; spring@ietf.org; ops...@ietf.org
Subject: RE: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr
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 S
tf.org; spring@ietf.org; ops...@ietf.org
Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
Hi Thomas,
Thanks for your response. Let us also wait for inputs from others in the WGs.
One small bit.
[KT] By giving different types for OSPF and ISIS, is the intention to
troubleshoot routing pref
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> "a
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 r
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: l...@ietf.org; spring@ietf.org; ops...@ietf.org
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
Hi Ketan,
* This helps identificati
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
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 prov
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
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 spec
f Tantsura
Sent: Friday, August 14, 2020 8:54 PM
To: Graf Thomas, INI-NET-DCF ; han...@gredler.at;
Ketan Talaulikar (ketant)
Cc: l...@ietf.org; SPRING WG
Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
In general, I agree with what Ketan said, what's important - it is the
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
ru
I agree with Kethan and Jeff.
This draft is extending IPFIX defined in RFC 7011 7012 to support SR
segments over IP export.
Since SR-MPLS reuses the MPLS data plane, why would the existing IPFIX RFCs
also not support SR-MPLS without having to dig into IGP control plane
extensions as from an IPFIX
In general, I agree with what Ketan said, what’s important - it is the value
that is being used in forwarding, even if multiple control plane entries exist,
think about IGP migrations, or LDP to SR, where more than 1 protocol could be
distributing the labels/SIDs. I’m not sure the FIB is the rig
< 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
mo
16 matches
Mail list logo
