Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ioam-data-12: Carlos Bernardos review comments #215

Open
brockners opened this issue Mar 22, 2021 · 0 comments
Open

ioam-data-12: Carlos Bernardos review comments #215

brockners opened this issue Mar 22, 2021 · 0 comments

Comments

@brockners
Copy link
Collaborator

Reviewer: Carlos Bernardos
Review result: Ready with Nits

Thanks for this document. I think it is well written and well on track. I include below some comments, mostly from an Internet view point, but not limited to that.

  • I wonder if some SHOULD/MUST language needs to be used in the following piece, as it talks about important operational considerations:

    "The operator has to consider the
    potential operational impact of IOAM to mechanisms such as ECMP
    processing (e.g. load-balancing schemes based on packet length could
    be impacted by the increased packet size due to IOAM), path MTU (i.e.
    ensure that the MTU of all links within a domain is sufficiently
    large to support the increased packet size due to IOAM) and ICMP
    message handling (i.e. in case of IPv6, IOAM support for ICMPv6 Echo
    Request/Reply is desired which would translate into ICMPv6 extensions
    to enable IOAM-Data-Fields to be copied from an Echo Request message
    to an Echo Reply message)."

  • I think a clarification of how an IOAM domain relates to an administrative domain (as mentioned in Section 4) is required. It is not clear if they are the same or an IOAM domain is a subset of an admin domain.

  • Are there any privacy concerns due to the fact of the information that IOAM discloses and can be analyzed by any node in the domain? There is some text in the Security Considerations, but it does not cover in much detail the new risks that it opens due to the additional information disclosure for that belong to the domain.

-Nit: in section 3, some abbreviations follow the approach "XXX: ", while others "YYY ". Please harmonize it. Example of what I mean below:

E2E Edge to Edge

Geneve: Generic Network Virtualization Encapsulation
[I-D.ietf-nvo3-geneve]

Thanks,

Carlos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant