Hi,
I think this version makes the issue very clear (and orthogonal to the
question whether RFC8200 says what it was intended to say).
May I humbly suggest a *new* WGLC on this version?
Regards
Brian Carpenter
On 05-Mar-20 01:25, Pablo Camarillo (pcamaril) wrote:
> Brian, Bruno,
>
> I have
Brian, Bruno,
I have just made this change to the draft.
This is the only change for revision 12.
Many thanks,
Pablo.
-Original Message-
From: Brian E Carpenter
Date: Tuesday, 3 March 2020 at 22:17
To: "Pablo Camarillo (pcamaril)" ,
"bruno.decra...@orange.com"
Cc: "Darren Dukes (dduk
Right, let's get the text clarified. Whether or not the IETF (not just these
two WGs, which plainly cannot agree) accepts or refuses this interpretation of
RFC 8200 is a separate question.
Regards
Brian
On 04-Mar-20 09:37, Pablo Camarillo (pcamaril) wrote:
> Brian, Bruno,
>
>
>
> Many th
Brian, Bruno,
Many thanks for your comments.
Based on the feedback I would propose to add Brian's proposed text as is into
the draft.
4.16.1. PSP: Penultimate Segment Pop of the SRH
SR Segment Endpoint Nodes advertise the SIDs instantiated on them via
control plane protocols as d
Pablo,
My reading is that Brian is asking for a clarification of the text, not a
change in the behavior.
In general, I think that clarification is good and that Brian's request is
reasonable.
Related to Brian's comment, but on top of them, I have further points on this
section 4.16.1:
1)
" S
On 2/3/20 20:21, Brian E Carpenter wrote:
On 03-Mar-20 09:02, Pablo Camarillo (pcamaril) wrote:
Brian,
The PSP pseudocode is presented as a modification to the End pseudocode
starting at line S14 of such.
Please go through the PSP pseudocode in conjunction with the End pseudocode
(Section 4.1
On 2/3/20 20:21, Brian E Carpenter wrote:
On 03-Mar-20 09:02, Pablo Camarillo (pcamaril) wrote:
Brian,
The PSP pseudocode is presented as a modification to the End pseudocode
starting at line S14 of such.
Please go through the PSP pseudocode in conjunction with the End pseudocode
(Section 4.1
On 03-Mar-20 09:02, Pablo Camarillo (pcamaril) wrote:
> Brian,
>
> The PSP pseudocode is presented as a modification to the End pseudocode
> starting at line S14 of such.
> Please go through the PSP pseudocode in conjunction with the End pseudocode
> (Section 4.1).
> You will see that the ingre
On 2/3/20 18:09, Darren Dukes (ddukes) wrote:
Fernando, you are wrong. SRH processing only occurs at the segment endpoint, there
is no "processing the routing header again”.
Does the fact that PSP stands for "Penultimate Segment Pop" ring any bells?
PSP specifies en-route removal of IPv6 ext
Fernando, you are wrong. SRH processing only occurs at the segment endpoint,
there is no "processing the routing header again”.
Darren
> On Mar 2, 2020, at 3:45 PM, Fernando Gont wrote:
>
> On 2/3/20 17:02, Pablo Camarillo (pcamaril) wrote:
>> Brian,
>> The PSP pseudocode is presented as a m
On 2/3/20 17:02, Pablo Camarillo (pcamaril) wrote:
Brian,
The PSP pseudocode is presented as a modification to the End pseudocode
starting at line S14 of such.
Please go through the PSP pseudocode in conjunction with the End pseudocode
(Section 4.1).
You will see that the ingress state of the
Brian,
The PSP pseudocode is presented as a modification to the End pseudocode
starting at line S14 of such.
Please go through the PSP pseudocode in conjunction with the End pseudocode
(Section 4.1).
You will see that the ingress state of the packet is (Segments Left == 1 and
Destination Addre
Darren,
Regardless of whether you accept Fernando's comment about the intention of RFC
8200, there is also the fact that the description of the PSP flavor cheats by
considering the packet to have
(Segments Left == 0 and Destination Address == the PSP node's address).
In fact that is *never* the
On 2/3/20 11:52, Darren Dukes (ddukes) wrote:
What follows has been made clear on the list for a while,
I am re-stating it.
The draft-ietf-spring-srv6-network-programming PSP behavior
strictly follows the letter of RFC 8200.
RFC8200 section 4 says:
Extension headers (except for the
What follows has been made clear on the list for a while,
I am re-stating it.
The draft-ietf-spring-srv6-network-programming PSP behavior
strictly follows the letter of RFC 8200.
RFC8200 section 4 says:
Extension headers (except for the Hop-by-Hop Options header) are not
processed
15 matches
Mail list logo
