By that reasoning, ipfix should be changed to carry multiple destination
options, multiple hop-by-hop options, and contents of unrecognized next
headers. After all, it they occur operators would want to know.Yoyrs,Joel Sent
via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
-------- Original message --------From: Benoit Claise
<benoit.cla...@huawei.com> Date: 5/26/23 10:25 AM (GMT-05:00) To:
bruno.decra...@orange.com, Joel Halpern <j...@joelhalpern.com>, James Guichard
<james.n.guich...@futurewei.com>, "Rob Wilton (rwilton)"
<rwilton=40cisco....@dmarc.ietf.org>, Andrew Alston - IETF
<andrew-ietf=40liquid.t...@dmarc.ietf.org>, BOUCADAIR Mohamed INNOV/NET
<mohamed.boucad...@orange.com> Cc: The IESG <i...@ietf.org>,
draft-ietf-opsawg-ipfix-srv6-...@ietf.org, opsawg-cha...@ietf.org,
opsawg@ietf.org, spring-cha...@ietf.org, John Scudder <j...@juniper.net>
Subject: Re: Andrew Alston's Discuss on draft-ietf-opsawg-ipfix-srv6-srh-13:
(with DISCUSS)
Dear all,
Bruno & Rob are right: "I would expect ipfix to report what’s in
the packet rather than what the IETF would like the packet to be".
This is a basic IPFIX principle.
Bruno is specifically right when he wrote: "removing this section
from the document will likely not change the reality (but may
introduce interop issues)"
Indeed, any decent IPFIX Metering Process should and will
export what it observes, even if multiple instances. This is covered
by 7011 Section 8 (ok, we could argue whether this is single or
multiple Information Element, but that doesn't change the
principle):
If an Information Element is required more than once in a Template,
the different occurrences of this Information Element SHOULD follow
the logical order of their treatments by the Metering Process.
This issue at stake here is a typical case of IESG DISCUSS that the
authors don't want to spend the energy DISCUSSing and prefer to
simply accept it ... as a path of least resistance to get their
document published.
So, in the end, the removal of this section 6.3 between version 13
and 14 doesn't matter too much.
Happy to move on.
Regards, Benoit
On 5/26/2023 8:58 PM,
bruno.decra...@orange.com wrote:
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;
mso-font-charset:2;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:0 268435456 0 0 -2147483648 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:-536869121 1107305727 33554432 0 415 0;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-469750017 -1073732485 9 0 511 0;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:modern;
mso-font-pitch:fixed;
mso-font-signature:-536869121 64767 1 0 415 0;}@font-face
{font-family:"Helvetica 75 Bold";
panose-1:2 11 8 4 2 2 2 2 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-1610612049 1342185563 0 0 159 0;}@font-face
{font-family:"Courier New \,serif\;color\:black";
panose-1:0 0 0 0 0 0 0 0 0 0;
mso-font-alt:"Courier New";
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:auto;
mso-font-signature:0 0 0 0 0 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0cm;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}a:link, span.MsoHyperlink
{mso-style-noshow:yes;
mso-style-priority:99;
color:blue;
text-decoration:underline;
text-underline:single;}a:visited, span.MsoHyperlinkFollowed
{mso-style-noshow:yes;
mso-style-priority:99;
color:purple;
text-decoration:underline;
text-underline:single;}pre
{mso-style-noshow:yes;
mso-style-priority:99;
mso-style-link:"Préformaté HTML Car";
margin:0cm;
mso-pagination:widow-orphan;
tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt
412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt;
font-size:10.0pt;
font-family:"Courier New";
mso-fareast-font-family:Calibri;}p.MsoListParagraph,
li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-style-unhide:no;
mso-style-qformat:yes;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:"Préformaté HTML";
font-family:Consolas;
mso-ascii-font-family:Consolas;
mso-fareast-font-family:Calibri;
mso-hansi-font-family:Consolas;
mso-bidi-font-family:Calibri;}p.msonormal0, li.msonormal0,
div.msonormal0
{mso-style-name:msonormal;
mso-style-unhide:no;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";
mso-ascii-font-family:"Courier New";
mso-hansi-font-family:"Courier New";
mso-bidi-font-family:"Courier New";}p.HTMLPreformatted,
li.HTMLPreformatted, div.HTMLPreformatted
{mso-style-name:"HTML Preformatted";
mso-style-unhide:no;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}span.EmailStyle23
{mso-style-type:personal;
mso-style-noshow:yes;
mso-style-unhide:no;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;
mso-bidi-font-family:Calibri;
color:windowtext;}span.EmailStyle24
{mso-style-type:personal-reply;
mso-style-noshow:yes;
mso-style-unhide:no;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;
font-family:"Arial",sans-serif;
mso-ascii-font-family:Arial;
mso-hansi-font-family:Arial;
mso-bidi-font-family:Arial;
color:windowtext;
mso-text-animation:none;
font-weight:normal;
font-style:normal;
text-decoration:none;
text-underline:none;
text-decoration:none;
text-line-through:none;}p.msipfootered91ed98, li.msipfootered91ed98,
div.msipfootered91ed98
{mso-style-name:msipfootered91ed98;
mso-style-unhide:no;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-size:10.0pt;
mso-ansi-font-size:10.0pt;
mso-bidi-font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}
My 2 cents since I’ve been specifically added
to the thread.
This is meant as a technical feedback FYI (My
own preference would be to avoid being dragged into this
controversy)
I’m not following opsawg but Rob ‘s point
make sense to me. I would expect ipfix to report what’s in
the packet rather than what the IETF would like the packet
to be.
If the reading of RFC 8200 is that a node
receiving an IPv6 packet with multiple routing headers “must
accept and attempt to process”, IMHO ipfix should adhere to that.
IMO the
rule on the source node (which should not push multiple
SRH), does not supersede (or even interfere with) the rule
on the transit node (which must accept it).
I believe that some major vendors are
allowing the insertion of an SRH when doing TI-LFA (Fast
ReRoute on a transit node) [1]. Hence the reality is that
this is implemented, deployed and in real packets.
Mis-accounting traffic, at minimum during TI-LFA and
presumably micro-loop avoidance, will reduce the data
quality of IPFIX.
My understanding of the diff between -13 and
-14 (i.e. removal of §6.3
“Multiple Segment Routing Headers”) is that with or
without this section, implementations would be able to
report multiple SRHs in IPFIX. IOW removing this section
from the document will likely not change the reality (but
may introduce interop issues)
With that in mind, as an individual, keeping
(i.e. reintroducing now) section 6.3 would have my
preference.
[1] from 6MAN WG:
https://mailarchive.ietf.org/arch/msg/ipv6/rhyXUs6uihXji80M7qEEqdn-DPE/
https://mailarchive.ietf.org/arch/msg/ipv6/VV6Dh1_FIA1wVwRV4PnHz8iKTmI/
https://mailarchive.ietf.org/arch/msg/ipv6/yGuBnAaVpbpiWUznMnW7rQ0KN7s/
Regards,
--Bruno
Orange Restricted
From: Joel Halpern
<j...@joelhalpern.com>
Sent: Thursday, May 25, 2023 11:13 PM
To: James Guichard
<james.n.guich...@futurewei.com>; Rob Wilton
(rwilton) <rwilton=40cisco....@dmarc.ietf.org>;
Andrew Alston - IETF
<andrew-ietf=40liquid.t...@dmarc.ietf.org>; John
Scudder <j...@juniper.net>; BOUCADAIR Mohamed
INNOV/NET <mohamed.boucad...@orange.com>
Cc: The IESG <i...@ietf.org>;
draft-ietf-opsawg-ipfix-srv6-...@ietf.org;
opsawg-cha...@ietf.org; opsawg@ietf.org;
spring-cha...@ietf.org
Subject: Re: Andrew Alston's Discuss on
draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)
I would add that the text about
processing such things seems to me to be the typical (and
appropriate) use of the Postel Principle, from which we can
tell that the important part is the rule earlier in the text
that says that EHs occur once each, except for destination
options which may occur exactly twice (before and after a
source routing header. The fact that 8200 doesn't use our now
preferred normative language does not mean we should ignore
its requirements.
Yours,
Joel
On 5/25/2023 1:28 PM, James Guichard wrote:
Hi Rob,
[adding spring chairs as my
comment is directly related to SRv6]
I did some digging on this from
an SRv6 perspective, and no documents explicitly prohibit
using multiple SRH in a packet. However, it is also true
that no documents define what a node is supposed to do if
it encounters another SRH after the topmost SRH has
completed processing. While 8200 might say that IPv6 nodes
must accept and attempt to process EHs occurring any
number of times, SRv6 has no standardized mechanism
defined to process multiple SRH.
Hope this helps.
Jim
From: iesg
<iesg-boun...@ietf.org>
On Behalf Of
Rob Wilton (rwilton)
Sent: Thursday, May 25, 2023 12:31 PM
To: Andrew Alston - IETF
<andrew-ietf=40liquid.t...@dmarc.ietf.org>;
John Scudder
<j...@juniper.net>; mohamed.boucad...@orange.com
Cc: The IESG <i...@ietf.org>;
draft-ietf-opsawg-ipfix-srv6-...@ietf.org;
opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: RE: Andrew Alston's Discuss on
draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)
Hi,
I don’t think that John’s example is quite
the same. The IPv6 packet header format only has a space
for a single source address and it is 16 bytes long. Two
source addresses or a 20-byte address is clearly an
invalid IPv6 packet because it doesn’t match the IPv6
packet format.
But I don’t think that this is quite true for
IPv6 extension headers, where the text states:
Each extension header should occur at most
once, except for the
Destination Options header, which should
occur at most twice (once
before a Routing header and once before
the upper-layer header).
But it also states in the same section:
IPv6 nodes must accept and attempt to process extension headers in
any order and occurring any number of times in the same packet,
except for the Hop-by-Hop Options header, which is restricted to
appear immediately after an IPv6 header only. Nonetheless, it is
strongly advised that sources of IPv6 packets adhere to the above
recommended order until and unless subsequent specifications revise
that recommendation.
This second paragraph, which is just as
normative as the first, seems to clearly indicate that
IPv6 nodes are expected to handle and process extension
headers occurring multiple times, implying that they could
occur.
Hence, I suspect that it is this second
paragraph as to why Thomas was trying to define how IPFIX
works if this scenario is encountered in the wild. E.g.,
operationally, it is better to report what you actually
see rather report what the operator/client ideally wants
to believe is in the packet. I.e., if your IPv6 node does
receive a packet with two SRv6 headers (which I still
believe RFC 8200 allows for), and modulo Jim’s argument
that this is invalid, then I would still argue that it is
more helpful to report that they are both there than just
reporting the first one and ignoring the second. YANG
NMDA, RFC 8342 is designed similarly. Even if a YANG list
states that it can only contain 2 elements, but due to
some (presumably buggy) reason, the device actually has 3,
it is better to report all three than just pretend that
there are only 2 elements, because it helps the operator
debug that something is going wrong (section 5.3).
I would argue that Jim’s argument that
another SRv6 related RFC (I don’t know which one) clearly
indicates that a v6 header can only ever contain a single
SRH header holds a little more sway and is perhaps more
relevant.
Having said all that, I think that point is
somewhat moot because I think that the authors have agreed
to remove this paragraph anyway – even if IMO it possibly
makes the spec a bit less robust/helpful.
Regards,
Rob
From: iesg <iesg-boun...@ietf.org>
On Behalf Of Andrew Alston - IETF
Sent: 25 May 2023 16:54
To: John Scudder <j...@juniper.net>;
mohamed.boucad...@orange.com
Cc: The IESG <i...@ietf.org>;
draft-ietf-opsawg-ipfix-srv6-...@ietf.org;
opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Re: Andrew Alston's Discuss on
draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)
Hi Med,
Firstly – I need to second
what John said below. Secondly, while we can agree that
IPFIX supporting this doesn’t violate the RFC – what it
does do – is cater explicitly for what I believe is a
violation of RFC8200, and that is where I have a
problem.
While there could be *many*
things that are done out of spec – unless there is a
very specific and solid reason to cater for such out of
spec behavior, this doesn’t make sense to pick and
choose the out of spec we are agreeing to suddenly cater
for.
Thanks
Andrew
From:
John Scudder <j...@juniper.net>
Date: Thursday, 25 May 2023 at 16:33
To: mohamed.boucad...@orange.com
<mohamed.boucad...@orange.com>
Cc: Andrew Alston - IETF <andrew-i...@liquid.tech>,
The IESG <i...@ietf.org>,
draft-ietf-opsawg-ipfix-srv6-...@ietf.org
<draft-ietf-opsawg-ipfix-srv6-...@ietf.org>,
opsawg-cha...@ietf.org
<opsawg-cha...@ietf.org>,
opsawg@ietf.org
<opsawg@ietf.org>
Subject: Re: Andrew Alston's Discuss on
draft-ietf-opsawg-ipfix-srv6-srh-13: (with DISCUSS)
Hi Med,
Not my DISCUSS, but… I did take a look at that thread
earlier and found it somewhat unsatisfying. In
particular, I find it a little odd that we feel the need
to cover this particular out-of-spec behavior with IPFIX
but not others — to take some extreme examples, how
would IPFIX handle a packet with two source addresses? A
packet with a 20-byte destination address? You can tell
me that these aren’t possible so it doesn’t need to
handle them, but that’s the point (as I understand it).
$0.02,
—John
> On May 25, 2023, at 9:14 AM, mohamed.boucad...@orange.com
wrote:
>
> Hi Andrew,
>
> (replying as the doc shepherd)
>
> Éric raised a similar comment. I shared already
some context about that section: FYI, this point was
discussed in the WG especially that there is no SPING
document that motivates/explains the use of multiple
SRHs. Please check:
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/opsawg/SVm4TZk1v6-a0WJwALk3FrUunFU/__;!!NEt6yMaO-gk!Dqk0pIxnGjA2Vlh7UL9wPsJy3iaHiPQ_mbdLAYsZ75BNxWqgxagtdnR_shIVNSp9F-GG_g7TBAFpbyc-kuhiV4jT$
for why the authors think this section is useful to be
maintained in the document.
>
> As currently worded, Section 6.3 does not violate
any RFC. It only ensures that it can successfully export
what it is observed in packets. This can be even used to
detect abnormal behaviors/packs, which is one of the
observability goals of IPFIX.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Andrew Alston via Datatracker <nore...@ietf.org>
>> Envoyé : jeudi 25 mai 2023 15:03
>> À : The IESG <i...@ietf.org>
>> Cc : draft-ietf-opsawg-ipfix-srv6-...@ietf.org;
opsawg-
>> cha...@ietf.org;
opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET
>> <mohamed.boucad...@orange.com>;
BOUCADAIR Mohamed INNOV/NET
>> <mohamed.boucad...@orange.com>
>> Objet : Andrew Alston's Discuss on
draft-ietf-opsawg-ipfix-srv6-srh-
>> 13: (with DISCUSS)
>>
>> Andrew Alston has entered the following ballot
position for
>> draft-ietf-opsawg-ipfix-srv6-srh-13: Discuss
>>
>> When responding, please keep the subject line
intact and reply to
>> all email addresses included in the To and CC
lines. (Feel free to
>> cut this introductory paragraph, however.)
>>
>>
>>
>>
>>
--------------------------------------------------------------------
>> --
>> DISCUSS:
>>
--------------------------------------------------------------------
>> --
>>
>> Hi There,
>>
>> Thanks for the document.
>>
>> I am issuing a discuss based on section 6.3 of
the document that I'd
>> like to
>> talk about. RFC8200 Section 4.1 states:
>>
>> Each extension header should occur at most
once, except for the
>> Destination Options header, which should occur
at most twice
>> (once
>> before a Routing header and once before the
upper-layer header).
>>
>> I also note that RFC8200 is not written using
normative language -
>> but
>> considering the context I am assuming that this
should be read as
>> such.
>>
>> This directly conflicts with section 6.3 -
which makes allowance for
>> multiple
>> SRH in the packet. The only way that multiple
SRH's should be
>> allowed to occur
>> in the packet is if the packet is
re-encapsulated - at which point
>> section 6.3
>> would still (in my view) not be referring to
multiple SRH's - since
>> the second
>> SRH would be attached to a fully encapsulated
packet.
>>
>> If there is indeed a need for multiple SRH in
IPFIX - this would
>> require a
>> pretty clear explanation as to why, how this
could occur and a
>> strong
>> justification for violating RFC8200 in my
opinion.
>>
>>
>>
>>
>
>
>
_________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir
des informations confidentielles ou privilegiees et ne
doivent donc
> pas etre diffuses, exploites ou copies sans
autorisation. Si vous avez recu ce message par erreur,
veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces
jointes. Les messages electroniques etant susceptibles
d'alteration,
> Orange decline toute responsabilite si ce message a
ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain
confidential or privileged information that may be
protected by law;
> they should not be distributed, used or copied
without authorisation.
> If you have received this email in error, please
notify the sender and delete this message and its
attachments.
> As emails may be altered, Orange is not liable for
messages that have been modified, changed or falsified.
> Thank you.
Internal All Employees
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
