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><mailto: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><mailto:andrew-ietf=40liquid.t...@dmarc.ietf.org>; John Scudder <j...@juniper.net><mailto:j...@juniper.net>; mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> Cc: The IESG <i...@ietf.org><mailto:i...@ietf.org>; draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto: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<mailto:iesg-boun...@ietf.org>> On Behalf Of Andrew Alston - IETF Sent: 25 May 2023 16:54 To: John Scudder <j...@juniper.net<mailto:j...@juniper.net>>; mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>; opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto: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<mailto:j...@juniper.net>> Date: Thursday, 25 May 2023 at 16:33 To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc: Andrew Alston - IETF <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org> <draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>>, opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto: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<mailto: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$<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<mailto:nore...@ietf.org>> >> Envoyé : jeudi 25 mai 2023 15:03 >> À : The IESG <i...@ietf.org<mailto:i...@ietf.org>> >> Cc : >> draft-ietf-opsawg-ipfix-srv6-...@ietf.org<mailto:draft-ietf-opsawg-ipfix-srv6-...@ietf.org>; >> opsawg- >> cha...@ietf.org<mailto:cha...@ietf.org>; >> opsawg@ietf.org<mailto:opsawg@ietf.org>; BOUCADAIR Mohamed INNOV/NET >> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; >> BOUCADAIR Mohamed INNOV/NET >> <mohamed.boucad...@orange.com<mailto: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
