Hi Med
Thanks much for your time in reviewing. We will discuss on this and get back to
you soon.
Regards
--Sriram
From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
Date: Thursday, 9 January 2025 at 7:53 PM
To: Sriram Gopalakrishnan (sriragop) <srira...@cisco.com>, opsawg@ietf.org
<opsawg@ietf.org>
Cc: opsawg@ietf.org <opsawg@ietf.org>, Dan-work Voyer <danvoyerw...@gmail.com>,
thomas.g...@swisscom.com <thomas.g...@swisscom.com>
Subject: RE: [OPSAWG]Re: I-D Action: draft-ietf-opsawg-ipfix-gtpu-03.txt
Hi Sriram, all,
Thank you for taking care of some of the comments I raised in my review. I
checked the 00/03 diff and I think that the text is improved. I do still think
that we need some discussion on the pending points:
* Should we add a statement about the base 3GPP release used to define the
IEs?
* Is it worth to also report the extension header chain? Also, the peer
tunnel endpoint?
* gtpuFlags
* This also cover the version. Not sure «flags» is accurate here. A
better name is needed if the version is also included.
* (5.1 description) I would say this corresponds to the first byte of
the header. The internal structure may change in the future (associate a
meaning with the remaining bit, etc.). The current description may be stale
then.
* I would insist that the bits are exported as observed. This allows,
for example, to export the current unassigned bit even if no meaning is
associated with it yet.
* As the header length is variable, is it worth to also export the length
as a separate IE?
* At the collector side, the presence of this IE when the S bit is unset
should be handled as an anomaly. I would add some text to cover this. Also,
indicate which one takes precedence.
* pdutype: I like the new text (s/presense/presence, though). However, I
would be more explicit that if this IE is present when E bit is not set is
considered as an anomaly. In such case, which information takes precedence?
* Can we cover how IPFIX can help to cover: «When using GTP-U over IPv6
(see IETF RFC 8200 [36]), the UDP checksum shall not be set to zero by the
sending GTP-U entity unless it is ensured that the peer GTP-U entity and the
path in-between supports UDP zero checksum. NOTE 1: GTP-U entities complying
with an earlier version of the specification or on path IPv6 middleboxes can
implement IPv6 as specified in IETF RFC 2460 [15] and discard UDP packets
containing a zero checksum. »
* What is an “intermediate UPF”?
* “or Uplink Classifier”: This corresponds to which entity in the 3GPP
architecture?
Cheers,
Med
De : Sriram Gopalakrishnan (sriragop) <sriragop=40cisco....@dmarc.ietf.org>
Envoyé : jeudi 9 janvier 2025 10:46
À : opsawg@ietf.org; i-d-annou...@ietf.org
Cc : opsawg@ietf.org; Dan-work Voyer <danvoyerw...@gmail.com>;
thomas.g...@swisscom.com
Objet : [OPSAWG]Re: I-D Action: draft-ietf-opsawg-ipfix-gtpu-03.txt
Hello OPSAWG
I have uploaded the -03 version of the draft. The update includes
1) changes to IE description in Section 5.
2) fixed this error – ‘** Downref: Normative reference to an Informational RFC:
RFC 6459’. Moved it to Informative reference
Please find the diff attached since last version.
Thanks
--Sriram
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
<internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>>
Date: Thursday, 9 January 2025 at 2:57 PM
To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
<i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>
<opsawg@ietf.org<mailto:opsawg@ietf.org>>
Subject: [OPSAWG]I-D Action: draft-ietf-opsawg-ipfix-gtpu-03.txt
Internet-Draft draft-ietf-opsawg-ipfix-gtpu-03.txt is now available. It is a
work item of the Operations and Management Area Working Group (OPSAWG) WG of
the IETF.
Title: Export of GTP-U Information in IP Flow Information Export (IPFIX)
Authors: Daniel Voyer
Sriram Gopalakrishnan
Thomas Graf
Vyasraj Satyanarayana
Name: draft-ietf-opsawg-ipfix-gtpu-03.txt
Pages: 14
Dates: 2025-01-09
Abstract:
This document introduces IP Flow Information Export (IPFIX)
Information Elements to report information contained in the Generic
Packet Radio Service Tunneling Protocol User Plane header such as
Tunnel Endpoint Identifier, and data contained in its session
container extension header.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-gtpu/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-gtpu-03
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-gtpu-03
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org>
To unsubscribe send an email to
opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org>
____________________________________________________________________________________________________________
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
To unsubscribe send an email to opsawg-le...@ietf.org
