Hi Greg,
Inline.
Thanks,
Pablo.
From: Greg Mirsky <gregimir...@gmail.com>
Date: Tuesday, 7 January 2020 at 21:01
To: Bruno Decraene <bruno.decra...@orange.com>
Cc: SPRING WG List <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org>,
draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <alias-boun...@ietf.org>
Resent to: <c...@cisco.com>, <pcama...@cisco.com>, <j...@leddy.net>,
<daniel.vo...@bell.ca>, <satoru.matsush...@g.softbank.co.jp>,
<lizhen...@huawei.com>
Resent date: Tuesday, 7 January 2020 at 21:01
Dear Authors, WG Chairs, et al.,
I hope I'm not too late with my comments and questions on the document. Please
kindly consider them as WG LC comments:
· I have a question regarding the following pseudo-code:
S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address,
Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field.
Interrupt packet processing and discard the packet.
S11. }
According to RFC 8200, Hdr Ext Len is the length of the extension header in
8-octet units, not including the first 8 octets. Thus, as I understand, max_LE
is the length in 8-octet units of half of the extension header less one. On the
other hand, Last Entry and Segments Left are indices. Hence my question, What
is being compared in line S09 ( Last Entry > max_LE)? Length and index? If the
goal is to use Hdr Ext Len to calculate the number of entries in the header,
then what assumption is used in S08? Is it that the entry's length is always
and only 128 bits, i.e. 16 octets? I believe that using such an assumption is
too narrowing and limiting to SRH.
PC: This has already been discussed with Adrian. Please check this thread:
https://mailarchive.ietf.org/arch/msg/spring/IOA_4nlNPacD2v7Jue2dkGeOABk
· Another question is to Section 6.3. What value do you see in this
section? I've noticed that draft-ietf-6man-spring-srv6-oam is in the
Informational References section. I agree with that for the first sentence in
the section. But I believe that the second sentence that refers to the new
O-bit and OAM behaviors defined in draft-ietf-6man-spring-srv6-oam requires it
to be moved into the Normative References section. Unless you'll decide to
remove the section altogether.
PC: The O-bit and OAM behaviors described in draft-ietf-6man-spring-srv6-oam
are not required to understand or implement the technology described in
draft-ietf-spring-srv6-network-programming. However, they are relevant as to
provide additional information to the reader. Why would it be a normative
reference?
Regards,
Greg
On Thu, Dec 5, 2019 at 9:15 AM
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:
Hello SPRING,
This email starts a two weeks Working Group Last Call on
draft-ietf-spring-srv6-network-programming [1].
Please read this document if you haven't read the most recent version, and send
your comments to the SPRING WG list, no later than December 20.
You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating
emails on the 6MAN mailing list for the comments which are only spring
specifics.
If you are raising a point which you expect will be specifically debated on the
mailing list, consider using a specific email/thread for this point.
This may help avoiding that the thread become specific to this point and that
other points get forgotten (or that the thread get converted into parallel
independent discussions)
Thank you,
Bruno
[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05
_________________________________________________________________________________________________________________________
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org<mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
