Hi Thomas,
I've clarified a few points inline.
Thank you,
--
Sergey
From: thomas.g...@swisscom.com
Sent: Tuesday, September 1, 2020 12:55 AM
To: Fomin, Sergey (Nokia - US/Mountain View) ;
ketant=40cisco@dmarc.ietf.org
Cc: lsr@ietf.org; spr...@ietf.org; ops...@ietf.org
Subject: RE: [spring]
Hi Sergey,
Thanks for the feedback. I am fully in line with your comment.
* Maybe we should consider adding a generic type 'Segment Routing' w/o
extra details if this might become an implementation challenge?
I would be interested to understand what extra details you would include in
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
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
I agree with Kethan and Jeff.
This draft is extending IPFIX defined in RFC 7011 7012 to support SR
segments over IP export.
Since SR-MPLS reuses the MPLS data plane, why would the existing IPFIX RFCs
also not support SR-MPLS without having to dig into IGP control plane
extensions as from an
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
