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.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/ ---------------------------------------------------------------------- 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
