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

From: <[email-masked]>
Date: Sat, 15 Aug 2020 04:10:17 +0000

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) <[email-masked]>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF <[email-masked]>; [email-masked]
Cc: [email-masked]; SPRING WG <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 31 July 2020 20:52
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200615130&sdata=Fp1WH4uMm3oxp8GGzt3IfexyzHzflHA3FC5QE5DixBk%3D&reserved=0>

thanks,

/hannes

On 28.07.2020, at 10:11, [email-masked]<mailto:[email-masked]> 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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087&sdata=q9GCxkzGIMx9p4WsXwITL4t1GMaP6dj6H4gu7hJAROY%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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087&sdata=%2FNT6dZ%2F6vsv69oW3g3iirmzygDI4UPn7a2VyGkwYCYo%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
[email-masked]<mailto:[email-masked]>
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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200635044&sdata=TsgdeCEH3Y5f%2BeHrPpANrK%2Bl5qT2TfSre2rPJZvoOuQ%3D&reserved=0>

---

From: <[email-masked]>
Date: Sat, 15 Aug 2020 04:16:25 +0000

Hi Jeff,

Thanks a lot for the review and feedback.

Please refer to my feedback to Ketan where elaborated more about why for label protocol migrations IE 46 is useful.

  *   I'm not sure the FIB is the right place to collect this data though, since most of meta-data has already been lost (flattened FIB structures often contain bare minimum) and really heavily depends on the implementation.

I quote from the previous feedback to Ketan:

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.

I hope this makes sense. Looking forward to your feedback.

Best Wishes
Thomas

From: Jeff Tantsura <[email-masked]>
Sent: Friday, August 14, 2020 8:54 PM
To: Graf Thomas, INI-NET-DCF <[email-masked]>; [email-masked]; Ketan Talaulikar (ketant) <ketant=[email-masked]>
Cc: [email-masked]; SPRING WG <[email-masked]>
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 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 right place to collect this data though, since most of meta-data has already been lost (flattened FIB structures often contain bare minimum) and really heavily depends on the implementation.

Cheers,
Jeff
On Aug 14, 2020, 10:36 AM -0700, Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>, wrote:

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Thanks a lot for the feedback. Yes, makes completely sense. Will take it for the next update...

Best Wishes
Thomas

Thomas,

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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340351625&sdata=ESqjEhY%2FAthUucGnGLX3TWPAb%2BmpJzZFlyLbJ52tq3I%3D&reserved=0>

thanks,

/hannes

Dear lsr,

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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340361562&sdata=JFcmLzj5dt7PM%2FFYD7FSFXWfmow6gR4l4Y3kmX%2FfW3g%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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340361562&sdata=GZDwtbZDSvo6CxSHwYUzZKqQ8bugVu9Xcf8ogCuXVU4%3D&reserved=0>

Best Wishes
Thomas Graf
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
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%7C2720ced2eb7740f2f7d808d8408363dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330280340371518&sdata=OWz24siAm5ZxCfzyGHaML%2Fm1VjeA3AqU9BPPiy2fD30%3D&reserved=0>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 15 Aug 2020 05:08:55 +0000

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: [email-masked] <[email-masked]>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

Best wishes
Thomas

From: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 14, 2020 7:35 PM
To: Graf Thomas, INI-NET-DCF <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

thanks,

/hannes

Dear lsr,

Best Wishes
Thomas Graf

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Aug 2020 02:00:56 -0400

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) <ketant=
[email-masked]> wrote:

>    - 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:
>
>
>
>
>
> 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:* [email-masked] <[email-masked]>
>
>
>
>
> *Sent:* 15 August 2020 09:40
>
>
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]
>
>
> *Cc:* [email-masked]; [email-masked]; [email-masked]
>
>
> *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
> Hi Ketan,
>
>
>
>
>
>    - 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.
>
>
>
>
>
>
> 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?
>
>
>
>
>
>
>    -
>    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.
>
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant) <[email-masked]>
>
>
>
>
> *Sent:* Friday, August 14, 2020 7:35 PM
>
>
> *To:* Graf Thomas, INI-NET-DCF <[email-masked]>;
>
> [email-masked]
>
>
> *Cc:* [email-masked]; SPRING WG <[email-masked]>
>
>
> *Subject:* RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
> 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 <[email-masked]>
>
> *On Behalf Of [email-masked]
>
>
> *Sent:* 31 July 2020 20:52
>
>
> *To:* [email-masked]
>
>
> *Cc:* [email-masked]
>
>
> *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
> Hi Hannes,
>
>
>
>
>
> *From:* Hannes Gredler <[email-masked]>
>
>
>
>
> *Sent:* Wednesday, July 29, 2020 9:31 AM
>
>
> *To:* Graf Thomas, INI-NET-DCF <[email-masked]>
>
>
> *Cc:* [email-masked]
>
>
> *Subject:* Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
> Thomas,
>
>
>
>
>
>
>
>
>
>
>
> 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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200615130&sdata=Fp1WH4uMm3oxp8GGzt3IfexyzHzflHA3FC5QE5DixBk%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thanks,
>
>
>
>
>
>
>
>
>
>
>
>
>
> /hannes
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 28.07.2020, at 10:11,
>
> [email-masked] wrote:
>
>
>
>
>
>
>
>
>
>
>
> Dear lsr,
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087&sdata=q9GCxkzGIMx9p4WsXwITL4t1GMaP6dj6H4gu7hJAROY%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087&sdata=%2FNT6dZ%2F6vsv69oW3g3iirmzygDI4UPn7a2VyGkwYCYo%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
> [email-masked]
> 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%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200635044&sdata=TsgdeCEH3Y5f%2BeHrPpANrK%2Bl5qT2TfSre2rPJZvoOuQ%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: <[email-masked]>
Date: Sat, 15 Aug 2020 06:01:29 +0000

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

Sent: Saturday, August 15, 2020 7:09 AM

Hi Thomas,

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

And my questions were:

Thanks,
Ketan

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: 15 August 2020 09:40
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Ketan,

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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465806010&sdata=rYZxsfoyTc2ZAqbqf2DLfiBhiRQyNcfGS8tvzeTGda0%3D&reserved=0>

Best wishes
Thomas

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465806010&sdata=WiW65MqkVXM5BOqJ7VxFPj14s9RynoBTjgzU%2Fhu%2FKOk%3D&reserved=0>

thanks,

/hannes

Dear lsr,

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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465815966&sdata=1DIvkRCu5tKMVSooUnsF%2B5R1h12rVOkbYyYzqvKSgV4%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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465815966&sdata=OM8BhFC%2FQJL3h%2FjqQPULt1c5SBTaz6yp%2Bj6i0QOjJJQ%3D&reserved=0>

Best Wishes
Thomas Graf
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465825923&sdata=PHRjGhYIP%2FLnBUvtjdbv%2FweQzspjf640vWDAovlS5Is%3D&reserved=0>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 15 Aug 2020 15:25:59 -0400

Hi Thomas

Responses in-line

On Sat, Aug 15, 2020 at 2:02 AM <[email-masked]> 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?

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 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
>
>
>
>
>
>
>
>
>
> *Sent:* Saturday, August 15, 2020 7:09 AM
>
>
> (if any) that they provide for the
>
> flow analysis and monitoring.
>
>
>
>
>
> Thanks,
>
>
> Ketan
>
>
>
>
>
>
>
>
>
> *From:*
>
> [email-masked] <[email-masked]>
>
>
>
>
> *To:* Ketan Talaulikar (ketant) <[email-masked]>;
>
> [email-masked]
>
>
> *Cc:* [email-masked];
>
> [email-masked]; [email-masked]
>
>
>    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.
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>    implementation where the protocol does not matter and this information
>
>    is not available therein.
>
>
>
>
>
>
> <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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465806010&sdata=rYZxsfoyTc2ZAqbqf2DLfiBhiRQyNcfGS8tvzeTGda0%3D&reserved=0>
>
>
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>    these types are control plane elements and we can
>
>    be sure more get added.
>
>
>
>
>
>
> 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.
>
>
>
>
>
> 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?
>
>
>
>
>
> 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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465806010&sdata=WiW65MqkVXM5BOqJ7VxFPj14s9RynoBTjgzU%2Fhu%2FKOk%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thanks,
>
>
>
>
>
>
>
>
>
>
>
>
>
> /hannes
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 28.07.2020, at 10:11,
>
> <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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465815966&sdata=1DIvkRCu5tKMVSooUnsF%2B5R1h12rVOkbYyYzqvKSgV4%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465815966&sdata=OM8BhFC%2FQJL3h%2FjqQPULt1c5SBTaz6yp%2Bj6i0QOjJJQ%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7CThomas.Graf%40swisscom.com%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465825923&sdata=PHRjGhYIP%2FLnBUvtjdbv%2FweQzspjf640vWDAovlS5Is%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>

-- 

*Gyan Mishra*

---

From: <[email-masked]>
Date: Sun, 16 Aug 2020 07:13:25 +0000

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 <[email-masked]>
Sent: Saturday, August 15, 2020 9:26 PM
To: Graf Thomas, INI-NET-DCF <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ketan,

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.

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.

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

Hi Thomas,

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

And my questions were:

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

Thanks,

Ketan

From:

[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>;

[email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Ketan,

  *   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

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>

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.

  *

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

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.

Best wishes

Thomas

To: Graf Thomas, INI-NET-DCF <[email-masked]<mailto:[email-masked]>>;

[email-masked]<mailto:[email-masked]>

Hi Thomas/All,

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.

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?

Thanks,

Ketan

From: Lsr <[email-masked]<mailto:[email-masked]>>

On Behalf Of [email-masked]<mailto:[email-masked]>

Sent: 31 July 2020 20:52

Hi Hannes,

Best Wishes

Thomas

Thomas,

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,

[email-masked]<mailto:[email-masked]> wrote:

Dear lsr,

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>

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>

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

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

Best Wishes

Thomas Graf

Lsr mailing list

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

[email-masked]<mailto:[email-masked]>

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 16 Aug 2020 16:39:31 -0400

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 <[email-masked]> wrote:

> 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> 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 is critical on their thoughts on
complexity and caveats with getting the codepoints assigned.

What about IPFIX  SRv6 support?

Comment on Section 2

   A typical use case scenario is to monitor MPLS control plane
   migrations from LDP to IS-IS or OSPF.  By looking at the MPLS label
   value itself, it is not always clear as to which label protocol it
   belongs, since they could potentially share the same label allocation
   range.  This is the case for IGP-Adjacency SID's and LDP as an
   example.

SR SRGB label range is different then LDP label range.

>
>
> Best wishes
>
>
> Thomas
>
>
>
>
>
> *From:* Gyan Mishra <[email-masked]>
>
>
>
>
> *Sent:* Saturday, August 15, 2020 9:26 PM
>
>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>
>
> *Subject:* Re: [OPSAWG] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Thomas
>
>
>
>
>
>
>
>
>
>
>
>
>
> Responses in-line
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> LDP, RSVP-TE.
> Not the new SrSidType IPFIX IE being proposed.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>    -
>
>    What value is provided for IPFIX analysis if the SR Prefix SID was
> operator
> want's to understand if the data plane is still forwarding
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>    What value is provided for IPFIX analysis if it was a Adjacency SID or
>    a LAN Adjacency SID?
>
>
>
>
>
>
>
>
>
>
>
>
> paradigm".
> Means that not the routing protocol does all the forwarding
>
>
>
>
>
> what you mean
> with
>    SR Prefix SID
>    SR Adjacency SID
>    SR Binding SID
>    SR BGP Peering SID
>    … and so on
>    1.
>    What value is provided for IPFIX analysis if the SR Prefix SID was
>    2.
>    What value is provided for IPFIX analysis if it was a Adjacency SID or
>    a LAN Adjacency SID?
>
>
>
>
>
>
>
>
>
>
>
>
> (if any)
> that they provide for the
>
>
>
>
>
>    What or how much value be there on determining whether a SR Prefix SID
>    was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS
>
>
>
>
>
> networks when migrations
> are ongoing. Usually in a life cycle. Migrating from
>
>
>
>
>
>    IPFIX may be picking this information from a FIB in some
> <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>
>
>
>
>
>
>
>
>
>
>
>
> Type identifier. There
> is an open ddts where vendor feasibility has been clarified.
>
>
>
>
>
> implement IE 46.
> But that’s not the point about the IPFIX IE registry.
>
>
>
>
>
>    On some nodes, the same Prefix SID may be learnt via both BGP and IGP
>    – what would we use/show?
>
>
>
>
>
>
>
>
>
>
>
>
> architecture
> and constraints within a router. When monitoring capabilities
>
>
>
>
>
> of visibility
> in the FIB by showing where Adj-SID was used. This
>
>
>
>
>
> more important
> is that it is a
> some cases not
> possible to different
> to perhaps
> consider a middle ground?
>
>
>
>
>
>
>
>
>
>
>
> Thanks,
>
>
>
>
>
> Ketan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks a lot for the feedback. Yes, makes completely sense. Will take it
> for the
>
> next update...
>
>
>
>
>
>
>
>
>
>
>
> Best Wishes
>
>
>
>
>
> Thomas
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <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,
>
>
>
>
>
>
>
> <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>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <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>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> IPFIX registry for IS-IS,
>
> OPSFv2 and OPSF v3 and segment routing SID types to gain
>
>
>
>
>
> also from lsr and mpls
> working groups since these code points are related to link
>
>
>
>
>
> <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>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <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>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <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-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --

*Gyan Mishra*

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 17 Aug 2020 03:04:47 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, August 15, 2020 2:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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.

?  What value is provided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?

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

Best wishes
Thomas

Hi Thomas,

-          ... and so on

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?

Thanks,
Ketan

Hi Ketan,

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

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

Best wishes
Thomas

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

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%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465806010&sdata=WiW65MqkVXM5BOqJ7VxFPj14s9RynoBTjgzU%2Fhu%2FKOk%3D&reserved=0>

thanks,

/hannes

Dear lsr,

Best Wishes
Thomas Graf

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 17 Aug 2020 02:19:57 -0400

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 <[email-masked]>
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.
>
>
> “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.”
>
>
> 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:[email-masked]]
>
> *On Behalf [email-masked]
>
>
> *Sent:* Saturday, August 15, 2020 2:01 PM
>
>
> *To:* [email-masked]; [email-masked]
>
>
> What value is provided for IPFIX analysis if the SR Prefix SID was being
> signalled via OSPF or ISIS?
>
>
>
>
>
>
> 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,
>
> What value is provided for IPFIX analysis if it was a Adjacency SID or a
> LAN Adjacency SID?
>
>
>
>
>
> 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.
>
>
>
>
>
> Ø
>
> coming from and SrSidType which SID type was used..
>
>
>
>
>
>
> Best wishes
>
>
> Thomas
>
>
>
>
>
>
>
>
>
> 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?
>
>
>
>
>
> 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.
>
>
>
>
>
> these types are control plane elements
>
> and we can be sure more get added.
>
>
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
>
>
>
> for the next update...
> to gain further insights
> into the MPLS-SR forwarding-plane.
>
>
>
>
>
>
>
>
>
>
>
>
>
> to link state routing
> protocols and mpls data plane.
>
>
>
>
>
>
>
>
>
>
>
>
>

*Gyan Mishra*

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 17 Aug 2020 06:51:23 +0000

Hi Thomas,

Please check inline below.

Sent: 15 August 2020 11:31

Hi Ketan,

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?

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.

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

Hi Thomas,

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

And my questions were:

Thanks,
Ketan

Hi Ketan,

Best wishes
Thomas

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

thanks,

/hannes

Dear lsr,

Best Wishes
Thomas Graf

---

From: <[email-masked]>
Date: Tue, 18 Aug 2020 12:46:57 +0000

Hi Gyan,

Thank you very much. Perfect we are in line. All ack on your comments.

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

Correct. IE46 is only referencing the top label. We do not know these additional dimensions for the other labels in the label stack. Same as all other IE below, just as reference.

46        mplsTopLabelType
47        mplsTopLabelIPv4Address
70        mplsTopLabelStackSection
91        mplsTopLabelPrefixLength
140       mplsTopLabelIPv6Address
200       mplsTopLabelTTL
203       mplsTopLabelExp

  *   What about IPFIX  SRv6 support?

Good point. draft-patki-srv6-ipfix-00 (https://tools.ietf.org/html/draft-patki-srv6-ipfix-00) is covering the IPv6 data plane in IPFIX. SrSidType in draft-tgraf-ipfix-mpls-sr-label-type relates to MPLS-SR and SRv6, IE46 only to MPLS-SR.

Best Wishes
Thomas

Sent: Sunday, August 16, 2020 10:40 PM

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

On Sun, Aug 16, 2020 at 3:13 AM <[email-masked]<mailto:[email-masked]>> 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.

https://tools.ietf.org/html/rfc5102#section-7.2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5102%23section-7.2&data=02%7C01%7CThomas.Graf%40swisscom.com%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894565532&sdata=0ZmtjaUiYX6IitB5ENQnQTmHa2ff8jEybu2uvbbOnhg%3D&reserved=0>

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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ali-spring-sr-traffic-accounting-01%23section-4&data=02%7C01%7CThomas.Graf%40swisscom.com%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894565532&sdata=al%2FAn5tWLYadyWEHXDTrxoLYIjjDNpnElGeUcf5D82M%3D&reserved=0>

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 is critical on their thoughts on complexity and caveats with getting the codepoints assigned.

Comment on Section 2

Best wishes

Thomas

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Thomas

Responses in-line

Hi Ketan,

  *

To be precise, the existing MPLS Label Type identifier differentiates from LDP, RSVP-TE.

  *

What value is provided for IPFIX analysis if the SR Prefix SID was being signalled via OSPF or ISIS?

If you migrate from one label distribution protocol to another, a network operator

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894575491&sdata=H1SkAcsjcQGOzoXQNCLL4FYqszkw%2FD8PUxFsmm3s08M%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.

  *

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

For the WG and me, I would be important if you can describe more detailed what you mean

with

Best wishes

Thomas

Hi Thomas,

  *

SR Prefix SID
  *

SR Adjacency SID
  *

SR Binding SID
  *

SR BGP Peering SID
  *

... and so on

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)

Thanks,

Ketan

From:

Hi Ketan,

  *

What or how much value be there on determining whether a SR Prefix SID was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS

As Jeff already pointed out. Multiple IGP labelling protocols are used  in networks when migrations

  *

IPFIX may be picking this information from a FIB in some implementation where the protocol does not matter and this information

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894575491&sdata=KiNpnuG0%2B%2BwsLcK92lwaIHf1DzQEU0QdF6uU3KjyEzI%3D&reserved=0>

Slide 2 shows Cisco as example vendor which implemented IE 46, MPLS Label Type identifier. There

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.

code point.

  *

  *

be sure more get added.

I fully agree. As a network operator its still hard to understand the architecture

In above mentioned slides I described how TI-LFA application would benefit of visibility

Best wishes

Thomas

Hi Thomas/All,

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

available therein.

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

Could we evaluate the implementation overhead and complexity of this level of categorization/information in IPFIX against their value in flow analysis to perhaps

Thanks,

Ketan

Sent: 31 July 2020 20:52

Hi Hannes,

Thanks a lot for the feedback. Yes, makes completely sense. Will take it for the

next update...

Best Wishes

Thomas

Thomas,

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894585445&sdata=RSQfUDhZODLkiHQW1oAe3XE46DxPpNzJx3Hadir9%2F44%3D&reserved=0>

thanks,

/hannes

On 28.07.2020, at 10:11,

Dear lsr,

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894585445&sdata=NRvPTvxaDXGyKQv6yHqq4fmJAgNngC8JcAsUcNZhiLE%3D&reserved=0>

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894595406&sdata=9rMXDuB2WnQMV9ZyzSnoFAsk8zN5k%2BJdAvUtcbVHoQg%3D&reserved=0>

This draft adds additional segment routing code points for in the IANA IPFIX registry for IS-IS,

I have been asked to not only gather feedback from spring and opsawg but also from lsr and mpls

Best Wishes

Thomas Graf

Lsr mailing list

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894595406&sdata=7qJbaz0tefDgrw1yubQrnpZh2DIiQdIInyVhVBIpPaI%3D&reserved=0>

OPSAWG mailing list

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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894595406&sdata=jphAmvQU51PoiIut6am4VWS0WONmUSQpK4RqughuYVY%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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894605358&sdata=eYXRGm6VJOWrRYHuAIpti5I6SdVLkQbQqtkvZAnNRtQ%3D&reserved=0>

Gyan Mishra

M 301 502-1347

13101 Columbia Pike<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7CThomas.Graf%40swisscom.com%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894605358&sdata=GlMv8EhLDGZ%2BUtc%2B9%2F561r6A21Ez1Nd%2B5VW71TcIusQ%3D&reserved=0>

Silver Spring, MD<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7CThomas.Graf%40swisscom.com%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894615316&sdata=ZxfQNW%2Fx3g%2FOm3SbeY%2BfKHqsr2J%2FXoaPlAbLtVgB%2B7E%3D&reserved=0>

<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%2B%250D%250A%2BSilver%2BSpring%2C%2BMD%3Fentry%3Dgmail%26source%3Dg&data=02%7C01%7CThomas.Graf%40swisscom.com%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894615316&sdata=ZxfQNW%2Fx3g%2FOm3SbeY%2BfKHqsr2J%2FXoaPlAbLtVgB%2B7E%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%7C61f6ea640e8744da5a2908d842248435%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332071894615316&sdata=YM6e2JFcGiqA022a6AgodPJ39L%2Fi4TyTGz7kOBcX1ko%3D&reserved=0>

Gyan Mishra

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

---

From: <[email-masked]>
Date: Tue, 18 Aug 2020 12:58:09 +0000

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.

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.

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

Sent: Monday, August 17, 2020 8:51 AM

Hi Thomas,

Hi Ketan,

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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958595571&sdata=rHgl40uEad8j%2B%2BEPevE9%2FIjchXW6fb1gbAKVoJ%2BKLjo%3D&reserved=0>, describes the context.
[KT] Sure, so adding the SR Segments to IE46, one can check whether the traffic forwarding is happening using LDP or SR labels at any link in the network.

Thanks,
Ketan

Best wishes
Thomas

Hi Thomas,

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

And my questions were:

Thanks,
Ketan

Hi Ketan,

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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958595571&sdata=sL2eM979dzvrLxakT%2B2QPGZ6jvJ%2FPV%2FNEyU0%2B6NC8X8%3D&reserved=0>

Best wishes
Thomas

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958605524&sdata=gecKAkX5fMg1hVb7e57U0rOk2VXaEwd503bYq9scCQg%3D&reserved=0>

thanks,

/hannes

Dear lsr,

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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958605524&sdata=t7fbigIqlqItQgLpGfGHiS3%2FNgKgmtRckPj3xsiEw9M%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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958605524&sdata=5cLxNj2JwXgSxGssv5VDWy2CQ1kahsZ3NIWjre%2FP3UQ%3D&reserved=0>

Best Wishes
Thomas Graf
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958615482&sdata=w088GvQPY5tsJ7W4WoTlMNpJv7qkFgEpieAPxUU6Zak%3D&reserved=0>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 18 Aug 2020 14:23:08 +0000

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

Sent: 18 August 2020 18:28

Hi Ketan,

Best Wishes
Thomas

Hi Thomas,

Hi Ketan,

Thanks,
Ketan

Best wishes
Thomas

Hi Thomas,

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

And my questions were:

Thanks,
Ketan

Hi Ketan,

Best wishes
Thomas

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

thanks,

/hannes

Dear lsr,

Best Wishes
Thomas Graf

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 24 Aug 2020 02:08:11 +0000

Hi Thomas, Ketan, all,

While I tend to agree with Ketan that, in principle, specific control plane protocol name might not be the most useful bit of info, I would argue that it still makes more sense to keep IE46 in this format instead of replacing it with srsidtype. I.e. treat IE46 as in 'control plane protocol that is the source/owner of a particular label in LIB/LFIB'. Maybe we should consider adding a generic type 'Segment Routing' w/o extra details if this might become an implementation challenge?

I'm in favor of keeping SrSidType as a separate entity -> this seems to be significantly more complex to implement and arguably IPFIX may not be the best way to collect this info.

--
Sergey
From: spring <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Tuesday, August 18, 2020 7:23 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Hi Thomas,

One small bit.

Thanks,
Ketan

Hi Ketan,

Best Wishes
Thomas

Hi Thomas,

Hi Ketan,

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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958595571&sdata=rHgl40uEad8j%2B%2BEPevE9%2FIjchXW6fb1gbAKVoJ%2BKLjo%3D&reserved=0>, describes the context.
[KT] Sure, so adding the SR Segments to IE46, one can check whether the traffic forwarding is happening using LDP or SR labels at any link in the network..

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

Thanks,
Ketan

Best wishes
Thomas

Hi Thomas,

  *   SR Prefix SID
  *   SR Adjacency SID
  *   SR Binding SID
  *   SR BGP Peering SID
  *   ... and so on

And my questions were:

Thanks,
Ketan

Hi Ketan,

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%7C190258f9ac0e455ad23908d84279fb18%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637332438958595571&sdata=sL2eM979dzvrLxakT%2B2QPGZ6jvJ%2FPV%2FNEyU0%2B6NC8X8%3D&reserved=0>

Best wishes
Thomas

Hi Thomas/All,

Thanks,
Ketan

Hi Hannes,

Best Wishes
Thomas

Thomas,

thanks,

/hannes

Dear lsr,

Best Wishes
Thomas Graf