Brian,
Il 2020-02-27 03:29, Brian E Carpenter ha scritto:
Stefano,
On 27-Feb-20 14:42, Stefano Salsano wrote:
Il 2020-02-27 02:14, Brian E Carpenter ha scritto:
Eric,
On 27-Feb-20 12:18, Eric Vyncke (evyncke) wrote:
Writing this without any hat,
Please note that on the logical side, it still have to be "proven" that this
idea is strictly forbidden by RFC 8200.
The draft uses an undefined term ("pop") but it does *explicitly* state in a section
called "Penultimate Segment Pop of the SRH":
S14.4. Remove the SRH from the IPv6 extension header chain
If the word "penultimate" means what it means in every dictionary, this is
in-flight removal of a header, and that is explicitly against RFC 8200, section 4, first
paragraph below the diagram.
Brian,
"penultimate segment" means what it means in every dictionary, but this
is not in-fligth removal of a header.
When the packet has reached the "penultimate segment", it has reached a
node "identified in the Destination Address field of the IPv6 header" as
stated in RFC 8200, section 4, first paragraph below the diagram
So in what sense is it penultimate (i.e. next to last)? If it has reached
the destination address,
if the segment list is [S1, S2, S3] (where S1 is the first segment and
S3 the final destination)
S2 is the penultimate segment and the packet is received by S2 with
Destination Address = S2, I repeat that at the very end of section 3 of
RFC 8200 the "Destination address" is defined as "address of the
intended recipient of the packet (possibly not the ultimate recipient,
if a Routing header is present)"
what happens next?
next the packet needs to be forwarded to S3
I understand this for the following case, Ultimate Segment Pop, where the
text refers to processing the packet inside the receiving node. But the
text is completely lacking an explanation of the "penultimate" case,
and I found nothing about it in other SRH documents either.
If I was writing code for this, I would have no idea how to generate a
test case.
It's also obscure in the text how the node receiving a packet knows
which of "PSP, USP and USD flavors" applies. They don't seem to be marked
in the packet in any way.
it is not marked in the packet, likewise it is not marked in the packet
which SRv6 behavior is associated with a SID
Stefano
It seems to me that there is something blindingly obvious to SRH specialists
that is not stated at all in the draft, so the rest of us simply can't make
sense of it. It may or may not be a gap in the protocol, but there is
definitely a gap in the description.
Brian
Please note that at the very end of section 3 the "Destination address"
is defined as "address of the intended recipient of the packet (possibly
not the ultimate recipient, if a Routing header is present)"
Stefano
It's possible that "penultimate" means something else, e.g. "ultimate". I don't know.
I've been puzzling over this language for months and it doesn't change. Maybe someone can finally post an
explanation, but until they do, I don't see how any WG Chair could assert rough consensus. An obviously
organised +1+1+1+1 campaign is not consensus. I don't know about you, but when I see a message whose only
content is "+1" I just delete it.
Brian
Moreover, this 'proof' can technically wait until the IETF last call or even
until the IESG ballot. I see little point in postponing the closing of the WGLC
and advancing the document (of course, the document shepherd will need to
carefully write the section about the rough WG consensus).
Finally, as far as I know, at the IETF we have no religion... else we would
still be running NCP or IPv4 :-)
-éric
-----Original Message-----
From: ipv6 <ipv6-boun...@ietf.org> on behalf of Warren Kumari
<war...@kumari.net>
...%<...%<....
It doesn't really matter how many people say +1 for moving it forwards
-- if there are valid technical objections these have to be dealt with
- and I think that the relationship with RFC8200 falling into this
category...
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY
http://netgroup.uniroma2.it/Stefano_Salsano/
E-mail : stefano.sals...@uniroma2.it
Cell. : +39 320 4307310
Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
