Hi all, I agree with Benoît that the justification of limited space (64 values) seems to be weak given existing codes and proposed new ones. However, after reading RFC 7270, I think that there might be a value in refreshing the existing IE#89 for the sake of better interoperability and promoting it to the Standard Track. Please note also that some of the subcodes are weakly defined (e.g., adjacent, for us) in RFC7270.
Cheers, Med De : OPSAWG <opsawg-boun...@ietf.org> De la part de Benoit Claise Envoyé : mardi 14 novembre 2023 14:40 À : Venkata Naga Chaitanya Munukutla <vmunuku=40juniper....@dmarc.ietf.org>; opsawg@ietf.org Cc : Shivam Vaid <shiv...@juniper.net>; Vishnu Pavan Beeram <vbee...@juniper.net>; Aditya Mahale <amah...@google.com>; pateldev...@google.com Objet : Re: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption Dear Chaitana, If finally read the draft. You mentioned: There is an existing IE 89 - forwardingStatus [IANA-IPFIX<https://www.iana.org/assignments/ipfix>] but it allows a very limited number of exceptions to be reported from the system (6-bit reason code) But at the same time, you just present a couple of entries in your table 3 +----------------+--------------------------------------------------+ | Forwarding | Reason | | Exception Code | | +----------------+--------------------------------------------------+ | 1 | FIREWALL_DISCARD | | 2 | TTL_EXPIRY | | 3 | DISCARD_ROUTE | | 4 | BAD_IPV4_CHECKSUM | | 5 | REJECT_ROUTE | | 6 | BAD_IPV4_HEADER (Version incorrect or IHL < 5)| | 7 | BAD_IPV6_HEADER (Version incorrect) | | 8 | BAD_IPV4_HEADER_LENGTH (V4 frame is too short) | | 9 | BAD_IPV6_HEADER_LENGTH | | 10 | BAD_IPV6_OPTIONS_PACKET(too many option headers) | | .. | .. | +----------------+--------------------------------------------------+ Table 3: Forwarding Status Codes If I look at the series of Dropped Reason for IPFIX IE ForwardingStatus, at https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status, this list is even more complete. Binary [https://www.iana.org/assignments/_support/sort_none.gif] Hex [https://www.iana.org/assignments/_support/sort_none.gif] Description [https://www.iana.org/assignments/_support/sort_none.gif] Reference [https://www.iana.org/assignments/_support/sort_none.gif] 10 000000b 0x80 Unknown [RFC7270<https://www.iana.org/go/rfc7270>] 10 000001b 0x81 ACL deny [RFC7270<https://www.iana.org/go/rfc7270>] 10 000010b 0x82 ACL drop [RFC7270<https://www.iana.org/go/rfc7270>] 10 000011b 0x83 Unroutable [RFC7270<https://www.iana.org/go/rfc7270>] 10 000100b 0x84 Adjacency [RFC7270<https://www.iana.org/go/rfc7270>] 10 000101b 0x85 Fragmentation and DF set [RFC7270<https://www.iana.org/go/rfc7270>] 10 000110b 0x86 Bad header checksum [RFC7270<https://www.iana.org/go/rfc7270>] 10 000111b 0x87 Bad total Length [RFC7270<https://www.iana.org/go/rfc7270>] 10 001000b 0x88 Bad header length [RFC7270<https://www.iana.org/go/rfc7270>] 10 001001b 0x89 bad TTL [RFC7270<https://www.iana.org/go/rfc7270>] 10 001010b 0x8A Policer [RFC7270<https://www.iana.org/go/rfc7270>] 10 001011b 0x8B WRED [RFC7270<https://www.iana.org/go/rfc7270>] 10 001100b 0x8C RPF [RFC7270<https://www.iana.org/go/rfc7270>] 10 001101b 0x8D For us [RFC7270<https://www.iana.org/go/rfc7270>] 10 001110b 0x8E Bad output interface [RFC7270<https://www.iana.org/go/rfc7270>] 10 001111b 0x8F Hardware [RFC7270<https://www.iana.org/go/rfc7270>] 0x90-0xBF Unassigned Status 11b: Consumed If this list is not complete, we should update it with some additional drop reasons, as opposed to define yet a new overlapping IPFIX IE... Especially at the time where we try to clean up the IPFIX registry. Note: I know of at least two vendors that implemented forwardingStatus. Regarding forwardingNextHopID, we already have a series of nexthop-related IPFIX IE. As a matter of fact, even the IPv4 and IPv6 are different IPFIX IEs in the IANA registry (whether this is right or wrong is irrelevant, that was a decision taken years ago) Therefore, I am afraid I can't support WG adoption of this draft. Regards, Benoit On 11/6/2023 3:56 PM, Venkata Naga Chaitanya Munukutla wrote: Hello OPSAWG experts, We've posted version v08 for IPFIX Extensions for Forwarding Exceptions (minor editorial changes). https://datatracker.ietf.org/doc/draft-mvmd-opsawg-ipfix-fwd-exceptions/08/ The document has been stable for a while and we believe it is sufficiently baked to be considered for WG adoption. The last time we presented this draft (IETF116), there seemed to be a reasonable amount of interest in the work (as captured in the meeting notes -- https://notes.ietf.org/notes-ietf-116-opsawg) . We would like to invite more feedback on this document and also formally request WG adoption. Thanks, Chaitanya (on behalf of co-authors/contributors) Juniper Business Use Only _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg ____________________________________________________________________________________________________________ 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
