Re: [OPSAWG] draft-ietf-opsawg-ipfix-fixes-05 shepherd review

[mohamed . boucadair]

Hi Thomas, all,

 

Thanks for preparing the writeup. Looks good to me.

 

I hope to receive more feedback on whether we mark these two IEs as
deprecated.

 

For forwardingStatus, I reiterate that the type should be unsigned32
as per the RFC.

 

Cheers,

Med

 

De : thomas.g...@swisscom.com  
Envoyé : samedi 3 février 2024 12:09
À : draft-ietf-opsawg-ipfix-fixes.auth...@ietf.org
Cc : draft-ietf-opsawg-ipfix-fixes.cha...@ietf.org; opsawg@ietf.org
Objet : draft-ietf-opsawg-ipfix-fixes-05 shepherd review

 

Dear Med and Benoit,

 

Thanks a lot. The document is straight forward and is a very valuable
contribution to the Internet community since it updates existing IPFIX
entities to make them consistent, which is for IPFIX data collections
which obtain the information from the IPFIX IANA registry especially
relevant, have references to other registries instead of re-defining
them eases the update procedures in the future and last but not least
updating some of the descriptions due to shortcomings for more
clarity. 

 

I have reviewed the document and wrote the initial shepherd review.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/shepher
dwriteup/

 

I am looking forward for the feedback from the OPSAWG mailing list
wherever ipv6ExtensionHeaders and tcpOptions in favor of
ipv6ExtensionHeadersFull and tcpOptionsFull defined in
draft-ietf-opsawg-ipfix-tcpo-v6eh. Depending on feedback on the
mailing list, a poll at the IETF 119 maybe could be useful as well.

 

ipv6ExtensionHeaders has been adopted by network vendors widely. Where
tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DA
qA/, merely used to its ambiguity.

 

I therefore suggest to deprecate tcpOptions. I suggest also
ipv6ExtensionHeaders to deprecate because not all observed extension
headers in a Flow maybe export because of a hardware or software limit
as described in Section 4.1.1 of this document and addressed with
ipv6ExtensionHeadersLimit.

 

As a contributor, I like also to confirm the authors opinions that
forwardingStatus should be unsigned32 instead of unsigned8 not only
because RFC 7270 specifies forwardingStatus as unsigned32, but it
reserves 3 bytes. We have with draft-opsawg-evans-discardmodel and
draft-mvmd-opsawg-ipfix-fwd-exceptions two documents showing interest
to describe the forwarding behavior in IPFIX. We have on OPSAWG
mailing list
https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-mvmd-opsawg-i
pfix-fwd-exceptions various feedback that an update, extension of
forwardingStatus would be preferred instead of introducing a new IPFIX
entity.

 

Best wishes

Thomas

Orange Restricted

 



smime.p7s
Description: S/MIME cryptographic signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] draft-ietf-opsawg-ipfix-fixes-05 shepherd review

[Thomas.Graf]

Dear Med and Benoit,

Thanks a lot. The document is straight forward and is a very valuable 
contribution to the Internet community since it updates existing IPFIX entities 
to make them consistent, which is for IPFIX data collections which obtain the 
information from the IPFIX IANA registry especially relevant, have references 
to other registries instead of re-defining them eases the update procedures in 
the future and last but not least updating some of the descriptions due to 
shortcomings for more clarity.

I have reviewed the document and wrote the initial shepherd review. 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/shepherdwriteup/

I am looking forward for the feedback from the OPSAWG mailing list wherever 
ipv6ExtensionHeaders and tcpOptions in favor of ipv6ExtensionHeadersFull and 
tcpOptionsFull defined in draft-ietf-opsawg-ipfix-tcpo-v6eh. Depending on 
feedback on the mailing list, a poll at the IETF 119 maybe could be useful as 
well.

ipv6ExtensionHeaders has been adopted by network vendors widely. Where 
tcpOptions appears to be, 
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/, 
merely used to its ambiguity.

I therefore suggest to deprecate tcpOptions. I suggest also 
ipv6ExtensionHeaders to deprecate because not all observed extension headers in 
a Flow maybe export because of a hardware or software limit as described in 
Section 4.1.1 of this document and addressed with ipv6ExtensionHeadersLimit.

As a contributor, I like also to confirm the authors opinions that 
forwardingStatus should be unsigned32 instead of unsigned8 not only because RFC 
7270 specifies forwardingStatus as unsigned32, but it reserves 3 bytes. We have 
with draft-opsawg-evans-discardmodel and draft-mvmd-opsawg-ipfix-fwd-exceptions 
two documents showing interest to describe the forwarding behavior in IPFIX. We 
have on OPSAWG mailing list 
https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-mvmd-opsawg-ipfix-fwd-exceptions
 various feedback that an update, extension of forwardingStatus would be 
preferred instead of introducing a new IPFIX entity.

Best wishes
Thomas


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg